Vercel AI Gateway : guide de production pour le routage, l'observabilité, les budgets et le contrôle des fournisseurs

Pourquoi Vercel AI Gateway compte pour les applications IA en production

La plupart des produits IA commencent par un seul appel : choisir un modèle, ajouter un SDK, écrire une invite et publier une fonctionnalité utile. Résumé. Classification. Rédaction. Triage du support. Assistance à la recherche interne. Cette première version peut être tout à fait raisonnable.

Le désordre arrive généralement plus tard. Un deuxième workflow a besoin d'un autre modèle. Un troisième workflow diffuse en streaming. Un autre appelle des outils. La finance demande qui possède la dépense. La sécurité demande quels fournisseurs peuvent recevoir quelles invites. Le produit veut une solution de secours, mais l'ingénierie ne sait pas si cette solution se comportera de la même manière. C'est le moment où l'accès aux modèles cesse d'être un choix de bibliothèque et devient un modèle opérationnel.

Vercel AI Gateway est utile à ce moment-là. Vercel le présente comme un moyen d'appeler des modèles IA chez plusieurs fournisseurs via l'AI SDK ou un endpoint HTTP compatible OpenAI. En pratique, il peut devenir une couche de contrôle entre le code applicatif et les fournisseurs de modèles. Cette frontière peut centraliser le routage, l'examen de l'utilisation, les budgets, la politique fournisseur et certains contrôles de conservation des données sans obliger chaque équipe produit à câbler ces préoccupations dans chaque fonctionnalité.

Voici l'avis direct : les équipes ne devraient pas adopter une passerelle IA parce qu'elles veulent de l'optionalité sur les modèles. Elles devraient l'adopter parce qu'elles sont prêtes à gérer cette optionalité. Ce sont deux choses différentes.

Une passerelle ne rendra pas de faibles invites meilleures. Elle ne prouvera pas que deux fournisseurs sont interchangeables. Elle ne fera pas baisser les coûts à elle seule. Les résultats dépendent de la conception de la charge de travail, du choix du modèle, de la taille des invites, des nouvelles tentatives, de la mise en cache, de la disponibilité des fournisseurs, de la qualité de l'évaluation, des paramètres de confidentialité et d'une discipline opérationnelle simple. Traitez Vercel AI Gateway comme un point de contrôle, pas comme un raccourci autour de l'ingénierie de production.

Ce que Vercel AI Gateway fournit réellement

La présentation de Vercel AI Gateway décrit l'accès à des modèles chez plusieurs fournisseurs, avec des exemples d'utilisation de l'AI SDK et un endpoint de complétions de chat compatible OpenAI à ai-gateway.vercel.sh. Cela donne aux équipes une surface d'intégration unique pour des appels qui seraient autrement répartis entre SDK fournisseurs, clés fournisseurs et code de requête propre à chaque fournisseur.

C'est précieux. Il est aussi facile d'en tirer trop de conclusions. Un endpoint partagé ne rend pas tous les modèles interchangeables. Les fournisseurs peuvent différer par leur comportement de streaming, leurs formats d'appels d'outils, leurs métadonnées, leurs contrôles de sécurité, leur prise en charge de l'image ou de l'audio, leurs limites de contexte et leurs schémas d'erreur. Les fils de discussion de la communauté dans le dépôt Vercel AI montrent des échanges en cours autour du comportement d'AI Gateway, notamment la gestion des métadonnées, les résultats d'outils, le placement des messages système, le comportement des flux et les erreurs fournisseurs. La leçon pratique est simple : une passerelle réduit la dispersion des intégrations, mais la compatibilité doit tout de même être testée.

Vercel documente aussi un démarrage rapide d'évaluation AI Gateway utilisant l'API Evaluation expérimentale dans AI SDK 7 ou version ultérieure. C'est important, car les décisions de routage doivent être jugées par rapport aux résultats de la tâche, pas seulement par rapport à des réponses HTTP réussies. Pour les sorties structurées, validez la conformité au schéma et le comportement de récupération. Pour les workflows d'assistant, vérifiez le respect des instructions, le comportement de refus, l'ancrage dans la récupération, la forme des appels d'outils et l'utilité. Pour les flux d'agents, reliez cette décision à la sélection d'un runtime durable pour agents IA, car le routage interagit avec les nouvelles tentatives, les approbations, l'état et la revue humaine.

