Mange innebygde enheter, inkludert roboter, smartkameraer og industrielle visjonsterminaler, bruker nå NPU-er til å kjøre AI-visjonsalgoritmer. En NPU er en maskinvareenhet i en brikke dedikert til AI-inferens.
Når de velger en brikke, ser mange team først på dens NPU TOPS-vurdering og antar at et høyere tall betyr en kraftigere brikke. I praksis støter produktutvikling på to typiske problemer:
Det første er utilstrekkelig datakapasitet. Enheten kjører med lav bildefrekvens, videoen hakker, bilder tapes når flere kameraer opererer samtidig, og AI-gjenkjenning kan mislykkes.
Det andre er for stor kapasitet. Brikken er dyr, bruker mer strøm og genererer betydelig varme. Ubrukt datakapasitet reduserer profittmarginene.
En viktig teknisk vurdering er at ytelsen i mange innebygde visjonsprosjekter er begrenset av bildeoverføringer, minnebåndbredde eller CPU-basert nedstrømsprosessering snarere enn NPU-beregningskapasitet.
Beregningsplanlegging krever ikke en lang liste med tekniske termer. Å skille mellom to nøkkelbegreper bidrar til å forhindre at brikkespesifikasjoner blir misvisende.
TOPS-tallet som annonseres av chipleverandører er teoretisk topp beregningsytelse: den maksimale prosesseringskapasiteten en NPU kan oppnå ved full belastning under ideelle laboratorieforhold. Produktdesign trenger takhøyde, så topp ytelse kan ikke brukes direkte til dimensjonering.
Vi bruker GMAC til å vurdere beregningsarbeidsmengden til en AI-modell. En MAC er en grunnleggende multipliserbar akkumuleringsoperasjon, og GMAC representerer én milliard slike operasjoner. Den måler beregningsmengden i en modell. Merk at GMAC måler arbeidsmengde, mens GMAC/s måler gjennomstrømning. Større modeller har høyere GMAC-verdier.
NPU-utnyttelse er ikke en fast konstant. Den representerer andelen av NPU-kapasiteten som brukes til effektiv beregning. For enkle konvolusjonelle nettverk, som VIO-grensesnitt eller lette deteksjonsmodeller, kan enkle operatorer og grundig chipoptimalisering gi en utnyttelse på 60–80 %. Modeller som inneholder komplekse transformasjoner eller transformatorblokker kan kreve gjentatt flislagt utførelse, noe som reduserer utnyttelsen til 20 % eller enda mindre.
Å bruke en fast utnyttelsesgrad på 40 % er en viktig årsak til unøyaktige estimater. Oppløsning påvirker også arbeidsmengden direkte: dobling av både bredden og høyden på inndatabildet firedobler arealet og omtrent firedobler beregningen for samme modell.
TOPS er bare maskinvaretaket. Start beregningsestimatene med modellens GMAC-arbeidsmengde, og kalibrer dem mot målinger på et utviklingskort. Ikke velg en brikke utelukkende basert på dens teoretiske toppytelse.
Før du estimerer beregningskrav, kartlegg produktets arbeidsmengde. Den kritiske forskjellen er om flere kameraer bruker parallell inferens eller tidsdelt, round-robin-inferens, fordi dette avgjør hvordan beregningskravene deres kombineres.
Parallellmodus: Alle kameraer kjører AI-inferens samtidig, slik at beregningskravene deres legges til direkte. For eksempel kombinerer en sikkerhetsenhet med fire kameraer som utfører objektdeteksjon i sanntid med 30 bilder per sekund på hver kanal belastningen fra alle fire kanalene.
Tidsdelt modus: NPU-en er en delt maskinvareressurs som behandler kamerabilder sekvensielt, og håndterer én kanal om gangen etter hvert som kanalene bytter på å stå i kø. Mange implementeringer av flerkameravisjon på Rockchip RK-plattformer bruker denne tilnærmingen.
Samle inn følgende informasjon når du definerer arbeidsmengden:
Oppløsning og bildefrekvens for hvert kamera.
AI-modelllisten: hvilke modeller som kjører på NPU-en og hvilke etterbehandlingsoppgaver som kjører på CPU-en.
Kvantiseringspresisjon: INT8 er et vanlig valg for innebygde enheter på grunn av dens høyere inferenseffektivitet.
Utløsermetode: kontinuerlig AI-prosessering på hver ramme, eller hendelsesutløst operasjon der komplekse algoritmer bare starter når en utløserbetingelse er oppfylt.
Viktig: Eksporter GMAC-modellen ved hjelp av verktøy som RKNN eller ONNX Runtime i stedet for å estimere den basert på erfaring. Å bruke arbeidsmengden til en stor YOLO-modell til å dimensjonere et lett VIO-nettverk kan overvurdere beregningskravene betraktelig.
Vår MV11 er en maskinvaresynkronisert visjons- og treghetsnavigasjonsplattform med fire kameraer, basert på den høytytende Rockchip RK3576-prosessoren. Den inkluderer en 6 TOPS NPU og 4 GB LPDDR4-minne, og støtter synkronisering på mikrosekundnivå på tvers av fire kameraer. Egnede applikasjoner inkluderer robotgjenkjenning og -deteksjon, VIO-, SLAM- og flerkamera-EGO-datainnsamling. Den kan fungere som maskinvareplattform for beregning på kortnivå, båndbredde og flerkanalsplanleggingstester beskrevet ovenfor. Prøver er tilgjengelige for tidlig prosjektevaluering, og komplette visjonsløsninger kan tilpasses for å støtte utrulling. Kontakt oss på [email protected].
Mange prosjekter fokuserer kun på NPU TOPS under valg, og oppdager deretter under board-oppstart at systemet ikke kan holde tritt selv om mer enn halvparten av NPU-kapasiteten fortsatt er tilgjengelig. Følgende begrensninger er vanlige flaskehalser i innebygd visjon.
Under AI-inferens leser NPU-en kontinuerlig bilder og modellvekter fra minnet og skriver mellomliggende funksjonskart tilbake til minnet. DDR-båndbredde bestemmer hastigheten på disse overføringene. Når båndbredden er utilstrekkelig, må selv en NPU med tilstrekkelig beregningskapasitet vente på data, noe som forhindrer forbedringer av bildefrekvensen. I de fleste flerkameraprosjekter på RK-plattformer blir båndbredden mettet mens bare en liten del av NPU-kapasiteten brukes.
Bildebuffere, vekter av AI-modeller og mellomliggende funksjonskart bruker alle minne. Minnebruken øker betydelig når flere kanaler opererer samtidig. Utilstrekkelig minne kan føre til at applikasjonen krasjer. Innebygde enheter mangler vanligvis virtuelt minne, så en tilstand med lite minne (OOM) kan føre til at enheten stopper.
Råbilder tatt av kameraer krever beskjæring, skalering og fargeromkonvertering. Noe forbehandling utføres av internettleverandørens maskinvare, mens noe bruker CPU-ressurser. Flerkameraopptak øker forbehandlingsbehovet og kan føre til forsinkelse i hele prosessen selv når NPU-en er inaktiv.
En brikkes annonserte topp-TOPS tilsvarer toppstrømforbruk. De fleste innebygde enheter er vifteløse og kan ikke tåle full NPU-belastning over lange perioder. Selv når den teoretiske datakapasiteten er høy, begrenser termiske forhold kapasiteten som er tilgjengelig for vedvarende drift.
Hvis en AI-modell inneholder spesielle operatorer som NPU-en ikke kan akselerere, faller de tilbake til CPU-kjøring. AI-prosessering på CPU-en er treg og kan alvorlig stoppe pipelinen selv når NPU-kapasiteten er tilstrekkelig. Bekreft støtte for operatørakselerasjon før du velger plattform.
1. Etabler arbeidsmengdegrunnlinjen og driftsmodusen. Definer AI-pipelinen: oppløsning, bildefrekvens, antall kanaler, triggerstrategi (kontinuerlig eller hendelsesdrevet), parallell eller tidsdelt utførelse, modellliste og presisjon for distribusjon. Vær spesielt oppmerksom på hvordan flere kanaler er planlagt.
2. Kvantifiser modellarbeidsbelastninger og eksporter GMAC/-er. Bruk verktøy til å eksportere GMAC/-er for hver modell, og separer NPU-akselerert beregning fra CPU-etterbehandling.
3. Mål på målkortet for å bestemme utførelseseffektiviteten. Konverter modeller til plattformformatet på kandidat-SoC-er som RK3576 eller RK3588. Mål inferenstid per ramme for å bestemme den faktiske gjennomstrømningen til den modellen på den NPU-en. Dette er det viktigste trinnet for å eliminere avvik i papirestimater: alle estimater må kalibreres mot målinger på kortnivå i stedet for generiske formler.
4. Samle arbeidsbelastninger på flere kanaler og vurder flaskehalser i systemet. Evaluer både normal drift i stabil tilstand og verst tenkelige toppscenarier når alle kanaler utløses samtidig. Sjekk DDR-båndbredde og minnebruk samtidig. Mange RK-flerkameraprosjekter bruker opp båndbredden mens beregningskapasiteten fortsatt er tilgjengelig.
5. Reserver passende kapasitet og sett grenser. Bruk en margin på 1,1–1,2 for kortsiktige produkter med stort sett faste algoritmer, og 1,3–1,4 for produkter som forventes å motta modelloppdateringer. Kapasiteten bør dekke modellutvikling, toppscenarioer og planleggingskostnader i stedet for vilkårlig overprovisjonering. Sett stykklistekostnad og effektgrenser samtidig.
6.1 Bruk av kun Chip TOPS og en fast utnyttelsesgrad
Å bruke en fast utnyttelsesgrad på 40 % på den annonserte TOPS-en kan overvurdere beregningskravene på flere måter og avvike betydelig fra reelle tekniske forhold. Utnyttelsen varierer betydelig på tvers av modeller og NPU-arkitekturer.
6.2 Multiplikasjon med kanalantall og ignorering av tidsdeling
I tidsdelt drift behandler NPU-en kanaler etter tur, og beregningskapasiteten gjenbrukes. Å bare multiplisere kanalantallet med enkeltkanals beregningsbehov kan overvurdere kravene kraftig, noe som resulterer i en overdrevet og unødvendig kostbar brikke.
6.3 Vurdering av NPU-beregning, men ignorering av DDR-båndbredde
Båndbreddeflaskehalser er mye vanligere enn beregningsflaskehalser i flerkameraprosjekter. NPU-en kan ha betydelig gjenværende kapasitet, men dataoverføringer kan ikke holde tritt, noe som begrenser bildefrekvensen. Båndbredde må vurderes først i flerkameraprosjekter.
6.4 Gjennomsnittlig belastning i betraktning, men ignorering av forbigående topper
Et produkt kan operere med lav belastning mesteparten av tiden, men oppleve forbigående topper når alle kameraer utløser AI samtidig. Designet må håndtere disse toppene, men en oppgavekø kan jevne ut forbigående behov, slik at brikken ikke nødvendigvis trenger å dimensjoneres direkte til topp beregningsbehov.
6.5 Kun telling av modellberegning og ignorering av systemoverhead
Mange estimater teller bare med AI-ryggradens GMAC og ignorerer ISP-forbehandling, bildekopiering og CPU-etterbehandling. Selv med tilstrekkelig NPU-kapasitet øker disse overheadkostnadene ende-til-ende-forsinkelsen og forhindrer at forventet bildefrekvens oppnås.
List opp alle kameraparametere: oppløsning, bildefrekvens og antall kanaler. Bekreft om kanalene bruker parallell eller tidsdelt planlegging.
Eksporter GMAC for hver modell og skill NPU-beregning fra CPU-etterbehandling.
Mål inferenstid for enkeltmodeller på kandidatplattformer for å fastslå faktisk utførelseseffektivitet.
Aggreger flerkanals arbeidsbelastninger og vurder NPU-beregningsutnyttelsen under stabile og toppforhold.
Mål DDR-båndbredde og minnebruk for å avgjøre om båndbredden er flaskehalsen.
Valider modelloperatorer og bekreft støtte for NPU-maskinvareakselerasjon for å unngå CPU-reserve.
Reserver beregningskapasitet i henhold til produktoppdateringens veikart og angi kostnads- og strømgrenser for stykkliste.
Kjør utvidede stresstester med samtidige flerkanalsutløsere. Sjekk variasjon i bildefrekvens og krasj forårsaket av minneutmattelse.
Dimensjonering av NPU-kapasitet for innebygd visjon er ikke en enkel matematisk øvelse når man bruker en TOPS-formel. Papirestimater gir bare en tidlig planleggingsreferanse. Endelig validering må utføres på målbrikkens utviklingskort.
En fullstendig vurdering følger denne sekvensen: avgjør om beregning er flaskehalsen → bekreft parallell eller tidsdelt planlegging → mål GMAC-modellen → prioriter DDR-båndbreddevurdering → kalibrer gjennom testing på kortnivå → reserver passende beregningskapasitet.
Målet er å balansere ytelse, strømforbruk og kostnader. Velg tilstrekkelig kapasitet for oppgaven i stedet for å satse på stadig høyere topp-NPU-TOPS.
Vår MV11 er en maskinvaresynkronisert visjons- og treghetsnavigasjonsplattform med fire kameraer, basert på den høytytende Rockchip RK3576-prosessoren. Den inkluderer en 6 TOPS NPU og 4 GB LPDDR4-minne, og støtter synkronisering på mikrosekundnivå på tvers av fire kameraer. Egnede applikasjoner inkluderer robotgjenkjenning og -deteksjon, VIO-, SLAM- og flerkamera-EGO-datainnsamling. Den kan fungere som maskinvareplattform for beregning på kortnivå, båndbredde og flerkanalsplanleggingstester beskrevet ovenfor. Prøver er tilgjengelige for tidlig prosjektevaluering, og komplette visjonsløsninger kan tilpasses for å støtte utrulling. Kontakt oss på [email protected].
Siste nytt2026-10-24
2026-10-23
2026-10-20
2026-10-19
2026-10-16
2026-10-12
EN
