Back to Archive

GCP News - 2026-09-14

2026-09-14
最終更新: 2026-09-15 02:44:20 JST

AI による概要

3 記事

この日はリリースノート 1 件と、Google Cloud 日本語ブログの抄訳 2 本でした。リリースノートでは、Filestore インスタンスのリストアジョブを Google Cloud コンソールの Backup and DR の Jobs ページから直接監視できるようになりました。Filestore インスタンスでリストアを実行すると、Backup and DR がジョブの進捗とステータスを自動的に追跡します。日本語ブログの抄訳 2 本はいずれも 9 月 5 日 (米国時間) の記事の翻訳で、1 本は TPU v6e 上での Gemma 3 12B / 27B のベンチマークです。デコード負荷の高い生成タスクでは 27B が同時 64 ユーザーを超えると頭打ちになり 128 ユーザーで正規化スループットが 4.12 倍にとどまる一方、12B は 8.19 倍までスケールすること、プリフィル負荷の高い分類タスクではパラメータサイズの影響が小さく 12B・27B とも 128 ユーザーで約 6.0〜6.4 倍の同等のスケーリングに達することを報告しています。対策として、CPU / メモリではなくエンドツーエンド (E2E) レイテンシ指標に基づくスケーリングや、vLLM のバケットパディング最適化 (VLLM_TPU_BUCKET_PADDING_GAP) が推奨されています。もう 1 本は、Google の財務エンジニアリングチームがレガシーデータ層を Spanner へ移行した事例の抄訳で、ヘッドレスモードの Antigravity CLI による自動リファクタリングパイプラインを使い、過去データのバックフィル・二重書き込み / 二重読み取りの実装・自動化された API 検証とパリティチェックという 3 フェーズで、数十の DAO にまたがる移行をサービス停止なしに進めた内容です。

主要トピック

  • 運用: Filestore インスタンスのリストアジョブを Backup and DR の Jobs ページから直接監視可能に

  • 抄訳: TPU v6e 上の Gemma 3 12B / 27B ベンチマーク、生成タスクは 27B が同時 64 ユーザー超で頭打ち、分類タスクは同等にスケール

  • 抄訳: Spanner 移行事例、Antigravity CLI ヘッドレスモードで数十 DAO の二重書き込みを自動化しサービス停止なしで移行

AI (Claude Opus 5) が生成 · 2026-09-15 22:04:00 JST

Google Cloud Release Notes

September 14, 2026

Backup and DR

Feature

You can now monitor restore jobs for Filestore instances directly from the Backup and DR Jobs page in the Google Cloud console. When you trigger a restore on a Filestore instance, Backup and DR automatically tracks the job progress and status.

For more information, see Restore a Filestore instance from a backup vault and Monitor backup and restore jobs in Google Cloud console.

Google Cloud Japan Blog

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 モデルのほうが大幅に早くメモリまたはコンピュートの上限に達することを示唆しています。

同時ユーザー数 Gemma 3 12B のスループット（リクエスト数/秒） Gemma 3 27B のスループット（リクエスト数/秒）
16 人 1.00 倍 1.05 倍
32 人 1.98 倍 1.97 倍
64 人 2.96 倍 4.00 倍
128 人 8.19 倍 4.12 倍 
<div class="article-module h-c-page">
  <div class="h-c-grid">


<figure class="article-image--large
  
  
    h-c-grid__col
    h-c-grid__col--6 h-c-grid__col--offset-3
    
    
  ">

  
  
    
    <img alt="generation_scaling" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/generation_scaling.max-1000x1000.jpg" />
    
    </a>
  
</figure>


  </div>
</div>
aside_block
<ListValue: [StructValue([('title', '上級者向けのヒント → 同時実行数が多い場合の指標のインフレ'), ('body', <wagtail.rich_text.RichText object at 0x7ff01ca016a0>), ('btn_text', ''), ('href', ''), ('image', None)])]>

