Vercel AI Gateway en production : forces, limites, alternatives
Quand la gateway Vercel est le bon choix, et quand un router dédié gagne

Vercel a shippé sa gateway IA et c'est l'une des options les mieux intégrées si tu es dans l'écosystème Vercel. Ce n'est pas un compliment en demi-teinte — honnêtement, si ton app est Next.js, déployée sur Vercel, utilisant le Vercel AI SDK, l'intégration est aussi proche de l'invisible qu'une intégration de gateway peut l'être.

La vraie question c'est : qu'est-ce qui se passe quand même une de ces trois hypothèses ne tient pas ? Et dans les cas où les trois tiennent, mais où un autre axe — région d'hosting, préférence BYOK, pricing à l'échelle — compte plus ?

Voici la réponse équitable.

Ce que le Vercel AI Gateway fait bien

Intégration avec le Vercel AI SDK

Le Vercel AI SDK est un vrai bon soft. Il abstrait streaming, tool use, structured outputs entre providers avec une ergonomie TypeScript propre. Ajouter la gateway c'est un changement de config — tu utilises déjà le SDK, tu actives la gateway, et tu as fallback, observability, et facturation unifiée sans rien réécrire.

C'est la position la plus forte du Vercel AI Gateway. Si tu es exactement à cet endroit, arrête de lire et utilise-le.

Déploiement pour Next.js

Si ton app Next.js déploie déjà sur Vercel, la gateway vit dans le même plan de contrôle que le reste de ton infra. Un dashboard, une facture, une surface de support. Les env vars passent par les settings Vercel existants. Pas d'onboarding vendor nouveau.

Proximité réseau edge

Le réseau edge Vercel est réel et rapide. Pour les features IA user-facing où la latence vers la gateway compte, la gateway qui tourne à l'edge veut dire moins de hops cross-region avant que ta requête tape le vrai provider.

UI d'observability

L'UI d'observability de Vercel pour la gateway est soignée, consistante avec leurs autres surfaces produit, et te donne des breakdowns par requête, résumés de coût, percentiles de latence sans setup supplémentaire.

Où le Vercel AI Gateway est moins convaincant

Soyons précis sur les limites.

Tu n'es pas sur Vercel

C'est le gros point. La proposition de valeur du Vercel AI Gateway est étroitement couplée à la plateforme Vercel. Si ton app deploie sur AWS, GCP, Fly, Render, une VM Hetzner, ton propre Kubernetes, ou un VPS français, beaucoup de l'avantage d'intégration disparaît. Tu payes la gateway pour des features que des routers spécialisés offrent équivalemment ou mieux.

Tu veux des garanties de résidence des données UE

Vercel est une boîte US avec un CDN global. Pour les équipes qui ont besoin d'une résidence des données UE dure — pas "notre CDN a un edge UE" mais "les prompts et completions de ma personne concernée sont traités en UE sous une infra controlée UE" — les engagements du Vercel AI Gateway sont moins précis que ceux des alternatives UE-hosted dédiées comme HiWay ou un LiteLLM self-hosté en région UE.

C'est une conversation compliance, pas features. Si ton équipe légale demande un DPA listant le traitement UE-only, les services US ne peuvent souvent pas le fournir proprement pour tous les composants, même avec des options régionales dispos.

Tu veux du BYOK proprement

Le Vercel AI Gateway peut marcher avec tes clés provider dans certaines configs, mais le modèle de facturation et de compte sous-jacent est Vercel-centrique. Les routers BYOK dédiés font de la propriété provider un concept first-class — tes clés vivent dans tes comptes provider, les providers te facturent directement, la gateway est purement dans le chemin de contrôle.

Ta dépense est concentrée et en croissance

Le pricing metered au-dessus des coûts provider est doux à faible volume. À plus haut volume — une fois que tu tournes des millions de requêtes LLM par mois — les coûts metered compound. Un modèle de pricing flat par requête (Build à 15 €, Scale à 39 €, ou Business à 249 €/mois peu importe vers quel modèle tu route) peut finir matériellement moins cher à l'échelle — et le smart routing par-dessus coupe typiquement 40-85% de la facture d'inférence indépendamment du volume.

Tu veux du routing basé sur l'intelligence

