9月4日、Google Cloudが「Not All LLM Workloads Are Equal: Benchmarking TPU Performance on Classification vs. Generation」と題した記事を公開した。Google Cloud TPU v6e上でGemma 3の分類タスクと生成タスクを実測ベンチマークし、ワークロードの種類によってインフラ選定が大きく変わることを示した知見をまとめている。
「全LLMリクエストは同じではない」——何が違うのか
LLMの推論コストを語るとき、モデルのパラメータ数だけを見ていると判断を誤る。同じモデル・同じハードウェアでも、リクエストの構造によってシリコンへの負荷は根本的に異なる。
今回のベンチマークが対象としたのは以下の2ワークロードだ：
- 分類タスク（Classification）：ECサイトのコンプライアンス判定を想定。商品ルール・説明文・OCRテキストなど大量のコンテキストを入力し、出力は「Allow」か「Prohibit」の数トークン。入力シーケンス長（ISL）は約4,000トークン、出力（OSL）は約10トークン。Prefill（入力処理）が支配的なワークロード。
- 生成タスク（Generation）：長文ポリシーレポートの生成を想定。入力は500トークン程度だが、出力は約1,000トークンに達する。Decode（トークン生成）が支配的なワークロード。
この2種類を、Gemma 3 12BとGemma 3 27Bを使い、同時ユーザー数16・32・64・128の4段階で計測した。インフラはGKE Autopilotクラスター上のTPU v6e（2x2チップ構成）、サービングフレームワークはvLLMのTPU向け実装を使用している。
生成タスクで露わになる27Bの「性能の壁」
最も実装判断に直結する発見が、生成タスクにおけるスケーリングの分岐だ。元記事のベンチマーク結果によると、64ユーザーまでは12Bと27Bのスケーリング特性はほぼ同等だが、128ユーザーで明確に分岐する。12Bが高いスループット倍率を維持する一方、27Bは早い段階で頭打ちになる。
この「壁」はメモリ帯域幅またはコンピュート限界によるものと考えられる。Decode処理はPrefillと異なり、1トークンを生成するたびにモデル全重みへのアクセスが発生するため、パラメータ数が多いモデルほど帯域幅の消費が激しい。27Bモデルはより早い段階でTPUのメモリ帯域幅を使い切ってしまう。
推奨アクション：高並列の生成ワークロードには12Bモデルを選択するか、27Bを使う場合は1レプリカあたりの同時リクエスト数を64以下に制限してポッドオートスケーリングを設定する。
分類タスクでは27Bでも性能差がほぼ出ない
一方、分類タスクの結果は対照的だ。元記事のデータでは、12Bと27Bの両モデルが128ユーザー時点で近いスループット水準に収束し、TPUは飽和状態に達しない。
Prefill処理はバッチ並列性が高く、パラメータ数の差がスループットに直結しにくい。つまり、分類・要約のような入力重視ワークロードであれば、より高精度な27Bモデルをスループット上のペナルティなしに採用できる。
記事では、この特性をより詳しく掘り下げている。Prefill支配のワークロードではTPUのコンピュートリソースがバッチ処理に効率的に充てられるため、モデルが大きくなってもDecodeほどメモリ帯域幅が律速になりにくいと説明されている。分類タスクにおいて27Bを積極的に選択できるのは、このアーキテクチャ上の特性によるものだ。
ただし注意点もある。--max-num-seqsや--max-model-lenのパラメータを平均ユーザー負荷とトークン数に基づいて適切に設定しないと、リクエストのドロップが発生する可能性があるとされている。入力シーケンスが長い分類タスクでは、これらのパラメータの設定ミスが特に影響しやすい点に注意が必要だ。
ハードウェア飽和の「見えない」サイン
記事が強調するのは、TPUの飽和がCPU/メモリ使用率では検知できない点だ。飽和状態はレイテンシの急増とサイレントなリクエストドロップとして現れる。
対策として推奨されているのは：
- スケーリングトリガーをCPU/メモリではなくE2Eレイテンシ指標に基づいて設定する
- vLLMの
VLLM_TPU_BUCKET_PADDING_GAP（バケットパディング最適化）を積極的に活用してメモリを節約する
VLLM_TPU_BUCKET_PADDING_GAPは、TPU上でシーケンス長を離散バケットに丸める際のパディング量を制御する環境変数で、過剰なメモリ確保を抑制する効果がある。
まとめ
今回のベンチマークが示す実装上の結論はシンプルだ：
- 生成（Decode重視）ワークロード × 高並列 → 12Bモデルが有利。27Bは高並列時にスケーリングが頭打ちになる
- 分類・要約（Prefill重視）ワークロード → 27Bでも性能差なし。精度優先で選べる
- スケーリング監視はレイテンシベースで。CPU/メモリトリガーは信頼できない
モデルサイズだけでなく「どんなリクエストを捌くか」を起点にインフラを設計する必要性を、実測データで裏付けた内容だ。
詳細はNot All LLM Workloads Are Equal: Benchmarking TPU Performance on Classification vs. Generationを参照していただきたい。