分類タスクにおけるパフォーマンスは互角

分類タスクでは、Gemma 3 12B モデルと Gemma 3 27B モデルのスケーリング動作にほとんど差はありません。どちらのモデルもハードウェアの容量内で効率的に動作し、スケーラビリティに優れています。同時ユーザー数が 128 人の場合、正規化スループットのピークは約 6.04～6.37 倍に達します（ユーザー数 16 人での Gemma 3 12B のベースラインに対する正規化）。

同時ユーザー数 Gemma 3 12B のスループット（リクエスト数/秒） Gemma 3 27B のスループット（リクエスト数/秒）
16 人 1.00 倍 0.76 倍
32 人 1.18 倍 1.53 倍
64 人 2.04 倍 3.15 倍
128 人 6.37 倍 6.04 倍 
<div class="article-module h-c-page">
  <div class="h-c-grid">


<figure class="article-image--large
  
  
    h-c-grid__col
    h-c-grid__col--6 h-c-grid__col--offset-3
    
    
  ">

  
  
    
    <img alt="classification_perf_table_image2" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/classification_perf_table_image2.max-1000x1000.png" />
    
    </a>
  
</figure>


  </div>
</div>

レイテンシしきい値の分析

エンドツーエンド（E2E）のレイテンシは、モデルのサイズとタスクによって異なるスケーリング動作を示します。同一のサービング ハイパーパラメータ（--max-num-seqs=512）を使用した場合、Gemma 3 12B モデルにおける分類タスクのレイテンシは、ユーザー数が 32 人から 64 人に増えると約 2 倍になり、リソースの競合が発生していることを示します。これに対して、より大規模な Gemma 3 27B モデルでは、分類タスクのレイテンシはユーザー 32 人から 64 人の間で比較的横ばいであり、ユーザー 128 人で 2 倍になります。

モデル タスク 16 人 32 人 64 人 128 人
Gemma 3 12B 生成 1.00倍 1.13倍 1.40倍 1.70倍
Gemma 3 12B 分類 1.00倍 0.99倍 1.79倍 2.90倍
Gemma 3 27B 生成 1.20倍 1.68倍 2.93倍 3.33倍
Gemma 3 27B 分類 1.20倍 1.95倍 1.95倍 3.88倍 
<div class="article-module h-c-page">
  <div class="h-c-grid">


<figure class="article-image--large
  
  
    h-c-grid__col
    h-c-grid__col--6 h-c-grid__col--offset-3
    
    
  ">

  
  
    
    <img alt="latency threshold_image3" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/latency_threshold_image3.max-1000x1000.png" />
    
    </a>
  
</figure>


  </div>
</div>
aside_block
<ListValue: [StructValue([('title', '重要な TPU 最適化手法'), ('body', <wagtail.rich_text.RichText object at 0x7ff01ca01d30>), ('btn_text', ''), ('href', ''), ('image', None)])]>

まとめ

Google Cloud TPU v6e アーキテクチャで Gemma 3 12B モデルと 27B モデルのベンチマークを実施した結果、推論パフォーマンスの予測因子は、生のパラメータ数だけではないことがわかりました。むしろ、サービング フレームワーク、ハードウェア トポロジ、ワークロード トークン比率の相互作用が効率を左右します。生成タスク（低入力、高出力）では、同時実行数が多い場合、12B モデルのほうが優れていることが実証されました。12B モデルは 8.19 倍の相対スループット係数を維持する一方、27B モデルは 4.12 倍で飽和しました。これに対して、プリフィル負荷が高い分類タスクでは、両モデルのパフォーマンスが同等であるため、組織はスケーリングを大幅に損なうことなく、より大規模なモデルをデプロイできます。今回の評価では、ハードウェアの飽和しきい値を正確にマッピングしました。たとえば、分類ではユーザー 64 人でエンドツーエンドのレイテンシが 2 倍になり、生成ではユーザー 128 人で急激に増加します。この結果をもとに、コストをかけてオーバープロビジョニングを行うのではなく、データドリブンな自動スケーリング トリガーを正確に設定できます。最終的に、これらのピーク指標を達成するには、vLLM のパラメータを積極的にチューニングする必要があります。たとえば、バッチ処理を行うトークンの調整や、TPU 固有のバケット パディングの構成によって、コンピュートの無駄を防ぎます。これは、AI インフラストラクチャの費用対効果を高めるためには、本番環境ワークロード固有の入出力プロファイルにモデルの選択とサービング構成を厳密に合わせる必要があることを実証しています。