L'observabilité de la passerelle est une autre capacité clé. La documentation d'observabilité de Vercel indique qu'AI Gateway journalise les dépenses, l'utilisation des modèles et les métriques liées aux requêtes, avec des vues par projet et par clé API. La documentation budgétaire de Vercel identifie des portées de budget au niveau de l'équipe, du projet, de la clé API et de l'utilisateur, et indique que les budgets sont vérifiés avant chaque requête. Ces contrôles aident, mais ce sont des garde-fous. L'application reste responsable de la longueur des invites, de la mise en cache, des nouvelles tentatives, de l'attribution par fonctionnalité, de l'expérience utilisateur et de la réponse aux incidents. Les équipes qui ont besoin de traces couvrant invites, récupération, outils, utilisateurs et événements en aval devraient associer les données de la passerelle à OpenTelemetry GenAI tracing ou à un plan de traçage similaire.

La documentation de liste d'autorisation des fournisseurs de Vercel permet aux propriétaires d'équipe de restreindre les fournisseurs pouvant servir des requêtes via la passerelle. Sa documentation sur la conservation zéro des données décrit les contrôles ZDR éligibles via les paramètres du tableau de bord et les options par requête. Ces contrôles comptent pour la gouvernance, mais ils nécessitent tout de même une revue propre à chaque route. Tous les fournisseurs, modèles, fonctionnalités ou postures contractuelles ne conviendront pas à toutes les exigences de traitement des données.

Le cadre Route, Observe, Govern

Le cadre Route, Observe, Govern d'Optijara est une façon compacte de décider si Vercel AI Gateway doit être placé devant un workflow de production.

Route demande ce qui peut passer sans risque d'un fournisseur à l'autre. Classez chaque appel de modèle selon l'impact utilisateur, la sensibilité à la latence, la sensibilité des données, le comportement propre au modèle, la tolérance au secours et la couverture d'évaluation. Un assistant interne de brouillon revu par un humain peut tolérer des changements de fournisseur si le ton et le format restent acceptables. Un workflow d'extraction sensible à la conformité, un agent utilisant des outils ou une fonctionnalité qui dépend du comportement d'API propre à un fournisseur peut nécessiter une route épinglée ou une intégration directe avec le fournisseur. Si un workflow ne peut pas être évalué, il ne devrait pas être rerouté librement.

Observe demande quelles preuves sont nécessaires avant et après les changements de routage. Au minimum, enregistrez la version de l'invite, le modèle, le fournisseur, le chemin de route, la latence, l'utilisation des tokens, la classe d'erreur, la validité de la sortie structurée et le résultat visible par l'utilisateur. Si le workflow utilise la récupération ou des documents, ajoutez des identifiants de source et des contrôles de provenance. La même discipline s'applique aux systèmes RAG, où la gestion des sources et la qualité des fragments peuvent compter autant que la route du modèle. Le guide Docling PDF RAG d'Optijara est un complément utile pour les workflows riches en documents.

Govern demande qui possède la politique fournisseur, les budgets, les paramètres de conservation, les dépréciations de modèles, les suites d'évaluation et les exceptions. Une liste d'autorisation de fournisseurs n'aide que si quelqu'un la révise. Un budget n'aide que si le produit dispose d'un plan pour ce que les utilisateurs voient lorsqu'une requête est rejetée. La gouvernance doit définir les propriétaires, les intervalles de revue, les chemins de retour arrière et les preuves d'incident.

{
  "framework": "Route, Observe, Govern",
  "route": ["workflow inventory", "provider fit", "fallback tolerance"],
  "observe": ["quality", "latency", "spend", "errors", "user outcome"],
  "govern": ["provider allowlist", "budget scope", "data retention", "change owner"]
}

Checklist de mise en oeuvre pour les équipes de production

Commencez par un inventaire, pas par une réécriture. Listez chaque appel IA par propriétaire de fonctionnalité, objectif de l'invite, fournisseur actuel, modèle actuel, entrées sensibles, destination de sortie, comportement de nouvelle tentative, modes d'échec connus et impact utilisateur. Indiquez si le workflow est interne uniquement, revu par un humain, visible par l'utilisateur, réglementé ou critique pour la mission.

