Vue d'ensemble de l'architecture vLLM

源码版本v0.25.1

En une phrase

vLLM est un moteur d'inférence LLM à haut débit ; v0.25 est passé à l'architecture v1 : LLMEngine est une fine coquille, le vrai cœur est EngineCore (qui peut tourner dans un processus arrière ZMQ, EngineCoreProc), exposé via EngineCoreClient (Inproc/MP/AsyncMP) ; au runtime, le Scheduler gère les files waiting/running, le batching continu et la préemption, GPUModelRunner.execute_model lance le forward sur le Worker, KVCacheManager + BlockPool implémentent PagedAttention + prefix caching, et AttentionBackend abstrait l'attention sur plusieurs backends.

Couches

Une phrase par couche

• Démarrage et configuration : EngineArgs parse tous les paramètres de lancement et dérive VllmConfig ; LLM est la classe d'inférence offline, AsyncLLM l'entrée asynchrone.
• Fil moteur v1 : LLMEngine est une fine coquille, EngineCore est le vrai cœur (il compose scheduler + worker), EngineCoreProc l'enveloppe dans un processus arrière ZMQ.
• EngineCoreClient : InprocClient (même processus) / MPClient (multi-processus) / AsyncMPClient, exposant uniformément vers le haut des API comme add_request/abort.
• Ordonnanceur : le Scheduler maintient les files waiting/running, schedule décide quelles requêtes tournent à cette étape, avec support de la préemption et du prefill throttle.
• Exécuteur : l'Executor abstrait le backend d'exécution (UniProc/Multiproc/Ray), responsable de lancer les Workers et l'environnement distribué.
• Worker et ModelRunner : le Worker détient le modèle et le KV cache, GPUModelRunner.execute_model lance un forward, ubatch fait le micro-batching, cudagraph accélère.
• Chargement du modèle : DefaultModelLoader charge les poids, les couches linéaires TP (ColumnParallel/QKVParallel/RowParallel) font la découpe, la couche quant gère la quantization.
• KV Cache : KVCacheManager gère le cycle de vie des blocks, KVCacheCoordinator (Hybrid/Unitary/NoPrefix) fixe la stratégie, BlockPool fait l'allocation + l'index du prefix cache.
• Backends d'attention : abstraction AttentionBackend, plusieurs backends interchangeables (FlashAttention/FlashInfer/Triton/MLA/Mamba).
• Sampling : Sampler forward/sample transforme les logits en tokens, LogitsProcessor fait le prétraitement.
• Prefix Cache et distribué : le prefix cache réutilise les KV blocks en cas de hit, GroupCoordinator gère la communication TP/PP, OpenAI serving expose l'API HTTP.

Motivation du découpage en couches

vLLM découple complètement « comment configurer » (engine args), « comment ordonnancer » (scheduler), « comment exécuter » (executor + worker), « comment gérer la mémoire GPU » (KV cache), « comment calculer l'attention » (attention backend), « comment communiquer » (distributed) et « comment exposer » (serving). Ainsi, changer de backend d'attention n'impacte pas l'ordonnancement, changer de backend d'exécution (mono-GPU/Ray) n'impacte pas la logique de KV cache, et ajouter le prefix cache ne modifie pas le code du modèle. EngineCore est le seul nœud central : toutes les requêtes transitent par lui.

Lectures couramment mal interprétées

• « Le cœur de vLLM, c'est PagedAttention » — PagedAttention est la technique clé de la gestion du KV cache, mais le cœur de l'architecture v1 est le trio EngineCore + Scheduler + batching continu ; PagedAttention n'est que l'implémentation de la couche KV cache.
• « LLMEngine, c'est le moteur » — en v1, LLMEngine est une fine coquille ; c'est EngineCore qui fait le vrai travail, LLMEngine se contente surtout de valider les paramètres et de transférer les requêtes.
• « Continuous batching et PagedAttention, c'est la même chose » — non. Le batching continu est une stratégie d'ordonnancement (à chaque étape on peut ajouter/retirer des requêtes) ; PagedAttention est une gestion de mémoire (KV cache en blocks). Les deux coopèrent mais restent indépendants.

Ordre de lecture recommandé

Commencer par Démarrage et configuration, puis LLMEngine et EngineCore, et descendre dans l'ordre Ordonnanceur → Exécuteur → Worker et ModelRunner → KV Cache → Attention → Sampling → Distribué et serving.

Voir la documentation officielle : Documentation vLLM · Design docs · GitHub