---
格式版本: 2
标题: "ODCC KV Cache测试结果 | 星辰天合MeshFusion推动AI推理存储多元场景落地"
原文链接: "http://mp.weixin.qq.com/s?__biz=MzA3Nzg1NDM4Mw==&mid=2654717004&idx=7&sn=9475d9ed6e2b2b743316265134e22b5e&chksm=854fde2860de4d07cccc1b13d0e0a4929494d4108eb41fc4d5c041bb323a13a9f5bb31386e8c&scene=126&sessionid=0#rd"
发布日期: "2026-06-30"
发布时间校准状态: "found"
发布时间需复核: "否"
发布时间来源: "llm:local:wechat_script_publish_field"
发布时间证据: "create_time: 2026-06-30"
发布时间校准原因: "候选日期来自微信脚本字段的创建时间，且无其他事件干扰，可确认为文章发布时间。"
发布时间校准置信度: "1"
发布时间候选数量: 1
发布时间严格候选数量: 0
发布时间原页读取状态: "原页面已读取"
发布时间未找到原因: ""
发布时间校准时间: "2026-07-26T02:20:13+08:00"
发布时间仲裁状态: "confirmed"
发布时间仲裁尝试次数: 1
发布时间仲裁耗时毫秒: 4354
发现时间: "2026-07-26T02:13:46+08:00"
入库时间: "2026-07-25T18:20:18.176Z"
来源平台: "次幂公众号"
搜索渠道: "cimidata_wechat"
搜索词: "ODCC发布"
匹配关键词:
  - "GPU"
  - "HBM"
  - "NPU"
  - "内存"
  - "计算"
  - "部署"
  - "性能"
  - "带宽"
  - "吞吐"
相关厂家:
  - "NVIDIA"
相关专家:
  []
内容类型: "公众号"
抓取工具: "次幂公众号详情"
清洗工具: "次幂 HTML 转 Markdown + Defuddle/Readability 正文提取"
原始附件:
  []
AI优质: "否"
AI打分: 62
AI分档: "召回候选"
AI质检状态: "不通过"
AI打分理由: "正文聚焦KV Cache存储方案测试，与超节点/AI Rack/机柜级系统核心主题关联较弱；虽含ODCC权威来源和详细技术数据，但缺乏架构、互连、供电、散热等关键要素；无直接量产或商业部署信号。"
AI质检模型: "deepseek-v4-flash"
AI质检时间: "2026-07-27T11:10:07+08:00"
AI主题相关性: 12
AI来源权威性: 12
AI新颖性: 10
AI技术细节: 14
AI商业部署信号: 8
AI完整性: 6
采集批次: "2026年7月25日22点32分16秒"
采集批次ID: "20260725-223216-273"
去重键: "http://mp.weixin.qq.com/s?__biz=MzA3Nzg1NDM4Mw%3D%3D&idx=7&mid=2654717004&sn=9475d9ed6e2b2b743316265134e22b5e"
---

ODCC KV Cache测试结果

为系统评估KV Cache专用存储方案的技术成熟度与场景适配能力，ODCCAI存储实验室，基于NVIDIA计算与网络平台，针对XSKY星辰天合存储系统、大普微SSD硬件，完成了面向多形态部署、多模型架构、多存储策略的KV Cache存储系统全面评测。本次测试的存储系统是XSKY星飞推理存储系统，主要验证其在推理场景下的性能表现与规模化落地能力。

一、测试方案：

多种部署形态，覆盖多元场景

XSKY星飞推理存储系统MeshFusion是专为推理场景设计的存储扩展系统，围绕KV Cache的数据特征进行深度自研，兼顾G3本地盘共享能力与G4高速访问性能，并兼容主流算力生态。系统采用极简基础架构设计，融合智能网络引擎，原生支持KV Cache接口，具备良好的可扩展性与适配性。

在部署方式上，MeshFusion支持多种灵活形态：

