Acheminez les requêtes vers les pods optimaux en vous basant sur les métriques de file d'attente et de cache GPU en temps réel afin de réduire le temps jusqu'au premier token (TTFT).
Fonctionnalités
Gateway with Inference Extension est un composant de passerelle amélioré basé sur l'API Gateway de la communauté Kubernetes et sa spécification Inference Extension. Il offre un routage de couche 4 et de couche 7, enrichi de fonctionnalités dédiées à l'inférence d'IA générative. Cette solution simplifie la gestion des services d'inférence et optimise l'équilibrage de charge entre plusieurs charges de travail d'inférence.
La solution prend en charge le routage de couche 4 et de couche 7, ainsi que les capacités d'inférence d'IA suivantes :
Équilibrage de charge conscient de l'inférence : achemine les requêtes en fonction des métriques en temps réel du serveur d'inférence (profondeur de la file d'attente et utilisation du cache KV GPU) plutôt que par une distribution uniforme. Cela permet de maintenir une utilisation cohérente des GPU et de réduire la latence du TTFT.
Routage conscient du modèle : achemine les requêtes selon le nom du modèle, conformément à la spécification de l'API OpenAI. Pour un modèle de base associé à plusieurs adaptateurs LoRA, le déploiement canari dirige le trafic vers des adaptateurs spécifiques en fonction du nom de l'adaptateur.
Criticité du modèle : attribue un niveau de criticité à chaque modèle. Les requêtes
Criticalsont prioritaires par rapport aux charges de travail de moindre criticité.
Concepts clés
Deux ressources personnalisées étendent l'API Gateway de Kubernetes :
| Ressource | Objectif |
|---|---|
| InferencePool | Regroupe les pods partageant la même configuration de calcul, le même type d'accélérateur, le même modèle de fondation et le même serveur de modèles. Peut s'étendre sur plusieurs nœuds ACK pour assurer l'évolutivité et la haute disponibilité. |
| InferenceModel | Définit le nom du modèle servi par un InferencePool ainsi que ses propriétés, y compris son niveau de criticité. |
Le diagramme suivant illustre les relations entre les ressources InferencePool, InferenceModel et l'API Gateway.
Fonctionnement
La passerelle évalue les métriques en temps réel suivantes sur chaque pod pour acheminer les requêtes entrantes :
Longueur de la file d'attente des requêtes (
vllm:num_requests_waiting) : nombre de requêtes en attente. Les pods dont la file d'attente est plus courte traitent les nouvelles requêtes plus rapidement.Utilisation du cache KV GPU (
vllm:gpu_cache_usage_perc) : pourcentage du cache KV GPU utilisé. Une utilisation plus faible indique une capacité disponible plus importante pour les nouvelles requêtes.
La passerelle achemine chaque requête vers le pod le mieux apte à la traiter, en se basant sur ces métriques.
Le diagramme suivant illustre le flux de requêtes.
Pourquoi un équilibrage de charge conscient de l'inférence ?
L'équilibrage de charge HTTP standard répartit uniformément les requêtes entre les pods. Cette approche convient aux services sans état, mais pas à l'inférence de grands modèles de langage (LLM), où le coût de calcul de chaque requête est imprévisible.
L'inférence LLM comprend deux phases :
Phase de préremplissage : encode l'entrée.
Phase de décodage : se déroule par étapes ; chaque étape décode l'entrée précédente et génère un token (correspondant approximativement à un mot).
Étant donné que la longueur de la sortie est imprévisible, une distribution uniforme crée une charge GPU inégale : certains pods deviennent des goulots d'étranglement tandis que d'autres restent inactifs.
L'équilibrage de charge conscient de l'inférence achemine chaque requête vers le pod disposant de la capacité disponible la plus importante, en se basant sur la profondeur de la file d'attente et l'utilisation du cache KV GPU en temps réel. Cette méthode maintient l'équilibre de la charge GPU, réduit le TTFT et améliore le débit.