IBM、超微和英伟达共同验证一套 KV 缓存存储方案,把推理延迟砍到 1/56
联合参考架构显示,长上下文推理吞吐量提升 22 倍,抗网络噪声能力提升 18 倍

IBM、超微和英伟达的一项联合验证证明,把 Transformer 注意力数据路由到企业级共享存储上——而不是在 GPU 上重新计算——能让 13 万词元上下文的首词元延迟缩短到 1/56,并把并发吞吐量提升 22 倍。这项发现,记录在一份今年早些时候联合撰写的 IBM Redbook 里,并在 2026 年超级计算大会(SC26)召开前的今天正式公布,为 AI 基础设施团队提供了一份具体的蓝图,让大语言模型推理能够规模化,而不必按比例扩充 GPU 机群。这支由三家公司共 19 名工程师组成的作者团队,公布了足够详细的硬件配置、软件版本和基准测试结果,详细程度足以当作一份企业采购指南来用。
这次公告,比 SC26 在芝加哥开幕早了十天——这是 AI 和高性能计算行业年度的硬件展示盛会——届时三家公司都预计会在现场展示这套架构。这次参考设计的正式发布,是为一份自 2026 年 6 月起就已公开的技术文档举行的联合品牌活动,那份名为《无限上下文》的 IBM Redbook 最初于 6 月发表,8 月又做了更新。
为什么长上下文推理会把 GPU 的 HBM 用光
要理解这套架构解决的是什么问题,首先要理解 GPU 显存为什么会被用光。当一个大语言模型处理一段提示词时,它会为上下文窗口里的每一个词元,在每一层 Transformer 注意力层上,计算出键(K)和值(V)投影。这些投影会被保留在一个缓存里——也就是 KV 缓存——这样同一次响应里后续的词元,就能直接访问它们,不需要重新计算一次。这种设计本身是高效的:重新计算会在每个词元上浪费数以千计的 GPU 运算。
问题在于体量。KV 缓存的存储需求,会同时随着模型层数、注意力头数量、上下文长度、并发请求数和数据精度而扩大。一个 1200 亿参数的模型,在 12.8 万词元上下文下处理 50 个并发会话,可能需要超过一个 TB 的 KV 数据——远远超出单块数据中心 GPU 上 80 到 192 GB 的高带宽显存(HBM)容量。当 HBM 被占满时,推理引擎就面临一组不那么好受的选择:截断上下文(丢失信息)、驱逐再重新计算(昂贵且慢),或者排队等待(降低吞吐量)。
IBM/超微/英伟达这套参考架构,增加了第四种选项:把冷的 KV 缓存块,移到一个通过网络连接的存储层上,按需取回。这项基准测试结果,直接捕捉到了前后的对比:从头重新计算一个 13 万词元的缓存,花费了 32.14 秒的 GPU 时间。从共享存储层取回同样的数据,只花了 0.19 到 0.57 秒——而且不管上下文长度多长,这个耗时都基本持平,因为取回时间取决于数据大小和网络速度,而不是模型计算量,根据这份IBM Redbook《无限上下文》所述。
英伟达 Dynamo 的分层存储架构,以及 KVBM/NIXL 这一层
软件侧的核心支撑技术,是英伟达 Dynamo,一个开源的分布式推理框架,在 2026 年 GTC 大会上以生产形态发布。Dynamo 把 KV 缓存存储组织成一个五级层级结构:G1(GPU HBM,微秒级访问)、G2(系统 DRAM,毫秒级)、G3(本地 NVMe)、G3.5(英伟达的 CMX 网络连接设备),以及 G4(通过网络访问的企业共享存储)。
KV 块管理器(KVBM)是 Dynamo 内部负责在这些层级之间分配 KV 块的组件,它会跟踪哪些块是「热」的(最近被访问过,保留在上层),哪些是「冷」的(可以被驱逐到下层的候选对象)。英伟达推理交换库(NIXL)负责实际的数据搬运——以异步方式在各层之间移动数据块,不会让推理引擎卡住。在有支持硬件的情况下,NIXL 可以使用 RDMA 或英伟达的 GPUDirect Storage 技术,让数据在存储和 GPU 显存之间直接传输,不需要经过 CPU,从而同时降低推理主机的延迟和 CPU 负担。
IBM 和超微这次验证,把IBM Storage Scale ECE放在了 G4 这一层。Storage Scale ECE 是 IBM 的软件定义并行文件系统——是 IBM GPFS 的企业版,被用在世界上许多最大的超级计算机里,服务于基因组学、金融建模和媒体工作流。对推理这个用例而言,它通过以太网提供 RDMA 支持和 GPUDirect Storage 兼容性,这意味着 NIXL 可以把 KV 数据块,直接从 Storage Scale 流式传输进 GPU 显存,不需要 CPU 介入。
硬件技术栈与集群配置
这套参考架构的存储层,使用了八台超微 ASG-1115S-NE316R Petascale 存储服务器,每台都是一个基于 AMD EPYC 9535(Turin)处理器的 1U 机箱。选用 AMD 的 EPYC Turin 是刻意为之的:9535 提供 128 条 PCIe Gen5 通道,均分给 16 块美光 E3 7.68 TB 的 NVMe 硬盘(E3.S 规格)和两个 400 Gb/s 的网络端口。这样的通道分配,避免了当 NVMe 和高速网络共用一条较窄总线时可能出现的 PCIe 带宽争抢。
网络结构是英伟达 Spectrum-X,采用三台 SN5600 交换机组成的脊叶式(spine-leaf)配置。Spectrum-X 是英伟达专为 AI 打造的以太网结构——它包含自适应路由和拥塞控制,针对 AI 全归约运算和存储访问那种多对多的流量模式做过调优,这让它区别于通用型数据中心交换机。每台存储服务器以双 400 Gb/s 连接(每节点聚合带宽 800 Gb/s),这个八节点集群能提供最高 6.4 Tb/s 的内部网络带宽。
推理测试节点,使用了四块英伟达 RTX PRO 6000 Blackwell 工作站 GPU,搭载在一台配备英特尔至强 8592 CPU 的超微 SYS-212GB-FNR 服务器上。软件技术栈是 IBM Storage Scale ECE v6.0.0.1、英伟达 Dynamo v0.9.0、作为推理引擎的 vLLM v0.14.1,以及作为负载生成器的英伟达 AIPerf v0.6.0。所用模型是 openai/gpt-oss-120b,量化为 MXFP4——这是英伟达随 Blackwell 推出的 4 位微缩放格式——相比 BF16 能减少显存占用,同时保持吞吐量。
在集群规模划分上,这份 Redbook 定义了三个参考档位:一个小型配置(4 个存储节点,最多 64 块 GPU,20 到 75 GB/s 读带宽,面向 70 亿到 340 亿参数的模型);一个与此次基准测试相匹配的中型配置(8 个节点,100 到 300 GB/s,100 到 256 块 GPU,700 亿到 1200 亿参数的模型);以及一个大型配置(16 个以上节点,300 GB/s 以上,1000 块以上 GPU,面向超过 1200 亿参数的多模型部署)。
基准测试结果,以及它们揭示出这套架构的上限在哪里
这次验证产出了三项不同的基准测试结果。第一项,团队在不同上下文长度下,测量了单 GPU 推理的 TTFT(首词元时间),对比 GPU 重新计算与 G4 取回两种方式。在 3.2 万词元时,重新计算耗时大约 7 秒;在 13 万词元时,达到了 32.14 秒。G4 取回路径,在所有上下文长度下,都在 0.193 到 0.57 秒之间返回结果——这条平坦的曲线,正是这种取回方式的一个决定性特征,因为取数时间受限于网络延迟和数据大小,而不是模型计算量。56 倍这个提速数字,来自把最差情况下的重新计算(13 万词元)与 G4 取回做对比,详见这份IBM Redbook《无限上下文》。
第二项基准测试,测量的是并发吞吐量:28 个同时连接,100 个独特提示词,总计 2400 万个词元,搬运了 825 GB 的 KV 缓存数据。在没有缓存卸载的基线情况下,吞吐量为每秒 0.19 个请求,受限于 GPU 把大部分时间都花在了重新计算被驱逐的上下文上。启用 G4 卸载之后,吞吐量达到每秒 4.26 个请求——提升了 22 倍——200 个请求的完成时间,从没有卸载层时的 1048 秒,缩短到了 46.94 秒。
第三项基准测试,模拟了一个「吵闹邻居」环境:一个相互竞争的网络负载,在同一个 Spectrum-X 网络结构上,额外推送 200 GB/s 的流量。在这种压力下,启用了 G4 的配置依然维持在每秒 3.6 个请求,相比基线的每秒 0.19 个请求——仍然是 18 倍的提升——但相比干净网络环境下的结果,吞吐量下降了 18%。对于存储网络是共享资源的多租户企业部署场景来说,这是一次颇具实际意义的测试。
方法论里藏着一个重要的细节:在全部三项基准测试中,G1(GPU HBM)和 G2(系统 DRAM)这两个 KV 缓存层级,都被完全关闭了,容量设为零。这些测试单独衡量的是 G4 这一层的性能,不是通常会部署的那种混合层级结构。这既是一个优点(它能单独刻画出 G4 这一层的特性),也是一个局限(生产系统通常会把所有层级一起使用,G4 只处理最冷、最不常被访问的那些数据块,这会带来不同的性能特征)。
结构上更具意义的发现,是存储吞吐量与实际网络利用率之间的差距:这个八节点集群,提供了 315 GB/s 的持续读带宽,但这次基准测试只用到了 80 GB/s——客户端那张双 400 Gb/s 网卡(理论上限为每客户端 160 GB/s,加上开销后实际更低)才是真正的上限。存储系统还有将近 4 倍的余量。对那些打算把规模扩展到超出这次基准配置的团队来说,升级路径要先走客户端网络这一步——不管是在每个存储集群下部署更密集的 GPU 节点,还是升级到 800 Gb/s 的客户端网卡——之后才有必要增加存储节点。
在拥挤的 KV 缓存存储市场里,IBM/超微这套方案处在什么位置
企业级 KV 缓存卸载市场正在快速发展,多家厂商都从不同的架构方向,瞄准同一个 GPU 显存瓶颈。
VAST Data把自己的统一闪存平台,定位为一个 AI 存储层,在一次使用 AMD Instinct MI355X 硬件的基准测试里,报告了 9.7 倍的吞吐量提升。WEKA 的 Augmented Memory Grid,瞄准的是集群本地这一层,目标是在一个机架内,把活跃会话的 KV 缓存带宽最大化。戴尔把自己的 PowerScale 文件存储,与开源的 LMCache 库结合起来,在自己的验证里,公布了在 13.1 万词元上下文下,首词元时间提升 19 倍的结果。
IBM Storage Scale 的差异化,集中在 G4 层的持久化特性上。本地 NVMe 方案(G3 以及 WEKA 式的架构),能在单个节点或机架内,为缓存的上下文提供快速取回,但当一个会话迁移到另一个节点,或服务器重启时,缓存就丢失了。像 Storage Scale 这样的共享并行文件系统,能把 KV 缓存数据持久保存数天、数周甚至数月,让此前计算过的上下文,能在不同会话、不同模型,甚至硬件升级之后被复用。对于维护着持久对话历史或监管审计记录的企业级智能体工作流来说,「临时性」与「持久性」KV 存储之间的差别是重大的。
这次「吵闹邻居」基准测试,在这场竞争里也是一个差异化因素。大多数厂商的 KV 缓存基准测试,测的都是干净、隔离的环境。IBM 这份 Redbook 明确加入了一项竞争负载测试,承认了多租户企业部署的现实:在这类部署里,推理集群要与备份系统、监控智能体和其他存储消费者共享网络。
局限性、悬而未决的问题,以及 SC26 上值得关注的方向
有几点限制值得直接指出。这次基准测试所用的 GPU 硬件——四块 RTX PRO 6000 Blackwell 工作站 GPU——并不能代表数据中心级的推理配置。这个模型规模下的生产部署,通常会用英伟达的 H100、H200 或 B200 GPU,具备明显更大的 HBM 容量和不同的 PCIe 拓扑。这套参考架构的规模划分表,是推算到那些配置上得出的,但这份 Redbook 里并没有公布用数据中心级 GPU 跑出来的基准数据。
这次基准测试所用的模型,标识为经过 MXFP4 量化的 openai/gpt-oss-120b,并不是一个被广泛使用的标准参考模型。它的来源,以及它与其他 1200 亿参数模型之间的关系,这份 Redbook 里都没有说明,这限制了它与其他已发表推理基准测试之间的可比性。
针对 G4 共享存储层的 KV 缓存租户隔离问题,这份 Redbook 里没有涉及。当多个租户的 KV 缓存块,都位于同一个 Storage Scale 集群上时,访问控制和隔离模型——哪些数据块可以被哪个推理引擎访问,以及如果数据块被错误归属,或一个租户的工作负载驱逐了属于另一个租户的数据块,会发生什么——需要明确的安全设计。英伟达在 2026 年 CES 上宣布的推理上下文显存存储平台(ICMSP),用 BlueField-4 DPU 在网络边缘解决租户隔离问题,但这套超微/IBM 配置用的是 Spectrum-X,并没有具体描述基于 BlueField DPU 的租户间隔离方案。
截至本文撰写时,还没有任何独立的基准复现。所有量化的说法,都来自这个由厂商协调组成的作者团队。对一份参考架构出版物来说,这并不罕见——但用数据中心级 GPU 对 56 倍和 22 倍这两个结果做独立复现,会大幅增强这个论据的说服力。
SC26 将于 11 月 15 日在芝加哥开幕,持续到 11 月 20 日,展览部分为 11 月 17 日到 19 日。三家公司预计都会在展会现场展示这套架构。从历史上看,SC26 这类展会,除了厂商自己的演示之外,往往还会浮现出独立的高性能计算和 AI 基础设施评测,到场的从业者将有机会评估,这套参考架构的性能,能否从一个受控的 8 节点实验室测试,顺利迁移到更大规模的生产部署中。
对那些眼下正在为大模型评估推理基础设施的企业 AI 团队来说,这份 IBM Redbook,提供了目前公开可得、关于 G4 KV 缓存层最详尽的工程文档之一——在一个厂商通常只发布头条基准数字、却不公开完整方法论的市场里,这相当罕见。这次验证数据里发现的网络带宽上限,可能和吞吐量这个头条数字一样有用:它告诉团队,当自己的 KV 缓存卸载架构不再能继续扩展时,该去哪里找原因。