callstackincubator/ai: On-Device-LLMs in React Native mit AI-SDK-Schnittstelle

Drei Provider, ein API-Vertrag

Das Repository heißt callstackincubator/ai und beschreibt sich selbst als Sammlung von On-Device-KI-Primitiven für React Native mit Unterstützung für das Vercel AI SDK. Der Kern der Idee: Statt einen Server für Inferenz zu betreiben, läuft das Modell auf dem Gerät des Nutzers. Das README nennt als Motivation Privatsphäre, niedrige Latenz und eingesparte Serverkosten. Das sind keine messbaren Zusagen, sondern die Zielsetzung des Projekts.

Der eigentliche Wert liegt in der Vereinheitlichung. Es gibt drei Provider: Apple, Llama und MLC. Jeder hat eigene Installationspakete, eigene Plattformanforderungen und eine eigene Laufzeit im Hintergrund. Nach außen hin werden sie jedoch über die AI-SDK-Aufrufe angesprochen, also über Funktionen wie generateText, streamText, embed, experimental_transcribe und experimental_generateSpeech. Wer diese API bereits kennt, muss für den Wechsel des Providers nur das Modellobjekt austauschen. Das ist der architektonische Kern des Projekts, und er ist es, der die drei sehr unterschiedlichen Backends überhaupt vergleichbar macht.

Apple: Inferenz ohne Download, aber nur auf iOS 26+

Der Apple-Provider ist der einzige, der ohne Modell-Download auskommt. Laut README nutzt er die Foundation Models von Apple für Textgenerierung, NLContextualEmbedding für 512-dimensionale Vektoren, SpeechAnalyzer für Transkription und AVSpeechSynthesizer für Sprachausgabe. Installiert wird er mit npm install @react-native-ai/apple, und das README hält fest, dass keine zusätzliche Verlinkung nötig ist, weil das Paket autolinked wird.

Die Verfügbarkeitstabelle ist der wichtigste Abschnitt der ganzen Dokumentation. Textgenerierung verlangt iOS 26 oder neuer und ein Gerät mit Apple Intelligence. Embeddings laufen ab iOS 17. Transkription setzt ebenfalls iOS 26 voraus. Sprachsynthese funktioniert ab iOS 13, wobei Personal Voice erst ab iOS 17 dazukommt. Wer also heute eine App ausliefert, die auf breiter Gerätebasis laufen soll, kann den Apple-Provider für alles außer Embeddings und Basis-Sprachausgabe nicht als gegeben voraussetzen. Das ist keine Kleinigkeit, sondern die zentrale Einschränkung dieses Providers.

Llama und MLC: Kontrolle über das Modell, Kontrolle über die Probleme

Die beiden anderen Provider laden Modelle herunter. Llama nutzt llama.rn als Laufzeit und akzeptiert GGUF-Modelle von HuggingFace. Die Modell-ID folgt dem Format owner/repo/filename.gguf, im README steht als Beispiel ggml-org/SmolLM3-3B-GGUF/SmolLM3-Q4_K_M.gguf. Der Ablauf im Beispielcode ist dreistufig: erst model.download mit einer Fortschrittsfunktion, dann model.prepare, um das Modell in den Speicher zu laden, und am Ende model.unload zum Aufräumen. Dass unload explizit im Beispiel auftaucht, sagt etwas über das Speichermodell: Ein geladenes Modell belegt Platz, bis man es freigibt.

Die Installation zieht drei Pakete: npm install @react-native-ai/llama llama.rn react-native-blob-util. Das dritte Paket deutet darauf hin, dass der Download über das Dateisystem abgewickelt wird. MLC verfolgt denselben Download-Ansatz, bringt aber eine andere Laufzeit mit, nämlich MLC LLM mit eigener Optimierung. Für MLC nennt das README eine Xcode-Anforderung: die Capability Increased Memory Limit muss gesetzt sein. Auch das ist ein Hinweis darauf, wie viel Speicher diese Laufzeiten beanspruchen.

