Comment la pile logicielle RK3588 NPU s'articule
La pile logicielle RKNN de Rockchip sépare la préparation du modèle de l'exécution sur l'appareil. RKNN-Toolkit2 fournit des outils de conversion et d'évaluation. RKNN-Toolkit-Lite2 fournit une interface Python sur les plates-formes cibles prises en charge, tandis que RKNN Runtime fournit des interfaces C/C++. Le pilote du noyau connecte le runtime au NPU. Vérifiez la compatibilité de ces composants avec le package de support de carte fourni pour votre module.
Un enregistrement de déploiement utile identifie la révision de la carte et du SoM, l'image Linux, le pilote, le runtime, la version de l'outil de conversion, le modèle original et le modèle converti. Enregistrez le script de génération et les paramètres de prétraitement à côté de l'artefact de modèle. Un nom de fichier tel que detector.rknn ne peut à lui seul expliquer pourquoi un déploiement se comporte différemment d’un autre.
Étape 1 : établir une référence avant la conversion
Exécutez le modèle d'origine sur un ensemble de validation représentatif. Enregistrez les résultats bruts et les mesures d'application importantes : précision de la classification, qualité de la détection ou autre mesure spécifique à une tâche. Pour un détecteur, conservez l’ordre des étiquettes, les seuils de confiance et les paramètres de post-traitement. Cela devient le point de comparaison pour le modèle converti.
Notez l'intégralité du contrat d'entrée. Incluez les dimensions, la taille du lot, l'ordre RVB ou BGR, la disposition, la plage numérique, la normalisation, le redimensionnement et le remplissage. Un modèle correct peut produire de mauvais résultats si l'application met une image en boîte aux lettres différemment de la formation ou soustrait un décalage deux fois. Gardez le post-traitement en dehors du réseau documenté avec autant de soin.
Utilisez Rockchip Zoo modèle RKNN comme point de départ lorsqu'il inclut un modèle et une cible correspondants. Ses exemples de conversion et d'inférence sont plus utiles que de supposer que tout réseau exporté fonctionnera inchangé. Sélectionnez une révision de référentiel connue et suivez les instructions pour cet exemple spécifique.
Étape 2 : convertir le modèle et vérifier le support de l'opérateur
- Faites correspondre la cible. Sélectionnez la cible RK3588 et une chaîne d'outils compatible avec l'image de la carte prévue.
- Inspectez le graphique. Confirmez les formes, le prétraitement, les sorties et la prise en charge des opérations réelles dans le modèle exporté.
- Créez une conversion de référence. Utilisez les options de précision prises en charge par ce graphique et cette version du logiciel.
- Lisez le journal de construction complet. Résolvez les pannes et étudiez les avertissements avant d’ajouter l’acquisition d’une caméra ou une interface utilisateur.
- Comparez les sorties. Exécutez les mêmes entrées dans les modèles d'origine et convertis, avec le même post-traitement.
Une opération non prise en charge peut nécessiter une exportation différente, une réécriture du graphique ou une étape explicite de traitement CPU. Ne présumez pas que le runtime exécutera de manière transparente chaque couche non prise en charge. Si une partie de la charge de travail est transférée vers le processeur, incluez les transferts et la synchronisation dans la mesure des performances.
Étape 3 : évaluez INT8 par rapport à vos exigences de précision
La quantification modifie la représentation numérique. Lorsque le flux de conversion sélectionné utilise des données de calibrage, choisissez des entrées représentatives du déploiement : éclairage, taille de l'objet, arrière-plan et conditions de fonctionnement. Conservez un ensemble de validation distinct pour évaluer le résultat. Une conversion réussie nécessite toujours un contrôle d’exactitude.
Comparez le résultat de l'application, pas seulement la différence entre deux tenseurs. Par exemple, un petit changement numérique peut faire passer une détection au-delà d’un seuil de confiance. Inspectez les cas difficiles, les classes avec peu d’exemples et les conditions où le modèle original était déjà marginal. Si la précision tombe en dessous de la limite d'acceptation, revoyez la couverture d'étalonnage et le prétraitement avant de changer le matériel.
Les Documentation sur la quantification du runtime ONNX constitue une base utile sur les compromis numériques et les recherches de précision. Les options de conversion RKNN et la précision prise en charge doivent toujours être vérifiées dans la propre documentation de Rockchip pour la version sélectionnée.
Étape 4 : mesurer plus que le temps d'inférence
Mesurez la charge de travail déployée après l'échauffement et à nouveau pendant une exécution soutenue. Enregistrez la température, le mode d’alimentation, les processus simultanés et le boîtier ou le système de refroidissement. Le résultat utile est une enveloppe de performances reproductible, incluant la précision et le délai, dans les conditions dans lesquelles le produit fonctionnera.
| Mesure | Ce à quoi il répond | Quoi enregistrer |
|---|---|---|
| Durée d'exécution du modèle | Combien de temps dure cet appel d'exécution ? | Forme d'entrée, précision, limites de synchronisation et version d'exécution |
| Latence de bout en bout | Quel âge a l’observation lorsque le résultat est livré ? | Temps de capture, prétraitement, mise en file d'attente, inférence et temps de sortie |
| Débit soutenu | Combien de résultats finalisés sont livrés au fil du temps ? | Durée d'exécution, requêtes terminées et entrées supprimées ou ignorées |
| Précision des applications | Le modèle déployé répond-il aux exigences de la tâche ? | Ensemble de validation, métrique de tâche et seuils de décision |
| Comportement thermique | Le résultat est-il stable après le réchauffement du système ? | Conditions ambiantes, refroidissement, températures et horloges si disponibles |
À titre indicatif, une application recevant une nouvelle trame toutes les 40 ms doit suivre le rythme de 25 images par seconde si elle traite chaque image. Une mesure d'inférence de 12 ms laisserait le reste de ce budget pour l'acquisition, la préparation et la livraison uniquement dans le cadre d'une conception correctement planifiée. Cela ne prouve pas un délai caméra-résultat de 12 ms. Ces chiffres sont un exemple de planification et non des performances ForgeEdge mesurées.
Utilisez une horloge monotone pour les durées logicielles. Signalez la latence médiane et de queue plutôt qu’une seule meilleure observation et préservez les mesures brutes. Pour plusieurs caméras, prenez en compte la charge de travail de tous les flux actifs, y compris le décodage, la conversion d'images, le mouvement de la mémoire et l'enregistrement. Une file d'attente qui augmente tout au long du test indique que la capacité moyenne est inférieure à la charge de travail entrante.
Symptômes de déploiement courants
| Symptôme | Première enquête |
|---|---|
| Modèle correct, étiquettes ou boîtes incorrectes | Ordre des couleurs, normalisation, redimensionnement/remplissage, disposition de sortie et post-traitement |
| Le modèle converti ne peut pas s'initialiser | Sélection de la cible, compatibilité d'exécution/pilote et intégrité des artefacts du modèle |
| Bon indice de référence court, mauvaise performance soutenue | Température, mode d'alimentation, pression de la mémoire et travail concurrent |
| Temps d'inférence acceptable, résultats visiblement retardés | Mise en mémoire tampon de capture, âge de la file d'attente, copies et planification des sorties |
| La sortie INT8 perd les détections utiles | Couverture de l'étalonnage, équivalence du prétraitement et validation au niveau des tâches |
Transformez le prototype en un produit reproductible
Packagez le modèle, le runtime et la configuration de l'application sous forme de version contrôlée. Définissez les contrôles de démarrage, les rapports d'échec, la récupération et un chemin de restauration. Conservez un petit test d'entrée de référence qui peut identifier un déploiement incorrect avant qu'une caméra ne soit connectée. Séparez cette vérification logicielle du test du capteur physique, qui porte également sur le câblage, les pilotes et les paramètres d'exposition.
Lorsque la carte nécessite différents connecteurs, conditionnement d'alimentation ou interfaces de capteur, consultez les Décision SoM contre SBC et le processus de conception de cartes porteuses. Ces décisions déterminent comment une démonstration de modèle réussie devient un système maintenable.
Questions sur le déploiement du NPU RK3588
Tous les modèles ONNX peuvent-ils fonctionner sur le NPU RK3588 ?
La compatibilité dépend du graphique, des formes, des opérations et de la chaîne d'outils sélectionnée. Établissez un support via la conversion et la validation sur l'appareil du modèle que vous avez l'intention d'expédier.
Une note d'accélérateur annoncée prédit-elle le FPS de l'application ?
Non. Le réseau, la précision, le comportement de la mémoire, le prétraitement et le temps d'exécution déterminent le débit mesuré de l'application. Utilisez la charge de travail cible et son chemin de données complet lorsque vous comparez les plateformes.
Dois-je d’abord optimiser le réseau neuronal ?
Profil d’abord. Si l'acquisition, la conversion d'images ou la mise en file d'attente dominent, la réduction du temps d'exécution du modèle peut avoir peu d'effet sur l'âge des résultats rencontrés par l'application.
Références techniques
Étendez votre charge de travail Edge AI.
Partagez le modèle, la résolution d'entrée, les interfaces de caméra, le taux de résultat requis et l'enveloppe de puissance. Nous pouvons évaluer le travail d'intégration autour d'une plateforme Edge basée sur RK3588.