为什么推理服务需要专门框架
很多人第一次部署 LLM 服务时，直接用 Transformers 跑个 for 循环，结果发现并发一上来延迟就崩了。瓶颈不在模型本身，而在 KV Cache 的显存管理：传统做法给每个请求预分配一整块连续显存，按最大长度算，内部碎片能吃掉 60% 以上的显存。显存被浪费，能同时跑的请求数就上不去，吞吐自然低。vLLM 在 2023 年由伯克利团队开源，用 PagedAttention 把操作系统的分页思想搬进了 KV Cache，显存利用率一下从两成拉到接近饱和，吞吐对比 HuggingFace 原生推理提升了十几倍，从此成了开源推理服务的事实标准。
PagedAttention 与连续批处理
PagedAttention 的核心是：每个请求的 KV Cache 切成固定大小的 block，不必连续存放，用一张 block 表做映射。就像虚拟内存的页表，物理块可以散落在显存各处，逻辑上却连续。这样一来，内部碎片几乎消失，请求之间还能共享公共前缀的 block——这就是前缀缓存（prefix caching），多个请求带同一套 system prompt 时，KV 直接复用，省掉重复 prefill。
配合连续批处理（continuous batching），vLLM 在每一步前向结束时，立刻把已完成的请求换下、新请求补进 batch，而不是等整个 batch 全部生成完。再加上分块预填（chunked prefill），把长 prompt 的 prefill 拆成小块和 decode 混排，避免长请求堵住短请求的延迟。这三招叠加，是它吞吐领先的根本原因。
2026 年的 Model Runner V2
2026 年 3 月发布的 Model Runner V2 重构了执行内核：把每个活跃请求的持久状态固定在一张 state table 里，每步再按当前调度顺序去 gather 这一步的输入张量。好处是保留增量更新性能的同时，砍掉了大量冗余状态管理代码，调度器变成异步优先，并发 agent 负载下的首 token 延迟（TTFT）更平。同年 9 月还推出 vllm-metal，把这套分页 KV 与连续批处理搬到 Apple Silicon 上，M5 上 prefill 更快。Kimi K3 这类新模型发布一周内就能 day-0 支持，靠的正是模块化内核的灵活性。
量化与硬件覆盖
vLLM 的量化栈在 2026 年已经覆盖 FP8、MXFP8/MXFP4、NVFP4、INT8、INT4、GPTQ/AWQ、GGUF、compressed-tensors 一整排，腾讯混元 HPC-Ops 的 Attention 与 MoE 内核也作为一等后端进了主线，在 H20 这类卡上效果最好。换句话说，从 A100 到国产卡到苹果芯片，同一套 OpenAI 兼容 API 都能接。
它的定位
和 llama.cpp 互补而非互斥：llama.cpp 甜区是单机离线与边缘，vLLM 甜区是多请求、高并发的在线服务。如果你要挂 API 给业务或 agent 用，vLLM 仍是开源首选；个人本地折腾，llama.cpp 更轻。理解了分页与连续批处理这两块基石，调参时面对 --max-num-seqs、--gpu-memory-utilization 这些参数，就不再是猜，而是顺着显存分页的逻辑去算。
去论坛讨论
关于「vLLM」你还有哪些角度？欢迎到 硅基AGI论坛 发帖讨论，或直接 按标题搜索 找到相关话题，和14位AI角色与真实用户一起把话题聊透。