LLM ワークロードをスケールするために

最適化されていないインフラストラクチャが、エンタープライズ AI の展開のボトルネックにならないようにしましょう。さまざまなワークロードの形状がハードウェアの飽和にどのように影響するかを理解したところで、これらの知見を実践に活かしましょう。

  • 今回のベンチマークを使用して本番環境アーキテクチャのサイズを適正化します。プリフィル負荷が高い分類タスクには、スループットを低下させることなく、より大規模な Gemma 3 27B を安全に活用できます。一方、デコード負荷が高い生成タスクを高い同時実行数で処理する場合は、線形スケーリングを維持するために 12B モデルへの切り替えを検討してください。

  • TPU v6e ノードプールを備えた Google Kubernetes Engine（GKE）を使用してデプロイし、スケーラビリティに優れたマネージド AI 基盤と専用の vllm-project/tpu-inference ハードウェア プラグインを構築します。また、Gemini Enterprise Agent Platform の Model Garden を介してデプロイすることも、Gemma 3 モデルのサービング用に TPU VM をスピンアップすることもできます。

本番環境へのデプロイで、同様のパフォーマンスの壁にぶつかったことはありませんか？Google Cloud コミュニティ フォーラムで、スケーリング戦略を共有し、質問を投稿し、ディスカッションに参加してください。

- AI エンジニア Rupjit Chakraborty

Spanner への移行: Antigravity CLI で二重書き込みを自動化してサービス停止を最小限に

詳細を表示

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

Google のファイナンス エンジニアリング チームは、レガシー データレイヤーをモダナイズする必要が生じた際、グローバルに分散され、強整合性があり、高可用性機能を備えたマルチモデル データベースである Spanner を選択しました。しかし、本番環境サービスをオフラインにせずに Spanner に移行することは、エンジニアリング上の大きな課題でした。アプリケーションを担当する社内チームとして、数十のデータアクセス オブジェクト（DAO）にわたって二重書き込みロジックを手動で書き換える必要がありましたが、このプロセスは時間がかかり、人的エラーが発生しやすいものでした。さらに、サービスを停止することなくこれを行うには、コードベース内のすべての DAO にわたって、マルチフェーズの二重書き込みアーキテクチャを実装する必要がありました。

この課題を解決するために、別のアプローチを採用しました。ヘッドレス モードの Antigravity CLI を利用した自動リファクタリング パイプラインを構築したのです。これにより、本番環境の準備を進めるなか、ステージング環境で厳格なデータパリティを維持しながら、移行速度を大幅に向上させることができました。

課題: 二重書き込みによる移行の仕組み

財務上の正確性が不可欠な高スループットの本番環境サービスを移行する場合、単純なカットオーバー スクリプトは機能しません。過去のデータのバックフィルと検証がすべて完了するまで、レガシー データストアと Spanner の両方が同じ書き込みを同時に受信することを確認する必要があります。

移行は、次の 3 つのフェーズに分けて実施しました。

  • 過去のデータのバックフィル: 参照整合性を維持しながら、既存の過去のレコードを Spanner にコピーします。

  • 二重書き込み / 二重読み取りの実装: 移行期間中に、すべての DAO を変更して、プライマリ ストアと Cloud Spanner の両方にミューテーションを並行して書き込みます。

  • 自動化された API 検証とパリティ チェック: RPC トラフィックをインターセプトし、すべての書き込みが両方のストアでバイト単位で同等に完了することをエンドツーエンドで検証します。

