Il y a six mois, notre facture mensuelle pour des modèles de langage hébergés était du genre à faire poser des questions à la finance. Aujourd’hui, elle ne représente plus qu’un dixième de ce montant, et les modèles sont plus rapides sur notre matériel qu’ils ne l’ont jamais été sur l’internet public. Nous n’avons pas négocié de remise. Nous ne sommes pas passés à une offre moins chère. Nous avons rapatrié les modèles.
Le changement a commencé comme une expérience et s’est transformé en une pile. Un petit ensemble de modèles open-weight, soigneusement choisis et exécutés sur une seule machine grand public en périphérie de notre réseau, prend désormais en charge la majeure partie de notre trafic d’inférence. Les modèles cloud restent dans la boucle, mais uniquement pour les tâches qui en ont vraiment besoin. Tout le reste s’exécute localement, et les économies se répercutent directement sur le résultat net.
La première leçon a été que plus grand n’est pas meilleur pour chaque prompt. Un modèle de 70 milliards de paramètres est impressionnant, mais pour le résumé courant, la classification et l’extraction structurée, il est largement surdimensionné. Nous avons analysé le trafic réel et constaté qu’environ sept requêtes sur dix étaient routinières. Un modèle affiné de 7 milliards de paramètres les gérait avec une latence bien moindre et sans coût par jeton. Le véritable déclic a été d’orienter les requêtes par tâche, et non par habitude.
La deuxième leçon concernait le matériel. Nous pensions avoir besoin d’une rangée d’accélérateurs. En pratique, un seul GPU moderne avec suffisamment de VRAM pour héberger confortablement deux ou trois modèles quantifiés à la fois a couvert notre charge de pointe. La quantification en poids sur quatre bits nous a coûté une baisse de qualité mesurable mais acceptable, tout en nous rendant d’énormes capacités de mémoire et de débit. Pour la longue traîne des tâches peu prioritaires, un mode de secours uniquement CPU avec un modèle plus petit a permis de maintenir la réactivité du système lorsque le GPU était occupé.
La troisième leçon portait sur la mise en cache. Les coûts en jetons se cumulent lorsque vous réévaluez encore et encore la même fenêtre de contexte. Nous avons ajouté un cache sémantique en amont de la couche d’inférence afin que les prompts quasi identiques renvoient une réponse enregistrée sans jamais solliciter le modèle. Combiné à un gabarit de prompt qui supprime l’historique inutile, le taux de réussite du cache a dépassé quarante pour cent en quelques semaines.
La quatrième leçon concernait l’observabilité. Sans tableaux de bord par modèle sur la latence, le coût par million de jetons et les contrôles ponctuels de qualité, l’optimisation n’est qu’un coup de dés. Nous avons instrumenté chaque appel afin de voir exactement quelles routes étaient rentables et lesquelles brûlaient discrètement le budget.
Si vous fixez une facture de modèle qui ne correspond plus à la valeur que vous en tirez, la voie à suivre est simple. Analysez ce que vous envoyez réellement, adaptez la taille du modèle à la tâche, quantifiez agressivement, mettez en cache les doublons et mesurez sans relâche. Le cloud reste là pour les cas difficiles. Tout le reste peut tourner sur votre propre bureau.
Curieux de voir à quoi ressemblerait votre trafic s’il était acheminé ainsi ? Répondez avec vos trois principaux cas d’usage des modèles et nous partagerons la répartition de routage par laquelle nous commencerions.