Gardez la logique de passerelle derrière une petite frontière d'intégration. Un wrapper, un gestionnaire de route ou un module de service devrait rendre le routage explicite et attacher des métadonnées comme le nom de la fonctionnalité, la version de l'invite, le workflow visible par l'utilisateur et l'identifiant d'expérience. Cette frontière donne à l'équipe des options de retour arrière si un fournisseur se comporte différemment ou si une limite budgétaire bloque de façon inattendue un chemin de requête.

Avant de déplacer le trafic de production, exécutez des tests d'évaluation sur des invites représentatives. Optijara ne peut pas exécuter ces tests pour votre application à partir de la seule documentation publique, car chaque produit a besoin de son propre jeu de données et de ses propres critères d'acceptation. Comparez la sortie directe du fournisseur et la sortie routée via la passerelle pour la factualité, le respect des instructions, la validité de la sortie structurée, le comportement de refus, le comportement des appels d'outils, la plage de latence, l'utilisation des tokens et la gestion des erreurs. Pour les tâches de données structurées, utilisez des validateurs déterministes avant la revue humaine. Pour les tâches créatives ou consultatives, utilisez des grilles de revue centrées sur l'utilité, la correction, le ton et les limites de sécurité.

Configurez l'observabilité de la passerelle avant le déploiement. Confirmez que les journaux de requêtes montrent les informations dont les opérateurs ont besoin, que les vues projet et clé API correspondent aux bonnes surfaces produit et que les portées budgétaires correspondent à la propriété. Les budgets au niveau de l'équipe peuvent protéger l'organisation. Les portées projet ou clé API offrent souvent un contrôle plus clair du rayon d'impact pour une nouvelle fonctionnalité. Les budgets au niveau utilisateur peuvent compter lorsque l'utilisation individuelle peut grimper.

Les listes d'autorisation de fournisseurs et les paramètres ZDR appartiennent au même ticket de déploiement que le routage. Décidez quels fournisseurs sont autorisés pour chaque fonctionnalité, quelles routes nécessitent des paramètres ZDR éligibles, qui peut modifier ces paramètres et ce que l'utilisateur voit si aucun fournisseur autorisé ne peut servir une requête. Une boucle silencieuse de nouvelles tentatives n'est pas de la gouvernance. C'est un risque opérationnel caché.

Ce qu'il faut tester avant de changer les routes de production

Les tests de qualité doivent refléter le travail réel, pas des invites de démonstration. Construisez un ensemble représentatif à partir d'exemples approuvés, de journaux assainis ou de cas synthétiques correspondant aux tâches de production. Examinez la factualité, le respect des instructions, le format de sortie, le ton, le comportement de refus et l'achèvement de la tâche. Si le workflow produit du JSON, validez le schéma. S'il cite des sources, vérifiez la structure des citations et les affirmations non étayées. S'il appelle des outils, inspectez les arguments et le traitement des résultats d'outils.

Les tests de latence et d'erreur doivent aller au-delà du chemin idéal. Inspectez le comportement médian et en queue lorsque votre télémétrie le permet, puis décidez ce que l'utilisateur voit lorsqu'une route est lente. Incluez les défaillances de fournisseurs, les rejets de passerelle, les sorties mal formées, les délais d'attente, les limites de débit et la correspondance des erreurs propres aux fournisseurs. Les tests de secours doivent demander si le secours est sémantiquement sûr, pas seulement si un autre fournisseur peut répondre.

Les tests de coût doivent examiner l'utilisation des tokens, les rafales de requêtes, l'amplification par nouvelles tentatives, la longueur du contexte, le comportement de streaming et l'attribution au niveau des fonctionnalités. Les budgets peuvent plafonner l'exposition, mais l'application contrôle toujours le nombre de requêtes qu'elle envoie et la quantité de contexte transportée par chaque requête. Une route peut devenir plus coûteuse si les nouvelles tentatives, les invites plus longues ou les schémas d'utilisation plus lourds changent après le lancement.

