callstackincubator/ai : exécuter un LLM dans une application React Native

Le problème concret : éviter un serveur d'inférence

Faire appel à un LLM depuis une application mobile suppose le plus souvent un aller-retour réseau vers une API hébergée. Cela implique des coûts par requête, une latence dépendante de la connexion, et l'envoi des données de l'utilisateur vers un tiers. Le projet callstackincubator/ai prend le problème par l'autre bout : le modèle s'exécute sur l'appareil, et le paquet ne fait que fournir les primitives nécessaires pour l'appeler depuis React Native. Le README résume l'objectif en une phrase : exécuter des modèles directement sur les appareils des utilisateurs pour une inférence qui préserve la confidentialité, avec une faible latence et sans coûts serveur. Le public visé est donc l'équipe qui écrit déjà du React Native et qui veut ajouter de la génération de texte, des embeddings, de la transcription ou de la synthèse vocale sans monter une infrastructure backend.

Trois fournisseurs, trois régimes de fonctionnement

La bibliothèque ne fournit pas un moteur unique mais trois fournisseurs qui n'ont ni les mêmes prérequis ni le même coût d'entrée. Apple s'appuie sur les Foundation Models du système et ne demande aucun téléchargement : le tableau des fournisseurs le marque comme Built-in, disponible sur iOS uniquement. Llama passe par llama.rn et exige le téléchargement d'un modèle GGUF depuis HuggingFace, sur iOS et Android. MLC s'appuie sur le runtime MLC LLM, également sur les deux plateformes, avec des modèles à télécharger au préalable. Cette séparation est le choix de conception central du paquet : il n'y a pas de couche d'abstraction qui masquerait la différence entre un modèle système et un fichier de plusieurs gigaoctets. L'API exposée reste la même côté appel, mais le cycle de vie ne l'est pas.

Le mécanisme : des objets modèle compatibles AI SDK

L'intégration repose sur la production d'objets modèle que le Vercel AI SDK sait consommer. Le README donne l'exemple pour Apple : on importe apple depuis @react-native-ai/apple, puis generateText, embed, experimental_transcribe et experimental_generateSpeech depuis ai. Le modèle passé à generateText est apple(), celui passé à embed est apple.textEmbeddingModel(), et ainsi de suite. Côté Llama, la fabrique prend un identifiant au format owner/repo/filename.gguf, par exemple ggml-org/SmolLM3-3B-GGUF/SmolLM3-Q4_K_M.gguf. Le cycle est explicite : model.download() avec une fonction de progression, puis model.prepare() qui charge le modèle en mémoire, puis l'appel de génération, puis model.unload() pour libérer. Cette dernière étape n'est pas décorative. Garder un modèle chargé sur un téléphone a un coût mémoire réel, et l'API le rend visible plutôt que de le cacher derrière un ramasse-miettes.

Installation et contraintes de plateforme

Pour Apple, l'installation tient en une commande : npm install @react-native-ai/apple. Le README précise qu'aucun linking supplémentaire n'est nécessaire et que le paquet fonctionne immédiatement sur les appareils iOS grâce à l'autolinking. La disponibilité, en revanche, est plus étroite qu'il n'y paraît. La génération de texte requiert iOS 26 ou plus récent et un appareil compatible Apple Intelligence. La transcription demande aussi iOS 26. Les embeddings descendent à iOS 17. La synthèse vocale fonctionne dès iOS 13, avec iOS 17 pour Personal Voice. Autrement dit, la fonctionnalité la plus visible du paquet, le chat, est aussi la plus restrictive. Pour Llama, l'installation est plus lourde : npm install @react-native-ai/llama llama.rn react-native-blob-util, trois paquets au lieu d'un. Pour MLC, npm install @react-native-ai/mlc, avec une exigence documentée dans Xcode, la capacité Increased Memory Limit.

Compatibilité AI SDK : la rupture entre 0.11 et 0.12

