Hvordan RK3588 NPU programvarestabel passer sammen
Rockchips RKNN programvarestabel skiller modellforberedelse fra kjøring på enheten. RKNN-Toolkit2 gir konverterings- og evalueringsverktøy. RKNN-Toolkit-Lite2 leverer et Python-grensesnitt på støttede målplattformer, mens RKNN Runtime leverer C/C++-grensesnitt. Kjernedriveren kobler kjøretiden til NPU. Sjekk kompatibiliteten til disse komponentene med kortstøttepakken som følger med modulen din.
En nyttig distribusjonspost identifiserer kortet og SoM-revisjonen, Linux-bildet, driveren, kjøretiden, versjonen av konverteringsverktøyet, originalmodellen og konvertert modell. Lagre byggeskriptet og forhåndsbehandlingsinnstillingene ved siden av modellartefakten. Et filnavn som f.eks detector.rknn alene kan ikke forklare hvorfor en distribusjon oppfører seg annerledes enn en annen.
Trinn 1: etablere en referanse før konvertering
Kjør den originale modellen på et representativt valideringssett. Lagre rå utdata og applikasjonsberegningen som betyr noe: klassifiseringsnøyaktighet, deteksjonskvalitet eller et annet oppgavespesifikk mål. For en detektor, bevar etikettbestilling, konfidensgrenser og etterbehandlingsinnstillinger. Dette blir sammenligningspunktet for den konverterte modellen.
Skriv ned hele innspillskontrakten. Inkluder dimensjoner, batchstørrelse, RGB- eller BGR-bestilling, layout, numerisk område, normalisering, endring av størrelse og polstring. En riktig modell kan gi dårlige resultater hvis applikasjonen postbokser et bilde annerledes enn trening eller trekker fra en offset to ganger. Hold etterbehandling utenfor nettverket dokumentert like nøye.
Bruk Rockchip RKNN Model Zoo som et utgangspunkt når den inkluderer en matchende modell og mål. Konverterings- og slutningseksemplene er mer nyttige enn å anta at ethvert eksportert nettverk vil fungere uendret. Velg en kjent repository-revisjon og følg instruksjonene for det spesifikke eksemplet.
Trinn 2: konverter modellen og sjekk operatørstøtte
- Match målet. Velg RK3588-målet og en verktøykjede som er kompatibel med det tiltenkte tavlebildet.
- Inspiser grafen. Bekreft former, forbehandling, utdata og støtte for de faktiske operasjonene i den eksporterte modellen.
- Bygg en referansekonvertering. Bruk presisjonsalternativene som støttes av den grafen og programvareversjonen.
- Les hele byggeloggen. Løs feil og undersøk advarsler før du legger til kameraanskaffelse eller et brukergrensesnitt.
- Sammenlign utganger. Kjør de samme inngangene gjennom de originale og konverterte modellene, med samme etterbehandling.
En operasjon som ikke støttes kan kreve en annen eksport, omskriving av grafer eller et eksplisitt prosesseringstrinn. Ikke anta at kjøretiden vil kjøre alle lag som ikke støttes. Hvis en del av arbeidsbelastningen flyttes til CPU, inkluderer overføringer og synkronisering i ytelsesmålingen.
Trinn 3: evaluer INT8 mot nøyaktighetskravet ditt
Kvantisering endrer numerisk representasjon. Når den valgte konverteringsflyten bruker kalibreringsdata, velg innganger som er representative for distribusjonen: belysning, objektstørrelse, bakgrunn og driftsforhold. Behold et eget valideringssett for å evaluere resultatet. En konvertering som fullføres, trenger fortsatt en nøyaktighetssjekk.
Sammenlign applikasjonsutgangen, ikke bare forskjellen mellom to tensorer. For eksempel kan en liten numerisk endring flytte en deteksjon over en konfidensgrense. Inspiser vanskelige tilfeller, klasser med få eksempler og forhold der den opprinnelige modellen allerede var marginal. Hvis nøyaktigheten faller under akseptgrensen, gå tilbake til kalibreringsdekning og forbehandling før du endrer maskinvaren.
Den ONNX Kjøretidskvantiseringsdokumentasjon er nyttig bakgrunn om numeriske avveininger og nøyaktighetsundersøkelser. RKNN konverteringsalternativer og støttet presisjon må fortsatt sjekkes i Rockchips egen dokumentasjon for den valgte utgivelsen.
Trinn 4: mål mer enn slutningstid
Mål den utplasserte arbeidsmengden etter oppvarming og igjen under en vedvarende løpetur. Registrer temperatur, strømmodus, samtidige prosesser og kapsling eller kjølearrangement. Det nyttige resultatet er en reproduserbar ytelseskonvolutt, inkludert nøyaktighet og forsinkelse, under forholdene som produktet vil fungere under.
| Måling | Hva den svarer | Hva skal registreres |
|---|---|---|
| Modellens utførelsesvarighet | Hvor lang tid tar dette kjøretidsanropet? | Inndataform, presisjon, tidsgrenser og kjøretidsversjon |
| End-to-end latens | Hvor gammel er observasjonen når resultatet leveres? | Registreringstid, forbehandling, køstilling, inferens og utgangstid |
| Vedvarende gjennomstrømning | Hvor mange fullførte resultater leveres over tid? | Kjørelengde, fullførte forespørsler og droppet eller hoppet over inndata |
| Søknadsnøyaktighet | Oppfyller den utplasserte modellen oppgavekravet? | Valideringssett, oppgaveberegning og beslutningsterskler |
| Termisk oppførsel | Er resultatet stabilt etter at systemet varmes opp? | Omgivelsesforhold, kjøling, temperaturer og klokker der dette er tilgjengelig |
Som et illustrativt budsjett må en applikasjon som mottar en ny ramme hver 40 ms holde tritt med 25 bilder per sekund hvis den behandler hver ramme. En 12 ms-inferensmåling ville bare la resten av det budsjettet for anskaffelse, forberedelse og levering i et passende planlagt design. Det beviser ikke en 12 ms kamera-til-resultat-forsinkelse. Disse tallene er et planleggingseksempel, ikke målt ForgeEdge ytelse.
Bruk en monoton klokke for programvarevarighet. Rapporter median- og halelatens i stedet for en enkelt beste observasjon, og bevar de rå målingene. For flere kameraer, ta hensyn til arbeidsmengden til alle aktive strømmer, inkludert dekoding, bildekonvertering, minnebevegelse og opptak. En kø som vokser gjennom testen indikerer at gjennomsnittlig kapasitet er under den innkommende arbeidsbelastningen.
Vanlige utplasseringssymptomer
| Symptom | Første etterforskning |
|---|---|
| Riktig modell, feil etiketter eller bokser | Fargerekkefølge, normalisering, endre størrelse/polstring, utdatalayout og etterbehandling |
| Konvertert modell kan ikke initialiseres | Målvalg, kjøretid/driverkompatibilitet og modellartefaktintegritet |
| God kort benchmark, dårlig vedvarende ytelse | Temperatur, strømmodus, minnetrykk og konkurrerende arbeid |
| Akseptabel slutningstid, synlig forsinkede resultater | Fange buffering, køalder, kopier og utdataplanlegging |
| INT8-utgang mister nyttige deteksjoner | Kalibreringsdekning, forbehandlingsekvivalens og validering på oppgavenivå |
Gjør prototypen til et repeterbart produkt
Pakk modellen, kjøretiden og applikasjonskonfigurasjonen som en kontrollert utgivelse. Definer oppstartskontroller, feilrapportering, gjenoppretting og en tilbakeføringsbane. Hold en liten referanse-inndatatest som kan identifisere en feil distribusjon før et kamera kobles til. Skille denne programvaresjekken fra den fysiske sensortesten, som også trener kabling, drivere og eksponeringsinnstillinger.
Når brettet trenger forskjellige kontakter, strømkondisjonering eller sensorgrensesnitt, se gjennom SoM versus SBC avgjørelse og den bærekort designprosess. Disse beslutningene bestemmer hvordan en vellykket modelldemonstrasjon blir et vedlikeholdbart system.
RK3588 NPU distribusjonsspørsmål
Kan alle ONNX-modeller kjøre på RK3588 NPU?
Kompatibilitet avhenger av den faktiske grafen, former, operasjoner og valgt verktøykjede. Etabler støtte gjennom konvertering og validering på enheten av modellen du har tenkt å sende.
Forutsier en annonsert akseleratorvurdering applikasjons-FPS?
Nei. Nettverket, presisjonen, minneatferden, forbehandlingen og kjøretiden bestemmer applikasjonens målte gjennomstrømning. Bruk målarbeidsmengden og dens fullstendige databane når du sammenligner plattformer.
Bør jeg optimalisere det nevrale nettverket først?
Profil først. Hvis innhenting, bildekonvertering eller kødannelse dominerer, kan reduksjon av modellutførelsestid ha liten effekt på resultatalderen som applikasjonen opplever.
Benchmark den komplette datasynsoppgaven
For en objektdeteksjonsapplikasjon, mål kamerafangst, endre størrelse og normalisering, NPU-slutning, utdatadekoding og levering av beslutningen. Rapporter modellversjonen, inngangsoppløsningen, presisjonen, konfidensgrensen og evalueringsdatasettet med tidsresultatet. Ellers kan to tilsynelatende like edge AI-benchmarks beskrive forskjellige oppgaver.
Test den eksporterte grafen og nødvendige operatører gjennom den valgte RKNN-verktøykjeden før du forplikter deg til en modellarkitektur. Sjekk nøyaktigheten etter kvantisering og oppførsel under vedvarende utførelse, ikke bare om konverteringen lykkes. Objektdeteksjon, segmentering og klassifisering har forskjellige utdatabehandlingskostnader; validere den faktiske arbeidsmengden som er valgt for prosjektet.
Sammenlign FPGA, NPU og MPU designroller
Tekniske referanser
Omfang din edge AI-arbeidsmengde.
Del modellen, inngangsoppløsningen, kameragrensesnittene, nødvendig resultatfrekvens og kraftomfang. Vi kan vurdere integreringsarbeidet rundt en RK3588-basert edge-plattform.
