发生了什么
2026 年 10 月 28 日，研究者在 arXiv 发布论文 FlatCake: A Flat KVCache Storage Architecture for LLM Serving。论文关注长上下文和多轮 Agent 请求中的一个问题：KV Cache 即使已经保存在存储系统里，也可能因为恢复不及时，无法在本次 Prefill 中实际复用。
传统多级方案通常把主机 DRAM 放在 NVMe SSD 之前：数据先进入 DRAM，再按淘汰策略进入 SSD；需要恢复时，再将数据送回计算侧。论文指出，当多个长会话并发时，单个会话的 KV 工作集可能很大，主存暂存、SSD 上的数据碎片和恢复队列都会影响首 Token 时延。
FlatCake 尝试把主机 DRAM 与 SSD 作为平级介质统一管理。其主要设计包括：在 KV 数据创建时选择存储介质；按会话范围和层组织 SSD 数据，以便合并读取；区分不同介质的请求调度；通过 GPUDirect Storage 将 SSD 数据流式送入有限的 GPU 显存窗口，并与逐层计算配合。它仍然使用 DRAM，并不是用 SSD 完全取代 DRAM。具体设计见论文第 3 节。
在作者报告的一组实验中，系统运行于 8 张 NVIDIA B200 的服务器，回放 Claude Code 生产请求轨迹，模型为 DeepSeek-V4-Flash。各方案使用相同的 1 TiB 主机 DRAM 与 4 TiB SSD 的 KV Cache 预算。在最高测试负载下，作者报告 FlatCake 的平均首 Token 时延从对照方案 Mooncake 的 12.24 秒降至 7.57 秒，约下降 38%；总 Token 吞吐约为对照方案的 1.6 倍，实际交付的缓存命中率约为 94%，对照方案约为 64%。实验设置与结果中的总 Token 吞吐不应直接理解为输出 Token 吞吐。
上述数字来自论文作者在指定硬件、模型、轨迹和基线下的测试，并非独立复现结果，也不能直接外推为其他系统的收益。
我们的分析
值得关注的指标是“及时交付的命中”，而不仅是“存储层存在的命中”。 对长上下文服务而言，一个缓存块只有在计算需要之前到达可用位置，才真正帮助本次请求减少重算。若恢复过程排队过长、预取失败或数据过于分散，存储容量再大，也未必能转化成首 Token 时延收益。
这给推理系统设计带来三个值得验证的方向：
- 把布局与恢复路径一起建模。 除了 SSD 峰值带宽，还应看单次恢复的有效连续读取规模、读放大、并发队列和数据从存储介质到加速器的端到端时间。
- 把容量命中与交付命中分开统计。 可分别记录数据存在、预取成功、按时到达和实际避免重算的比例，并结合 TTFT 的均值及尾延迟评估。这样的指标拆分是本文的工程建议，不是论文对所有部署的性能保证。
- 按负载选择介质与调度。 多轮 Agent、一次性长文档和短请求的复用模式不同。平级管理是否优于分层缓存，需要在目标请求分布、并发、硬件拓扑及成本约束下比较，不能只依据单一命中率做决定。
对于昇腾及超节点推理系统，值得进一步研究的是：主存、SSD 与加速器之间的数据路径能否支持高效的分段直达和计算掩盖；多设备并发恢复时，存储、主机互联与加速器侧接收窗口会否形成新的瓶颈。这是基于论文提出的系统设计问题，并非对昇腾现有产品能力或性能的判断。
下一步如果要评估这类方案，建议固定模型、上下文长度、请求轨迹与缓存容量，对照重算、主存缓存和 SSD 恢复方案，同时测量交付命中率、有效带宽、读放大、TTFT 与总成本。先验证目标负载确实受 KV 恢复约束，再决定是否引入新的存储组织方式。
公开来源
本文仅供信息参考，详情请见免责声明。
← 继续阅读更多内容