Comparatif des LLM Gateways — 12 outils sur 10 critères

Il y a trop de LLM gateways pour que la plupart des équipes les évaluent une par une. L'espace s'est rempli vite : chaque cloud, chaque vendor d'observabilité, chaque startup d'outillage IA a shippé une gateway. L'outillage se recouvre. Les différenciateurs sont subtils. Et les pages marketing se ressemblent toutes.

Cette page est une matrice en un coup d'œil : 12 outils qui reviennent dans la plupart des short-lists, comparés sur 10 critères qui différencient vraiment. L'objectif est de faire passer la recherche d'une semaine à un après-midi. Tout ci-dessous est d'après la doc publique de chaque outil au 2026-04-22 — si une cellule te paraît fausse, dis-le nous et on corrige.

Les 12 outils

Le champ est plus large, mais ces douze apparaissent dans presque chaque comparaison qu'on voit en pratique :

• HiWay2LLM — router BYOK avec smart routing au niveau modèle, hébergé EU.
• OpenRouter — agrégateur en modèle reseller avec un énorme catalogue, hébergé US.
• LiteLLM (OSS) — la lib Python self-hosted devenue standard de fait.
• LiteLLM Cloud — la version managée de la lib.
• Vercel AI Gateway — gateway BYOK sur l'edge Vercel, intégration AI SDK serrée.
• Portkey — gateway BYOK-first avec observabilité profonde, posture entreprise.
• Helicone — observabilité d'abord, gateway comme effet de bord du proxy.
• Cloudflare AI Gateway — edge-native, BYOK, caching + analytics sur Cloudflare.
• LangSmith — la suite observabilité + évaluation de LangChain ; gateway-adjacent.
• Requesty — gateway BYOK d'optimisation de coût, plus petite et plus jeune.
• Martian — gateway de routing issue de la recherche, focalisée sur les trade-offs qualité/coût modèle.
• Unify — router positionné sur la sélection dynamique de provider avec benchmarks.
• Kong AI Gateway — la couche IA de l'API gateway Kong ; ADN d'api-gateway entreprise.

Les 10 critères

Ce sont les axes qui comptent dans les vraies discussions d'achat :

1. Modèle de prix — reseller (marge % sur tokens), abonnement fixe, usage-based sur les requêtes proxifiées, ou gratuit/OSS.
2. BYOK — tu apportes tes clés providers, ou la gateway les détient ?
3. Type de smart routing — aucun, fallback-provider (même modèle, autre upstream), ou niveau-modèle (choisit un modèle différent selon la difficulté de la requête).
4. Hébergement EU — existe-t-il un vrai data path EU-only, y compris le control plane ?
5. API OpenAI-compatible — ton code OpenAI SDK existant peut-il pointer dessus juste avec un swap de base_url ?
6. Prompt logging par défaut — les prompts sont-ils loggés par défaut, ou le logging est-il off par défaut ?
7. DPA disponible — peux-tu signer un DPA article 28 sur n'importe quel plan (oui / entreprise-only / non) ?
8. Burn-rate alerts — alerte-t-il proactivement quand la dépense s'envole ?
9. Taille du catalogue modèles — nombre approximatif de modèles supportés.
10. Primary job — ce pour quoi le produit est vraiment optimisé : routing, observabilité, ou edge/API-management.

La matrice

Les noms concurrents cliquables mènent à notre page /compare/<slug> plus profonde quand elle existe.

Deux notes pour lire ça :

• "Fallback-provider" veut dire que la gateway route vers un autre host upstream du même modèle si l'un est down. "Niveau-modèle" veut dire que la gateway peut choisir un modèle différent selon la requête (moins cher, plus rapide, mieux adapté). Ce sont deux features différentes. Les deux sont utiles. Ce n'est pas la même chose.
• "Prompt log défaut : off" ne veut pas dire que la gateway ne peut pas logger — ça veut dire que le défaut est off et que tu actives si besoin. Cette posture compte sous RGPD parce que la donnée que tu ne stockes pas est la donnée que tu ne peux pas fuiter.
• "DPA : tous les plans" vs "DPA : entreprise" est une vraie friction d'achat. Un DPA sur tous les plans veut dire que tu peux onboarder un client compliance-aware sans cycle commercial.

