Frozen v2を読む、LLM推論をチップに寄せる前に測る3つの境界
title: "Frozen v2を読む、LLM推論をチップに寄せる前に測る3つの境界"
emoji: "🧊"
type: tech
topics: ["生成AI", "llm", "gemini", "推論", "aiチップ"]
published: false
GoogleがGeminiのアーキテクチャをハードウェアへ深く固定する「Frozen v2」を開発中だという報道が出ている。報道値の6〜10倍という効率だけを追うと、設計変更を見誤る。モデル専用チップは推論費用を下げる代わりに、モデルを変えるコストを基盤側へ押し戻す。
自分は推論基盤の設定を見るとき、tokens/s と更新頻度を同じ表に置いている。片方だけ良くても、運用はすぐ詰まるんだよね。Frozen v2の話で先に設計したいのも、固定した前提が外れたときの逃げ道だと思う。
「6〜10倍」の前に、何が固定されるのか
The Decoderの報道では、Frozen v2はGeminiのアーキテクチャをチップに組み込み、6〜10倍の効率を狙い、2028年投入の計画とされる。TechCrunchも、Geminiを効率よく動かす新しいAIチップをGoogleが開発中だと報じている。
対象モデルが絞れれば、行列演算、メモリ移動、通信を一般形で扱う余白を削れる。attentionの形、Mixture of Expertsのルーティング、KVキャッシュ（直前までの文脈を保持する推論用メモリ）の置き方まで読めるからだ。
固定されるのは「Gemini」という名前ではない。レイヤー幅、MoEで何個の専門家を選ぶか、文脈長、量子化、演算順序といった実行時の前提だ。重みを差し替えられても、この前提が動けば専用回路のうまみは薄くなる。
境界1: モデル更新を、重み更新と形状変更に分ける
モデル更新を一つのデプロイとして扱うと危ない。LoRAの差し替えのようにテンソルの形を変えない更新は専用チップと相性がいい。長いコンテキストを標準にする、attentionを別方式へ変える、MoEのtop-kを変える変更はデータフローに触る。
「新モデルを出したらベンチを回す」だけでは遅い。リリースノートから、チップ側の前提が割れたかを機械的に判定したい。APIのバージョンより、実行形状のバージョンを持つ感覚に近い。
model: gemini-next
runtime_shape:
context_window: 1048576
attention: grouped_query
moe_top_k: 2
kv_cache: int8_paged
route:
frozen_v2: compatible
general_tpu: fallback
このようなメタデータは地味だけど効く。モデル名だけでルーティングすると、互換性のない変更を専用系へ流してから気づく。障害はたいてい、性能が少し落ちた状態で始まる。
境界2: ベンチマークと実トラフィックを分ける
チップの効率は、単発の生成速度だけでは決まらない。実運用ではprefill（入力トークンを読む処理）とdecode（出力を1トークンずつ生成する処理）の比率が変わる。長文RAGと短いチャットが同じキューに入れば、平均tokens/sが高くてもp99レイテンシは崩れる。
専用化が効きやすいのは、形の揃った処理を高い利用率で流せるときだ。リクエストの形が散る初期プロダクトや、毎週モデル構成をいじる検証環境では、汎用TPUやGPUの余白が価値になる。速いハードウェアほど「何を流さないか」の制約も増える。
手元のダッシュボードなら、総tokens/sの横にこれを置きたい。
| 観測値 | 分けて見る理由 |
|---|---|
| prefill / decode の時間 | 長い入力と生成待ちを混ぜると原因が消える |
| p50 / p99 レイテンシ | 平均の改善が待ち時間の改善とは限らない |
| 専用系への適合率 | 何割が想定どおりの形で流れたかを見る |
| fallback率 | モデル更新や混雑で逃げ道が常用化していないか確認する |
境界3: フォールバックを障害時だけの経路にしない
一番やりがちなのは、汎用TPUへの退避を「保険」として実装し、平常時に観測しないこと。モデル更新の当日、互換性のないリクエストが初めて退避経路を踏む。性能低下がそのまま障害に化ける。
専用系と汎用系の両方へ、少量の影トラフィックを流して差分を見る方がいい。入力長、実行形状、出力長の分布を採れば、どの変更から適合率が落ちたかは追える。昨日この手のメトリクスを眺めていても、失敗率より先にfallback率がじわっと動くケースが多い。アラートの閾値を一つ増やすだけで、調査の開始点がかなり変わる。
専用チップを、速いモデル更新へつなげる
Frozen v2が報道どおり進めば、Googleは推論費用をモデル設計と一緒に削ることになる。更新を重み・実行形状・トラフィック特性に分解し、互換性を判定して、常に動く汎用系へ逃がせるから専用化を使える。
次に見るべきなのは倍率そのものより、Gemini側でどの実行形状を長く固定するのかだと思う。専用チップの勝負は回路性能だけで決まらない。モデル、コンパイラ、ルータの三者がどこまで同じ前提を共有できるか。その境界を観測できるチームから、効率化を本番の利益に変えていくはずだ。
Discussion