LLM ワークロードはすべて同じではない: 分類と生成における TPU のパフォーマンス ベンチマーク

※この投稿は米国時間 2026 年 9 月 5 日に、Google Cloud blog に投稿されたものの抄訳です。

大規模言語モデル（LLM）を試験運用版のプロトタイプからエンタープライズ規模の本番環境に移行すると、インフラストラクチャがパフォーマンスの上限とユニット エコノミクスの両方を左右するという重要な事実が明らかになります。多くの標準的なハードウェア ベンチマークでは、すべての LLM リクエストが同じようにシリコンに負荷をかけるわけではないという基本的な現実が見過ごされています。

この投稿では、Google Cloud TPU v6e 上で Gemma 3 12B と Gemma 3 27B を比較する包括的なベンチマーク テストについて詳しく見ていくことで、「構造的に異なるワークロードを大規模に処理する場合、TPU インフラストラクチャの実際のパフォーマンスはどうなるのか？」というアーキテクチャに関する重要な問題を考えます。

主な結果と提案

ベンチマークの手法を詳しく説明する前に、TPU v6e で Gemma 3 をデプロイするアーキテクトにとって重要なポイントを以下に示します。

生成タスクにおけるパフォーマンスの壁

デコード負荷が高い生成タスクでは、Gemma 3 27B モデルは同時ユーザー数が 64 人を超えるとパフォーマンスの限界に達し、128 人では正規化スループット係数が 4.12 倍で頭打ちになります。一方、12B モデルは最大 8.19 倍までスケールアップします。

提案: 多くの生成を同時実行するワークロードの場合は、12B モデルに縮小するか、27B モデルでレプリカあたりの同時リクエスト数を 64 に制限する厳格な Pod 自動スケーリング制限を設定します。

分類タスクでは互角

プリフィル負荷が高い分類タスクでは、モデルのパラメータ サイズの影響が大きく下がります。12B モデルと 27B モデルはどちらも、TPU を飽和させることなく、同様のピーク スケーリング（ユーザー 128 人で正規化スループットが約 6.0 ～ 6.4 倍）を達成しています。

提案: 要約や分類のワークフローでは、スループットを低下させることなく、より大規模で高性能なモデルを安全にデプロイできます。平均の --max-num-seqs や --max-model-len は、平均ユーザー負荷とリクエストあたりの平均トークン数に基づいて慎重に維持する必要があります。そうしないと、リクエストのドロップが発生する可能性があります。

壁を回避するための設計

ハードウェアの飽和は、深刻なレイテンシの急増と、リクエストのサイレント ドロップアウトとして現れます。これを軽減するには、標準の CPU / メモリ スケーリング トリガーに依存しないようにします。代わりに、エンドツーエンド（E2E）レイテンシ指標に基づいてスケールし、積極的な vLLM バケット パディング最適化（VLLM_TPU_BUCKET_PADDING_GAP）を実装してメモリを節約します。

アーキテクチャの構成

推論スタックは、次の 3 つの主な要素に分けることができます。

1. インフラストラクチャ: GKE と TPU

今回のデプロイメントの基盤となったのは、Google Kubernetes Engine（GKE）Autopilot クラスタです。これに、2×2 チップ トポロジで構成された単一ホストの TPU v6e ノードプールを接続しました。

2. ソフトウェアとツール: vllm

サービング フレームワークには、vllm-project/tpu-inference を介して vLLM を活用しました。

3. モデル: Gemma 3 12B、27B

今回は、Gemma 3 12B と Gemma 3 27B という 2 つの高性能なオープン ウェイト モデルを評価しました。これらのモデルには HuggingFace 経由でアクセスしました。

ワークロード: 分類と生成

すべての LLM リクエストがシステムに同じ負荷をかけるわけではありません。今回は、分類と生成という 2 つの異なるシナリオで、同時ユーザー数が 16 人、32 人、64 人、128 人の場合のベンチマークを実施しました。

• 分類（高入力、低出力）: このユースケースは、e コマースのコンプライアンス タスクを模倣するものです。プロンプトには、商品ルール、アイテムの説明、OCR で抽出されたテキストの大きなブロックが含まれています。出力は非常に小さく、通常はアイテムを「許可」または「禁止」に分類するだけです。入力シーケンス長（ISL）は約 4,000 トークン、出力シーケンス長（OSL）は約 10 トークンです。

• 生成（低 / 中入力、高出力）: このユースケースは、長文テキストの生成を模倣するものです。プロンプトでは、労働市場における AI の未来に関する詳細な分析的政策提言書を求めます。モデルは、ほとんどの時間を数百のトークンのデコードとストリーミングに費やします。入力シーケンス長（ISL）は 500 トークン、出力シーケンス長（OSL）は約 1,000 トークンです。

結果と考察

スループット（リクエスト数/秒）、エンドツーエンドのレイテンシなどの指標を測定した結果、パラメータ サイズとハードウェア帯域幅の相互作用について興味深い知見が得られました。アーキテクチャの整合性を確保するため、ベンチマークはすべて vllm-project/tpu-inference ハードウェア プラグインを使用して実行され、max-model-len=128000、max-num-batched-tokens=8192、max-num-seqs=512 という標準的なグローバル サービング構成が利用されました。

生成タスクにおけるスケーリングの相違

生成タスクでは、同時ユーザー数が 64 人まで、両モデルのパフォーマンスは同等です。しかし、同時ユーザー数が 128 人になると、Gemma 3 12B モデルのほうが大幅にスケーリングに優れ、正規化スループット係数が 8.19 倍に達します。一方、Gemma 3 27B モデルは 4.12 倍で頭打ちになります（ユーザー数 16 人での Gemma 3 12B のベースラインに対する正規化）。これは、生成負荷が高い状況では、より大規模な 27B モデルのほうが大幅に早くメモリまたはコンピュートの上限に達することを示唆しています。