NVIDIA cuObject 将 AI 存储访问拓展至文件之外，但互操作性仍未完善

NVIDIA 于 9 月 30 日正式发布 cuObject 客户端和服务器库，将加速 AI 存储访问从传统文件系统扩展至文件之外。NVIDIA cuObject 通过新增标准化 API 和 RDMA 线协议，使对象数据能够在不经由服务器 CPU 转发有效载荷的情况下完成传输。

该公司还推出了 SCADA Server SDK，用于处理由 GPU 发起的存储请求。SCADA 即 Scaled Accelerated Data Access，是一套面向海量细粒度存储操作而设计的框架。IBM 已利用该 SDK 构建了一个早期的 Storage Scale 原型。

这项发布瞄准了 AI 基础设施中长期存在的鸿沟。对象存储提供了容量扩展能力和熟悉的 S3 兼容接口，而高性能训练和推理流水线通常依赖更快的文件系统或本地临时存储。NVIDIA 希望借助 cuObject 缩小这一差距，但其更宏大的互操作性计划仍未完成。

NVIDIA cuObject 从产品库走向行业提案

重要变化不只是 NVIDIA 发布了又一个存储库，而是它正呼吁云服务与存储提供商围绕一套通用的加速对象协议达成共识。

根据 NVIDIA 公告，cuObject 客户端和服务器库现已全面可用。NVIDIA 还发布了 cuObject Server 2.0.0，供评估服务器端集成的存储提供商使用。

客户端库位于 GPU 应用程序、数据加载器或中间件层中，将应用层对象操作连接至 RDMA 数据路径。远程直接内存访问（RDMA）可让网络硬件在已注册的内存区域之间直接传输数据。

服务器库则与对象存储服务集成，负责管理已注册的缓冲区，并执行在客户端之间传输数据所需的 RDMA 操作。该系统可将目标设为 GPU 内存或系统内存。

这一设计解决了 GPUDirect Storage 尚未完全解决的问题。GPUDirect Storage 已经提供了存储与 GPU 内存之间的直接路径，但其最知名的接口 cuFile 主要围绕文件访问设计。许多 AI 数据集则存放在对象接口之后。

对于将训练样本、文档、图像、检查点和生成内容保存在 S3 兼容存储库中的组织而言，这一区别至关重要。这类系统之所以具有吸引力，是因为它们能够跨大型命名空间扩展，并将存储与计算分离。不过，传统对象访问通常仍要经过 TCP 协议栈和由 CPU 管理的缓冲区。

NVIDIA cuObject 保留了面向对象的控制操作，同时改变了有效载荷路径。客户端仍可通过经过适配的 S3 软件开发工具包发出熟悉的 GET 或 PUT 请求，而对象数据随后可经由 RDMA 传输，无需遵循常规 TCP 数据路径。

全面可用为开发者提供了受支持的起点，但 NVIDIA 正通过 xio-sig 追求更广泛的目标。该组织正从文件访问扩展至对象访问，并计划分别推进客户端 API、线协议和一致性测试。

Google Cloud 正在评估围绕 cuObject 扩大参与度。Microsoft 也表示计划加入 xio-sig 董事会。IBM 的 SCADA 原型为早期参与群体增加了一家存储供应商，但原型并不等同于生产环境支持。

这一区别正是报道的核心。NVIDIA 现在已有可下载的组件、文档，以及讨论互操作性的合作伙伴。但它尚未拥有一套成熟的多供应商对象存储标准，也尚无多个经过验证的生产级实现。

这使得此次发布既具体又带有阶段性。开发者现在可以开始评估这些库；更大的承诺则取决于云平台、存储供应商、框架和应用开发者是否采用相同接口。

NVIDIA cuObject 如何分离控制与数据

NVIDIA cuObject 将 S3 风格的控制消息保留在熟悉的路径上，同时通过 RDMA 传输对象有效载荷。

cuObject 架构 将每项操作划分为控制平面和数据平面。标准 S3 GET 和 PUT 请求仍属于控制流程的一部分；经过适配的 S3 SDK 会添加描述 RDMA 传输的元数据。

对象有效载荷则走另一条路径。客户端注册一块内存区域，并创建一个包含传输所需信息的 RDMA 令牌。该令牌会通过自定义请求头附加到 HTTP 请求中。

存储网关解析请求，并指示合适的数据节点执行操作。该节点通过 cuObject 服务器 API 注册本地缓冲区，随后使用 RDMA 写入或读取来推送或拉取有效载荷。

RDMA 操作完成后，成功的网关响应会完成控制事务。这种拆分方式让应用保留对象语义，同时将服务器 CPU 从主要的有效载荷路径中移除。

这一方法瞄准的不只是原始带宽。当大量加速器并发生成存储操作时，CPU 处理可能成为约束因素。避免对每个有效载荷进行 TCP 处理，可为元数据、协调、安全及其他服务保留 CPU 容量。

