Faut-il simplement prendre le modèle le plus puissant ?

Non. Le modèle le plus capable est aussi le plus lent et le plus coûteux, ce qui en fait un mauvais choix par défaut pour la majorité de ce qu'un système en production fait. La capacité est une variable parmi plusieurs : une tâche de routing ou une classification à fort volume n'obtient pas de meilleures réponses d'un frontier model, ça coûte juste plus cher. Réserver le tier du haut aux étapes qui en ont réellement besoin et router le reste vers un tier moins coûteux qui passe la barre.

Comment choisir un benchmark ?

Aligner le benchmark sur la tâche et le tier. Utiliser un benchmark de code comme SWE-bench pour une tâche de code, une suite agentique pour les agents qui utilisent des outils, et un leaderboard de raisonnement uniquement pour du vrai travail de raisonnement. Ne pas scorer une tâche de routing ou de classification sur des leaderboards de raisonnement frontier. Traiter tout benchmark comme un point d'entrée qui constitue une shortlist, jamais comme un verdict : celui-ci vient de vos propres evals.

Pourquoi lancer ses propres evals ?

Parce que les benchmarks publics ne correspondent jamais à votre distribution de tâches. Un modèle qui domine un leaderboard peut quand même échouer sur vos entrées, vos formats et vos cas limites. Votre eval est un golden set de quelques dizaines de cas réels avec des sorties de référence, scoré sur la trace complète pour les agents, pas seulement sur la réponse finale. Les benchmarks shortlistent, les evals décident : l'eval est la porte de sélection, pas un bonus facultatif.

Qu'est-ce que le model routing ?

Une couche qui lit chaque requête, estime sa difficulté et la dispatche vers le tier le moins coûteux capable de la traiter : appels courants vers un small model, raisonnement difficile vers un frontier model. Le router lui-même est un modèle petit et rapide dont l'overhead est négligeable face à l'appel frontier qu'il évite. Il divise généralement le coût par plus de deux sans perte de qualité, car la plupart des requêtes n'avaient jamais besoin du modèle coûteux. Le routing est la sortie du processus de sélection, pas un détail.

Comment choisir un modèle pour un agent ?

Sélectionner sur des signaux spécifiques aux agents, pas sur le score de raisonnement brut. Ceux qui comptent : la tool-calling reliability et la faible hallucination de schéma (invente-t-il des paramètres absents du schéma ?), la cohérence des structured outputs sur du JSON imbriqué, la cohérence de l'objectif sur une longue séquence d'étapes, et l'économie du cached-input à mesure que la trace d'outils grossit. Lancer des trace-based evals sur un golden set, en scorant chaque tool call et pas seulement la réponse finale : la trace est là où se cachent les échecs agentiques.

← Stack

Choisir un modèle

Choisir un modèle est un processus, pas un choix : cinq étapes qui aboutissent à une stratégie de routing, pas à un gagnant unique.

Vue d'ensemble

Le réflexe est de prendre le modèle le plus puissant et de passer à la suite. C'est le mauvais réflexe. La capacité brute est une variable parmi plusieurs : le modèle le plus capable est aussi le plus lent et le plus coûteux, ce qui en fait un mauvais choix par défaut pour la majorité de ce qu'un système en production fait réellement. Bien choisir n'est pas un choix, c'est un processus : une décision reproductible que vous pouvez justifier, rejouer à chaque nouveau modèle, et appliquer tâche par tâche plutôt qu'une fois pour toute l'entreprise. La page ci-dessous déroule ce processus en cinq étapes, dans l'ordre, parce que l'ordre est l'essentiel : on élimine avant de comparer, et on classifie avant de benchmarker.

Les cinq étapes sont les suivantes : éliminer les candidats qui échouent à une contrainte non négociable (confidentialité et résidence des données, plafond de latence, budget, licence) avant même d'aborder la qualité ; classer la tâche par intelligence tier, frontier, workhorse ou small, pour benchmarker la tâche face aux bons pairs ; lire les benchmarks adaptés à ce tier, en traitant les leaderboards comme des points d'entrée et non comme des verdicts ; constituer une shortlist de trois à cinq candidats et lancer vos propres evals sur votre distribution de tâches réelles ; et concevoir une stratégie de routing plutôt que de tout miser sur un seul modèle. Chaque étape réduit le champ, et l'ordre vous évite de gaspiller un budget d'eval sur un modèle qui n'aurait jamais passé un non-négociable.