Les tests de sécurité et de confidentialité doivent vérifier quelles données sont envoyées, quels fournisseurs peuvent les recevoir, qui peut modifier la politique et comment les preuves d'audit sont conservées. Confirmez les listes d'autorisation des fournisseurs, les exigences ZDR, la propriété des clés API, les permissions applicatives et les étapes de revue d'incident. Si le produit traite des données sensibles, ne vous reposez pas sur un simple bouton de tableau de bord. Examinez les conditions des fournisseurs, le comportement de conservation, la minimisation des données, le contrôle d'accès et la rédaction des journaux d'invites.

Erreurs courantes avec le routage par passerelle IA

La première erreur consiste à optimiser l'optionalité des modèles avant les preuves produit. L'optionalité fournisseur n'est utile que lorsque les équipes savent à quoi ressemble une sortie acceptable. Sans évaluations propres à la tâche, le routage des modèles devient de la devinette.

La deuxième erreur consiste à confondre l'observabilité de la passerelle avec une traçabilité complète. Les tableaux de bord de passerelle peuvent montrer l'activité au niveau de la passerelle, mais la traçabilité complète relie un appel de modèle aux invites, outils, récupérations, permissions, état de l'interface, utilisateurs et événements en aval. Un assistant de support peut échouer parce que la récupération a extrait le mauvais enregistrement alors que la passerelle affiche toujours une requête de modèle réussie.

La troisième erreur consiste à utiliser les budgets comme seul contrôle des coûts. Les budgets sont des garde-fous. La longueur des invites, le contexte récupéré, la politique de nouvelles tentatives, les choix de streaming, la mise en cache, la sélection de modèle et la demande utilisateur influencent tous la dépense.

La quatrième erreur consiste à laisser les politiques de routage dériver sans propriété. Les listes d'autorisation de fournisseurs, les portées budgétaires, la disponibilité des modèles, les exigences ZDR, les clés API et les suites d'évaluation ont besoin de propriétaires nommés et d'intervalles de revue. Lorsqu'une route change, consignez pourquoi elle a changé, quels tests ont réussi, qui l'a approuvée et quel chemin de retour arrière existe.

Comment décider si Vercel AI Gateway convient à votre feuille de route

Vercel AI Gateway est un bon candidat pour les produits multi-modèles, les équipes qui construisent déjà sur l'infrastructure Vercel, les applications qui ont besoin de visibilité sur les dépenses et les groupes produit qui testent des alternatives fournisseurs sans réécrire chaque point d'appel. Il convient aussi aux équipes qui veulent intégrer les listes d'autorisation de fournisseurs, les portées budgétaires et la visibilité au niveau des requêtes dans la pratique normale de l'ingénierie.

L'intégration directe avec les fournisseurs peut rester préférable lorsqu'un workflow dépend d'API propres à un fournisseur, de flux spécialisés de fine-tuning, de contraintes de déploiement inhabituelles, d'exigences strictes de conformité ou de paramètres qui ne sont pas exposés clairement via le chemin de passerelle. Un chemin direct n'est pas moins mature par défaut. C'est un compromis différent. Le vrai risque est la dispersion non gérée : beaucoup de routes, beaucoup de clés, une journalisation incohérente, des politiques fournisseurs floues et aucun processus d'évaluation.

Un déploiement raisonnable commence petit. Choisissez un workflow important mais pouvant être revu en sécurité. Définissez les critères de réussite. Exécutez des évaluations de référence sur le chemin actuel. Configurez la route de passerelle avec une politique fournisseur explicite, une portée budgétaire et la journalisation des requêtes. Comparez les résultats. Revoyez avec les propriétaires produit et ingénierie. Puis élargissez uniquement lorsque les preuves le soutiennent. Si votre équipe veut de l'aide pour cartographier l'inventaire, le plan d'évaluation et le modèle de gouvernance, Optijara peut soutenir cette planification sans transformer une passerelle utile en projet de plateforme surdimensionné.

Vercel AI Gateway est utile lorsque la flexibilité de routage, l'observabilité au niveau de la passerelle, les contrôles de dépense et la politique fournisseur ont besoin d'une place centrale dans la pile. Il ne supprime pas le besoin d'évaluation produit, de traçage applicatif, de revue de confidentialité ou de propriété opérationnelle. Le meilleur modèle d'adoption est guidé par les preuves : routez avec soin, observez à la fois le comportement de la passerelle et celui de l'application, gouvernez les limites de fournisseurs et de budgets, puis élargissez workflow par workflow.