实测 107 倍 KV Cache 容量，绿算 GP7000 让多轮长会话不再"崩落"
绿算 GP7000 SPDK KV Cache 与纯 DRAM 方案 · 分层对比实测
一、背景：KV Cache 正在吃掉推理集群的内存预算
大模型多轮对话的 KV Cache 是会累积的。以本次测试的负载为例，每轮缓存增量为「并发数 × 每轮输出 token × 88.1 KB」。当会话拉长到 20 轮、50 轮，工作集迅速越过单机 DRAM 边界——而 DRAM 一旦开始驱逐，vLLM 链式块哈希会让整条会话的复用集体失效。
我们把这个问题放到真实集群上跑了一遍：NVMe-oF 全闪是否能接住 DRAM 接不住的那部分。
二、测试环境
| 项目 | 配置 |
|---|---|
| 算力服务器 | cx81 / cx82 两台，分别搭载 Intel Xeon 6767P（256 vCPU）与 Xeon 6787P（344 vCPU），内存均为 1007 GiB |
| GPU | 每机 8 张 NVIDIA RTX 6000D（Blackwell，sm_120，单卡 83.6 GiB），卡间无 NVLink，全走 PCIe Gen5 x16 |
| 推理引擎 | vLLM 聚合模式（Dynamo 调度），4 个引擎实例，TP=4，FP8 KV Cache，block=256 |
| 模型 | DeepSeek-V4-Flash，156 GB / 48 分片，双机本地部署 |
| 网络 | 200 Gb/s RoCEv2，Mooncake DRAM 层与 NVMe-oF 层分物理网卡，互不抢带宽；全量 GPUDirect（每机 8 卡注册进 RDMA） |
| 存储 | 绿算 GP7000 全闪 NVMe-oF 存储阵列（双 PCIe 5.0 主控 / 6×BlueField-3 / 12×200 Gb/s RoCEv2 / 24×7.68 TB U.2 SSD / SPDK NVMe-oF Target） |
三、对比方式：一个刻意不对等的设置
| 配置 | KV 落点 | DRAM 段总量 | 有效容量 | 等效 token 容量 |
|---|---|---|---|---|
| DRAM KV Cache | Mooncake DRAM 段（纯内存） | 400 GiB | 429.5 GB | ≈ 4.8M token |
| 绿算 GP7000 SPDK KV Cache | DRAM 段 + NVMe-oF(SPDK) 副本层 | 50 GiB | 46.09 TB | ≈ 1,092M token |
关键点：SPDK 方案的 DRAM 段只有 DRAM 方案的 1/8。它不是"同样的内存再叠一层存储"，而是"DRAM 砍到 1/8，靠 NVMe-oF 把容量补回来"。以下每一项性能结论，都建立在 SPDK 方案先在 DRAM 侧让出 8 倍容量的前提下。
为保证对比有效，我们以机器判据核验介质身份：两模式 save_put 总量相差 +0.1%、load_get 相差 +0.3%；DRAM 方案全程写入约 1.49 TB 对象，而 NoF 层分配字节增量恒为 0.0 B；SPDK 方案两个 tier 均被证实真实写入。
四、测试结果
4.1 性能：吞吐打平，高并发反超
| 维度 | DRAM KV Cache | GP7000 SPDK KV Cache | 结论 |
|---|---|---|---|
| 纯读路径吞吐（f=1.0，C≤64） | 基准 | 0.97–1.03× | 噪声内打平 |
| 20 轮稳态 RPS（osl=128，C=4…128） | 基准 | −0.1% ~ −4.9% | 差异在噪声量级 |
| C=256 更高并发（20 轮） | 24.27 RPS | 25.67 RPS | SPDK 反超 +5.5% |
| 20 轮稳态 TPOT（解码单 token） | 基准 | 6 档中 4 档 SPDK 略优 | 解码不受介质影响 |
C=256 对照中，两模式命中率逐位相同（0.9750 vs 0.9752）、store 工作量相同（300.5 GB vs 300.3 GB），表明该处饱和来自引擎侧而非存储侧——单纯把 DRAM 段从 50 GiB 扩到 400 GiB（8×）、完全不用 NVMe-oF，并不能提升吞吐。
4.2 容量：107 倍，且支付方式在工程上可行
有效容量从 429.5 GB 提升至 46.09 TB，放大 107 倍。按 NoF 池实测 46.09 TB、每轮约 21.5 GB 的写入推算，可连续支撑约 2,140 轮 osl=5000 会话才会写满。
4.3 长会话：从"崩落"变为"命中率单调上升"
长输出场景（每轮强制输出 5,000 token，20 轮，C=112）：
| 指标（第 20 轮） | DRAM KV Cache | GP7000 SPDK KV Cache | 差异 |
|---|---|---|---|
| KV 命中率 | 0.0085 | 0.9516 | 112× |
| 单轮墙钟 | 727.3 s | 277.7 s | 2.62× |
| TTFT p50 | 246,236 ms | 16,852 ms | 14.6× |
| 每请求超额重算 | 99,754 token | 117 token | 853× |
| 点总墙钟 | 7,480 s | 5,036 s | 1.49× |
| 全程累计写入 | 5,557.3 GB | 1,063.5 GB | 写入量降至 1/5.2 |
第 20 轮的解析上限为理想命中率 0.9527，SPDK 实测 0.9516 = 上限的 99.88%；DRAM 实测 0.0085 = 上限的 0.9%。
50 轮超长会话中，SPDK 方案命中率由 0.6580 单调升至 0.9797，超额重算长期维持在可复用前缀的 0.06%–0.2%，全程运行 3.90 小时、0 错误。同等负载下 DRAM 方案约在第 20 轮耗尽，50 轮会话在算术上不可行。
工作集超出 DRAM 容量场景（471 GB 工作集，DRAM 方案存在约 19% 缺口）：第 2 轮墙钟 121.0 s → 11.4 s（10.6×），命中率 0.4821 → 0.9954，重算 token 相差 113 倍。
五、机理：为什么"落在哪一层"比"读得多快"更重要
DRAM 的失效是悬崖，不是缓降。 vLLM 前缀缓存为链式块哈希（第 k 块哈希包含第 k−1 块），LRU 驱逐的最旧块正是每条会话的链头；链头一掉，整条会话复用一起失效，并触发"驱逐 → 重算 → 重写 → 更多驱逐"正反馈（实测单轮写入从 50 GB 飙升至 1,051.8 GB）。崩落时刻可在测试前精确预测。
读路径为什么能打平？ 单轮墙钟由 TTFT（25–28%）与解码（70%）构成，几乎没有独立的 store 等待项；KV 读取发生在 TTFT 之内。命中 token 供给被三层分散：GPU 自有前缀缓存 87–91%、外部 store 8–12%、本地重算 2.5%。存储器层的介质差异由此被稀释。
结论：KV Cache 分层设计的第一性问题不是带宽，而是是否存在一个不会驱逐的落点。NVMe-oF 全闪提供的正是这个落点。
适用人群
正在部署或扩容 DeepSeek 等长上下文模型的推理集群、遇到 KV Cache 命中率随会话轮次崩塌、需要在不追加内存预算的前提下提升多轮会话承载能力的团队。
进一步了解
如需测试报告全文，或希望基于自有集群负载形态做容量测算，请通过官网「联系我们」提交需求，或通过公众号「绿算技术」留言获取。