Architecture multi-modèles : les frontier models pour le raisonnement, les petits modèles pour tout le reste

Pendant nos premiers mois en production, chaque appel LLM du produit passait par le modèle le plus capable disponible. Conversation de l'agent ? Frontier model. Générer un titre d'une ligne pour un fil de discussion ? Le même frontier model. Classifier si une image uploadée était un logo ? Encore le frontier model.

Ça marchait, et c'est précisément le problème. Rien ne vous force à corriger une architecture qui fonctionne, jusqu'à ce que vous regardiez la facture, ou jusqu'à ce que les plaintes sur la latency arrivent pour des fonctionnalités censées sembler instantanées. Nous avons regardé les deux. La correction n'était pas "utilisez un modèle moins cher". C'était accepter que le choix du modèle est une décision d'architecture, la même famille de décision que choisir entre Postgres et une queue.

Détails produit anonymisés. Patterns d'ingénierie réels.

L'audit de la charge de travail

Avant de changer quoi que ce soit, nous avons listé chaque endroit où le produit appelle un modèle et les avons triés selon ce que l'appel exige réellement. Le pattern qui en a émergé :

Tier 1, orchestration et raisonnement. La conversation de l'agent elle-même : comprendre l'intention, planifier un travail en plusieurs étapes, choisir des outils, composer du SQL, gérer l'ambiguïté. Faible volume (une conversation à la fois par utilisateur), enjeux les plus élevés, besoin réel d'une capacité de niveau frontier. Quand l'orchestrateur choisit le mauvais outil, tout ce qui suit n'est que déchet.

Tier 2, génération bornée. Produire un récit de performance pour un dashboard, rédiger des variantes de texte publicitaire à partir d'un brand kit, résumer la semaine d'une campagne. Des tâches bien cadrées, avec des entrées claires et une forme de sortie définie. Un modèle de tier intermédiaire les exécute de façon indiscernable du frontier model (nous l'avons vérifié par des comparaisons à l'aveugle sur notre eval set, pas au feeling).

Tier 3, micro-tâches à haute fréquence. Génération de titres, classification, extraction de champs structurés, vérifications de pertinence oui/non, routing. Volume énorme, enjeux individuels minuscules, sensibles à la latency. Petits modèles rapides. Certains de ces appels ont fini par ne plus être des appels LLM du tout : une regex ou une table de correspondance en a remplacé deux, ce qui est une leçon en soi.

La distribution m'a surpris : en nombre d'appels, le Tier 3 représentait l'écrasante majorité de notre trafic. En coût, avant le changement, les conversations Tier 1 et les micro-tâches Tier 3 étaient des lignes comparables sur la facture. Nous payions des prix frontier pour un travail qu'un modèle à une fraction du coût fait à l'identique.

À quoi ressemble réellement le routing

Rien d'exotique. Un model registry associe chaque task type (pas chaque site d'appel) à une configuration de modèle : provider, model, fallback, max tokens, temperature. Le code déclare "ceci est une tâche narrative_generation" et le registry décide ce qui l'exécute.

Deux choix de conception se sont remboursés à de multiples reprises :

Centraliser la correspondance. Quand les décisions tâche-vers-modèle vivent dans un seul fichier au lieu d'être éparpillées sur les sites d'appel, changer un tier après la sortie d'un nouveau modèle est une modification d'une ligne plus un run d'eval. Nous avons re-tiéré des tâches quatre ou cinq fois au fil de l'évolution du paysage des modèles, et le registry a rendu chaque migration ennuyeuse, ce qui est le plus beau compliment qu'une infrastructure puisse recevoir.

Une eval par tâche, pas par modèle. Chaque task type a son propre petit golden set. "Le modèle X est-il bon ?" n'a pas de réponse. "Le modèle X produit-il des récits acceptables sur nos 40 cas de récit ?" est une question de vingt minutes. Rétrograder une tâche vers un tier moins cher sans son eval, c'est parier ; avec elle, c'est de la maintenance de routine.

Il y a aussi une subtilité côté utilisateur : pour l'agent principal, nous exposons un sélecteur de modèle. Certains utilisateurs veulent une capacité maximale, d'autres veulent de la vitesse. Cela ne fonctionne que parce que l'architecture traite déjà le modèle comme un paramètre plutôt que comme une constante.

L'astuce async qui a compté plus que le routing

Un seul changement a amélioré la performance perçue plus que tous les remplacements de modèles réunis : sortir la génération du chemin de la requête.

Les récits du dashboard se généraient autrefois au chargement de la page, et l'utilisateur fixait un effet de scintillement pendant qu'un modèle rédigeait trois phrases pertinentes. Désormais les récits se génèrent en async quand de nouvelles données arrivent, sont mis en cache, et le dashboard s'affiche instantanément avec le texte pré-calculé. La régénération se fait en arrière-plan lors des changements de données.

Le principe général : un appel LLM dans un chemin utilisateur synchrone doit se justifier. La plupart des générations sont assez prévisibles pour être faites à l'avance. Les utilisateurs ne subissent pas la latency de votre modèle ; ils subissent la latency de votre architecture.

Les coûts honnêtes de l'approche

Le multi-modèles n'est pas gratuit. Vous maintenez des variantes de prompt par tier, parce qu'un prompt réglé pour un frontier model sous-performe souvent tel quel sur un petit modèle : les petits modèles veulent une structure plus explicite et moins d'étapes implicites. Votre surface d'eval se multiplie. La logique de fallback (panne de provider, rate limits) doit être testée par tier. Et il y a une tentation constante de sur-concevoir le routing pour des appels qui coûtent des fractions de centime, ce qui est précisément pourquoi l'audit compte, pour optimiser les lignes qui apparaissent sur la facture.

Pour nous le compromis en valait clairement la peine : environ 60-70% de réduction des dépenses d'inference à qualité de sortie égale (selon les evals), et les fonctionnalités Tier 3 sont passées de nettement poussives à effectivement instantanées.

Ce que je me dirais au départ

Commencez par l'audit, pas par le router. Une après-midi à lister chaque appel de modèle en se demandant "qu'est-ce que cela exige vraiment ?" vous dit si vous avez un problème multi-modèles ou simplement deux endpoints coûteux à corriger.

Et construisez les eval sets avant la migration, pas après. Toute l'approche repose sur la capacité à dire "le modèle bon marché est suffisant ici" avec des preuves. Sans cela, le tiering n'est que de la réduction de coûts avec des étapes en plus, et la première régression de qualité renverra tout vers le frontier model, cette fois avec des cicatrices organisationnelles en prime.