Comment utiliser la matrice

Trois manières honnêtes de rétrécir.

Commence par la colonne primary job. Si tu as besoin d'observabilité, la plupart des outils routing-first sont le mauvais point de départ (et vice versa). Helicone et LangSmith sont des produits d'observabilité. Cloudflare et Vercel sont edge/platform-native. HiWay, Portkey, Requesty, Martian, Unify sont routing-first. LiteLLM est routing-en-lib. OpenRouter est routing-en-agrégateur. Kong est une API gateway qui a ajouté une couche IA. Savoir quel job tu achètes coupe la liste en deux.

Ensuite filtre sur le modèle de prix. Reseller vs abonnement fixe vs usage-based vs OSS sont des relations fondamentalement différentes. Si tu as un mandat interne pour éviter la tarification pourcentage-de-dépense, OpenRouter est out. Si tu veux zéro coût fixe, tout ce qui a un abonnement est out. Ça fait généralement passer la liste de six à trois.

Ensuite filtre sur les colonnes compliance qui te concernent. Hébergement EU, prompt logging par défaut, disponibilité du DPA — ce sont des questions oui/non pour la plupart des acheteurs. Si l'hébergement EU est obligatoire, la liste s'effondre sur HiWay, LiteLLM self-hosted, et Kong self-hosted, plus les options EU-entreprise de Portkey et Vercel. C'est généralement une liste assez courte pour demo.

Trois filtres, dix minutes, short-list. Le reste c'est du détail.

Ce que la matrice ne peut pas te dire

Un gros tableau comme celui-là est un bon premier filtre, mais il cache trois choses.

1. La maturité de la logique de routing. "Smart routing niveau-modèle" couvre un spectre allant de "une règle que tu écris à la main en config" à "un modèle de scoring entraîné sur des millions de requêtes". La différence de qualité est énorme, et elle n'apparaît qu'en prod. Demo les 2–3 top candidats avec ton propre trafic.

2. La posture de support. Une gateway d'une startup de 10 personnes et une gateway de Cloudflare se comportent différemment quand quelque chose casse à 3h du matin. Aucune n'est automatiquement meilleure — les startups shippent plus vite, les gros vendors sont plus stables — mais le profil ops est différent.

3. La forme du lock-in vendor. "API OpenAI-compatible" réduit le lock-in énormément, mais pas à zéro. Les primitives workspace, les schémas d'analytics, la syntaxe des règles de fallback — tout ça est spécifique vendor. Migrer c'est en général un après-midi, mais "en général" fait du travail dans cette phrase.

Utilise la matrice pour short-lister. Utilise un POC d'une semaine avec du vrai trafic pour choisir le gagnant.

Deep-dives côte à côte

Les pages /compare/<slug> vont plus loin que cette page ne peut aller — maths de prix, code de migration, comparaison feature par feature, FAQ par concurrent. Celles publiées actuellement :

• HiWay2LLM vs OpenRouter
• HiWay2LLM vs LiteLLM
• HiWay2LLM vs Vercel AI Gateway
• HiWay2LLM vs Portkey
• HiWay2LLM vs LangSmith
• HiWay2LLM vs Requesty

D'autres sont dans la roadmap. S'il y a une comparaison spécifique qu'il te faut et qu'on n'a pas, dis-le nous.

Conclusion

Douze outils, dix critères, et la vraie décision se résume presque toujours à trois filtres : quel job tu recrutes la gateway pour faire, quel modèle de prix colle à ta courbe de coût, et quelles cases de compliance tu dois cocher. Tout le reste est du détail utile une fois la short-list à trois ou quatre produits — mais c'est du bruit si tu essaies d'évaluer les douze sur chaque axe en parallèle.