Application Gateway pour conteneurs - Passerelle d’inférence

Les charges de travail d’inférence IA ne se comportent pas comme les applications HTTP sans état traditionnelles. Les demandes sont souvent spécifiques au modèle, longues, coûteuses à servir et sensibles aux signaux d’exécution tels que la disponibilité de l’accélérateur, la profondeur de file d’attente, la priorité des requêtes, le budget des jetons et la capacité du serveur de modèles.

La passerelle d’inférence d’Application Gateway for Containers prend en charge ces charges de travail en s’intégrant à l’extension d’inférence de l’API Gateway de Kubernetes, qui ajoute au modèle de l’API Gateway des ressources adaptées à l’inférence. À l’aide de la passerelle d’inférence, vous pouvez exposer des serveurs de modèles auto-hébergés via Application Gateway for Containers avec un comportement de routage tenant compte du modèle et de la charge.

La passerelle d’inférence est conçue pour servir de grands modèles de langage (LLMs) et d’autres charges de travail d’inférence. Il route les requêtes basées sur les signaux du serveur de modèles plutôt que sur l’équilibrage de charge générique, ce qui réduit le temps de premier jeton (TTFT), réduit les délais d’attente sous charge et améliore l’efficacité du GPU. Basée sur les fonctionnalités d’entrée d’Application Gateway pour conteneurs, la passerelle d’inférence vous permet également de associer des charges de travail IA avec des fonctionnalités telles que le pare-feu d’applications web (WAF) pour sécuriser le trafic avant d’atteindre vos serveurs de modèles.

De nombreux runtimes d’inférence auto-hébergés, notamment vLLM, exposent des API HTTP compatibles OpenAI telles que /v1/chat/completions, /v1/completionset /v1/models. OpenAI-compatible fait référence au format d’API, et non à une restriction aux modèles hébergés par OpenAI. Si une autre famille de modèles est servie par le biais d’un runtime ou d’un proxy qui utilise ce format, Application Gateway pour conteneurs peut utiliser le model champ dans le corps de la requête JSON pour le routage basé sur le corps.

Que fournit l’extension d’inférence de l’API de passerelle

L’extension d’inférence pour Gateway API transforme une implémentation de Gateway API en une passerelle d’inférence en ajoutant des concepts de back-end et d’ordonnancement spécifiques à l’inférence.

L’extension introduit ces ressources et composants principaux :

• InferencePool : ressource back-end qui représente un groupe de pods de serveur de modèle et le sélecteur de points de terminaison utilisé pour sélectionner un pod pour chaque demande d’inférence.
• InferenceObjective : ressource qui représente des objectifs de service de requête, tels que la priorité, pour les requêtes qui partagent un inferencePool.
• Endpoint Picker (EPP) : une extension fournie par le client qui s’exécute dans votre cluster et assure la planification de l’inférence. Le PPE reçoit les métadonnées de la requête, évalue les pods candidats de serveurs de modèles à l’aide de plug-ins configurables (par exemple, la profondeur de la file d’attente, l’utilisation du cache KV et l’affinité du cache de préfixes), puis renvoie le point de terminaison sélectionné. Étant donné que la sélection des points de terminaison s’exécute dans le PPE, les comportements de routage disponibles dépendent des plug-ins d’évaluation que votre PPE active.
• Routage basé sur le corps (BBR) : processeur de requêtes qui peut inspecter un corps de requête compatible OpenAI, extraire le nom du modèle et le rendre disponible pour la passerelle en tant qu’en-tête pour le routage prenant en charge le X-Gateway-Model-Name modèle.

Application Gateway pour conteneurs exécute le processeur BBR en tant que partie gérée de la passerelle. Il n’existe donc aucun niveau de routage distinct basé sur le corps pour déployer, mettre à l’échelle ou corriger. Il s’intègre à un PPE fourni par le client pour prendre en charge les décisions de routage au moment des demandes. La passerelle d’inférence prend en charge la Gateway API Inference Extension API. Vous pouvez donc configurer ces fonctionnalités au moyen de ressources Gateway API standard, et les équipes de plateforme peuvent utiliser un modèle d’API natif de Kubernetes pour le trafic d’inférence au lieu d’introduire un modèle de configuration Ingress distinct.

Comment Application Gateway pour conteneurs utilise des ressources d’inférence

Application Gateway pour conteneurs continue d’utiliser les ressources d’API de passerelle standard pour la configuration d’entrée. Le comportement d’inférence est activé lorsqu’une référence de backend d’un HTTPRoute cible un InferencePool au lieu d’un Service Kubernetes.

