DanLevy.net

N'épousez pas votre modèle

Le routage LLM, tellement à la mode

La plupart des équipes techniques choisissent un modèle de langage et s’y tiennent. Un fournisseur, un modèle, toutes les tâches. C’est comme embaucher une seule personne pour coder, rédiger vos textes et faire vos impôts parce qu’elle était bonne lors du premier entretien.

À tout moment, un modèle est meilleur pour le code, un autre pour les contextes longs et désordonnés, et un autre est le cheval de trait le plus ennuyeux et le moins cher pour la classification. Les noms changent. La forme du problème, non. Traiter un modèle comme s’il excellait dans tout signifie que vous payez trop cher pour des tâches simples, ou que vous obtenez des résultats médiocres sur des tâches spécialisées.

J’ai vu une équipe brûler des milliers de dollars en faisant passer de l’analyse de sentiment par un modèle à 30$ le million de tokens alors qu’un modèle à 0,50$ aurait fait le travail tout aussi bien. Du simple formatage JSON, des tâches de classification basiques, tout passait par leur fournisseur premium. La seule chose qui chauffait, c’était leur facture AWS.

Il y a une meilleure façon, et ce n’est pas particulièrement compliqué.

Délégation plutôt que dévotion

Et si vous pouviez router les requêtes vers le modèle réellement le mieux adapté à cette tâche spécifique ? Utilisez votre modèle puissant et coûteux pour les choses difficiles, mais faites descendre l’analyse et le formatage simples vers quelque chose de moins cher. Obtenez les avantages de plusieurs fournisseurs sans avoir à les gérer manuellement dans votre base de code.

Mastra vous permet de construire exactement ce genre de système. Vous configurez des agents spécialisés pour différents types de travail, puis créez un agent routeur qui détermine quel spécialiste doit traiter chaque requête. Les identifiants de modèles ci-dessous sont des exemples, pas un classement. Remplacez-les par les modèles actuels qui gagnent vos évaluations et correspondent à votre budget.

Considérez-le comme ceci : vous avez trois spécialistes dans votre équipe.

./src/mastra/index.ts
import { Mastra } from '@mastra/core';
import { Agent } from '@mastra/core/agent';
import { openai } from '@ai-sdk/openai';
import { anthropic } from '@ai-sdk/anthropic';
import { google } from '@ai-sdk/google';
export const claudeAgent = new Agent({
id: 'claude-agent',
instructions: 'You are an expert engineer. Write bugs? You are fired.',
model: anthropic(process.env.CODE_MODEL ?? 'claude-sonnet-4-5'),
});
export const geminiAgent = new Agent({
id: 'gemini-agent',
instructions: 'You are a creative writer. Be weird.',
model: google(process.env.LONG_CONTEXT_MODEL ?? 'gemini-3-pro-preview'),
});
export const gptAgent = new Agent({
id: 'gpt-agent',
instructions: 'You are a helpful assistant. Be boring.',
model: openai(process.env.GENERAL_MODEL ?? 'gpt-5.2'),
});

Chacun a un rôle. Votre agent de code devrait être le modèle qui réussit vos évaluations de codage spécifiques au dépôt. Votre agent long-contexte devrait être celui qui survit à vos documents réels sans transformer le milieu en soupe. Votre agent général devrait être bon marché, fiable et ennuyeux dans le meilleur sens possible.

C’est là que ça devient intéressant. Vous ajoutez un routeur qui agit comme un proxy intelligent :

export const routerAgent = new Agent({
id: 'router-agent',
name: 'The Boss',
instructions: `You are an intelligent router.
- Coding -> Claude
- Poetry -> Gemini
- Facts -> GPT
Do not do the work yourself. Delegate.`,
model: openai(process.env.ROUTER_MODEL ?? 'gpt-5-mini'), // Use a cheap model for routing!
agents: {
claudeAgent,
geminiAgent,
gptAgent,
},
});
export const mastra = new Mastra({
agents: { routerAgent, claudeAgent, geminiAgent, gptAgent },
});

Le routeur lui-même tourne sur un modèle léger car il ne fait que prendre des décisions sur où envoyer le trafic. Vous ne payez pas des tarifs premium pour déterminer quel autre modèle premium utiliser. Mesurez cela aussi ; un mauvais routeur transforme silencieusement les économies en mauvais aiguillages.

Quand quelqu’un demande une implémentation de tri à bulles, le routeur reconnaît qu’il s’agit de travail de code et le transmet à votre spécialiste du code. Un prompt d’écriture créative ? Ça va au modèle que vous avez choisi pour la voix et l’amplitude. Une question factuelle sur un événement historique ? Routez-la vers l’agent général, idéalement avec une recherche documentaire quand la fraîcheur ou la citation importe.

Les avantages concrets

L’efficacité des coûts importe plus que vous ne le pensez. Un petit modèle de routage qui prend des décisions de délégation coûte une fraction du prix qu’il faudrait pour faire passer chaque requête par votre fournisseur le plus cher. Avec le temps, surtout à l’échelle, cela représente de l’argent réel. Vous ne payez pour l’intelligence lourde que lorsque vous en avez réellement besoin.

La qualité s’améliore quand vous assortissez les modèles aux tâches. Le gagnant change chaque mois, selon la tâche et la forme du prompt. C’est pourquoi la couche de routage doit dépendre de vos évaluations, pas du modèle qui gagnait sur Twitter la semaine où vous avez écrit l’intégration.

La résilience devient un avantage secondaire. Quand OpenAI a l’une de ses pannes périodiques (et ça arrive), votre routeur peut rediriger le trafic vers d’autres fournisseurs. Vous n’êtes pas coincé à attendre qu’une API spécifique revienne en ligne.

Il ne s’agit pas d’être malin pour le plaisir. Il s’agit de construire des systèmes qui ont du sens à la fois financièrement et techniquement. Vous n’utiliseriez pas le même marteau pour chaque tâche de construction, et vous ne devriez probablement pas utiliser le même modèle de langage pour chaque tâche d’IA non plus.

La beauté de cette approche est que votre code applicatif ne change pas. Vous appelez toujours simplement votre agent routeur. La complexité de décider quel modèle utiliser pour quelle tâche vit à un seul endroit, configurée une fois, plutôt que dispersée dans toute votre base de code dans un tas de logique conditionnelle.

Ressources

Lire la série

  1. Routage LLM (Cet article)
  2. Sécurité & garde-fous
  3. Intégrations MCP & outils
  4. Workflows & mémoire