Hoeveel camerastreams kan een thuis-NVR analyseren bij dezelfde detectiesnelheid?
Een thuis-NVR kan slechts zoveel streams analyseren als de detector en videopijplijn aankunnen zonder de geconfigureerde detectiesnelheid van elke camera te verlagen.
Als acht camera’s elk vijf detectiebeelden per seconde aanvragen, moet de detector na aftrek van overhead minstens 40 inferenties per seconde aankunnen. Decoderen, schalen, volgen, opnemen en bewegingsfiltering verbruiken echter ook CPU, GPU, geheugenbandbreedte en I/O. De werkelijke streamlimiet wordt bereikt wanneer de detectiefrequentie per camera of de gebeurtenislatentie begint af te nemen tijdens gelijktijdige activiteit in huis.
De detectievraag is het aantal streams vermenigvuldigd met de detectie-FPS
De eenvoudigste ondergrens is het aantal camera’s vermenigvuldigd met het geconfigureerde aantal detectiebeelden per seconde. Tien camera’s met vijf FPS vragen 50 geanalyseerde beelden per seconde. Bewegingsfiltering kan de werkelijke werklast verlagen, maar bij capaciteitsplanning moet je rekening houden met perioden waarin veel camera’s tegelijk actief zijn.
Het project voor lokale objectdetectie scheidt lokale opname van realtime objectdetectie en raadt speciale versnelling aan in plaats van detectie die uitsluitend op de CPU draait. Die onderdelen belasten dezelfde server op verschillende manieren.
De bron-FPS van de camera is niet noodzakelijk gelijk aan de detectie-FPS. Een opnamestream van 25 FPS kan een detectiestream van vijf FPS voeden, waardoor de inferentievraag afneemt zonder de vloeiendheid van opgenomen bewegingen te verminderen. Als je die twee door elkaar haalt, worden capaciteitsramingen verspild of onveilig.
Decoderen en voorbewerken kunnen eerder de bottleneck worden
Voor inferentie moet gecomprimeerde video worden gedecodeerd, geschaald, van kleurindeling worden omgezet en naar de detector worden gekopieerd. Hardwaredecodering kan de CPU ontlasten, maar codec, resolutie, bitdiepte en limieten voor gelijktijdige sessies zijn van belang. Opnames wegschrijven en liveweergave transcoderen concurreren om dezelfde pijplijn.
Een overzicht van AI-versnellers legt uit dat versnellers bij herhaalde inferentie beter kunnen presteren dan algemene CPU’s, met minder overhead op de host. Decodering moet de beelden nog steeds op tijd aanleveren.
Een snelle detector garandeert daarom niet dat je meer camera’s kunt gebruiken. Als de beeldwachtrij vóór de inferentie groeit, blijft extra detectiecapaciteit ongebruikt. Als opslag blokkeert, kan de opname daaronder lijden, zelfs wanneer de detectie-FPS correct lijkt.
Waar de deel-formule tekortschiet
Deel de detector-FPS door de FPS per camera veronderstelt gelijke modelkosten en onafhankelijke beelden. Secundaire modellen voor gezichten, kentekens, poses of classificatie voegen alleen werk toe aan geselecteerde detecties. Tegels met variabele resolutie en externe streams kunnen ongelijke werklasten veroorzaken.
Een productuitleg over secundaire herkenning merkt op dat secundaire herkenning de pijplijn kan vertragen, tenzij taken detecties efficiënt delen. Functieselectie verandert de capaciteit, zelfs bij dezelfde basis-FPS.
De schatting faalt ook wanneer latentie, en niet doorvoer, de beperkende factor is. Een detector kan gemiddeld 60 FPS halen, maar een camera soms seconden vertragen doordat wachtrijen niet eerlijk worden afgehandeld. Gelijke gemiddelde snelheden garanderen geen gelijke responsiviteit per stream.
Verhoog het aantal streams totdat de traagste camera achteruitgaat
Schakel camera’s één voor één in met hun uiteindelijke codec, resolutie, opnamemodus en detectie-FPS. Activeer gelijktijdige beweging in alle beelden en registreer per camera de behaalde detectie-FPS, de ouderdom van de beeldwachtrij, inferentietijd, decodegebruik, verloren beelden, gebeurtenisvertraging en schijflatentie.
Voer de test uit op dezelfde configuratie van de gedeelde videocomputer die video- en AI-diensten zal delen. Schakel niet-gerelateerde taken alleen uit als ze in productie ook niet gelijktijdig worden gepland.
Houd het hoogste aantal camera’s aan waarbij de traagste stream minstens 95 procent van zijn geconfigureerde detectiesnelheid behoudt en de p95-gebeurtenisvertraging binnen de gekozen doelwaarde blijft. Reserveer 20 procent detector- en decodecapaciteit voor gelijktijdige beweging en secundaire modellen.
Aanbevolen producten
Tech & AI HUB
Meer om te lezen
Hoe je de kwaliteit van lokale RAG-opvragingen meet en recall, precisie en citatiedekking interpreteert
Bouw een lokale RAG-testset, bereken de belangrijkste retrievalmetrics, interpreteer de afwegingen ertussen en controleer of beweringen in antwoorden worden ondersteund door aangehaald bewijs.
Waarom wordt computation in smart homes belangrijker naarmate het aantal sensoren toeneemt bij dezelfde bemonsteringsfrequentie?
Houd de berekeningen per sensor en tussen sensoren bij naarmate het aantal apparaten toeneemt, identificeer niet-lineaire fusiekosten en benchmark de functiepijplijn voordat automatiseringen vertraging...
Waarom worden de kosten van RAG-evaluatie belangrijker naarmate de documentbibliotheek groeit bij hetzelfde aantal zoekopdrachten?
Begrijp waarom groei van het corpus de evaluatie-inspanning voor RAG verhoogt zonder meer gebruikersvragen, en hoe gestratificeerde tests de kosten aan het risico koppelen.
