La loterie de l'ID de modèle : même requête, tirage différent

Derrière une passerelle multi-fournisseurs, un ID de modèle ne spécifie pas ce qui sert votre requête. Il désigne un ensemble de déploiements avec des configurations de service différentes, et à moins de verrouiller un fournisseur spécifique, chaque requête est un tirage au sort parmi cet ensemble. Nous l'avons mesuré à nos dépens : lors de notre évaluation de moonshotai/kimi-k2.5 via OpenRouter (186 appels, lancés le 22 avril 2026, dernières séries dans les jours suivants), la même configuration de requête, le même ID de modèle, le même indicateur provider: { sort: "latency" }, le même ensemble de dix invites, a produit un temps médian jusqu'au premier token de 312 ms avec zéro caractère de raisonnement streamé lors d'une série, 10 appels sur 10, et 3 073 ms avec un médiane de 2 627 caractères de raisonnement lors d'une série ultérieure, à nouveau 10 appels sur 10. Un fournisseur différent a servi le même ID avec un comportement matériellement différent, sans aucun changement de notre part. Les métadonnées de la réponse indiquent bien le fournisseur de service si vous pensez à les enregistrer ; rien n'indique que le comportement a changé.

Le constat le plus marquant est que le drapeau de routage que nous attendions pour éviter exactement ce problème n'a pas fonctionné lors de nos tests. Si votre produit dépend de la profondeur du raisonnement, l'ID de modèle dans votre configuration n'est pas ce que vous avez déployé. Ce que vous avez déployé est un ticket de loterie, et les contrôles de routage de la passerelle sont des indications à vérifier, pas des contrats sur lesquels s'appuyer.

La même requête, deux fois

Nous testions des modèles candidats pour un assistant de conformité, donc chaque configuration exécutait les mêmes ensembles d'invites : dix invites standard de conformité (expliquer l'Annexe A.5.1 de l'ISO 27001, l'Article 32 du RGPD, le CC6.1 du SOC 2, etc.) et cinq invites complexes conçues pour la synthèse multi-cadres, le type de question où la profondeur du raisonnement se révèle. Pour chaque appel, nous avons enregistré le temps jusqu'au premier token, le temps total, les caractères de raisonnement streamés, les caractères de contenu streamés, et le champ provider que OpenRouter renvoie dans chaque fragment de flux.

Avec sort: "latency", les premières séries ont routé les dix appels de l'ensemble standard vers un fournisseur d'hébergement (BaseTen) : 312 ms de temps médian jusqu'au premier token, zéro caractère de raisonnement streamé sur chaque appel. Lors d'une série ultérieure, à quelques jours d'intervalle, la même configuration de requête a été routée vers un fournisseur différent (ModelRun) : 3 073 ms de temps médian, 2 627 caractères de raisonnement médians. Une série encore plus tardive a été routée vers le premier fournisseur. C'est ce que fait sort: "latency" par conception. La documentation de routage des fournisseurs d'OpenRouter (consultée le 15 juillet 2026) indique qu'avec un sort explicite, "l'équilibrage de charge sera désactivé, et le routeur essaiera les fournisseurs dans l'ordre", triés par latence mesurée. La latence mesurée évolue, donc l'ordre évolue, et avec lui, dans nos tests, l'apparition ou non de sortie de raisonnement.

Un écart de latence d'un facteur 10 est ennuyeux. Un comportement qui bascule d'un jour à l'autre sous un ID de modèle stable est d'une autre nature, car rien ne vous en avertit. Chaque réponse était un HTTP 200 avec un contenu fluide et un comptage de tokens plausible.

Le drapeau que nous attendions pour le détecter

Nous n'avons pas accepté le résultat sans raisonnement au pied de la lettre. Nous avons tenté de forcer le raisonnement sur le chemin rapide avec tous les paramètres que l'API propose : reasoning: { enabled: true }, reasoning: { effort: "high" }, reasoning: { max_tokens: 1024 }. Zéro caractère de raisonnement streamé, à chaque fois, dès que la requête était servie par ce fournisseur.

Puis nous nous sommes tournés vers le contrôle de routage. La documentation d'OpenRouter décrit require_parameters de la manière suivante : "Lorsque vous définissez require_parameters sur true, la requête ne sera même pas routée vers ce fournisseur", en référence aux fournisseurs qui ne supportent pas tous les paramètres de votre requête (documentation sur le routage des fournisseurs, consultée le 15 juillet 2026). Nous avons défini require_parameters: true en même temps que reasoning: { effort: "high" }. La requête a tout de même été routée vers le même fournisseur, et la réponse ne contenait toujours aucun texte de raisonnement.