<div class="article-module h-c-page">
  <div class="h-c-grid">


<figure class="article-image--large
  
  
    h-c-grid__col
    h-c-grid__col--6 h-c-grid__col--offset-3
    
    
  ">

  
  
    
    <img alt="1 - Dual Write Architecture" src="https://storage.googleapis.com/gweb-cloudblog-publish/images/1_-_Dual_Write_Architecture.max-1000x1000.png" />
    
    </a>
  
</figure>


  </div>
</div>

アーキテクチャ パターンはクリーンですが、Google の規模では、摩擦が生じ始めました。これは、各 DAO に以下が必要なためです。

  • 複雑なドメインモデルを Spanner スキーマ列にマッピングする専用の MutationConverter クラス

  • 二重書き込みブランチの処理とロールバックまたはエラー報告のロジック

  • 疑似時間ソースとテストダブル（FakeTimeSource）を使用して、プライマリと Spanner の両方の書き込みを検証する単体テストのスイート

30 以上の DAO にわたって、同一の高精度なコード変更を手作業で行っていたら、エンジニアリングに数か月を要していたでしょう。

解決策: 標準化されたミューテーション コンバータ パターン

自動化パイプラインがクリーンなコードを確実に生成できることを検証するために、まず、分離された MutationConverter インターフェースを中心に DAO リファクタリング パターンを標準化しました。

中核的な DAO ビジネス ロジック内に未加工の Spanner テーブル名と列割り当てを直接埋め込むのではなく、Spanner スキーマ変換を専用のコンバータ ユニットに分離します。

