一个显卡上到底能塞多少个KV缓存块?科技博主Aleksa Gordić给出了具体公式:2×block_size(默认16)×注意力头数×每头维度×数据类型字节数。这个公式过去没人写清楚过,他是照着2025年8月9日的vLLM代码(commit 42172ad)一行行抠出来的。
这事有意思的地方不在公式本身,而在于:vLLM是大半个开源大模型推理服务的地基,但连它自己的V1架构,都没有一份靠谱的官方文档能讲明白内部到底怎么转的。这篇长文本质上是一次民间逆向工程,不是官方背书。
拆开引擎看到了什么
vLLM的V0引擎已经进入弃用流程,V1不是小修小补,是架构重写。核心变化集中在调度器和显存管理上:
- Scheduler支持FCFS(先到先服务)和优先级两种策略,还能在同一步里混合处理prefill(读prompt)和decode(吐token),V0做不到这点。
- KV Cache Manager维护一个叫free_block_queue的空闲块池,规模通常在数十万量级,具体看显存大小。这是PagedAttention的核心索引结构。
- 示例用的是TinyLlama-1.1B这种小模型跑通全流程,说明这套机制不挑模型大小,重点在工程设计本身。
这套链路解释了vLLM为什么能做连续批处理——不用等一批请求全部处理完,新请求随时插队,GPU很少空转。这是它当年比朴素实现快一截的根本原因,现在成了行业标配。
谁该在意这套细节
直接受影响的是负责选型推理引擎的Infra工程师、按token计费的云服务商,以及做高并发agent产品、对首字延迟敏感的团队。这些人平时看的是跑分表,很少有人真去读调度器怎么写的——但决定成本和延迟上限的,恰恰是这些看不见的部分。
“高吞吐”到底是谁的吞吐
vLLM、SGLang、TensorRT-LLM三家常被拿来横向比吞吐,但行业里没有统一赢家的说法更接近事实:TensorRT-LLM在调优充分的NVIDIA环境里吞吐上限通常最高;SGLang靠前缀缓存机制在共享前缀、agent这类workload上常占优;vLLM则是部署简单、硬件适配广。
兵无常势,水无常形——推理引擎的吞吐,也从没有定势。
- 风险.脱离并发数、prefix复用率、精度格式(BF16/FP8)、GPU互联方式单独摆出来的跑分数字,不管出自哪家,都不具备可比性。
这篇拆解本身也留了个明显的口子:作者承诺的benchmark章节还没写出来,vLLM相对SGLang、TensorRT-LLM的实际表现,目前只能等后续文章或者自己动手测。这不是背景知识空白,是一个可以直接标记、等着被验证的具体缺口。
值得肯定的是,把调度器、KV块公式这些细节讲清楚,本身就是一种少见的诚实——不靠一句“高吞吐”糊弄过去,而是把决定吞吐的机制摊开给你看。这比任何一张官方跑分图都更值得工程师收藏。
- 结论.选推理引擎前,先按自己的并发规模和workload类型跑一遍对照测试,别被任何单一数字带节奏。