NobodyWho: eine Rust-Inferenz-Engine mit Bindings für sieben Plattformen

Welches Problem NobodyWho löst und für wen es gedacht ist

Ein Sprachmodell in eine App zu bekommen, ist selten das Modellproblem. Es ist das Bindungsproblem. llama.cpp ist C++, die Zielplattformen sind Kotlin, Swift, Dart, TypeScript und GDScript, und dazwischen liegt pro Plattform eine eigene Foreign-Function-Schnittstelle mit eigenen Speicherregeln. NobodyWho setzt genau dort an: Der Kern ist in Rust geschrieben, und das Repository liefert fertige Bindings für Kotlin, Swift, Python, Flutter, React Native, Expo und Godot. Die Zielgruppe sind damit Entwickler, die bereits eine Anwendung haben und eine lokale Inferenz hineinziehen wollen, ohne eine eigene FFI-Schicht zu bauen und zu pflegen.

Die README formuliert das Ziel als "On-device AI for any device". Der Zusatz "on-device" ist die eigentliche Einschränkung: Es geht nicht um einen Server, der viele Anfragen bedient, sondern um Inferenz auf dem Gerät, auf dem die App läuft. Das erklärt auch die Plattformliste. Godot, Flutter, React Native und Expo sind Umgebungen, in denen man typischerweise kein Python-Ökosystem zur Hand hat und in denen ein Modell im Prozess der App laufen soll, nicht daneben.

llama.cpp als Unterbau, Rust als Klebstoff

Die README benennt den Unterbau offen: "Powered by the wonderful llama.cpp". NobodyWho implementiert keine eigene Quantisierung und keine eigene Attention. Es lädt GGUF-Dateien, und die README nennt Gemma, Qwen und Mistral als Beispiele sowie die allgemeine Aussage, dass jede LLM im GGUF-Format nutzbar sei. Wer die Engine bewertet, bewertet damit zu einem großen Teil llama.cpp mit.

Interessanter ist, was NobodyWho darüber legt. Die README nennt vier Punkte: konversationsbewusstes preemptive context shifting, GPU-Beschleunigung über Vulkan oder Metal, GGUF-Kompatibilität und die genannten Zusatzmodule. Das context shifting ist der architektonisch auffälligste Punkt. Die README behauptet damit, dass Gesprächserinnerung ohne Nachrichtenlängenlimit erhalten bleibt. Wie das im Detail funktioniert, geht aus dem vorliegenden Material nicht hervor. Wer das für ein Projekt mit langen Verläufen braucht, sollte die verlinkte Dokumentation unter docs.nobodywho.ooo heranziehen, bevor er sich darauf verlässt.

Die GPU-Anbindung ist auf Vulkan oder Metal festgelegt. Das ist eine bewusste Einschränkung gegenüber einem breiteren Backend-Set, deckt aber Windows, Linux, macOS, iOS und Android ab, sofern die Geräte die entsprechenden Treiber mitbringen.

Die API ist über alle Bindings hinweg gleich aufgebaut

Auffällig ist, wie ähnlich die Quick-Start-Beispiele ausfallen. In Kotlin lautet der Aufruf Chat.fromPath(modelPath = ...), in Swift try await Chat.fromPath(modelPath: ...), in React Native Chat.fromPath({ modelPath: ... }), in Flutter nobodywho.Chat.fromPath(modelPath: ...). Nur Python weicht ab und nimmt den Pfad direkt im Konstruktor: Chat("huggingface:..."). Die Kette .ask(...).completed() findet sich in Kotlin, Swift, React Native, Flutter und Python wieder.

Das ist kein Zufall, sondern der Kern des Angebots. Ein Team, das eine Kotlin-App und eine Swift-App parallel pflegt, muss die Inferenzlogik nicht zweimal entwerfen. Die Modell-URLs sind ebenfalls über die Beispiele hinweg identisch aufgebaut, mit dem Muster hf://NobodyWho/Qwen_Qwen3-0.6B-GGUF/Qwen_Qwen3-0.6B-Q4_K_M.gguf. Zwei Schemata tauchen auf: hf:// in Kotlin, Swift und React Native, huggingface: in Flutter und Python. Wer Beispiele zwischen den Plattformen kopiert, sollte auf diesen Unterschied achten, weil ein falsches Schema vermutlich erst zur Laufzeit auffällt.

Das Modell in den Beispielen ist durchgehend ein Qwen3 mit 0,6 Milliarden Parametern in Q4_K_M. Das ist ein Hinweis darauf, für welche Größenklasse die Beispiele gedacht sind, und keine Aussage über die Obergrenze.

Installation: sieben Wege, ein Kern

