Une passerelle pour tous vos modèles, et trois façons dont un modèle local gèle vos agents

Dès que vous faites tourner plus d'un modèle, chaque outil pose les mêmes questions : quelle adresse, quel nom, que se passe-t-il quand ce modèle n'est pas chargé. Placez une passerelle devant eux, un proxy compatible OpenAI comme LiteLLM, et les réponses vivent à un seul endroit. Puis apprenez les trois réglages qui peuvent faire passer un modèle en parfaite santé pour mort aux yeux de vos agents.

Un peu d'histoire

Quand l'API de discussion d'OpenAI est devenue le standard de fait en 2023, chaque serveur local s'est mis à l'imiter : llama.cpp, Ollama, vLLM. Une passerelle comme LiteLLM, sortie cette année-là, a retourné l'idée : une seule adresse qui parle aux outils les formats d'OpenAI et d'Anthropic, et envoie chaque requête au modèle, local ou hébergé, qui se trouve derrière un nom.

1. Une adresse

Agents, apps, téléphone, Home Assistant : chaque client parle à la passerelle, jamais directement à un serveur de modèle. Gardez la passerelle sur votre réseau privé (Homelab 6). Quand un modèle passe d'une carte à l'autre, aucun client ne change quoi que ce soit.

2. Des noms qui ne mentent jamais

Nous avions commencé avec des noms de rôle sympathiques (« rédacteur », « lecteur ») et des chaînes de repli : si le modèle préféré était arrêté, un autre répondait sous le même nom. Ça avait l'air robuste et rendait tout illisible : une comparaison de qualité entre deux « rédacteurs » comparait deux modèles différents. Désormais :

• le nom du modèle vient d'un seul endroit, son fichier de poids, et tous les autres noms en sont dérivés ;
• la configuration de la passerelle est générée depuis la liste des modèles que les cartes servent vraiment, jamais éditée à la main ;
• un nom dont le modèle n'est pas chargé échoue ; il n'en remplace jamais un autre en silence.

« L'eau change avec les fleurs, mais le vase s'appelle toujours 9B. » Un nom qui encode un rôle ment le jour où vous changez le modèle derrière.

3. Trois façons dont un modèle en bonne santé gèle vos agents

Une nuit, notre nœud était sain, le modèle chargé, le conteneur se déclarait en bonne santé, et une requête de dix octets expirait au bout d'une minute. Trois causes, empilées, toutes mesurées :

1. Un seul emplacement pour tout le monde. Avec --parallel 1, le serveur traite une requête à la fois. Un agent de code demandait 32 000 jetons par défaut ; à 12 jetons par seconde, ce sont 35 minutes pendant lesquelles personne d'autre n'obtient de réponse. Plafonnez max_tokens pour les agents, ou donnez plus d'emplacements au serveur.
2. La réflexion sur un budget minuscule. La même question avec la réflexion activée et un budget de 16 jetons rendait une réponse vide ; réflexion coupée, « Prêt » en 3 jetons. Coupez la réflexion pour les agents qui appellent des outils ; gardez-la là où vous lisez vous-même la réponse.
3. Un micro-batch trop petit. -ub 128 faisait lire les prompts à 21,9 jetons par seconde. Le harnais d'un agent pèse environ 8 000 jetons : six minutes avant le premier mot. L'agent expirait, réessayait, et chaque nouvelle tentative relisait le prompt. Mesurez la vitesse de lecture du prompt, pas seulement celle de génération.

Lisez les compteurs du serveur lui-même avant d'accuser le réseau : /slots de llama.cpp montrait la requête qui tenait l'unique emplacement, et /metrics celles qui attendaient.

Sources

• LiteLLM, official repository

Utile ? Dites-nous ce qu'il faut mesurer ensuite.