「GPUが余っている。だが遅い」はなぜ起こる？ Googleが検証、AI推論の負荷分散：3地域、1万7000ノードで検証

生成AIの推論処理では、GPUなどの計算資源を効率よく活用することが課題となる。Googleは、従来の負荷分散方式の限界に着目し、複数地域に分散したGPUなどを有効活用する技術を1万7000ノード規模で検証した。

[＠IT]

　生成AIの普及によって「GPU」などの計算資源に対する需要が高まる一方、必要な計算資源を単一のデータセンターで確保することは難しくなっている。結果として、企業は複数のデータセンターや地域に分散した計算資源を利用する必要がある。

　しかし、計算資源を分散配置するだけでは、その能力を十分に引き出せるとは限らない。ある地域ではGPUが十分に使われていない一方、別の地域ではリクエストが集中し、処理待ちが発生することがある。

　こうした中、Googleは2026年9月21日（米国時間）、生成AIの推論処理に使用するGPUや「TPU」などの計算資源を効率的に活用するため、複数地域に分散したクラスタ間でリクエストを振り分ける技術の検証結果を公開した。

なぜGPUを十分に活用できていないのか

　Googleは、GPUなどの計算資源を十分に活用できない要因の一つとして、従来の負荷分散方式が生成AIの推論処理に適していない点を挙げている。従来の方式では、なぜGPUの能力を十分に引き出せないのか。

　一般的な負荷分散方式の一つに、複数のサーバにリクエストを順番に振り分ける「ラウンドロビン方式」がある。この方式はリクエストを均等に分散できる一方、それぞれのリクエストがサーバに与える負荷の違いまでは考慮しない。

　生成AIの推論処理では、この違いが問題になる。

　例えば、大量のテキストを入力するリクエストはGPUの演算能力に大きな負荷をかける。一方、長い文章を生成するリクエストはメモリ帯域幅を圧迫する。また、長い会話履歴を扱う場合には、GPUのメモリ容量が不足し、新たなリクエストを受け付けられなくなることもある。

　つまり、同じ1件のリクエストでも、必要な計算資源は大きく異なる。単純にリクエスト数を均等に振り分けても、GPUの負荷が均等になるとは限らない。

　特に、長時間動作し、大量のコンテキストを扱うAIエージェントでは、GPUの演算能力よりも先にメモリが制約になる場合がある。

　Google Cloudは、従来のラウンドロビン方式ではGPUのメモリ使用状況や演算負荷を把握できず、高価なGPUの処理能力を無駄にする可能性があると説明している。

GPUメモリの使用状況を基にリクエストを振り分ける

　この課題に対応するため、Google Cloudが利用したのが「multi-cluster GKE Inference Gateway」だ。コンテナ管理サービス「Google Kubernetes Engine」（GKE）上で、複数のクラスタにまたがるAI推論処理のリクエストを振り分ける仕組みだ。

　今回の構成では、複数地域のクラスタを単一の接続先として扱い、リクエストを受け付ける。利用者は個々のクラスタの所在地を意識する必要がない。

　特徴は、単にリクエストを順番に振り分けるのではなく、各クラスタの実際の負荷を基に振り分け先を決める点にある。

　具体的には、AI推論エンジンが出力する「KVキャッシュ」の使用状況を利用する。KVキャッシュは、大規模言語モデル（LLM）が文章を生成する際に、過去のトークンに関する計算結果を保持し、同じ計算を繰り返さずに済むようにする仕組みだ。

　このキャッシュはGPUのメモリを消費するため、使用状況を把握することで、推論処理に伴うメモリ負荷を判断できる。

　今回の検証では、クラスタのKVキャッシュ使用率が40％のしきい値を超えると、ゲートウェイが別の正常な地域のクラスタへリクエストを自動的に振り分けるようにした。

　これにより、特定の地域に負荷が集中しても、別の地域にある計算資源を利用して処理を継続できる。なお、振り分けの判断にはKVキャッシュ以外にも、処理待ちのリクエスト数や同時実行数などの指標を利用できるという。

1万7000ノードの検証、処理性能は計算資源の増加にほぼ比例

　Googleはこの仕組みの有効性を確かめるため、米国東部、米国西部、欧州の3地域にまたがるGKEクラスタを使用し、計1万7000ノード規模の環境で検証を実施した。

　検証には、複数の専門的なニューラルネットワークを組み合わせる「Mixture of Experts」（MoE）方式の基盤モデルと、LLM推論エンジン「SGLang」を使用した。

　検証では、クラスタ数を1つから3つに増やした場合のリクエスト処理性能を測定した。結果は次の通りだ。

クラスタ数	リクエスト処理性能	トークン処理性能	成功率
1	0.72件／秒	2898トークン／秒	99.87％
2	1.40件／秒	6380トークン／秒	99.95％
3	2.10件／秒	8457トークン／秒	99.90％

　クラスタ数を1つから3つに増やした結果、リクエスト処理性能は約2.9倍となった。Googleは、計算資源の増加にほぼ比例して処理性能を拡張できたとしている。

　また、ゲートウェイを経由してリクエストを処理した場合のスループットは、単一のローカルクラスタに直接リクエストを送信した場合の99.5％だった。複数地域への振り分け機構を追加したことによる処理性能の低下は1％未満にとどまった。

AI推論では「リクエスト数」だけでは負荷を判断できない

　Googleは今回の検証を踏まえ、AI推論基盤の設計では、従来のWebアプリケーション向けの負荷分散方式をそのまま適用することには限界があると指摘している。

　一般的なWebアプリケーションでは短時間で完了するリクエストが多い一方、LLMの推論処理では1件のリクエストが数分間続くこともある。そのため、負荷分散装置の接続数制限やタイムアウト設定についても、AI推論に合わせた設計が必要になる。

　また、AIエージェントのように大量のコンテキストを扱う処理では、GPUの演算能力だけでなく、メモリの使用状況を把握することが重要になる。

　今回の検証は、複数の地域に分散したGPUなどの計算資源を有効活用するには、リクエスト数だけでなく、GPUの負荷を考慮した振り分けが重要になることを示している。