Die Bezugswege sind in der README konkret aufgeführt. Für Kotlin gibt es zwei getrennte Artefakte, eines für Android und eines für Desktop-JVM: ai.nobodywho:nobodywho-android:2.0.0 und ai.nobodywho:nobodywho:2.0.0. Diese Trennung ist sinnvoll, weil die GPU-Anbindung auf Android anders aussieht als auf dem Desktop, bedeutet aber auch, dass man beim Versionssprung beide Zeilen im Blick behalten muss.

Swift kommt über Swift Package Manager von einem eigenen Repository, nobodywho-ooo/nobodywho-swift. React Native und Expo teilen sich ein npm-Paket, react-native-nobodywho, wobei Expo den Umweg über npx expo install nimmt. Flutter kommt über flutter pub add nobodywho von pub.dev. Python über pip install nobodywho. Godot schließlich über die AssetLib im Editor ab Version 4.5 oder als ZIP-Import von der Releases-Seite.

Der Godot-Weg hat eine Eigenheit, die in der README ausdrücklich erwähnt wird: Beim ZIP-Import muss im Dialog die Option zum Ignorieren des Asset-Roots gesetzt werden. Das ist die Art Detail, die man einmal falsch macht und dann eine Stunde sucht.

Bemerkenswert ist die Versionslage. Die drei jüngsten Releases im Material sind nobodywho-swift-v3.0.0, nobodywho-react-native-v3.0.0 und nobodywho-python-v2.0.0. Die Bindings werden also unabhängig voneinander versioniert, und die README-Beispiele für Kotlin nennen 2.0.0. Wer mehrere Plattformen aus einem Monorepo bedient, sollte damit rechnen, dass die Versionsnummern auseinanderlaufen.

Tool-Calling und multimodale Eingaben als eigentlicher Differenzierungspunkt

Die README wirbt mit "Fast, type-safe tool calling" und erklärt den Mechanismus: Aus den Funktionssignaturen werden automatisch strukturierte Grammatiken erzeugt, "no schema writing needed". Das ist der Punkt, an dem NobodyWho mehr tut als llama.cpp zu verpacken. Wer schon einmal JSON-Schemas für Tool-Aufrufe von Hand geschrieben und dann festgestellt hat, dass das Modell sie nicht einhält, weiß, was hier eingespart wird. Ob die Generierung in allen sieben Bindings gleich funktioniert, lässt sich aus dem Material nicht belegen. Die README zeigt kein einziges Tool-Calling-Beispiel, nur die Beschreibung. Das ist eine Lücke in der Dokumentation, die auffällt, weil das Feature so prominent beworben wird.

Dasselbe gilt für die multimodale Eingabe. Die README nennt "image and audio information" als Eingabe für das LLM, ohne Beispiel. Bei den Sprachfunktionen ist die Angabe konkreter: Text-to-Speech über die Backends Kokoro, Pocket TTS und Supertonic, Speech-to-Text über Whisper. Die Nennung der Backends ist hilfreich, weil sie zeigt, dass hier nicht ein einzelnes Modell fest verdrahtet ist.

Für wen das relevant ist: Eine Godot-Anwendung mit vertonter Dialogausgabe oder eine Mobile-App mit Spracheingabe braucht normalerweise zwei oder drei getrennte Bibliotheken. Hier kommen sie aus derselben Abhängigkeit.

Wo NobodyWho die falsche Wahl ist

Die deutlichste Grenze steckt im Namen des Ansatzes. On-Device heißt: ein Gerät, ein Prozess, ein Modell im Speicher. Wer zwanzig gleichzeitige Anfragen bedienen will, braucht vLLM, TensorRT-LLM oder einen llama.cpp-Server mit entsprechendem Batching. NobodyWho adressiert diesen Fall nicht, und die README erhebt auch keinen Anspruch darauf.

Die zweite Grenze ist das Format. GGUF ist die einzige genannte Modellquelle. Wer ein Modell in Safetensors mit eigener Quantisierung oder ein Modell mit einer Architektur, für die llama.cpp noch keine Unterstützung hat, einsetzen will, muss zuerst konvertieren. Ob das gelingt, hängt am Modell, nicht an NobodyWho.

Die dritte Grenze ist die Hardware. Vulkan oder Metal werden als Beschleunigungspfad genannt. Ein Gerät ohne brauchbaren Vulkan-Treiber fällt auf CPU-Inferenz zurück. Die README nennt dazu keine Zahlen, und ich habe keine gemessen. Wer eine Latenzzusage braucht, muss sie auf dem eigenen Zielgerät selbst ermitteln, mit dem eigenen Modell in der eigenen Quantisierung.

Schließlich die Plattformliste selbst. Sie ist breit, aber sie ist nicht vollständig. Wer eine Web-Anwendung im Browser oder eine .NET-Anwendung hat, findet hier kein Binding.

Der Vergleich mit llama.cpp direkt und mit ONNX Runtime GenAI

