3. 传统推理系统的瓶颈：显存管理、KV Cache的显存浪费、批处理效率低下的原因
3.1 核心原理：推理阶段为何“显存墙”先于“算力墙”出现
在大语言模型（LLM）推理服务中，我们通常关注算力（FLOPs）是否充足，但实际生产环境里，显存容量与带宽往往更早成为瓶颈。推理过程分为两个阶段：预填充阶段（Prefill）和解码阶段（Decode）。预填充阶段并行处理用户输入的整个Prompt，计算密集；解码阶段则逐token生成输出，每次只产生一个token，属于典型的访存密集操作。
解码阶段的每一次迭代，都需要将当前token对应的权重矩阵以及该序列全部的KV Cache从显存中读取到计算单元。随着并发序列数增加，KV Cache的总量线性增长，显存带宽被大量消耗，导致GPU计算单元处于“等待数据”的空闲状态。这就是传统推理系统中“显存墙”效应的本质：算力利用率被显存访问速度锁死。
关键量化关系：对于一个7B参数的模型（约14GB权重，以FP16计），若输入输出总长度为2048个token，单个序列的KV Cache占用约为：
2 (K和V) × 32 (层数) × 4096 (隐藏维度) × 2048 (序列长度) × 2 (字节/FP16) ≈ 1GB这意味着仅14GB的权重需要服务约14个并发序列时，KV Cache总量就会与权重相当。显存容量迅速被“缓存”吞噬，而非模型本身。
3.2 三大瓶颈的深入剖析
3.2.1 显存管理：静态预分配与碎片化
传统推理框架（如早期的FasterTransformer、TensorRT-LLM早期版本）在显存管理上采用静态预分配策略。当一个新的请求到达时，系统根据该请求可能达到的最大序列长度（例如2048或4096 token）一次性分配连续的显存块。这种策略存在两个严重问题：
- 过度预留：绝大多数请求的实际生成长度远短于预设最大值。例如预设4096 token，但实际平均只生成200 token，则超过95%的预分配显存被闲置。
- 外部碎片：不同请求的预分配块大小不同，随着请求完成释放，显存空间被切割成大量不连续的小块。当新请求需要一个大块连续显存时，即使总空闲量足够，也会因找不到连续区域而触发OOM（Out of Memory）。
典型故障场景：某生产环境GPU显存总量40GB，监控显示空闲总量为6GB，但新请求仍报 CUDA out of memory。原因正是显存碎片化——最大连续空闲块仅2.5GB，无法满足一个需要4GB连续空间的KV Cache分配请求。传统显存管理无法解决此类问题，只能通过重启服务或降低并发来缓解。
3.2.2 KV Cache的显存浪费：内部碎片与低效存储
KV Cache的本质是为每个已生成的token保存其注意力计算所需的Key和Value向量。在传统实现中，每个序列的KV Cache被存储为独立的连续张量，且按最大长度预留。这导致：
| 浪费类型 | 产生原因 | 量化示例（单序列） |
|---|---|---|
| 内部碎片 | 预分配长度 > 实际生成长度 | 预分配4096 token，实际生成512 token → 浪费87.5% |
| 存储精度冗余 | 统一使用FP16存储K/V | 部分场景可用FP8，精度损失可忽略，但显存减半 |
| 重复计算 | 不同请求的共享前缀（如系统提示词）各自存储KV | 1000个请求共享同一系统提示词 → 重复存储1000份 |
更关键的是，传统系统在解码阶段需要将整个序列的KV Cache从显存搬运到计算单元。当序列长度增长到数千token时，KV Cache的读取带宽需求远超权重读取，成为解码速度的绝对瓶颈。例如，一个序列长度为2048时，单次解码需读取约1GB的KV Cache，而权重仅需读取14GB（但权重可被多个序列共享，KV Cache则每个序列独立）。
3.2.3 批处理效率低下：静态批调度与“最慢者决定论”
传统推理系统采用静态批处理（Static Batching）策略：将多个请求组成一个batch，同时进行前向计算。这种方式的低效体现在：
- 批大小固定：一个batch开始后，必须等待其中所有序列都生成完毕才能释放资源。短请求完成后仍需等待长请求，造成GPU算力空转。
- 无法动态增删：新到达的请求无法加入正在执行的batch，只能等待下一轮调度，增加了排队延迟。
- KV Cache不均衡：batch内不同序列的长度差异巨大，导致显存分配必须按最长序列对齐，进一步加剧浪费。
对比示例：假设一个batch包含4个请求，预期生成长度分别为[10, 50, 100, 200] token。
- 静态批处理：所有请求必须等待200 token全部生成完毕才释放，总耗时 = 200次解码迭代。前三个请求早已完成，但GPU仍需为它们保留KV Cache并参与计算（尽管已无新token生成）。
- 理想动态批处理：前三个请求完成后立即释放显存，并允许新请求加入，GPU始终在处理“活跃”的token生成。
静态批处理的算力利用率约为 (10+50+100+200) / (200×4) = 45%，超过一半的算力被浪费在已完成请求的空转上。
3.3 案例复盘：一个典型的OOM故障排查过程
某团队部署了一个13B参数的LLM服务，配置为单GPU（A100 80GB），最大并发8个请求，每个请求最大序列长度设为4096。上线后频繁出现OOM，服务重启后短暂恢复，随后再次崩溃。
排查步骤与发现：
| 排查项 | 结果 | 结论 |
|---|---|---|
| 权重占用 | 约26GB（FP16） | 正常 |
| 激活值峰值 | 约8GB（Prefill阶段） | 正常 |
| KV Cache理论需求 | 8并发 × 4096长度 × 2(K/V) × 40层 × 5120维 × 2字节 ≈ 26GB | 理论总量已接近极限 |
| 实际显存分配 | 监控显示峰值分配达78GB，但有效利用率仅61% | 存在大量预分配浪费 |
| 碎片化程度 | 最大连续空闲块仅3.2GB | 碎片化严重 |
根因分析：系统按4096最大长度预分配KV Cache，但实际平均生成长度仅约800 token。8个请求实际有效KV Cache仅约5GB，但预分配却占用了约26GB。同时，由于不同请求的完成时间不同，释放的显存块大小不一，导致碎片化。最终，当第9个请求到达时，系统尝试为其分配一块4GB的连续显存，但最大空闲块仅3.2GB，触发OOM。
传统方案的临时对策：
- 将最大并发从8降至5（牺牲吞吐）
- 将最大序列长度从4096降至2048（牺牲长文本能力）
- 定期重启服务以清理碎片（牺牲可用性）
这些对策均未触及根本问题——显存管理粒度太粗、缺乏动态按需分配能力。这也正是PagedAttention与vLLM要解决的核心痛点。
3.4 误区与复盘：对传统系统瓶颈的常见误解
误区一：认为OOM只是“显存不够大”
实际上，多数OOM并非总量不足，而是碎片化 + 过度预留导致的有效容量远低于物理容量。即使增加GPU显存，若不改变管理策略，浪费比例不变，只是将崩溃点推迟。
误区二：认为批处理效率低是“GPU算力不够”
静态批处理中，GPU算力利用率低并非因为算力不足，而是因为等待慢请求和为已完成请求做无用计算。算力监控可能显示利用率仅40%，但实际是调度策略限制了并行度。
误区三：认为KV Cache优化只是“省显存”
KV Cache的浪费不仅影响容量，更影响解码速度。因为每次解码都要读取全部KV Cache，浪费的预分配空间虽然不参与计算，但会导致缓存命中率下降、内存带宽消耗在无效地址上。优化KV Cache管理能同时提升吞吐（支持更大batch）和延迟（减少访存开销）。