vLLM

一句话定位

vLLM 是面向大语言模型推理与服务的引擎，重点处理请求调度、模型执行和 KV Cache 管理。

它解决的核心矛盾不是“怎样算出下一个 token”——模型本身已经定义了计算——而是多个长度不同、到达时间不同的请求如何共享有限 GPU 计算与 KV Cache，又不让空闲槽位和内存碎片吞掉吞吐。

在系统中的位置

应用 / Serving platform
  → API server 或离线 LLM 入口
  → Engine Core：请求状态、调度、KV Cache 分配
  → GPU worker / model runner：执行模型与 attention kernel
  → CUDA / ROCm / 其他设备后端

这是控制面与数据面的交界：scheduler 决定这一轮哪些 token 进入批次，model runner 执行张量计算，KV Cache manager 维护请求历史对应的缓存块。API 路由、跨副本扩缩容和业务状态仍属于更上层系统。

一个请求怎样穿过引擎

接收 prompt
  → tokenize 并建立请求状态
  → scheduler 选择 prefill/decode 工作
  → 为新增 token 分配 KV block
  → worker 执行本轮模型计算
  → 写回 KV，采样并流式返回 token
  → 完成或取消后释放请求资源

关键点是调度发生在迭代边界，而不是等整个静态 batch 全部结束。Continuous Batching 让已完成请求退出、新请求进入；PagedAttention 让每个请求的逻辑 KV 序列映射到非连续物理块。前者提高计算槽位利用率，后者降低 KV 分配浪费，两者共同决定可容纳的有效并发。

例如 A 已进入 decode、B 刚到且需要长 prefill：调度器不是简单把两者永久绑成一个 batch。它必须在吞吐、A 的逐 token 延迟、B 的首 token 延迟和剩余 KV 容量之间取舍。若只盯总 token/s，B 的大 prefill 可能让 A 的 TPOT 尾延迟恶化；若过度保护 decode，长 prompt 又可能长期排队。

它不负责什么

不定义 Transformer 模型原理。
不替代 Kubernetes 的集群编排。
不替代完整的应用层 Agent 运行时。
不自动给出适合业务的 SLO、容量规划和故障恢复策略。

对应的底层概念

PagedAttention MANAGES KV Cache 的块映射与分配。
Continuous Batching MANAGES 不同阶段请求如何共享每轮执行。
attention/GEMM/量化 kernel IMPLEMENTS 真正的设备计算；引擎调度不能弥补缺失或低效的 kernel。

与量化格式的关系

vLLM 不是量化文件格式的定义者。它消费 Safetensors/GGUF 等容器中的模型，并依赖对应 kernel 执行 FP8、INT8/INT4、AWQ/GPTQ 或其他量化方案。

容器	支持程度	说明
Safetensors	主要场景	服务端量化的标准路径
GGUF	实验性	非核心生态；生产前必须验证版本/kernel/吞吐

量化是否更快不成立为普适结论——取决于硬件、batch、序列长度、kernel 和反量化开销。

与本地引擎的关系

维度	vLLM	llama.cpp / Ollama
目标	GPU 高并发 serving	本地便捷推理
GGUF	实验性	核心生态
多卡并行	重点（TP/PP/DP）	支持，但非主战场
典型用户	服务端部署	个人/边缘设备

两者是场景不同的平行选择。

部署时真正要验证什么

现象	优先检查
TTFT 高	排队、prefill 长度、chunked prefill、输入处理
TPOT 或其尾延迟高	decode 批次、抢占/排队、kernel、跨卡通信
吞吐上不去但 GPU 不满	请求形状、调度空洞、CPU/tokenizer、同步边界
KV Cache 很快耗尽	上下文/并发分布、block 配置、prefix reuse、量化/卸载策略
多卡反而变慢	TP/PP/DP 选择、互联拓扑、通信与模型规模

版本升级时应重跑相同请求轨迹，而不是只确认服务能启动。模型支持、量化路径、attention backend 和 scheduler 配置都可能改变性能边界；当前功能列表只能作为待验证实现证据。

关系与边界

向上：vLLM IMPLEMENTS Inference Engine Selection 中的服务端高并发候选，并由 MOC - Serving and LLMOps 负责路由、扩缩容和观测。
同层：vLLM CONTRASTS-WITH SGLang；具体差异保持在 vLLM 和 SGLang 的调度器区别是什么中验证。
向下：vLLM DEPENDS-ON KV Cache、PagedAttention、Continuous Batching、并行通信与设备 kernel。
邻接而非上下游：llama.cpp 面向本地/边缘执行，Ollama 是本地模型管理平台，二者不是“低配版 vLLM”。

一个请求的状态不是只有 running/finished

线上调度至少要区分等待输入处理、prefill、等待 KV、decode、被抢占重算、流式发送和取消。相同的 running 数量可能对应完全不同的压力：一批请求刚完成长 prefill，另一批已经在 decode 且 KV 快满，scheduler 的下一步选择会分别影响 TTFT、TPOT 和可接入容量。

1
2
3

waiting → prefill → decoding
             ↘ KV pressure → preempt/recompute
decoding → stream / finish / cancel → release blocks

因此调参要同时看 max_num_seqs、token budget、KV block 使用、抢占/重算、prefix hit 和每轮实际 batch；把 max_num_seqs 调大后吞吐不升，可能是 KV 或带宽先饱和，而不是 scheduler 没有“足够激进”。

服务层必须补齐的契约

vLLM 能提供推理入口和流式 token，但租户配额、优先级、跨副本 prefix 路由、灰度、超时、取消传播和故障恢复仍需上层实现。特别是客户端断开后，如果 gateway 没把取消传到 engine，KV block 可能继续占用，造成“用户已离开但容量仍下降”。部署验收应包含取消、长请求 drain、OOM/抢占、模型升级和副本失联，而不只是服务启动和单请求输出。