当前实现采用动态连接传输（Dynamically Connected transport），通常称为 DC。DC 无需在每一对客户端和存储服务器之间维持可靠连接。当大型计算集群需要访问大量存储节点时，这一特性尤为有用。

NVIDIA 记录了通过 InfiniBand 和 RoCEv2 提供的 DC 支持。RoCEv2 可在配置为支持所需行为的以太网上承载 RDMA 流量。两种方案都需要在安装库之外进行基础设施规划。

客户端也不会与未经改动的 S3 端点直接交互。NVIDIA 的文档指出，集成需要修改客户端 S3 SDK 和服务器端存储软件。这些改动用于创建加速路径并交换 RDMA 元数据。

支持的操作包括 GET、PUT、分段上传操作和字节范围读取。范围访问适用于应用只需要大型对象的一部分，而非将整个对象传输至 GPU 内存的场景。

这一架构可以移除常见的数据暂存步骤。传统 AI 流水线通常会将数据从对象存储库复制到本地或分布式临时文件系统，计算节点随后再从该中间层读取数据。

暂存能够提供可预测的性能，但也会占用容量并增加运维工作。团队必须安排复制任务、监控同步、清理陈旧数据，并决定哪些数据集值得使用高速存储。

NVIDIA cuObject 提出了一条从对象存储直达加速器内存的更扁平路径。如果端到端均获支持，应用就可以直接从主对象存储库读取，而无需先创建另一份完整副本。

这一优势并不能消除所有中间操作。数据仍可能需要解码、解压、验证、批处理或转换。存储软件在通过 RDMA 交付有效载荷前，也可能使用内部缓冲区。

因此，此次发布改变的是传输层面的机会，而非整个数据流水线。应用仍需管理格式、访问权限、对象元数据和故障恢复；存储供应商则必须将加速路径连接到自身的数据放置和持久化系统。

NVIDIA cuObject 最适合作为这些组件之间的集成层。它并不替代对象存储、S3 控制平面、数据加载器或网络基础设施。

SCADA Server SDK 将请求控制转向 GPU

SCADA Server SDK 解决的是另一项瓶颈：大量小型请求的协调工作可能在存储达到极限前就压垮 CPU。

对于大型顺序传输，带宽是显而易见的指标。读取大尺寸样本或检查点的训练任务，可将请求开销分摊到每次传输中，控制工作占整个操作的比例也更小。

推理和检索系统则会形成另一种模式。语义搜索、推荐、欺诈检测和智能体记忆可能产生大量更小的查询。GPU 可以拥有足够多的并行任务，以高并发方式发起这些操作。

传统存储软件预期由 CPU 构造、提交和完成这些请求。随着请求规模缩小、操作数量上升，这种设计的效率会逐渐下降。固定的处理成本会占据每笔事务更大的比例。

SCADA 让基于 GPU 的客户端能够通过通用接口发起存储请求。新的 SDK 为第三方存储提供商提供了构建服务器的方法，以接收这些请求。服务器可从本地或远程存储中完成请求，再通过 RDMA 返回数据。

该 SDK 并不要求每个存储系统直接向 GPU 暴露其内部设计。相反，SCADA 服务器充当共享客户端接口与供应商特定存储逻辑之间的桥梁。

IBM 已展示了一个基于该 SDK、面向 IBM Storage Scale 的初始服务器。在该原型中，SCADA 客户端向 IBM 构建的服务器发送请求，服务器将通用请求模型连接至 Storage Scale。

这是一个早期的互操作性信号，但其范围仍然有限。NVIDIA 尚未公布 IBM 原型的独立生产结果。公告也未提供延迟、吞吐量或 CPU 利用率的对比测量数据。

SCADA 除服务器 SDK 外还包含支持性工作。NVIDIA 已发布 Storage Lender Service，用于配置对 NVMe 队列的访问；另有一款命令行工具旨在帮助配置和部署 SCADA 组件。

Storage-Next 倡议 提供了更广泛的行业背景。NVIDIA 表示，该组织汇聚了 40 多家供应商和客户，覆盖闪存、控制器、存储系统、云基础设施和应用开发等领域。

该组织正尝试定义 GPU 驱动的存储应如何运作。其工作同时覆盖大型数据传输和小型细粒度操作，目标是将供应商协作转化为可互操作的接口和标准。

这一时机反映了不断变化的 AI 数据访问模式。训练仍然重要，但生产级推理引入了上下文检索、工具调用、数据库查询和持久化记忆。每个用户请求都可能触发多项下游数据操作。

长上下文服务也会在 GPU 内存之外产生压力。键值缓存数据记录了先前处理的 token 的注意力状态。当这些状态无法保留在加速器内存中时，系统就需要另一层能够高效返回数据的存储。

