Il y a six mois, notre facture mensuelle pour les modèles de langage hébergés était de ces chiffres qui faisaient poser des questions à la finance. Aujourd'hui, elle en représente un dixième, et les modèles sont plus rapides sur notre matériel qu'ils ne l'ont jamais été via l'Internet public. Nous n'avons négocié aucune remise. Nous ne sommes pas passés à une offre moins chère. Nous avons ramené les modèles à la maison.
Le changement a commencé comme une expérience et s'est transformé en une stack. Un petit ensemble, bien choisi, de modèles à poids ouverts exécuté sur une seule machine grand public en périphérie de notre réseau traite désormais l'essentiel de notre trafic d'inférence. Les modèles cloud restent dans la boucle, mais uniquement pour les tâches qui en ont réellement besoin. Tout le reste tourne en local, et les économies se répercutent directement sur le résultat net.
La première leçon a été que plus gros n'est pas mieux pour chaque prompt. Un modèle à 70 milliards de paramètres est impressionnant, mais pour les tâches de résumé, de classification et d'extraction structurée courantes, il est largement surdimensionné. Nous avons analysé le trafic réel et constaté qu'environ sept requêtes sur dix étaient courantes. Un modèle affiné à 7 milliards de paramètres les a prises en charge pour une fraction de la latence et un coût par token nul. Router par tâche, et non par habitude, a été le déclic.
La deuxième leçon concernait le matériel. Nous avions supposé qu'il nous faudrait un rack d'accélérateurs. En pratique, un seul GPU moderne avec suffisamment de VRAM pour héfiler confortablement deux ou trois modèles quantifiés en même temps a couvert notre charge de pointe. La quantification en poids sur quatre bits nous a coûté une baisse de qualité mesurable mais acceptable et nous a rendu d'énormes quantités de mémoire et de débit. Pour la longue traîne des tâches de faible priorité, un repli purement CPU avec un modèle plus petit a maintenu le système réactif lorsque le GPU était occupé.
La troisième leçon concernait la mise en cache. Les coûts en tokens s'accumulent lorsqu'on réévalue la même fenêtre de contexte encore et encore. Nous avons ajouté un cache sémantique devant la couche d'inférence afin que les prompts quasi identiques renvoient une réponse stockée sans jamais solliciter le modèle. Combiné à un templating de prompts qui supprime l'historique inutile, le taux de réussite du cache est monté au-delà de quarante pour cent en quelques semaines.
La quatrième leçon concernait l'observabilité. Sans tableaux de bord de latence par modèle, de coût par million de tokens et de contrôles qualité ponctuels, l'optimisation relève du tâtonnement. Nous avons instrumenté chaque appel afin de voir exactement quelles routes étaient rentables et lesquelles brûlaient discrètement du budget.
Si vous fixez une facture de modèles qui ne correspond plus à la valeur que vous en tirez, le chemin est simple. Profilez ce que vous envoyez réellement, dimensionnez le modèle à la tâche, quantifiez de manière agressive, mettez en cache les doublons et mesurez sans relâche. Le cloud reste pour les cas difficiles. Tout le reste peut tourner sur votre propre bureau.
Vous êtes curieux de savoir à quoi ressemblerait votre trafic routé de cette manière ? Répondez avec vos trois principaux cas d'usage de modèles et nous partagerons la répartition de routage par laquelle nous commencerions.