RunAnywhere : huit SDK au-dessus d'un noyau C++ unique, et un registre de capacités qui choisit le moteur
Production ready toolkit to run AI locally
En bref
- De quoi s’agit-il ?
- RunAnywhere veut faire tourner LLM, vision, parole, RAG et génération d'images en local sur mobile, navigateur, poste de travail et serveur, derrière une API sémantique commune. La promesse est large, l'architecture est explicite, mais la licence reste à vérifier avant toute intégration.
- À qui s’adresse-t-il ?
- Adoptez RunAnywhere si vous devez livrer une même fonction d'inférence locale sur iOS, Android, web et bureau sans maintenir quatre piles distinctes, et si vous acceptez de dépendre d'une licence non standard qu'il faut lire avant de distribuer. Passez votre chemin si votre besoin se résume à un seul LLM sur un seul serveur : llama.cpp seul ou un serveur Ollama couvrira cela avec moins de couches.
- Puis-je l’utiliser commercialement ?
- À vérifier. La licence de ce dépôt n’entre pas dans les catégories que nous classons automatiquement : lisez son fichier LICENSE avant tout usage commercial.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 5 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
Le problème visé : une API, huit plateformes, des moteurs qui changent selon le matériel
Le dépôt s'adresse aux équipes qui doivent exécuter de l'inférence sur des appareils hétérogènes. Le README décrit huit SDK posés sur un noyau C++ unique, avec un registre de capacités qui route chaque appel vers le meilleur moteur disponible sur la machine. Les cibles annoncées couvrent Android, iOS, Flutter, React Native, Kotlin, Swift, le web et le bureau. Le public visé n'est donc pas celui qui écrit un script Python jetable, mais celui qui doit livrer la même fonction de génération ou de transcription dans une application mobile et dans un navigateur, sans réécrire la couche d'inférence à chaque fois. Le README précise aussi que le code applicatif choisit rarement le matériel : les moteurs déclarent ce qu'ils savent exécuter, et le moteur le plus prioritaire compatible avec l'appareil l'emporte. Cette inversion de contrôle est le cœur du projet. Elle évite de coder en dur « Snapdragon » ou « Apple silicon » dans la logique métier, au prix d'une indirection qu'il faut comprendre avant de déboguer.
Le registre de capacités, ou pourquoi une énumération présente ne prouve rien
Le README insiste sur un point que beaucoup de SDK passent sous silence : il faut appeler RunAnywhere.capabilities() en v4 pour découvrir ce que le paquet et l'appareil peuvent réellement exécuter. La documentation précise que la seule présence d'une valeur d'énumération ne signifie pas qu'un moteur est installé. C'est une distinction importante en pratique. Un développeur peut voir la capacité vision dans la liste, écrire son appel, puis découvrir à l'exécution que le moteur correspondant n'est pas embarqué dans ce paquet. La méthode capabilities() devient donc un contrôle à faire au démarrage, pas une formalité. La priorité annoncée est la suivante : QHexRT sur le NPU Hexagon de Snapdragon, MLX sur Apple silicon, llama.cpp partout (Metal sur Apple, CUDA sur NVIDIA en build optionnel, WebGPU dans le navigateur), sherpa + ONNX pour la parole et les embeddings, Core ML pour la diffusion. Le README signale également que LiteRT et ExecuTorch ne sont que des valeurs de framework réservées : ce ne sont pas encore des runtimes intégrés. Cette phrase mérite d'être lue deux fois avant de bâtir une feuille de route dessus.
Mise en route : pip, CLI, ou enregistrement manuel du backend
Le chemin le plus court passe par Python. Le README donne pip install runanywhere, puis un appel à ra.initialize() suivi de ra.llm.generate avec LlmOptions(model="qwen2.5-0.5b"). Le commentaire du README indique que le modèle est téléchargé au premier usage. Pour un terminal, le projet renvoie vers RunanywhereAI/RCLI, installable par brew install runanywhereai/tap/rcli ou par un script curl, avec la commande rcli run qwen3. Ce CLI consomme le kit desktop C++ publié par ce dépôt, ce qui explique la présence de la release cpp-desktop-v0.20.37. Côté Swift, le README montre un enregistrement explicite du backend avant l'initialisation : LlamaCPP.register() puis try RunAnywhere.initialize(). Le chargement d'un modèle se fait via RAModelLoadRequest avec modelID, category et framework, et la génération via RALLMGenerateRequest avec un champ prompt. Pour ajouter le backend Apple natif, le README indique import RunAnywhereMLX et MLX.register(). L'installation passe par Swift Package Manager avec l'URL du dépôt. Le point à retenir : sur Swift, le backend ne se devine pas, il s'enregistre.
Ce que le projet ne fait pas, et le dit lui-même
Plusieurs limitations sont écrites noir sur blanc dans le README, ce qui est plus utile qu'un silence. La détection de mot-clé d'activation n'est pas implémentée : les agents vocaux enchaînent VAD, STT, LLM et TTS, mais il n'y a pas de wake word. Le parseur d'actions de type computer-use transforme des chaînes d'action au style Fara1.5 en coordonnées mises à l'échelle du viewport, et le README précise qu'il ne s'agit pas d'un framework d'agent autonome complet. L'inpainting sur le NPU Hexagon est conditionné à la plateforme et au backend. Les appels d'outils en parallèle ne sont possibles que si le moteur et la capacité déclarent ce support. Le décodage contraint pour la sortie structurée dépend aussi du moteur. Autrement dit, plusieurs fonctionnalités listées sont conditionnelles, pas garanties. C'est le principal piège du projet : la liste des capacités se lit comme un catalogue, alors que le comportement réel dépend de l'appareil, du paquet et du backend enregistré. Un test sur simulateur ne prédit pas ce qui se passera sur un téléphone d'entrée de gamme.
Un noyau C++ unique face à des piles séparées
L'alternative la plus directe pour un usage serveur ou bureau est llama.cpp employé seul. Le projet s'appuie d'ailleurs dessus comme moteur présent partout, avec Metal sur Apple, CUDA sur NVIDIA en build optionnel et WebGPU dans le navigateur. La différence d'approche est nette : llama.cpp expose une bibliothèque d'inférence et des binaires, sans registre de capacités, sans couche sémantique commune entre plateformes et sans SDK mobile dédié. Vous gardez le contrôle total du moteur et de la quantification, mais vous portez vous-même l'intégration iOS, Android et web. RunAnywhere ajoute une couche d'abstraction et un routage automatique vers QHexRT, MLX, sherpa + ONNX ou Core ML selon la machine. Ce confort a un coût : une dépendance de plus entre votre code et le moteur, et un comportement qui varie d'un appareil à l'autre sans que votre code change. Pour un service backend unique sur GPU NVIDIA, la couche d'abstraction n'apporte pas grand-chose. Pour une application livrée sur l'App Store et Google Play, elle évite de maintenir deux chemins d'inférence.
Licence, cadence de publication et coût de suivi
Le dépôt affiche une licence RunAnywhere, et l'identifiant renvoyé par l'outillage est NOASSERTION : le texte de licence n'est pas reconnu automatiquement comme une licence standard. Le README pointe vers le fichier LICENSE, et c'est ce fichier qu'il faut lire avant toute distribution, en particulier pour savoir ce qui est permis en usage commercial et en redistribution de binaire. Je ne peux pas trancher à votre place sur ce point, et personne ne devrait le faire à partir d'un badge. Sur la cadence, les releases visibles sont rapprochées : v0.20.35 et v0.20.36 le 2 septembre 2026, cpp-desktop-v0.20.37 le 7 septembre. Le numéro de version reste en 0.20.x, ce qui suggère une API encore mouvante. Le README mentionne d'ailleurs une API v4 pour capabilities(), signe que la surface publique a déjà évolué. Concrètement, prévoyez de suivre les notes de version et de retester vos appels après chaque montée, en particulier autour de l'enregistrement des backends et des demandes de chargement de modèle.
Ce qu'il faut vérifier avant de s'engager
Trois vérifications concrètes ressortent du matériel fourni. D'abord, appeler RunAnywhere.capabilities() sur chaque appareil cible et confronter le résultat aux fonctionnalités que vous comptez utiliser, puisque la présence d'une énumération ne garantit pas l'installation du moteur. Ensuite, confirmer que le backend nécessaire est bien enregistré dans votre intégration, comme le montre l'exemple Swift avec LlamaCPP.register() ou MLX.register(). Enfin, lire le fichier LICENSE, l'identifiant NOASSERTION indiquant que le texte n'entre dans aucune catégorie connue de l'outillage. Le projet indique aussi une Console capable de déployer des modèles et de collecter de la télémétrie, mentionnée dans la légende de l'architecture ; le README ne détaille pas ce point, et je ne peux donc rien affirmer sur son fonctionnement. Si votre contrainte principale est la souveraineté des données et l'exécution hors ligne, l'orientation du projet est cohérente avec cet objectif. Si votre contrainte est la stabilité d'une API figée, la série 0.20.x et la mention d'une API v4 invitent à la prudence.
Conclusion éditoriale
Adoptez RunAnywhere si vous devez livrer une même fonction d'inférence locale sur iOS, Android, web et bureau sans maintenir quatre piles distinctes, et si vous acceptez de dépendre d'une licence non standard qu'il faut lire avant de distribuer. Passez votre chemin si votre besoin se résume à un seul LLM sur un seul serveur : llama.cpp seul ou un serveur Ollama couvrira cela avec moins de couches. Avant d'écrire du code de production, appelez RunAnywhere.capabilities() sur chaque appareil cible et vérifiez que l'enum attendu correspond à un moteur réellement installé, puis lisez le fichier LICENSE, dont l'identifiant NOASSERTION signale que le texte n'est pas reconnu automatiquement.
Notes de la communauté