Présentation du routage de modèle

Le routage de modèle pour API Gateway est une couche de gestion du trafic gérée qui accepte les requêtes de prompt compatibles avec OpenAI, les transcode en cours de transmission et les achemine vers des modèles Vertex AI spécifiques. Le routage de modèle constitue une alternative gérée aux proxys côté client tels que LiteLLM, en fournissant une infrastructure centralisée pour gérer le cycle de vie des agents IA.

Le routage de modèle déplace la logique de routage vers la périphérie du réseau et s'intègre à Vertex AI Model Garden pour les optimisations sur le même hôte. Cette architecture élimine la nécessité d'héberger, de mettre à l'échelle et de gérer des serveurs proxy non gérés, ce qui réduit les frais généraux et les coûts d'infrastructure.

Portée et parcours utilisateur

Le routage de modèle est compatible avec les parcours utilisateur principaux suivants :

  • Sélection de modèle : un développeur d'IA utilise des modèles ouverts de Model as a Service (MaaS) dans Vertex AI Model Garden. Il s'agit des modèles des familles Gemini, Anthropic Claude ou OpenAI GPT.
  • Création de spécifications : un développeur d'IA crée ou met à jour une configuration de routeur de modèle dans une spécification OpenAPI 3.x pour référencer les modèles déployés.
  • Déploiement de passerelle : un développeur d'IA déploie une configuration d'API et une instance API Gateway à l'aide de la spécification OpenAPI créée.
  • Routage de prompt : les applications clientes envoient des requêtes de prompt compatibles avec OpenAI à la passerelle, qui achemine les requêtes et traduit les charges utiles en fonction du nom de modèle spécifié dans la charge utile JSON.

Les futures versions d'API Gateway devraient être compatibles avec d'autres parcours utilisateur.

Avantages du routage de modèle

L'implémentation du routage de modèle dans API Gateway présente les avantages suivants :

  • Gestion centralisée : consolidez la gestion du trafic d'IA dans une seule passerelle gérée, en remplaçant les configurations de routage côté client fragmentées.
  • Réduction des frais généraux : éliminez les coûts d'infrastructure et la charge de maintenance associés au déploiement de serveurs proxy autonomes.
  • Performances optimisées en périphérie : inspectez les prompts et acheminez le trafic en périphérie du réseau, en tirant parti de l'intégration directe aux points de terminaison Vertex AI Model Garden.
  • Interface client standardisée : permettez aux applications clientes d'interagir avec une interface REST uniforme compatible avec OpenAI tout en distribuant dynamiquement les requêtes à différents modèles de fondation sous-jacents.

Personas et cas d'utilisation

Le routage de modèle répond aux exigences des personas suivants :

  • Ingénieurs de plate-forme : fournissez une solution d’infrastructure gérée pour remplacer la logique de routage côté client dans les déploiements d’IA d’entreprise.
  • Développeurs d'IA : exposez un point de terminaison d'API standardisé qui achemine dynamiquement les requêtes entre différents modèles de fondation (tels que Gemini Pro, Gemini Flash ou Anthropic Claude) en fonction des paramètres de la charge utile de la requête.
  • Administrateurs de la gouvernance : appliquez des règles d'accès centralisées (telles que l'authentification et les quotas) et surveillez le volume global de trafic d'IA dans une organisation.

Cas d'utilisation compatibles

Pendant la préversion publique, le routage de modèle est compatible avec le routage basé exclusivement sur le tag ou le nom du modèle (par exemple, "model": "gemini-3.5-flash-lite") spécifié dans la charge utile JSON des requêtes client compatibles avec OpenAI.

Architecture et flux de requêtes

