ONNX Runtime 1.31 : compilation en mémoire, puce neuronale d'Apple et télémétrie par défaut

ONNX Runtime est un moteur libre de Microsoft qui exécute des modèles d'IA au format ONNX sur à peu près tout : serveur, PC, téléphone, navigateur. Beaucoup d'éditeurs s'en servent sans que l'utilisateur le voie. La version 1.31.0 est sortie le 9 octobre ; une version 1.31.1 a suivi le 26 octobre.

Ce qui change pour les développeurs

• Des interfaces stabilisées. L'API de paquets de modèles et les fonctions de rappel liées aux modèles précompilés (EPContext) deviennent des interfaces C et C++ stables. Les fonctions de rappel arrivent aussi en C#, Python et Java.
• La compilation en mémoire. L'API de compilation peut écrire ses résultats dans des tampons mémoire plutôt que sur disque, ce qui ouvre la voie aux modèles de plus de 2 Go.
• Un démarrage plus rapide sur processeur. La préparation des poids s'effectue en parallèle à l'ouverture d'une session. Les notes ne chiffrent pas le gain.
• Davantage de processeurs optimisés. De nouveaux noyaux de calcul visent les puces x86, Arm et RISC-V.

Mac et iPhone : le choix du matériel simplifié

Le fournisseur CoreML rejoint le mécanisme de sélection automatique du matériel. Une application peut demander à privilégier la puce neuronale d'Apple avec la préférence PREFER_NPU. Les notes fixent les versions minimales : iOS 16 ou macOS 13 pour la puce neuronale, iOS 15 ou macOS 12 pour la carte graphique.

Cartes graphiques et navigateur

La version s'accompagne de deux modules séparés : le greffon CUDA en version 0.3.0, avec notamment des améliorations annoncées pour les cartes grand public de la génération Blackwell, et le greffon WebGPU en version 0.5.0 pour l'exécution dans le navigateur.

Les changements de comportement

• Télémétrie. Les compilations natives prises en charge activent désormais par défaut la télémétrie 1DS de Microsoft. Les notes mentionnent une option de compilation --no_telemetry.
• Interfaces expérimentales retirées. Le code qui utilisait les anciennes entrées expérimentales pour les paquets de modèles doit passer par OrtApi::GetModelPackageApi.
• Cœur et greffons alignés. Le moteur et ses greffons doivent partager les mêmes définitions d'opérateurs. Microsoft recommande de les compiler à partir de la même révision, car un écart peut passer inaperçu au chargement.
• Un opérateur modifié. GatherBlockQuantized renvoie désormais des zéros pour un indice hors limites, au lieu d'une erreur.

Côté abandons, le fournisseur ACL est déprécié et sera retiré dans une version future. La bibliothèque ONNX reste en version 1.22.0 : l'intégration de la version 1.23 a été annulée en attendant des corrections en amont.

Les limites

La page lue ne précise ni les versions de Python, ni les plateformes couvertes par les paquets, ni les problèmes connus. Elle ne donne aucune mesure de performance. Et elle ne détaille pas quelles données la télémétrie transmet ni dans quels paquets précompilés elle est active : c'est à vérifier dans la documentation du projet avant tout déploiement sur des postes soumis à des règles de confidentialité.

Notre lecture

Pour une PME, ONNX Runtime est rarement un choix direct : il arrive dans les bagages d'un logiciel. La question utile à poser à votre éditeur ou à votre prestataire est donc double. Quelle version du moteur embarque le produit ? Et la télémétrie y est-elle active ? Si vous développez en interne, la sélection automatique de la puce neuronale sur Mac et la compilation en mémoire sont de vraies simplifications. Mais prenez le temps de lire la politique de télémétrie et, si vous compilez vous-même, de décider explicitement de l'option à retenir. Dans un contexte RGPD, un envoi de données activé par défaut se documente, même s'il est technique.