Deep|LLM: Kimi K3 KV Cache 更小，为什么反而可能利好DRAM/NAND

过去的周末，某友商在推特上关于Kimi K3及其对存储需求影响的点评引发了大量讨论。我们同意他们的核心判断方向——Kimi K3 并不是一个 "内存和网络需求显著下" ”的轻量化模型，而是一个 attention memory 更高效、但模型权重更大、Expert Parallelism 更宽的超大 MoE。K3 总参数量达到 2.8T，每个 token 激活 896 个专家中的 16 个，并使用 KDA、Gated MLA、Stable LatentMoE 和 MXFP4 权重；Moonshot 官方明确建议部署在至少 64 颗加速器组成的高带宽 supernode 上。因此，它仍然需要大量 HBM、scale-up networking 和 GPU。性能上可以认为已进入第一梯队，但 Moonshot 自己也承认整体能力和用户体验仍落后于最强闭源模型，不宜过度吹捧。同时，我们此前的报告也提到K3的token效率较低，导致实际完成长任务时价格比GPT-5.6 Sol更高，性价比并无明显优势。

不过，我们认为友商的部分论证需要更精确。第一，WideEP 并不是每生成一个 token 都在 GPU 之间搬运全部模型权重；专家权重通常分片并常驻各 GPU，网络主要传输被路由到不同专家的 token activation，并在计算后执行 combine。K3 激活 16 个专家、总计 896 个专家，确实显著增加了 dispatch/combine 的 all-to-all 通信，因此更适合 NVL72 这类大 scale-up domain，但主要矛盾是 activation routing bandwidth，而不是反复传输权重。第二，按 MXFP4 粗略计算，2.8T 权重约为 1.4TB，加上非 FP4 参数、scale 和 metadata 后超过 1.5TB 是合理的；但 GB200 NVL72 合计有约 13.4TB HBM， "此“模型权重本身几乎占满 " BM”并不普遍成立。真正推动 KV offloading 的，是长上下文、高并发、长时间保留 prefix cache，以及提高 batch size 的需求。

1. 什么是 KV Cache offloading，为什么重要

模型处理 prompt 时，会为历史 token 生成 Key 和 Value 状态。后续逐 token decode 时复用这些状态，避免重复执行完整 prefill。传统部署把活跃 KV cache 全部放在 GPU HBM 中，但 HBM 容量有限且昂贵；当上下文变长、多轮对话增加、并发用户增多时，KV cache 很快会挤占 batch capacity。

KV cache offloading 是把 KV 做成分层存储：HBM 存最热、正在 decode 的 KV；CPU DRAM 存 warm KV 和预取缓冲；NVMe/NAND 存历史会话、公共 prefix 和暂时不活跃的 cold KV。

请求重新命中某段 prefix 时，系统从 SSD 或远端存储把 KV 预取到 DRAM，再搬回 HBM，直接复用，而不是重新计算整个 prompt。Moonshot 的 Mooncake 正是这种 KV-centric 架构，它把集群中原本利用不足的 CPU、DRAM、SSD 和 NIC 组织为分布式 KV cache pool；SGLang HiCache 也采用 GPU—DRAM—disk/remote storage 的多级 cache。Moonshot 表示，K3 官方 API 在 coding workload 中通过 Mooncake 实现了超过 90% 的 cache hit rate，这也是其 cache-hit input 定价远低于 cache miss 的基础。