Quand une requête réussie reste un échec
Imaginez que vous parlez au même personnage depuis des semaines. Sa voix vous est familière, sa langue reste cohérente et ses réponses semblent vives et pertinentes.
Puis, sans changer de personnage ni de modèle, quelque chose ne va plus.
La réponse suivante met dix secondes à commencer. Une fonctionnalité fondée sur une sortie structurée cesse soudain de fonctionner. Le personnage se met à divaguer, insère des fragments dans une autre langue ou répond dans un style qui semble provenir d’un modèle bien moins performant.
Du point de vue du serveur, rien n’a échoué. L’API a renvoyé 200 OK, des tokens sont arrivés et la requête a été facturée.
Du point de vue de l’utilisateur, le modèle vient de se dégrader.
C’est pour combler cet écart que nous avons conçu pour Reverie un système de sondes canari et de mise en quarantaine des routes par fournisseur.
Un nom de modèle, de nombreux environnements d’inférence
OpenRouter est notre principale passerelle de modèles. L’un de ses atouts est qu’un même modèle peut être servi par de nombreux fournisseurs d’inférence indépendants. Si l’un est indisponible, un autre peut traiter la requête. Nous gagnons ainsi en capacité, en compétitivité tarifaire et en résilience par rapport à un endpoint unique.
Mais cela introduit aussi une variable invisible.
Le nom du modèle peut rester identique alors que l’infrastructure qui le sert change d’une requête à l’autre. Chaque fournisseur peut utiliser un moteur d’inférence, une configuration matérielle, un niveau de quantification, un parseur, un modèle de conversation, une file d’attente ou une couche de règles supplémentaire différente.
La documentation d’OpenRouter sur le routage des fournisseurs explique que le routage par défaut tient compte de la disponibilité récente et du prix, tout en gardant d’autres fournisseurs en secours. Ces signaux comptent, mais un endpoint peut être disponible, peu coûteux et néanmoins produire un résultat inacceptable pour un produit donné.
OpenRouter a également évoqué publiquement les écarts mesurables entre fournisseurs servant un même modèle. En théorie, des poids identiques à précision identique devraient se comporter de façon similaire. En production, servir un grand modèle est complexe, et des différences apparaissent.
Ce que nous appelons « dégradation du modèle »
La « dégradation du modèle » n’est pas un diagnostic unique et normalisé. Elle ne signifie pas non plus automatiquement qu’un fournisseur a volontairement remplacé le modèle par un plus petit.
Nous employons ce terme de manière opérationnelle : un endpoint d’inférence est dégradé lorsqu’il ne préserve plus le comportement, les capacités ou les performances interactives attendus du modèle demandé sur des prompts représentatifs, même si la requête réussit techniquement.
Pour Reverie, les formes les plus nettes sont :
- Dégradation de la latence : la connexion réussit, mais le délai avant le premier token est assez long pour briser la sensation d’une conversation en direct.
- Dégradation des capacités : un endpoint censé prendre en charge les sorties structurées renvoie un texte mal formé ou ne respecte plus le schéma.
- Dégradation comportementale : les réponses sont corrompues, incohérentes, anormalement répétitives ou basculent visiblement vers une autre langue.
- Incompatibilité de politique : un hébergeur ajoute son propre filtre et transforme une scène prise en charge par Reverie en refus, en réponse vide ou en texte tronqué.
Les causes peuvent être nombreuses. Une quantification de plus faible précision peut affecter les prompts difficiles, comme le signalent la documentation d’OpenRouter et les travaux publiés sur la quantification. Mais elle n’explique pas tout : bugs du moteur d’inférence, parseurs d’outils, erreurs de tokenizer ou de modèle de conversation, files saturées et middleware du fournisseur peuvent compter tout autant. OpenRouter a constaté que, pour les appels d’outils, les parseurs créent souvent davantage d’écarts que la seule précision.
La bonne question n’est donc pas « quelle cause paraît la plus suspecte ? », mais « pouvons-nous isoler l’endpoint et reproduire l’échec ? ».
Deux cas qui ont rendu le problème concret
Il ne s’agissait pas d’une inquiétude théorique.
Lors d’une comparaison épinglée par fournisseur, l’un d’eux a corrompu le début de 19 réponses sur 20 en insérant un signe de ponctuation ou un fragment de token sans rapport. Sur quatorze autres hébergeurs du même modèle, le problème est apparu 0 fois en 49 réponses. En roleplay, où le premier caractère est souvent un marqueur d’emphase Markdown, un seul octet parasite pouvait aussi casser la mise en forme de toute la réponse.
Dans un autre test, un endpoint a produit un mélange prononcé de portugais et d’espagnol dans 3 générations sur 3. Le même prompt est resté en portugais sur l’hébergeur officiel du modèle et sur les autres fournisseurs testés avec la même classe de précision. « Le modèle est simplement imprévisible » n’était plus une explication convaincante : le défaut suivait l’endpoint.
Ces pannes sont discrètes, car elles ne déclenchent pas nécessairement d’exception. La supervision classique voit une API en bonne santé. L’utilisateur voit un personnage qui, soudain, ne sait plus parler correctement.
Notre réponse : tester chaque route, pas seulement le modèle
Toutes les trente minutes, notre canari découvre les fournisseurs actifs du modèle de chat par défaut de Reverie. Il envoie ensuite à chacun un petit ensemble de requêtes synthétiques, épinglées sur ce seul fournisseur et sans fallback.
Cet épinglage est essentiel. Si la sonde peut basculer vers un secours, un deuxième fournisseur sain peut masquer la panne du premier. Nous devons savoir précisément quel environnement a produit le résultat.
Le système teste quatre contrats étroits et évaluables par le code.
1. Délai avant le premier token
Dans une conversation en streaming, le débit ne représente que la moitié de l’expérience. Le premier token détermine combien de temps l’utilisateur reste devant un indicateur de chargement.
Nous le mesurons directement dans le flux. Un fournisseur qui ne produit aucun texte dans les dix secondes échoue au test de latence. Le seuil est volontairement généreux et une seule ronde lente ne suffit pas à retirer un hébergeur : une file peut être momentanément chargée.
2. Filtrage et refus silencieux
Nous envoyons une suite de roleplay fixe, représentative du trafic pris en charge par Reverie. La sonde vérifie la raison de fin, les motifs de refus à haute confiance et les sorties vides.
Nous lançons aussi ce test sur des hébergeurs connus pour filtrer, utilisés comme contrôles positifs. Si l’un d’eux passe de manière inattendue, nous ne déclarons pas tous les autres fournisseurs sains : nous signalons que la sonde elle-même est devenue trop faible. Un test incapable de détecter son défaut connu ne prouve rien.
3. Sortie structurée
Nous demandons un petit objet selon un schéma fixe, puis validons le résultat. Une erreur de transport et une sortie mal formée sont traitées différemment : une connexion rompue indique que le fournisseur était inaccessible, tandis qu’une génération terminée qui ne respecte pas le schéma révèle une régression de capacité.
« L’endpoint annonce la prise en charge du paramètre » et « l’endpoint l’honore de façon fiable » ne sont pas la même promesse.
4. Intégrité linguistique
Reverie prend en charge 17 langues d’interface. Un simple test en anglais manquerait donc certains problèmes réellement rencontrés par nos utilisateurs.
Le canari alterne entre les langues prises en charge à l’aide de prompts de roleplay synthétiques. Un détecteur local et déterministe recherche un basculement net de toute la réponse vers une autre langue, un mélange linguistique prolongé et des corruptions d’encodage évidentes. Il n’utilise aucune conversation réelle et ne demande pas à un autre modèle de porter un jugement subjectif.
Une sortie ambiguë ou trop courte est indéterminée, pas défaillante. Lorsqu’une anomalie linguistique est détectée, le canari effectue immédiatement deux essais de confirmation et exige une majorité. La même langue est reprise à la ronde suivante afin que le fournisseur ne contourne pas la règle des rondes consécutives à cause de la rotation.
Un système conçu pour douter de ses propres conclusions
Retirer automatiquement de la capacité d’inférence est utile, mais un faux positif peut provoquer une panne plus grave que le défaut initial. Le canari dispose donc de plusieurs freins :
- Les erreurs de transport ne comptent pas comme des défauts de qualité. Les timeouts, limites de débit et réponses 5xx figent le score au lieu d’allonger une série menant à la suspension.
- Une mauvaise ronde ne suffit pas. Un fournisseur doit échouer à deux rondes consécutives exécutées toutes les demi-heures.
- L’observation et l’application sont séparées. Nous pouvons faire fonctionner le système en mode observation, consigner les hébergeurs qui seraient suspendus, prévenir les administrateurs et mesurer les faux positifs avant d’activer l’action automatique.
- La capacité possède un plancher. Le canari ne suspend pas un fournisseur si cela laisse moins de deux hébergeurs en production. Il alerte alors un administrateur.
- La reprise est elle aussi testée. Les fournisseurs suspendus restent sondés. Deux rondes propres consécutives permettent une restauration anticipée.
- Les récidives entraînent une progression graduelle. La suspension dure un jour au premier incident, trois jours au suivant, puis sept jours. Après quatorze jours sans nouvelle suspension, l’historique s’efface et l’échelle repart du début.
L’objectif n’est pas de punir les fournisseurs. Il est de détourner le trafic utilisateur d’une route dont le mauvais état est reproductible, tout en laissant une voie de retour claire après correction.
Trois couches de protection
La décision finale de routage combine trois types d’exclusions :
- Des exclusions intégrées et revues pour les défauts ou incompatibilités de politique déjà mesurés que nous ne voulons pas réintroduire par accident.
- Des exclusions d’incident à l’exécution qu’un administrateur peut ajouter immédiatement, sans attendre de déploiement.
- Des suspensions temporaires du canari pour les fournisseurs qui franchissent le seuil automatique d’échec.
Ces listes sont fusionnées dans la préférence provider.ignore d’OpenRouter lorsque Reverie construit une requête. L’utilisateur n’a pas à recommencer jusqu’à ce que le hasard choisisse un meilleur fournisseur : la route défaillante est retirée des candidats.
Chaque décision automatique est auditée, les administrateurs sont avertis lors des transitions importantes et une suspension peut être levée manuellement si nécessaire.
Ce que ce système garantit — et ce qu’il ne garantit pas
Le canari est volontairement ciblé. Le code peut juger la latence, la validité du schéma, les filtrages à haute confiance, l’intégrité de la langue et celle de l’encodage. Il ne prétend pas noter si un personnage est assez drôle, assez perspicace émotionnellement ou fidèle à une personnalité complexe.
Ces questions plus larges exigent toujours des évaluations fondées sur des prompts représentatifs, une revue humaine, la télémétrie de production et, surtout, les signalements des utilisateurs.
Ce système ne signifie pas non plus que toute réponse étrange prouve une dégradation. Les modèles génératifs sont probabilistes. Une longue conversation peut accumuler un contexte contradictoire et une définition de personnage peut contenir des consignes concurrentes. Parfois, une réponse étrange n’est qu’une réponse étrange.
Ce qui change, c’est que « c’est le même modèle » ne met plus fin à notre enquête. Nous pouvons maintenant isoler la route, reproduire des défaillances objectives et en éloigner le trafic suivant.
La fiabilité consiste à préserver l’expérience
Le routage multi-fournisseurs reste précieux. Il donne à Reverie la capacité et la résilience nécessaires pour maintenir les conversations lorsque certains endpoints tombent en panne.
Mais la résilience ne se résume pas à recevoir une réponse HTTP. Une réponse qui arrive trop tard, perd la structure attendue, refuse un contenu pris en charge ou change soudain de langue n’est pas saine simplement parce que la facture indique une requête réussie.
Pour un produit de personnages IA, la fiabilité a un sens plus humain : le personnage doit rester lui-même, quelle que soit la machine qui parle en son nom.
C’est le standard que nos nouvelles protections de routage cherchent à préserver.
Si vous remarquez un changement soudain de qualité ou de langue, envoyez-nous un signalement avec le nom du modèle et l’heure approximative. Cela nous aide à relier votre expérience à la route exacte qui l’a produite.