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.

Application Gateway for Containers inference gateway prend en charge ces workloads en s’intégrant à l’Gateway API Inference Extension de Kubernetes, qui ajoute des backends conscients de l’inférence au modèle Gateway API. À 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.

Blocs de construction de la passerelle d’inférence

Une passerelle d’inférence combine trois parties : une implémentation de l’API de passerelle qui gère l’entrée, un InferencePool serveur principal défini par l’extension d’inférence de l’API de la passerelle, et un sélecteur de point d’extrémité qui choisit un pod de serveur modèle pour chaque requête. Application Gateway for Containers fournit la partie initiale et un processeur de routage basé sur le corps de la requête géré. Vous fournissez le InferencePool et le sélecteur de point de terminaison dans votre cluster.

• InferencePool : Une ressource d’arrière-plan (inference.networking.k8s.io/v1) qui représente un groupe de pods de serveurs de modèles, le port sur lequel ils servent, ainsi qu’une référence au sélecteur de point de terminaison qui sélectionne un pod pour chaque requête d’inférence.
• Sélecteur de point de terminaison (EPP) : Le rôle, défini par l’extension d’inférence de l’API Gateway, du composant qui sélectionne un point de terminaison pour chaque requête. La passerelle appelle l’EPP en utilisant le protocole de sélection de point de terminaison défini par l’extension. L’EPP renvoie le pod serveur modèle qui doit répondre à la requête. EPP décrit un contrat, pas un produit unique, et toute implémentation du protocole peut remplir ce rôle.
• Routage basé sur le corps (BBR) : Un processeur de requêtes qui inspecte un corps de requête compatible OpenAI, extrait le nom du modèle et le met à disposition de la passerelle sous forme d’en-tête X-Gateway-Model-Name pour le routage conscient du modèle.

Application Gateway for Containers fait fonctionner le processeur BBR comme une partie gérée de la passerelle, il n’y a donc pas de couche séparée de routage basé sur le corps de la requête ou de traitement de payload à déployer, mettre à l’échelle ou patcher. Parce que la passerelle d’inférence utilise l’API d’extension d’inférence de l’API Gateway, vous la configurez via les ressources standard de l’API Gateway, et les équipes de plateforme peuvent utiliser un modèle API natif Kubernetes pour le trafic d’inférence au lieu d’introduire un modèle de configuration d’ingress distinct.

Modifications de l’extension d’inférence de l’API Gateway v1.6

À partir de la version 1.6, le projet d’extension d’inférence de l’API Gateway se concentre sur la spécification principale : l’API InferencePool , le protocole de sélection de terminaison et les tests de conformité. Les composants spécifiques à l’implémentation ont été transférés au projet llm-d :

Si vous avez créé des ressources InferenceObjective ou InferenceModelRewrite avec l’API inference.networking.x-k8s.io/v1alpha2, installez les CRD llm-d et recréez les ressources avec les versions d’API llm-d. L’API InferencePool ne change pas.

Implémentations de sélecteurs de points de terminaison

Le comportement de routage que vous obtenez d’un InferencePool dépend de l’implémentation EPP que le pool référence. Application Gateway for Containers appelle l’EPP via le protocole standard et ne dépend pas d’une implémentation spécifique. Deux implémentations sont maintenues parallèlement à la spécification :

Utilisez le llm-d router lorsque vous souhaitez les comportements conscients de la charge, du cache et des priorités décrits dans cet article. Utilisez LWEPP pour valider que votre passerelle, InferencePool, et vos serveurs de modèle sont correctement câblés avec le plus petit EPP possible.

Chacun InferencePool fait référence à un déploiement EPP. Le routeur llm-d est généralement installé par pool en utilisant son chart Helm, qui crée ensemble le InferencePool, le déploiement EPP et sa configuration.

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 routes qui ciblent les backends Kubernetes Service n’invoquent pas l’EPP et ne reçoivent pas de comportement de routage spécifique à l’inférence, même lorsque Service sélectionne les mêmes pods de serveurs modèle.

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 la route correspondante vise un InferencePool, Application Gateway for Containers invoque l’EPP du pool. L’EPP évalue la télémétrie de la requête et du serveur de modèles, puis renvoie le point de terminaison sélectionné. En utilisant le routeur LLM-D, l’EPP peut également conserver la requête dans une file d’attente prioritaire jusqu’à ce que la capacité soit disponible, ou réécrire le nom du modèle demandé avant de retourner un point de terminaison.
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. Application Gateway for Containers fournit un routage conscient du modèle, la division du trafic et la gestion des pannes. La sélection des points de terminaison, la priorité et les réécritures de modèle s’exécutent dans l’EPP, donc ces comportements dépendent de l’implémentation de l’EPP et des plugins et fonctionnalités que vous activez dedans.