AI-SDK-Versionen binden das Projekt an eine Major-Version

Das Kompatibilitätstabelle im README ist kurz und folgenreich. React Native AI 0.11 und darunter passt zu AI SDK v5. Ab 0.12 ist AI SDK v6 die Grundlage. Wer bereits eine App mit dem AI SDK gebaut hat, muss beim Wechsel der AI-SDK-Hauptversion also auch die passende Version dieses Projekts wählen. Das ist ein Kopplungspunkt, der bei jedem AI-SDK-Major-Release erneut Aufmerksamkeit verlangt.

Die Release-Historie zeigt den Rhythmus: v0.10.0 im September 2025, v0.11.0 im Oktober 2025, v0.12.0 im Januar 2026. Der letzte Push ins Repository datiert vom Juli 2026. Die Versionsnummern bleiben im Nuller-Bereich, was bei einem Projekt dieser Art bedeutet, dass die API noch nicht als stabil zugesagt wird. Wer das Projekt einsetzt, sollte damit rechnen, dass sich Importe oder Modell-Fabriken zwischen Minor-Versionen ändern können.

DevTools: Telemetrie für lokale und entfernte Laufzeiten

Das Paket @react-native-ai/dev-tools liefert ein Plugin namens AI SDK Profiler. Es sammelt OpenTelemetry-Spans aus Anfragen des Vercel AI SDK und zeigt sie in Rozenite DevTools an. Laut README sind die DevTools laufzeitunabhängig, funktionieren also sowohl bei On-Device- als auch bei entfernten Laufzeiten. Das ist insofern bemerkenswert, als es den Vergleich zwischen lokalem und entferntem Modell auf derselben Oberfläche erlaubt, ohne dass man zwei Werkzeugketten betreiben muss.

Die Installation erfolgt separat über npm install @react-native-ai/dev-tools, und Rozenite muss in der App installiert und aktiviert sein. Das README verweist dafür auf den Getting-started-Leitfaden von Rozenite. Interessant ist ein konkreter Fehlerfall, den die Dokumentation selbst benennt: Wenn das Panel AI SDK Profiler sichtbar ist, aber nach dem Senden einer Chat-Nachricht leer bleibt, soll man das React Native DevTools-Fenster schließen und ein frisches öffnen. Eine veraltete Debugger-Sitzung könne das Rozenite-Panel eingehängt lassen, ohne den Telemetriestrom der aktuellen App zu empfangen. Dass ein solcher Hinweis überhaupt in der README steht, spricht dafür, dass das Problem im Alltag auftritt.

Wann dieses Projekt die falsche Wahl ist

Der offensichtlichste Fall: Android-Geräte ohne Zugriff auf Apple Foundation Models. Dort bleibt nur Llama oder MLC, und damit die Frage, welches Modell auf welchem Gerät vertretbar läuft. Das README nennt Beispiele wie SmolLM3-3B, Llama-3.2-3B-Instruct und Qwen2.5-1.5B-Instruct, alle in Q4-Quantisierung. Das sind kleine Modelle. Wer ein Modell mit deutlich mehr Parametern braucht, wird auf den Speichergrenzen der Mittelklasse-Geräte anstoßen, und die Increased-Memory-Limit-Anforderung bei MLC deutet an, dass selbst die kleineren Varianten nicht kostenlos sind.

Ein zweiter Fall: Szenarien, in denen die Modellqualität wichtiger ist als Datenschutz oder Latenz. Ein lokales 3B-Modell in Q4 liefert nicht die Antwortqualität eines großen Servermodells. Wer Zusammenfassungen von Verträgen oder mehrstufige Agentenabläufe baut, für die Fehlerquote teuer ist, sollte die Inferenz nicht auf das Gerät verlagern. Der dritte Fall ist die Update-Frage: Ein heruntergeladenes GGUF-Modell liegt beim Nutzer, und eine neue Modellversion erfordert einen erneuten Download. Bei Apple-Modellen entfällt dieses Problem, weil sie mit dem System kommen, aber dafür hat man auch keine Wahl bei der Modellversion.

