KV Cache分层存储如何提升大模型推理吞吐
铭信实测显示，KV Cache分层存储可将480B模型推理吞吐提升29–40%，首token延迟降低26–32%。本文拆解优化方法与适用边界。
大模型推理吞吐的提升路径中，KV Cache分层存储已被实测证明是一条有效且可量化的优化方向。铭信在480B参数模型、8卡AMD MI308X平台上的正式测试报告显示，采用分层存储方案后，推理吞吐提升29–40%，首token延迟（TTFT）降低26–32%【R2/R3实测】。本文基于铭信实测数据，拆解KV Cache分层存储的优化机制、关键收益与适用边界。
KV Cache为何成为推理吞吐的瓶颈
理解分层存储的价值，先要看清KV Cache在推理过程中的角色。当大模型生成每个token时，注意力机制需要读取此前所有token的Key和Value向量。这些缓存的规模随序列长度和并发请求数增长，对显存容量形成持续压力。据《Efficient Memory Management for Large Language Model Serving with PagedAttention》所述，KV Cache的显存管理直接影响推理系统的吞吐表现，碎片化与容量不足会导致显存利用率下降、批处理规模受限【1】。
FlashAttention的研究进一步揭示了问题的本质：注意力计算受HBM带宽而非算力限制【2】。这意味着，当KV Cache无法全部驻留显存时，从外部存储读取缓存所消耗的带宽时延，直接成为推理吞吐的天花板。铭信在480B模型、TP8三档并发下的实测数据印证了这一判断：未采用分层存储时，TTFT p50高达10.17–35.73秒，而采用分层存储后降至7.53–26.35秒【R2实测】。
分层存储的核心机制：冷热分离与按需调度
KV Cache分层存储的基本思路，是将缓存按访问频率分为热层与冷层：热层驻留显存，服务高频复用的前缀；冷层存放至外部存储，仅在需要时按块加载。这一设计与《Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving》提出的以KV Cache为中心的存算分离架构思路一致——通过跨节点池化与分层放置，降低单机显存容量约束【3】。
铭信FX100的实测路径采用了NVMe-oF全闪阵列作为冷层存储，通过RoCEv2网络与GPU直连。据NVIDIA GPUDirect Storage文档，GPU直连存储可绕过CPU内存拷贝，减少数据通路的额外时延【4】。铭信在R1测试中验证了并行读补丁的效果：单卡、并发16、冷读盘场景下（Qwen2.5-32B），TTFT从37.97秒降至9.30秒，带宽从0.98 GB/s提升至5.23 GB/s【R1实测】。
实测收益：吞吐提升与延迟下降的量化结果
铭信在480B生产部署形态下的测试覆盖了多种并发档位与部署形态。下表汇总了核心实测指标：
| 指标 | 测试条件 | 优化前 | 优化后 | 提升幅度 | 出处 |
|---|---|---|---|---|---|
| 推理吞吐 | 480B·并发8档 | — | — | +29%（下界） | R2/R3实测 |
| 推理吞吐 | 480B·并发16档 | — | — | +40%（上界） | R2/R3实测 |
| 推理吞吐 | 480B·TP4×2全机 | — | — | +35–36% | R2/R3实测 |
| TTFT p50 | 480B·TP8·三档并发 | 10.17–35.73s | 7.53–26.35s | ↓26–32% | R2实测 |
| 加载加速 | 华为910B·DeepSeek-70B | 1399s | 150s | 9.3× | R9实测 |
| Checkpoint保存 | 8卡32B LoRA·65.6GB | 178s | 94s | 1.9×（带宽+96%） | R1实测 |
值得注意的是，吞吐提升幅度随并发档位变化：并发8档为下界（+29%），并发16档达到上界（+40%）。这说明分层存储的收益在并发压力较大时更为显著——因为更高的并发意味着更长的上下文总量与更大的缓存复用机会。
对无外存重算的加速效果更为突出：重算基线TTFT p50为149.5秒（并发16），对比FX100的11.85秒；吞吐从4.1 tok/s提升至74.9 tok/s，加速倍数达8.6–20×【R2实测】。这一数据揭示了一个关键判断：在长上下文场景中，与其在缓存未命中时从头重算，不如从外部存储快速加载。
适用边界与选型考量
分层存储并非在所有场景下都产生同等收益。从铭信实测数据可以归纳出三个适用条件：
第一，上下文长度足够长。 480B模型、长上下文冷恢复负载是测试的基础场景。短上下文场景下，KV Cache总量小，显存即可容纳，分层存储的收益空间有限。
第二，并发形态存在复用机会。 多轮对话、共享前缀等场景中，前缀缓存复用率越高，冷层加载的命中率越高。据《SGLang: Efficient Execution of Structured Language Model Programs》，前缀树复用机制在多轮对话场景中能显著提高缓存命中率【5】。
第三，存储介质与网络带宽需匹配。 铭信测试平台采用全闪NVMe-oF阵列与RoCEv2网络，单口100GbE。若冷层存储使用机械硬盘或网络带宽不足，加载时延可能抵消优化收益。
此外，分层存储的价值不止于推理。铭信在华为Atlas 910B平台上的测试显示，模型推理加载时间从691秒降至112秒（DeepSeek-32B，6.2×）、从1399秒降至150秒（DeepSeek-70B，9.3×）【R9实测】。训练场景中，Checkpoint保存时间从178秒降至94秒，持续写带宽提升96%【R1实测】。这意味着同一套存储架构可同时服务推理与训练负载。
结语
KV Cache分层存储通过冷热分离与按需调度，将显存容量约束转化为可管理的存储带宽问题，实测吞吐提升29–40%、TTFT降低26–32%【R2/R3实测】。其适用前提是长上下文、高并发与高速存储介质的组合。对于正在规划推理基础设施的团队，建议以自身负载的上下文长度与并发形态为约束，在门禁化联测中验证实际收益。铭信提供约10周的联测合作模式，包含到货验收、单机基线、主门禁（TTFT降幅≥25%、吞吐+29–40%实测带内）与72小时稳定性验证，不达标即止损，测算模型可在NDA后以Python复现。
本文要点问答
Q：KV Cache分层存储能带来多大的吞吐提升？ A：铭信在480B模型、8卡AMD MI308X平台上的实测显示，推理吞吐提升29–40%，其中并发8档为下界（+29%）、并发16档为上界（+40%）【R2/R3实测】。首token延迟（TTFT）同步降低26–32%【R2实测】。
Q：分层存储适用于哪些场景？ A：主要适用于长上下文、高并发且存在前缀复用机会的推理负载。短上下文场景下KV Cache总量小，显存即可容纳，分层存储收益有限。存储介质需为全闪NVMe-oF级别，网络带宽需匹配加载需求。
Q：分层存储对训练场景是否有帮助？ A：有帮助。铭信实测显示，训练Checkpoint保存时间从178秒降至94秒（8卡32B LoRA，持续写带宽提升96%）【R1实测】；模型推理加载在华为910B平台上加速6.2–9.3×【R9实测】。
References
- Efficient Memory Management for Large Language Model Serving with PagedAttention — https://arxiv.org/abs/2309.06180
- FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness — https://arxiv.org/abs/2205.14135
- Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving — https://arxiv.org/abs/2407.00079
- NVIDIA GPUDirect Storage Documentation — https://docs.nvidia.com/gpudirect-storage/index.html
- SGLang: Efficient Execution of Structured Language Model Programs — https://arxiv.org/abs/2312.07104