Pour les routes qui ne sont pas liées à l’inférence, Application Gateway pour conteneurs conserve le comportement existant de Gateway API. Les itinéraires qui ciblent les back-ends Kubernetes Service n’appellent pas de processeurs d’inférence et ne reçoivent pas de comportement de routage spécifique à l’inférence.

Pour les itinéraires d’inférence, le plan de contrôle rapproche l’API de passerelle et les ressources d’inférence et programme le plan de données afin que :

• Le HTTPRoute sélectionne le backend InferencePool.
• Le InferencePool sélectionne les pods du serveur de modèles qui appartiennent au pool.
• Le EPP associé au pool est invoqué pour sélectionner le point de terminaison.
• Le point de terminaison du serveur de modèles sélectionné reçoit la requête.
• Le routage facultatif prenant en charge le modèle utilise le nom du modèle de requête extrait par BBR.

Flux de requête

Une demande d’inférence classique suit ce chemin d’accès. Les étapes numérotées correspondent aux étiquettes du diagramme suivant :

1. Demande cliente : un client envoie une requête compatible OpenAI au serveur frontal Application Gateway pour conteneurs, et l’écouteur de passerelle l’accepte.
2. Routage basé sur le corps (BBR) : pour les itinéraires prenant en charge le modèle, le processeur BBR managé inspecte le corps de la requête, extrait le nom du modèle et injecte l’en-tête X-Gateway-Model-Name . Le HTTPRoute peut ensuite se baser sur cette valeur pour sélectionner le InferencePool approprié.
3. Sélection du point de terminaison : lorsque l’itinéraire correspondant cible un InferencePool, Application Gateway pour conteneurs appelle le PPE, qui évalue la télémétrie de la requête et du serveur de modèles et retourne le point de terminaison sélectionné.
4. Route vers inferencePool : Application Gateway pour conteneurs transfère la requête au pod de serveur de modèle sélectionné, et la réponse du serveur de modèles retourne au client via la passerelle.

Fonctionnalités de routage

La passerelle d’inférence prend en charge ces modèles de routage pour les charges de travail IA auto-hébergées. La sélection de point de terminaison s’effectue dans le PPE ; les comportements tenant compte de la charge et du cache dépendent donc des plugins d’évaluation activés par votre PPE.

• Routage en fonction du modèle : achemine les requêtes en fonction du nom du modèle dans les corps de requête compatibles avec OpenAI, que le processeur BBR géré extrait.
• Répartition du trafic et déploiements progressifs : utilisez les HTTPRoute pondérées standard d’backendRefs pour répartir le trafic entre plusieurs backends InferencePool lors de déploiements de modèles Canary ou Blue-Green.
• Sélection du point de terminaison en fonction de la charge et du cache : l’EPP évalue les points de terminaison à l’aide de la télémétrie du serveur de modèle, comme la profondeur de la file d’attente et l’utilisation du cache KV. Lorsque l’EPP active le calcul de score tenant compte du cache de préfixes, les requêtes qui partagent un même préfixe de requête sont dirigées vers le même réplica afin d’augmenter le taux de réussite du cache et de réduire le TTFT.
• Priorité de la demande et protection de surcharge : utilisez des InferenceObjective ressources et l’en-tête x-gateway-inference-objective de requête pour affecter la priorité de service. Lorsque les serveurs de modèles sont saturés, l’EPP écarte d’abord les requêtes les moins prioritaires afin de protéger le trafic sensible à la latence.
• Sélection de point de terminaison résiliente : Configurer le comportement d’échec PPE avec FailOpen ou FailClose, selon que la disponibilité ou la sélection stricte des points de terminaison est plus importante pour un pool.
• Compatibilité de l’API de passerelle : continuez à utiliser la passerelle, HTTPRoute, ReferenceGrant et les conditions d’état de l’API de passerelle standard pour la configuration d’entrée.

Inférence sécurisée

Conservez les serveurs de modèles privés derrière la passerelle managée et appliquez les fonctionnalités de sécurité de la plateforme au trafic d’inférence.

• Pare-feu d’applications web (WAF) : la passerelle d’inférence s’intègre nativement à la fonctionnalité WAF existante d’Application Gateway pour conteneurs, appliquant au trafic d’IA des protections conformes aux recommandations d’OWASP avant que les requêtes n’atteignent vos serveurs de modèles.
• Protection pour les back-ends coûteux : étant donné que la stratégie est appliquée à la périphérie managée, les demandes incorrectes ou abusives peuvent être inspectées et bloquées avant qu’elles n’utilisent une capacité GPU rare.

Exemples de scénarios

