Vercel AI Gateway : les « modèles virtuels » pour changer de modèle sans redéployer

Quand une application appelle un modèle d'IA, son nom est en général écrit dans le code. En changer oblige à redéployer. Avec les agents de code, c'est pire : chaque développeur a sa propre configuration, et ces outils ne savent souvent pas transmettre de réglages fins à la passerelle. Vercel répond à ce problème avec les « modèles virtuels » de son AI Gateway, annoncés le 28 octobre 2026.

Le principe

Un modèle virtuel est une configuration enregistrée : un modèle du catalogue, plus les réglages qui doivent accompagner chaque requête. Il reçoit un identifiant de la forme vmc/<nom>. L'application ou l'agent appelle cet identifiant comme un modèle ordinaire. Si l'on modifie la configuration, le changement s'applique aux nouvelles requêtes en quelques minutes, selon la documentation, sans toucher au code.

Parmi les réglages possibles :

• l'ordre des fournisseurs à essayer, ou une liste fermée de fournisseurs ;
• des modèles de repli si tous les fournisseurs du modèle principal échouent ;
• une région d'inférence ;
• l'obligation de passer par des fournisseurs sans conservation des données, ou qui n'entraînent pas leurs modèles sur les requêtes ;
• des étiquettes pour attribuer la dépense à une équipe ou à un projet.

Créer un modèle virtuel

La création se fait dans le tableau de bord ou en ligne de commande. Cet exemple, repris de la documentation et allégé d'une option, épingle un modèle sur l'Europe, avec deux fournisseurs dans l'ordre :

vercel ai-gateway virtual-models create coding-agent-eu \
  --model anthropic/claude-opus-5.5 \
  --provider-order bedrock,vertex \
  --config '{
    "inferenceRegion": { "scope": "zone", "geoRegion": "eu" },
    "observabilityTags": ["coding-agents"]
  }'

Il suffit ensuite d'utiliser vmc/coding-agent-eu partout où l'on indiquait le nom du modèle. Pour les agents de code, la commande vercel ai-gateway setup les relie à la passerelle ; le modèle virtuel apparaît alors dans leur sélecteur de modèles.

Qui l'emporte en cas de conflit

La règle est simple : ce que le modèle virtuel fixe s'impose, et la valeur envoyée par la requête est ignorée. Ce qu'il laisse vide reste au choix de l'appelant. Les réglages de conformité, eux, ne font que se durcir : aucune des deux parties ne peut désactiver la non-conservation des données si l'autre l'a activée. Et un modèle virtuel ne peut jamais assouplir un réglage défini pour toute l'équipe.

Les limites à connaître

• La région ne couvre pas tout. D'après la documentation, la région d'inférence ne s'applique qu'aux requêtes passant par les identifiants de Vercel. Si vous utilisez vos propres clés de fournisseur, elle ne joue pas.
• L'ordre n'est pas une restriction. Avec un simple ordre de fournisseurs, les autres peuvent encore servir la requête en secours. Pour l'interdire, il faut la liste fermée, au risque d'un échec si tous les fournisseurs listés sont en panne.
• Le nom est définitif. L'identifiant ne peut plus être modifié après création.
• L'archivage coupe le service. Un modèle virtuel archivé renvoie une erreur 404. En ligne de commande, la suppression s'exécute sans demande de confirmation.

Ni l'annonce ni la page de documentation ne mentionnent de tarif propre à cette fonction.

Notre lecture

Pour une petite équipe, l'usage le plus utile est celui des agents de code : un seul identifiant partagé, épinglé sur l'Europe et sur des fournisseurs sans conservation, que l'on fait évoluer en un endroit. C'est aussi un bon moyen de sortir les noms de modèles du code.

Il faut toutefois voir ce que l'on échange. La dépendance à un fournisseur de modèles diminue, celle à la passerelle augmente : routage, règles de conformité et suivi des coûts vivent désormais chez Vercel. Cloudflare a publié une fonction voisine le 4 novembre, les alias de modèles de son AI Gateway. Dans les deux cas, gardez une copie de vos configurations et vérifiez, sur une requête réelle, quel fournisseur et quelle région ont effectivement répondu.