Apps IA multi-modèles : routage et fallbacks

Une app IA en production doit survivre à la panne d'un modèle sans réveiller personne. Le patron qui vous y amène est ennuyeux et fiable : un client compatible OpenAI, une liste de modèles classés par priorité, des règles de routage qui privilégient les fournisseurs bon marché mais sains, et des plafonds de prix stricts.

Ce que vous allez construire dans ce tutoriel :

• Un client unique capable d'appeler GPT, Claude, Gemini, DeepSeek et d'autres en changeant une seule chaîne de caractères

• Des fallbacks automatiques — si le modèle principal renvoie une erreur ou dépasse le délai, la requête est retentée sur le modèle suivant de votre liste

• Un contrôle des coûts — routage au moins cher d'abord et plafonds max_price pour qu'un pic de trafic ne puisse pas cramer votre budget

• Une visibilité sur les dépenses — une comptabilité du coût par requête que vous pouvez logger et surveiller par alertes

Tout ce qui suit utilise OpenRouter comme couche de routage ; la même architecture fonctionne avec n'importe quelle passerelle compatible OpenAI, y compris APIMart quand vous avez besoin de modèles d'image, de vidéo ou d'audio dans la même app.

Pourquoi le multi-modèles bat le mono-modèle

Les pannes sont une question de quand, pas de si

Chaque grand fournisseur a des incidents visibles. Si votre app code en dur un seul fournisseur, chacun de ces incidents devient votre incident. Une chaîne de fallbacks transforme un « fournisseur en panne » en simple pic de latence.

Chaque modèle a son point fort

Les modèles rapides et bon marché gèrent la classification et l'extraction ; les modèles frontier gèrent la génération à fort raisonnement. Mélanger les niveaux selon la tâche divise couramment la facture d'inférence par deux, voire plus.

Les prix changent tous les mois

Les prix des modèles baissent en permanence. Si changer de modèle se résume à modifier une ligne, vous pouvez courir après le meilleur rapport prix-performance chaque trimestre sans projet de migration.

Étape 1 : un client, plusieurs modèles

Pointez le SDK officiel OpenAI vers la passerelle — aucun code HTTP maison nécessaire :

from openai import OpenAI

client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key="sk-or-..."
)

resp = client.chat.completions.create(
    model="anthropic/claude-sonnet-4.5",
    messages=[{"role": "user", "content": "Summarize this contract clause..."}],
)
print(resp.choices[0].message.content)

Passer à deepseek/deepseek-chat ou google/gemini-2.5-pro n'est qu'une chaîne model différente. Gardez les noms de modèles dans la config, pas dans le code.

Version TypeScript

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://openrouter.ai/api/v1",
  apiKey: process.env.OPENROUTER_API_KEY,
});

const resp = await client.chat.completions.create({
  model: "deepseek/deepseek-chat",
  messages: [{ role: "user", content: "Classify this ticket: ..." }],
});

Un registre de modèles, pas des chaînes éparpillées

Centralisez une bonne fois le mapping tâche → niveau de modèle :

{
  "extract": "deepseek/deepseek-chat",
  "chat": "anthropic/claude-sonnet-4.5",
  "reason": "openai/gpt-5.2"
}

Étape 2 : des fallbacks qui se déclenchent automatiquement

Le tableau models

OpenRouter retente la requête côté serveur en parcourant une liste classée quand le modèle principal renvoie une erreur, est limité en débit ou dépasse le délai ^[1] :

{
  "model": "openai/gpt-5.2",
  "models": ["anthropic/claude-sonnet-4.5", "deepseek/deepseek-chat"],
  "messages": [{ "role": "user", "content": "..." }]
}

La réponse vous indique quel modèle a réellement servi la requête — loggez-le.

Failover au niveau des fournisseurs

Sous les fallbacks de modèles, chaque modèle peut être servi par plusieurs fournisseurs. Les préférences de routage épinglent ou excluent des upstreams précis ^[2] :

{
  "model": "meta-llama/llama-3.3-70b-instruct",
  "provider": {
    "order": ["deepinfra", "together"],
    "allow_fallbacks": true
  }
}

Dernier recours côté client

Enveloppez l'appel dans une unique nouvelle tentative vers une autre passerelle (ou une réponse en cache) pour le rare cas où le routeur lui-même est injoignable. Tenez-vous-en à une seule tentative — les tempêtes de retries sont des pannes auto-infligées.

Étape 3 : un contrôle des coûts impossible à contourner

Routage au moins cher d'abord

Triez les fournisseurs par prix quand la latence est secondaire — soit par requête ("provider": {"sort": "price"}), soit avec le suffixe de modèle :floor pour les traitements batch.

Plafonds de prix stricts

max_price rejette tout fournisseur dont le tarif dépasse votre plafond (dollars par 1M de tokens) :

{
  "model": "openai/gpt-5.2",
  "max_price": { "prompt": 1.5, "completion": 10 },
  "messages": [{ "role": "user", "content": "..." }]
}

C'est une garantie, pas une préférence — les requêtes qui ne peuvent pas être servies sous le plafond échouent immédiatement au lieu de coûter plus cher en silence.

Suivez le coût par requête

Les réponses incluent l'usage ; multipliez-le par les tarifs du modèle qui a servi la requête et émettez le résultat comme métrique. Alertez sur la dérive du coût par tâche, pas seulement sur la dépense totale — la dérive, c'est ainsi qu'un fallback silencieux vers un modèle plus cher se manifeste.

Au-delà du texte : le même patron pour l'image, la vidéo et l'audio

Les routeurs LLM s'arrêtent aux modèles de langage. Les vrais produits génèrent aussi des images, de la vidéo et de la voix — et jongler avec cinq SDK fournisseurs de plus réintroduit exactement le problème que vous venez de résoudre.

Une passerelle pour toutes les modalités

APIMart expose 500+ modèles — le chat plus GPT-Image-2, Sora 2, Kling, Veo, Suno — derrière une seule API compatible OpenAI et un seul solde.

Intégration familière, tarifs remisés

La configuration du client est identique à l'Étape 1 avec une autre base URL, et les prix par modèle se situent environ 20% sous les tarifs officiels — consultez la page de tarifs pour les tarifs exacts par modèle.

Mélanger les routeurs ne pose aucun problème

Une architecture de production courante : OpenRouter ou des API directes pour le texte, APIMart pour la génération de médias — les deux derrière la même abstraction dans votre code, les deux remplaçables via la config.

Ajoutez des modèles image, vidéo et audio à votre app

Gardez l'architecture multi-modèles que vous venez de construire et étendez-la au-delà du texte — 500+ modèles, une API compatible OpenAI, paiement à l'usage ~20% sous les prix officiels.

Obtenir une clé API

Checklist de production

Livrez avec les cinq éléments : registre de modèles piloté par la config, chaîne de fallbacks côté serveur, routage au moins cher d'abord quand la latence le permet, plafonds max_price sur chaque appel et métriques de coût par requête avec alertes de dérive. C'est cette combinaison qui permet à une équipe de deux personnes de faire tourner une app multi-modèles sans astreinte ops dédiée.