Créer des agents IA avec plusieurs modèles : un guide d'architecture pratique

La plupart des agents IA s'appuient sur un seul modèle pour gérer chaque phase d'exécution. L'étape de planification, les appels d'outils, l'extraction de données, la synthèse et la gestion des erreurs passent tous par le même LLM. Bien que cette approche soit simple pour les prototypes initiaux, elle introduit des inefficacités significatives dans les environnements de production.

Une étape de planification nécessitant un raisonnement approfondi ne requiert pas le même modèle qu'une étape d'extraction JSON basique. Une tâche de génération de code a des exigences différentes d'une tâche de classification. Utiliser un modèle de raisonnement de haut niveau comme Claude Fable 5 ou Claude Opus 4.8 pour formater une chaîne de date est une mauvaise allocation coûteuse des ressources.

Construire des agents IA avec plusieurs modèles vous permet d'acheminer chaque étape d'un flux de travail vers le modèle le mieux adapté à cette tâche spécifique. Ce guide explore comment concevoir, implémenter et gérer ces architectures multi-modèles.

Si vous travaillez sur la couche API plutôt que sur la couche d'orchestration d'agents, consultez Agent-First API Design et Why Teams Switch from Direct Model APIs to a Unified AI API en complément de ce guide. Les agents multi-modèles fonctionnent de manière plus fiable lorsque la surface API sous-jacente est suffisamment stable pour permettre de changer de modèle sans réécrire le code d'orchestration.

:::info

Points clés à retenir

1. Adapter le modèle à la complexité de la tâche : utilisez des modèles petits et rapides pour le routage, l'extraction et le formatage, en réservant les modèles de raisonnement plus larges à la planification et à l'analyse complexe.
2. Standardiser les schémas : implémentez une validation stricte des sorties (comme Pydantic) à chaque transfert pour éviter la dérive des contrats lors du changement de fournisseur de modèle.
3. Concevoir pour les replis (fallbacks) : construisez des chemins de repli automatisés pour gérer les limites de débit, les pannes de fournisseur ou les pics de latence sans perturber le flux de travail de l'agent.
4. Centraliser la télémétrie : suivez la latence, le nombre de tokens en entrée/sortie et le coût par étape pour optimiser en continu votre logique de routage. :::

---

L'architecture d'agent multi-modèle

Une architecture d'agent multi-modèle distribue les tâches entre des modèles spécialisés en fonction des exigences de complexité, de coût et de latence.

Requête utilisateur
    │
    ▼
┌─────────────┐
│   Routeur    │  ← Classifie la complexité de la tâche
│ (modèle rapide)│
└──────┬──────┘
       │
   ┌───┴───┐
   ▼       ▼
┌──────┐ ┌──────┐
│Modèle│ │Modèle│
│Simple│ │Complexe│
└──┬───┘ └──┬───┘
   │        │
   ▼        ▼
┌─────────────┐
│  Agrégateur  │  ← Combine les résultats
│ (modèle rapide)│
└─────────────┘

L'architecture de base se compose de cinq composants principaux :

