3、VLLM框架概览：核心特性（PagedAttention、Continuous Batching）、与其他推理框架（TGI、TensorRT-LLM）对比
在大模型推理服务化部署的工程实践中，框架选型直接决定了吞吐量、显存利用率、首Token延迟（TTFT）与部署复杂度。vLLM 自 2023 年开源以来，凭借 PagedAttention 显存管理机制与 Continuous Batching 调度策略，迅速成为业界高吞吐推理的主流选择。本章将深入拆解 vLLM 的两大核心引擎，并与 HuggingFace TGI、NVIDIA TensorRT-LLM 进行多维度对比，帮助你在实际业务场景中做出合理的架构决策。
3.1 PagedAttention：显存碎片化的革命性解法
核心原理：从连续分配到分页管理
传统推理框架（如 HuggingFace Transformers 原生实现）在生成过程中，需要为每个请求预先分配一块连续的 KV Cache 显存。KV Cache 用于存储历史 Token 的 Key 和 Value 张量，其大小与序列长度成正比。这种连续分配方式存在两个致命问题：内部碎片（预分配长度超过实际生成长度）与外部碎片（不同请求的显存块无法复用）。PagedAttention 借鉴操作系统虚拟内存的分页机制，将 KV Cache 划分为固定大小的物理块（Block），每个块通常包含 16 或 32 个 Token 的 KV 数据。请求在逻辑上拥有连续的 Token 序列，但物理上这些块可以分散在显存的任意位置，通过块表（Block Table）维护逻辑块到物理块的映射。
这种设计带来了三个直接收益：其一，显存利用率接近 100%，因为物理块按需分配，不再预留空间；其二，支持跨请求共享，例如并行采样（Beam Search）或多个请求共享相同前缀时，同一物理块可被多个逻辑序列引用，极大节省显存；其三，零拷贝的 KV Cache 访问，注意力计算时直接通过块表索引物理块，避免了数据搬移。
--gpu-memory-utilization 参数控制显存预留比例，默认 0.9。若业务以长序列（如 8K 以上）为主，建议将块大小调大（如 32 Token/块），减少块表开销；若以短序列为主，块大小 16 更灵活。
案例拆解：长上下文场景下的显存节省
某金融科技公司需要部署一个 70B 参数的对话模型，上下文窗口为 32K Token，单卡 A100-80G。使用原生 Transformers 推理时，每个请求预分配 32K 的 KV Cache，显存占用约 18GB，导致并发数仅为 3。切换到 vLLM 后，实际平均生成长度仅 4K Token，PagedAttention 按需分配物理块，单请求 KV Cache 降至 2.3GB，并发数提升至 12。进一步开启前缀共享（Prefix Caching）后，系统提示词（固定 2K Token）对应的物理块被所有请求复用，显存再节省 15%。最终吞吐量从 120 Token/s 提升至 850 Token/s，TTFT 从 2.1s 降至 0.4s。
--max-model-len 限制最大序列长度，并启用 --enable-prefix-caching 缓解长前缀压力。
3.2 Continuous Batching：迭代级调度的吞吐革命
核心原理：从静态批处理到动态调度
传统推理框架采用静态 Batching：将多个请求组成一个 Batch，Batch 内所有请求必须同步完成生成，才能释放显存并接收新请求。这种机制导致两个问题：一是气泡时间，Batch 中最短请求完成后仍需等待最长请求；二是资源浪费，新到达的请求必须等待当前 Batch 完全结束。vLLM 的 Continuous Batching（又称 In-flight Batching）将调度粒度从请求级细化为Token 级。调度器在每个 Decode 步骤后检查所有请求的状态：已完成的请求立即释放资源，新到达的请求在下一个迭代被插入 Batch，未完成的请求继续参与计算。
这种机制的核心优势在于：GPU 计算单元始终被有效请求占满，消除了 Batch 内的等待气泡。同时，vLLM 的调度器支持优先级策略，例如基于请求到达时间（FCFS）或基于最长等待时间，确保公平性。实际工程中，Continuous Batching 可将 GPU 利用率从静态批处理的 50%-70% 提升至 90% 以上。
| 对比维度 | 静态 Batching | Continuous Batching |
|---|---|---|
| 调度粒度 | 请求级（整个 Batch 同步） | Token 级（每步独立决策） |
| 显存释放时机 | Batch 全部完成 | 单个请求完成即释放 |
| 新请求接入 | 等待当前 Batch 结束 | 下一个迭代立即接入 |
| GPU 利用率 | 50%-70% | 90% 以上 |
| 典型延迟 | 高（长尾效应） | 低且稳定 |
实战场景：混合负载下的调度策略
某互联网公司的 AI 助手服务同时承载两类请求：在线交互（要求 TTFT < 500ms）和离线批量分析（不敏感于延迟）。使用 vLLM 时，通过 --max-num-seqs 控制最大并发 Batch 大小，并设置 --scheduler-policy 为 fcfs 保证公平性。实际运行中，在线请求的平均 TTFT 为 320ms，离线任务的吞吐量达到 1.2K Token/s。若将 --max-num-seqs 从 256 调至 512，离线吞吐提升 20%，但在线 TTFT 恶化至 800ms。最终通过设置 --priority 参数为在线请求分配更高优先级，实现了两类负载的隔离调度。
--enable-chunked-prefill，将 Prefill 阶段拆分为多个 Chunk，避免长 Prompt 阻塞 Decode 阶段的调度。
3.3 框架对比：vLLM vs TGI vs TensorRT-LLM
多维度对比分析
在实际选型中，需要综合考量吞吐量、延迟、易用性、硬件适配和生态成熟度。以下表格基于 2025 年各框架的稳定版本特性整理：
| 维度 | vLLM | TGI (HuggingFace) | TensorRT-LLM |
|---|---|---|---|
| 显存管理 | PagedAttention（分页） | 连续预分配 | 显存池化 + 图优化 |
| 调度策略 | Continuous Batching | 静态 Batching + 简单动态 | In-flight Batching（类似） |
| 吞吐量（同硬件） | 高（基准） | 中（约为 vLLM 的 70%-85%） | 极高（比 vLLM 高 10%-30%） |
| 首 Token 延迟 | 低（约 100-300ms） | 中（约 200-500ms） | 极低（约 50-150ms） |
| 模型支持 | 广泛（HF 生态） | 广泛（HF 原生） | 有限（需导出 ONNX/TRT） |
| 动态形状 | 优秀（运行时自适应） | 良好 | 弱（需固定 Batch/序列） |
| 部署复杂度 | 低（Pip 安装即可） | 低（Docker 一键） | 高（需编译、调优） |
| 硬件适配 | NVIDIA/AMD/华为昇腾 | NVIDIA 为主 | NVIDIA 专属 |
| 量化支持 | AWQ/GPTQ/FP8 | GPTQ/AWQ | INT4/INT8/FP8 深度优化 |
选型判断流程
- 硬件约束：若使用非 NVIDIA 硬件（如昇腾、AMD），直接选择 vLLM；若为 NVIDIA 且追求极致性能，考虑 TensorRT-LLM。
- 模型动态性：若业务存在多变的 Prompt 长度和 Batch 大小，vLLM 的 PagedAttention 更灵活；若模型结构固定且序列长度可控，TensorRT-LLM 的图优化收益更大。
- 团队技术栈：若团队熟悉 PyTorch/HF 生态，vLLM 上手成本最低；TGI 适合已有 HF 部署经验的团队；TensorRT-LLM 需要 C++/CUDA 优化经验。
- 延迟敏感度：在线交互场景（如语音助手）优先 TensorRT-LLM；离线批处理场景（如数据标注）vLLM 性价比最高。
--tensor-parallel-size 2 实现双卡张量并行，8 个模型共享一个推理服务，通过 --model 参数动态切换。最终部署时间缩短至 2 小时，吞吐量满足峰值需求，TTFT 稳定在 200ms 左右。复盘结论：在模型数量多、更新频繁的场景下，vLLM 的工程效率远高于 TensorRT-LLM 的性能收益。
3.4 常见误区与工程总结
误区一：PagedAttention 一定优于传统显存管理
PagedAttention 在长序列、高并发场景下优势明显，但在短序列（如 < 128 Token）且并发极低（如 < 4）时，块表查询开销可能超过连续分配的收益。实测中，当 Batch 大小小于 8 且平均序列长度小于 256 时，vLLM 与原生 Transformers 的吞吐差异小于 10%。
误区二：Continuous Batching 无需调参
调度器参数（如 --max-num-seqs、--max-paddings）对性能影响显著。过大的 Batch 会导致 Prefill 计算阻塞 Decode，增加 TTFT；过小则无法充分利用 GPU。建议通过压测工具（如 vllm-bench）绘制吞吐-延迟曲线，找到拐点。
误区三：TensorRT-LLM 永远比 vLLM 快
TensorRT-LLM 的图优化在固定形状下确实更快，但一旦输入形状变化，需要重新编译或使用动态形状模式（性能下降）。vLLM 的 XFormers 内核在动态场景下更稳定。实测中，当序列长度方差超过 50% 时，vLLM 的吞吐反而超过 TensorRT-LLM 约 15%。