LLMの本番推論では、開発しやすさとスループットの両立が長年の課題でした。GoogleとAnyscaleは2026年6月、Google Kubernetes Engine（GKE）上のRay Serve LLMに最大5倍のスループットと8倍の低遅延を実現するアップデートを発表しました。
この記事では、何が変わったのか、性能改善の仕組み、ベンチマーク結果、有効化の手順までを整理します。
この記事でわかること
- Ray Serve LLMの3つの主要なアーキテクチャ改善
- GKE上でのベンチマーク結果とvLLMとの比較
- 高スループットモードを有効にする環境変数と前提バージョン
何が変わったか
Google CloudとAnyscaleの共同開発により、Ray Serve LLMの分散推論性能が大幅に向上しました。公式発表では、従来構成と比べてスループット最大5倍、レイテンシ最大8倍の改善が示されています。
Ray ServeはAnyscaleが開発したPythonネイティブのモデル配信ライブラリです。GKEと組み合わせると、開発から本番運用まで一貫したLLM推論基盤を構築できます。今回の更新で、柔軟な機能セットを維持したまま、本番レベルの性能要件を満たせるようになりました。
背景：柔軟性がもたらす性能コスト
Ray Serveはモデル合成やマルチモデル配信など、LLMサービス構築に便利な機能を備えています。一方で、高負荷時には内部ルーティングがボトルネックになり、スループットが頭打ちになる問題がありました。
Anyscaleの技術ブログでも、レイテンシに敏感なワークロードではスケール時に性能が頭打ちになるケースが報告されています。デフォルトのRay Serve ProxyはPython製で、高並行時にプロセスが飽和し、レプリカを増やしてもスループットが伸びにくい構造でした。
今回の改善は、このプロキシ層とレプリカ間通信の両方を見直すことで、分散推論のボトルネックを取り除くものです。
3つのアーキテクチャ改善
Google Cloudブログで紹介された主要な最適化は次の3点です。
HAProxy統合
Ray ServeにHAProxyを組み込み、内部リクエストのルーティングと負荷分散を担わせます。HAProxyはC言語製の高性能ロードバランサーで、Pythonランタイムの飽和を防ぎます。Anyscaleのベンチマークでは、HAProxy有効化だけでユニタリ（単一応答）ワークロードのスループットが約2倍、ストリーミングでは約1.4倍の改善が報告されています。
ダイレクトトークンストリーミング
初期リクエスト経路と返却ストリームを分離する設計です。トークンはモデルレプリカから直接プロキシへ流れ、ストリーミングデータ経路ではイングレスルーターを迂回します。これにより、トークン生成からクライアントへの返却までの遅延が短縮されます。
v2 Rayエグゼキュータ（vLLM向け）
vLLM向けのRayバックエンドを刷新し、Rayをデータプレーンから切り離して非同期スケジューリングを有効にしました。ネイティブvLLMエグゼキュータと同等のコードパスに近づけ、エンジンレベルの最適化をRayユーザーにも届けます。
加えて、レプリカ間通信をRay CoreのActor RPCから直接gRPCに切り替える最適化も含まれます。小さなペイロード（100KB未満）の通信では、オブジェクトストアを経由しないポイントツーポイント通信でオーバーヘッドを削減します。
GKE上のベンチマーク結果
GoogleとAnyscaleは、次世代AIハードウェアを搭載したGKEクラスタで性能検証を行いました。テスト環境はGoogle Cloud A4 VM（NVIDIA HGX B200搭載）です。モデルにはオーケストレーションとルーティングのボトルネックを切り分けやすい小型モデルのGemma 4 E2Bを採用しました。
8レプリカ構成では、改善後のRay Serve LLMが従来構成を大きく上回るスケーリングパターンを示しました。同時接続ユーザー数が増えても、99パーセンタイルのtime-to-first-token（最初のトークン到達時間）を低く保ちながらスループットを伸ばせます。以前は同時接続が増えるとスループット維持が難しかった領域です。
比較対象には、Rayエグゼキュータを使った素のvLLM構成も含まれています。改善後のRay Serve LLMはネイティブvLLMに匹敵する性能を示しつつ、Rayのエコシステムと機能拡張性を維持できると報告されています。
Anyscaleの別ベンチマークでは、単一H100 GPU上でopenai/gpt-oss-20bをTP1で配信するケースでも、HAProxy有効化によりレプリカ数に応じたリニアなスループットスケールが確認されています。
有効化の手順と前提条件
高スループットモードはRay 2.55以降で利用できます。Google CloudブログではRay 2.56以降の利用を推奨しています。KubeRayでGKEにデプロイする場合、RayServiceのheadとworkerの両方に次の環境変数を設定します。
RAY_SERVE_ENABLE_HA_PROXY=1— HAProxyによるイングレスを有効化RAY_SERVE_THROUGHPUT_OPTIMIZED=1— gRPCデータプレーン通信など複数の最適化を一括有効化
レプリカ間のgRPC通信を個別に制御する場合は RAY_SERVE_USE_GRPC_BY_DEFAULT=1 も設定します。詳細はRay公式のパフォーマンスチューニングドキュメントに記載されています。
これらの最適化は、レプリカあたり秒間50リクエスト以上、レプリカあたり同時接続250以上、バーストトラフィックがある高負荷環境で特に効果が大きくなります。レプリカ数が多いほど、2.55以前との性能差も広がります。
GKEが担う役割
ソフトウェア最適化だけでは、ハードウェアのオーケストレーションが追いつきません。GKEのRay Operatorアドオンを使うと、Google CloudのAIアクセラレータ上への展開、水平スケーリング、モニタリング、マルチクラスタスケーリング、障害耐性がまとめて利用できます。
GKEは物理ハードウェアの分散管理を抽象化し、チームはモデル改良とアプリケーションロジックに集中できます。今回のRay Serve改善は、このインフラ層と組み合わさることで本番環境での効果が最大化されます。
実務への示唆
LLM推論基盤の選定では、「開発のしやすさ」と「本番性能」のトレードオフが論点になりがちです。今回のアップデートは、Ray Serve LLMがそのトレードオフを大きく縮小したことを示しています。GKE上で既にRayを使っているチームは、Ray 2.56への更新と環境変数の設定を検討する価値があります。
新規構築の場合も、KubeRayとGKE Inference Gatewayを組み合わせたマルチクラスタ配信や、GemmaモデルのRay Serve配信ガイドなど、Google Cloudが公開している関連ドキュメントが出発点になります。分散推論の性能ボトルネックに悩んでいるなら、まずHAProxyとgRPC最適化の有効化から試すのが現実的です。