Le Vercel AI Gateway supporte le fallback provider (essaye A, puis B). Il est moins spécialisé en routing intelligent basé sur la complexité (envoie les prompts simples vers un modèle moins cher, envoie les prompts durs vers un flagship, route basé sur une analyse de prompt en moins d'1 ms). Les routers dédiés comme HiWay construisent leur produit core autour de ça.

Tu veux des contrôles budgétaires profonds

Budgets par endpoint, auto-downgrade aux seuils de dépense, détection burn-rate avec alertes Slack, détection de boucles — la gateway Vercel couvre les bases mais n'est pas optimisée comme surface de contrôle de coût. L'ingénierie de coût est une préoccupation secondaire pour une plateforme dont le job principal c'est "rendre les apps Next.js faciles à deployer".

La décision quand-utiliser

Voici l'arbre de décision honnête :

À quoi ressemble la migration (si tu quittes Vercel AI Gateway)

Si tu utilises déjà le Vercel AI Gateway avec le Vercel AI SDK et tu veux migrer, le changement de code est petit parce que HiWay et le Vercel AI SDK respectent tous les deux la convention compatible OpenAI.

Avant (Vercel AI Gateway) :

import { gateway } from "@ai-sdk/gateway";
import { streamText } from "ai";

const result = await streamText({
  model: gateway("openai/gpt-4.1"),
  prompt: "Hello",
});

Après (HiWay, en restant sur le Vercel AI SDK) :

import { createOpenAI } from "@ai-sdk/openai";
import { streamText } from "ai";

const hiway = createOpenAI({
  baseURL: "https://app.hiway2llm.com/v1",
  apiKey: process.env.HIWAY_API_KEY,
});

const result = await streamText({
  model: hiway("gpt-4-1"),
  prompt: "Hello",
});

Même SDK, même streaming, mêmes APIs de structured output. Tu swap la factory gateway pour un provider OpenAI pointé sur HiWay. Le reste de ton code Vercel AI SDK n'est pas touché.

À quoi ressemble rester sur Vercel AI Gateway

Si après avoir lu ça tu penses que le Vercel AI Gateway est toujours le bon fit — honnêtement, pour beaucoup d'équipes ça l'est — le conseil c'est : pousse l'intégration à fond. Utilise l'UI d'observability. Configure les fallbacks provider. Utilise le pinning de version de modèle. C'est la surface la plus forte de la gateway, et tu en tireras plus en la traitant comme un bout d'infra Vercel-native plutôt qu'un router générique.

Un mot sur les bundles

Les bundles plateforme comme Vercel — où hosting, gateway, observability, et analytics viennent tous d'un seul vendor — sont opérationnellement pratiques et portent un risque structurel. Le risque c'est que les features bundlées sont rarement best-in-class sur n'importe quel axe unique, et avec le temps tu accumules une dépendance sur la forme précise du bundle. Quand tu veux changer un morceau, tu finis souvent par en changer plusieurs.

Ce n'est pas une critique Vercel ; c'est vrai de tout bundle plateforme (AWS, GCP, Cloudflare, Render). La question à poser régulièrement c'est : "Est-ce que je choisirais encore chaque morceau de cette stack individuellement si je choisissais aujourd'hui ?" Si la réponse est oui, le bundle marche. Sinon, ça vaut le coup de réfléchir à quels morceaux unbundler en premier.

La gateway LLM est souvent un bon candidat pour l'unbundling parce que la surface d'intégration est étroite (quelques appels API) et le paysage vendor est riche.

Le résumé honnête

Le Vercel AI Gateway n'est pas un mauvais produit. C'est une gateway bien construite, bien intégrée pour la population précise d'équipes qui vivent dans l'écosystème Vercel. Pour ces équipes, l'avantage d'intégration est réel et souvent décisif.

Pour les équipes hors de cet écosystème — ou dedans mais avec des contraintes dures sur hosting UE, BYOK, ou coût à l'échelle — les routers dédiés gagnent typiquement. Pas parce qu'ils sont plus flashy, mais parce que leur focus produit est plus étroit et leurs incitations pointent plus directement vers la chose pour laquelle tu achètes une gateway en premier lieu.

Choisis celle qui fit la forme de ton équipe, pas celle avec la démo la plus soignée.

Prochain : le routing LLM et le RGPD — ce que les gateways US-hosted ne te disent pas.