2、vLLM基础：vLLM架构、核心特性、与常见推理框架的对比
2.1 为什么需要专门的推理引擎
大语言模型（LLM）的推理与传统的深度学习模型推理有本质区别。传统模型（如ResNet、BERT）的推理通常是固定形状、低延迟、高吞吐的请求-响应模式；而LLM推理是自回归生成过程，每个请求需要循环执行“前向传播→采样→更新KV Cache→再次前向传播”，直到生成结束符。这种动态性带来了三个核心挑战：
- 显存管理复杂：每个请求的KV Cache大小随生成长度动态增长，无法预分配固定空间，容易产生碎片化浪费。
- 调度开销大：不同请求的生成进度不同，若按批次同步等待最慢的请求，会造成大量GPU空闲。
- 吞吐瓶颈明显：朴素实现下，GPU算力利用率低，尤其在长序列生成时，访存带宽成为主要瓶颈。
vLLM正是为解决这些问题而设计的高性能LLM推理引擎，其核心目标是：在保证低延迟的同时，最大化GPU吞吐量。
关键认知：LLM推理是“访存密集型”而非“计算密集型”任务。生成每个token时，需要读取整个模型权重（数GB），但只产生少量计算。因此，减少显存浪费、提高批大小是提升吞吐的核心手段。
2.2 vLLM核心架构：PagedAttention与Continuous Batching
vLLM的架构创新集中在注意力机制和调度器两个层面。其最核心的突破是PagedAttention——一种受操作系统虚拟内存分页机制启发的KV Cache管理方案。
上图展示了vLLM的核心机制。左侧的请求队列中的多个请求（Req A/B/C）进入调度器后，调度器采用Continuous Batching策略：当一个请求生成完成，立即从队列中拉入新请求，而不是等待整个批次结束。每个请求的KV Cache被划分为固定大小的逻辑块，通过块表映射到物理显存中的任意位置（如逻辑块0→物理块7），从而彻底解决了显存碎片化问题。
2.3 核心特性清单
| 特性 | 说明 | 对压测的影响 |
|---|---|---|
| PagedAttention | 分页KV Cache管理，显存利用率高 | 支持更大并发批大小，吞吐上限高 |
| Continuous Batching | 请求级动态调度，无需等待整批完成 | 吞吐曲线更平滑，尾延迟降低 |
| Prefix Caching | 自动缓存公共前缀的KV Cache | 多轮对话/系统提示词场景收益明显 |
| 量化支持 | GPTQ/AWQ/FP8等量化格式 | 降低显存占用，但可能影响精度 |
| 张量并行 | 多GPU分片模型权重 | 压测需考虑跨卡通信开销 |
| 流式输出 | 支持token级流式返回 | 压测需模拟流式接收逻辑 |
2.4 与常见推理框架的对比
在生产环境选型时，需要综合评估吞吐、延迟、易用性和生态。下表对比了当前主流的LLM推理框架：
| 维度 | vLLM | TensorRT-LLM | HuggingFace TGI | llama.cpp |
|---|---|---|---|---|
| 核心优势 | PagedAttention，吞吐高，易用 | NVIDIA深度优化，延迟极低 | 生态好，功能全 | CPU/边缘设备友好 |
| 显存管理 | 分页机制，利用率高 | 静态KV Cache规划 | 连续缓存，有碎片 | 简单分配 |
| 批处理策略 | Continuous Batching | In-flight Batching | Continuous Batching | 无/简单批处理 |
| GPU支持 | NVIDIA/AMD/华为等 | 仅NVIDIA | NVIDIA为主 | CPU/Apple Silicon |
| 编译优化 | 无（PyTorch eager模式） | 图编译+算子融合 | 部分优化 | C++手工优化 |
| 生产成熟度 | 高（OpenAI等使用） | 高（NVIDIA官方） | 中高 | 中（偏研究） |
选型误区：不要盲目认为“TensorRT-LLM一定比vLLM快”。实际压测中，吞吐量取决于批大小、序列长度分布、显存容量等多因素。在长序列、高并发场景下，vLLM的PagedAttention往往能获得更高吞吐；而在短序列、追求极致延迟的场景，TensorRT-LLM可能更优。务必以真实压测数据为准。
2.5 压测视角的关键理解
从压测工程师的角度，理解vLLM架构有助于设计更合理的测试方案：
- 吞吐瓶颈通常在显存而非算力：压测时需监控
KV Cache使用率和GPU显存占用，而非仅看GPU利用率。 - 批大小是动态的：Continuous Batching意味着实际并发数会波动，压测工具需支持动态请求注入，而非固定并发。
- 前缀缓存影响结果：若压测数据包含相同系统提示词，vLLM会缓存前缀，导致后续请求更快。压测时应设计前缀多样性场景。
- 首token延迟与生成延迟分离：vLLM的调度策略会影响首token延迟（TTFT），压测指标需分别统计TTFT和TPOT（每token生成时间）。
压测参数建议：使用vLLM的
--max-num-seqs参数控制最大批大小，--gpu-memory-utilization控制显存利用率（默认0.9）。压测时建议将显存利用率调至0.85~0.95，观察不同批大小下的吞吐曲线，找到最佳吞吐点。
2.6 常见误区与复盘
在实际压测项目中，以下误区反复出现，值得特别注意：
- 误区一：用固定并发数压测。vLLM的Continuous Batching使得实际处理中的请求数动态变化，固定并发无法反映真实吞吐能力。应使用恒定请求速率（QPS）或队列长度作为控制变量。
- 误区二：忽略输入/输出长度分布。vLLM的显存分配与序列长度强相关。若压测使用固定长度（如128输入+128输出），结果无法代表真实场景。应使用真实业务日志中的长度分布。
- 误区三：只测吞吐不测延迟分布。高吞吐下可能出现长尾延迟（P99极高）。压测报告应同时包含吞吐（tokens/s）和延迟分位数（TTFT/TPOT的P50/P95/P99）。
- 误区四：跨框架对比不公平。不同框架的默认配置不同（如批大小上限、量化格式），对比时应统一模型、精度、硬件、请求分布，并分别调优各框架参数。