Exploitation de l'IA en production

Plan d'architecture vLLM : inférence à faible latence et à grande échelle

Un plan vLLM sourcé couvrant la charge, le traitement continu par lots, le cache KV, le contrôle d'admission, l'observabilité et un déploiement sûr.

10 avril 20266 min de lectureIngénierie de l'inférencevLLM

vLLM peut améliorer l'utilisation des accélérateurs grâce au traitement continu par lots et à une gestion efficace du cache KV, mais le moteur d'inférence n'est qu'une couche d'une plateforme de service fiable. La file d'attente, le contrôle d'admission, le cycle de vie des modèles, l'observabilité et le comportement des clients déterminent souvent si le système atteint son véritable objectif. Cet article est un plan d'architecture sourcé, pas l'affirmation que j'ai livré vLLM en production. Il montre comment je raisonnerais sur le service d'inférence et quelles preuves j'exigerais avant de déclarer la plateforme prête.

Définir la charge avant l'architecture

Une faible latence ne signifie rien sans définition de la charge. Il faut préciser :

la famille du modèle, sa précision et son empreinte mémoire ;
les distributions de tokens d'entrée et de sortie ;
les clients avec ou sans diffusion en continu ;
la concurrence et la forme des pics ;
le nombre de modèles et d'adaptateurs ;
la politique de longueur de contexte ;
les exigences de disponibilité, de résidence et d'isolation des données ;
l'objectif de latence du premier token et de la complétion ;
les objectifs de débit et de coût.

Le délai jusqu'au premier token et la latence entre tokens affectent différemment l'expérience. Une requête analytique longue et un assistant interactif ne doivent pas partager un seul objectif indifférencié. Le modèle de charge doit représenter le trafic produit attendu. Des requêtes synthétiques uniformes masquent les effets des longs contextes, de la variance des sorties, de la pression sur le cache et des arrivées en rafale.

Comprendre les compromis du moteur

Le traitement continu par lots permet au moteur d'ajouter et de retirer des requêtes pendant la génération. Il peut améliorer le débit face à des lots fixes, mais crée aussi des choix d'ordonnancement entre requêtes interactives courtes et longues générations. Le cache KV constitue une autre contrainte centrale. Les contextes longs, le nombre de séquences concurrentes et la taille du modèle consomment rapidement la mémoire. Le cache de préfixes évite du calcul lorsque plusieurs requêtes partagent des préfixes stables, mais son bénéfice dépend de la réutilisation réelle et d'une clé qui respecte les versions du modèle, du tokeniseur, de l'adaptateur et de la politique. La configuration doit être ajustée sur le trafic mesuré plutôt que copiée. Les variables importantes incluent le nombre maximal de séquences, les budgets de tokens, l'utilisation mémoire, le parallélisme tensoriel ou de pipeline, la quantification et le préremplissage par blocs. Chaque évolution peut déplacer le débit, la latence, la pression mémoire et la qualité dans des directions différentes.

Le budget de latence utile suit tout le chemin de la requête. Le réglage du moteur ne compense ni une file sans limite ni une passerelle surchargée.

Placer le contrôle d'admission avant le moteur

Un serveur surchargé ne doit pas accepter un travail illimité en espérant que le traitement par lots le résorbera. La passerelle a besoin de :

authentification et quotas par client ;
limites de requête et de contexte ;
files bornées ;
échéances et propagation de l'annulation ;
contrôles de concurrence par classe de charge ;
contre-pression et réponses explicites en surcharge ;
routage sûr vers des réplicas sains ou une capacité de repli.

Les charges incompatibles doivent être isolées. La conversation interactive, la génération par lots hors ligne et les très longs contextes peuvent se battre pour le même cache et le même ordonnanceur. L'isolation peut être physique ou fondée sur une politique, mais elle doit rester mesurable. Les nouvelles tentatives exigent de la prudence. Un client qui relance une génération après un dépassement de délai alors que la requête initiale continue peut doubler la charge pendant un incident. Il faut propager l'annulation et utiliser des budgets de nouvelle tentative avec un aléa temporel et une liste explicite d'erreurs éligibles.

Séparer les couches de service et de déploiement

Une plateforme pratique distingue :

