nndeploy : un orchestrateur de workflows C++ pour l'inférence multi-backend
一款简单易用和高性能的AI部署框架 | An Easy-to-Use and High-Performance AI Deployment Framework
En bref
- De quoi s’agit-il ?
- nndeploy assemble des modèles IA en graphes de nœuds exécutables sur desktop, mobile et edge. Le README promet 13 moteurs d'inférence et plus de 100 nœuds prêts à l'emploi. Voici ce que la documentation permet réellement de vérifier, et où le cadre impose ses contraintes.
- À qui s’adresse-t-il ?
- nndeploy convient aux équipes qui doivent faire tourner un même pipeline sur plusieurs cibles matérielles et qui acceptent de décrire ce pipeline en graphe de nœuds plutôt qu'en Python. Il ne convient pas à un prototype où l'on veut modifier le modèle toutes les semaines, ni à un projet qui n'a qu'une seule cible : le coût d'apprentissage du graphe ne se rentabilise pas.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 31 jours.
- En quel langage est-il écrit ?
- Principalement C++, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Un problème de glue code, pas de performance brute
Le README situe nndeploy comme une réponse au déploiement d'algorithmes IA côté terminal : Windows, macOS, Android, iOS, Jetson, Ascend310B, cartes RK, et serveurs mono-machine avec GPU RTX, T4 ou Ascend310P. Le problème visé n'est donc pas d'écrire un kernel plus rapide, mais d'éviter de réécrire la même chaîne de prétraitement, d'inférence et de post-traitement pour chaque combinaison matériel plus moteur. Le projet cible en priorité les équipes qui ont déjà un modèle exporté et qui doivent le faire tourner sur plusieurs cibles, pas les chercheurs qui entraînent. Le README précise aussi une orientation : pour les modèles de plus de 10B paramètres, comme les LLM et les modèles génératifs, nndeploy est présenté comme un outil de workflow visuel plutôt que comme un moteur d'inférence autonome.
Le graphe de nœuds comme unité de déploiement
L'unité de base est le nœud. On assemble ces nœuds dans un workflow, on règle les paramètres dans l'interface, puis on exporte le tout en JSON. Ce JSON est ensuite rechargé via les API C++ ou Python, ce qui signifie que le graphe visuel et le graphe exécuté en production sont le même artefact. C'est le point d'architecture le plus intéressant du projet : il n'y a pas de génération de code intermédiaire, la topologie reste des données. Le README décrit trois modes d'exécution pris en charge : série, parallélisme pipeline et parallélisme de tâches. Côté mémoire, il cite la copie zéro, les pools mémoire et la réutilisation mémoire. Ces mécanismes sont annoncés, pas documentés en détail dans le matériel fourni : on ne sait pas depuis le README comment le pool est dimensionné ni comment les tampons sont réutilisés entre nœuds. Un nœud peut être écrit en Python pour le prétraitement ou en C++/CUDA pour les parties chaudes, et les deux se branchent dans le même graphe. Le README mentionne également des nœuds internes écrits en Ascend C et en SIMD.
Treize moteurs derrière une même interface
Le tableau du README liste treize backends marqués comme pris en charge : ONNXRuntime, TensorRT, OpenVINO, MNN, TNN, ncnn, CoreML, AscendCL, RKNN, SNPE, TVM, PyTorch, plus un sous-module d'inférence interne à nndeploy. La compilation est sélective : le README indique que l'on peut choisir les moteurs à inclure afin de réduire les dépendances. C'est une décision de conception qui a un coût direct sur la taille du binaire et sur le temps de build, mais qui évite d'embarquer TensorRT sur une cible Android. Le même document mentionne un mode d'exécution isolé permettant de brancher un moteur d'inférence personnalisé. La liste des modèles déjà déployés couvre les LLM (QWen-2.5, QWen-3, avec une mention de prise en charge des petits modèles), la génération d'images et de vidéo (Stable Diffusion 1.5, SDXL, SD3, HunyuanDiT) via diffusers, l'échange de visages avec deep-live-cam, l'OCR Paddle, la détection YOLO de v5 à v11 plus YOLOx, le suivi FairMot, la segmentation (RBMGv1.4, PPMatting, Segment Anything), la classification (ResNet, MobileNet, EfficientNet, PPLcNet, GhostNet, ShuffleNet, SqueezeNet) et l'appel à des services distants (OPENAI, DeepSeek, Moonshot).
Construire et lancer : ce que le README donne réellement
Le README ne fournit pas de séquence de compilation complète dans l'extrait disponible. Il renvoie à la documentation hébergée sur nndeploy-zh.readthedocs.io, à un dépôt de questions-réponses, à un canal Discord et à un fichier docs/zh_cn/knowledge_shared/wechat.md. Les seuls éléments exécutables explicitement cités sont les workflows d'intégration continue, un par plateforme : .github/workflows/linux.yml, windows.yml, android.yml, macos.yml et ios.yml. C'est en pratique le point d'entrée le plus fiable pour reconstituer une chaîne de build, puisque ces fichiers décrivent les dépendances réellement installées par les mainteneurs sur chaque système. Le README mentionne aussi un point d'entrée applicatif mobile dans app/android/README.md. Pour les API d'appel du graphe exporté, le document se contente d'indiquer qu'elles existent en C++ et en Python, sans montrer de signature ni d'exemple de chargement de JSON. Toute personne qui évalue le projet doit donc ouvrir la documentation Read the Docs avant de se faire une idée du temps d'intégration.
Le workflow visuel est un verrou, pas seulement un confort
Le choix d'un graphe éditables visuellement a une contrepartie peu discutée dans le README. Un pipeline décrit en JSON et en nœuds est difficile à versionner finement : une modification de paramètre dans l'interface produit un diff dans un fichier de configuration, pas dans du code relu. Les tests unitaires portent alors sur le graphe entier plutôt que sur une fonction. Autre limite : le README annonce plus de 100 nœuds visuels, mais la maturité de chacun n'est pas homogène. La liste des modèles déployés montre des écarts, par exemple RBMGv1.4 et PPMatting cités sans la mise en avant accordée à Segment Anything. Le projet est aussi explicitement positionné comme inadapté aux modèles de plus de 10B en tant que moteur d'inférence, ce qui exclut les cas où l'on cherche à servir un LLM avec du batching continu et un ordonnancement de requêtes. Sur ce terrain, nndeploy sert de plaque tournante vers un service externe (OPENAI, DeepSeek, Moonshot) plutôt que de serveur d'inférence.
Face à un script Python et à ONNX Runtime
L'alternative la plus directe reste un script Python qui charge un modèle avec onnxruntime et enchaîne les étapes à la main. La différence n'est pas la vitesse d'exécution, c'est la séparation entre topologie et code. Dans un script, changer l'ordre des étapes ou permuter le backend signifie éditer du code et le retester. Avec nndeploy, la topologie vit dans le JSON exporté et le backend est un paramètre de compilation. En contrepartie, un script Python se débogue avec les outils Python habituels, s'intègre dans un notebook et se teste avec pytest ; un graphe C++ exporté demande une autre chaîne d'outils. Le second point de comparaison est un moteur comme ONNX Runtime utilisé seul : il fournit l'exécution d'un graphe ONNX, mais pas la gestion du prétraitement, du post-traitement ni la répartition pipeline sur plusieurs threads. nndeploy se place au-dessus de ce type de moteur, ce qui veut dire que ses performances dépendent de celles du backend choisi et non d'un runtime propre au projet.
Maintenance, licence et coût de mise à jour
Le projet est publié sous Apache-2.0, ce qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions de copyright et du fichier de licence, et une clause de brevets. Rien dans le matériel fourni n'indique de restriction supplémentaire, mais je ne peux pas me prononcer sur les licences des treize moteurs d'inférence intégrés : TensorRT, CoreML, SNPE et AscendCL ont leurs propres conditions, et c'est ce cumul qu'il faut examiner avant une distribution commerciale. Sur le rythme, les trois dernières versions listées sont v3.0.10 et v3.0.9 le 4 avril 2026, puis v3.0.8 le 4 décembre 2025. Le dernier envoi sur la branche main est daté du 15 août 2026, soit environ quatre mois après la dernière publication de version. Cette combinaison suggère un développement actif entre les releases, avec des correctifs qui peuvent rester un moment sur main sans être étiquetés. Pour un utilisateur, cela implique de suivre une balise plutôt que main, faute de quoi la reproductibilité du build dépend d'un commit non publié.
Conclusion éditoriale
nndeploy convient aux équipes qui doivent faire tourner un même pipeline sur plusieurs cibles matérielles et qui acceptent de décrire ce pipeline en graphe de nœuds plutôt qu'en Python. Il ne convient pas à un prototype où l'on veut modifier le modèle toutes les semaines, ni à un projet qui n'a qu'une seule cible : le coût d'apprentissage du graphe ne se rentabilise pas. Avant d'adopter, vérifiez que le moteur d'inférence visé figure bien dans le tableau du README, que la plateforme cible est couverte par les workflows CI listés (linux.yml, windows.yml, android.yml, macos.yml, ios.yml), et surtout que le nœud dont vous dépendez n'est pas marqué comme non implémenté dans la documentation.
Notes de la communauté