# LiteRT Tensor API : authoring de modèles IA embarqués en C++

_Publié le 3 novembre 2026 — https://ip73.fr/2026/11/03/litert-tensor-api-authoring-de-modeles-ia-embarques-en-c/_

L'annonce de Google concernant la LiteRT Tensor API apporte une réponse concrète au problème de la portabilité des modèles d'intelligence artificielle embarqués. Face aux contraintes strictes de latence et de mémoire imposées par les dispositifs finaux, le développement de modèles exigeait jusqu'alors soit une conversion simple, soit une ingénierie manuelle lourde.

L'approche traditionnelle, qui consiste à coder les opérations en C++ pour obtenir un contrôle absolu sur le réseau, se heurte pourtant à une difficulté majeure : chaque nouveau matériel cible – qu'il s'agisse de Metal, d'OpenCL ou de Vulkan – nécessite une réécriture complète de l'implémentation. Sans compter l'effort considérable lié à la gestion de l'interopérabilité des tampons sans copie entre le CPU, le GPU et le NPU.

La LiteRT Tensor API, dévoilée par Google, s'attaque à ce dilemme en servant de couche d'authoring légère au sein de l'architecture LiteRT. Elle autorise désormais la construction du graphe de calcul opérande par opérande en C++, tout en assurant que ce même code fonctionne sur le CPU, le GPU (via ML Drift) ou le NPU, sans nécessiter de modification spécifique pour chaque plateforme. Cette alliance entre flexibilité intrinsèque et capacité de portage étendue représente un atout majeur pour les développeurs.

Ce n'est pas une nouveauté purement théorique. Pour illustrer sa puissance, Google a utilisé un agent de codage pour créer une application interactive de segmentation d'objets, basée sur le modèle Segment Anything Model 2 (SAM 2). Cette application fonctionne entièrement sur l'appareil, directement dans le navigateur grâce à WebGPU. L'intégralité du modèle SAM 2 a été rédigée en C++ via cette nouvelle API, permettant à l'agent d'évoluer la performance de moins de dix à plus de trente images par seconde à 512x512 en WebGPU.

## Le contrôle fin du graphe et la gestion des données

La structure de l'API est conçue pour que les opérations (comme `Add` ou `Softmax`) soient des fonctions sur des valeurs `Tensor`, enregistrant un Graphe Orienté Acyclique (DAG) sans effectuer de calcul immédiat. En définissant ainsi les couches — par exemple, une couche d'auto-attention multi-têtes — en C++, le développeur spécifie comment les poids sont chargés et comment les tenseurs interagissent. Les poids sont chargés directement depuis les *checkpoints*.

L'API permet d'intégrer non seulement le modèle cœur, mais aussi les étapes de pré-traitement et de post-traitement dans le même flux. Grâce à des structures comme `ModelChain` et `LitertBuffer`, les activations peuvent circuler entre les différentes étapes en partageant la mémoire de l'accélérateur, éliminant ainsi les coûteux transferts de données vers le CPU. Cela permet d'éviter que les données ne fassent un aller-retour par le CPU.

L'idée est d'avoir un seul code qui peut générer différents formats de déploiement. En encapsulant le graphe avec des balises *mixin* telles que `TfLiteMixinTag` ou `XnnpackMixinTag`, le même code C++ peut exporter un fichier `.tflite` exécutable sur CPU, GPU ou NPU, ou bien s'exécuter directement sur XNNPACK sans aucun fichier intermédiaire.

## Automatisation et comparaison des performances

Au-delà de la simple portabilité, la Tensor API fournit une base programmatique idéale pour les agents d'IA de codage. Ces agents peuvent désormais générer, réorganiser et ajuster les graphes de modèles de manière structurée en écrivant du code C++. Google a souligné que l'agent a permis de déplacer des décisions critiques, comme la vérification de la visibilité d'un objet, du code CPU vers le graphe exécutable sur le GPU, optimisant ainsi le flux de travail.

Pour ceux qui souhaitent vérifier la justesse des optimisations, `GraphProbe` est disponible pour exposer n'importe quel tenseur intermédiaire comme sortie de modèle, permettant de comparer une exécution optimisée avec une référence CPU. Les tests montrent, par exemple, que sur un MacBook Pro, l'implémentation du SAM 2 a fonctionné environ 1,5 fois plus vite que l'implémentation Apple MLX (fp16, encodeur d'image plus décodeur de masque). Arm, par exemple, a indiqué que les développeurs devraient privilégier la conversion sauf si leur besoin est de contrôler le graphe au niveau le plus bas ou si le pré-traitement et le post-traitement doivent rester sur l'accélérateur.

## Sources

- [Native Model Authoring for Edge with LiteRT Tensor API](https://developers.googleblog.com/native-model-authoring-for-edge-with-litert-tensor-api/), developers.googleblog.com
- [LiteRT/tensor/README.md at main · google-ai-edge/LiteRT](https://github.com/google-ai-edge/LiteRT/blob/main/tensor/README.md), github.com
- [Google Launches LiteRT Tensor API for Building, Customizing, and Optimizing ML Models for On-Device](https://www.infoq.com/news/2026/11/litert-tensor-api/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global), InfoQ, 3 novembre 2026