存储比加速器内存更便宜、容量也更大，但其延迟特性不同。SCADA 试图通过并行性让 GPU 容忍这种差距。大量 GPU 线程可以让操作保持在途，而非等待由 CPU 驱动的请求序列。

这一思路与 cuObject 相辅相成，而非取而代之。NVIDIA cuObject 专注于加速访问 S3 兼容对象存储；SCADA 则专注于跨存储实现的、由 GPU 发起的细粒度访问。

它们共同将 NVIDIA 的影响力从计算延伸至连接加速器与存储数据的协议层。这一扩张正是本次发布背后的主要竞争压力。

开放接口与供应商专属加速方案的竞争

核心竞争在于共享的加速器—存储接口，与为各云服务或存储供应商分别构建的集成方案之间。

基于 RDMA 的对象存储长期缺乏被广泛采用的通用线缆协议。希望让 GPU 直接访问数据的开发者，可以依赖传统 S3 传输、使用中间文件系统，或围绕特定供应商的加速路径进行构建。

每种选择都会带来不同成本。传统访问可保持兼容性，但仍保留 CPU 与 TCP 开销。数据暂存可改善数据本地性，但会造成数据重复。供应商专属集成可能具备出色性能，却会增加另一层依赖。

NVIDIA 希望通过 xio-sig 减少这种碎片化。xio-sig organization 将 cuObject 的工作拆分为客户端 API、加速线缆协议和一致性测试套件。该组织还包含相关的 cuFile 工作。

一致性至关重要，因为发布接口并不保证行为兼容。各实现必须就请求语义、内存注册、错误处理、安全边界和回退行为达成一致；在故障与并发情境下，它们也必须表现一致。

截至发布时，该公开组织表示，代码将在创始参与者完成各层集成与验证后出现。其状态页面也称，这些技术栈必须先通过一致性测试，才会进行该发布。

这使 NVIDIA 的公告与完成的互操作层之间仍存在显著差距。仓库结构已经存在，预期组件也已被命名；但大量可用于生产环境的实现仍待公开发布。

Google Cloud 和 Microsoft 带来了重要可信度，因为云服务供应商运营着大型对象存储平台。它们的参与也检验了 xio-sig 能否兼容不受 NVIDIA 控制的基础设施。

不过，合作伙伴作出的承诺并不相同。Google Cloud 正在评估更广泛参与 cuObject 的可能性；Microsoft 则表示有意加入董事会。仅凭这两项表态，均无法确认其对象服务会面向普通客户提供该能力。

IBM 的原型提供了更具体的实现，但它涉及 SCADA 和 Storage Scale。这并不能证明多个独立的 S3 兼容平台能够通过一项经过生产验证的单一协议交换 cuObject 流量。

存储公司也有理由保留自身的加速方法。供应商专属路径可体现差异化的缓存、数据放置、安全或数据服务。共享协议必须足够广泛以实现互操作，同时又不能抹去这些功能。

NVIDIA 自身也有战略利益。从存储到 GPU 内存的通用路径，可让 NVIDIA 加速器更容易处理更大规模的数据集；它还可将网络产品、DPU、CUDA 软件和存储合作伙伴纳入协调一致的架构。

这并不意味着互操作性推进本质上是封闭的。该公开组织当前仓库采用 Apache-2.0 许可证，一致性工作也能降低集成风险。不过，治理和实现细节将决定最终结果究竟有多开放。

其他加速器供应商构成了另一项考验。NVIDIA 的文章在描述计算需求时提到了 GPU、TPU 和 XPU。真正可移植的存储接口不应在每一层都依赖某一种加速器架构。

最明确的证据将来自通过共享测试的非 NVIDIA 实现。对常见框架的支持同样重要。开发者较少关心组织成员资格，更在意现有应用是否能在无需重写的情况下切换后端。

对于存储采购方而言，实际问题是可移植性。当一个接口能在多种受支持产品之间保持应用行为时，它才有价值。绑定于某一经验证组合的单一高速路径，仍是一种集成，而非行业标准。

正式可用并不意味着部署风险消失

这些库已经可用，但生产环境采用仍需要专用网络、经过修改的软件、谨慎的内存管理以及可信的基准测试。

cuObject release notes 显示，客户端于 2026 年 8 月达到 1.3.0 版本。更早版本加入了多路径故障切换、故障恢复和 IPv6 支持。1.3.0 版本则新增了使过期 RDMA token 失效的方法。

这些新增功能回应了运维层面的关切，但同一份文档也列出了重要限制。单次内存注册调用的最大值低于 4 GiB；同一已注册缓冲区不支持并发 GET 和 PUT 操作。

主机内存传输需要使用已注册缓冲区。部分配置行为与 cuFile 不同，其中包括 cuObject I/O 请求不提供线程池。应用在采用该路径前必须理解这些约束。

