Comment orienter les requêtes LLM vers le bon modèle pour chaque tâche

Réponse courte : routez les requêtes dans votre application, puis utilisez une seule clé CometAPI et l’URL de base compatible OpenAI https://api.cometapi.com/v1 pour appeler le modèle choisi. Envoyez les tâches répétitives et faciles à vérifier vers une tranche à bas coût ; les interactions clients sensibles à la latence vers une tranche rapide ; et les tâches ambiguës ou à fort impact vers une tranche à haute précision. Conservez ces étiquettes comme votre propre politique — pas comme un classement universel des modèles — et mesurez chaque tranche sur le même jeu de test.

Ce guide construit ce routeur à trois tranches avec un exemple Python compact, un repli borné, et un modèle de coût qui compte les nouvelles tentatives et les sorties rejetées. L’exemple utilise des IDs de modèles actuels du catalogue CometAPI, mais la logique de routage reste séparée afin que les modèles puissent être remplacés sans réécrire l’application.

Qu’est-ce que le routage LLM ?

Le routage LLM est le processus consistant à envoyer chaque requête vers le modèle ou la tranche de service qui correspond le mieux à sa tâche, à son objectif de latence, à son exigence de qualité et à son budget.

Comment devriez-vous router les requêtes LLM par tâche ?

Au 20 août 2026, les IDs de modèles suivants et les champs de tarification du catalogue étaient disponibles via l’API publique CometAPI Models API. Les tarifs consommateurs estimés ci-dessous appliquent la valeur ratio du catalogue à ses prix de base d’entrée et de sortie, conformément au CometAPI pricing guide. Confirmez le tarif final affiché pour votre compte avant un usage en production.

« Rapide » signifie que la route a un objectif de latence ; « haute précision » signifie qu’elle a un objectif de qualité plus strict. Mesurez la latence p50 et p95, le taux de réussite par tâche, et le coût par sortie acceptée sur votre propre trafic avant de rendre le mapping permanent.

Comment configurer CometAPI pour un routeur LLM ?

Vous avez besoin d’une clé API CometAPI, de Python 3.10 ou supérieur, et du package Python OpenAI. Stockez la clé côté serveur plutôt que dans le code source.

pip install openaiexport COMETAPI_KEY="your-key-here"

L’exemple utilise POST /v1/chat/completions. CometAPI documente ceci comme une interface partagée pour plusieurs fournisseurs, mais le comportement des paramètres peut encore varier selon le modèle. Vérifiez l’entrée du modèle actuel et la Chat Completions reference avant d’ajouter des champs spécifiques à un fournisseur.

De quoi avez-vous besoin pour construire un routeur LLM ?

Mappez les tâches stables vers des tranches de service. N’utilisez pas un autre LLM pour classifier chaque requête sauf si des signaux simples de l’application sont insuffisants. Un tag de support est de manière prédictible une tâche de tranche économique ; une réponse en direct est sensible à la latence ; une revue de politique mérite la barrière de qualité la plus stricte.

Validez la sortie. Un statut HTTP réussi ne signifie pas que le résultat est exploitable. Passez un validateur spécifique à la tâche au routeur. Un validateur de classification peut vérifier un label autorisé ; un validateur de réponse client peut imposer une longueur et des affirmations interdites ; un workflow structuré peut valider un schéma JSON.

Repli étroit. Essayez la prochaine route approuvée après un timeout, 408, 429, un 5xx temporaire, ou un échec borné de la barrière de qualité. N’utilisez pas un autre modèle pour masquer une entrée malformée, une clé invalide, ou des paramètres non pris en charge.

Comment construire un routeur LLM en Python ?

import osimport time​from openai import APIError, OpenAI​client = OpenAI(    api_key=os.environ["COMETAPI_KEY"],    base_url="https://api.cometapi.com/v1",    max_retries=0,    timeout=20,)​MODELS = {    "cheap": "deepseek-v4-flash",    "fast": "gemini-3.7-flash",    "accurate": "claude-opus-5",}​# Put the preferred tier first; later tiers are fallbacks.ROUTES = {    "tag": ["cheap", "fast", "accurate"],    "reply": ["fast", "cheap", "accurate"],    "policy_review": ["accurate", "fast", "cheap"],}​​def retryable(error):    status = getattr(error, "status_code", None)    return status is None or status in {408, 429} or (status and status >= 500)​​def route(task, prompt, validate=lambda text: True):    attempts = []    for tier in ROUTES.get(task, ROUTES["reply"]):        model = MODELS[tier]        started = time.perf_counter()        try:            response = client.chat.completions.create(                model=model,                messages=[{"role": "user", "content": prompt}],                max_tokens=400,            )            text = response.choices[0].message.content or ""            attempts.append({                "tier": tier,                "model": model,                "latency_ms": round((time.perf_counter() - started) * 1000),                "accepted": validate(text),            })            if attempts[-1]["accepted"]:                return {                    "text": text,                    "route": tier,                    "model": model,                    "usage": response.usage.model_dump() if response.usage else None,                    "attempts": attempts,                }        except APIError as error:            attempts.append({"tier": tier, "model": model, "status": error.status_code})            if not retryable(error):                raise​    raise RuntimeError(f"No route passed: {attempts}")​​if __name__ == "__main__":    result = route(        "reply",        "Reply to a customer asking when their refund will arrive. Do not promise a date.",        validate=lambda text: 30 <= len(text) <= 600 and "guarantee" not in text.lower(),    )    print(result)

