KV Cache 预填充与解码阶段的存储配置差异

发布2026/9/10KV Cache预填充解码存储配置

直接答案

预填充吃带宽、解码吃延迟，两类负载对存储的要求并不相同。本文拆解两阶段的配置口径与闲置成因，并给出可复现的验证路径。

引言

KV Cache 的预填充与解码两个阶段，对存储的要求并不相同：预填充阶段以大批量写入与带宽吞吐为主，解码阶段以低延迟随机读与稳定 IOPS 为主。把两者按同一套存储规格配置，通常会在其中一个阶段留下明显的闲置。本文拆解两阶段的负载特征、配置口径与闲置成因，并说明如何在联测中验证配置是否匹配。

需要先说明一个前提：KV Cache 的落盘与复用，本质上是在显存之外寻找一层可被复用的上下文存放位置。据《Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving》，以 KVCache 为中心的存算分离架构，其核心设计取舍之一就是前缀缓存的复用与跨节点 KV 池化——这为「KV 该不该下沉到外存」提供了架构层面的依据，但该来源不提供任何可引用的性能数字。

预填充阶段的存储配置：为什么带宽比对延迟更关键

预填充阶段处理的是整段输入 prompt，一次性生成大量 KV 条目。这一阶段的存储压力集中在写入侧：条目体量大、写入连续、对单次写延迟不敏感，但对持续写带宽敏感。

据《Efficient Memory Management for Large Language Model Serving with PagedAttention》，KV Cache 的分页管理动机来自显存碎片问题，vLLM 的吞吐提升口径也建立在这一显存管理机制之上。这条来源支撑的是显存侧的分页管理逻辑，不能外推到存储层的落盘单元设计；但它提示了一个判断方向：当显存侧已经用分页方式管理 KV 时，外存侧承接的是被换出或需长期保留的部分，其访问模式与显存内的访问模式并不一致。

因此，预填充阶段的存储配置应优先看三件事：

持续写带宽：决定 KV 条目下沉的速度，进而决定预填充能否与写入重叠。
写放大控制：KV 条目通常按块写入，块大小与存储内部条带不匹配会放大写入量。
容量与淘汰策略：决定哪些前缀值得保留、保留多久。

芯元一在 R1 实测中记录了训练 Checkpoint 保存的持续写带宽变化：8 卡 32B LoRA、每份 65.6GB 整模型快照的保存耗时从 178s 降至 94s，持续写带宽从 3.26 GB/s 提升至 6.40 GB/s（+96%）【出处：R1 实测】。这一组数字来自训练快照场景而非推理预填充场景，两者负载形态不同，不能直接互相套用；但它说明持续写带宽是这类大块写入负载的可测、可优化维度。

解码阶段的存储配置：延迟与 IOPS 才是约束

解码阶段逐 token 生成，每一步都需要读取此前累积的 KV。这一阶段的存储访问特征是：单次读取量小、访问频次高、对尾延迟敏感。带宽再高，如果单次读延迟不稳定，解码的 token 间间隔就会被拉长。

据《SGLang: Efficient Execution of Structured Language Model Programs》，RadixAttention 通过前缀树复用机制提升多轮对话与共享前缀场景的命中率。命中率越高，需要真正落到外存读取的 KV 就越少——这意味着解码阶段的存储配置目标不是「更快地读」，而是「更少地读」。配置决策的顺序应当是：先通过前缀复用降低外存访问量，再针对剩余访问优化延迟。

芯元一在 R1 实测中记录了 LMCache 并行读补丁对首 token 延迟的改善：单卡、并发 16、冷读盘（Qwen2.5-32B）条件下，TTFT 从 37.97s 降至 9.30s，带宽从 0.98 GB/s 提升至 5.23 GB/s（↑5.3×），TTFT 改善 4.1×【出处：R1 实测】。这组数字说明的是并行读路径对冷读场景的作用，属于解码前的首 token 准备阶段，与逐 token 解码的稳态延迟不是同一个指标，引用时需区分。

两阶段配置对照与闲置成因

