Ein heimischer NVR kann nur so viele Streams analysieren, wie sein Detektor und seine Videopipeline verarbeiten können, ohne die konfigurierte Erkennungsrate jeder Kamera zu verringern.
Wenn acht Kameras jeweils fünf Erkennungsbilder pro Sekunde anfordern, muss der Detektor nach Berücksichtigung des Overheads mindestens 40 Inferenzen pro Sekunde verarbeiten können. Doch auch Dekodierung, Größenanpassung, Tracking, Aufzeichnung und Bewegungserkennung beanspruchen CPU, GPU, Speicherbandbreite und I/O. Das tatsächliche Stream-Limit ist erreicht, sobald die Erkennungshäufigkeit pro Kamera oder die Ereignislatenz bei gleichzeitiger Aktivität im Haushalt nachlässt.
Der Erkennungsbedarf ergibt sich aus Streams multipliziert mit der Erkennungs-FPS
Die einfachste Mindestanforderung ist die Anzahl der Kameras multipliziert mit der konfigurierten Anzahl der Erkennungsbilder pro Sekunde. Zehn Kameras mit fünf FPS fordern 50 analysierte Bilder pro Sekunde an. Bewegungserkennung kann den tatsächlichen Arbeitsaufwand reduzieren, doch bei der Kapazitätsplanung sollten Zeiträume berücksichtigt werden, in denen viele Kameras gleichzeitig aktiv sind.
Das Projekt zur lokalen Objekterkennung trennt lokale Aufzeichnung von der Objekterkennung in Echtzeit und empfiehlt gegenüber einer rein CPU-basierten Erkennung eine dedizierte Beschleunigung. Diese Pfade belasten denselben Server auf unterschiedliche Weise.
Die Quell-FPS der Kamera entspricht nicht unbedingt der Erkennungs-FPS. Ein Aufzeichnungsstream mit 25 FPS kann einen Erkennungsstream mit fünf FPS speisen und so den Inferenzbedarf reduzieren, ohne die flüssige Aufzeichnung von Bewegungen zu beeinträchtigen. Eine Verwechslung der beiden Werte führt zu überhöhten oder unsicheren Kapazitätsschätzungen.
Dekodierung und Vorverarbeitung können zum früheren Engpass werden
Vor der Inferenz muss komprimiertes Video dekodiert, skaliert, in den richtigen Farbraum umgewandelt und an den Detektor übertragen werden. Hardwaredekodierung kann die CPU entlasten, doch Codec, Auflösung, Farbtiefe und die Begrenzung gleichzeitiger Sitzungen sind entscheidend. Aufzeichnungen und Transkodierung für die Live-Ansicht konkurrieren um dieselbe Pipeline.
Eine Übersicht über KI-Beschleuniger erklärt, dass Beschleuniger wiederholte Inferenzen mit geringerem Host-Overhead schneller als allgemeine CPUs ausführen können. Die Dekodierung muss die Bilder dennoch rechtzeitig liefern.
Ein schneller Detektor garantiert daher nicht automatisch mehr Kameras. Wenn die Bildwarteschlange vor der Inferenz wächst, bleibt zusätzliche Detektorkapazität ungenutzt. Wenn der Speicher blockiert, kann die Aufzeichnung beeinträchtigt werden, selbst wenn die Erkennungs-FPS korrekt aussieht.
Wo die Teilungsformel versagt
Die Division von Detektor-FPS durch die FPS pro Kamera setzt gleiche Modellkosten und unabhängige Bilder voraus. Zusätzliche Modelle für Gesichter, Kennzeichen, Posen oder Klassifizierung verursachen nur bei ausgewählten Erkennungen weiteren Aufwand. Kacheln mit variabler Auflösung und Remote-Streams können ungleichmäßige Kosten verursachen.
Eine Produkterklärung zur sekundären Erkennung weist darauf hin, dass sekundäre Erkennung die Pipeline verlangsamen kann, wenn Aufgaben erkannte Objekte nicht effizient gemeinsam nutzen. Die Auswahl der Merkmale verändert die Kapazität selbst bei gleicher Basis-FPS.
Die Schätzung versagt außerdem, wenn nicht der Durchsatz, sondern die Latenz das Limit darstellt. Ein Detektor kann durchschnittlich 60 FPS erreichen und dennoch eine Kamera gelegentlich um mehrere Sekunden verzögern, weil Warteschlangen nicht fair behandelt werden. Gleiche Durchschnittsraten garantieren keine gleichmäßige Reaktionsfähigkeit für jeden Stream.
Streams hinzufügen, bis die langsamste Kamera nachlässt
Aktiviere die Kameras nacheinander mit ihrem endgültigen Codec, ihrer Auflösung, ihrem Aufzeichnungsmodus und ihrer Erkennungs-FPS. Löse in allen Ansichten gleichzeitig Bewegungen aus und erfasse die erreichte Erkennungs-FPS pro Kamera, das Alter der Bildwarteschlange, die Inferenzzeit, die Dekodierungsauslastung, verworfene Bilder, die Ereignisverzögerung und die Festplattenlatenz.
Führe den Test auf derselben Konfiguration des gemeinsam genutzten Video-Computers durch, auf dem Video- und KI-Dienste gemeinsam ausgeführt werden sollen. Deaktiviere unabhängige Aufgaben nur, wenn sie auch im Produktivbetrieb entsprechend eingeplant werden.
Behalte die höchste Kamerazahl bei, bei der der langsamste Stream mindestens 95 Prozent seiner konfigurierten Erkennungsrate beibehält und die p95-Ereignisverzögerung innerhalb des gewählten Zielwerts bleibt. Halte 20 Prozent Reserve bei der Detektor- und Dekodierungskapazität für gleichzeitige Bewegungen und sekundäre Modelle vor.
Tech- & KI-Zentrum
Mehr zum Lesen

So messen Sie die lokale RAG-Abrufqualität und interpretieren Recall, Precision und Zitatabdeckung
Erstellen Sie einen lokalen RAG-Testsatz, berechnen Sie zentrale Retrieval-Metriken, interpretieren Sie deren Zielkonflikte und prüfen Sie, ob die Antwortaussagen durch die zitierten Belege gestützt...

Warum wird die Berechnung von Smart-Home-Funktionen bei gleicher Abtastrate wichtiger, je mehr Sensoren vorhanden sind?
Verfolge die Berechnungen pro Sensor und über mehrere Sensoren hinweg, während die Anzahl der Geräte steigt, ermittle nichtlineare Fusionskosten und benchmarke die Feature-Pipeline, bevor...

Warum werden die Kosten der RAG-Evaluierung bei gleichbleibender Abfragezahl wichtiger, je größer die Dokumentbibliothek wird?
Verstehen Sie, warum das Wachstum des Korpus den Bewertungsaufwand für RAG ohne zusätzliche Nutzeranfragen erhöht und wie geschichtete Tests die Kosten an das Risiko...

