En NVR-enhet för hemmet kan analysera lika många strömmar som detektorn och videopipelinen klarar utan att minska den konfigurerade detektionsfrekvensen för varje kamera.
Om åtta kameror vardera begär fem detektionsbilder per sekund måste detektorn klara minst 40 inferenser per sekund efter overhead. Men avkodning, skalning, spårning, inspelning och rörelsefiltrering använder också CPU, GPU, minnesbandbredd och I/O. Den verkliga strömgränsen nås när detektionsfrekvensen per kamera eller händelselatensen börjar försämras vid samtidig aktivitet i hemmet.
Detektionsbehovet är antalet strömmar multiplicerat med detektions-FPS
Den enklaste uppskattningen är antalet kameror multiplicerat med den konfigurerade detektionsfrekvensen. Tio kameror med fem FPS begär 50 analyserade bilder per sekund. Rörelsefiltrering kan minska det faktiska arbetet, men kapacitetsplaneringen bör omfatta perioder då många kameror är aktiva samtidigt.
Projektet för lokal objektdetektering skiljer lokal inspelning från objektdetektering i realtid och rekommenderar dedikerad acceleration framför detektering som enbart använder CPU. Dessa arbetsflöden belastar samma server på olika sätt.
Källans FPS är inte nödvändigtvis detsamma som detektions-FPS. En inspelningsström på 25 FPS kan mata en detektionsström på fem FPS, vilket minskar inferensbehovet utan att den inspelade rörelsens jämnhet försämras. Om man blandar ihop dem blir kapacitetsuppskattningarna antingen onödigt stora eller osäkra.
Avkodning och förbehandling kan bli den första flaskhalsen
Före inferensen måste komprimerad video avkodas, skalas, färgkonverteras och kopieras till detektorn. Hårdvaruavkodning kan avlasta CPU:n, men codec, upplösning, färgdjup och begränsningar för samtidiga sessioner spelar roll. Inspelning och transkodning för livevisning konkurrerar om samma pipeline.
En översikt över AI-acceleratorer förklarar att acceleratorer kan överträffa generella CPU:er vid upprepad inferens, med lägre belastning på värdsystemet. Avkodningen måste fortfarande leverera bilder i tid.
En snabb detektor garanterar därför inte fler kameror. Om bildkön växer före inferensen förblir extra detektorkapacitet outnyttjad. Om lagringen blockerar kan inspelningen påverkas även när detektions-FPS ser korrekt ut.
När divisionsformeln inte fungerar
Detektorns FPS dividerat med FPS per kamera förutsätter samma modellkostnad och oberoende bilder. Sekundära modeller för ansikten, registreringsskyltar, poser eller klassificering lägger bara till arbete för utvalda detektioner. Tiling med varierande upplösning och fjärrströmmar kan skapa ojämna kostnader.
En produktförklaring av sekundär igenkänning påpekar att sekundär igenkänning kan göra pipelinen långsammare om uppgifterna inte delar detektioner effektivt. Funktionsurvalet påverkar kapaciteten även vid samma grundläggande FPS.
Uppskattningen fallerar också när latensen, inte genomströmningen, är begränsningen. En detektor kan i genomsnitt klara 60 FPS men ibland fördröja en kamera i flera sekunder på grund av orättvis köhantering. Samma genomsnittliga frekvens garanterar inte samma respons per ström.
Öka antalet strömmar tills den långsammaste kameran börjar tappa
Aktivera kamerorna en i taget med deras slutliga codec, upplösning, inspelningsläge och detektions-FPS. Utlös samtidig rörelse i alla vyer och registrera uppnådd detektions-FPS per kamera, bildköernas ålder, inferenstid, avkodningsutnyttjande, tappade bilder, händelsefördröjning och disklatens.
Kör testet på samma konfiguration av delad videoberäkningsvärd som ska dela video- och AI-tjänsterna. Inaktivera orelaterade jobb endast om de också kommer att schemaläggas bort i produktion.
Behåll det högsta antalet kameror där den långsammaste strömmen fortfarande når minst 95 procent av sin konfigurerade detektionsfrekvens och där den 95:e percentilen för händelsefördröjningen ligger inom det valda målet. Reservera 20 procent detektor- och avkodningsmarginal för samtidig rörelse och sekundära modeller.
Teknik- och AI-hubb
Mer att läsa

Så mäter du kvaliteten på lokal RAG-hämtning och tolkar återkallning, precision och källhänvisningstäckning
Bygg ett lokalt RAG-testset, beräkna centrala återhämtningsmått, tolka deras avvägningar och granska om svarens påståenden stöds av citerade belägg.

Varför blir beräkning av smarta hem-funktioner viktigare när antalet sensorer ökar vid samma samplingsfrekvens?
Spåra beräkningar per sensor och mellan sensorer när antalet enheter ökar, identifiera icke-linjära kostnader för fusion och benchmarka funktionspipelinen innan automatiseringarna börjar släpa efter.

Varför blir kostnaden för RAG-utvärdering viktigare när dokumentbiblioteket växer trots samma frågevolym?
Förstå varför en växande korpus ökar utvärderingsarbetet för RAG utan fler användarfrågor och hur stratifierade tester håller kostnaden kopplad till risken.

