Présentation du routage des modèles

Le routage de modèles 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 transfert et les achemine vers des modèles Gemini Enterprise Agent Platform spécifiques. Le routage de modèles est une alternative gérée aux proxys côté client tels que LiteLLM. Il fournit une infrastructure centralisée pour gérer le cycle de vie des agents d'IA.

Le routage de modèle déplace la logique de routage vers la périphérie du réseau et s'intègre à Agent Platform 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 coûts opérationnels et 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 Agent Platform 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 la 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 des requêtes : les applications clientes envoient des requêtes de requête compatibles avec OpenAI à la passerelle, qui les route et traduit les charges utiles en fonction du nom du modèle spécifié dans la charge utile JSON.

Les futures versions d'API Gateway devraient prendre en charge 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 opérationnels : é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 requêtes et acheminez le trafic en périphérie du réseau, en tirant parti de l'intégration directe aux points de terminaison Model Garden d'Agent Platform.
  • Interface client standardisée : permet 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èles répond aux exigences des personas suivants :

  • Ingénieurs de plate-forme : provisionnez 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 charge utile des requêtes.
  • Administrateurs de la gouvernance : ils appliquent des règles d'accès centralisées (comme l'authentification et les quotas) et surveillent le volume global du trafic d'IA dans une organisation.

Cas d'utilisation compatibles

Pendant la Preview publique, le routage de modèle n'est possible que sur la base du tag ou du 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ête

Le routage des modèles 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 des requêtes : 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 fait correspondre la chaîne model aux 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 : la passerelle transcode la requête compatible avec OpenAI dans le schéma de prédiction de l'Agent Platform de destination.
  5. Distribution du backend : la passerelle distribue la requête transcodée au point de terminaison Model Garden Agent Platform désigné et renvoie la réponse du modèle au client.

Performances et limites

Avant d'implémenter le routage de modèles, examinez 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 dans le Model Garden d'Agent Platform, où tous les modèles référencés par un même routeur partagent le même nom d'hôte (par exemple, le point de terminaison global aiplatform.googleapis.com ou un point de terminaison régional unique tel que us-central1-aiplatform.googleapis.com).
  • Exigences concernant les spécifications : le routage de modèle nécessite une spécification OpenAPI 3.x et les extensions API Gateway OpenAPI 3.x correspondantes. Les spécifications OpenAPI 2.0 (Swagger) ne sont pas acceptées.
  • 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. Vous ne pouvez pas non plus mettre à jour une passerelle déployée avec le routage de modèle pour le désactiver ou le supprimer. 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 non basé sur un 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 des modèles 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èles.
  • Streaming et protocoles non compatibles : le routage de modèles est compatible avec le streaming des réponses (événements envoyés par le serveur), mais pas avec le streaming côté requête, gRPC, les WebSockets ni Gemini Live.
  • Modalités acceptées : pendant la version Preview publique, le routage des modèles suppose que les requêtes d'invite textuelles sont mises en forme en tant que charges utiles JSON compatibles avec OpenAI et qu'elles sont routées en fonction de la balise ou du nom model 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 version Preview publique, si le champ model est manquant dans le payload de la requête client, la passerelle traite la requête de manière incorrecte au lieu de la refuser 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) pour les requêtes de streaming de longue durée.
    • Latence de démarrage à froid : si votre instance de passerelle passe à 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 les chemins d'URL réservés commençant par /_ah/ ni 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).

Étapes suivantes