HiWay2LLM vs Cloudflare AI Gateway

Cloudflare AI Gateway et HiWay2LLM revendiquent tous les deux le mot "gateway", se posent tous les deux entre ton app et le LLM upstream, et sont tous les deux OpenAI-compatible sur le fil. Si tu lis vite les landings, ils ont l'air substituables. Ils ne le sont pas. Ils opèrent à des couches différentes et optimisent pour des choses différentes.

Le produit Cloudflare c'est une edge gateway : une couche de cache, de rate-limiting et d'analytics déployée sur le réseau global de Cloudflare. Tu proxy tes appels LLM à travers une URL comme https://gateway.ai.cloudflare.com/v1/<account>/<gateway>/openai, et tu obtiens cache, retries, rate limits et analytics pour quasi rien au hobby. C'est l'équivalent AI de mettre Cloudflare devant un site.

Le produit HiWay c'est un model router : il lit chaque requête, score la complexité en moins d'1 ms, et choisit le modèle le moins cher capable — avec BYOK et 0% de markup sur l'inférence. Ce n'est pas un CDN. Il ne cherche pas à cacher à l'edge. Son job c'est que le bon modèle réponde à la requête.

Au sens strict ce ne sont pas des produits concurrents. Ils opèrent à des couches différentes de la stack. Mais comme la plupart des équipes n'ont du budget et de la bande passante d'intégration que pour un seul middleware, la comparaison pratique compte.

Décision rapide

• Une grosse partie de ton trafic LLM c'est des questions répétées (support bots, Q&A doc avec hot spots, boucles de classif) ? Les cache hits de Cloudflare sont quasi gratuits et feront fortement descendre ta facture sur la tranche cacheable.
• Ton trafic c'est surtout des requêtes uniques (agents, prompts custom, contexte par utilisateur) ? Le cache ne sert à rien ; il te faut un router qui choisit des modèles moins chers par requête. HiWay.
• Tu es déjà tout-in sur Cloudflare Workers et tu veux tout à l'edge ? Cloudflare AI Gateway est le choix natif ; il se pose à côté de tes Workers.
• Tu veux un middleware hébergé en EU avec DPA signé et 0% markup sur l'inférence ? HiWay est hébergé sur OVH en EU, avec BYOK et facturation wholesale par provider.
• Tu veux les deux, cache edge ET routing par complexité ? Empile-les. Cloudflare devant pour le cache + rate-limiting, HiWay pour le routing. Les exemples de migration ci-dessous montrent la forme.

Pricing

Cloudflare AI Gateway est connu pour être peu cher. Au hobby/faible volume c'est gratuit, et les tiers payants scale avec les features avancées et le volume (check les pages pricing Cloudflare Workers et AI Gateway au 2026-04-22 pour le détail actuel). Tu payes toujours le provider LLM upstream pour l'inférence — Cloudflare est un proxy, pas un revendeur.

HiWay te facture un flat fee mensuel pour la couche routing. L'inférence est facturée par le provider directement sur ta carte chez eux au wholesale (BYOK, 0 % markup côté tokens) :

Le smart routing downgrade aussi automatiquement les requêtes simples vers des modèles moins chers — 40-85 % d'économies sur un mix typique — et bat les 15 €/mois de l'abo Build en quelques heures d'usage réel, à n'importe quelle échelle.

Ces prix ne se comparent pas directement parce qu'ils font des jobs différents. Le pricing ultra peu cher de Cloudflare est possible en partie parce que le cache et les analytics sont commodifiés à leur échelle. Le pricing de HiWay est en ligne avec les middlewares LLM dédiés parce que l'intelligence de routing est le produit. Si c'est du pure cache edge qu'il te faut, le plancher de prix Cloudflare est imbattable. Si tu as besoin d'un router qui baisse le coût par requête, HiWay est pricé pour ce job-là.

Feature par feature

Quand choisir lequel

Migration — ce qui change vraiment dans ton code

Si tu es sur Cloudflare AI Gateway, ta base URL c'est le pattern de proxy gateway (https://gateway.ai.cloudflare.com/v1/<account_id>/<gateway>/openai). Switcher vers HiWay c'est un simple swap de base URL plus un changement de clé API — le reste du code client ne bouge pas.

from openai import OpenAI

client = OpenAI(
  base_url="https://gateway.ai.cloudflare.com/v1/ACCOUNT_ID/GATEWAY_ID/openai",
  api_key="sk-openai-...",
)