内存生命周期需要特别谨慎处理。当操作尚未完成时，客户端不得复用或注销缓冲区。错误处理也必须防止内存区域密钥被复用后，过期请求继续访问该区域。

这些要求对于高性能 RDMA 软件并不罕见，但它们确实将更多责任转移给应用、框架和存储开发者。错误的集成可能导致难以诊断的故障。

网络同样重要。通过 InfiniBand 或 RoCEv2 的 DC 传输，假定已具备适当的适配器、交换机、路由和配置。组织不能期待加速路径无需基础设施建设就能在普通网络中出现。

RoCE 部署可能对拥塞和网络结构较为敏感。多路径行为、故障恢复和遥测必须在真实流量下进行测试。一次成功的实验室传输，并不能证明整个集群能提供可预测的性能。

安全同样值得关注。直接数据传输减少了负载路径中 CPU 的参与，但不能绕过授权。系统仍需要可信的控制层，以决定哪个进程可访问每个已注册区域和存储对象。

NVIDIA 将 SCADA 描述为把非特权应用工作与特权设置组件分离。这种结构若实现正确，可以保护数据路径。存储供应商仍须将其与租户隔离、审计、凭据管理和撤销机制相结合。

该公告没有提供将 cuObject 与传统 S3、暂存式文件访问或供应商专属替代方案进行比较的标准化基准测试，也没有量化 IBM 原型的收益。

这一缺失阻碍了广泛的性能结论。RDMA 可以减少复制和 CPU 处理，但应用效果取决于对象大小、访问模式、存储介质、网络拓扑、并发度和预处理。

大型顺序读取可能已经能通过优化后的文件系统充分发挥性能。极小请求则可能暴露其他环节的限制，包括闪存转换层、元数据服务或应用同步。

围绕 SCADA 的独立存储分析 强调了这种差异。批量传输和细粒度读取提出的要求不同，因此没有任何单一的标题级吞吐量数字能同时描述二者。

因此，开发者应将 NVIDIA cuObject 视为需要评估的路径，而非有保证的性能结果。测试应使用真实对象大小、具有代表性的并发度、既有的数据转换流程以及预期的故障情景。

可信的概念验证不应只衡量带宽，还应跟踪尾延迟、服务器 CPU 消耗、GPU 利用率、内存注册开销、恢复时间，以及 RDMA 路径不可用时的行为。

团队还应验证回退行为。当服务器不支持 RDMA 或网络组件发生故障时，生产应用需要有明确的应对方式。与普通对象访问的兼容性，可能与峰值加速性能同样重要。

最强烈的怀疑并不针对技术可行性，而是针对采用情况。NVIDIA 已展示这些组件可以构建，但尚未证明广泛的供应商群体会在多个发布周期中维护兼容实现。

NVIDIA SCADA Server SDK 发布后值得关注的事项

三个信号将表明 NVIDIA cuObject 会成为共享基础设施，还是仍停留在一组经优化的合作伙伴集成方案。

第一个信号是公开的 xio-sig 代码及可运行的一致性测试。该组织已为 cuObject 客户端 API、线缆协议和一致性测试套件确定了仓库。这些仓库需要提供实质性实现，而不只是接口说明。

在独立维护的客户端和服务器之间通过测试，将强化 NVIDIA 的互操作性主张。延迟、有限的测试覆盖范围，或对某一硬件组合的依赖，都会削弱这一主张。

第二个信号是云服务和存储供应商的生产支持。Google Cloud 的评估和 Microsoft 计划参与董事会均有意义，但面向客户的可用性更为重要。

采购方应关注受支持的服务组合、已记录的部署要求和清晰的兼容性矩阵。除 IBM Storage Scale 之外，若出现更多 SCADA 服务器实现，也将检验该 SDK 是否能适用于不同存储设计。

第三个信号是面向特定工作负载的证据。供应商需要发布可复现的训练数据导入、检查点操作、检索、语义搜索和推理缓存访问结果。这些测试应比较标准对象传输、暂存工作流和启用 RDMA 的路径。

结果应包含 CPU 消耗和尾延迟，而不仅是峰值吞吐量；还应披露对象大小、网络配置、存储介质和故障行为。缺少这些背景，性能数字将难以应用。

开发者无需等待即可开始研究该架构。他们可以识别应用在哪些环节暂存对象数据，分析存储传输中的 CPU 时间，并测量请求大小分布。这些工作将揭示 cuObject 或 SCADA 是否解决了真实瓶颈。

最终问题并非 RDMA 能否更快地传输数据，而是多个供应商能否提供一条可靠的统一路径，同时不把应用困在狭窄的技术栈中。请关注一致性仓库、受支持的供应商产品和可复现的工作负载测试。这些信号将决定 NVIDIA cuObject 是成为可移植的 AI 存储层，还是另一种专用加速选项。