RWKV-Runner : lancer un modèle RWKV sans écrire une ligne de Python

Le problème concret : installer RWKV est un travail de plomberie

Faire tourner un modèle RWKV sur sa propre machine implique normalement plusieurs étapes distinctes. Il faut récupérer les poids, convertir le format du modèle, installer les bonnes versions de PyTorch et des bibliothèques associées, puis écrire un script de chargement avant même de pouvoir poser une question. Le README de RWKV-Runner résume l'objectif du projet en une phrase : automatiser tout cela pour que l'utilisateur n'ait qu'un exécutable de quelques mégaoctets à lancer. La cible est donc claire. Il s'agit de développeurs qui veulent une instance RWKV locale pour bricoler une interface, tester des paramètres de génération ou brancher un client de chat existant, sans consacrer une soirée à la configuration de l'environnement Python. Le projet annonce aussi un outil de conversion de modèles intégré et un gestionnaire de téléchargement avec inspection des modèles distants, ce qui couvre la partie récupération des fichiers.

Séparation front-end et back-end : deux services, pas un monolithe

L'architecture décrite dans le README est explicitement découpée. Le dossier backend-python contient le service d'inférence, écrit en Python avec FastAPI. Le dossier frontend contient une application TypeScript compilée avec npm. Les deux peuvent tourner ensemble ou séparément. Le README précise qu'on peut déployer backend-python sur un serveur et n'utiliser le programme local que comme client, en renseignant l'adresse du serveur dans le champ API URL des paramètres. Cette séparation a une conséquence pratique : l'interface graphique n'est pas nécessaire pour utiliser le moteur. Une fois le modèle chargé, le service expose une documentation interactive sur http://127.0.0.1:8000/docs, ce qui permet d'inspecter les routes disponibles sans lire le code. Le chargement du modèle lui-même passe par une route dédiée, /switch-model, mentionnée dans l'exemple de déploiement. Autrement dit, démarrer le service ne charge pas un modèle : il faut un second appel pour indiquer lequel utiliser.

La compatibilité OpenAI comme argument de raccordement

Le point le plus intéressant du projet n'est pas l'interface graphique, c'est la compatibilité avec l'API OpenAI. Le README affirme que chaque client ChatGPT devient un client RWKV, à condition de renseigner l'API URL et l'API Key dans la page Settings. Le projet cite ChatGPT, GPT-Playground, Ollama et llmman parmi les clients concernés. Cette approche évite d'écrire un adaptateur pour chaque outil : on réutilise le format de requête déjà supporté par l'écosystème. Le README fournit d'ailleurs un exemple concret avec langchain, en instanciant OpenAIEmbeddings avec openai_api_base pointant vers http://127.0.0.1:8000 et une clé factice sk-. Un point de vigilance figure dans le même passage : à partir de la v1.4.0, la qualité de l'API embeddings a changé et les résultats ne sont plus compatibles avec les versions antérieures. Si une base de connaissances a été construite avec une version précédente, il faut la régénérer. C'est une rupture de compatibilité assumée, pas un détail.

Démarrage réel : les commandes du README

Le déploiement minimal tient en quelques lignes. On clone le dépôt avec git clone https://github.com/josStorer/RWKV-Runner, puis on lance python ./backend-python/main.py pour démarrer le service d'inférence. Pour compiler l'interface séparément, il faut se placer dans frontend, exécuter npm ci puis npm run build, revenir à la racine et lancer python ./backend-python/webui_server.py. Une variante existe : python ./backend-python/main.py --webui démarre front-end et back-end d'un seul coup. L'aide s'obtient avec python ./backend-python/main.py -h. Le README documente aussi un test de charge avec ApacheBench, en envoyant un corps JSON sur /chat/completions avec vingt requêtes concurrentes et cent requêtes au total. Côté configuration, deux éléments ressortent. Le noyau CUDA personnalisé est activé par défaut, décrit comme plus rapide et moins gourmand en VRAM ; en cas de sortie illisible, le README conseille de désactiver l'option Use Custom CUDA kernel to Accelerate dans la page Configs ou de mettre à jour le pilote GPU. Et pour basculer sur des cartes AMD ou Intel, il faut passer Strategy sur WebGPU dans la même page.

