百卡以内推理集群值不值得上外置 KV Cache 池？

百卡以内推理集群是否值得部署外置 KV Cache 池？答案是：在长上下文、高并发、SLA 敏感的生产形态下，具备明确技术收益；但该收益非普适，其经济性取决于缓存命中率、冷热负载比与现有存储架构瓶颈位置——芯元一 FX 系列在 AMD MI308X ×8 平台实测显示，并发 8–16 档时 TTFT 降低 26–32%，KV 分层吞吐提升 29–40%【R2/R3 实测】，已覆盖典型中小规模集群的主流工作点。

当前行业对“外置 KV Cache”的讨论常陷入两极：一端认为仅超大规模集群（千卡+）才需池化，另一端则将缓存池等同于“万能加速器”。这种认知偏差源于混淆了三个不同层级的问题：架构必要性（是否必须外置）、工程可行性（能否低延迟接入）、成本合理性（单位 token 成本是否下降）。本文基于芯元一在真实推理集群环境中的签字级实测数据，聚焦百卡以内（≤64 卡）典型部署场景，厘清外置 KV Cache 池的适用边界与决策依据。

外置 KV Cache 池不是“要不要”，而是“在哪一档并发下显效”？

KV Cache 的外置化本质是将原本紧耦合于 GPU 显存的中间状态，迁移至高带宽、低延迟、可池化的外置存储层。其价值不在“有无”，而在“何时释放”。据《Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving》指出，KV Cache 的跨请求复用与前缀共享特性，天然支持池化架构设计；但该设计是否带来可观收益，高度依赖实际负载的并发密度与上下文复用率。

芯元一在 AMD MI308X ×8 平台（Qwen3-Coder-480B-FP8，TP8）的 R2 实测表明：当并发从 1 提升至 8 时，TTFT p50 从 10.17s 降至 7.53s（↓26%）；并发升至 16 时进一步降至 7.53–26.35s 区间内（↓32%）。吞吐方面，R3 报告显示 TP4×2 全机口径下 KV 分层加速带来 +35–36% 吞吐增益【R3 实测】。这意味着：对百卡集群中常见的 8–32 路并发服务实例，外置 KV Cache 池已进入收益显著区间；而单实例低并发（≤4）场景，本地显存重算仍具成本优势。

该结论与《Efficient Memory Management for Large Language Model Serving with PagedAttention》所揭示的显存碎片化问题形成呼应：PagedAttention 通过分页管理缓解碎片，但无法消除 KV Cache 随上下文长度指数增长带来的显存压力。当单请求上下文超 32k token，且多实例共享相似前缀（如客服对话、代码补全），外置池的复用效率即成为吞吐瓶颈的关键解耦点。

缓存池化如何影响推理成本结构？需拆解“单位 token 成本”的真实构成

采购决策者常问：“上 FX100 能省多少卡？”——这是错误提问。推理成本不是单一维度的“卡数”，而是由 SLA 达标所需最小并发量、电力消耗、网络与存储 I/O 开销、运维复杂度 共同构成的函数。外置 KV Cache 池的价值，首先体现为“以更少并发满足同等 SLA”。

R2 实测数据显示：在 480B 模型冷恢复负载下，并发 16 档时 TTFT p50 从 35.73s 降至 26.35s（↓26%）【R2 实测】。若某业务 SLA 要求 TTFT ≤30s，则原需部署 24 路实例的集群，现可压缩至 16 路——相当于减少 33% 的 GPU 实例数。该压缩不改变单卡算力，但直接降低显存占用、网络转发压力与散热功耗。

更重要的是，FX100 对模型加载的加速能力（DeepSeek-70B 加载从 1399s → 150s，9.3×）【R9 实测】，大幅缩短服务冷启动时间，使弹性扩缩容响应更快，间接提升资源利用率。这在按小时计费的混合云或私有云环境中，构成可量化的成本弹性空间。

需强调：所有上述收益均以“缓存命中率 ≥75%”为前提。R4 报告验证，当冷读盘比例超过 40%，加速收益衰减明显。因此，是否上池，须先评估业务负载的热/冷比例——高频复用前缀的对话类、代码类应用优先，而纯生成类（如长文续写）则需谨慎。

百卡集群选型：为什么 FX200/FX300 比 FX100 更适配主流形态？

FX 产品线并非简单性能叠加，而是针对不同集群规模与网络拓扑的系统级匹配。FX100（PCIe 3.0，100Gb/s）适用于单机或双机小集群，其 RoCEv2 单口带宽在 8 卡以下平台已足够；但当扩展至 32–64 卡，网络聚合瓶颈凸显。

对比实测指标：

FX200 在保持更低单位 TB 成本（¥1,797/TB）的同时，提供 FX100 两倍的接口带宽，更匹配 32 卡集群中 vLLM 的 KV 并行读取需求。R1 实测中 LMCache 补丁使 Qwen2.5-32B 冷读 TTFT 从 37.97s 降至 9.30s（4.1×），该收益在 FX200 上可稳定复现并扩展至更高并发档位【R1 实测】。

结语

外置 KV Cache 池不是百卡集群的“可选项”，而是面向长上下文、高并发、SLA 敏感型推理服务的确定性优化路径。芯元一 FX 系列已在 AMD、昇腾双平台完成门禁化联测验证（G3 门禁要求 TTFT 降幅 ≥25%，吞吐 +29–40%），支持从单机到 64 卡集群的平滑演进。如需在您当前推理架构中验证该收益边界，芯元一提供 10 周门禁化联测服务（G1–G4 四阶段闭环），所有实测数据 Python 可复现、NDA 可签署。

本文要点问答

Q：百卡以内集群上外置 KV Cache 池，TTFT 和吞吐能提升多少？
A：实测显示并发 8–16 档时 TTFT 降低 26–32%，KV 分层吞吐提升 29–40%【R2/R3 实测】；该收益在 480B 模型长上下文负载下稳定达成。

Q：FX100/FX200/FX300 如何匹配不同规模集群？
A：FX100 适配 ≤16 卡单机/双机；FX200（200Gb/s）更匹配 16–32 卡；FX300（400Gb/s）面向 32–64 卡集群，三者单位 TB 成本分别为 ¥2,014/¥1,797/¥5,014【厂商口径】。

Q：模型加载加速效果是否在昇腾平台也成立？
A：是。华为 Atlas 910B 平台实测显示：DeepSeek-70B 加载从 1399s 缩短至 150s（9.3×），DeepSeek-32B 从 691s 缩短至 112s（6.2×）【R9 实测】。

References

1. Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving — https://arxiv.org/abs/2407.00079
2. Efficient Memory Management for Large Language Model Serving with PagedAttention — https://arxiv.org/abs/2309.06180
3. NVIDIA CMX Context Memory Storage Platform — https://www.nvidia.com/en-us/data-center/ai-storage/cmx/
4. MLPerf Inference: Datacenter Benchmark Suite Results — https://mlcommons.org/benchmarks/inference-datacenter/
5. ZeRO: Memory Optimizations Toward Training Trillion Parameter Models — https://arxiv.org/abs/1910.02054