高額なGPUがアイドル状態に陥る理由

ブログ原稿：https://www.dell.com/en-sg/blog/why-expensive-gpus-sit-idle/
筆者：Jon Hyde | 2026年6月30日

主なポイント
・GPUの性能が低いわけではなく、単に「待たされている」だけ。
・ストレージ組み込み型のAIスタックは、データがすでに到達していることを前提としている。しかし、実際のエンタープライズ環境ではデータが届いていないことが多く、時にはそもそも届かない場合もある。
・KVキャッシュのオフロードは、データの3つの形態が哲学的な概念ではなく、数値として測定可能になる具体的な領域である。
・規制、アプリケーションの結合、データ主権といった外部要因により、「データが最初に到達する」という前提は、アーキテクチャー上、非常に脆弱なものである。
・フェデレーテッド（連携型）プラットフォームは、データが存在するその場所からGPUへとデータを供給している。

NVIDIA H100を購入する際、最大の懸念事項は「間違ったGPUを選ぶこと」ではありません。真のリスクは、「適切なGPUをデータ不足に陥らせること」です。AIインフラストラクチャーにおいて最も高価なコスト項目であるGPUは、そのすぐ下の階層に潜むアーキテクチャー上の誤りに、最も強く影響されます。その誤りとは、GPUにデータを供給することを目的に設計されたデータプラットフォームではなく、データがあらかじめ供給されていることを前提に設計されたデータプラットフォームを採用してしまうことです。

当初から、構造的な法則は明確でした。データにはグラビティ（重力）があり、実際のエンタープライズ環境には歪みが存在します。そして、私たちが「データ」と呼ぶものは、実際には「データ」「メタデータ」「ベクトル」という3つの異なる形態で存在し、それぞれに独自の特性と要件があります。ここから焦点は、これらの現実を無視したアーキテクチャーが課す運用上のオーバーヘッドへと移行します。さらに論理を推し進めると、その影響はGPU層にまで達し、抽象概念は物理的な制約へと変わり、設計上の選択が実際の電力消費量として表面化し始めるのです。

目に見える症状：待たされるGPU

稼働率のグラフを前にしたことのあるAIリーダーなら、誰もがその瞬間を知っています。2つのトレーニングクラスターに数百台のNVIDIA H100。それにもかかわらず、アクティブなジョブ実行中の平均稼働率は30台にとどまっています。AIのビジネスケースを構築した経験がある人なら、その数値の意味がわかるでしょう。インフラ内で最も高価な項目が、稼働時間の大部分をアイドル状態のまま、何かが届くのを「待つ」ことに費やしているのです。

GPUが待っているもの、それはほぼ例外なく「データ」であり、より具体的には「AIサービスが認識できるネームスペースにまだ到着しきっていないデータ」です。

ボトルネックがコンピュートや相互接続（インターコネクト）であることは、ほとんどありません。何度も繰り返される原因は、ストレージ組み込み型AIスタックと、その他のデータ環境との間に存在する「継ぎ目（シーム）」です。ジョブはパイプラインを待ち、パイプラインはソースシステムを待ち、ソースシステムは変更ウィンドウを待ちます。その連鎖の末端で、数十万ドル相当のGPUがアイドル状態で放置され、電力を消費し続けているのです。

アイドル状態を引き起こすアーキテクチャー上の前提

ストレージ組み込み型AIスタックは、一見害のないように見える前提の上に構築されています。それは、「AIサービスは、すでにプラットフォーム上に到達したデータ上でのみ実行される」というものです。

この前提は、グリーンフィールド（新規構築環境）であれば問題ありません。また、範囲が厳密に限定された単一のワークロードでも問題はないでしょう。しかし、昨今のエンタープライズAIが置かれた次のような状況では破綻します。数多くのワークロード、多様なモデル、絶えず変化する多数のデータソースが存在し、限界近くまで運用されたトレーニング環境の上に、レイテンシーに敏感な推論（インファレンス）が積み重ねられている状況では、その前提は成立しません(*2)。

そのような世界では、「データがすでに到達している」という状態を継続的に維持しなければなりません。そして、以下のような外部要因こそが、その状態の維持を困難にしています。
・規制およびデータ主権上の制約：一部のデータのコピーが認められない。
・アプリケーションの結合：ソースシステムが変更ウィンドウに固定され、AIワークロード側で制御できなくなっている。
・データレジデンシー（データの所在）：ネームスペースがカバーしていない特定の地域にデータを固定している。
・データ量とデータ生成速度（データヴェロシティ）：テレメトリー、顧客との対話、トランザクションストリームなどにより、いかなる同期エンジンも追いつけないスピードでデータが生成される。

