La plupart des agents AI utilisent un seul modèle pour tout. L'étape de planification, les appels d'outils (tool calls), la synthèse, la récupération d'erreurs. Cela fonctionne pour les démos. En production, c'est du gaspillage.
Une étape de planification qui nécessite un raisonnement approfondi n'a pas besoin du même modèle qu'une étape d'extraction JSON. Une tâche de génération de code a des exigences différentes d'une tâche de classification. Utiliser Claude Opus 4.6 (25 $/1M output tokens) pour formater une chaîne de date, c'est comme embaucher un architecte senior pour peindre un mur.
Voici comment construire des agents qui dirigent chaque étape vers le modèle optimal.
Si vous travaillez sur la couche API plutôt que sur la couche agent, lisez Agent-First API Design et Pourquoi les équipes passent des API de modèles directs à une API AI unifiée en complément de cette page. Les agents multi-modèles fonctionnent mieux lorsque la surface API sous-jacente est suffisamment stable pour échanger des modèles sans réécrire le code d'orchestration.
L'architecture d'un agent multi-modèles
Requête Utilisateur
│
▼
┌─────────────┐
│ Router │ ← Classifie la complexité de la tâche
│ (fast model) │
└──────┬──────┘
│
┌───┴───┐
▼ ▼
┌──────┐ ┌───────┐
│Simple│ │Complex│
│Model │ │Model │
└──┬───┘ └──┬────┘
│ │
▼ ▼
┌─────────────┐
│ Aggregator │ ← Combine les résultats
│ (fast model) │
└─────────────┘
Trois composants :
- Un router qui classifie les tâches entrantes par complexité
- Un pool de modèles adaptés aux différents types de tâches
- Un aggregator qui combine les résultats si nécessaire
En pratique, les agents en production ont généralement besoin de deux éléments supplémentaires :
- Une politique de fallback lorsque le modèle préféré échoue ou ralentit
- Une couche de telemetry qui enregistre le choix du modèle, la latence et le coût par étape
Sans ces deux éléments, un agent multi-modèles se transforme rapidement en une boîte noire au comportement imprévisible.
Implémentation avec l'OpenAI SDK
En utilisant une seule api_key via un aggregator, vous pouvez accéder à tous les modèles sans gérer plusieurs SDK :
from openai import OpenAI
client = OpenAI(
api_key="sk-lemon-xxx",
base_url="https://api.lemondata.cc/v1"
)
# Model pool with cost/capability tiers
MODELS = {
"router": "gpt-4.1-mini", # $0.40/1M in - fast classification
"simple": "gpt-4.1-mini", # $0.40/1M in - extraction, formatting
"reasoning": "claude-sonnet-4-6", # $3.00/1M in - planning, analysis
"complex": "gpt-4.1", # $2.00/1M in - code gen, multi-step
"budget": "deepseek-chat", # $0.28/1M in - bulk processing
}
def route_task(task: str) -> str:
"""Use a cheap model to classify task complexity."""
response = client.chat.completions.create(
model=MODELS["router"],
messages=[
{"role": "system", "content": """Classify this task into one category:
- simple: data extraction, formatting, translation
- reasoning: analysis, planning, comparison
- complex: code generation, multi-step problem solving
- budget: bulk processing, non-critical tasks
Reply with just the category name."""},
{"role": "user", "content": task}
],
max_tokens=10
)
category = response.choices[0].message.content.strip().lower()
return MODELS.get(category, MODELS["simple"])
def execute_task(task: str, context: str = "") -> str:
"""Route task to appropriate model and execute."""
model = route_task(task)
messages = []
if context:
messages.append({"role": "system", "content": context})
messages.append({"role": "user", "content": task})
response = client.chat.completions.create(
model=model,
messages=messages
)
return response.choices[0].message.content
Agent concret : Pipeline de revue de code
Voici un agent multi-modèles pratique qui examine les pull requests :
def review_pr(diff: str) -> dict:
"""Multi-model PR review pipeline."""
# Step 1: Classify changes (cheap model)
classification = client.chat.completions.create(
model="gpt-4.1-mini",
messages=[{
"role": "user",
"content": f"Classify these code changes: {diff[:2000]}\n"
"Categories: bugfix, feature, refactor, docs, test"
}],
max_tokens=20
).choices[0].message.content
# Step 2: Security scan (reasoning model)
security = client.chat.completions.create(
model="claude-sonnet-4-6",
messages=[{
"role": "system",
"content": "You are a security reviewer. Check for: "
"SQL injection, XSS, auth bypass, secrets in code, "
"unsafe deserialization. Be specific about line numbers."
}, {
"role": "user",
"content": f"Review this diff for security issues:\n{diff}"
}]
).choices[0].message.content
# Step 3: Code quality (general model)
quality = client.chat.completions.create(
model="gpt-4.1",
messages=[{
"role": "user",
"content": f"Review code quality: naming, structure, "
f"error handling, test coverage.\n{diff}"
}]
).choices[0].message.content
# Step 4: Summary (cheap model)
summary = client.chat.completions.create(
model="gpt-4.1-mini",
messages=[{
"role": "user",
"content": f"Summarize this PR review in 3 bullet points:\n"
f"Type: {classification}\n"
f"Security: {security[:500]}\n"
f"Quality: {quality[:500]}"
}]
).choices[0].message.content
return {
"classification": classification,
"security": security,
"quality": quality,
"summary": summary
}
Répartition des coûts pour une revue de PR typique (diff de 2K tokens) :
| Étape | Modèle | Tokens d'entrée | Coût |
|---|---|---|---|
| Classer | GPT-4.1-mini | ~2 100 | 0,0008 $ |
| Sécurité | Claude Sonnet 4.6 | ~2 500 | 0,0075 $ |
| Qualité | GPT-4.1 | ~2 500 | 0,0050 $ |
| Synthèse | GPT-4.1-mini | ~1 200 | 0,0005 $ |
| Total | ~0,014 $ |
Utiliser Claude Sonnet 4.6 pour les quatre étapes coûterait environ 0,028 $. L'approche multi-modèles réduit les coûts de 50 % tout en utilisant le modèle le plus performant là où c'est le plus important (la revue de sécurité).
Router par capacité, pas seulement par prix
De nombreuses équipes commencent le routing multi-modèles avec une règle simple : les tâches coûteuses vont aux modèles coûteux, les tâches bon marché aux modèles bon marché.
C'est une bonne première étape, mais ce n'est pas suffisant.
Une politique de routing plus robuste examine quatre dimensions :
- profondeur de raisonnement (reasoning)
- longueur du context window
- fiabilité de l'utilisation des outils (tool-use)
- sensibilité à la latence
Cela conduit à de meilleures règles :
- la planification et la décomposition vont vers un modèle à fort raisonnement
- l'extraction et le formatage vont vers un modèle rapide et économique
- la revue de code va vers le modèle ayant le meilleur comportement de détection de bugs
- l'analyse à l'échelle du repo va vers le modèle avec le plus grand context window
C'est la même raison pour laquelle la comparaison des modèles de code et la comparaison des prix devraient informer votre router plutôt que de rester dans un dossier de recherche séparé.
Intégration LangChain
from langchain_openai import ChatOpenAI
# Create model instances with different configs
fast = ChatOpenAI(
model="gpt-4.1-mini",
api_key="sk-lemon-xxx",
base_url="https://api.lemondata.cc/v1"
)
reasoning = ChatOpenAI(
model="claude-sonnet-4-6",
api_key="sk-lemon-xxx",
base_url="https://api.lemondata.cc/v1"
)
# Use in LangChain chains
from langchain_core.prompts import ChatPromptTemplate
classify_chain = ChatPromptTemplate.from_template(
"Classify: {input}"
) | fast
analyze_chain = ChatPromptTemplate.from_template(
"Analyze in depth: {input}"
) | reasoning
Quand utiliser des agents multi-modèles
Le routing multi-modèles ajoute de la complexité. Cela en vaut la peine quand :
- Votre agent gère des types de tâches diversifiés (pas seulement du chat)
- Les coûts mensuels d'API dépassent 100 $ (les économies deviennent significatives)
- Vous avez besoin des forces spécifiques d'un modèle (Claude pour le code, Gemini pour le long contexte, GPT pour la vitesse)
- La latence est critique pour certaines étapes mais pas pour d'autres
Pour les chatbots simples ou les agents à but unique, un seul modèle suffit. Le surcoût du routing n'est pas justifié lorsque chaque requête nécessite la même capacité.
Le point de bascule est généralement l'un des suivants :
- vous payez pour un raisonnement haut de gamme sur des tâches à faible valeur
- les pannes d'un seul fournisseur représentent désormais un risque commercial réel
- les besoins en contexte varient énormément au sein du workflow
- vous avez besoin d'étapes de revue / extraction / synthèse moins chères autour d'une étape centrale coûteuse
Si aucun de ces points n'est vrai, un modèle unique reste la bonne réponse.
Modes d'échec courants
Les systèmes multi-modèles échouent de manières prévisibles :
1. Le router est trop "intelligent"
Si le prompt du router devient un exercice de taxonomie géant, vous dépensez trop pour décider quoi faire. Gardez le router économique et simple.
2. Dérive des contrats de sortie
Un modèle renvoie du JSON propre, un autre renvoie de la prose avec un bloc JSON, et votre parser en aval casse. Utilisez des schémas explicites et une validation à chaque passage de relais.
3. Le fallback change la qualité silencieusement
Router vers un modèle moins cher lors d'une surcharge du fournisseur peut rendre l'agent instable si l'utilisateur voit un profil de qualité totalement différent. C'est pourquoi la stratégie de rate limiting doit faire partie de la conception, et non être une réflexion après coup.
4. Absence de rapport de coûts
Si vous n'enregistrez pas le choix du modèle, le coût et la latence par étape, vous ne pouvez pas savoir si la conception multi-modèles permet réellement d'économiser de l'argent.
Une boucle d'évaluation minimale
Vous n'avez pas besoin d'une plateforme d'évaluation géante pour exploiter un agent multi-modèles de manière responsable.
Commencez par une feuille de calcul ou une table de base de données par exécution :
- catégorie de tâche utilisateur
- décision du router
- modèle final utilisé par étape
- latence par étape
- coût total en tokens
- si le fallback a été déclenché
- si l'utilisateur a accepté la réponse
Cela vous donne suffisamment de signaux pour répondre aux questions importantes :
- Le router choisit-il le bon modèle coûteux assez souvent ?
- Quelle étape consomme la majeure partie du budget ?
- Les fallbacks sauvent-ils les exécutions ou cachent-ils simplement une instabilité ?
- Le chemin économique est-il suffisant pour les tâches répétitives ?
C'est aussi pourquoi une gateway unifiée aide. Lorsque l'utilisation des modèles est répartie sur de nombreux fournisseurs, il est plus difficile d'assembler un registre d'exécution comparable. Lorsque tout passe par une seule couche API, la charge d'instrumentation diminue.
Gardez l'architecture simple (boring)
Les meilleurs agents multi-modèles ne semblent pas exotiques. Ils semblent opérationnellement simples.
Cela signifie :
- une forme de requête stable dans votre couche d'orchestration
- un seul endroit pour définir les règles de routing
- un seul endroit pour inspecter le coût et la latence
- une seule politique de fallback par famille de tâches
- une seule source de vérité pour les allowlists de modèles
Si votre graphe d'agent semble ingénieux mais que vos opérateurs ne peuvent pas expliquer pourquoi une requête est allée vers un modèle plutôt qu'un autre, la conception n'est pas terminée.
Quand ne pas utiliser d'agent multi-modèles
Il existe également des cas clairs où la conception la plus simple l'emporte.
N'ajoutez pas de routing simplement parce que le catalogue de modèles est vaste.
Tenez-vous-en à un seul modèle quand :
- le produit effectue une tâche étroite de manière répétée
- les différences de qualité entre les modèles sont non pertinentes pour l'utilisateur
- votre trafic est trop faible pour que l'optimisation des coûts compte
- votre surface opérationnelle est déjà sous-instrumentée
- vous n'avez pas encore d'evals assez solides pour dire si le routing a aidé ou nui
Un seul modèle bien choisi avec de bons retries, une hygiène de prompt et une observabilité bat souvent un graphe multi-modèles tape-à-l'œil en lequel personne n'a confiance.
La bonne question n'est pas « pouvons-nous router ? » mais « le routing produit-il une meilleure qualité, un coût moindre ou un comportement d'échec plus sûr pour ce workflow ? »
Si la réponse est vague, gardez l'architecture simple jusqu'à ce que le workflow lui-même devienne plus diversifié.
Points clés à retenir
- Utilisez le modèle le moins cher qui gère bien chaque étape
- Réservez les modèles coûteux aux tâches qui en ont réellement besoin
- Les étapes de classification/routing doivent toujours utiliser le modèle le moins cher disponible
- Mesurez le coût réel par exécution d'agent, pas seulement le prix par token
- Un aggregator d'API avec une seule clé simplifie considérablement l'accès multi-modèles
Les agents multi-modèles ne sont pas intrinsèquement meilleurs. Ils sont meilleurs lorsque le workflow contient réellement différents types de travail.
Accédez à tous les modèles via une seule API : LemonData fournit plus de 300 modèles avec une seule api_key. Construisez des agents multi-modèles sans gérer plusieurs comptes de fournisseurs ni réinventer le routing pour chaque paire de fournisseurs.