ストレージ専門メディアのBlocks & Filesは2026年11月4日、xAIのAI計算基盤「Colossus 2」のストレージ容量が5.2EB（エクサバイト）を超える可能性があると報じた。ただし、これは新たに公開された設備仕様ではなく、初期のストレージ容量と年末のGPU増設目標を基にした推計だ。AIの学習では、大量のデータを保存できるだけでなく、必要なデータをGPUへ速やかに供給し、学習途中の状態を効率よく保存する能力も求められる。ストレージの読み書きが遅ければ、GPUがデータを待つ時間が生じ、計算能力を十分に活用できない。Colossusの拡張を評価するには、ストレージの総容量と、実際の学習を支える入出力性能を分けて考える必要がある。
5.2EB超という数字はGPU数に基づく推計
Blocks & FilesのChris Mellor記者による推計は、初期の約23万基のGPUと1EB超のストレージを基準に、年末目標の約120万基までGPUが増えた場合、ストレージ容量も同じ比率で増加すると仮定したものだ。計算式は「120万÷23万×1EB≒5.217EB」となり、基準となる容量が1EBを超えていることから、推計値も5.2EB超としている。Mellor記者自身も、この数字は非常に大まかな概算であると断っている。
重要なのは、GPUの増加率をストレージ容量に当てはめただけであり、実際に保存するデータ量を積み上げて計算したものではないという点だ。例えば、同じ学習データを多数のGPUで共有する場合、GPU数が増えても固有のデータ量が同じ割合で増えるとは限らない。一方、学習途中の状態を何世代分保存するか、障害に備えてどの程度の冗長性を持たせるかによっても必要な容量は変わる。こうした条件はGPU数だけでは判断できない。
ストレージ容量の定義にも注意が必要だ。5.2EB超という数字が、記憶媒体の物理容量の合計を指すのか、冗長化などによる消費分を差し引いた利用可能容量なのか、データ削減の効果を含めた実効容量なのかは分からない。したがって、購入したSSDの総容量や、すでに稼働している設備の容量として扱うことはできない。また、約120万基というGPU数も年末の増設目標であり、現時点で設置が完了した台数ではない。
初期のColossusではDDNとVAST Dataの採用を確認できる
DDNは2024年11月18日、10万基のHopper GPUを備えた段階のColossusに、同社のストレージ製品「EXAScaler」とデータプラットフォーム「Infinia」を組み合わせると発表した。この発表から、少なくとも初期のColossusにDDNの製品が採用されたことは確認できる。
VAST Dataについても、共同創業者のAlon Horevが共有したRenen Hallakの公開発言で、VAST Data PlatformがColossusのデータ処理とモデル学習を支えていることが説明されている。ただし、確認できる投稿表示からは、発言の正確な年月日を特定できない。
これらの発表や発言は、ColossusにDDNとVAST Dataの技術が採用されたことを裏付ける資料となる。しかし、2026年時点で各施設にどの製品がどれだけ導入されているか、両社がどの処理を分担しているか、ストレージ容量をどのような割合で供給しているかまでは明らかになっていない。初期のColossusにおける採用実績を、そのままColossus 2の設備構成に当てはめることはできない。
GPUの稼働を妨げる三つの待ち時間
AIモデルの学習では、学習データを読み込むだけでなく、途中まで進んだ学習の状態を定期的に保存する必要がある。この処理は「チェックポイント保存」と呼ばれ、障害が発生した際に、保存した時点から学習を再開するために使われる。PyTorchの公式文書では、モデルのパラメータに加え、それらを更新する最適化器の状態を保存する例が紹介されている。つまり、学習済みモデルの最終成果物を保存する容量を確保するだけでは不十分だ。
AI向けストレージを評価する際には、保存容量に加え、学習データの読み込み、チェックポイントの書き出し、障害後の復旧という処理をそれぞれ確認する必要がある。以下の表は、NVIDIAの認定ストレージ技術文書、保存・復旧時の通信に関する技術解説、前述のPyTorch文書を基に、AI学習で求められるストレージの役割を整理したものだ。Colossusの実測結果や、特定製品の性能を比較したものではない。
| 評価項目 | 主な処理 | 確認すべき性能・条件 | 性能が不足した場合の影響 |
|---|---|---|---|
| 保存容量 | 学習データや途中状態を保持する | 必要なデータ量を保存できる容量と保持条件 | 必要なデータや状態を保存できない |
| 学習データの読み込み | GPUへ計算に必要なデータを供給する | 継続的な読み込み性能と遅延 | GPUがデータの到着を待つ |
| チェックポイント保存 | 学習途中の状態を書き出す | 保存にかかる時間と、短時間に集中する書き込みへの対応 | 保存処理による待ち時間が増える |
| 障害後の復旧 | 保存済みの状態を読み戻して学習を再開する | 読み込み性能と再開までの所要時間 | 計算の再開が遅れる |
保存容量は、必要なデータや学習状態を保持できるかを左右する。一方、残る三つの項目は、GPUが計算を進められるまでの時間に直接関係する。ただし、これらの処理は同時並行で進む場合もあるため、それぞれの所要時間を単純に合計してGPU稼働率を算出することはできない。Colossusについても、実効的な読み書き帯域やチェックポイント保存時間、障害後の復旧時間は確認されていない。
チェックポイント保存の頻度にもトレードオフがある。保存回数を減らせば書き込み負荷は軽くなるが、障害が発生した際に再開できる時点が古くなり、やり直す計算量が増える可能性がある。反対に頻繁な保存は、障害時の損失を抑えられる一方で、ストレージへの負荷を高める。保存をどれだけ速く完了できるかと、どの時点まで戻って学習を再開できるかは、併せて評価しなければならない。こうした条件は、ストレージの総容量だけでは分からない。
非同期保存と処理・容量の分離、それぞれに必要な設計
PyTorchが提供する非同期チェックポイント保存は、保存処理とモデルの学習を並行して進める仕組みだ。公式文書では、学習中に更新されるモデルの状態と保存するデータを分離するため、状態をCPU側の内部バッファへコピーする方法が説明されている。これにより、ストレージへの書き込みが完了するまで学習を待たせる負担を軽減できる。ただし、コピーを保持する追加のCPUメモリが必要になり、複数の保存処理が同時に実行される場合の管理も欠かせない。PyTorchの文書では、原則として一度に実行する非同期保存を一つに制限することが推奨されている。
つまり、非同期化によって保存処理そのものがなくなるわけではない。学習と保存を並行させるために、追加のメモリ領域と適切な実行制御が必要になる。なお、ColossusがこのPyTorchの方式を採用しているかどうかは明らかになっていない。
一方、VAST DataのDASEホワイトペーパーでは、ストレージ側で処理能力と保存容量を分離するアーキテクチャが説明されている。処理を担当するノードを「CNode」、記憶媒体とシステム状態を保持する装置を「DBox」と呼ぶ。各CNodeは、ネットワーク経由でNVMeストレージにアクセスする「NVMe-oF」を利用し、ストレージ全体にアクセスできる。この構成により、データ処理を担うノードと保存容量を独立して増設できる。
VAST Dataは、書き込みデータを高耐久SSDのバッファで一時的に受け止め、その後、大容量のフラッシュストレージへ移す設計も説明している。短時間に集中する書き込みを処理する領域と、データを長期的に保持する領域を分ける仕組みだ。ただし、これらはVAST Data製品の一般的なアーキテクチャに関する説明であり、Colossusに導入された製品の世代や設定、実際のバッファ構成が確認されたわけではない。
PyTorchの非同期保存は、学習ソフトウェア側で計算と保存を並行させる方法であり、VAST DataのDASEはストレージ側で処理能力と容量を分離する方法だ。対象とする領域は異なるものの、どちらも保存容量を増やすだけでは解決できない課題に対応している。大規模AI基盤では、ストレージ容量の増設と、データ処理能力や通信性能の強化を分けて検討する必要がある。
通信スループット95%はストレージ性能を意味しない
NVIDIAは2024年10月28日、初期Colossusの10万基のGPUを接続するネットワーク技術「Spectrum-X」について、学習中に95%の通信スループットを維持したと発表した。スループットは単位時間当たりのデータ転送量を表す指標だ。ただし、この95%はネットワーク通信に関するものであり、GPUが稼働時間の95%を計算に使っていたという意味ではない。ストレージの読み書き帯域を測定した数字でもない。
もっとも、ストレージの性能を評価するうえで、ネットワークを無視することはできない。NVIDIAが2025年2月4日に公開した技術ブログでは、チェックポイントの保存や復旧に伴い、短時間に大量のデータ転送が集中する「バースト通信」が発生すると説明されている。ストレージ自体が高速でも、そこへ接続するネットワークが混雑すれば、データの読み書きに時間がかかる。特に大規模なGPUクラスタでは、ストレージと計算ノードの間で十分な通信性能を維持できるかが重要になる。
同ブログでは、NVIDIAのIsrael-1でHGX H100サーバーを使用し、40〜800基のGPUをクライアントとする構成で実施した試験も紹介されている。入出力性能を測定するツール「fio」を使い、標準的なRoCE v2の構成と、適応ルーティングおよび輻輳制御を有効にした構成を比較した。その結果、読み込み帯域は20〜48%、書き込み帯域は9〜41%改善した。ただし、これはColossusとは別の環境で実施された入出力試験であり、Colossusの学習速度が同じ割合で向上したことを意味しない。EB級のストレージ環境でも同様の改善が得られると保証するものでもない。
NVIDIAの認定ストレージ技術文書でも、瞬間的な最高性能だけでなく、負荷を繰り返した際の性能や遅延、復旧可能性を評価する方針が示されている。これはAI向けストレージを評価するための基準であり、Colossusが同認定を取得しているという意味ではない。
Colossusの拡張が実際の学習性能にどれほど貢献するかを判断するには、ストレージの実効的な読み書き性能に加え、チェックポイントの保存や障害後の復旧にかかる時間を確認する必要がある。さらに、学習データの読み込みとチェックポイント保存などが同時に発生しても、安定した性能を維持できるかが重要だ。5.2EB超という推計値は設備の規模を考える手掛かりにはなるが、増設されたGPUをデータ待ちにさせず、継続的に計算へ投入できるかを判断するには、容量とは別の性能指標が欠かせない。