データの到着が遅れる1分1秒ごとに、下流のGPUは待ち続けます。ソースシステムの変更に同期が追いつかないたびに、ジョブ実行時に最新のデータがネームスペースに存在しないことになります。ネームスペース自体が取り込み、メタデータ、検索のボトルネックになるたびに、それを利用するすべての利用者が同時に低速化します。

GPUのパフォーマンスが低いのではありません。データの移動を「作業を開始するための前提条件」として扱ってきたアーキテクチャーのせいで、GPUが待たされているのです。

データの「3つの形態」が概念にとどまらず数値として測定可能になる領域：KVキャッシュ

この主張を具体的なものにする技術的な要素が存在します。それこそが、ストレージ組み込み型スタックと「3つの形態」アーキテクチャーの差が明確な数値として現れる場所です。

現代の推論、特に大規模言語モデル（LLM）における主なボトルネックは、KVキャッシュ（モデルがコンテキストを処理する際に構築するキー/バリューテンソル）になりつつあります。
・キャッシュをGPUメモリー内に保持すれば高速ですが、容量制限に直面します。
・キャッシュを破棄して再計算を行えば、同じ作業に対して二重のコストを支払うことになります。
・キャッシュをストレージにオフロードする場合、そのストレージがどれだけ高速か、どれだけ並列処理が可能か、そしてGPUにどれだけ近いかが非常に重要になります。

「エンタープライズAIの物理学」の視点から言えば、KVキャッシュは普通のデータとして扱うべきではない典型例です。それはベクトル（意味の構造化された表現）であり、GPUとストレージの間を高頻度で移動する必要があります。KVキャッシュを通常のデータとして扱い、顧客のソースデータと同じパスを通じて取り込まなければならないアーキテクチャーは、自らの構造と矛盾してしまうことになります。

デル・テクノロジーズは2025年10月、Qwen3-32Bモデル(*1)を使用して、このワークロードに関する直接比較テスト結果を公表しました。以下は、デル・テクノロジーズの社内テストおよびVAST社の公開情報をベースとした結果です。
・「Dell PowerScale」：0.82秒のTTFT（Time to First Token）
・「Dell ObjectScale」：0.86秒のTTFT
・VAST：1.5秒のTTFT
・KVキャッシュオフロードなしの標準vLLM：11.8秒のTTFT

言葉を換えると、デル・テクノロジーズのストレージエンジンは、標準vLLMと比較して最大19倍高速なTTFTを実現し、KVキャッシュオフロードなしの標準vLLMと比較して約14倍の高速化を達成しました。

デル・テクノロジーズとVAST社のいずれのアーキテクチャーも、推論を加速させました。しかし、オープンでGPUに最適化されたストレージ基盤は推論をさらに加速させ、結果としてクエリ応答時間の短縮とGPU稼働率の向上をもたらしました。最適化が進むにつれて数値は変動しますが、重要なのはその方向性です。容量の大きいデータを「グラビティ（重力）に縛られたもの」、意味を持つベクトルを「ポータブルなもの」として扱い、GPUへのデータ供給を目的に構築されたアーキテクチャーは、推論リクエストごとにその優位性を高めていきます。一方、GPUへのデータ供給が「まずベンダーのネームスペースにデータが届くこと」に依存しているアーキテクチャーは、構造的に一歩出遅れることになります(*3)。

この直接比較以降も、VAST社はKVキャッシュオフロードに関する公開を続けており、直近の2025年12月にはNVIDIA DynamoおよびCoreWeaveを用いた検証で、再計算と比較して約20倍のTTFT改善と90%のGPU効率向上を報告しています。しかし、これらは異なるワークロードおよびベースラインによるものであり、上記の1.5秒というTTFTを上回るQwen3-32Bによる直接比較結果は示されていません(*5)。

ストレージ製品とAIデータプラットフォームを区別するRFPの質問

初期のAIインフラストラクチャーに関するRFP（提案依頼書）では、IOPS、帯域幅、容量が問われていました。これらはストレージ「製品」に対して尋ねるべき質問です。AI「データプラットフォーム」に対して尋ねる質問としては適切ではありません。

導入から18カ月が経過するまで多くの企業が尋ねない、決め手となる質問は以下のとおりです。「規制対象のデータや、データ主権、アプリケーション結合したデータソースを含むデータ環境において、KVキャッシュオフロードを有効にした現実的な推論ワークロードを実行した際、このプラットフォーム上でのGPU稼働率はどうなりますか？」

この質問は、ベンダーに構造的な議論への対峙を迫るものです。データがネームスペースに到達できたときのことだけでなく、到達「できない」場合に何が起こるのかについての回答を求めます。現在のオープンソースモデルにおいて、再現可能なTTFT、1秒あたりのトークン数、キャッシュヒット率を、検証手法とともに公表することを余儀なくさせます。そして、最も重要な経済的質問である「御社のアーキテクチャーは、どれだけのGPUアイドル時間を想定して設計されていますか？」に対する誠実な回答を引き出すのです。