1. Le Routeur : un modèle rapide et peu coûteux qui classifie les tâches entrantes par complexité et intention.
2. Le Pool de modèles : une collection de modèles adaptés à différents types de tâches (comme le raisonnement, l'extraction ou la génération de code).
3. L'Agrégateur : un modèle rapide qui combine les résultats des étapes parallèles en une réponse finale.
4. La Politique de repli (Fallback) : des règles qui dictent quel modèle utiliser si le choix principal échoue, expire ou rencontre des limites de débit.
5. La Couche de télémétrie : un système de journalisation qui enregistre les choix de modèles, la latence et les coûts exacts en tokens par étape.

Sans politiques de repli et télémétrie, un agent multi-modèle peut devenir difficile à déboguer, avec des profils de latence et de coût imprévisibles.

---

Implémentation avec l'OpenAI SDK

L'utilisation d'une passerelle API unifiée vous permet d'accéder à des modèles de différents fournisseurs en utilisant un seul SDK et une seule clé API. Cela simplifie le changement de modèle et le routage.

L'exemple suivant démontre une implémentation de routage de base. La disponibilité et la tarification des modèles doivent être vérifiées sur le répertoire de modèles TokenLab.

from openai import OpenAI

client = OpenAI(
    api_key="sk-tokenlab-xxx",
    base_url="https://api.tokenlab.sh/v1"
)

# Pool de modèles avec niveaux de coût et de capacité
MODELS = {
    "router": "deepseek-v4-flash",        # Classification rapide
    "simple": "deepseek-v4-flash",        # Extraction, formatage
    "reasoning": "claude-sonnet-5",       # Planification, analyse
    "complex": "gpt-5.5",                 # Génération de code, logique complexe
    "budget": "deepseek-v4-flash",        # Traitement en masse
}

def route_task(task: str) -> str:
    """Utiliser un modèle à moindre coût pour classifier la complexité de la tâche."""
    response = client.chat.completions.create(
        model=MODELS["router"],
        messages=[
            {"role": "system", "content": """Classifiez cette tâche dans une seule catégorie :
- simple : extraction de données, formatage, traduction
- reasoning : analyse, planification, comparaison
- complex : génération de code, résolution de problèmes multi-étapes
- budget : traitement en masse, tâches non critiques
Répondez uniquement par le nom de la catégorie en minuscules."""},
            {"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:
    """Acheminer la tâche vers le modèle sélectionné et l'exécuter."""
    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 en conditions réelles : Pipeline de revue de code

Pour constater l'impact pratique de la construction d'agents IA avec plusieurs modèles, considérons un pipeline conçu pour examiner les pull requests. Ce flux de travail décompose la revue en étapes spécialisées plutôt que d'envoyer l'intégralité du diff de code à un seul modèle coûteux.

def review_pr(diff: str) -> dict:
    """Pipeline de revue de PR multi-modèle."""

    # Étape 1 : Classifier les changements en utilisant un modèle rapide et peu coûteux
    classification = client.chat.completions.create(
        model="deepseek-v4-flash",
        messages=[{
            "role": "user",
            "content": f"Classifiez ces changements de code : {diff[:2000]}\n"
                       "Catégories : bugfix, feature, refactor, docs, test"
        }],
        max_tokens=20
    ).choices[0].message.content

    # Étape 2 : Effectuer une analyse de sécurité en utilisant un modèle de raisonnement puissant
    security = client.chat.completions.create(
        model="claude-sonnet-5",
        messages=[{
            "role": "system",
            "content": "Vous êtes un réviseur de sécurité. Vérifiez : "
                       "injection SQL, XSS, contournement d'auth, secrets dans le code, "
                       "désérialisation non sécurisée. Soyez précis sur les numéros de ligne."
        }, {
            "role": "user",
            "content": f"Examinez ce diff pour des problèmes de sécurité :\n{diff}"
        }]
    ).choices[0].message.content

    # Étape 3 : Analyser la qualité du code en utilisant un modèle généraliste
    quality = client.chat.completions.create(
        model="gpt-5.5",
        messages=[{
            "role": "user",
            "content": f"Examinez la qualité du code : nommage, structure, "
                       f"gestion des erreurs, couverture de tests.\n{diff}"
        }]
    ).choices[0].message.content

    # Étape 4 : Générer un résumé en utilisant un modèle rapide et peu coûteux
    summary = client.chat.completions.create(
        model="deepseek-v4-flash",
        messages=[{
            "role": "user",
            "content": f"Résumez cette revue de PR en 3 points :\n"
                       f"Type : {classification}\n"
                       f"Sécurité : {security[:500]}\n"
                       f"Qualité : {quality[:500]}"
        }]
    ).choices[0].message.content

    return {
        "classification": classification,
        "security": security,
        "quality": quality,
        "summary": summary
    }

Optimisation des coûts et de l'efficacité

Le tableau ci-dessous présente l'allocation des modèles pour ce pipeline. La tarification exacte varie selon le fournisseur et le volume ; vérifiez les tarifs actuels sur le répertoire de modèles TokenLab.

Étape	Modèle	Tokens d'entrée	Rôle / Spécialisation
1. Classification	DeepSeek V4 Flash	~2 100	Classification rapide, routage peu coûteux
2. Sécurité	Claude Sonnet 5	~2 500	Raisonnement approfondi, analyse de sécurité
3. Qualité	GPT-5.5	~2 500	Qualité de code avancée et revue structurelle
4. Résumé	DeepSeek V4 Flash	~1 200	Agrégation de texte rapide et peu coûteuse

Exécuter les quatre étapes via un modèle de raisonnement phare comme Claude Sonnet 5 ou GPT-5.5 augmenterait considérablement les coûts. En acheminant les tâches plus simples vers des modèles moins coûteux comme DeepSeek V4 Flash, le pipeline multi-modèle réduit les dépenses totales en tokens tout en préservant le raisonnement approfondi pour l'étape critique d'analyse de sécurité.

---

Routage par capacité, pas seulement par prix

Bien que la réduction des coûts soit un objectif courant, les décisions de routage doivent également tenir compte des capacités spécifiques des modèles. Une politique de routage robuste évalue les modèles selon quatre dimensions clés :

• Profondeur de raisonnement : logique complexe, planification et déduction multi-étapes.
• Fenêtre de contexte : le volume d'informations de base ou de code requis pour la tâche.
• Fiabilité de l'utilisation des outils : la précision de l'appel de fonction et de la génération de sortie structurée.
• Sensibilité à la latence : les exigences de vitesse de l'application orientée utilisateur.

Ces dimensions aident à établir des règles de routage claires :

• Les tâches de décomposition et de planification sont acheminées vers des modèles axés sur le raisonnement.
• Les tâches d'extraction de données et de formatage sont acheminées vers des modèles rapides et peu coûteux.
• La génération de code et l'analyse syntaxique sont acheminées vers des modèles optimisés pour les tâches de codage.
• Les tâches d'analyse à l'échelle du dépôt sont acheminées vers des modèles avec de grandes fenêtres de contexte.

Pour aligner votre routeur sur ces exigences, consultez la comparaison des modèles de codage et la comparaison des prix pour faire correspondre les étapes de votre flux de travail avec les benchmarks actuels des modèles.

---

Intégration LangChain

Vous pouvez également implémenter le routage multi-modèle au sein de frameworks d'orchestration comme LangChain. L'exemple suivant configure différents modèles en utilisant une URL de base API unifiée :

from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate

# Initialiser les modèles avec des configurations distinctes
fast_model = ChatOpenAI(
    model="deepseek-v4-flash",
    api_key="sk-tokenlab-xxx",
    base_url="https://api.tokenlab.sh/v1"
)

reasoning_model = ChatOpenAI(
    model="claude-sonnet-5",
    api_key="sk-tokenlab-xxx",
    base_url="https://api.tokenlab.sh/v1"
)

# Définir des chaînes spécialisées
classify_chain = ChatPromptTemplate.from_template(
    "Classifiez l'intention de cette requête : {input}"
) | fast_model

analyze_chain = ChatPromptTemplate.from_template(
    "Effectuez une analyse détaillée de ce problème : {input}"
) | reasoning_model

---

Quand utiliser des agents multi-modèles

L'introduction de plusieurs modèles ajoute une complexité architecturale. Cette approche est généralement plus bénéfique lorsque :

• Exigences de tâches diverses : l'agent gère un mélange de tâches simples (comme la classification ou le formatage) et de tâches complexes (comme la planification stratégique ou la génération de code).
• Volume et coût élevés : les dépenses mensuelles en API sont suffisamment élevées pour que l'optimisation génère des économies significatives.
• Forces des modèles spécialisés : le flux de travail bénéficie des forces spécifiques des fournisseurs, comme la fenêtre de contexte de Gemini, les capacités de codage de Claude ou la vitesse d'utilisation des outils de GPT.
• Besoins de latence asymétriques : certaines parties du flux de travail doivent renvoyer des résultats instantanément, tandis que d'autres étapes en arrière-plan peuvent prendre plus de temps.

Pour les agents à usage unique ou les interfaces de chat simples, un seul modèle est souvent plus facile à maintenir. La surcharge opérationnelle du routage peut ne pas être justifiée si chaque requête nécessite le même niveau de capacité.

---

Modes de défaillance courants

Les architectures multi-modèles introduisent des modes de défaillance spécifiques qui nécessitent une atténuation :

1. Routeurs sur-ingéniérés

Si le prompt du routeur devient trop complexe, l'étape de classification elle-même peut devenir lente et coûteuse. Gardez les prompts de routage concis et les catégories de classification larges.

2. Dérive des contrats de sortie

Différents modèles peuvent formater les sorties différemment, même lorsqu'ils sont invités à renvoyer du JSON. Un modèle peut renvoyer du JSON brut, tandis qu'un autre l'enveloppe dans des blocs markdown. Pour éviter les échecs d'analyse en aval, imposez des schémas stricts en utilisant des bibliothèques de validation comme Pydantic à chaque transfert d'étape.

3. Dégradation silencieuse de la qualité

Si une politique de repli achemine une requête vers un modèle de niveau inférieur lors d'une panne du fournisseur principal, l'agent peut renvoyer des réponses de moindre qualité sans générer d'erreur. La mise en œuvre d'une stratégie de limitation de débit claire et d'un système d'alerte aide à suivre quand les replis sont actifs.

4. Télémétrie fragmentée

Lorsque l'utilisation des modèles est répartie entre plusieurs API de fournisseurs directs, l'agrégation des mesures de coût et de performance devient difficile. Centraliser les requêtes via une passerelle unique simplifie la journalisation et le suivi des coûts.

---

Une boucle d'évaluation minimale

Pour maintenir un agent multi-modèle, établissez une boucle d'évaluation de base pour suivre les performances. Vous pouvez enregistrer les mesures suivantes pour chaque exécution dans une table de base de données :

• Catégorie de tâche : la classification attribuée par le routeur.
• Modèle sélectionné : le modèle choisi pour chaque étape.
• Latence de l'étape : le temps nécessaire pour terminer chaque étape.
• Utilisation des tokens : le nombre exact de tokens d'entrée et de sortie.
• Statut de repli : si un modèle de repli a été déclenché.
• Retour utilisateur : un indicateur binaire indiquant si la sortie finale a été réussie.

L'analyse de ces données aide à déterminer si le routeur sélectionne les bons modèles, quelles étapes génèrent la majorité de vos coûts et si les modèles de repli maintiennent une qualité acceptable.

---

FAQ

Comment gérez-vous différents formats de prompt selon les modèles ?

Différents modèles répondent mieux à différentes structures de prompt. Par exemple, certains modèles fonctionnent mieux avec des prompts système, tandis que d'autres préfèrent des instructions intégrées dans le prompt utilisateur. Pour gérer cela, abstrayez vos prompts dans des modèles qui s'adaptent en fonction du modèle cible, plutôt que d'envoyer des chaînes brutes identiques à chaque modèle de votre pool.

Le routage ajoute-t-il trop de latence aux applications orientées utilisateur ?

Le routage introduit une petite quantité de latence pour l'étape de classification. Vous pouvez minimiser cela en utilisant des modèles hautement optimisés à faible latence pour le routeur, en gardant les limites de tokens max basses (moins de 10 tokens), ou en parallélisant les étapes lorsque la classification peut être déduite de l'état de l'application de l'utilisateur ou du point d'entrée.

Comment éviter les erreurs d'analyse JSON lors du changement de modèle ?

Pour éviter les erreurs d'analyse, utilisez les fonctionnalités de sortie structurée (comme le mode JSON ou l'appel d'outils) prises en charge par les fournisseurs de modèles. De plus, enveloppez toutes les sorties de modèle dans une couche de validation utilisant Pydantic ou des bibliothèques similaires pour analyser, valider et réparer la charge utile avant de la transmettre à l'étape suivante de votre pipeline.

---

Accédez à chaque modèle via une seule API : Commencez avec TokenLab pour accéder à plus de 300 modèles avec une seule clé API. Construisez des agents multi-modèles sans gérer plusieurs comptes de fournisseurs ou réécrire la logique de routage pour différentes API.