Der naheliegendste Vergleich ist llama.cpp ohne Wrapper. Der Unterschied liegt nicht in der Inferenz, sondern in der Arbeit drumherum. llama.cpp liefert eine C-API und Beispielprogramme. Wer daraus eine Kotlin-Bibliothek mit Coroutinen, eine Swift-Bibliothek mit async/await und eine Dart-Bibliothek mit Futures bauen will, schreibt drei Bindings und pflegt sie. NobodyWho hat diese Arbeit bereits gemacht und stellt sie unter einer gemeinsamen API-Form bereit. Der Preis dafür ist eine zusätzliche Abstraktionsebene und eine Abhängigkeit von den Release-Zyklen des Projekts. Wer nur eine einzige Plattform bedient und bereit ist, ein Binding selbst zu schreiben, gewinnt durch den direkten Weg an Kontrolle über Speicher und Threading.

Der zweite Vergleich ist ONNX Runtime GenAI. Dort ist das Modellformat ONNX und nicht GGUF, und der Ansatz ist entsprechend breiter bei Nicht-LLM-Modellen. Wer ohnehin einen ONNX-Pfad im Projekt hat, etwa für Vision-Modelle, fährt mit einem einzigen Runtime-Stack möglicherweise besser, als zwei getrennte Laufzeiten zu pflegen. Umgekehrt ist die Modellauswahl im GGUF-Ökosystem deutlich größer, und die README verweist ausdrücklich auf die GGUF-Modelle auf Hugging Face.

Der dritte Vergleich ist der einfachste: eine gehostete API. Sie löst das Bindungsproblem gar nicht, sondern verlagert es. Dafür entfallen Modellverteilung, Speicherbedarf und Gerätekompatibilität. NobodyWho richtet sich an die Fälle, in denen genau das nicht akzeptabel ist: Offline-Betrieb, keine API-Schlüssel, keine laufenden Kosten pro Anfrage.

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

NobodyWho steht unter EUPL-1.2, der European Union Public Licence in Version 1.2. Das ist eine Copyleft-Lizenz, die von der EU-Kommission veröffentlicht wurde und ausdrücklich mit mehreren anderen Copyleft-Lizenzen kompatibel ist. Wer die Bibliothek in ein proprietäres Produkt einbindet, sollte die Weitergabepflichten der EUPL prüfen, insbesondere die Frage, was beim Verteilen einer Anwendung mit statisch gelinkter Bibliothek als abgeleitetes Werk gilt. Das ist eine Rechtsfrage, keine technische, und ich gebe hier keine Rechtsberatung. Auffällig ist jedenfalls, dass die Wahl auf eine Copyleft-Lizenz gefallen ist und nicht auf MIT oder Apache-2.0, wie es bei Binding-Bibliotheken häufig der Fall ist.

Zum Wartungsaufwand: Die drei jüngsten Releases im Material stammen aus einem engen Zeitfenster im August 2026, der letzte Push auf den Hauptzweig datiert auf den 9. September 2026. Das Repository ist nicht archiviert. Die Versionsnummern der Bindings stehen bei 3.0.0 für Swift und React Native und 2.0.0 für Python, während die README für Kotlin 2.0.0 nennt. Solange diese Nummern auseinanderlaufen, bedeutet ein Upgrade nicht eine Änderung, sondern mehrere, verteilt über Plattformen. Wer mehrere Bindings einsetzt, sollte die Release-Notizen deshalb pro Plattform lesen und nicht nur die des Kerns.

Konkret zu prüfen, bevor man anfängt: ob das Zielgerät Vulkan oder Metal bereitstellt, ob das gewünschte Modell als GGUF vorliegt, ob die Versionsnummer des eigenen Bindings zu den Beispielen in der README passt, und ob die EUPL-1.2 mit der geplanten Distributionsform vereinbar ist. Die Dokumentation unter docs.nobodywho.ooo ist die Stelle, an der die hier offen gebliebenen Fragen zu Tool-Calling und context shifting beantwortet werden müssten.

Redaktionelles Fazit

Wer eine lokale LLM-Inferenz in eine bestehende Mobile-, Desktop- oder Godot-Anwendung einbetten will und dafür keine eigene FFI-Schicht schreiben möchte, findet hier sieben gepflegte Bindings unter einer einheitlichen API. Wer eine Server-Inferenz mit Batch-Verarbeitung, mehreren gleichzeitigen Nutzern oder einer breiten Modellunterstützung jenseits von GGUF braucht, ist hier falsch: NobodyWho ist auf ein Gerät und einen Chat-Verlauf ausgelegt. Vor dem ersten Commit sollte man prüfen, ob das eigene Zielgerät Vulkan oder Metal bereitstellt, ob die eigene Modellwahl als GGUF vorliegt und ob die EUPL-1.2 mit der eigenen Distributionsform vereinbar ist.

Offizielle Quellen

1. License: EUPL-1.2
2. nobodywho-ooo/nobodywho on GitHub
3. Project website
4. README
5. Releases