Les limites que le README reconnaît lui-même

Le projet est franc sur plusieurs points faibles. Le premier concerne l'exposition publique. Le README demande de limiter la taille des requêtes via une passerelle API pour éviter une consommation excessive de ressources provoquée par des prompts trop longs, et de plafonner max_tokens. Le fichier backend-python/utils/rwkv.py fixe une valeur par défaut de le=102400, ce que le README qualifie de potentiellement coûteux en ressources pour une réponse individuelle. En clair, l'outil n'est pas conçu pour être exposé tel quel sur Internet. Le deuxième point concerne Windows Defender, qui peut signaler l'exécutable comme un virus. La parade proposée est de télécharger une version ancienne, v1.3.7_win.zip, et de la laisser se mettre à jour, ou d'ajouter le dossier aux exclusions. C'est un contournement, pas une résolution. Le troisième point est la fonction de fine-tuning LoRA en un clic, réservée à Windows. Enfin, le réglage des paramètres d'inférence reste à la charge de l'utilisateur : le README suggère par exemple Temperature à 1 et Top_P à 0.3 pour la traduction, ce qui suppose de tâtonner par tâche.

Face à llama.cpp et Ollama : deux philosophies différentes

L'alternative la plus directe est Ollama, que le README cite lui-même comme client compatible. La différence tient au périmètre. Ollama se concentre sur la gestion et le service de modèles, avec une interface en ligne de commande et une API propre, sans interface graphique intégrée ni outil de conversion visuel. RWKV-Runner ajoute une couche d'interface complète : chat, complétion, composition, presets de conversation, pièces jointes, entrée MIDI matérielle et édition de pistes. Il vise aussi un modèle précis, RWKV, là où Ollama reste agnostique. Un projet comme llama.cpp se situe encore ailleurs : c'est une bibliothèque d'inférence que l'on intègre, pas une application prête à lancer. Le choix dépend donc de ce qu'on veut faire. Pour servir un modèle en production derrière une API maîtrisée, RWKV-Runner n'est pas l'outil naturel. Pour explorer RWKV sur un poste de travail avec une interface graphique et sans toucher à Python, il correspond à ce que le README promet.

Maintenance, licence et coût de mise à jour

Le projet est distribué sous licence MIT, ce qui autorise l'usage commercial, la modification et la redistribution, à condition de conserver l'avis de licence. Le README ne mentionne aucune restriction supplémentaire, mais il ne constitue pas un avis juridique et une vérification du fichier LICENSE reste nécessaire pour un usage en entreprise. Sur la maintenance, les versions publiées montrent un rythme irrégulier : v1.9.12 en juillet 2026, v1.9.11 en mai 2026, v1.9.10 en février 2026. Le dépôt n'est pas archivé et le projet annonce des mises à jour automatiques. Cette automatisation a un revers : la rupture de compatibilité de l'API embeddings introduite en v1.4.0 illustre qu'une montée de version peut invalider des données dérivées. Toute base vectorielle construite avec une version antérieure doit être régénérée. Le coût de mise à jour n'est donc pas nul pour les usages qui s'appuient sur les embeddings, alors qu'il reste faible pour un simple usage de chat.

Conclusion éditoriale

RWKV-Runner convient à ceux qui veulent faire tourner un modèle RWKV sur une machine locale sans gérer Python, pip et les dépendances CUDA, ou qui souhaitent exposer une API compatible OpenAI à des clients existants. Il ne convient pas à ceux qui ont besoin d'un déploiement multi-utilisateurs durci : le README demande explicitement de limiter la taille des requêtes et le paramètre max_tokens via une passerelle. Avant d'adopter, vérifier la version de Python requise par backend-python/main.py et la compatibilité de votre pilote GPU avec le noyau CUDA personnalisé activé par défaut dans les Configs.

Sources officielles

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