passerelle : identité, quotas, validation, routage et métadonnées ;
groupe d'inférence : réplicas vLLM avec modèle et matériel explicites ;
cycle de vie : validation des artefacts, préchauffage, état de préparation et promotion ;
télémétrie : traces, métriques moteur, journaux et attribution des coûts ;
plan de contrôle : mise à l'échelle automatique, déploiement progressif, retour arrière et politique de capacité.

L'état de préparation ne doit pas se limiter à un port ouvert. Un réplica charge le modèle et le tokeniseur attendus, passe un contrôle d'inférence représentatif, expose sa télémétrie et reste hors rotation pendant le préchauffage. Lorsque possible, la promotion du modèle reste indépendante du déploiement applicatif. Une route versionnée ou une politique pondérée rend la validation canari et le retour arrière plus clairs qu'un remplacement simultané de tous les réplicas.

Observer la file, le cache et l'expérience

L'utilisation GPU ne suffit pas à expliquer la qualité du service. Il faut suivre :

le débit de requêtes, la charge acceptée et rejetée ;
le temps en file et les séquences actives ;
les distributions du délai au premier token et entre tokens ;
les tokens de prompt et générés ;
l'utilisation du cache KV et les préemptions ;
le comportement du cache de préfixes lorsqu'il est activé ;
les annulations, dépassements de délai et raisons de fin ;
les erreurs par modèle, réplica, client et classe de charge ;
le coût ou le temps d'accélérateur par requête réussie.

La passerelle, la file, le moteur et la diffusion en continu partagent le même identifiant de requête dans les traces. Les prompts sensibles ne doivent pas être stockés dans une télémétrie librement accessible. Des métadonnées et des traces échantillonnées avec contrôle d'accès sont généralement plus sûres. Le guide d'observabilité LLM explique comment relier ces traces à la qualité, au coût, aux alertes et à la réponse aux incidents. Les valeurs de latence d'un tableau de bord doivent provenir de la charge mesurée. Il n'existe aucune cible vLLM universelle applicable à tous les modèles, matériels, contextes et produits.

Tester les frontières de panne et de capacité

Un test de charge fait varier la longueur du contexte, la longueur de sortie, la concurrence et les pics. Il continue jusqu'à franchir une frontière, puis documente le comportement de la file, du rejet, de la latence et de la récupération. Un test qui n'atteint jamais la saturation ne valide pas la politique de surcharge. Il faut aussi tester l'échec du chargement modèle, les réplicas non sains, la disparition des clients, les mises à jour progressives, l'épuisement du cache, un consommateur lent en diffusion continue et les déplacements soudains entre classes de charge. Cette discipline de service est liée à mon étude publique sur l'AI Product Photo Detector, qui couvre FastAPI, le registre de modèles, l'infrastructure, la supervision et la CI/CD pour une autre charge ML. Ce projet ne prouve pas une utilisation de vLLM. Il illustre le même principe : un point de terminaison de modèle a besoin d'un cycle de vie, d'observabilité, de tests et d'un retour arrière.

Déployer avec des preuves réversibles

La démarche commence avec un seul modèle et un banc d'essai représentatif. La correction et la parité qualité sont établies avant l'optimisation de performance. Un réplica canari est ensuite ajouté, son préchauffage et sa télémétrie validés, puis une part contrôlée du trafic lui est envoyée en comparant latence utilisateur, erreurs et comportement des sorties avec le service courant. La montée en charge ne commence qu'une fois les files et la surcharge comprises. La route précédente reste disponible jusqu'à ce que la nouvelle configuration ait passé les tests de charge et l'observation du trafic réel. Un bon déploiement vLLM ne se définit pas par un pic de tokens par seconde. Il se définit par un comportement prévisible lorsque le trafic, la longueur du contexte et les pannes quittent le scénario idéal.

Sources et références

Documentation vLLMMoteur d'inférence, parallélisme, cache et configuration de déploiement
NVIDIA Triton Inference ServerConcepts de service, ordonnancement, métriques et cycle de vie des modèles
Spécification OpenTelemetrySémantique portable pour les traces et métriques

Des principes aux systèmes livrés

Ces articles documentent mes méthodes de travail. Les études de cas montrent comment je les applique aux agents d'entreprise, au RAG et au MLOps.

Voir les études de cas Consulter mon CV

Continuer l'exploration

Des notes complémentaires sur les choix d'architecture, d'évaluation et d'exploitation des systèmes IA en production.

12 avril 20265 min de lectureCoûts LLMOptimisation des coûts