Les scénarios suivants montrent des façons courantes d’utiliser la passerelle d’inférence :

• Diffusez et déployez des versions de modèles : acheminez les requêtes compatibles OpenAI vers un InferencePool en fonction du nom du modèle, puis utilisez les backendRefs pondérés HTTPRoute pour rediriger un pourcentage du trafic vers une nouvelle version du modèle pour des tests Canary avant de finaliser le déploiement.
• Donner la priorité au trafic sensible à la latence : définissez des ressources InferenceObjective pour les charges de travail de haute et de faible priorité sur un pool partagé. Les requêtes de conversation interactive utilisent l’objectif de priorité élevée, tandis que les traitements par lots utilisent une priorité plus faible, qui est la première à être abandonnée lorsque le pool est saturé.

InferencePool par rapport au service

Un Kubernetes Service reste l’abstraction principale appropriée pour le trafic d’application standard. Utilisez un InferencePool lorsque le backend est un groupe de pods de serveur de modèles nécessitant une sélection de point de terminaison propre à l’inférence.

Un InferencePool comprend un sélecteur de pod, des informations sur le port cible et une référence à un sélecteur de points de terminaison. Le PPE est chargé de sélectionner le point de terminaison d’une demande. Un seul PPE est associé à un pool unique.

Comportement d’échec

Le routage d’inférence est un comportement qui intervient au moment de la requête ; le mode d’échec du sélecteur de point de terminaison est donc important.

InferencePool Les références du sélecteur de point de terminaison prennent en charge les modes de défaillance suivants :

• FailOpen : si l’EPP n’est pas disponible ou ne répond pas, la passerelle peut poursuivre en utilisant la sélection standard de points de terminaison pour le pool. Ce choix conserve la disponibilité, mais peut réduire la qualité du routage.
• FailClose: si l’EPP n’est pas disponible ou ne répond pas, la passerelle rejette la requête. Ce choix empêche l’envoi du trafic sans la décision de sélection de point de terminaison requise.

Pour le routage tenant compte du modèle, qui repose sur l’analyse du corps de la requête, Application Gateway pour conteneurs privilégie l’exactitude. Si le nom du modèle ne peut pas être extrait pour une route nécessitant BBR, la demande est rejetée au lieu d’être acheminée en mode silencieux vers le serveur principal de modèle incorrect.

Considérations opérationnelles

Planifiez les considérations suivantes lors de l’exécution de charges de travail d’inférence derrière Application Gateway pour conteneurs :

• Capacité EPP : l’EPP se trouve sur le chemin des requêtes pour les backends InferencePool. Dimensionner et surveiller comme un composant d’application critique.
• Télémétrie du serveur de modèles : l’EPP a besoin de métriques à jour du serveur de modèles pour prendre des décisions de routage pertinentes. Vérifiez que votre serveur de modèles prend en charge les métriques attendues par votre configuration PPE.
• Capacité GPU et ordonnancement : les pods du serveur de modèles nécessitent souvent des pools de nœuds GPU, des plug-ins de périphérique et des identifiants pour télécharger les modèles.
• Mise à l’échelle automatique : mettez à l’échelle les pods du serveur de modèle en fonction de signaux d’inférence tels que la longueur de la file d’attente et l’utilisation du cache KV à l’aide de Horizontal Pod Autoscaler ou de KEDA. La mise à l’échelle automatique augmente la capacité à mesure que la demande croît, tandis que l’EPP redirige le trafic pour contourner les réplicas déjà saturés.
• Réponses en streaming : de nombreux scénarios de complétion de chat utilisent des événements envoyés par le serveur. Validez le comportement de diffusion en continu lors du test de la latence de bout en bout et des paramètres de délai d’expiration.
• Observabilité: Surveillez l’état de Gateway et de HTTPRoute, l’état d’InferencePool, l’intégrité d’EPP, l’état de préparation du serveur de modèles et les métriques du serveur de modèles, telles que les requêtes actives et la longueur de la file d’attente.

Limitations

La passerelle d’inférence se concentre sur les charges de travail d’inférence auto-hébergées s’exécutant sur Kubernetes. Le routage directement vers des points de terminaison de fournisseur de modèles publics ou managés est en dehors de l’étendue de cette intégration.

L’extension d’inférence de l’API de passerelle évolue indépendamment d’Application Gateway pour conteneurs. Utilisez des versions d’API et des manifestes qui correspondent aux CRD de l’extension d’inférence installées sur votre cluster.

Étapes suivantes

• Configurer la passerelle d’inférence d’Application Gateway for Containers
• Composants Application Gateway pour conteneurs
• Documentation de l’extension d’inférence de Gateway API