Routing par latence vs routing par coût vs routing par qualité
Quand choisir lequel

Il y a trois axes de routing possibles : la latence, le coût, ou la qualité. La plupart des systèmes routent par coût parce que le coût est facile à mesurer. La latence est plus difficile. La qualité est encore plus difficile. Et celui que vous devriez réellement prioriser dépend entièrement du workload - c'est pourquoi opter par défaut pour le coût est généralement une erreur.

Les trois stratégies de routing

Router par coût

Choisir le provider le moins cher capable de traiter la requête au-dessus d'un seuil de qualité minimal.

Quand ça fonctionne : Les jobs en arrière-plan, le traitement par lots, les pipelines asynchrones. Tout workload où l'utilisateur n'attend pas une réponse immédiate. Indexation de documents, files de modération de contenu, génération de rapports nocturnes.

Quand ça échoue : Toute interface utilisateur où le temps d'attente ressemble à un bug. À 900ms de TTFT (Gemini Pro un mauvais jour), un chatbot semble cassé même si la réponse est correcte.

Le calcul : Router tout par coût donne environ Gemini Flash pour les requêtes simples (0,19 $/1M tokens en blended) et GPT-4o pour les complexes (6,88 $/1M). Économies moyennes vs. Claude 3.5 Sonnet partout : ~65%.

Router par latence

Choisir le provider le plus rapide qui satisfait un seuil de qualité minimal, quel qu'en soit le coût.

Quand ça fonctionne : Le chat temps réel, les interfaces vocales, l'autocomplétion, les suggestions de code live. Tout UX où la vitesse perçue est le produit.

Le p99 compte plus que la médiane. Groq à 65ms de médiane, 280ms en p99 est meilleur que GPT-4o à 620ms de médiane même si Groq atteint parfois 400ms - parce que le p99 de GPT-4o est à 2 100ms. Le pire jour de Groq bat la moyenne de GPT-4o pour les chemins critiques en latence.

Le coût : Groq Llama 3.1 70B à 0,70 $/1M tokens blended n'est pas le moins cher, mais reste abordable. Le delta de coût par rapport au routing qualité en vaut généralement la peine pour toute interaction où l'utilisateur attend activement.

Router par qualité

Choisir le provider au meilleur score qui rentre dans un plafond de coût défini.

Quand ça fonctionne : Tout ce qui implique un relecteur humain dans la boucle. Rédactions juridiques, notes médicales, tâches de raisonnement complexe où les erreurs ont des conséquences réelles. L'utilisateur n'attend pas de façon synchrone - il relira le résultat plus tard, et une amélioration de qualité de 20% vaut une multiplication du prix par 3.

Le piège : Le routing qualité sans plafond devient "router tout sur Claude 3.5 Sonnet", ce qui est le comportement par défaut dans lequel la plupart des équipes se retrouvent accidentellement. Le routing qualité n'a de sens que si vous avez défini le plafond.

L'arbre de décision routing en conditions réelles

En pratique, vous ne choisissez pas une seule stratégie. Vous les empilez :

1. Cette requête doit-elle se terminer en < 300ms pour un bon UX ?
   → OUI : router par latence (Groq > Haiku > GPT-4o-mini)
   → NON : continuer

2. Est-ce un job background ou asynchrone ?
   → OUI : router par coût (Gemini Flash > GPT-4o-mini > Haiku)
   → NON : continuer

3. Un humain relira-t-il ce résultat avant qu'il impacte quelque chose d'important ?
   → OUI : router par qualité (Claude 3.5 Sonnet > GPT-4o > Gemini Pro)
   → NON : router par coût avec un seuil de qualité à 75+

La plupart des équipes court-circuitent à l'étape 3 et envoient tout sur Claude 3.5 Sonnet. Résultat : payer un prix qualité pour des tâches sensibles à la latence où Groq serait identique du point de vue de l'utilisateur, et pour des tâches asynchrones où Gemini Flash est 50× moins cher.

L'erreur qui aggrave les trois stratégies

Router après que la requête est déjà en vol.

Si votre décision de routing a lieu au niveau de la couche proxy après que le client s'est connecté et attend, vous avez déjà payé le coût de la connexion au provider "rapide". Le vrai gain de latence avec Groq vient quand la décision de routing est prise avant que la requête atteigne le provider - pas en cours de vol.

Cela signifie que votre couche de routing doit classifier la requête en moins d'1ms, avant de choisir un provider. La classification via un petit modèle local (ou un classifieur à règles sur les métadonnées de la requête) est le bon pattern. La classification via un second appel LLM pour "décider quel modèle utiliser" est plus lente qu'utiliser Claude 3.5 Sonnet pour tout.

La couche CORTEX de HiWay2LLM classifie en moins de 0,4ms grâce à une combinaison d'heuristiques sur le nombre de tokens et de règles sur le type de tâche dérivées des patterns de requêtes. Aucun appel de modèle dans le hot path.

Le routing blended : ce qui passe réellement en production

En production, la plupart des équipes finissent avec une stratégie blended :

• Tier latence pour les chemins interactifs (chat, recherche, autocomplétion) → Groq ou Haiku
• Tier coût pour les chemins background (indexation, batch eval, jobs nocturnes) → Gemini Flash
• Tier qualité pour les étapes de planification d'agents et les résultats revus par des humains → Claude 3.5 Sonnet

La règle de routing n'a pas besoin d'être intelligente. Elle doit être cohérente. Une simple correspondance endpoint → tier surpasse un classifieur ML sophistiqué en termes de prévisibilité et de debuggabilité.

Le résultat dans nos benchmarks : le routing blended sur ces trois tiers coûte 2,40 $/1M tokens en moyenne vs. 9,75 $ avec Claude 3.5 Sonnet partout - soit une réduction de 75% sans perte de qualité perceptible sur 90% des requêtes.

Une configuration de départ qui fonctionne

Voici un point de départ qui convient à la plupart des produits SaaS IA :

Ce n'est pas la configuration optimale pour chaque produit. Mais c'est meilleur que le comportement par défaut, et c'est auditable - vous pouvez voir exactement pourquoi chaque requête coûte ce qu'elle coûte.