RunAnywhere: acht SDKs über einem C++-Kern für lokale Inferenz
Production ready toolkit to run AI locally
Auf einen Blick
- Was ist das?
- RunAnywhere bündelt LLM, Vision, Sprache, RAG und Diffusion hinter einer semantischen API und routet jeden Aufruf über eine Capability-Registry auf die passende Engine. Der Ansatz ist überzeugend, die Lizenzlage bleibt aber die erste Frage vor dem Einsatz.
- Für wen ist es gedacht?
- Für Teams, die LLM, Speech und Vision auf iOS, Android, Desktop oder im Browser mit derselben API ansprechen wollen, ist RunAnywhere ein ernstzunehmender Kandidat. Wer nur einen einzelnen llama.cpp-Aufruf braucht, trägt mit acht SDKs und einer Registry zu viel Gewicht.
- Darf ich es kommerziell nutzen?
- Erst prüfen. Die Lizenz dieses Repositorys ordnen wir nicht automatisch ein; lesen Sie vor jeder kommerziellen Nutzung die LICENSE-Datei.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 5 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich C++, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem die acht SDKs lösen sollen
Wer heute ein Sprachmodell in eine App bringen will, steht vor einer unangenehmen Auswahl. llama.cpp läuft fast überall, aber nicht auf jedem Gerät gleich gut. Apples MLX ist auf Apple Silicon stark, hilft auf einem Snapdragon-Gerät jedoch nicht. Für Speech-to-Text kommt Whisper oder Moonshine in Frage, für Text-to-Speech Piper, Kokoro, Kitten, MeloTTS oder Magpie, für Diffusion Core ML oder der Hexagon-NPU. Jede dieser Engines hat eigene Bindings, eigene Modellformate und eigene Initialisierungsroutinen. RunAnywhere setzt genau dort an: Das Projekt beschreibt sich als Toolkit, das LLMs, Vision, Speech, Voice Agents, RAG, Embeddings und Bildgenerierung lokal auf Telefonen, im Browser, auf Desktops und Servern ausführt, und zwar hinter einer gemeinsamen API. Die Zielgruppe sind damit nicht Forscher, die ein einzelnes Modell vermessen, sondern Produktteams, die dieselbe Funktion auf mehreren Plattformen ausliefern müssen.
Capability-Registry statt fester Engine-Wahl
Der Kern des Designs ist eine Registry, die nicht der Anwendungscode, sondern die Engines selbst befüllen. Jede Engine registriert, was sie auf dem jeweiligen Gerät ausführen kann. Bei einem Aufruf gewinnt die Engine mit der höchsten Priorität, die zum Gerät passt. Die vom README genannte Reihenfolge lautet QHexRT auf dem Snapdragon Hexagon NPU, MLX auf Apple Silicon, llama.cpp überall (mit Metal auf Apple, CUDA auf NVIDIA als Opt-in-Build und WebGPU im Browser), sherpa zusammen mit ONNX für Speech und Embeddings sowie Core ML für Diffusion. Das ist eine bewusste Umkehr der üblichen Kontrolle: Der Entwickler beschreibt, was er will, nicht worauf es laufen soll. Der Preis dafür ist Sichtbarkeit. Das README empfiehlt ausdrücklich, RunAnywhere.capabilities() aufzurufen, um herauszufinden, was das aktuelle Paket und Gerät tatsächlich ausführen kann, denn die bloße Existenz eines Enum-Werts sagt nichts darüber aus, ob die Engine installiert ist. LiteRT und ExecuTorch tauchen als reservierte Framework-Werte auf, sind laut README aber noch keine integrierten Runtimes. Wer diese Namen in einer Capability-Abfrage sieht, sollte daraus keine Verfügbarkeit ableiten.
Ein C++-Kern, acht Sprachoberflächen
Die Architektur ist im README als Bild beschrieben: acht SDKs über einem gemeinsamen C++-Kern, darunter die Registry, darunter die Engines, darunter die Hardware. Die acht Bindings decken Android, iOS, Flutter, React Native, Web, Desktop und weitere Plattformen ab, wobei die Topics des Repositories Kotlin, Swift, C++, Flutter, React Native und Web SDK nennen. Für Teams bedeutet das, dass die Modellverwaltung, das Laden und die Inferenz nicht pro Plattform neu geschrieben werden. Die Sprachoberflächen unterscheiden sich dennoch deutlich. Das Swift-Beispiel im README registriert zuerst einen Backend-Anbieter (LlamaCPP.register()), initialisiert dann die Laufzeit, lädt ein Modell über eine RAModelLoadRequest mit modelID, category und framework und ruft schließlich RunAnywhere.generate mit einer RALLMGenerateRequest auf. Der Python-Weg ist kürzer: ra.initialize() und ein Aufruf von ra.llm.generate mit LlmOptions(model="qwen2.5-0.5b"). Beide Wege münden in dieselbe Registry, aber die Swift-Variante macht die Backend-Wahl explizit, während Python sie implizit lässt. Wer auf Apple zusätzlich MLX nutzen will, registriert es laut README separat mit MLX.register().
Installation über pip, brew oder den CLI-Installer
Der schnellste Einstieg ist der Python-Pfad. Ein pip install runanywhere, danach ra.initialize() und ein Generierungsaufruf mit dem Modell qwen2.5-0.5b. Das README weist darauf hin, dass das Modell beim ersten Gebrauch heruntergeladen wird. Für die Kommandozeile verweist das Projekt auf ein separates Repository, RunanywhereAI/RCLI, das den in diesem Repository veröffentlichten C++-Desktop-Kit konsumiert. Die Installation läuft entweder über brew install runanywhereai/tap/rcli oder über ein Shell-Skript, das per curl geladen und direkt an sh übergeben wird. Der Aufruf lautet dann rcli run qwen3 "...". Für mobile und Web-Ziele nennt das README Swift Package Manager mit der URL des Repositories als Bezugsweg. Die Versionsstände sind eng getaktet: Die Releases cpp-desktop-v0.20.37, v0.20.36 und v0.20.35 liegen innerhalb weniger Tage im September 2026. Das spricht für aktive Arbeit, bedeutet aber auch, dass Pinning auf eine konkrete Version sinnvoll ist, wenn ein Projekt auf einem Kit aufbaut.
Was das README selbst als nicht vorhanden markiert
Die ehrlichsten Stellen im README sind die Einschränkungen. Wake-Word-Erkennung ist nicht implementiert, obwohl Voice Agents als Feature aufgeführt sind. Der Computer-Use-Action-Parser (CUA) parst Fara1.5-artige Aktionsstrings in viewport-skalierte Koordinaten und ist ausdrücklich kein vollständiges autonomes Agent-Framework. Strukturierte Ausgaben sind schema-validiert, aber Constrained Decoding nur dort, wo die Engine es unterstützt, und der Modus wird über generateStructured zusammen mit einem Enforcement-Modus gesteuert. Parallele Tool-Aufrufe hängen davon ab, ob Engine und Capability das melden. Diffusion läuft auf Core ML, Inpainting auf der Hexagon-NPU, beides ist laut README plattform- und backend-abhängig. Das ist die entscheidende Einschränkung: Die API ist einheitlich, die Fähigkeiten sind es nicht. Ein Team, das dieselbe Funktion auf iOS und Android verspricht, muss mit unterschiedlichem Verhalten rechnen. Wer ein einzelnes, gut verstandenes Modell auf einer einzigen Plattform betreibt, fährt mit einer direkten llama.cpp-Einbindung geradliniger, weil dann keine Registry zwischen Aufruf und Engine steht.
Alternative: Ollama und der Unterschied im Ansatz
Ollama wird in den Topics des Repositories selbst genannt und ist der naheliegende Vergleich. Der Unterschied liegt nicht in den Modellen, sondern im Ort der Ausführung. Ollama betreibt einen lokalen Serverprozess, den die Anwendung über HTTP anspricht. Das Modell liegt auf dem Rechner, auf dem der Server läuft, und die Inferenz passiert dort. RunAnywhere geht den entgegengesetzten Weg: Die Inferenz läuft im Prozess der Anwendung selbst, auf dem Gerät des Nutzers, mit Engines, die sich zur Laufzeit registrieren. Für einen Desktop-Rechner oder einen Server ist der Serveransatz einfacher zu betreiben und zu beobachten, weil ein Prozess neu gestartet werden kann, ohne die Anwendung anzufassen. Auf einem Telefon oder im Browser gibt es diesen Server nicht, und genau dort ist der In-Process-Ansatz von RunAnywhere die Voraussetzung dafür, dass überhaupt etwas läuft. Wer nur einen Server mit einer HTTP-Schnittstelle braucht, gewinnt durch den Wechsel zu RunAnywhere nichts.
Wartung, Versionstakt und die offene Lizenzfrage
Das Repository ist nicht archiviert, der letzte Push liegt im September 2026, und die Releases folgen in kurzen Abständen. Die Versionsnummern tragen Kit-Namen wie cpp-desktop-v0.20.37, was darauf hindeutet, dass verschiedene Kits unabhängig voneinander veröffentlicht werden. Ein Upgrade kann daher bedeuten, dass sich nur ein Kit bewegt, während die anderen stehen bleiben. Wer die SDKs einsetzt, sollte die Version des jeweiligen Kits festhalten und nicht auf einen gleitenden Stand setzen. Der Punkt, der vor allem anderen zu klären ist, betrifft die Lizenz. Die Metadaten des Repositories melden NOASSERTION, und der Badge im README trägt die Beschriftung "RunAnywhere License" mit einem Link auf die Datei LICENSE. Ob diese Lizenz kommerzielle Nutzung erlaubt, ob sie an Bedingungen geknüpft ist oder ob sie pro Plattform variiert, lässt sich aus dem vorliegenden Material nicht beantworten. Das ist keine Formalie, sondern die erste Frage, die ein Team vor der Integration klären muss, und zwar anhand der LICENSE-Datei selbst und nicht anhand des Badges.
Redaktionelles Fazit
Für Teams, die LLM, Speech und Vision auf iOS, Android, Desktop oder im Browser mit derselben API ansprechen wollen, ist RunAnywhere ein ernstzunehmender Kandidat. Wer nur einen einzelnen llama.cpp-Aufruf braucht, trägt mit acht SDKs und einer Registry zu viel Gewicht. Vor dem ersten Commit sollte die LICENSE-Datei im Repository geklärt werden, denn die Metadaten melden NOASSERTION und der Badge im README nennt lediglich "RunAnywhere License". Danach lohnt ein Aufruf von RunAnywhere.capabilities() auf dem Zielgerät, weil die Enum-Präsenz laut README nicht bedeutet, dass eine Engine installiert ist.
Community-Notizen