RWKV-Runner: Ein 8-MB-Client, der RWKV-Modelle startet und als OpenAI-Endpunkt ausgibt

Welches Problem der Runner löst und für wen er gedacht ist

RWKV ist ein offenes Sprachmodell, dessen Gewichte und Code kommerziell nutzbar sind. Der Aufwand liegt weniger im Modell als in der Umgebung: passende Python-Abhängigkeiten, ein Inferenz-Backend, ein Modell in einem Format, das die Laufzeit versteht, und ein Client, der mit dem Ergebnis spricht. Genau diese Kette automatisiert RWKV-Runner. Das Projekt beschreibt sein Ziel selbst damit, die Hürden bei der Nutzung großer Sprachmodelle zu beseitigen und alles zu automatisieren; das ausgelieferte Programm ist dem README zufolge nur wenige Megabyte groß. Die Zielgruppe sind damit Anwender, die ein RWKV-Modell lokal oder auf eigener Hardware betreiben wollen, ohne die Abhängigkeitskette manuell zusammenzusetzen. Der zweite Teil der Zielgruppe ist größer, als er zunächst wirkt: Weil der Server eine OpenAI-kompatible Schnittstelle anbietet, lässt sich laut README jeder ChatGPT-Client als RWKV-Client verwenden. Wer bereits Werkzeuge gegen die OpenAI-API laufen lässt, muss in diesen Werkzeugen nur Basis-URL und Schlüssel ändern. Das ist der eigentliche Nutzen des Projekts, nicht der Chat-Client, der mitgeliefert wird.

Frontend, Backend und ein HTTP-Server dazwischen

Die Architektur ist eine Trennung von Oberfläche und Inferenz, die sich auch einzeln betreiben lässt. Das Repository enthält ein Verzeichnis backend-python mit der Inferenz-Logik und ein Verzeichnis frontend, das mit npm ci und npm run build zu einer statischen Anwendung kompiliert wird. Der Client selbst ist ein Wails-Programm, also eine Kombination aus Web-Oberfläche und Go-Rahmen, weshalb TypeScript als Hauptsprache im Repository geführt wird und die Themenliste Wails enthält. Der Datenfluss ist geradlinig: Das Backend lädt ein RWKV-Modell über den Endpunkt /switch-model, hält es im Speicher und beantwortet Anfragen auf Port 8000. Die API-Dokumentation liegt unter http://127.0.0.1:8000/docs, und laut README ist die Schnittstelle mit der OpenAI-API kompatibel. Diese Trennung ist der Grund, warum das Projekt sowohl als Desktop-Anwendung als auch als Serverkomponente funktioniert. Wer nur die Inferenz braucht, startet backend-python/main.py und spricht direkt mit dem Endpunkt. Wer die Oberfläche auf einem anderen Rechner haben will, trägt in den Einstellungen unter API URL die Adresse des Servers ein und benutzt das Programm nur noch als Client.

Inbetriebnahme: Klonen, starten, Modell umschalten

Der einfachste Weg steht im README als Abfolge von Befehlen. Zuerst git clone https://github.com/josStorer/RWKV-Runner, danach cd RWKV-Runner und python ./backend-python/main.py. Damit läuft der Inferenzdienst, aber noch kein Modell: Das README verweist ausdrücklich darauf, dass anschließend der Endpunkt /switch-model aufgerufen werden muss, um ein Modell zu laden, und nennt als Referenz die API-Dokumentation unter http://127.0.0.1:8000/docs. Wer zusätzlich die Oberfläche braucht, kompiliert sie im Verzeichnis frontend mit npm ci und npm run build und startet dann python ./backend-python/webui_server.py. Der kürzere Weg für beides zusammen ist python ./backend-python/main.py --webui. Hilfe zu den Optionen gibt python ./backend-python/main.py -h. Für die Konfiguration sind zwei Stellen wichtig. In den Einstellungen der Anwendung stehen API URL und API Key, die festlegen, welchen Server der Client anspricht. Auf der Configs-Seite liegt der Schalter Use Custom CUDA kernel to Accelerate, der laut README standardmäßig aktiv ist und sowohl schneller als auch sparsamer im VRAM-Verbrauch sein soll. Bei Ausgabe-Artefakten empfiehlt das README, diesen Schalter zu deaktivieren oder den GPU-Treiber zu aktualisieren.

Die API-Obergrenze ist die wichtigste Betriebsentscheidung

Das README enthält einen Hinweis, den man leicht überliest, der aber den Ressourcenverbrauch bestimmt. Für öffentlich erreichbare Deployments wird empfohlen, die Request-Größe über ein API-Gateway zu begrenzen, um übermäßigen Ressourcenverbrauch durch sehr lange Prompts zu verhindern. Zusätzlich soll die Obergrenze für max_tokens an die eigene Situation angepasst werden. Das README verlinkt dafür eine konkrete Stelle im Backend-Code, backend-python/utils/rwkv.py, Zeile 567, und nennt den dort gesetzten Standardwert: le=102400. Dieser Wert ist keine Empfehlung, sondern eine Voreinstellung, die im Extremfall einzelne Antworten sehr teuer macht. Wer den Dienst ohne vorgelagertes Gateway betreibt, trägt dieses Risiko selbst. Zur Belastbarkeit liefert das README ein eigenes Beispiel mit ApacheBench: ab -p body.json -T application/json -c 20 -n 100 -l http://127.0.0.1:8000/chat/completions, wobei body.json eine messages-Liste mit einer user-Rolle enthält. Das ist ein Werkzeug zum Nachmessen, kein Beleg für ein Ergebnis. Wer den Dienst produktiv betreibt, sollte diesen Aufruf mit dem eigenen Modell und der eigenen Hardware wiederholen, bevor er Last annimmt.

