NVIDIA 将 cuObject 纳入 xio-sig 并发布 SCADA Server SDK，让 GPU 经 RDMA 直连文件与对象存储

NVIDIA 与 Google Cloud、Microsoft 合作，把 cuObject 加入 xio-sig，与已有的 cuFile 并列，并宣布 cuObject 客户端与服务器库正式可用。 此前对象存储走 RDMA 缺少通用线协议，开发者只能做厂商专属集成或退回传统访问方式；现在 cuObject 提供 API 与 RDMA 线协议，xio-sig 则给出让 cuObject 客户端与任何遵循该线协议的服务器实现互操作的路径。 文中说明这是与 Google Cloud、Microsoft 的合作公告，并称 cuObject 客户端与服务器库已正式发布；仓库结构已按 cuFile 与 cuObject 分别搭建，但头文件、线协议与 libxFile、xFilekernel 实现代码要等生产就绪栈通过一致性测试后才共享，治理文档仍在待定董事会成员审阅中。

新的 SCADA Server SDK 让存储厂商可以构建 SCADA 服务器，接收来自 GPU 侧 SCADA 客户端的请求，用本地或远程存储完成请求并经 RDMA 返回结果。 SCADA 被定位为支撑高吞吐、细粒度、GPU 发起存储访问的软件基础设施，面向的是加速器发起的小而细的 I/O 请求，这类请求不适配传统存储介质与协议。 文中提到该工作还包含 Storage Lender Service 与用于配置和部署 SCADA 的 SCADA 命令行工具；IBM Storage 展示了一个原型，由 SCADA 客户端向基于新 SDK 构建的初版 Storage Scale SCADA 服务器发送请求，以此说明互操作性。

NVIDIA 通过 Storage-Next 计划牵头超过 40 家厂商与客户，包括 NAND 厂商、控制器厂商、存储提供商、超大规模云厂商与应用开发者，共同定义 GPU 驱动存储的工作方式并推动其成为可互操作的开放行业标准。 把 GPU 发起存储访问从单一厂商实现推向多方参与的开放标准制定，覆盖从介质、控制器到应用的多层参与者。 文中给出参与方数量为超过 40 家及其类别构成，并指出 SCADA 是支撑这类访问的软件基础设施；未给出标准草案的具体条款或时间表。

cuObject 库正式可用后，AI 应用开发者、开源框架开发者、存储提供商与存储消费者可用统一方式同时经文件与对象协议做加速数据访问，加速器经 RDMA 访问存储而无需让数据经过服务器 CPU。 把文件与对象两条路径统一到共享 API 与协议之下，使不同角色可以开始使用 cuObject 并为 cuFile 与 cuObject 的互操作 API 与协议社区工作做准备。 文中称这样可带来更高吞吐、更低延迟，并降低数据读写时的 CPU 占用；Google Cloud 正在评估扩大其在 xio-sig 中针对 cuObject 的参与，Microsoft 也表示期待加入 xio-sig 董事会以改善存储 I/O 互操作性。

这套组合面向需要为 AI 工作负载提供高速、安全访问高容量文件与对象存储的 AI 基础设施工程师、存储开发者与云服务提供商，适用场景包括本地与云端部署，以及训练、微调、推理上下文、工具调用、搜索与数据库查询等数据访问环节。cuObject 客户端与服务器库已正式可用，开发者可以据此构建加速的对象存储应用与服务器；存储厂商可以基于 SCADA Server SDK 构建能响应 GPU 发起请求的 SCADA 服务器，并配合 Storage Lender Service 与 SCADA 命令行工具进行配置与部署。xio-sig 的扩展为 cuObject 客户端与任何遵循线协议的服务器实现之间提供互操作路径，Google Cloud 正在评估扩大其在 cuObject 上的参与，Microsoft 表示期待加入 xio-sig 董事会。

文中未给出吞吐、延迟或 CPU 占用的具体数值，只以定性方式描述更高吞吐、更低延迟与更低 CPU 占用；cuObject 头文件、线协议与 libxFile、xFilekernel 实现代码的共享时点取决于生产就绪栈通过一致性测试，治理文档仍在待定董事会成员审阅中，因此互操作承诺的落地节奏尚不明确。Storage-Next 的开放标准制定涉及超过 40 家参与方，但文中未说明标准草案内容或时间表；SCADA 目前以 IBM Storage 的原型演示互操作性，尚未说明其他存储厂商的适配情况。语义搜索、推荐系统与欺诈检测被描述为可能受益的应用方向，属于前瞻性表述而非已验证结果。