Avant de tirer des conclusions, nous avons vérifié le format de nos paramètres par rapport à des déploiements connus pour fonctionner, car "le modèle ne raisonne pas" et "ce point de terminaison n'expose pas de raisonnement" semblent identiques de l'extérieur. Verrouillé sur DeepInfra, le même ID de modèle a produit 3 116 caractères de raisonnement sans drapeau et 3 807 avec reasoning: { enabled: true }. Verrouillé sur Novita : 3 460 caractères. Ces exécutions répondent à la question qui compte : la famille de modèles raisonne, notre syntaxe de requête était valide, et c'est le point de terminaison de service, et non le modèle, qui était la variable.

Pour être précis sur ce que cela montre et ce qu'il ne montre pas : require_parameters est documenté comme filtrant les fournisseurs en fonction du support des paramètres, et à partir des seules réponses, nous ne pouvons pas savoir si nos résultats sans raisonnement reflétaient les métadonnées de capacité du point de terminaison, la gestion des paramètres côté fournisseur, ou une configuration de service qui expose simplement aucun texte de raisonnement. Un point de terminaison qui n'expose pas de raisonnement peut être un choix de service délibéré et légitime ; un premier token à 312 ms est un produit réel à offrir, et zéro caractère de raisonnement streamé prouve seulement qu'aucun raisonnement ne nous a été exposé, pas qu'aucun calcul n'a eu lieu. Ce que nous pouvons dire est plus restreint mais plus utile : lors de nos tests d'avril 2026, déclarer le paramètre de raisonnement comme requis ne nous a pas permis d'être routés vers un point de terminaison dont les réponses contenaient une sortie de raisonnement. Quel que soit le mécanisme, le contrat pratique que nous pensions avoir ne s'est pas concrétisé, et seule la mesure de la sortie nous l'a révélé.

Pourquoi un produit de conformité le remarque, et pourquoi le vôtre pourrait ne pas le faire

Voici la partie inconfortable, énoncée clairement : sur nos cinq invites complexes, la configuration sans raisonnement avait toujours l'air compétente. Interrogé pour trouver des chevauchements de contrôles et un conflit entre l'ISO 27001, l'Article 32 du RGPD et le PCI DSS pour une entreprise SaaS de 50 personnes, il a produit une analyse structurée avec des références de clauses spécifiques, comme enregistré dans nos notes de test : contrôles A.9.1 à A.9.4 de l'Annexe A de l'ISO 27001, Article 32(1)(a) du RGPD, exigences 3.4 et 4.1 du PCI DSS. Remarquez la subtilité à l'intérieur de la fluidité : A.9.x est la numérotation de l'édition 2013 de l'ISO/IEC 27001, remplacée par la révision de 2022. La réponse semblait autoritaire et portait une obsolescence au niveau de l'édition que rien dans la réponse n'indiquait ; nous ne l'avons détectée qu'en vérifiant la numérotation par rapport à la révision de 2022. C'est la forme de défaillance en miniature : fluide, structurée, spécifique, et silencieusement différente du comportement que vous aviez configuré. Si notre évaluation avait consisté à "jeter un œil à quelques réponses pour détecter des échecs évidents", la perte de sortie de raisonnement serait passée inaperçue. Elle est apparue parce que nous avons enregistré les caractères de raisonnement par appel comme une métrique de premier ordre, et la colonne est passée à zéro.

Le reste du scan de la famille kimi a renforcé à quel point chaque chemin échoue différemment. La variante dédiée au raisonnement (moonshotai/kimi-k2-thinking) a produit une sortie de raisonnement sur chaque invite complexe (4 103 caractères médians) mais a atteint 178 618 ms jusqu'au premier token sur une invite de raisonnement profond, trois minutes à fixer un indicateur de chargement. Verrouiller kimi-k2.5 sur un fournisseur capable de raisonnement (Inceptron) a produit un vrai raisonnement mais a échoué sur 2 des 5 invites complexes : la réponse a consommé l'intégralité du budget de 2 048 tokens pour le raisonnement et n'a émis aucun contenu. Rapide sans sortie de raisonnement, raisonnement sans latence bornée, ou raisonnement qui affame la réponse. Trois modes d'échec au sein d'une même famille de modèles, et aucun d'eux n'est visible dans les ID. Nous avons écarté chacune de ces options pour la production.