Grenzen: Hardware, Plattform und ein umgebautes Embeddings-Format

Die VRAM-Konfigurationen sind laut README mehrstufig voreingestellt und sollen auf nahezu allen Rechnern funktionieren. Für AMD-, Intel- und andere Grafikkarten nennt das README einen Ausweg: Auf der Configs-Seite lässt sich die Strategy auf WebGPU umstellen. Das ist ein Kompatibilitätspfad, kein gleichwertiger Betrieb, und ob die Geschwindigkeit für den eigenen Anwendungsfall reicht, lässt sich aus dem Material nicht ableiten. Der CUDA-Kernel ist ebenfalls ein Vorteil mit Bedingung: Er ist standardmäßig aktiv, und das README nennt verfälschte Ausgaben als mögliches Symptom von Kompatibilitätsproblemen. Ein weiterer Stolperstein ist historisch gewachsen. Ab v1.4.0 wurde die Qualität der Embeddings-API verbessert, und die erzeugten Ergebnisse sind nicht mit früheren Versionen kompatibel. Wer über diese Schnittstelle Wissensbasen aufgebaut hat, muss sie neu erzeugen. Das LoRA-Finetuning ist im README ausdrücklich auf Windows beschränkt, auf anderen Plattformen fällt dieser Teil weg. Und schließlich der unangenehmste Punkt: Windows Defender kann die Binärdatei als Schadsoftware einstufen. Das README bietet dafür zwei Wege an, den Download von v1.3.7_win.zip mit anschließendem automatischem Update oder das Hinzufügen des RWKV-Runner-Ordners als Ausnahme in den Windows-Sicherheitseinstellungen. Beides verlangt dem Anwender Vertrauen ab, das technisch nicht belegt wird.

Was RWKV-Runner nicht ist: Abgrenzung zu llama.cpp und Ollama

Der naheliegende Vergleich ist ein Inferenzserver für ein anderes Modellformat. llama.cpp und darauf aufbauende Werkzeuge wie Ollama laden GGUF-Gewichte und bringen ihre eigene Server- und Client-Schicht mit. Der Unterschied liegt nicht in der Geschwindigkeit, sondern in der Bindung: RWKV-Runner ist um RWKV herum gebaut, inklusive Modellkonvertierung, Download-Verwaltung und Remote-Modellprüfung, die im Funktionsumfang genannt werden. Für ein RWKV-Modell ist das ein Vorteil, weil die Konvertierung und das Laden bereits abgedeckt sind. Für alles andere ist es der falsche Weg. Das README beschreibt zwar, dass sich das Programm auch als Client für OpenAI ChatGPT, GPT-Playground, Ollama und weitere Dienste verwenden lässt, indem man API URL und API Key in den Einstellungen einträgt. Dann ist RWKV-Runner aber nur noch eine Oberfläche vor einem fremden Backend, und sein eigener Inferenzpfad bleibt ungenutzt. Wer bereits eine Ollama-Installation mit passenden Modellen betreibt, gewinnt durch den Wechsel nichts, solange das Modell nicht RWKV ist. Die Entscheidung hängt also am Modell, nicht am Werkzeug.

Pflegeaufwand, Update-Pfad und Lizenz

Das Projekt wird aktiv gepflegt. Die letzten Releases liegen bei v1.9.12 vom 7. Juli 2026, v1.9.11 vom 8. Mai 2026 und v1.9.10 vom 1. Februar 2026, der letzte Push datiert auf den 4. September 2026. Der Abstand zwischen den Veröffentlichungen liegt in dieser Reihe bei etwa zwei bis drei Monaten. Das Programm bringt laut Funktionsumfang automatische Updates mit, was den laufenden Pflegeaufwand auf der Anwendungsseite senkt. Auf der Serverseite bleibt der Aufwand bei der Umgebung: Python-Abhängigkeiten, GPU-Treiber und die Frage, ob der CUDA-Kernel nach einem Treiberwechsel noch sauber arbeitet. Die Lizenz ist MIT, angegeben im Repository und verlinkt über das LICENSE-Datei im Wurzelverzeichnis. Das erlaubt kommerzielle Nutzung und Änderungen, verlangt aber, dass Lizenz- und Urheberrechtshinweis in Weitergaben erhalten bleiben. Diese Einschätzung ist keine Rechtsberatung; wer das Programm in ein eigenes Produkt einbettet, sollte die Lizenzbedingungen selbst prüfen. Zu beachten ist außerdem, dass die MIT-Lizenz des Runners nichts über die Lizenz der heruntergeladenen Modellgewichte sagt. Beides sind getrennte Gegenstände, und die kommerzielle Nutzbarkeit des Modells ist unabhängig vom Werkzeug zu klären.

Redaktionelles Fazit

Sinnvoll ist RWKV-Runner für Anwender, die ein RWKV-Modell lokal oder auf einem eigenen Server betreiben und bestehende ChatGPT-Clients ohne Umbau weiterverwenden wollen, sowie für Teams, die Backend und Frontend getrennt deployen. Wer ausschließlich ein anderes Modellformat fährt oder eine verwaltete Inferenz-Infrastruktur braucht, sollte nicht darauf setzen. Vor dem Produktivbetrieb zu prüfen sind die tatsächliche Latenz des gewählten Modells auf der Zielhardware, die Obergrenze für max_tokens, die im Backend-Code unter backend-python/utils/rwkv.py gesetzt ist, sowie die Frage, ob der mitgelieferte CUDA-Kernel auf der vorhandenen GPU sauber läuft.

Offizielle Quellen

1. josStorer/RWKV-Runner on GitHub
2. License: MIT
3. Project website
4. README
5. Releases