Comment CArouter protège vos conversations d'IA chez le fournisseur

CArouter confie chaque requête à l'un des fournisseurs qui servent le modèle demandé. La plupart des pannes se signalent d'elles-mêmes, par un délai dépassé ou un code d'erreur : notre plateforme passe alors la requête au fournisseur suivant, avant que le premier octet vous parvienne.

D'autres pannes prennent l'allure d'une réponse tout à fait normale. Notre trafic de production en a révélé plusieurs cet automne, et chacune a mené à un changement dans la plateforme. Cet article couvre ce que le fournisseur renvoie, ce qu'il reçoit de votre conversation et l'endroit où elle s'exécute.

Une réponse faite de points d'exclamation

Le 5 novembre, pendant environ cinq heures, un point d'accès qui sert Qwen3.6 35B-A3B a répondu à certains longs prompts par un seul caractère, le point d'exclamation, répété jusqu'à la limite de tokens. Chaque réponse portait un statut de succès et un décompte de tokens complet, et un tour de conversation y perdait d'une à quatre minutes.

Ce caractère trahit la cause. Quand les calculs d'un modèle débordent, ses probabilités pour le token suivant deviennent invalides, et l'échantillonneur choisit le token 0 à chaque étape. Dans le vocabulaire de Qwen, comme dans bien d'autres, le token 0 est justement le point d'exclamation.

Notre plateforme traite désormais ce motif comme une panne du fournisseur :

• Une réponse qui aligne 128 points d'exclamation, dans le texte, le raisonnement ou les arguments d'un appel d'outil, compte comme une tentative échouée.
• Une réponse livrée d'un seul bloc est relancée chez le fournisseur suivant du même modèle, exactement comme après un délai dépassé.
• Un flux est retenu tant que son texte se compose uniquement de points d'exclamation, et son premier vrai token le libère : une réponse saine arrive donc à la même vitesse. Un flux qui s'effondre dès son premier token est relancé ailleurs, et vous recevez seulement la réponse saine.
• Un flux qui s'effondre après vous avoir livré une partie de la réponse se termine par une trame d'erreur que votre application peut relancer. Reprendre une réponse à moitié livrée reste votre décision.
• Dans les deux cas, la tentative est gratuite, et votre page Utilisation l'affiche comme « Réponse dégénérée ».

Sur le point d'accès en cause, nous avons aussi corrigé l'origine du problème : la mémoire récurrente du modèle fonctionne désormais à la précision numérique prévue par ses auteurs.

Une route absente chez un fournisseur

Les fournisseurs servent souvent un même modèle sur Chat Completions et diffèrent sur les autres routes, comme l'API Responses. Un appel vers une route absente chez un fournisseur revenait autrefois en 404, comme si le modèle avait disparu.

Le catalogue recense désormais les routes absentes de chaque offre. Le routeur envoie une requête uniquement aux offres qui servent sa route, une réponse « route not supported » la fait passer au fournisseur suivant, et la documentation indique pour chaque modèle les routes qui fonctionnent.

Un point d'accès qui ralentit avant d'être plein

Chaque point d'accès a un plafond de requêtes simultanées, et un moteur ralentit bien avant de l'atteindre. En octobre, de longs prompts ont attendu plus de 90 secondes sur des points d'accès chargés, pendant qu'un autre point d'accès du même modèle avait de la place.

Un point d'accès compte désormais comme occupé dès la moitié de son plafond. Il reste disponible, mais passe derrière les points d'accès du même fournisseur qui ont de la place : un long prompt va donc là où il obtiendra sa réponse plus vite.

Savoir à qui revient une panne

Sur votre page Utilisation, chaque requête échouée indique à qui revient le problème : la plateforme, le fournisseur, votre propre requête ou une limite de capacité. Une panne de cause inconnue nous est imputée. Une ligne rouge à expliquer nous coûte moins cher qu'une panne mise sur le dos de quelqu'un d'autre.

Ce que le fournisseur reçoit de votre conversation

• Quand le filtre de renseignements personnels est activé sur une clé API, les renseignements personnels détectés, comme les noms, les adresses courriel, les numéros de téléphone, les numéros d'assurance sociale et les numéros d'assurance maladie, sont remplacés par des tokens de remplacement avant que le prompt parvienne au fournisseur, puis restaurés dans la réponse.
• La détection a ses limites, et un texte pseudonymisé demeure un renseignement personnel. La table de correspondance existe uniquement en mémoire, le temps de la requête, et une clé qui exige le filtre est refusée dès que celui-ci est indisponible.
• Sur les moteurs que nous exploitons, le cache de prompts est réservé à votre espace de travail : un début de prompt mis en cache sert uniquement à vos propres requêtes. Paramètres > Confidentialité et données permet de désactiver entièrement cette réutilisation.
• Le message d'erreur d'un fournisseur peut citer votre requête. La même page de paramètres permet de garder uniquement la classification de chaque erreur, et efface le texte déjà stocké.
• Quand l'entente d'un fournisseur exige un identifiant client pour traiter les signalements d'abus, ce fournisseur reçoit une empreinte à clé de votre espace de travail. Les identifiants de vos propres utilisateurs restent chez vous.
• Un fournisseur porte la mention « zéro conservation » seulement après que quelqu'un a lu sa politique publiée et noté la référence. Tous les autres affichent « conservation non vérifiée » : vous choisissez donc en connaissance de cause.
• Chaque connexion à un fournisseur vérifie son certificat TLS, y compris vers les points d'accès que des clients ajoutent eux-mêmes.

Où s'exécute votre conversation

• Une offre servie au Canada par un fournisseur de propriété canadienne passe en premier, quel que soit le prix d'une offre étrangère.
• La bascule reste au Canada. Une requête dont tous les fournisseurs canadiens sont indisponibles est refusée, et elle franchit une frontière seulement pour une clé API qui accepte explicitement les fournisseurs étrangers.
• La bascule reste aussi sur le modèle que vous avez nommé. Un modèle affiné et son modèle de base ont des poids différents : chacun est servi uniquement sous son propre nom.
• Chaque réponse indique sa région de service dans l'en-tête X-CArouter-Region, d'après le rapport du fournisseur lorsqu'il en donne un. Une région inconnue est déclarée UNVERIFIED plutôt que Canada.

Vérifiez-le dans vos propres journaux

Les en-têtes X-CArouter-Provider et X-CArouter-Region nomment le fournisseur qui a répondu et l'endroit d'où il l'a fait. Votre page Utilisation liste chaque requête échouée avec sa cause : vous pouvez donc vérifier chacune de ces règles sur votre propre trafic.

Comparer les modèles et les fournisseurs disponibles. Consulter les règles techniques de routage.