Ce que l’on demande avant de l’installer.
Qu’est-ce que LM Warden ?
Un plan de contrôle autour de moteurs d’inférence, sur votre propre matériel : vLLM et llama.cpp sur un hôte Linux avec des GPU NVIDIA, ou MLX et llama.cpp dans une app bêta sur un Mac à puce Apple. Vous récupérez un modèle sur HuggingFace, le chargez sur votre propre GPU, créez une clé API et l’appelez via un point de terminaison /v1 compatible OpenAI. Une interface web permet de charger et décharger les modèles, de suivre les journaux des moteurs en direct, de discuter dans un espace de chat, de consulter les statistiques GPU et de jetons, et offre une page par clé API. Il ne rend pas les modèles plus rapides et ne modifie pas les moteurs : il ajoute ce qu’un moteur seul ne fournit pas.
Sur quels GPU et systèmes d’exploitation fonctionne-t-il ?
Linux et macOS. Sous Linux : des GPU NVIDIA sur un hôte x86_64. Le minimum est Turing (sm_75, la génération des RTX série 20) : l’image de base embarque CUDA 13, qui a abandonné Maxwell, Pascal et Volta ; une GTX 1080 Ti, une Titan X ou une V100 ne fonctionnera donc pas. De Turing à Blackwell, tout est pris en charge, y compris Ada, Hopper et la série RTX 50. Sous macOS : les Mac à puce Apple (M1 ou plus récent), via une app Mac distincte, en bêta : une app native de la barre des menus pour macOS 14 ou version ultérieure, qui exécute les modèles avec MLX et une version Metal de llama.cpp, sert la même API compatible OpenAI et affiche le même tableau de bord dans sa propre fenêtre, à télécharger sur lmwarden.com/download/mac (environ 110 Mo, avec un fichier SHA-256). Elle est signée ad hoc et non notarisée : au premier lancement, autorisez-la dans Réglages Système › Confidentialité et sécurité › Ouvrir quand même (sur macOS 14, clic droit › Ouvrir fonctionne aussi) ; par défaut, elle n’écoute que sur l’interface de bouclage, et elle ne se met pas à jour toute seule. Windows sera la prochaine plateforme ; nous y travaillons, sans date pour l’instant. ROCm, les GPU Intel et le CPU ne sont pas pris en charge dans cette version ; les GPU AMD Radeon et Intel sont sur la feuille de route, et l’ordre dépendra des retours que nous recevrons dans les GitHub Discussions du projet. Plusieurs GPU dans une même machine Linux sont pris en charge ; un modèle réparti sur plusieurs machines ne l’est pas.
Mon client OpenAI actuel fonctionnera-t-il avec ?
Oui. La passerelle sur /v1/* est compatible OpenAI : le SDK openai, LangChain, OpenWebUI et vos propres agents fonctionnent sans modification une fois base_url et la clé changés. GET /v1/models indique aussi le max_model_len de chaque modèle, pour qu’un client n’ait pas à deviner la fenêtre de contexte. Codex CLI, qui ne prend en charge que l’OpenAI Responses API, fonctionne aussi : POST /v1/responses est traduit en Chat Completions pour un modèle que vous avez chargé (sans état, et en local uniquement : les règles du routeur ne s’appliquent pas).
Puis-je l’utiliser avec Claude Code et garder mon compte Anthropic ?
Oui. Faites pointer ANTHROPIC_BASE_URL vers le warden, restez connecté à claude comme d’habitude, et placez la clé warden dans ANTHROPIC_CUSTOM_HEADERS sous la forme X-LMWarden-Key. Une règle associe un nom de modèle demandé par Claude Code, comme claude-haiku*, à un modèle chargé sur vos GPU ; tous les autres modèles, et tous les autres chemins /v1, sont transmis à Anthropic octet pour octet avec vos propres identifiants. Il faut Claude Code 2.1.227 ou version ultérieure ; la fonction est désactivée par défaut, et une clé doit avoir l’option « May relay to Anthropic » pour que quoi que ce soit soit transmis. Les clients plus anciens peuvent toujours utiliser le mode local uniquement.
Anthropic voit-il ma clé warden, ou le warden mes identifiants Anthropic ?
Anthropic ne voit jamais la clé warden : elle est transmise dans un en-tête distinct et retirée avant qu’une requête ne soit relayée. Le warden manipule bien vos identifiants Anthropic, car il doit les transférer, mais uniquement vers Anthropic. Ils ne sont jamais envoyés à un moteur ni journalisés, et rien d’une requête relayée n’est stocké ni affiché dans le God mode.
Quels moteurs d’inférence utilise-t-il ?
Sous Linux, vLLM v0.32.0 et llama.cpp b11719 dans leurs versions officielles, choisis par modèle et exécutés sans modification : pas d’image patchée, pas de fork, pas de monkeypatching. Choisir un fichier .gguf sélectionne llama.cpp, qui fait tenir de plus gros modèles sur de plus petites cartes grâce à la quantification GGUF et permet de continuer à exploiter des GPU plus anciens. TensorRT-LLM, SGLang et le runtime d’Ollama ne sont pas fournis ; la bêta Mac exécute les modèles avec MLX, son moteur par défaut, ou avec une version Metal de llama.cpp pour les fichiers .gguf, et ne propose pas vLLM.
Quelque chose quitte-t-il ma machine ?
Rien ne quitte l’hôte, sauf si vous activez le routeur Claude Code et donnez à une clé l’option « May relay to Anthropic ». Dans ce cas, les requêtes de cette clé pour des modèles Claude qu’aucune règle n’envoie vers vos GPU partent chez Anthropic, avec les propres identifiants Anthropic de l’utilisateur, et rien d’autre ne sort. Il n’y a ni compte, ni vérification de licence, ni outil d’analyse d’audience. Pour le reste, la pile ne contacte l’extérieur que lorsque vous le lui demandez : huggingface.co pour télécharger les poids (HF_HUB_OFFLINE=1 bloque même cela), Docker Hub quand vous ouvrez le sélecteur de version de moteur, et le registre des images de version, que docker load remplace dans une installation hors ligne ou isolée du réseau.
Les prompts et les réponses sont-ils stockés ?
Pas par défaut. L’historique des requêtes qui alimente les graphiques et la consommation par clé ne contient que des métadonnées et n’a aucune colonne pour le texte des prompts ou des complétions. Deux fonctions de diagnostic peuvent capturer le contenu, et toutes deux restent désactivées tant que vous ne les activez pas : le God mode (VW_GODMODE_ENABLED), une vue bornée, en mémoire, du trafic d’une clé, et le journal de contenu (VW_CONTENT_LOG_ENABLED), qui n’écrit sur disque que pour les identifiants de clé que vous indiquez.
Comment fonctionnent les clés API pour une équipe ?
Chaque application ou personne reçoit sa propre clé vw_ avec sa propre page. Fixez une priorité de P0 à P9 (une requête P9 en attente passe toujours avant une requête P8), suspendez une clé pour que ses clients reçoivent 403 token paused pendant que les requêtes en cours se terminent, ou renouvelez-la avec un délai de grâce pendant lequel l’ancien secret continue de fonctionner. Les requêtes, les jetons de prompt et les jetons de complétion sont comptés par clé et par IP de client, avec l’attente en file et la latence par clé. Les scripts, la CI et les agents qui pilotent l’API de contrôle utilisent des jetons admin vwa_ distincts au lieu du mot de passe administrateur.
Puis-je exécuter plusieurs modèles sur un GPU ?
Non. La règle « un modèle chargé par GPU » est vérifiée avant le démarrage de tout moteur. Vous pouvez charger des modèles différents sur différentes cartes du même hôte, et répartir un modèle sur plusieurs cartes avec le parallélisme de tenseurs de vLLM.
Que faut-il pour l’installer ?
Sous Linux, un hôte avec Docker, Docker Compose v2.24 ou version ultérieure, un GPU NVIDIA, le NVIDIA Container Toolkit et environ 40 Go libres là où Docker stocke ses images. Le programme d’installation vérifie l’hôte, vous laisse choisir les GPU, génère les secrets, télécharge les images de version et propose de démarrer la pile. Un assistant de premier lancement, dans le navigateur, demande ensuite les GPU à utiliser, un jeton HuggingFace et votre compte administrateur. Sur un Mac à puce Apple, il suffit de télécharger l’app bêta ; voir la section Mac.
Combien cela coûte-t-il ?
Rien. LM Warden est distribué sous licence Apache-2.0. C’est un logiciel que vous exécutez, pas une API hébergée : vous fournissez le matériel, le pilote, le disque et l’électricité, et une fois le matériel payé, une requête ne coûte que de l’électricité, pas des frais par jeton.