vllm 学习笔记

Appearance

架构概览 — 概念 ​

分层架构 ​

vLLM 采用清晰的分层设计，各层之间通过定义良好的接口通信：

渲染与解析层 ​

v0.23 在入口层与引擎层之间显式引入两套可复用的抽象（被 OpenAI、Anthropic、Responses 三套 API 共用）：

  • Renderer（vllm/renderers/）：OnlineRenderer 负责把 chat/completion 请求渲染为引擎输入（prompt token + 多模态），OnlineDerenderer 负责把引擎输出反向解析为协议消息（含 tool call、reasoning）。模型特定的渲染由 registry.py 注册（如 deepseek_v32、deepseek_v4、mistral、hf 等）。
  • Parser（vllm/parser/）：ParserManager + 流式解析器引擎（Streaming Parser Engine）从生成 token 流中增量提取 tool call 与 reasoning，取代了过去分散在每个 entrypoint 的解析逻辑。

/render（在线渲染：prompt→token）与 /derender（反向：token→message+tool call）端点允许把渲染放到独立进程/节点，支持 PD 分离部署。

核心组件 ​

EngineCore ​

topics/engine-core/ 是 vLLM V1 架构的心脏，运行在独立进程中：

  • 接收来自前端（AsyncLLM/LLMEngine）的请求
  • 每轮迭代调用 Scheduler 决策
  • 通过 Executor 分发到 Worker 执行模型推理
  • 通过 ZMQ 与前端进行进程间通信

Scheduler ​

调度器 是系统的大脑，负责：

  • 连续批处理（Continuous Batching）：动态插入新请求，移除已完成请求
  • Chunked Prefill：将长 prompt 的 prefill 拆分为多个 chunk
  • 前缀缓存（Prefix Caching）：复用共享前缀的 KV 缓存块
  • 抢占与交换：在显存不足时抢占低优先级请求

Worker 与 ModelRunner ​

Worker 是执行层的核心抽象：

  • GPU Worker：管理 CUDA 设备初始化、模型加载、KV 缓存分配；Worker 通过 local_rank/rank 绑定到具体设备（设备由 executor 经 CUDA_VISIBLE_DEVICES 决定，也可用 --device-ids 显式指定物理设备）
  • CuMemAllocator：CUDA 内存池分配器，由 enable_cumem_allocator 控制，可用性经 current_platform.is_cumem_allocator_available() 做平台门控（cuda / hip）。注意 enable_sleep_mode 仍会自动开启 cumem allocator（sleep 依赖 cumem），二者并未解耦
  • ModelRunner：执行前向传播，管理 CUDA Graph、LoRA、推测解码集成。当前并存两套实现 —— v1（vllm/v1/worker/gpu_model_runner.py，约 7400 行）与 Model Runner V2 (MRV2)（vllm/v1/worker/gpu/model_runner.py，约 1600 行），由 use_v2_model_runner 选择（详见 topics/executor-worker/）
  • Mamba 推测解码：融合 Triton 内核消除了 CPU-GPU 同步瓶颈

配置系统 ​

vLLM 的配置系统基于 VllmConfig，聚合了 30+ 子配置（dataclass）：

配置文件职责
VllmConfigconfig/vllm.py主配置聚合器
ModelConfigconfig/model.py模型名称、dtype、最大长度
ParallelConfigconfig/parallel.pyTP/PP/DP/EP 并行配置
SchedulerConfigconfig/scheduler.py最大 token 数、批大小
CacheConfigconfig/cache.pyKV 缓存块大小、swap 空间
CompilationConfigconfig/compilation.pytorch.compile、CUDA Graph 设置

数据流：请求生命周期 ​

V1 架构改进 ​

V1 架构相较于旧版的主要改进：

  1. EngineCore 独立进程：调度与 API 服务解耦，避免 GIL 竞争
  2. ZMQ IPC 通信：高效进程间数据传递
  3. 统一的 Scheduler：合并了旧版的多个调度逻辑
  4. CUDA Graph 全面集成：decode 阶段零开销图重放
  5. torch.compile 支持：自动算子融合与优化

相关概念 ​

反向链接

出链