Was eine Alternative anders macht

Der naheliegende Vergleich ist der AI SDK selbst mit einem entfernten Provider. Dort ruft der Client einen HTTP-Endpunkt auf, das Modell läuft auf einem Server, und die App muss nur ein Netzwerk antworten lassen. Die Unterschiede sind grundlegend: Bei einem entfernten Provider gibt es keine Modell-Downloads, keine Speichergrenzen auf dem Gerät und keine Plattformversionsabhängigkeit wie iOS 26. Dafür verlassen die Nutzereingaben das Gerät, es entstehen laufende Kosten pro Anfrage, und die Latenz hängt von der Verbindung ab.

Der zweite Vergleich ist llama.rn direkt, ohne die Abstraktion dieses Projekts. Wer llama.rn unmittelbar anspricht, hat vollen Zugriff auf dessen Parameter und muss keine Zwischenschicht verstehen. Dafür schreibt man den Code für Download, prepare und unload selbst und verliert die Möglichkeit, denselben Aufrufcode mit einem anderen Backend zu verwenden. Der Gewinn dieses Projekts liegt genau in dieser Austauschbarkeit, und er wiegt nur dann etwas, wenn man tatsächlich mehr als einen Provider in Betracht zieht.

Lizenz, Pflegeaufwand und was vor dem Einsatz zu prüfen ist

Das Repository steht unter der MIT-Lizenz. Das ist eine permissive Lizenz, die kommerzielle Nutzung, Veränderung und Weitergabe erlaubt, sofern der Lizenztext und der Urheberrechtshinweis beibehalten werden. Wichtig ist, dass die MIT-Lizenz nur dieses Repository abdeckt. Die Abhängigkeiten haben eigene Lizenzen: llama.rn, react-native-blob-util, das MLC-LLM-Projekt und die heruntergeladenen GGUF-Modelle von HuggingFace. Gerade bei Modellgewichten sind die Lizenzbedingungen oft nicht MIT, sondern enthalten Nutzungsbeschränkungen. Das ist keine Rechtsberatung, aber ein Punkt, der vor dem Ausliefern einer App geklärt werden sollte.

Der Pflegeaufwand hat drei Quellen. Erstens die Kopplung an die AI-SDK-Hauptversion, die bei jedem Major-Release eine Anpassung erzwingt. Zweitens die Plattformversionen: Apple-Features hängen an iOS 26 und an Apple-Intelligence-Hardware, und diese Grenze verschiebt sich mit jedem iOS-Release. Drittens die Laufzeiten selbst, also llama.rn und MLC LLM, die eigene Release-Zyklen haben. Wer das Projekt einsetzt, sollte zuerst prüfen, welche iOS-Version die eigene Zielgruppe tatsächlich nutzt, ob die AI-SDK-Version im Projekt zu 0.12 oder älter passt, und ob das gewählte GGUF-Modell auf den schwächsten unterstützten Geräten noch lädt. Diese drei Prüfungen entscheiden mehr über den Erfolg als die Wahl des Providers.

Redaktionelles Fazit

Wer eine iOS-App ab Version 26 für Apple-Intelligence-Geräte baut, findet in @react-native-ai/apple den kürzesten Weg zu Textgenerierung und Embeddings ohne Modell-Download. Für Android oder ältere iOS-Versionen führt kein Weg an llama.rn oder MLC vorbei, und damit an die Frage, welches GGUF-Modell auf welchem Gerät noch in den Speicher passt. Vor dem ersten Commit sollte man klären, ob die Zielgruppe überhaupt Apple-Intelligence-Hardware besitzt, denn davon hängt ab, welcher Provider überhaupt in Frage kommt.

Offizielle Quellen

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