数据中心级KV Cache部署的能耗评估与优化路径

KV Cache 的部署位置与访问路径，正在成为数据中心能耗账单里不可忽视的一项变量。本文基于铭信 FX100 在 480B 模型长上下文负载下的实测数据（R2/R3 实测），给出 KV Cache 能耗评估的方法论框架与优化方向：核心结论是，将 KV Cache 从本地显存/本地盘迁移到共享存储池，虽然增加了网络与存储层能耗，但通过显著缩短首 token 延迟（TTFT ↓26–32%）和提升吞吐（+29–40%），能够在同一 SLA 约束下减少所需 GPU 并发余量，从而在整机层面获得净能耗收益。这一结论的前提是存储池本身具备足够的带宽与低延迟特性，下文展开论证。

为什么 KV Cache 会成为数据中心的能耗变量

大模型推理服务中，KV Cache 的大小随上下文长度线性增长。据《Efficient Memory Management for Large Language Model Serving with PagedAttention》（SOSP '23）的分析，KV Cache 的显存占用是推理服务显存压力的主要来源之一，其分页管理机制正是为了解决显存碎片与利用率问题而设计。当上下文长度达到数万 token 时，单请求的 KV Cache 可达数百 MB 至数 GB 量级，这对显存容量与访存带宽都构成持续压力。

在传统部署形态下，KV Cache 存放在 GPU 本地显存中，这意味着：

• 显存容量限制了可并发处理的请求数，超出部分必须排队等待；
• 长上下文场景下，显存不足导致请求被挤出，需要从外部存储重新加载模型或 KV Cache，产生大量重算。

这两种情况都会造成 GPU 空闲等待或重复计算，而 GPU 是数据中心里单位能耗最高的设备之一。据 NVIDIA DGX SuperPOD 参考架构文档（NVIDIA Docs），大规模 GPU 集群的设计中，计算、存储、网络分层是基本方法论，存储层的性能直接决定了计算层的利用率。当存储层无法跟上 GPU 的消费速度时，GPU 只能空转等待——这是能耗浪费的隐性来源。

实测数据：KV Cache 外置存储的能耗收益从何而来

铭信 FX100 在 8× AMD MI308X 平台（R2 实测）上的测试数据，可以量化说明 KV Cache 从本地盘迁移到 NVMe-oF 共享存储后的效果。测试模型为 Qwen3-Coder-480B-FP8（MoE，权重约 450GB），长上下文冷恢复负载，对比基线与 FX100 全闪阵列。

这些数字的能耗含义需要拆解。TTFT 降低 26–32% 意味着：在同样的 SLA（如首 token 延迟不超过 10 秒）约束下，系统需要预留的并发余量可以相应减少。例如，若基线需要 16 并发才能保证 p50 达标，使用 FX100 后可能 12 并发即达标——少占用的 GPU 卡时就是直接的能耗节省。吞吐提升 8.6–20× 则意味着单卡可服务的请求数大幅增加，单位 token 的 GPU 能耗成本显著摊薄。

需要强调的是，这些收益并非没有代价。NVMe-oF 阵列本身有功耗，RoCEv2 网络交换也有功耗，存储介质持续读写同样耗电。但关键在于：存储层的功耗远低于 GPU 的功耗量级。据《Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving》（arXiv:2407.00079）的架构分析，以 KVCache 为中心的存算分离设计，其核心动机之一就是让昂贵的 GPU 资源专注计算，而将存储负担转移到相对廉价的存储节点上。这一设计取舍的能耗逻辑是：与其让 GPU 空转等待重算，不如让存储层多承担一些读写压力。

能耗评估的方法论：三个必须拆开的账本

对数据中心运维者而言，评估 KV Cache 部署方案的能耗影响，需要拆开三个账本分别核算，再合并判断。

第一本账：GPU 利用率账。 这是最大头的能耗项。GPU 空闲时的功耗约为满载的 30–50%，而满载与空闲的差值就是 KV Cache 优化可以回收的空间。评估方法是：在固定 SLA 下，分别测量基线与优化方案的 GPU 平均利用率、排队等待时间、重算次数，换算成等效 GPU 卡时。铭信 R2 实测中，无外存重算基线（conc16）的 TTFT p50 为 149.5s，而 FX100 为 11.85s（R2 实测）——这意味着基线方案中 GPU 有大量时间在等待重算完成，这些等待时间全部转化为空转能耗。