Comment borner les nouvelles tentatives avant le repli ?

Gardez les nouvelles tentatives du SDK à zéro et encapsulez chaque appel modèle avec une limite explicite. Le helper ci-dessous ne retente qu’une seule fois les échecs API re-tentables, puis lève une exception pour que la route externe passe à la tranche approuvée suivante.

MAX_ATTEMPTS_PER_MODEL = 2​def call_model(model, prompt):    for attempt in range(1, MAX_ATTEMPTS_PER_MODEL + 1):        try:            return client.chat.completions.create(                model=model,                messages=[{"role": "user", "content": prompt}],                max_tokens=400,            )        except APIError as error:            if not retryable(error) or attempt == MAX_ATTEMPTS_PER_MODEL:                raise            time.sleep(min(0.5 * (2 ** (attempt - 1)), 2.0))

Dans route(), remplacez l’appel direct à client.chat.completions.create(...) par call_model(model, prompt). Avec trois tranches, une requête s’arrête après au plus six appels fournisseur ; les échecs de validation montent tout de même d’un cran par tranche au lieu de retenter la même sortie.

Exécutez-le avec python3 llm_task_router.py. Pour changer plus tard de fournisseurs ou de générations de modèles, mettez à jour MODELS ; la politique de tâches et le contrat de réponse restent au même endroit.

L’exemple n’utilise que les paramètres partagés par les modèles sélectionnés. Ajoutez des contrôles de tokens spécifiques au modèle via une couche adaptatrice après avoir vérifié la compatibilité du modèle.

Comment tester une politique de routage LLM ?

Vérifiez d’abord que la politique déterministe sélectionne la tranche primaire prévue. Ce sont des attentes de routage, pas des résultats de performance fournisseur :

Un test fumigène en direct réussi renvoie la réponse plus la tranche sélectionnée, l’ID du modèle, l’usage de tokens, et chaque tentative. Les valeurs réelles de tokens et de latence varieront :

{  "text": "...",  "route": "fast",  "model": "gemini-3.7-flash",  "usage": {    "prompt_tokens": "measured value",    "completion_tokens": "measured value"  },  "attempts": [    {      "tier": "fast",      "model": "gemini-3.7-flash",      "latency_ms": "measured value",      "accepted": true    }  ]}

Pour une vraie comparaison, exécutez les mêmes requêtes étiquetées sur les trois modèles. Enregistrez le taux de réussite par tâche, la latence p50 et p95, le taux d’erreur, les tokens d’entrée et de sortie, le taux de repli, et le taux de revue humaine. La métrique qui compte généralement est le coût par sortie acceptée, pas le coût par appel API.

Combien coûte le routage multi-modèles ?

Utilisez une même forme de charge pour une comparaison équitable. Supposons 1 million de tokens au total : 800 000 tokens d’entrée et 200 000 tokens de sortie. En utilisant les tarifs dérivés du catalogue vérifiés au 20 août 2026 :

Si le trafic est à 60 % économique, 30 % rapide, et 10 % haute précision, le coût projeté mixte de tokens est d’environ 1,19 $ par 1 million de tokens au total. Envoyer le même mix entièrement vers la route haute précision serait d’environ 7,20 $ selon ces hypothèses. Il s’agit d’un calcul de tarification, pas d’une preuve que la politique mixte atteindra votre objectif de qualité.

Les nouvelles tentatives et les rejets modifient le résultat. Un taux de nouvelle tentative ponctuelle de 5 % augmente la projection de 1,19 $ à environ 1,25 $. Si une sortie à bas coût échoue à la validation et que la requête entière est répétée sur la tranche haute précision, comptez les deux appels. Suivez les sorties acceptées afin qu’un modèle apparemment économique ne dissimule pas les coûts de revue ou de régénération.

Quelles sont les pannes de routage LLM les plus courantes ?

Le error and retry guide recommande de retenter les limites de taux et les pannes temporaires de plateforme avec backoff, tandis que les requêtes malformées et les échecs d’authentification doivent être corrigés. Le fallback guide maintient également le repli de modèle ordonné et explicite.

