NVIDIA cuObjectがファイルを超えてAIストレージを開放、ただし相互運用性はなお未完成
NVIDIAは9月30日、cuObjectのクライアントおよびサーバーライブラリを一般提供し、加速AIストレージへのアクセスを従来のファイルシステムの枠を超えて拡張した。NVIDIA cuObjectのリリースでは、サーバーCPUを経由させずにオブジェクトデータを移動するための標準化APIとRDMAワイヤープロトコルが追加された。
同社はまた、GPUから開始されるストレージ要求を処理するSCADA Server SDKも導入した。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リクエストを引き続き発行できる。その後、オブジェクトデータは通常のTCPデータパスではなくRDMA経由で移動できる。
一般提供により、開発者はサポートされた出発点を得られるが、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 writeまたはreadを使用してペイロードをプッシュまたはプルする。
RDMA操作の完了後、ゲートウェイからの正常な応答によって制御トランザクションが完了する。この分離により、アプリケーションはオブジェクトのセマンティクスを維持しながら、主なペイロード経路からサーバーCPUを外せる。
このアプローチの対象は、生の帯域幅だけではない。多数のアクセラレーターが同時にストレージ操作を生成する場合、CPU処理が制約となり得る。各ペイロードに対するTCP処理を回避することで、メタデータ、調整、セキュリティ、その他のサービスのためにCPU容量を維持できる可能性がある。
現行実装は、一般にDCと呼ばれるDynamically Connectedトランスポートを使用する。DCは、すべてのクライアントとストレージサーバーの組み合わせごとに信頼性の高い接続を維持する必要がない。この特性は、大規模コンピュートクラスターが多数のストレージノードにアクセスする場合に有用である。
NVIDIAは、InfiniBandおよびRoCEv2上でのDCサポートを文書化している。RoCEv2は、必要な動作をサポートするよう構成されたEthernetネットワーク上で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はIBM Storage Scale向けに、このSDKに基づく初期サーバーを実証した。このプロトタイプでは、SCADAクライアントがIBM構築のサーバーへリクエストを送信する。サーバーは共通のリクエストモデルをStorage Scaleへ接続する。
これは初期の相互運用性シグナルではあるが、依然として限定的である。NVIDIAはIBMプロトタイプについて、独立した本番結果を公開していない。また、この発表では、比較可能なレイテンシー、スループット、CPU使用率の測定値も示されていない。
SCADAには、サーバーSDK以外の補助的な取り組みも含まれる。NVIDIAはNVMeキューへのアクセスをプロビジョニングするStorage Lender Serviceを公開している。コマンドラインユーティリティも、SCADAコンポーネントの構成とデプロイを支援することを目的としている。
Storage-Nextイニシアチブは、より広い業界的文脈を提供する。NVIDIAによると、このグループにはフラッシュ、コントローラー、ストレージシステム、クラウドインフラ、アプリケーション開発にまたがる40社超のベンダーと顧客が参加している。
このグループは、GPU駆動ストレージがどのように動作すべきかを定義しようとしている。その取り組みは、大規模なデータ移動と小規模で細粒度の操作の両方を対象とする。目標は、ベンダー間の協力を相互運用可能なインターフェースと標準へ変えることだ。
このタイミングは、AIのデータアクセスパターンの変化を反映している。学習は引き続き重要だが、本番推論ではコンテキスト検索、ツール呼び出し、データベース検索、永続メモリが導入される。各ユーザーリクエストは、複数の下流データ操作を引き起こし得る。
ロングコンテキストサービスは、GPUメモリ外にも圧力を生む。キー・バリューキャッシュのデータは、以前に処理されたトークンのアテンション状態を記録する。この状態をアクセラレーターメモリに保持できない場合、システムには効率的に返せる別の階層が必要となる。
ストレージはアクセラレーターメモリより安価で大容量だが、レイテンシー特性は異なる。SCADAは、並列性によってGPUがこの差を許容できるようにしようとする。多数のGPUスレッドは、CPU駆動のリクエストシーケンスを待つのではなく、複数の操作を進行中の状態に維持できる。
この考え方はcuObjectの代替ではなく、補完するものである。NVIDIA cuObjectは、S3互換オブジェクトストレージへの加速アクセスに焦点を当てる。SCADAは、ストレージ実装をまたぐGPU開始型の細粒度アクセスに焦点を当てる。
これにより、NVIDIAの影響力はコンピューティングから、アクセラレータと保存データをつなぐプロトコルへと拡大する。この拡張こそが、今回の発表の背景にある主要な競争圧力を生み出している。
オープンなインターフェースとプロバイダー固有の高速化が競合
主要な争点は、共有型のアクセラレータ・ストレージ・インターフェースと、各クラウドまたはストレージプロバイダー向けに構築された個別統合との間にある。
RDMA経由のオブジェクトストレージには、広く採用された共通のワイヤプロトコルが存在してこなかった。GPUへの直接アクセスを求める開発者は、従来のS3転送に依存するか、中間ファイルシステムを使うか、あるいは特定プロバイダーの高速化パスを中心に構築する必要があった。
各選択肢には異なるコストがある。従来のアクセスは互換性を保つ一方、CPUとTCPのオーバーヘッドが残る。ステージングはローカリティを改善できるが、データの複製を伴う。プロバイダー固有の統合は高性能になり得る一方、新たな依存関係を生む。
NVIDIAはxio-sigによって、この断片化を軽減したい考えだ。xio-sig organizationは、クライアントAPI、高速化ワイヤプロトコル、適合性スイートのための個別のcuObject取り組みを説明している。同組織には、関連するcuFileの取り組みも置かれている。
インターフェースを公開しても互換性のある動作が保証されるわけではないため、適合性は重要だ。実装は、リクエストのセマンティクス、メモリ登録、エラー処理、セキュリティ境界、フォールバック動作について合意しなければならない。障害発生時および同時実行時にも、一貫して動作する必要がある。
公開時点で、この公開組織は、創設参加者が各レイヤーを統合・検証した後にコードを公開するとしている。ステータスページでも、公開に先立ってスタックが適合性テストを通過しなければならないと説明している。
つまり、NVIDIAの発表と完成した相互運用レイヤーの間には、なお大きな隔たりがある。リポジトリ構造は存在し、想定されるコンポーネントも示されている。しかし、本番利用可能な実装の多くは、依然として公開を待つ段階にある。
Google CloudとMicrosoftは、大規模なオブジェクトストレージプラットフォームを運用するクラウドプロバイダーであり、その参加は重要な信頼性をもたらす。また、NVIDIAが管理しないインフラをxio-sigが受け入れられるかを試す意味もある。
ただし、パートナー各社のコミットメントには差がある。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トークンを無効化する方法が追加された。
これらの追加機能は運用上の懸念に対応するものだが、同じドキュメントには重要な制限も記載されている。単一のメモリ登録呼び出しには4 GiB未満の上限がある。同一の登録済みバッファでは、GETとPUTの同時操作はサポートされない。
ホストメモリ転送には登録済みバッファが必要となる。cuObject I/O発行用のスレッドプールが存在しないことを含め、一部の設定動作はcuFileと異なる。アプリケーションは、このパスを採用する前にこれらの制約を理解しなければならない。
メモリのライフタイムには特段の注意が必要だ。操作が未完了の間、クライアントはバッファを再利用したり登録解除したりしてはならない。エラー処理でも、キーが再利用された後に古いリクエストがメモリ領域へアクセスしないよう防ぐ必要がある。
こうした要件は、高性能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が共有インフラになるのか、それとも最適化されたパートナー統合の集合にとどまるのかを示すシグナルは3つある。
第一のシグナルは、動作する適合性テストを伴うxio-sigコードの公開だ。同組織は、cuObjectクライアントAPI、ワイヤプロトコル、適合性スイートのリポジトリを特定している。これらのリポジトリには、インターフェース記述だけでなく実質的な実装が必要となる。
独立して保守されるクライアントとサーバーの間でテストに合格すれば、NVIDIAの相互運用性に関する主張は強化される。遅延、狭いテストカバレッジ、あるいは単一のハードウェア構成への依存は、その主張を弱める。
第二のシグナルは、クラウドおよびストレージプロバイダーによる本番サポートである。Google Cloudの評価とMicrosoftによる取締役会参加の計画は意味のあるものだが、顧客向けの提供開始の方がより重要になる。
購入者は、サポートされるサービスの組み合わせ、文書化された導入要件、明確な互換性マトリクスを確認すべきだ。IBM Storage Scale以外のSCADAサーバー実装が増えれば、このSDKが異なるストレージ設計にまたがって汎用化できるかも検証される。
第三のシグナルは、ワークロード固有の証拠だ。ベンダーは、トレーニングデータの取り込み、チェックポイント操作、リトリーバル、セマンティック検索、推論キャッシュアクセスについて、再現可能な結果を公開する必要がある。これらのテストでは、標準的なオブジェクト転送、ステージングワークフロー、RDMA対応パスを比較すべきである。
結果にはピークスループットだけでなく、CPU消費量とテールレイテンシも含めるべきだ。また、オブジェクトサイズ、ネットワーク構成、ストレージメディア、障害時の動作も開示する必要がある。この文脈がなければ、性能数値を適用するのは難しい。
開発者は、アーキテクチャの検討を始めるために待つ必要はない。アプリケーション内でオブジェクトデータがステージングされる箇所を特定し、ストレージ転送におけるCPU時間をプロファイリングし、リクエストサイズの分布を測定できる。この作業により、cuObjectまたはSCADAが実際のボトルネックに対応するかが明らかになる。
最終的な問いは、RDMAがより高速にデータを移動できるかどうかではない。複数のプロバイダーが、アプリケーションを狭いスタックに閉じ込めることなく、信頼できる単一のパスを提供できるかどうかだ。適合性リポジトリ、対応ベンダー製品、再現可能なワークロードテストに注目すべきである。これらのシグナルが、NVIDIA cuObjectがポータブルなAIストレージレイヤーになるのか、それとも別の特化型高速化オプションとなるのかを決定する。