• 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 entre pools : Utilisez un backendRefs routage pondéré standard HTTPRoute pour répartir le trafic entre InferencePool backends pour les déploiements canari ou bleu-vert d’un modèle fonctionnant sur des pods séparés.
• Réécritures de modèles au sein d’un pool : Avec le routeur llm-d, utilisez les ressources InferenceModelRewrite pour mapper le nom de modèle demandé par les clients à un ou plusieurs modèles cibles desservis par le même pool, avec des poids. Par exemple, les clients continuent de demander support-assistant pendant que l’EPP envoie 90 % des requêtes à l’adaptateur LoRA support-v1 et 10 % à support-v2. Le routeur renvoie le nom de modèle demandé par le client dans la réponse.
• 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 la notation tenant compte du cache de préfixe, les requêtes partageant un préfixe du prompt, comme les échanges d’une même conversation, vont vers la même réplique pour augmenter le taux de succès du cache et réduire le TTFT.
• Priorité des requêtes et protection contre la surcharge : Avec le routeur LLM-D, définissez InferenceObjective les ressources (llm-d.ai/v1) qui attribuent une priorité à une classe de trafic sur un pool, et laissez les clients sélectionner un objectif avec l’en-tête x-llm-d-inference-objective de requête. Lorsque le contrôle de flux est activé et que le pool est saturé, l’EPP met les requêtes en file d’attente dans les bandes prioritaires, envoie d’abord les requêtes de priorité supérieure, et élimine les requêtes de priorité inférieure lorsque sa bande est pleine ou que leur temps de vie expire.
• 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’associe nativement à la capacité WAF existante dans Application Gateway for Containers, appliquant des protections au trafic IA avant que les requêtes n’atteignent vos serveurs modèles.
• Protection pour les backends coûteux : Parce que la politique est appliquée à la périphérie gérée, les requêtes mal formées ou abusives peuvent être inspectées et bloquées avant d’atteindre l’EPP ou de consommer une capacité GPU limitée.

Exemples de scénarios

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

• Diffuser et déployer les versions du modèle : Acheminer les requêtes compatibles OpenAI vers un point de terminaison InferencePool par nom de modèle. Pour déployer un nouvel adaptateur LoRA sur les mêmes pods, utilisez InferenceModelRewrite pour transférer un pourcentage des requêtes vers le nouvel adaptateur. Pour déployer un modèle qui fonctionne sur des pods séparés, utilisez des backendRefs pondérés HTTPRoute répartis sur deux InferencePool backends.
• Réutiliser le contexte mis en cache pour les conversations à plusieurs tours : Activez le calcul de score tenant compte du cache de préfixe dans le routeur llm-d afin que les tours suivants d’une conversation soient redirigés vers la réplique qui contient déjà son cache KV, ce qui réduit le travail de préremplissage et la TTFT.
• 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 chat interactives ont une priorité élevée, tandis que les tâches batch utilisent une priorité plus basse qui attend qu’une capacité soit disponible et est supprimée en premier 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.

An InferencePool inclut un sélecteur de pod, des informations sur le port cible et une référence à un sélecteur de point de terminaison (endpointPickerRef). L’EPP sélectionne le point de terminaison pour une requête. 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.

Le endpointPickerRef d’un InferencePool prend en charge ces modes de défaillance :

• FailOpen : Si l’EPP n’est pas disponible ou ne répond pas, la passerelle continue avec la sélection standard du point de terminaison pour le pool. Ce choix préserve la disponibilité mais perd les comportements de l’EPP tels que l’affinité du cache, la priorité et les réécritures du modèle jusqu’à la récupération de l’EPP.
• 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. FailClose est la valeur par défaut.

Si votre pool s’appuie sur InferenceModelRewrite pour mapper un nom de modèle orienté client vers un modèle que les serveurs chargent réellement, les requêtes qui contournent l’EPP sous FailOpen atteignent le serveur modèle avec le nom de modèle d’origine. Assurez-vous que les serveurs modèles peuvent servir ce nom, sinon, utilisez FailClose pour le pool.

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. Calibrez-la correctement et surveillez-la comme un composant d’application critique, et exécutez plus d’une réplique pour les pools de production.
• Configuration EPP : Avec le routeur llm-d, les plugins scorer, leurs poids, la détection de saturation et le contrôle de flux sont réglés dans le EndpointPickerConfig du routeur, généralement via les valeurs de Helm. Certaines fonctionnalités, comme le contrôle de flux, sont derrière des feature flags et sont désactivées par défaut.
• 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. Confirmez que votre serveur modèle expose les métriques que votre configuration EPP attend.
• 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. La passerelle et l’EPP ne nécessitent pas de GPU.
• 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. Le routeur LLM-D expose également les métriques Prometheus pour ses décisions de planification, de contrôle de flux et de réécriture de modèle.

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.
• La validation JWT définie par un AuthPolicy n’est actuellement pas prise en charge sur les routes dont le backend est un InferencePool.
• L’extension d’inférence de l’API Gateway et le routeur llm-d évoluent indépendamment d’Application Gateway for Containers et l’un de l’autre. Utilisez des versions d’API et des manifestes correspondant aux CRD installés sur votre cluster : le InferencePool CRD de l’extension d’inférence de l’API Gateway, et les CRD InferenceObjective et InferenceModelRewrite de la version du routeur llm-d que vous déployez.

É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
• Routeur LLM-D