Written with AI assistance from the source video. The video is the authority.
Log in to leave a comment
No posts yet
Dans un environnement d'entreprise où plusieurs équipes appellent simultanément des modèles d'IA générative, une structure de proxy centralisée provoque facilement un épuisement des threads en raison de milliers d'entrées/sorties de jetons et de sessions longues. Pour éliminer la latence réseau inter-VPC de 15 à 40 millisecondes et le problème du voisin bruyant entre locataires, il est nécessaire d'isoler physiquement le chemin du trafic d'exécution et le plan de contrôle des politiques central.
Une passerelle centrale unique devient l'épicentre des goulots d'étranglement dans un environnement à fort trafic. L'introduction d'une topologie à deux niveaux permet d'isoler le transfert du trafic vers des plans de données spécifiques au domaine tout en maintenant le plan de contrôle au centre.
Dans un environnement Kubernetes, la spécification Envoy AI Gateway 1.0 est appliquée de manière déclarative. Des ressources Gateway sont créées dans les espaces de noms de chaque domaine métier pour terminer le trafic HTTPS, et BackendSecurityPolicy est lié pour synchroniser les clés d'authentification API à partir du coffre de sécurité central. Les ressources AIServiceBackend et AIGatewayRoute sont définies pour lire les paramètres du modèle dans le corps de la requête et répartir le routage.
En cas de panne du serveur de politique central ou du backbone réseau de l'entreprise, chaque domaine traite le trafic d'inférence sans interruption grâce à la politique de cache synchronisée juste avant. La configuration de la taille des messages du contrôleur est étendue à 25 mégaoctets ou plus et la période d'interrogation est stabilisée pour supprimer les pics de CPU causés par des rechargements fréquents.
Si le temps d'exécution global (turnaround time) est collecté sous la forme d'une métrique unique, les temps d'inférence des grands et petits modèles se mélangent, masquant la dégradation des performances. Pour distinguer si une augmentation de l'indicateur P99 est due à une surcharge de la file d'attente de pré-remplissage GPU d'un fournisseur externe ou au temps d'attente des verrous à l'intérieur de la passerelle, il est nécessaire de mesurer séparément le cycle de vie au niveau de la couche middleware.
Un middleware est directement écrit pour collecter des métriques d'histogramme Prometheus dans le pipeline de la passerelle. L'heure d'entrée du client est capturée par un middleware ASGI et l'ID du locataire ainsi que l'en-tête du domaine de route sont stockés dans les valeurs d'état. Le temps de latence de mise en file d'attente du middleware interne est enregistré dans un objet Histogram et collecté dans des compartiments (buckets) allant de 0,001 seconde à 2,5 secondes. Le moment où le premier octet de jeton est reçu lors du piping du flux client en amont est détecté pour observer la latence TTFT pure du fournisseur sous la forme d'un histogramme indépendant.
Selon les cas de gouvernance d'infrastructure d'Uber, lorsque la latence P99 de mise en file d'attente du middleware interne et la latence TTFT pure par fournisseur de backend sont placées côte à côte sur un tableau de bord Grafana, le temps de traitement des réponses du pipeline de génération de résumés de consultation client a été réduit de 6 secondes.
La majorité des serveurs d'inférence LLM vident immédiatement le code d'état 200 OK, puis suspendent la transmission de la charge utile pendant plusieurs secondes le temps de charger le cache KV. Pour éviter que les utilisateurs ne se retrouvent face à un écran figé, il est nécessaire de faire fonctionner un moteur d'exécution capable de détecter en temps réel le retard de réception du premier octet du jeton pour basculer vers un modèle de secours.
Le routage de secours (fallback) à l'exécution est mis en œuvre en combinant une boucle d'événements asynchrone et une logique de contrôle de flux. Un dictionnaire de configuration contenant les points de terminaison et les en-têtes d'authentification des fournisseurs primaire et secondaire est défini, et le seuil de délai d'attente (timeout) est fixé à 2,0 secondes. Le flux du fournisseur primaire est appelé via un itérateur asynchrone et la fonction asyncio.wait_for est utilisée pour vérifier si le premier jeton arrive dans le délai spécifié.
En cas de dépassement du délai, le flux primaire est immédiatement annulé pour récupérer le socket et les ressources, et le trafic est instantanément basculé vers le flux du fournisseur secondaire dans un état sans perte où pas un seul octet de jeton n'a été transmis au client en aval.
Selon les données de benchmark du hedger adaptatif, l'exploitation d'une couche de transmission générant des requêtes de sauvegarde en cas de latence a permis de réduire la latence de queue P99 de 64,3 millisecondes à 17,0 millisecondes, soit une réduction de la latence de 73,6 pour cent. Cela protège parfaitement contre les temps d'arrêt perçus par l'utilisateur, même en cas de panne partielle du fournisseur primaire.