Le tableau de compatibilité du README indique que la version 0.11 et les précédentes visent l'AI SDK v5, tandis que la 0.12 et au-delà visent la v6. Ce n'est pas un détail de version mineure : une application qui monte le paquet de 0.11 à 0.12 doit s'attendre à devoir suivre le SDK dans sa version majeure. Le rythme des publications est irrégulier. La v0.10.0 date du 27 septembre 2025, la v0.11.0 du 14 octobre 2025, et la v0.12.0 du 28 janvier 2026. Le dépôt n'est pas archivé et le dernier push enregistré est le 7 juillet 2026, ce qui suggère une activité de développement continue, mais l'espacement des versions montre qu'il ne faut pas compter sur des correctifs hebdomadaires.

Le profiler OpenTelemetry et le piège de la session de débogage

Le paquet @react-native-ai/dev-tools ajoute un plugin qui capture les spans OpenTelemetry émis par les requêtes du Vercel AI SDK et les affiche dans Rozenite DevTools. Le README précise que ces outils sont indépendants du runtime, donc utilisables aussi bien avec un modèle embarqué qu'avec un modèle distant. L'installation suppose que Rozenite soit déjà installé et activé dans l'application, et l'exemple Expo du dépôt contient le câblage natif nécessaire. Un point mérite d'être relevé parce qu'il ressemble à un bug alors que c'est un état de session : si le panneau AI SDK Profiler s'affiche mais reste vide après l'envoi d'un message, il faut fermer la fenêtre React Native DevTools et en ouvrir une nouvelle. Le README attribue cela à une session de débogueur obsolète qui garde le panneau monté sans recevoir le flux de télémétrie de l'application courante.

Les limites que la documentation ne contourne pas

La première limite est géographique au sens des plateformes : le fournisseur le plus simple à mettre en œuvre, Apple, ne concerne que iOS. Une application Android doit passer par Llama ou MLC, donc par le téléchargement d'un modèle, avec ce que cela implique en taille de paquet, en temps de premier lancement et en gestion du stockage. La deuxième limite est la version du système. Exiger iOS 26 pour la génération de texte et la transcription exclut mécaniquement une part importante du parc installé, et aucune couche de repli n'est décrite dans le matériel fourni. La troisième concerne Llama et MLC : les deux dépendent de runtimes tiers, llama.rn et MLC LLM, dont les contraintes propres ne disparaissent pas parce qu'on les appelle depuis TypeScript. La documentation du dépôt ne dit rien non plus sur le comportement en arrière-plan, sur la consommation thermique ou sur la qualité comparée des modèles GGUF cités en exemple, qui vont de 1,5 à 3 milliards de paramètres. Ce sont des choix à évaluer par vous-même, pas des garanties du paquet.

Ce qui distingue cette approche d'un appel API classique

L'alternative la plus directe est l'appel à un modèle hébergé, via le même Vercel AI SDK mais avec un fournisseur distant. La différence n'est pas seulement le coût : elle porte sur ce que vous devez construire. Avec un fournisseur distant, vous gérez une clé d'API, vous acceptez que le prompt quitte l'appareil, et vous dépendez de la connectivité. Avec callstackincubator/ai, vous gérez à la place un cycle de vie de modèle, une étape de téléchargement pour Llama et MLC, et un chargement en mémoire explicite. Le compromis est net : vous échangez une dépendance réseau contre une dépendance matérielle et système. Une autre alternative consiste à écrire directement contre llama.rn sans passer par l'adaptateur AI SDK. Vous perdez alors l'API generateText, embed et streamText, et vous devez réimplémenter vous-même la conversion des messages et le streaming. L'intérêt du paquet tient précisément dans cette couche, pas dans le moteur sous-jacent.

Conclusion éditoriale

À adopter si vous ciblez iOS 26 ou plus récent sur un appareil compatible Apple Intelligence et que vous voulez de l'inférence locale sans téléchargement de modèle. À éviter si votre base installée est majoritairement Android ou si vous devez supporter des versions d'iOS antérieures. Avant de vous engager, vérifiez la disponibilité d'Apple Foundation Models sur vos appareils cibles et le tableau de compatibilité AI SDK v5 contre v6, car le passage de 0.11 à 0.12 change la version du SDK attendue.

Sources officielles

1. callstackincubator/ai on GitHub
2. License: MIT
3. Project website
4. README
5. Releases