高速GPUだけではAIインフラのボトルネックを解消できない
SK hynix Newsroomは2026年8月31日、GPU中心の考え方に真っ向から異を唱えた。データの到着が遅ければ、高速なアクセラレータも待機を余儀なくされる。同社の主張は、チップのピーク仕様から、各プロセッサを取り巻くインフラへと焦点を移すものだ。
このinfrastructure analysisは、本番環境のAIには、コンピュート、メモリ、ネットワーキング、ストレージ、電力、冷却を連携させる必要があると述べている。いずれかの層が弱ければ、高価なアクセラレータは公称性能を発揮できない可能性がある。
この見解は、アクセラレータ競争に対し、より目に見えにくい現実を突きつける。NVIDIA、AMD、Google、クラウド事業者、メモリ供給企業、データセンター建設事業者は、個別部品ではなくシステム全体を最適化しなければならない。入手可能な中で最速のGPUを購入しても、最速のトレーニングジョブやAIサービスが保証されるわけではない。
hynix Newsroom、チップからデータフローへと注目を移す
中心となる主張はシンプルだ。アクセラレータは、まだ受け取っていないデータを使って計算することはできない。
SK hynixの記事は、変化するAIデータセンターを扱う全4回シリーズの第2回に当たる。インフラ変化の概要に続き、電力、冷却、将来のシステム設計を扱う記事に先行する内容だ。
今回の記事は、高速GPUが自動的にAI運用を高速化するのかを問いかける。SK hynixの答えは、条件付きで「いいえ」だ。コンピュートは依然として不可欠だが、そのコンピュートのうちどれだけが実用的な性能になるかは、データ供給によって決まる。
GPUは、多数の数学演算を同時に実行できる並列プロセッサだ。AIアクセラレータには、機械学習の計算向けに設計されたGPU、ニューラルプロセッシングユニット、テンソルプロセッシングユニットが含まれる。
これらのプロセッサは、連鎖する支援システムに依存している。モデルパラメータはメモリからコンピュートユニットへ移動しなければならない。トレーニングデータはストレージから到着する必要がある。ワークロードが複数のプロセッサにまたがる場合、結果はインターコネクトを通過しなければならない。
この連鎖のどこかが遅れれば、アクセラレータはアイドル状態に陥る可能性がある。利用率が下がっている間も、事業者は導入済み容量、電力、冷却、ネットワーキング、床面積に対して費用を負担するため、この待機時間は重要だ。
SK hynixは、UC Berkeley、ICSI、Lawrence Berkeley National Laboratoryに関係する研究者らによる2024年の論文で自らの主張を補強している。このmemory wall studyは、サーバーのコンピュートとデータ移動が20年にわたりどのように発展してきたかを調査した。
論文によれば、サーバーのピークFLOPSは2年ごとに約3倍に増加した。これに対し、DRAM帯域幅は約1.6倍、インターコネクト帯域幅は同期間に約1.4倍増加した。
FLOPSは、システムが1秒間に実行できる浮動小数点演算の理論上の回数を示す。帯域幅は、一定期間にメモリまたは接続を通じて移動できるデータ量を測る指標だ。
異なる成長率がメモリウォールを生み出す。コンピュート能力はそれを供給する経路より速く向上するため、より多くのワークロードが演算ではなくデータ移動によって制約されるようになる。
これは、すべてのAIワークロードが同じボトルネックに直面することを意味しない。モデルアーキテクチャ、バッチサイズ、数値精度、ソフトウェア効率、導入規模はいずれもバランスを変える。
しかし、この長期的な差は、高速プロセッサだけでは性能向上が一様にならない理由を説明する。すでにメモリやネットワーキングに制約されているワークロードは、他の部分を変更しなければ追加コンピュートを十分に活用できない。
したがって、hynix Newsroomは単なる技術的な指摘にとどまらない。競争の単位が半導体から、それを取り巻く完全な運用システムへと拡大したと論じている。
AIインフラの購入者は今、バランスという課題に直面している
この圧力は、供給するワークロードやシステムを測定せずにアクセラレータを購入するすべての人に及ぶ。
企業の購入担当者は、しばしばGPU台数からインフラ計画を始める。この数値は比較しやすいが、メモリ容量、通信効率、ストレージスループット、サービスレイテンシーを示すものではない。
トレーニングはこの問題を明確に示している。大規模モデルでは、1台のデバイスにすべてのパラメータ、アクティベーション、オプティマイザの状態を収められないため、多数のアクセラレータに作業を分散する。
これらのアクセラレータは情報を繰り返し交換する。ネットワークが混雑すれば、プロセッサは同期を待つことになる。その場合、GPUを追加しても、トレーニング性能が比例して向上することなく、調整のオーバーヘッドだけが増える可能性がある。
推論では異なるパターンが生じる。本番サービスは、モデルの重みを読み込み、ユーザーコンテキストを処理し、補助情報を取得し、予測可能なレイテンシー目標の範囲で応答を返さなければならない。
より長いプロンプトは、進行中のリクエストの中間アテンションデータを保存するメモリ構造であるキー・バリューキャッシュへの負荷も高める。このキャッシュが利用可能な高帯域幅メモリを超えると、システムはより低速な階層を通じてデータを移動させなければならない。
検索拡張型サービスは、さらに別の経路を加える。モデルが回答を生成する前に、文書、画像、ログ、履歴、データベースレコードを検索する。ストレージや検索が遅ければ、応答時間の大半を占める可能性がある。
したがって、ボトルネックはアクセラレータから遠く離れた場所にある場合がある。アプリケーションはGPUに制約されているように見えても、実際にはデータベース、ネットワーク接続、ストレージアレイ、あるいはスケジューリングが不十分なリクエストキューを待っている可能性がある。
Metaのインフラ取り組みは、システムレベルの最適化に何が含まれるかを示している。同社による大規模training clustersの説明では、2種類のクラスタ設計それぞれに24,576基のH100 GPUが含まれる。
Metaは、それらのGPUを自己完結的なものとして提示していない。専用ネットワークファブリック、フラッシュ最適化された分散ストレージ、チェックポインティングの変更、スケジューリング作業、ソフトウェア改善を組み合わせている。
チェックポインティングは、作業を中断後に再開できるよう、モデルのトレーニング状態を保存する仕組みだ。大規模では、これらの状態の書き込みがストレージとネットワークのトラフィックを急増させる可能性がある。
Metaは、システム全体の最適化により、大規模クラスタの性能が90％を超える理想的な範囲に近づいたと報告している。この数値はMetaの環境における測定結果であり、普遍的な利用率のベンチマークではない。
それでもこの例は、購入時の課題を示している。インフラ性能は、ワークロード配置、ソフトウェア、ストレージ、トポロジー、障害対応、ハードウェアが一体となって生まれる。
クラウドプロバイダーも同様の圧力に直面している。顧客は導入済みチップではなく、成果を評価するようになっているためだ。有用な指標には、毎秒トークン数、応答レイテンシー、トレーニング完了時間、可用性、ワット当たり性能が含まれる。
高速GPUが役立つのは、システムの他の部分がその向上分を維持できる場合に限られる。そうでなければ、顧客はピーク仕様と実際に提供されるサービスの違いを高価な形で学ぶことになる。
このバランスの問題は開発者にも及ぶ。モデル設計の選択は、メモリ負荷、通信頻度、キャッシュサイズ、ストレージ需要、リクエストごとに必要なプロセッサ数に影響する。
開発者だけで施設面の制約を解決することはできない。それでも、実際のワークロードをプロファイリングすれば、次の投資先がコンピュート、メモリ容量、ネットワーク帯域幅、ストレージ、ソフトウェア最適化のどれなのかを明らかにできる。
高速GPUはメモリとインターコネクトの壁に直面する
主要な競争はもはやGPU同士ではない。ピークコンピュートと、そのコンピュートを稼働させ続けるシステム能力との競争だ。
高帯域幅メモリ、すなわちHBMは、アクセラレータの近くに配置され、従来のサーバーメモリよりはるかに高速にデータを移動させる。その帯域幅と容量は、収容可能なモデルとその実行速度を左右するようになっている。
HBM容量は、モデルとその作業データのどれだけをプロセッサ近くに保持できるかを決める。帯域幅は、計算中にアクセラレータがその情報をどれだけ速く読み出せるかを決める。
メモリ帯域幅がそれに見合って増加しなければ、より高い演算能力を持つアクセラレータでも性能が伸び悩む可能性がある。追加されたコンピュートユニットは、有用な処理を完了する代わりに待機する時間が増える。
同じ関係はプロセッサ間にも見られる。分散トレーニングでは、複数デバイス間でデータを結合または再分配する頻繁な集団通信操作が必要になる。
集団通信操作の速度は、参加するネットワークとその中で最も遅い経路に左右される。レイテンシー、混雑、トポロジー、障害コンポーネントはいずれも実効スループットを低下させうる。
Googleのアプローチは、同じ原則を示す独立した例だ。同社のTPU co-designは、アクセラレータポッドを相互接続された1台のスーパーコンピュータとして扱う。
Googleによると、Ironwood TPUはチップ当たり192 GiBのHBMと、毎秒7.4テラバイトのピークHBM帯域幅を備える。システムは、チップ間で直接データを交換するためのカスタムインターコネクトを使用する。
これらの仕様は、Googleのアーキテクチャに紐づく企業側の主張だ。すべてのGPUシステムやワークロードと中立的に比較できるものとして扱うべきではない。
見出しとなる数値より、その設計の方向性が重要だ。各層が互いを制約するため、Googleはコンピュート、メモリ、通信を同時に拡張している。
AMDも同様の道を進んでいる。同社のMI350 hardwareは、アクセラレータ性能に加え、最大288 GBのHBM3Eと最大8 TB/sの理論ピーク帯域幅を組み合わせている。
8基のアクセラレータを搭載するMI350プラットフォームは、合計2.3 TBのHBM3E容量と64 TB/sの理論上の総メモリ帯域幅に達する。AMDはデバイスをInfinity Fabricアーキテクチャで接続している。
繰り返しになるが、これらはベンダー仕様であり、アプリケーション性能の証明ではない。ソフトウェアの成熟度、通信パターン、数値フォーマット、ワークロードのチューニングが実際の結果を左右する。
重要なのは、競合するアクセラレータベンダーが、コンピュートと並んでメモリとインターコネクトの能力を訴求するようになっていることだ。AI性能が生の計算速度だけで決まるなら、それは不要なはずだ。
この仕組みはモデルのトレーニングを超えて広がる。推論システムは、重みを読み出し、キャッシュデータを維持し、リクエストをバッチ処理し、プロセッサ間に作業を分配しなければならない。
バランスの悪い推論サーバーでは、需要が高い間もアクセラレータ利用率が低くなる場合がある。GPUがメモリ、通信、前処理を待つ間、リクエストは別の場所で待機している可能性がある。
モデルがより長いコンテキストやマルチモーダル入力を扱うようになるにつれ、GPUメモリのボトルネックはより顕著になる。テキスト、音声、画像、動画は、より大きく予測しにくいデータフローを生み出す。
エージェント型アプリケーションでは、モデル呼び出し、ツール出力、検索結果、増大するコンテキスト履歴が繰り返される。そのワークロードは単一の明快な計算ではなく、依存関係を持つ一連の操作だ。
これが、hynix Newsroomがデータフローを次のインフラ課題として位置づける理由だ。高速な演算は依然として価値があるが、プロセッサへの入力とそこからの出力の経路が、どれだけの価値が維持されるかを決める。
ストレージ、電力、冷却がコンピュート性能の向上を相殺しうる
バランスの取れたサーバーであっても、ストレージや物理設備が追いつかなければ、安定したAI性能は提供できない。
ストレージは、トレーニングと推論の両方でクリティカルパスに入る。トレーニングシステムはデータセットを継続的に読み込み、定期的にチェックポイント、ログ、評価結果を書き込む。
チェックポイントは、ハードウェアまたはソフトウェアの障害後に非常に価値を持ちうる。トレーニングチームが高額な実行を最初から再開せずに済むためだ。
しかし、ストレージがトラフィックを迅速に吸収できない場合、チェックポイントのトラフィックは生産的な作業を中断させうる。プロセッサが状態データの書き込み完了を待つ間、クラスタは停止する可能性がある。
マルチモーダルモデルは、画像、音声、動画がプレーンテキストより多くのストレージと帯域幅を消費するため、さらなる負荷をもたらす。トレーニング開始前のデータ準備が、大きな作業負担になることもある。
推論サービスも、起動時やスケールイベント時にモデルの重みを取得する。必要なファイルの到着と初期化が完了するまで、新しいレプリカはトラフィックを処理できない。
検索システムは、リクエストごとにベクトルインデックス、文書、ユーザー履歴、アプリケーションデータベースへアクセスする場合がある。その場合、ストレージのレイテンシーがユーザーに見える応答時間の一部となる。
NVIDIA自身のファクトリー設計ガイドも、このシステム全体の視点を裏付けている。同ガイドは、アクセラレータ容量、高速ネットワーク、拡張可能なストレージ、電力、冷却の整備を求めている。
このガイドは、分散処理向けの低レイテンシー・ファブリックと、データセット、チェックポイント、埋め込み、モデル向けの並列ストレージを説明している。また、異なる性能要件に対応する階層型ストレージも推奨している。
この指針が主要GPUサプライヤーから示されていることは、その転換をいっそう明確にする。NVIDIAでさえ、AI導入をプロセッサ単体の購入ではなく、統合されたインフラの課題として捉えている。
電力は、システムにより厳しい上限を課す。電力会社の供給能力、配電設備、バックアップシステムが対応できなければ、データセンターは追加のアクセラレータを設置・運用できない。
冷却は、高密度ハードウェアが安全に性能を維持できるかを左右する。排出できない熱は、機器の動作速度低下、ワークロードの中断、ラック密度の制限を招き得る。
液冷は、空気だけに全面的に依存するのではなく、流体によって熱を移動させる。ラック単位の電力密度が上昇し、従来の冷却方式が現実的でなくなるにつれ、その重要性は増している。
ただし、冷却は最後に付け足せる部品ではない。施設レイアウト、水系統、排熱設備、電気設計、制御、保守手順を早期から連携させる必要がある。
ここに時間的なずれが生まれる。チップ世代は、電力会社、変電所、データホール、冷却設備の計画・建設より速く進化し得る。
そのため、運用事業者は新しいアクセラレータを利用できても、それを稼働させる適切な場所を欠く可能性がある。制約は半導体供給から、導入準備の度合いへと移る。
この主張には重要な留保が必要だ。すべての組織が、最も統合度が高く、最も高密度なAI施設を構築すべきではない。
小規模な推論サービスは、控えめなクラスタでも効率的に運用できる場合がある。ワークロードによっては、インフラ拡張よりもモデル圧縮、リクエストのバッチ処理、キャッシュ、アプリケーション変更の方が有効だ。
クラウドサービスは、顧客から多くの物理的な詳細を隠すこともできる。しかし、クラウド事業者も根本的な制約には直面しており、その影響は可用性、割り当て、性能、商取引条件を通じて顧客に伝わる。
懐疑的に問うべきなのは、システムバランスが重要かどうかではない。ベンダーが、それぞれのアーキテクチャが同等の本番ワークロードで有用な出力を改善することを証明できるかどうかだ。
ピーク帯域幅とピーク演算性能は理論上の上限にすぎない。実際のシステムでは、障害、不均一なトラフィック、通信オーバーヘッド、ソフトウェアの不具合、変化するアプリケーション要件に直面する。
したがって、購入者はワークロード単位の測定値を求めるべきだ。毎秒トークン数、学習完了までの時間、テールレイテンシー、利用率、障害復旧、タスク当たりのエネルギー消費は、より包括的な状況を示す。
メモリサプライヤーはシステム設計に近づいている
SK hynixは、ボトルネックの議論を用いて、メモリの役割を購入部品からAIインフラの共同設計要素へと拡張しようとしている。
この戦略的な利害は精査に値する。SK hynixは、主要なAIアクセラレータの近傍で使われるHBMを含むメモリを販売している。
メモリ帯域幅を強調するニュースルーム記事は、当然ながら同社の市場での立場を支える。その結論は、GPUベンダーの主張と同様の慎重さで評価されるべきだ。
それでも、この議論はNVIDIA、AMD、Google、Metaの公開設計と一致している。各社は、ますます大規模化するシステム全体でデータをより効率的に移動させる方法に投資している。
より難しい問いは責任の所在にある。従来、メモリ企業はインターフェースと性能仕様に準拠する部品を提供してきた。
システムレベルの最適化には、アクセラレータ設計者、サーバーメーカー、ネットワークベンダー、クラウドプラットフォーム、ソフトウェアチームとの早期連携が求められる。また、顧客ワークロードへの可視性も必要になる可能性がある。
SK hynixは、メモリサプライヤーがデータフローの設計支援と適切なアーキテクチャの特定を担う必要性が高まっていると述べる。これは同社の仕事をプラットフォームエンジニアリングに近づけることになる。
この変化は、すでにHBMのパッケージングに表れている。物理的な距離、接続幅、エネルギー消費がデータ移動に影響するため、先端パッケージングによってメモリスタックはプロセッサの近くに配置される。
容量も製品の実現可能性を変える。モデルがローカルHBMに収まれば、低速なメモリ層やストレージ層を経由する一部の転送を避けられる。
もっとも、HBMを増設するだけで、あらゆるGPUメモリのボトルネックが解消されるわけではない。アプリケーションは、非効率な割り当て、断片化、過剰なキャッシュ、最適でない並列化によって容量を無駄にし得る。
ソフトウェアは階層構造を理解する必要がある。どの情報を高速メモリに保持し、どれをより大きなプールへ移し、いつ転送するかを判断しなければならない。
これは、従来型のHBM製品を超えた競争を生む。キャッシュシステム、メモリプーリング、Compute Express Link、高速ソリッドステートストレージ、光接続、圧縮は、それぞれ異なる部分の課題に対応できる。
一般にCXLと呼ばれるCompute Express Linkは、プロセッサがコヒーレントアクセスでメモリを共有または拡張できるようにするインターコネクト標準だ。そのレイテンシーは、直接接続されたHBMとは異なる。
単一のメモリ階層が、速度、容量、エネルギー消費、柔軟性のすべてで最適な組み合わせを提供するわけではない。高速メモリは依然として限られ、生産コストも高いため、AIインフラは今後も階層構造を用いることになる。
結果として、連携をめぐる市場は広がる。ハードウェアサプライヤーはより緊密な統合を望み、顧客は柔軟性とベンダーロックインからの保護を求める。
高度に最適化された独自システムは、対応ワークロードで優れた性能を発揮できる。一方で、部品の代替、ソフトウェア移行、独立したベンチマークを難しくする可能性もある。
オープン標準はサプライヤーの選択肢を広げられるが、緊密に統合された設計と同等の性能を自動的に実現するわけではない。運用事業者は、統合がどこで測定可能な価値を生むかを選ぶ必要がある。
SK hynixは信頼性に関する試験にも直面している。一般的なメモリウォールの議論を、製品、リファレンス設計、再現可能なワークロード結果へと結び付けなければならない。
ニュースルームによる説明が確立するのは物語であって、証明ではない。顧客が異なるメモリ容量、インターコネクト、ストレージ経路、アクセラレータプラットフォームを比較する際には、独立ベンチマークが重要になる。
それでも同社の機会は明確だ。演算がより大きなシステムの一層となるにつれ、メモリサプライヤーはアーキテクチャ、ロードマップ、パッケージング、導入判断に対する影響力を増す。
hynixニュースルームの議論を検証する3つのシグナル
次の段階は、ピーク性能の数値をさらに大きくすることではなく、実際に提供されるワークロード性能によって評価される。
第1のシグナルは、完全なシステムを対象とする独立ベンチマークだ。テストでは、アクセラレータをメモリ、ネットワーク、ストレージ、ソフトウェア、消費電力と合わせて検証する必要がある。
有用なベンチマークは、モデルサイズ、数値形式、バッチ構成、レイテンシー目標、ハードウェアトポロジー、障害条件を開示すべきだ。こうした文脈がなければ、単一の数値が真の制約を隠しかねない。
学習結果は、理論上の演算性能だけでなく、時間当たりに完了した作業を報告すべきだ。推論テストには、最も遅いユーザー体験を捉えるスループットとテールレイテンシーを含めるべきである。
バランスの取れたシステムが一貫して高い利用率とワット当たりの出力を示せば、SK hynixの主張は支持を得る。周辺設計にかかわらず演算性能の向上が支配的であれば、この議論は弱まる。
第2のシグナルは、今後のプラットフォームが演算とデータ移動の間でどのように向上分を配分するかだ。NVIDIA、AMD、Google、カスタムチップ開発者はいずれも、より広範なインフラ機能を統合している。
新しいシステムが、演算性能と並行してHBM容量、メモリ帯域幅、スケールアップ接続、スケールアウトネットワーク、ストレージアクセス、施設効率を向上させるかを注視すべきだ。
演算性能だけをあらゆる支援層より大幅に引き上げる設計は、同じボトルネックをより大規模に再現する危険がある。バランスの取れた設計は、実際のワークロード全体で向上を示すはずだ。
第3のシグナルは、クラウドプロバイダーと企業からの運用上の証拠である。その結果は、より良いインフラがアイドル時間、失敗した実行、起動遅延、応答レイテンシーを減らすかどうかを明らかにできる。
最も有用な開示は、技術的な変更をサービス成果に結び付けるものだ。たとえば、チェックポイントからの復旧高速化、アクセラレータ利用率の向上、より予測可能な推論レイテンシーが挙げられる。
運用事業者はトレードオフも開示すべきだ。あるシステムはスループットを改善する一方で、より多くの電力を消費し、より高密度な冷却を必要とし、ソフトウェアの可搬性を制限するかもしれない。
これらのシグナルが重要なのは、インフラの課題に恒久的な解決策がないためだ。1つのボトルネックを取り除くと、それまで隠れていた別のボトルネックが現れることが多い。
より高速なストレージはネットワークへの負荷を移す可能性がある。メモリ増強は同期への要求を高め得る。高密度な演算は、サーバーが良好に動作していても施設の問題を生み出し得る。
実務上の教訓は、より高速なアクセラレータの購入をやめることではない。それらを、測定されたデータパスにおける1つの投資として扱うことだ。
開発者は、リクエストがどこで時間を費やしているかをプロファイリングすべきだ。インフラチームは、代表的なワークロードのもとで利用率、帯域幅、ストレージレイテンシー、電力、熱、障害を監視すべきである。
企業の購入者は、一般的なピーク仕様を受け入れるのではなく、自社アプリケーションでの結果を求めるべきだ。クラウド顧客は、現実的なトラフィックパターンにおける実際のレイテンシーとスループットを比較すべきである。
hynixニュースルームは、AIインフラの次の段階に向けた適切な検証基準を示した。データはどれほど効率的にプロセッサへ届き、再びそこから出ていくのか。
次のGPUを購入する前に、代表的なワークロードをストレージからメモリ、ネットワーク、アクセラレータ、応答までマッピングしてほしい。どの層が待機しており、提案されたアップグレードは実際にその待ち時間を取り除くのか。