フェデレーテッド（連携型）という回答

「Dell AI Data Platform」は、ストレージ組み込み型スタックとは反対の前提に基づいて設計されています。GPUがデータを使用する前にベンダーのネームスペースへデータを到達させることを求めるのではなく、データが存在するその場所（PowerScale、ObjectScale、サードパーティ製ストレージ、データウェアハウス、クラウドなど）から、そのままの状態でGPUにデータを供給するように構築されています。さらに、KVキャッシュオフロード、高帯域幅の並列処理、推論の加速機能がスタック全体に最初から組み込まれています(*4)。

これが機能するのは、データの「3つの形態」の実際の振る舞いに合わせて動作するからです。
・容量の大きいデータ：規制、アプリケーションの結合、データ所有権の観点から求められる場所にとどまり、ガバナンス、データ主権、セキュリティを維持します。
・メタデータ：事前にデータを取り込むことなく、GPU層がデータ環境全体を可視化・選択できるように伝播します。
・ベクトル（特殊なケースとしてのKVキャッシュを含む）：アーキテクチャーがベクトルを特別なファイルとしてではなく、独立した第一級の対象として扱うため、GPUが必要とするスピードと近接性で移動します。

その結果として、ダッシュボードに本来求められていた数値が得られます。すなわち、稼働時間の多くを実際の処理に充て、データパイプラインの待ち時間が減ったGPUの姿です。

契約前に尋ねるべき3つの質問

これらをそのままRFP（提案依頼書）に盛り込んでください。
1. 当社の規制対象、データ主権、アプリケーション結合などの課題を持つデータ環境に対して、御社のプラットフォーム上でKVキャッシュオフロードを有効にした現実的な推論ワークロードを実行した場合、期待されるGPU稼働率はどのくらいですか？
ベンダーがIOPSや帯域幅でしか回答できない場合、購入しようとしているのはAIデータプラットフォームではなく、単なるストレージ製品です。
2. 現在のオープンソースモデルにおける最新の直接比較テスト結果を公表し、競合他社がそれを再現した際にもその構成の妥当性を証明できますか。
3. 単純にコピーすることが不可能なデータソースを含め、新しいデータソースがオンラインになった場合、当社のGPUがそのデータを用いてトレーニングや推論を行えるようになるまでどのくらいの時間がかかりますか。
この質問への誠実な回答こそが、そのアーキテクチャーがどれだけのGPUアイドル時間を見込んでいるかを直接示す尺度となります。

つまり、高価なGPUに投資する理由は、その能力を最大限活用するためであり、待機させるためではないということです。

今後の展望

稼働率の数値の陰には、事業を拡大しようとしたときに初めて表面化する第2の問題が隠されています。次に直面する制約はコンピュートでもストレージでもありません。それは「データセンターの建物自体」であり、すでに重力と戦っているアーキテクチャーが、電力、冷却、設置面積の面へとその戦いを拡大させていくプロセスです。それについては次回の記事で解説します。

データにはグラビティ（重力）が存在します。AIはそのデータをさらに生み出します。実際のエンタープライズ環境は歪みに満ちています。データは「データ」「メタデータ」「ベクトル」の3つの形態で存在し、それぞれ異なる要件を持っています。グラビティ、AIによるデータ増、現実環境の歪み、データの3つの形態、これら4つすべてを正しく捉えたアーキテクチャーこそが、アイドル状態のGPUを稼働状態へと変えることができるのです。なぜなら、そのアーキテクチャーはリファレンスデザインが想定する理想環境ではなく、企業が実際に運用している現実の環境のために構築されているからです。

*1. デル・テクノロジーズ「Dell Storage Engines: Accelerating AI inferencing with PowerScale and ObjectScale」2025年10月。デル・テクノロジーズのテストでは「Qwen3-32B」モデルを使用。VASTの結果は、VAST Data「Accelerating Inference」2025年7月より引用。
*2. NAND Research「How to Think about VAST Data」2026年2月。
*3. Prowess Consulting（デル・テクノロジーズの委託による調査）「Architectural and Operational Comparison: Dell AI Data Platform vs. VAST AI OS」2026年4月。
*4. デル・テクノロジーズ「Dell AI Data Platform with NVIDIA Supercharges Enterprise AI with Breakthrough Data Orchestration and Storage Innovations」PR Newswire、2026年3月。
*5. VAST Data「NVIDIA Dynamo + VAST = Scalable, Optimized Inference」2025年12月。