Le bénéfice se trouve à la cinquième étape, et c'est une décision d'architecture, pas un détail. La sortie du processus n'est pas "le modèle X a gagné", c'est une stratégie de routing : un modèle router peu coûteux lit chaque requête, décide du tier nécessaire et la dispatche, de sorte que le frontier model est réservé aux étapes qui en ont réellement besoin. C'est ici que le principe model != provider prend tout son sens : coder contre une interface et choisir un modèle par node permet de remplacer un modèle sans toucher au reste du système. Le routing divise généralement le coût par plus de deux sans perte de qualité, car la plupart des requêtes n'avaient jamais besoin du modèle coûteux. Le choix du modèle est un choix de conception système, c'est pourquoi cette page occupe le sommet du cluster.

Architecture

Lire l'entonnoir de haut en bas. On part d'un grand nombre de modèles candidats et on resserre à chaque étape : les non-négociables éliminent tout ce qui échoue à une contrainte dure, la classification par tier fixe le groupe de comparaison, les bons benchmarks constituent une shortlist dans ce groupe, vos propres evals classent cette shortlist sur votre tâche, et le routing transforme les survivants en stratégie. L'entonnoir ne se termine pas sur un modèle unique : il aboutit à une stratégie de routing, un petit router qui dispatche chaque requête vers le tier dont elle a besoin. Chaque étape coûte moins cher à exécuter que l'étape précédente à ignorer, c'est pourquoi l'ordre tient.

L'entonnoir de sélection : de nombreux modèles candidats se resserrent à travers les non-négociables, le tier, les benchmarks et vos propres evals, pour aboutir non pas à un gagnant unique mais à une stratégie de routing.

Concepts clés