把两阶段的差异整理成对照表，便于逐项核对配置是否匹配：

维度	预填充阶段	解码阶段	出处
主要压力	持续写带宽	单次读延迟与 IOPS	—
敏感指标	写带宽、写放大	TTFT、token 间间隔	—
优化方向	写入与计算重叠、块大小对齐	前缀复用降低外存访问量	—
芯元一实测参考	持续写带宽 3.26 → 6.40 GB/s（+96%，训练快照场景）	TTFT 37.97s → 9.30s，带宽 0.98 → 5.23 GB/s（↑5.3×，冷读盘场景）	R1 实测

闲置的典型成因有三类：

一是按峰值配置、按均值运行。 预填充的写入是突发性的，解码的读取是持续性的。若按预填充峰值选存储，解码期大部分时间处于低利用率；反之则预填充期排队。

二是忽略了两阶段的时间占比。 长上下文场景下预填充占比上升，短输出场景下解码占比上升。配置前应先测清楚自身业务的两阶段时间分布，而不是照搬他人配置。

三是把显存管理结论直接搬到存储层。 显存侧的分页管理与外存侧的块管理，优化目标不同：前者解决碎片，后者解决带宽与延迟的匹配。据《Efficient Memory Management for Large Language Model Serving with PagedAttention》，分页管理的动机是显存碎片；这一结论的适用范围是显存侧，不应直接推导出外存落盘单元的设计规则。

存储通路的选型判据

在通路层面，据《NVIDIA GPUDirect Storage Documentation》，GPU 直连存储可以绕过 CPU bounce buffer，其适用条件与数据通路有明确说明。这一机制对预填充阶段的大块写入与解码阶段的低延迟读取都有意义，但具体收益取决于负载形态，需要在自己的平台上实测确认，不宜直接引用他方结论。

在实例选型层面，据《Compare GPU Instance Families for AI, HPC & Rendering - Elastic GPU Service - Alibaba Cloud》，不同 GPU 实例族按适用场景划分。选型时应先确定约束——SLA、上下文长度、并发形态——再对照实例族分类，而不是先选实例再倒推约束。

据《NVIDIA CMX Context Memory Storage Platform》，NVIDIA 将 CMX 定义为 AI 原生上下文存储层，其公开口径为「相对传统存储最高约 5× 吞吐 / 5× 能效」（up to 5x higher throughput；up to 5x better power efficiency）。这是厂商口径，可作为「上下文存储正在成为独立产品类别」这一判断的佐证，但不构成对任何具体部署的收益预期。

结语

预填充与解码的存储配置差异，本质上是写入密集与读取密集两类负载的差异。避免闲置的关键不是选一款「全能」存储，而是先测清自身业务的两阶段时间分布与访问特征，再按主要矛盾配置。芯元一在 KV Cache 分层加速方向有可复现的实测数据与约 10 周门禁化联测流程（G3 主门禁为 TTFT 降幅 ≥25%、吞吐 +29–40% 实测带内），如需验证自身负载下的配置匹配度，可在联测中逐项核对。

本文要点问答

Q：预填充和解码阶段能用同一套存储配置吗？ A：可以共用硬件，但配置口径应分开设定。预填充优先保证持续写带宽与写放大控制，解码优先保证单次读延迟与 IOPS 稳定，两者按同一规格配置通常会在其中一个阶段留下闲置。

Q：解码阶段提升存储带宽就能降低延迟吗？ A：不一定。据《SGLang: Efficient Execution of Structured Language Model Programs》，前缀复用机制可提升共享前缀场景的命中率，命中率提升意味着外存访问量下降。先降低访问量，再优化剩余访问的延迟，顺序更合理。

Q：如何判断自己的配置是否匹配？ A：先测两阶段的时间占比与访问特征，再对照配置。芯元一 R1 实测中，冷读盘场景下 TTFT 从 37.97s 降至 9.30s、带宽从 0.98 GB/s 提升至 5.23 GB/s（↑5.3×）【出处：R1 实测】，这类数字需要在自身平台上复现才有决策价值。