Pour un assistant de conformité, les enjeux sont spécifiques : la réponse alimente une évaluation des risques ou une réponse d'audit, et une réponse peut sembler autoritaire tout en portant exactement l'obsolescence qu'un auditeur recherche. "Fluide, mais pas le comportement que vous avez configuré" est la pire forme d'échec dans ce domaine, car rien dans la réponse ne la marque comme un échec. Le propre blog d'ingénierie d'OpenRouter reconnaît la dimension qualitative de cette variance : "Certains fournisseurs servent des variantes plus fortement quantifiées d'un modèle qui sous-performent par rapport au même modèle hébergé ailleurs" (Comment fonctionne le routage des modèles d'OpenRouter, publié le 12 juin 2026). Nos données ajoutent une dimension comportementale à cette image : non seulement le même modèle est servi de manière moins performante, mais la présence ou l'absence de sortie de raisonnement derrière un ID stable.

La loterie de l'ID de modèle

Voilà l'idée nommée, et le modèle mental que nous appliquons désormais à chaque intégration de passerelle : lorsqu'un ID de modèle équilibre la charge entre plusieurs fournisseurs avec des configurations de service différentes, chaque requête est un tirage au sort, et le nom imprimé sur le ticket est la chose la moins informative à son sujet. L'ID de modèle vous indique la famille de pondération. Il ne vous indique pas la quantification, la distribution de latence, si une sortie de raisonnement apparaîtra, ou si les paramètres que vous avez marqués comme requis seront reflétés dans ce qui revient. Ce sont des propriétés du triplet (modèle, fournisseur, jour), et deux des trois variables sont en dehors de votre fichier de configuration.

La liste de contrôle portable

Si vous routez le trafic LLM via une passerelle multi-fournisseurs, pas seulement OpenRouter :

• Enregistrez les sorties comportementales comme des métriques de premier ordre. Caractères ou tokens de raisonnement par appel, ainsi que la latence, indexés par le fournisseur de service que la réponse indique. Un comportement qui n'est pas mesuré par réponse peut disparaître sans que personne ne s'en aperçoive. Alertez sur l'effondrement en production, pas seulement dans les évaluations.
• Traitez les drapeaux de routage et de paramètres comme des indications jusqu'à ce que vous les ayez confirmés par rapport à la sortie. Envoyez une requête qui nécessite une capacité, puis vérifiez quel fournisseur l'a servie et si la capacité est réellement apparue dans la réponse.
• Avant de conclure "ce modèle ne peut pas X", verrouillez un fournisseur connu pour fonctionner et faites un A/B test du drapeau. Notre requête était valide tout le temps ; le point de terminaison de service était la variable. Sans la vérification verrouillée, nous aurions accusé le modèle.
• Re-échantillonnez le routage sur des heures et des jours, pas au sein d'une même session. Dix appels sur dix vers un fournisseur un mardi est un échantillon, pas une propriété. Notre oscillation n'est apparue qu'entre des séries à plusieurs jours d'intervalle.
• Discriminez avec des invites complexes et rapportez les distributions. Nos dix invites faciles ont produit des réponses que nous ne pouvions pas classer de manière significative ; seules les cinq invites complexes ont séparé la qualité des réponses entre configurations, et les médianes ont masqué la queue à 178 secondes. La colonne du maximum est là où se trouvent les configurations non déployables.
• Si un comportement déterministe compte, verrouillez le fournisseur et ré-vérifiez selon un calendrier. Le verrouillage sacrifie la bascule et parfois la latence. Pour un domaine régulé, c'est souvent le bon compromis.

Limites

Il s'agit d'une évaluation : 186 appels, 5 à 10 invites par configuration, sur notre ensemble d'invites de conformité, lancés le 22 avril 2026 avec les dernières séries dans les jours suivants (nous avons enregistré la date de l'évaluation, pas les horodatages par série). Chaque chiffre ici est notre propre mesure sur nos propres tâches à cette période, pas une affirmation sur le comportement, la configuration ou l'intention actuelle d'un fournisseur. Les identifiants de modèles sont les ID publics de la passerelle tels que demandés à l'époque ; nous n'avons pas enregistré indépendamment les révisions sous-jacentes des modèles. Les déploiements des fournisseurs, la logique de routage d'OpenRouter et la documentation que nous citons (consultée le 15 juillet 2026) peuvent tous avoir changé depuis. L'observation sur require_parameters concerne un modèle sur une paire de fournisseurs ; nous ne l'avons pas étendue à l'ensemble du catalogue. Zéro caractère de raisonnement streamé signifie qu'aucun raisonnement n'a été exposé dans la réponse, rien de plus. Et les tailles d'échantillon sont suffisantes pour notre décision de déploiement, indicatives pour la vôtre. Ce dont nous sommes confiants, c'est du mécanisme : lorsque le comportement de service varie par fournisseur derrière un ID stable, la seule capacité que vous avez réellement est celle que vous mesurez à la sortie.

L'ID de modèle dans votre configuration est un nom pour une distribution. Mesurez les tirages.