第二本账：存储与网络账。 NVMe-oF 阵列、交换机的功耗相对可控，但需要按实际带宽占用率核算，而非按额定功耗。R1 实测显示，LMCache 并行读补丁后，单卡冷读盘带宽从 0.98 GB/s 提升至 5.23 GB/s（↑5.3×，R1 实测），带宽利用率提升意味着同样的存储硬件可以服务更多 GPU，单位带宽的能耗成本下降。

第三本账：运维与散热账。 存储层增加的功耗会转化为散热负担，但 GPU 空转减少带来的散热下降通常远大于此。据 Kubernetes 官方文档（Kubernetes Docs），推理集群的资源调度与存储卷接入机制，允许运维者精细控制存储资源的分配策略，这为能耗优化提供了编排层面的杠杆。

优化路径：从实测到落地的三个步骤

基于上述方法论，数据中心级 KV Cache 能耗优化可按以下路径推进：

第一步：建立基线。 在现有部署形态下，测量典型负载的 GPU 利用率、TTFT 分布、重算频率，核算单位 token 的 GPU 能耗成本。这一步的关键是区分"计算能耗"与"等待能耗"——后者是优化的主要目标。

第二步：分层迁移。 将 KV Cache 从 GPU 本地显存迁移到 NVMe-oF 共享存储池，优先处理长上下文、冷启动场景。R2 实测显示，480B 模型长上下文冷恢复负载下，吞吐提升的上下界为 +29%（并发 8 档）至 +40%（并发 16 档），TP4×2 全机口径为 +35–36%（R3 实测）——这些数据可作为容量规划的输入。

第三步：按 SLA 反推并发。 以 TTFT 降幅（26–32%，R2 实测）为依据，重新计算达标所需的最小并发数，释放多余的 GPU 资源。这一步骤需要与业务方确认 SLA 的百分位要求（p50 还是 p95），不同百分位对应的并发余量不同。

需要明确的是，上述优化路径的适用边界是：存储池带宽必须足够（建议不低于单 GPU 的 KV Cache 读取峰值），网络延迟要低（RoCEv2 或更优），且负载本身以长上下文、多并发为主。对于短上下文、低并发的场景，KV Cache 外置的收益可能不明显，甚至因网络开销而略有劣化。

结语

KV Cache 的能耗优化不是简单的"省电"，而是在 GPU、存储、网络三者之间重新分配能耗预算，让最贵的计算资源尽可能满负荷运转。铭信 FX100 在 480B 模型上的实测数据（R2/R3 实测）为这一分配提供了量化依据。对于希望验证自身负载下收益的团队，铭信提供约 10 周的联测合作模式，可在实际业务负载中测量 TTFT 降幅与吞吐提升，不达标即止损。能耗账本最终要落在自己的负载上算，别人的数字只能作为参考。

本文要点问答

Q：KV Cache 外置存储真的能省电吗？ A：能，但前提是存储池带宽足够。铭信 R2 实测显示，480B 模型长上下文负载下 TTFT 降低 26–32%、吞吐提升 29–40%，这意味着同一 SLA 下所需 GPU 并发余量下降，GPU 空转能耗显著减少，净效果是整机能耗下降。

Q：评估 KV Cache 能耗优化应该看哪些指标？ A：核心看三个账本：GPU 利用率（含等待与重算时间占比）、存储与网络的带宽利用率、散热负担变化。不要只看存储层功耗，GPU 空转的代价远大于存储层多消耗的电。

Q：这个优化适用于所有场景吗？ A：不适用。短上下文、低并发、对延迟不敏感的场景，KV Cache 外置的收益有限。优化前应在自身负载上做基线测量，铭信提供约 10 周联测，可在实际负载中验证 TTFT 降幅与吞吐提升是否落在实测带内。

References

1. Efficient Memory Management for Large Language Model Serving with PagedAttention — https://arxiv.org/abs/2309.06180
2. Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving — https://arxiv.org/abs/2407.00079
3. NVIDIA DGX SuperPOD - NVIDIA Docs — https://docs.nvidia.com/dgx-superpod/
4. Kubernetes Documentation — https://kubernetes.io/docs/home/