8.0
热点
AI SCORE
技术实践2026-08-11 16:16
数据中心KV缓存能耗评估与优化
dev.to · AI#LLM推理#KV缓存#能耗优化
Editor brief · 编辑速览
480B大模型长上下文下，将KV缓存迁移至共享存储池可降低TTFT 26-32%、提升吞吐29-40%，系统级净节能。
在数据中心账本上，KV Cache 的存放位置与访问路径正在成为一个不可忽视的变量。本文基于明新 FX100 在 480B 模型长上下文工作负载下的实测数据（实测，报告 R2/R3），提出一套 KV Cache 能源评估的方法论框架与优化方向。核心结论是：将 KV Cache 从本地 GPU 显存/本地磁盘迁移到共享存储池，虽然增加了网络与存储层的能耗，但能显著降低首 token 耗时（TTFT ↓26–32%）并提升吞吐量（+29–40%）。这使得在相同 SLA 约束下可以减少所需 GPU 并发余量，从而在系统层面实现净节能。需要指出的是，上述结论的前提是存储池本身具备充足的带宽与低延迟特性，下文将详细展开。
在 LLM 推理服务中，KV Cache 大小随上下文长度线性增长。根据《Efficient Memory Management for Large Language Model Serving with PagedAttention》（SOSP '23）中的分析，KV Cache 内存占用是推理服务内存压力的主要来源之一，其分页管理机制正是针对内存碎片与利用率问题而设计。当上下文长度达到数万 token 时，单个请求的 KV Cache 可从数百 MB 到数 GB 不等，对内存容量与内存访问带宽持续施压。
在传统部署配置下，KV Cache 位于 GPU 本地显存，这意味着：
两种情况都会导致 GPU 空闲等待或冗余计算，而 GPU 是数据中心单位能耗最高的设备之一。根据 NVIDIA DGX SuperPOD 参考架构文档（NVIDIA Docs），分层计算、存储与网络设计是大规模 GPU 集群的基础方法论，其中存储层性能直接决定了计算层的利用率。当存储层无法跟上 GPU 消费速度时，GPU 就会空转等待——这是一种隐形的能源浪费。
明新 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× 意味着每块 GPU 可服务的请求数大幅增加，显著摊薄了每 token 的 GPU 能源成本。
必须强调的是，这些收益并非没有代价。NVMe-oF 阵列耗电，RoCEv2 网络交换机耗电，持续的存储介质读写同样耗电。但关键在于：存储层功耗比 GPU 功耗低若干个数量级。根据《Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving》（arXiv:2407.00079）中的架构分析，KVCache 为中心分离式算存分离设计的一个核心动机，就是让昂贵的 GPU 资源专注于计算，而将存储负担转移到相对廉价的存储节点。这一设计取舍的能源逻辑是：与其让 GPU 空转等待重新计算，不如让存储层承担额外的读写压力。
对于数据中心运营商而言，评估 KV Cache 部署方案的能源影响，需要将三本账分开算，再做综合判断。
这是最大的能源项。GPU 空闲功耗约为满载的 30–50%，满载与空闲之间的差值就是 KV Cache 优化可以回收的空间。评估方法是：在固定 SLA 下，分别测量基准方案与优化方案的 GPU 平均利用率、队列等待时间与重新计算次数，折算为等效 GPU 卡时。在明新的实测 R2 数据中，无外部重算基准方案（conc16）的 TTFT p50 为 149.5 秒，而 FX100 仅为 11.85 秒（实测，R2）——这意味着基准方案中 GPU 将大量时间花在等待重新计算完成上，这些时间全部转化为空转能耗。
NVMe-oF 阵列与交换机功耗相对可控，但必须基于实际带宽利用率而非额定功率来计算。实测 R1 数据表明，应用 LMCache 并行读取补丁后，单 GPU 冷读磁盘带宽从 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）——这些数字可作为容量规划的输入。
以 TTFT 降低幅度（26–32%，实测，R2）为依据，重新计算满足 SLA 目标所需的最小并发数，释放多余的 GPU 资源。这一步需要与业务方确认 SLA 百分位要求（p50 还是 p95），因为不同百分位对应不同的并发余量。
需要明确指出上述优化路径的适用边界：存储池带宽必须充足（建议不低于单块 GPU 的峰值 KV Cache 读取速率），网络延迟必须低（RoCEv2 或更优），且工作负载本身必须以长上下文、高并发场景为主。对于短上下文、低并发场景，外部 KV Cache 的收益可能有限，甚至可能因网络开销而略有下降。
KV Cache 能源优化并非简单的"省电"——而是在 GPU、存储与网络之间重新分配能源预算，让最昂贵的计算资源尽可能接近满载运行。明新 FX100 在 480B 模型上的实测数据（实测，报告 R2/R3）为这一资源分配提供了定量依据。对于希望在自己的工作负载上验证收益的团队，明新提供约 10 周的联合测试合作模式，可以在实际业务工作负载上测量 TTFT 降低与吞吐量提升效果，若未达到目标可随时停止。能源账最终必须用你自己的工作负载来算，他人的数字仅供参考。
问：外部 KV Cache 存储真的能省能源吗？
答：能，但前提是存储池必须具备充足带宽。明新的实测 R2 数据表明，在 480B 模型长上下文工作负载下 TTFT 降低 26–32%、吞吐量提升 29–40%。这意味着相同 SLA 下所需的 GPU 并发余量减少，GPU 空转能耗大幅降低，系统层面净效果是能源消耗降低。
问：评估 KV Cache 能源优化时应该关注哪些指标？
答：聚焦三本账：GPU 利用率（含等待与重算时间占比）、存储与网络带宽利用率、冷却负担变化。不要只看存储层功耗——GPU 空转的代价远超过存储层额外消耗的电费。
问：这个优化适用于所有场景吗？
答：不适用。对于短上下文、低并发或延迟不敏感的场景，外部 KV Cache 的收益有限。优化前应基于自身工作负载进行基准测量。明新提供约 10 周联合测试，可在实际工作负载上验证 TTFT 降低与吞吐量提升是否落在实测区间内。
Efficient Memory Management for Large Language Model Serving with PagedAttention — https://arxiv.org/abs/2309.06180
Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving — https://arxiv.org/abs/2407.00079
NVIDIA DGX SuperPOD - NVIDIA Docs — https://docs.nvidia.com/dgx-superpod/
Kubernetes Documentation — https://kubernetes.io/docs/home/
Originally published at mingxinstorage.xyz. Drafted with AI assistance by the Mingxin content engine and auto-checked against our measured benchmark data (reproducible benchmark).