直接嵌入现有GPU/NPU服务器：系统可复用服务器自带的闲置NVMe盘，通过高速RDMA组建集群级共享KV Cache存储池，打破本地SSD的孤岛限制。该方式无需额外采购独立存储服务器，改造投入低，适用于已有算力集群的轻量化升级。

部署于DPU速卡：在此模式下，KV Cache数据流绕过主机CPU与内存，经由DPU直达GPU显存，实现CMX近存计算架构。配合JBOF全闪硬件构建大容量高速共享存储池，并依托Spectrum-X高速网络，可满足推理任务对高带宽、低延迟的严苛要求，尤其适合中大型规模化推理Token工厂的部署需求。

独立集群部署：基于该系统可独立构建专用的存储集群，能够高效承载海量训练数据集与推理过程中的KV Cache，为企业AI基础设施提供高性能、可扩展的统一存储底座。

![图片](https://mmbiz.qpic.cn/sz_mmbiz_png/o5O9IQVnBqQXNv8wjU0WXEViaglzLcRRcZ4Km2T2hAuTLN7UA63AK1TrbQiaJ7icB1zvcSByvKBiaAR8HprSnuUb6MxbqPbBntl86tFHKhvyic90/640?wx_fmt=png&from=appmsg&wxfrom=13&tp=wxpic#imgIndex=0)

图1 MeshFusion架构图

二、测试环境：

一套环境，验证多种方案

“

（一） 总体概述

本次测试聚焦于验证推理过程中Prefill阶段及Prefill-Decode混合阶段的性能表现，覆盖DeepSeek-R1、Qwen3-235B、DeepSeek V4与GLM-5.1等主流大模型。在推理架构层面，测试同时纳入了PD一体与PD分离两种主流方案，以评估不同调度策略下的效率差异。硬件配置上，测试选用高端HBM GPU服务器与中端GDDR GPU服务器两类算力节点，以兼顾高吞吐与高性价比的部署需求；存储系统除采用传统X86存储服务器外，还引入了基于NVIDIA BlueField-3 DPU的JBOF全闪硬件，着力探索类似NVIDIA CMX的前沿近存计算架构。上述多维度的组合设计，有效覆盖了业界当前主流以及未来演进中的各类硬件部署形态，为推理存储系统的实际选型提供了坚实的数据支撑。

![图片](https://mmbiz.qpic.cn/sz_mmbiz_png/o5O9IQVnBqQOs6IJD0U4eRQJJ9fUabC8MkRB2mvVnVSGUgUlfFoeMuDKLuzKwomsxDjlRMovicr7c4ibp425Nz5DZF9U4gQvPicGMIyYkxN4v0/640?wx_fmt=png&from=appmsg&tp=wxpic&wxfrom=5&wx_lazy=1#imgIndex=1)

图2 测试环境网络拓扑架构图

“

（二） 方案介绍

本次测试具有四种方案组合，具体如下表所示。

![图片](https://mmbiz.qpic.cn/sz_mmbiz_png/o5O9IQVnBqSVkTibn7f6PteQYV5L4Ovbh1lWTwRBVMRzoBUdz5PDmGiciakKplEkZu4kwqeMRumicD4eEukMviabVDuLDmGdbm9xEIVLpfLIHVYY/640?wx_fmt=png&from=appmsg&tp=wxpic&wxfrom=5&wx_lazy=1#imgIndex=2)

A：高端 HBM GPU 服务器 + X86 存储服务器

验证MeshFusion在“独立集群部署”下的KV Cache卸载性能。

![图片](https://mmbiz.qpic.cn/mmbiz_png/o5O9IQVnBqSFPh7f87fLA42UJN6x4BJzPCUGxzjwnial3LZKQicLBlEibVLp5I4W9F1G72YeRLhDA7e5V42wChWxPMWGiaaz5lvmHzYrsyIWWXY/640?wx_fmt=png&from=appmsg&tp=wxpic&wxfrom=5&wx_lazy=1#imgIndex=3)

图3 方案A拓扑架构图

B1：高端HBM GPU服务器+JBOF节点

验证MeshFusion在“BlueField-3 DPU+JBOF 部署(NVIDIA CMX 架构)”下的KV Cache卸载性能。

![图片](https://mmbiz.qpic.cn/mmbiz_png/o5O9IQVnBqS2kdcfA8MVj8w878ia9mlAAOpibN4IUyK4at535jiaMzdSsyHXpnUib87upAlJMU7SicV28fcO4gbclde7IkaKPvE7RNO221ia0q3yc/640?wx_fmt=png&from=appmsg&tp=wxpic&wxfrom=5&wx_lazy=1#imgIndex=4)

图4 方案B1拓扑架构图

B2：中端GDDR GPU服务器+JBOF节点

验证MeshFusion在使用“NVIDIA GDR（GPUDirect RDMA）”下的KV Cache卸载性能。

![图片](https://mmbiz.qpic.cn/mmbiz_png/o5O9IQVnBqR1LoAbHUibR84pdvfOBvhvicDOjNOgkOqMkibjkjgz1Pjpib2JQqCE19R4ljuDHLllpHz55Mm7bEvyZBmdh2MyrvFGtwZzfnByW0Q/640?wx_fmt=png&from=appmsg&tp=wxpic&wxfrom=5&wx_lazy=1#imgIndex=5)

图5 方案B2拓扑架构图

C：高端HBM GPU 服务器+中端GDDR GPU服务器+X86存储服务器

验证MeshFusion在“PD分离场景”下的KV Cache卸载性能。其中P节点和D节点之间的KV Cache传输使用NixlConnector，KV Cache卸载使用MeshFusion SDK。

![图片](https://mmbiz.qpic.cn/sz_mmbiz_png/o5O9IQVnBqRK4J3vcJwIVKYIeOiaHGZ1FpoYSaOsTSEias7Slyordra98Fmkp74Q2pcFrONic1flUP4tZicqfZOsAiacnb4ICqgk5ERPfqQjZsoU/640?wx_fmt=png&from=appmsg&tp=wxpic&wxfrom=5&wx_lazy=1#imgIndex=6)

图6 方案C拓扑架构图

三、核心成果：

创新架构，国内领先

“

（一）国内首个实现类似NVIDIA CMX架构的KV Cache存储方案

基于XSKY MeshFusion的轻量化架构，将其部署于BlueField 3 DPU中，实现了KV Cache数据与GPU显存的直通，架构如图7所示。

![图片](https://mmbiz.qpic.cn/sz_mmbiz_png/o5O9IQVnBqQMrjYE2n8jD1EblGSzKBeW2pOg5n5cxAsH85YcmG2FoyOMMYibV96jaejfsTN2UZPfqLIpdjUb1JbyOFRZVxoXicRKmy1tvOdibI/640?wx_fmt=png&from=appmsg&tp=wxpic&wxfrom=5&wx_lazy=1#imgIndex=7)

图7 DPU+JBOF部署架构图

在此架构上，本次测试以方案B1为基础，针对JBOF存储后端开展了Prefill-only场景的测试，重点对比KV Cache命中（Warm）与重算（Cold）的性能差异。结果表明，卸载KV Cache带来的收益极为显著：TTFT从数十秒锐降至命中后的百毫秒甚至数秒，尤其在长序列场景中降幅最大；而吞吐量（TPS）则整体提升了一个数量级（达10至28倍），在Cache命中时普遍稳定在7万至10万 Tokens/s。上述数据充分证明，基于DPU+JBOF构建的、形态类似NVIDIA CMX的存储架构，能够高效承载KV Cache卸载，为企业AI推理提供坚实的性能支撑，测试数据详见图8。

![图片](https://mmbiz.qpic.cn/sz_mmbiz_png/o5O9IQVnBqRPzRVk4aWorZ2yZoYWNB0hhJlMFCjjWI6oPCyROfG1QqGBg1Dft8o7516asxfw4HJwDmb0me7d5NJECVwKkWTLOVlOtakngH8/640?wx_fmt=png&from=appmsg&tp=wxpic&wxfrom=5&wx_lazy=1#imgIndex=8)

图8 JBOF后端·Prefill-only: Cold vs Warm性能对比（DeepSeek-R1,EC 4+2:1,1.6T）

为验证基于DPU的JBOF后端能否等效替代X86存储后端，AI存储实验室在相同条件下对方案A（X86）与方案B1（JBOF）进行了Prefill-only以及Prefill-Decode一体对比测试，结果分别如图9和图10所示。

在Prefill-only测试中，两者的TTFT加速比与TPS加速比高度接近，在KV Cache卸载负载下性能表现基本持平，由此充分证明基于DPU的JBOF后端完全可作为X86存储的可靠替代方案，为实际部署提供了更具灵活性的硬件选择。

![图片](https://mmbiz.qpic.cn/mmbiz_png/o5O9IQVnBqRuDsAgCAdNAxJic8CwVSy8THZlMiceTWMYqYnguCqP9djpxSR25GO8LbnIagbOI35AjN6DIlWNJk6eY7cRU7aY4AQA2DQicMANm0/640?wx_fmt=png&from=appmsg&tp=wxpic&wxfrom=5&wx_lazy=1#imgIndex=9)

图9 X86 vs JBOF后端·Prefill-only: 加速比对比（DeepSeek-R1,EC 4+2:1,1.6T）

在Prefill-Decode一体测试中，以每秒完成请求数（req/s）衡量端到端吞吐，X86存储后端与 JBOF 后端的加速比依然相似。这进一步说明 JBOF 后端在真实推理负载（含 Decode 阶段）下同样可用。

![图片](https://mmbiz.qpic.cn/sz_mmbiz_png/o5O9IQVnBqQGXRkia1T8kYbvHbT3Mhp9ShFib1lPMtJuXttlKfCG1fOJ06BzE9HVwcmeOUtrT1SCpFicecDobGiaZKgmTaGm9hrhoVVqwIzib1sA/640?wx_fmt=png&from=appmsg&tp=wxpic&wxfrom=5&wx_lazy=1#imgIndex=10)

图10 X86 vs JBOF后端·Prefill-Decode: req/s加速比对比（DeepSeek-R1,EC 4+2:1,1.6T）

在方案B2的基础上，本次进一步开展了GPUDirect RDMA（GDR）技术的KV Cache卸载测试（Prefill‑Only场景）。通过在GPU服务器部署Qwen3‑235B模型进行推理，并在4块BlueField‑3 DPU上安装MeshFusion SDK，构建GDR直通链路。本次测试着重对比了KV Cache命中（Warm/Run2）与重算（Cold/Run1）的性能。结果表明，吞吐量（TPS）从重算时的约800 tokens/s跃升至命中后的4万 tokens/s以上，如图11和图12所示。这一结果充分验证了GDR读写路径打通后，KV Cache卸载在GPUDirect方案下能够带来数量级的性能收益，证明该技术路线在高效推理场景中的巨大潜力。

![图片](https://mmbiz.qpic.cn/mmbiz_png/o5O9IQVnBqTsmqIpbMuE4I0ryCA3Z3GgPXl4pyYdh2lf54bibRCe6u5oLreyu9ZfLJPu664gvFuz4EiaW9szV1XHlkPE0h1ZbxbC0W0COSNw8/640?wx_fmt=png&from=appmsg&tp=wxpic&wxfrom=5&wx_lazy=1#imgIndex=11)

图11 GDR方案·Prefill-only: Cold vs Warm性能对比（Qwen3-235B,RTX6000 DPU+JBOF,4GPU+4DPU）

![图片](https://mmbiz.qpic.cn/sz_mmbiz_png/o5O9IQVnBqSvjQ9GDyhIysQw1RM5KY0aiaHhw2GNr4WVbQHTV6KCIa9437k0lsLhFGfUgknmUsvpcHBLDlLHw45llXicfvYMibwmiaNiaAbcKBz8/640?wx_fmt=png&from=appmsg&tp=wxpic&wxfrom=5&wx_lazy=1#imgIndex=12)

图12 GDR方案·Prefill-only:KV Cache卸载加速比（Qwen3-235B,长序列峰值58×）

基于 BlueField-3 DPU 的JBOF 的成功，可以证明 XSKY MeshFusion具备平滑移植到 NVIDIA CMX平台的能力，发挥出分布式KV Cache存储软件更大性能潜力。

“

（二）基于 NVIDIA  Spectrum-X 网络，存储与网络栈无明显软件瓶颈，扩展性可预测

本次测试基于NVIDIA Spectrum-X网络环境，结果表明，集群EC顺序读性能达272.1 GiB/s，占三台存储节点网络物理极限的97.4%；单客户端EC顺序读在1.6T条件下亦达到167.0 GiB/s，为单机网络极限的89.7%。两者均逼近各自的物理上限，充分证明存储软件栈能够高效压满RDMA网络，不存在明显的软件层瓶颈。此外，带宽容量可按网口数量线性规划，这一特性为大规模部署场景下的硬件选型与成本测算提供了可靠的量化依据。

![图片](https://mmbiz.qpic.cn/mmbiz_png/o5O9IQVnBqRDswW09k8QKLWmxERvVrTa97Y1ZqMdtLicJjtvoolA8GKjmLWtHA4rtArldc95khUmr4ib9FdmrV1lG9wq3hG83pzibibs0z8ibo3I/640?wx_fmt=png&from=appmsg&tp=wxpic&wxfrom=5&wx_lazy=1#imgIndex=13)

图13 EC 1M顺序读达成率：集群vs单客户端

在此展示3台存储节点的6个RDMA网口（400G）的带宽监控，可以看到网口带宽达到46 GiB/s，接近打满网卡物理带宽。

![图片](https://mmbiz.qpic.cn/sz_mmbiz_png/o5O9IQVnBqR8ibVpC6HHicYQJDeOdQ9vFuB0ibcmySvSibib3jmRkBYfp0RmuDfZZ9nwQ7oUh05v6LxRPEAvOKv1LSV2Wtib6IuicVhFNnrsiat5BM4/640?wx_fmt=png&from=appmsg&tp=wxpic&wxfrom=5&wx_lazy=1#imgIndex=14)

图14带宽监控图（截选）

“

（三）国内领先的支持混合注意力大模型的KV Cache存储方案

随着 DeepSeek-V4 、GLM-5.1 等采用混合注意力架构的模型兴起，其KV Cache结构与传统 MHA/GQA 显著不同。 本次测试结果表明，KV Cache 卸载后命中吞吐均远高于重算：V4-Flash 的命中吞吐稳定在4万–6万Tokens/s，吞吐加速比是6.6倍，GLM-5.1更高、峰值超过15万tokens/s，吞吐加速比是57.4倍。这证明存储侧能正确处理混合注意力模型的异构KV布局并保持高卸载收益。

![图片](https://mmbiz.qpic.cn/sz_mmbiz_png/o5O9IQVnBqREr9zFjAF6dib2RAIPxHUMAqKTIbxlNtZwEznqyMdDuTysMeKpp4WcebZnJ0RWePoVeKqIicKWdDYic4Qicz0XHlBdalcvcPvsWYw/640?wx_fmt=png&from=appmsg&tp=wxpic&wxfrom=5&wx_lazy=1#imgIndex=15)

图15混合注意力模型·Prefill-only: Cold vs Warm性能对比（X86,EC,1.6T）

“

（四）EC 纠删码和单副本在KV Cache卸载场景无性能差距

在方案A的Prefill‑only与Prefill‑Decode两类测试场景中，本次测试对比了“EC 4+2:1纠删码”与“单副本”存储策略下的性能表现。结果表明，两者的TTFT加速比与TPS加速比均无明显差异，因此生产部署可直接采用EC纠删码策略，在不牺牲推理性能的前提下同时获得更高的存储容量利用效率与数据可靠性。

进一步地，在EC策略下，KV Cache卸载带来的收益依然显著：命中（Warm）相比重算（Cold），TTFT从数十秒降至百毫秒或数秒，长序列场景下降幅最大；吞吐（TPS）提升一个数量级（10倍～32倍），命中时普遍达到7万至11万Tokens/s。该结果充分证明，即便在纠删码带来的额外计算与存储开销下，KV Cache卸载的收益仍能得到完整保留，为实际生产环境中兼顾性能与可靠性的存储选型提供了有力支撑。

![图片](https://mmbiz.qpic.cn/mmbiz_png/o5O9IQVnBqTAGK85icTOwIxJXdCjXTec3xbxcM7uNjpzvKiaXTTbKHk8PibY5wUw3IaFHAQiaeXprMID0ClZ8RcoWWyp9tjqR9e5GQHY0ejpmDo/640?wx_fmt=png&from=appmsg&tp=wxpic&wxfrom=5&wx_lazy=1#imgIndex=16)

图16 X86后端·EC 4+2:1·Prefill-only：Cold vs Warm性能对比（DeepSeek-R1,1.6T）

在 Prefill-only 场景下，“单副本”与 “EC 纠删码”的 TTFT 加速比和吞吐（TPS）加速比逐场景互有高低、整体持平。这两种存储策略在卸载场景下性能无可辨别差距。

![图片](https://mmbiz.qpic.cn/mmbiz_png/o5O9IQVnBqTe37iaRrY3OJag4OWp5okLuOfTBDbzr43ohLH9qosgJhYIR3KMl7sJF6whgERwgYiaJZhV6ydDkST4PEiaUvPISBgb030OYGVAz4/640?wx_fmt=png&from=appmsg&tp=wxpic&wxfrom=5&wx_lazy=1#imgIndex=17)

图17 X86后端·单副本vs EC·Prefill-only：加速比对比

在 Prefill-Decode 测试中，以每秒完成请求数（req/s）衡量端到端吞吐，“单副本”与 “EC 纠删码” 的 req/s 加速比同样接近，逐场景方向随机。

![图片](https://mmbiz.qpic.cn/sz_mmbiz_png/o5O9IQVnBqRYPSgJ0cttNeKiaDNTT8ibYylUmDlua6wHHzZN3LobTb9BiagIY2KpCvbdL6OAhudzc3iazfwHyQT1qyfumC537YWn5gOYsngrKhI/640?wx_fmt=png&from=appmsg&tp=wxpic&wxfrom=5&wx_lazy=1#imgIndex=18)

图18 X86后端·单副本vs EC·Prefill-Decode：req/s加速比对比

“

（五）NVIDIA  Spectrum-X 网络高级特性对于KV Cache卸载性能的影响

本次测试基于Spectrum-X网络的高级特性，重点评估了Adaptive Routing与Spectrum-X Congestion Control功能对推理性能的影响。在Qwen3‑235B模型、2K输入长度及256高并发的Prefill‑only场景下，以关闭ARCC为基线，对比了开启ARCC后KV Cache命中（Warm）路径的性能。结果表明，开启ARCC后，吞吐量与请求吞吐均提升约22.7%，首Token延迟（TTFT）改善约18.7%，充分验证了Spectrum-X网络高级特性在提升推理效率方面的积极作用。

![图片](https://mmbiz.qpic.cn/mmbiz_png/o5O9IQVnBqQLGkevevXBlic8J98bnjEUTxbibhzudcnCAIe40d3HyX1rRVibCugq5GOrHk8GpNPJteq1h1gKDDmPPTPKkKo3NicJoPwQfkGpMnk/640?wx_fmt=png&from=appmsg&tp=wxpic&wxfrom=5&wx_lazy=1#imgIndex=19)

图19 Spectrum-X ARCC vs noARCC: Warm (命中)路 KV Cache卸载性能

“

（六）网络带宽对于推理性能的影响

本次测试验证GPU服务器使用1.6T/800G/400G存储网络下KV Cache卸载性能（Prefill-only测试）。测试结果表明，1.6T与800G两档存储网络性能基本贴合且维持高位，而400G始终垫底。400G相对1.6T的吞吐比值随Input增长从79%单调下滑至55%。说明请求上下文越长、单请求KV Cache越大，400G单口带宽越成为瓶颈。而800G已能满足当前负载、受限于当前GPU规格算力制约4×400G的边际收益有限。

![图片](https://mmbiz.qpic.cn/mmbiz_png/o5O9IQVnBqSBPIJu0mSgE5qick6T1ppTtYdjtblEbtx7X5fvLOUHGqItwc3aJ6I8pP3BQV4MciaDrNumV2DIHERqfiaQxmsPHHZoUSPuq0dG94/640?wx_fmt=png&from=appmsg&tp=wxpic&wxfrom=5&wx_lazy=1#imgIndex=20)

图20 存储网络带宽影响：Input越长，400G越受限(R1,EC,Prefill-only,Warm)

本次测试也验证了 2 台 GPU 服务器使用 800G/400G 计算网络下的 PD 分离测试的性能。在 PD 分离架构下，P 节点和 D 节点间传输KV Cache的计算网络从 400G 升级到 800G 后，TTFT 加速比与吞吐加速比逐场景显著提升，800G 普遍约为 400G 的 1.7 倍（TTFT）和 1.5 倍（TPS）。说明对依赖 PD 间KV Cache传输的场景，提升计算网络带宽可带来明显的端到端性能收益。

![图片](https://mmbiz.qpic.cn/mmbiz_png/o5O9IQVnBqSsaCFJlSaPMxdV2P2Gy2JsrWJt6icJiaD7hIGiboPQ6gDB1l0tkNHRhGIpiabwuWUZNlJHan3g15pSyvhrgc30Mw2WBoaNuxftV9Y/640?wx_fmt=png&from=appmsg&tp=wxpic&wxfrom=5&wx_lazy=1#imgIndex=21)

图21 计算网络带宽影响：PD间KV Cache传输800G vs 400G(DeepSeek-V4-Flash, Prefill-only)

四、总结展望：

以创新架构推动多元场景落地

本次测试基于NVIDIA计算与网络平台，系统覆盖X86存储服务器与基于BlueField-3 DPU的JBOF（类似NVIDIA CMX架构）两类存储后端，同时验证了“单副本”与“EC纠删码”两种存储策略，并选取DeepSeek-R1、Qwen3-235B、DeepSeek-V4（混合注意力）、GLM-5.1（混合注意力）等多款主流大模型作为测试负载，力求全面评估方案在不同硬件形态与模型架构下的适配能力与性能表现。

作为ODCC AI存储实验室的重要实践，本次测试不仅验证了KV Cache专用存储系统在推理场景下的技术可行性与性能优势，也为AI基础设施的标准化建设与产业落地提供了可复用的测试方法论与参考基准。

若您对该存储系统或测试感兴趣，可直接联系相关对接人咨询。

ODCC AI存储实验室联系人

![图片](https://mmbiz.qpic.cn/mmbiz_gif/o5O9IQVnBqQKdF5LHMhcPwNsv8pvwXjibPyy1ia3l9Rskr0DNrzbyyRvCvGXXD56C6GVZh4EzW905FQicavlllZmdeyIGYCwhsFTOeV1OLt5Co/640?wx_fmt=gif&from=appmsg&tp=wxpic&wxfrom=5&wx_lazy=1#imgIndex=22)

段老师：16600265822

谢老师：18800199616

星辰天合联系人

![图片](https://mmbiz.qpic.cn/mmbiz_gif/o5O9IQVnBqQKdF5LHMhcPwNsv8pvwXjibPyy1ia3l9Rskr0DNrzbyyRvCvGXXD56C6GVZh4EzW905FQicavlllZmdeyIGYCwhsFTOeV1OLt5Co/640?wx_fmt=gif&from=appmsg&tp=wxpic&wxfrom=5&wx_lazy=1#imgIndex=23)

郑晋：15110068647

ODCC秘书处联系人

![图片](https://mmbiz.qpic.cn/mmbiz_gif/o5O9IQVnBqQzHo4s0BYjqMoQicClqmGvVTsIdSlL4LgeKVJzvEw2aXHQ10FmY5ZznqmRok72PXpt49FWIvaaJ3icK4kiaD8g6EOM3Z17co5ia9s/640?wx_fmt=gif&from=appmsg&tp=wxpic&wxfrom=5&wx_lazy=1#imgIndex=24)

刘老师：13488889649

邮箱：liupengyun@caict.ac.cn

![图片](https://mmbiz.qpic.cn/sz_mmbiz_jpg/o5O9IQVnBqTMzGMzKG9CffhLrhEnwmyaTaDlrr20W3icHMKzE36uCgem9EUNfCM8SKTkEFvEtGYB0EeribPzN6VThEzOZjiaI8YpicNj4kEP9iaU/640?wx_fmt=jpeg&from=appmsg&tp=wxpic&wxfrom=5&wx_lazy=1#imgIndex=25)

![图片](https://mmbiz.qpic.cn/sz_mmbiz_jpg/o5O9IQVnBqTC8TbkJyBwJQ6718kLnC6pCclcMGxt2MgJiankpickmXbG1xITQ6KKckxDkszs0oYfR586aUNV8oXSCTOdMiaZELr6C6OIvbrkh8/640?wx_fmt=jpeg&from=appmsg&tp=wxpic&wxfrom=5&wx_lazy=1#imgIndex=26)

往期回顾

[瓷城聚智算，标准启新程 I 2026ODCC夏季全会新技术与测试工作组](https://mp.weixin.qq.com/s?__biz=MzA3Nzg1NDM4Mw==&mid=2654716974&idx=1&sn=239a1aea1b8b15e22d9d9bf5709fae9c&scene=21#wechat_redirect)

[筑牢高效算力底座，驱动AI技术跃升 | 2026ODCC夏季全会服务器工作组会议](https://mp.weixin.qq.com/s?__biz=MzA3Nzg1NDM4Mw==&mid=2654716974&idx=2&sn=511eb502666e61848c18551959050bfd&scene=21#wechat_redirect)

[直面超大规模挑战，重塑AIDC基础设施 | 2026ODCC夏季全会设施工作组会议顺利召开！](https://mp.weixin.qq.com/s?__biz=MzA3Nzg1NDM4Mw==&mid=2654716974&idx=3&sn=7801fe7419f5d4e058e34e4cea85931c&scene=21#wechat_redirect)

[聚力智算网络创新 共筑产业标准底座｜2026ODCC夏季全会网络工作组](https://mp.weixin.qq.com/s?__biz=MzA3Nzg1NDM4Mw==&mid=2654716974&idx=4&sn=c8552eb6cbe76bcdce5030aa4150984e&scene=21#wechat_redirect)

[聚焦边缘智算，构筑AI推理新底座 | 2026ODCC夏季全会边缘计算组会议](https://mp.weixin.qq.com/s?__biz=MzA3Nzg1NDM4Mw==&mid=2654716974&idx=5&sn=ea0a6a38d493e4a27ea25fed51cdcf4d&scene=21#wechat_redirect)