Le routage de modèle fonctionne comme une couche de routage gérée dans le plan de données API Gateway. Lorsqu'une application cliente envoie une requête de prompt compatible avec OpenAI à la passerelle, la séquence suivante se produit :

  1. Interception de la requête : la passerelle intercepte la requête POST entrante (par exemple, POST /chat/completions).
  2. Inspection de la charge utile : le routeur de modèle inspecte l'attribut model dans la charge utile JSON entrante (par exemple, {"model": "claude-opus-4-7", "messages": [...]}).
  3. Évaluation des règles : le routeur met en correspondance la chaîne model avec les règles de routage définies dans votre spécification OpenAPI. Si aucune règle ne correspond, le routeur sélectionne le modèle par défaut configuré.
  4. Transcodage en cours de transmission : la passerelle transcode la requête compatible avec OpenAI dans le schéma de prédiction Vertex AI de destination.
  5. Distribution du backend : la passerelle distribue la requête transcodée au point de terminaison Vertex AI Model Garden désigné et renvoie la réponse du modèle au client.

Performances et limites

Avant d'implémenter le routage de modèle, consultez les contraintes techniques suivantes :

  • Contraintes d'hôte : le routage de modèle n'est compatible qu'avec le routage vers des modèles MaaS prédéployés hébergés sur Vertex AI Model Garden, où tous les modèles référencés par un seul routeur partagent le même nom d'hôte (par exemple, le point de terminaison mondial aiplatform.googleapis.com ou un seul point de terminaison régional tel que us-central1-aiplatform.googleapis.com).
  • Exigences de spécification : le routage de modèle nécessite une spécification OpenAPI 3.x et les extensions OpenAPI 3.x API Gateway correspondantes. Les spécifications OpenAPI 2.0 (Swagger) ne sont pas compatibles.
  • Mises à jour de la passerelle : vous ne pouvez pas mettre à jour une passerelle existante déployée sans routage de modèle pour activer le routage de modèle, ni mettre à jour une passerelle déployée avec le routage de modèle pour désactiver ou supprimer le routage de modèle. Pour changer de mode de routage, vous devez créer et déployer une nouvelle configuration d'API et une nouvelle instance de passerelle.
  • Configurations mixtes : une spécification OpenAPI ne peut pas contenir un mélange d'opérations de routage de modèle et de routage sans modèle. Toutes les opérations de la spécification doivent utiliser le routage de modèle ou le routage de passerelle standard.
  • VPC Service Controls : les passerelles de routage de modèle ne sont pas compatibles avec VPC Service Controls. Vous ne pouvez pas utiliser les périmètres VPC Service Controls avec les instances API Gateway qui activent le routage de modèle.
  • Streaming et protocoles non compatibles : le routage de modèle est compatible avec le streaming de réponses (événements envoyés par le serveur), mais pas avec le streaming côté requête, gRPC, WebSockets ni Gemini Live.
  • Modalités compatibles : pendant la préversion publique, le routage de modèle suppose que les requêtes de prompt textuelles sont mises en forme en tant que charges utiles JSON compatibles avec OpenAI et achemine les requêtes en fonction exclusivement du model tag ou du nom dans la charge utile.
  • Champs de charge utile obligatoires : la charge utile de la requête JSON entrante doit inclure un attribut model. Pendant la préversion publique, si le champ model est manquant dans la charge utile de la requête client, la passerelle traite la requête de manière incorrecte au lieu de la rejeter avec une erreur. Assurez-vous toujours que les requêtes client spécifient un champ model dans la charge utile JSON.
  • Limites d'exécution : les limites et les comportements standards du service d'infrastructure d'hébergement de passerelle s'appliquent à vos points de terminaison de routage de modèle :
    • Délai avant expiration maximal : la passerelle applique un délai avant expiration maximal de 3 600 secondes (1 heure), qui s'applique aux requêtes de streaming de longue durée.
    • Latence de démarrage à froid : si votre instance de passerelle est mise à l'échelle à zéro pendant les périodes d'inactivité, la requête initiale peut subir une latence de démarrage à froid, ce qui peut avoir un impact sur les chemins d'inférence d'IA sensibles à la latence.
    • Chemins d'URL réservés : vous ne pouvez pas utiliser de chemins d'URL réservés tels que /eventlog, les chemins commençant par /_ah/ ou certains chemins se terminant par z (pour éviter les conflits, évitez d'utiliser des noms de chemins se terminant par z).
    • Décodage des caractères d'URL : la passerelle décode automatiquement certains caractères encodés dans les URL de requête avant de traiter la requête (par exemple, %41 est décodé en A).

Étape suivante