11月5日、SiliconAngleが「Enterprise AI hits a storage bottleneck」と題した記事を公開した。この記事では、エンタープライズAIにおけるGPU投資の効果を実質的に削いでいるストレージのボトルネック問題と、Google Cloudがその解決に向けて提示するアーキテクチャについて詳しく紹介されている。

GPUを買ったのに使い切れない——本当のボトルネックはストレージだった

過去2年間、エンタープライズAIへの投資はほぼ一点集中だった。GPUの確保、インフラ交渉、MLプラットフォームの立ち上げ——あらゆる組織がコンピュート層に全力を注いだ。しかし多くの企業が後になって気づいたのは、戦って手に入れたGPUやTPUがデータ供給待ちでアイドル状態に陥っているという現実だ。

Google Cloud StorageのVP（製品担当）であるRonen Schwartzは、AppDevANGLEポッドキャストのインタビューでこう述べている。

「多くの顧客と話すと、TPUやGPUを手に入れるために長い時間をかけて戦った、という話をよく聞く。そしていざ手に入れると、期待した出力が得られないことがある。たいていの場合、データ配送パスへの設計的配慮が足りなかったことに行き着く。」

Schwartzの言葉を借りれば、「ストレージは昇格した。バックエンドのイネーブラーから、アクセラレータ実行のフロントに立つ存在になった」。GPUは企業の最も高価な資産であり、データ待ちでアイドルになる1秒1秒が直接的なコストの無駄になる。

トレーニング・推論・エージェント——3種類のストレージ問題

この記事で特に核心をついているのが、「AIは単一ワークロードではない」という指摘だ。Schwartzは、トレーニング・推論・エージェントワークロードそれぞれがまったく異なるデータ移動パターン（"heartbeat"）を持つと説明している。

トレーニングの最大の課題はチェックポイント管理だ。大規模なトレーニングクラスターは約15分ごとに数テラバイト規模のチェックポイントを書き出す必要がある。ここでストレージが遅ければ、GPUクラスター全体が凍りつく。GoogleのRapid object storageはチェックポイントの書き込みを標準オブジェクトストレージの3倍以上高速化し、復元は5倍以上高速化するとしている。記事では自律走行車企業のTorinが具体例として挙げられており、数百万に及ぶセンサーデータがストレージに流れ込み、チェックポイント性能が「エッジケース」ではなくコアな運用要件になっていると説明されている。

推論ではリアルタイムのレイテンシが直接ユーザー体験とトークンコスト（LLMの利用料金換算）に影響する。レスポンスタイムのわずかな悪化がエンドユーザーの離脱につながるため、データをアクセラレータに届けるまでの経路設計がサービス品質を左右する。

エージェントワークロードはさらに複雑だ。複数エージェントが同一ワークスペースを共有しながら並列で動作するシナリオでは、①エージェント間でのリアルタイムなデータ共有、②タスクをまたいだ状態の永続化、③ハイバネーション（Hibernation）からの再起動時にセッション状態を完全復元する能力、という三重の要求をストレージが満たす必要がある。数千〜数百万のエージェントが同時実行される規模では、これらの要件を設計段階で織り込んでいないと後から対処することが著しく困難になる。

Googleのアーキテクチャ的な差別化

Schwartzが挙げる具体的な性能数値は以下の通りだ：

• Rapid object storage：15TB/秒のスループット、20M QPS（クエリ/秒）、サブミリ秒レイテンシ
• Google Cloud管理クラスター：10TB/秒

これを実現する技術的な柱は「Zonal Colocation」——GPUやTPUクラスターと物理的に近い場所にデータを置き、バイトがアクセラレータに届くまでの時間を最小化するアプローチだ。従来のストレージ設計はマルチゾーン・マルチリージョン分散をデフォルトとしていたが、AIワークロードではその前提が逆効果になる。データが地理的に分散しているほど、アクセラレータへの転送レイテンシが増し、GPU稼働率が下がる——という構造的な問題が生じるためだ。

Googleがこの設計を先行して提供できる根拠としてSchwartzが挙げるのは、同社が社内でフロンティアモデルのトレーニングと推論を外部提供より先に長期間運用してきた実績だ。「世界トップ10のAIフロンティアモデル企業のうち9社がGoogleと協業している」という数字も付け加えている。

非構造化データをエージェントが使えるようにする「Object Enrichment」

エージェント向けの取り組みとして、SchwartzはSmart Storage Initiativeを紹介している。その中核となるObject Enrichment機能は、ファイルや画像がストレージバケットに書き込まれた瞬間に、Google AIモデルが自動でコンテンツを解析し、構造化メタデータをオブジェクトに付与する仕組みだ。これにより、PDFや画像といった非構造化データが、手動処理や追加パイプラインなしでエージェントから検索・参照できるようになる。

エージェント基盤としては、Google Kubernetes EngineおよびエージェントサンドボックスにFilestoreのエージェント専用ボリュームが統合されており、数千〜数百万のエージェントを同時実行するコスト・レイテンシ・データ共有の要件に対応するとしている。

設計フェーズで判断しなければ後で高くつく

記事の結論は、プラットフォームエンジニアやMLインフラチームに向けて具体的だ。AIプラットフォーム構築の初期段階で行うストレージアーキテクチャの選択が、その後の全ワークロードのパフォーマンスを制約するか、解放するかを決める。ボトルネックが表面化してから見直すのは、設計段階で対処するよりはるかにコストが高い。

GPUの稼働率がKPIとして計測される時代になった今、ストレージはインフラ調達のチェックボックスではなくパフォーマンス変数として評価し直す必要がある——というのがこの記事の主張だ。

詳細はEnterprise AI hits a storage bottleneckを参照していただきたい。