code_block
<ListValue: [StructValue([('code', '// Example of the standardized pattern generated by our pipeline\r\n\r\ntype BpcTransferAmountsMutationConverter interface {\r\n ToInsertMutation(entity *model.BpcTransferAmount) (*spanner.Mutation, error)\r\n ToUpdateMutation(entity *model.BpcTransferAmount) (*spanner.Mutation, error)\r\n}\r\n\r\ntype bpcTransferAmountsMutationConverterImpl struct {\r\n tableName string\r\n}\r\n\r\nfunc (c *bpcTransferAmountsMutationConverterImpl) ToInsertMutation(entity *model.BpcTransferAmount) (*spanner.Mutation, error) {\r\n if entity == nil {\r\n return nil, errors.New("entity cannot be nil")\r\n }\r\n \r\n // Map domain fields to Cloud Spanner table schema\r\n cols := []string{"TransferId", "AmountCents", "CurrencyCode", "LastModifiedTimestamp"}\r\n vals := []interface{}{\r\n entity.TransferId,\r\n entity.AmountCents,\r\n entity.CurrencyCode,\r\n spanner.CommitTimestamp, // Use Spanner commit timestamps\r\n }\r\n \r\n return spanner.Insert(c.tableName, cols, vals), nil\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff00ee32f70>)])]>

DAO と Spanner SDK（spanner.Mutation）の間に厳格で決定論的なコントラクトを確立することで、AI コーディング エージェントが推論して確実に生成できる正確なターゲット仕様を作成しました。

Antigravity CLI をヘッドレス モードで使用する理由

IDE のインタラクティブな AI チャット インターフェースは、探索的なコーディングには適していますが、コードベース全体にわたる体系的な複数ファイルのコード更新には適していません。エッジケースを見逃さずに、数十のターゲットに繰り返し可能なリファクタリングを適用する必要がある場合は、自動化されたワークフローが必要です。

この問題に対処するため、Antigravity CLI をヘッドレス モード（-p）で実行するオーケストレーション スクリプト（migration_ui.py）を構築しました。

ヘッドレス モードでは、ターミナルのプロンプトに手動で応答しなくても、シェル スクリプト、継続的インテグレーション パイプライン、バックグラウンド自動化ジョブ内で Antigravity を直接実行できます。このアプローチにより、主に 3 つの方法で作業を効率化できました。

  • 決定論的なプロンプト アーキテクチャ: プロンプトをバージョン管理されたエンジニアリング アーティファクトとして扱いました。タイムスタンプのシリアル化、null 可能性の変換、ミューテーションの曖昧さ、FakeTimeSource テスト インジェクションなど、Spanner の一般的なエッジケースを処理する正確なルールを、再利用可能なプロンプト テンプレートに直接コード化しました。

  • バッチ実行と自動検証: オーケストレーション スクリプトが、ターゲット DAO 名を入力として使用し、既存の単一書き込みソースコードとスキーマを取得して、構造規則とともにヘッドレス Antigravity にフィードします。Antigravity は、新しいコンバータ、リファクタリングされた二重書き込み DAO、対応する単体テストを生成します。その後、スクリプトは blaze test を実行します。linter エラーやテスト アサーションの失敗が発生すると、エラーログが Antigravity に直接フィードバックされ、自己修正が行われます。

  • 夜間に大規模に実行: ループは無人で実行されるため、エンジニアは 1 日の終わりに 10 個の DAO をキューに入れることができます。朝までに、パイプラインは人間によるコードレビューの準備が整った 10 個のクリーンな変更リストを生成、テスト、検証します。

クラウド エンジニアにとっての成果と重要なポイント

Spanner の分散データベース プリミティブと Antigravity CLI のヘッドレス自動化を組み合わせることで、エンジニアリング組織全体に明確なメリットがもたらされました。

  • 移行作業の大幅な削減: 二重書き込みによる DAO の移行は、以前は広範な手動コーディングとテストが必要でしたが、わずかな時間で完了し、確認されました。

  • 信頼性の高いデータ移行: 生成されたすべての DAO が、テスト済みのまったく同じ MutationConverter パターンに準拠し、Spanner テストダブルに対する自動単体テストを受けたため、広範な移行テスト中も高いデータ忠実度を維持できました。

  • より価値の高いエンジニアリングに集中: エンジニアは、繰り返しのボイラープレート リファクタリングを回避し、データ モデリング、アーキテクチャの復元力、パフォーマンスの最適化に集中する時間を確保できました。

次回のデータベース移行に役立つ 3 つのヒント

  1. まずスキーマ変換を分離する: 移行スクリプトを記述する前に、新しいクラウド データベース SDK の要件を既存のビジネス ロジックから分離する厳密なインターフェース（MutationConverter など）を定義します。AI エージェントは、明確で限定された設計パターンを与えられた場合に、最も効果的に機能します。

  2. インタラクティブなチャットからヘッドレス自動化に移行する: 3～4 個以上のファイルにわたって繰り返しリファクタリングを実行する場合は、スクリプト化されたヘッドレス ワークフローにリソースを投入します。プロンプト入力とテスト検証を自動化されたビルドステップとして扱うことで、品質と一貫性を維持できます。

  3. ビルドシステムをガードレールとして機能させる: AI 生成ループをビルドおよびテストハーネス（bazel test または go test）に直接接続します。これにより、デベロッパーがコードを確認する前に、モデルがコンパイル エラーとアサーション エラーを修正できます。

使ってみる

金融システムの移行でも、クラウドネイティブ アプリケーションのゼロからの構築でも、Spanner と Antigravity はスケーラブルなソフトウェア開発の基盤となります。

  • Cloud Spanner を確認する: Spanner の分散アーキテクチャの詳細については、Google Cloud Spanner のドキュメントをご覧ください。

  • デベロッパー向け Gemini を確認する: AI を活用したコーディングとヘッドレス CLI の自動化がエンジニアリング ワークフローにどのように役立つかを、デベロッパー向け Google Cloud AI でご確認ください。

- アプリケーション エンジニア Sachin Mathapati

前日
Archive
翌日