Routage applicatif vs. CometAPI Auto : lequel utiliser ?

Utilisez le routage applicatif lorsque le contrôle et la reproductibilité comptent. Conservez la décision dans votre code lorsque les tâches sont stables et que vous avez besoin d’identités de modèles fixes, de budgets par tranche, de validateurs personnalisés, et d’un ordre de repli auditable. Cette approche facilite aussi la comparaison du même mapping de modèles entre les versions.

Utilisez CometAPI Auto lorsque la réduction de la maintenance du routage importe davantage. Définissez model=auto pour un défaut équilibré ou model=auto-high lorsque la qualité est prioritaire. CometAPI sélectionne dynamiquement un modèle éligible à partir des caractéristiques de la requête et du pool de routage actuel, de sorte que le modèle sous-jacent peut varier ; cela rend Auto moins adapté lorsque chaque exécution doit utiliser le même modèle ou des paramètres spécifiques au modèle.

Comment exécuter le routage LLM en production ?

Actualisez le registre des modèles. Appelez GET https://api.cometapi.com/api/models lors du déploiement ou au démarrage et échouez la release si un ID configuré ou un endpoint requis manque. Les IDs de modèles, les prix, et les capacités peuvent changer.

Gardez les options spécifiques au fournisseur hors du routeur. Une surface Chat Completions commune ne rend pas chaque paramètre identique. Par exemple, la prise en charge de logprobs, des contrôles de raisonnement, ou de multiples candidats peut différer. Placez ces différences dans des adaptateurs testés.

Limitez le trafic et la sortie. Limitez la concurrence avant que les requêtes ne quittent l’application, utilisez un backoff exponentiel avec jitter pour 429, et définissez un plafond de tokens de sortie. Le rate-limit guide de CometAPI recommande les mêmes contrôles côté application.

Journalisez la décision. Enregistrez le type de tâche, la version de la politique, la tranche choisie, l’ID du modèle, la latence, l’usage de tokens, le résultat de la validation, le nombre de nouvelles tentatives, la raison du repli, et l’estimation du coût. Évitez de journaliser des secrets ou du contenu client inutile.

Promouvez les routes avec des preuves. Conservez un jeu d’évaluation étiqueté pour chaque tâche. Déployez progressivement les changements de mapping, comparez-les avec la politique précédente, et conservez un chemin de rollback rapide.

Foire aux questions

CometAPI décide-t-il automatiquement quel modèle est économique, rapide, ou précis ?

Ce tutoriel conserve cette politique dans le code de l’application. CometAPI fournit la clé partagée, l’URL de base, le catalogue de modèles, l’interface Chat Completions, et des éléments de construction de repli documentés. Votre équipe définit ce que signifie chaque tranche et quel modèle a passé ses tests.

Une seule clé CometAPI peut-elle appeler des modèles de différents fournisseurs ?

Oui. Pour les routes de texte compatibles OpenAI, utilisez https://api.cometapi.com/v1 et changez la valeur model. Le catalogue actuel doit être vérifié avant le déploiement.

Pourquoi ne pas envoyer chaque requête vers le modèle le moins cher ?

Le tarif de token le plus bas peut devenir coûteux si les sorties échouent à la validation, nécessitent des nouvelles tentatives, ou génèrent du travail de revue humaine. Comparez le coût par résultat accepté et gardez les tâches à fort impact derrière des barrières de qualité plus strictes.

Un échec de qualité doit-il déclencher un repli ?

Seulement lorsque l’échec est détectable par machine et que l’escalade est bornée. Une erreur de schéma, un champ requis manquant, ou une promesse interdite peuvent justifier une escalade. Une insatisfaction vague devrait devenir des données d’évaluation plutôt qu’une boucle de nouvelles tentatives illimitée.

À quelle fréquence la carte des modèles doit-elle changer ?

Changez-la lorsque les données du catalogue actuelles et une évaluation répétable montrent un meilleur compromis. Ne faites pas tourner les modèles simplement parce qu’un nouveau nom apparaît dans le catalogue.

Puis-je ajouter un modèle OpenAI plus tard ?

Oui. Ajoutez un ID de modèle compatible OpenAI actuel à MODELS, testez le même contrat de requête et de réponse, et placez-le dans l’ordre des routes. Le client, la clé, et l’URL de base restent inchangés.

Comment garder une politique de routage LLM maintenable ?

Le routeur multi-fournisseurs le plus simple n’est pas une boîte noire autonome. C’est une courte politique de tâches versionnée, soutenue par un accès API partagé, des métadonnées de modèles à jour, un validateur de qualité, et une chaîne de repli étroite. CometAPI réduit le travail de connexion à une seule clé et une seule URL de base compatible OpenAI ; votre application conserve le contrôle des décisions de coût, de latence et de qualité.