Non-négociable (contrainte dure): Une exigence binaire qui élimine un modèle avant même d'aborder la qualité : résidence ou souveraineté des données, plafond de latence, cap budgétaire, conditions de licence. Les quatre qui reviennent systématiquement sont la confidentialité des données, la latence, le coût et le niveau d'intelligence requis. Si un modèle en échoue une, aucun score de benchmark ne le sauve.
Intelligence tier: La classe de capacité à laquelle appartient une tâche : frontier, workhorse ou small. Classifier la tâche d'abord permet de la benchmarker face aux bons pairs, plutôt que d'évaluer une tâche de routing sur des leaderboards de raisonnement frontier. L'échelle des tiers a sa propre page.
Benchmark vs eval: Un benchmark est un test public et partagé (un leaderboard, SWE-bench, une suite agentique) qui classe les modèles sur une distribution générique. Un eval est votre propre test sur votre propre distribution de tâches. Les benchmarks shortlistent ; les evals décident. Ils répondent à des questions différentes, et seul l'eval reflète votre charge de travail réelle.
Golden set: Un petit ensemble d'exemples représentatifs avec des sorties attendues de référence, constitué à partir de cas réels et de vrais échecs. C'est la vérité terrain contre laquelle vos evals notent : quelques dizaines d'exemples bien choisis l'emportent sur un benchmark générique pour sélectionner un modèle sur votre tâche.
Trace-based eval: Evaluer un agent sur sa trace d'exécution complète : chaque tool call, chaque argument et chaque étape intermédiaire, pas seulement la réponse finale. La trace dit ce qui s'est passé ; l'eval dit si c'était correct. Pour les agents, la trace est là où se cachent la plupart des échecs, c'est donc là que l'eval doit regarder.
Model routing: Une couche qui estime la difficulté de chaque requête et la dispatche vers le tier le moins coûteux capable de la traiter : appels courants vers un small model, raisonnement difficile vers un frontier model. C'est la sortie du processus de sélection, pas un détail : le routing divise généralement le coût par plus de deux sans perte de qualité.
Shadow router: Un modèle petit et rapide dont le seul rôle est de lire une requête et de décider du tier nécessaire, en bien moins de temps que l'appel réel. Il est suffisamment peu coûteux pour que son overhead soit négligeable face à l'appel frontier qu'il évite, ce qui rend le routing rentable.
Tool-calling reliability: La régularité avec laquelle un modèle appelle le bon outil, au bon moment, avec des arguments conformes au schéma, sans inventer de paramètres ou de champs inexistants. Le risque augmente avec le nombre d'outils, et c'est un signal de sélection primaire pour un modèle agentique, distinct du score de raisonnement brut.
Prompt caching: Réutiliser le calcul du modèle pour un préfixe répété (un system prompt, un schéma d'outil, un long contexte) pour ne pas le facturer au plein tarif à chaque appel. C'est surtout important dans les boucles agentiques, où le même contexte est renvoyé à chaque étape et où les traces d'outils grossissent : le tarif cached-input peut dominer la facture.

Quand l'utiliser

Cas adaptés

Les systèmes en production à fort volume. Quand un flux traite des milliers de requêtes, l'écart entre le tier le moins coûteux qui passe la barre et un frontier par défaut s'accumule vite. Le processus complet s'amortit dès que le routing envoie la majorité courante vers un small model et réserve le frontier aux rares étapes qui en ont besoin.
Les projets à grande échelle où la facture modèle est une ligne que quelqu'un surveille. Ici, la stratégie de routing est le coeur du sujet : un petit router qui dispatche par tier divise généralement le coût par plus de deux sans perte de qualité, car la plupart des requêtes n'avaient jamais besoin du modèle coûteux. Le processus transforme cette économie en une conception justifiable plutôt qu'une intuition.
Les données réglementées ou souveraines, où la première étape décide de tout. Quand les données ne peuvent pas quitter une juridiction ou un périmètre, le non-négociable élimine des classes entières de modèles avant même d'aborder la qualité. Suivre le processus dans l'ordre vous évite de vous enticher d'un champion de leaderboard que vous n'auriez jamais eu le droit de déployer.
Les charges de travail agentiques avec des outils et de longs horizons. Un agent qui appelle des outils sur de nombreuses étapes se sélectionne sur des signaux différents d'un chatbot : tool-calling reliability, cohérence des structured outputs sur du JSON imbriqué, cohérence de l'objectif sur une longue trace, et économie du cached-input à mesure que la trace grossit. Les trace-based evals sur un golden set sont la seule façon honnête de comparer les candidats ici.

Anti-patterns

Choisir sur la seule base du classement leaderboard. Un score de benchmark de premier plan classe les modèles sur une distribution générique qui n'est pas la vôtre. Prendre le modèle numéro un sans le confronter à vos contraintes et à votre tâche est l'erreur de sélection la plus répandue : le leaderboard est un point d'entrée, pas un verdict.
Tout miser sur un seul frontier model. Un modèle coûteux unique pour chaque requête surpaye sur la majorité courante et ne laisse aucun fallback quand il est lent, indisponible ou dont le tarif change. Le processus aboutit à une stratégie de routing précisément pour ne jamais dépendre d'un seul modèle.
Sauter vos propres evals. Les benchmarks publics ne correspondent jamais à votre distribution de tâches, donc un modèle qui les domine peut quand même échouer sur vos entrées. Livrer un modèle que vous n'avez pas évalué sur un golden set tiré de vos cas réels, c'est choisir à l'aveugle : l'eval est la porte de sélection, pas un bonus facultatif.
Sur-router une application triviale. Le routing est une décision d'architecture, et comme toute architecture il a un coût. Une petite application avec une seule tâche et un faible volume n'a pas besoin d'un router et d'une stratégie multi-tier : elle a besoin d'un workhorse bien choisi. Exécuter le processus, mais le laisser conclure sur un modèle unique quand c'est la réponse honnête.

Exemples de code

Un router tâche-vers-tier

# Step 5 in code: a cheap router reads the request and dispatches it
# to the tier it needs. Code against an interface, choose a model per
# node, so swapping a model never touches the system around it.

def route(request) -> str:
    difficulty = classify(request)        # a small, fast shadow router
    if difficulty == "hard":
        return "frontier"                 # reserve for steps that need it
    if difficulty == "routine":
        return "workhorse"                # the everyday default
    return "small"                        # high-volume, narrow tasks

# Most requests are not "hard", so most never hit the frontier model.
# That is the saving: routing typically cuts cost 60%+, no quality loss.

Le router lui-même est un small model, suffisamment peu coûteux pour que son overhead soit négligeable face à l'appel frontier qu'il évite. La sortie du processus de sélection, c'est ce dispatch, pas un modèle gagnant unique.

Evaluer une shortlist sur un golden set

# Step 4 in code: rank a shortlist on YOUR task, not a public benchmark.
# A golden set is a few dozen real cases with known-good outputs.

golden = load_golden_set()                # real inputs, expected outputs

def evaluate(model) -> float:
    passed = 0
    for case in golden:
        trace = run_agent(model, case.input)   # full trace, not just output
        if score_trace(trace, case.expected):  # tool calls + final answer
            passed += 1
    return passed / len(golden)

shortlist = ["candidate_a", "candidate_b", "candidate_c"]
ranked = sorted(shortlist, key=evaluate, reverse=True)

Les benchmarks shortlistent, les evals décident. Scorer la trace complète (chaque tool call, pas seulement la réponse finale) permet de détecter les échecs qui comptent pour un agent. Le golden set est votre vérité terrain.

Comparatif

vs Model tiers

Lien : les tiers dans lesquels l'étape 2 classifie

Cette page est le processus ; model tiers est l'échelle dans laquelle le processus classifie les tâches. L'étape 2 associe chaque tâche à frontier, workhorse ou small, et la page des tiers définit ce que sont ces barreaux et quand chacun l'emporte. Lire la page des tiers pour comprendre les barreaux, lire celle-ci pour dérouler la décision.

vs Deploying models

Lien : là où le modèle choisi tourne

Choisir un modèle décide lequel ; déployer des modèles décide où il tourne : API du labo, inférence managée ou auto-hébergé. Les deux sont orthogonaux et séquentiels : dérouler ce processus pour choisir le modèle et le tier, puis choisir le déploiement sur sa propre page. La souveraineté comme non-négociable ici pointe souvent directement vers une réponse de déploiement là-bas.

Ressources

FAQ

Faut-il simplement prendre le modèle le plus puissant ?: Non. Le modèle le plus capable est aussi le plus lent et le plus coûteux, ce qui en fait un mauvais choix par défaut pour la majorité de ce qu'un système en production fait. La capacité est une variable parmi plusieurs : une tâche de routing ou une classification à fort volume n'obtient pas de meilleures réponses d'un frontier model, ça coûte juste plus cher. Réserver le tier du haut aux étapes qui en ont réellement besoin et router le reste vers un tier moins coûteux qui passe la barre.
Comment choisir un benchmark ?: Aligner le benchmark sur la tâche et le tier. Utiliser un benchmark de code comme SWE-bench pour une tâche de code, une suite agentique pour les agents qui utilisent des outils, et un leaderboard de raisonnement uniquement pour du vrai travail de raisonnement. Ne pas scorer une tâche de routing ou de classification sur des leaderboards de raisonnement frontier. Traiter tout benchmark comme un point d'entrée qui constitue une shortlist, jamais comme un verdict : celui-ci vient de vos propres evals.
Pourquoi lancer ses propres evals ?: Parce que les benchmarks publics ne correspondent jamais à votre distribution de tâches. Un modèle qui domine un leaderboard peut quand même échouer sur vos entrées, vos formats et vos cas limites. Votre eval est un golden set de quelques dizaines de cas réels avec des sorties de référence, scoré sur la trace complète pour les agents, pas seulement sur la réponse finale. Les benchmarks shortlistent, les evals décident : l'eval est la porte de sélection, pas un bonus facultatif.
Qu'est-ce que le model routing ?: Une couche qui lit chaque requête, estime sa difficulté et la dispatche vers le tier le moins coûteux capable de la traiter : appels courants vers un small model, raisonnement difficile vers un frontier model. Le router lui-même est un modèle petit et rapide dont l'overhead est négligeable face à l'appel frontier qu'il évite. Il divise généralement le coût par plus de deux sans perte de qualité, car la plupart des requêtes n'avaient jamais besoin du modèle coûteux. Le routing est la sortie du processus de sélection, pas un détail.
Comment choisir un modèle pour un agent ?: Sélectionner sur des signaux spécifiques aux agents, pas sur le score de raisonnement brut. Ceux qui comptent : la tool-calling reliability et la faible hallucination de schéma (invente-t-il des paramètres absents du schéma ?), la cohérence des structured outputs sur du JSON imbriqué, la cohérence de l'objectif sur une longue séquence d'étapes, et l'économie du cached-input à mesure que la trace d'outils grossit. Lancer des trace-based evals sur un golden set, en scorant chaque tool call et pas seulement la réponse finale : la trace est là où se cachent les échecs agentiques.