response = client.chat.completions.create(
  model="gpt-4o",
  messages=[{"role": "user", "content": "Bonjour"}],
)

from openai import OpenAI

client = OpenAI(
  base_url="https://app.hiway2llm.com/v1",
  api_key="hw_live_...",
)

response = client.chat.completions.create(
  model="auto",  # laisse le router choisir
  messages=[{"role": "user", "content": "Bonjour"}],
)

Deux étapes en plus avant le switch : ajoute tes clés providers une fois dans le dashboard HiWay (Settings → Providers), et garde model: "auto" si tu veux laisser le router choisir — ou pin un modèle précis si tu veux le forcer.

Edge gateway vs model router — deux jobs différents

La manière la plus claire de voir pourquoi ce ne sont pas les mêmes produits : imagine ton trafic LLM aujourd'hui, et regarde où le pognon part en fumée.

Si le pognon part sur des requêtes identiques répétées, une edge gateway l'économise. Cloudflare cache la réponse pour des prompts identiques à l'edge, sert la réponse cachée en quelques dizaines de millisecondes, et tu ne payes pas du tout le LLM upstream sur un cache hit. C'est la forme classique CDN, appliquée à l'AI. C'est extraordinairement peu cher parce que c'est de l'infra commodity qui tourne à l'échelle de Cloudflare.

Si le pognon part sur des requêtes uniques qui tapent le mauvais modèle (trop cher), une edge gateway ne fait rien. Chaque prompt est différent, rien ne cache, et tu continues à payer les tarifs GPT-4 pour répondre à "c'est quoi 2+2 ?" parce que c'est ce que ton code a demandé. Ici ce qui économise, c'est le routing : lire le prompt, scorer sa complexité, envoyer les simples sur des modèles classe Haiku et garder les gros pour les jobs qui en ont besoin. C'est ce que fait HiWay.

Deux couches, deux jobs. Pas concurrents — complémentaires en théorie. La raison pour laquelle les équipes n'en prennent souvent qu'un, c'est pas que l'autre est mauvais, c'est que chaque middleware de plus c'est un hop de plus dans le hot path, un truc de plus à opérer, un truc de plus qui peut casser. Si un hop te donne 80% des économies, tu t'arrêtes là.

Certaines équipes empilent quand même : Cloudflare en edge extérieure pour le cache, le rate-limiting et la protection DDoS, puis HiWay comme router à l'intérieur. Le flow c'est app → Cloudflare AI Gateway → HiWay → provider upstream. Les cache hits ne touchent jamais HiWay ni le provider. Les cache misses passent par HiWay, sont scorés, sont routés sur le modèle le moins cher capable, et payent au wholesale. C'est une archi légitime si la couche cache gagne sa place sur ton pattern de trafic.

Données & compliance

Cloudflare AI Gateway est déployée sur l'edge global de Cloudflare. C'est le but — latence basse partout. Les analytics peuvent capturer prompts et réponses selon la config ; check les docs Cloudflare actuelles pour les options de résidence et la rétention des données sur ton plan. Si la résidence EU stricte est une exigence dure, valide le plan avant de t'engager.

HiWay est opéré depuis la France par Mytm-Group, hébergé sur OVH en EU. Zéro logging des prompts par défaut — les prompts transitent en mémoire et ne sont jamais persistés. On signe un DPA sur demande (même en free plan) et on publie nos sous-traitants. Si tu as besoin de logs de requêtes pour ton propre debug, c'est opt-in par workspace.

Pour les équipes dont la posture compliance exige de la résidence EU sans config supplémentaire, le défaut HiWay passe tout seul. Pour les équipes déjà sur l'infra Cloudflare avec une posture compliance qui accepte le traitement de données de Cloudflare, Cloudflare AI Gateway est une option zéro-nouveau-vendor.

FAQ

Bilan

Cloudflare AI Gateway et HiWay sont tous les deux légitimes, mais ce ne sont pas des substituts. Cloudflare c'est une couche de cache et d'analytics edge — fantastique quand ton trafic est cacheable ou quand tu veux tout à l'edge pour quasi rien. HiWay c'est un model router qui choisit des modèles moins chers capables par requête — fantastique quand ta facture vient de sur-payer sur les appels uniques.

Si ton trafic est répétitif, cache-le à l'edge. Si ta facture vient du sur-paiement par requête, route-le plus intelligemment. Si c'est les deux, empile-les.

Quand la facture est le chiffre à bouger, mets ta dépense actuelle dans le calculateur d'économies et regarde ce que le routing par complexité en fait.