Come si integra lo stack software RK3588 NPU
Lo stack software RKNN di Rockchip separa la preparazione del modello dall'esecuzione sul dispositivo. RKNN-Toolkit2 fornisce strumenti di conversione e valutazione. RKNN-Toolkit-Lite2 fornisce un'interfaccia Python sulle piattaforme di destinazione supportate, mentre RKNN Runtime fornisce interfacce C/C++. Il driver del kernel collega il runtime allo NPU. Verifica la compatibilità di questi componenti con il pacchetto supporto scheda fornito per il tuo modulo.
Un utile record di distribuzione identifica la scheda e la revisione SoM, l'immagine Linux, il driver, il runtime, la versione dello strumento di conversione, il modello originale e il modello convertito. Salvare lo script di compilazione e le impostazioni di preelaborazione accanto all'artefatto del modello. Un nome file come detector.rknn da solo non può spiegare perché una distribuzione si comporta diversamente da un'altra.
Passaggio 1: stabilire un riferimento prima della conversione
Eseguire il modello originale su un set di convalida rappresentativo. Salva gli output grezzi e la metrica dell'applicazione che conta: accuratezza della classificazione, qualità del rilevamento o un'altra misura specifica dell'attività. Per un rilevatore, preservare l'ordine delle etichette, le soglie di confidenza e le impostazioni di postelaborazione. Questo diventa il punto di confronto per il modello convertito.
Annotare l'intero contratto di input. Include dimensioni, dimensione batch, ordinamento RGB o BGR, layout, intervallo numerico, normalizzazione, ridimensionamento e riempimento. Un modello corretto può produrre risultati scadenti se l'applicazione inserisce un'immagine in formato letterbox in modo diverso dall'addestramento o sottrae un offset due volte. Mantieni la postelaborazione al di fuori della rete documentata con la stessa attenzione.
Usa Rockchip RKNN Zoo modello come punto di partenza quando include un modello e un obiettivo corrispondenti. I suoi esempi di conversione e inferenza sono più utili che assumere che qualsiasi rete esportata funzionerà invariata. Seleziona una revisione del repository nota e segui le istruzioni per quell'esempio specifico.
Passo 2: convertire il modello e verificare il supporto dell'operatore
- Abbina l'obiettivo. Seleziona il target RK3588 e una toolchain compatibile con l'immagine della scheda prevista.
- Ispeziona il grafico. Conferma forme, preelaborazione, output e supporto per le operazioni effettive nel modello esportato.
- Crea una conversione di riferimento. Utilizza le opzioni di precisione supportate da quella versione del grafico e del software.
- Leggi il registro di compilazione completo. Risolvi gli errori ed esamina gli avvisi prima di aggiungere l'acquisizione della telecamera o un'interfaccia utente.
- Confronta le uscite. Esegui gli stessi input nei modelli originali e convertiti, con la stessa postelaborazione.
Un'operazione non supportata potrebbe richiedere un'esportazione diversa, una riscrittura del grafico o una fase di elaborazione esplicita della CPU. Non dare per scontato che il runtime eseguirà in modo trasparente ogni livello non supportato. Se parte del carico di lavoro si sposta sulla CPU, includere i trasferimenti e la sincronizzazione nella misurazione delle prestazioni.
Passaggio 3: valuta INT8 rispetto ai tuoi requisiti di precisione
La quantizzazione modifica la rappresentazione numerica. Quando il flusso di conversione selezionato utilizza dati di calibrazione, scegli input rappresentativi della distribuzione: illuminazione, dimensione dell'oggetto, sfondo e condizioni operative. Mantenere un set di convalida separato per valutare il risultato. Una conversione completata correttamente necessita ancora di un controllo di accuratezza.
Confronta l'output dell'applicazione, non solo la differenza tra due tensori. Ad esempio, una piccola variazione numerica può spostare un rilevamento oltre una soglia di confidenza. Ispeziona casi difficili, classi con pochi esempi e condizioni in cui il modello originale era già marginale. Se la precisione scende al di sotto del limite di accettazione, rivedere la copertura della calibrazione e la preelaborazione prima di cambiare l'hardware.
Il ONNX Documentazione sulla quantizzazione runtime è un utile background sui compromessi numerici e sull'indagine sull'accuratezza. Le opzioni di conversione RKNN e la precisione supportata devono comunque essere verificate nella documentazione di Rockchip per la versione selezionata.
Passo 4: misurare più del tempo di inferenza
Misura il carico di lavoro distribuito dopo il riscaldamento e di nuovo durante una corsa sostenuta. Registra la temperatura, la modalità di alimentazione, i processi simultanei e l'involucro o la disposizione di raffreddamento. Il risultato utile è un inviluppo prestazionale riproducibile, inclusa precisione e ritardo, nelle condizioni in cui funzionerà il prodotto.
| Misurazione | Cosa risponde | Cosa registrare |
|---|---|---|
| Durata di esecuzione del modello | Quanto tempo richiede questa chiamata di runtime? | Forma dell'input, precisione, limiti temporali e versione runtime |
| Latenza end-to-end | Quanti anni ha l'osservazione al momento della consegna del risultato? | Tempo di acquisizione, preelaborazione, accodamento, inferenza e tempo di output |
| Produttività sostenuta | Quanti risultati completati vengono consegnati nel tempo? | Durata della sequenza, richieste completate e input eliminati o saltati |
| Precisione dell'applicazione | Il modello distribuito soddisfa i requisiti dell'attività? | Set di validazione, metrica delle attività e soglie decisionali |
| Comportamento termico | Il risultato è stabile dopo il riscaldamento del sistema? | Condizioni ambientali, raffreddamento, temperature e orologi ove disponibili |
A titolo illustrativo, un'applicazione che riceve un nuovo frame ogni 40 ms deve tenere il passo con 25 frame al secondo se elabora ogni frame. Una misurazione di inferenza 12 ms lascerebbe il resto del budget per l'acquisizione, la preparazione e la consegna solo in una progettazione opportunamente pianificata. Non dimostra un ritardo 12 ms dalla fotocamera al risultato. Questi numeri sono un esempio di pianificazione, non le prestazioni ForgeEdge misurate.
Utilizzare un orologio monotono per le durate del software. Riporta la latenza mediana e di coda anziché una singola osservazione migliore e preserva le misurazioni grezze. Per diverse telecamere, tenere conto del carico di lavoro di tutti i flussi attivi, inclusa la decodifica, la conversione delle immagini, lo spostamento della memoria e la registrazione. Una coda che cresce durante il test indica che la capacità media è inferiore al carico di lavoro in entrata.
Sintomi comuni di distribuzione
| Sintomo | Prima indagine |
|---|---|
| Modello corretto, etichette o scatole errate | Ordine dei colori, normalizzazione, ridimensionamento/imbottitura, layout di output e postelaborazione |
| Il modello convertito non può essere inizializzato | Selezione del target, compatibilità runtime/driver e integrità degli artefatti del modello |
| Buon benchmark breve, scarsa performance sostenuta | Temperatura, modalità di alimentazione, pressione della memoria e lavoro competitivo |
| Tempo di inferenza accettabile, risultati visibilmente ritardati | Acquisisci buffering, durata della coda, copie e pianificazione dell'output |
| L'uscita INT8 perde rilevamenti utili | Copertura della calibrazione, equivalenza della preelaborazione e convalida a livello di attività |
Trasforma il prototipo in un prodotto ripetibile
Preparare il modello, il runtime e la configurazione dell'applicazione come versione controllata. Definire i controlli di avvio, la segnalazione degli errori, il ripristino e un percorso di rollback. Conservare un piccolo test di input di riferimento in grado di identificare una distribuzione errata prima che venga collegata una telecamera. Separa il controllo del software dal test del sensore fisico, che esamina anche il cablaggio, i driver e le impostazioni di esposizione.
Quando la scheda necessita di connettori, condizionamento dell'alimentazione o interfacce sensore diversi, rivedere il file Decisione SoM contro SBC e il baseboard per un processo di progettazione di moduli di elaborazione. Tali decisioni determinano il modo in cui una dimostrazione di modello di successo diventa un sistema mantenibile.
Domande sulla distribuzione di RK3588 NPU
Ogni modello ONNX può funzionare sullo RK3588 NPU?
La compatibilità dipende dal grafico, dalle forme, dalle operazioni e dalla toolchain selezionata. Stabilisci supporto attraverso la conversione e la convalida sul dispositivo del modello che intendi spedire.
La valutazione di un acceleratore pubblicizzato prevede gli FPS dell'applicazione?
No. La rete, la precisione, il comportamento della memoria, la preelaborazione e il runtime determinano il throughput misurato dell'applicazione. Utilizza il carico di lavoro di destinazione e il relativo percorso dati completo quando confronti le piattaforme.
Dovrei prima ottimizzare la rete neurale?
Prima il profilo. Se prevalgono l'acquisizione, la conversione delle immagini o l'accodamento, la riduzione del tempo di esecuzione del modello potrebbe avere un effetto minimo sull'età dei risultati riscontrata dall'applicazione.
Riferimenti tecnici
Definisci l'ambito del tuo carico di lavoro Edge AI.
Condividi il modello, la risoluzione di input, le interfacce della fotocamera, la velocità di risultato richiesta e l'inviluppo di potenza. Possiamo valutare il lavoro di integrazione attorno a una piattaforma basata su RK3588 per l'elaborazione locale.