Frozen v2とは何か？Gemini専用AIチップ構想を読み解く
結論：固定構成の評価手法ではなく、Gemini向けAIチップのコードネーム
Frozen v2とは、Googleが生成AIモデル「Gemini」の推論に特化して開発していると報じられた、サーバー向けAIチップの内部コードネームです。
下書きでは、Frozen v2を「モデルや実行環境を固定したうえで、性能・品質・安定性を検証する評価プロセス」として説明していました。この考え方自体はAIシステムの評価方法として有用ですが、現在報道されているFrozen v2とは別の概念です。
2026年7月21日時点で、GoogleによるFrozen v2の正式発表、製品仕様、実測ベンチマークは確認できません。報道では、Geminiの処理特性をハードウェア設計に組み込み、Googleの最新TPUと比べてトークンあたりの電力効率を6〜10倍高める可能性や、2028年頃の導入が言及されています。ただし、これらは未発表の計画に関する報道であり、Googleが公開した性能値ではありません。The Informationの報道
したがって、現時点でFrozen v2について断定できるのは、報道された開発計画と、そこから合理的に推測できる技術的な意義までです。
Frozen v2と固定構成評価は別の概念
本稿では、用語を次のように整理します。
| 用語 |
本稿での意味 |
| Frozen v2 |
GoogleがGemini向けに開発していると報じられた専用AIチップ |
| Frozen v2評価 |
Frozen v2のような固定用途チップを評価するための方法論 |
| 固定構成評価 |
モデル、チップ、ランタイム、入力条件などを固定して継続的に測定する評価プロセス |
この区別をしないまま記事を構成すると、「Frozen v2という製品の説明」と「AIシステムの評価方法」が混在し、論点がぼやけてしまいます。
固定構成評価は、Frozen v2を検証する際に活用できる方法論です。しかし、それ自体がFrozen v2を意味するわけではありません。
報道されているFrozen v2の位置づけ
報道ベースでは、Frozen v2は次のような構想として説明できます。
Google Geminiの推論に特化したサーバー向けAIチップであり、Geminiのニューラルネットワーク構造やデータ処理方式の一部をハードウェアに組み込み、汎用的なAIアクセラレータよりもデータ移動や制御処理のオーバーヘッドを削減することを目指すものです。
現時点で報道されている主な特徴は、Geminiの推論処理への特化、トークン生成あたりの電力効率の大幅な改善、そして早ければ2028年頃の導入計画です。ただし、チップの回路構成、搭載メモリ、演算精度、チップレット構成、ネットワーク仕様などは公開されていません。
Googleはこれまでも、AIモデルの学習や推論に利用する独自プロセッサとしてTPUを継続的に改良してきました。TPUの製品情報や利用方法は、Google CloudのTPU公式ドキュメントで確認できます。
Frozen v2が既存のTPUの延長線上にあるのか、それともGemini専用のASICとして別系統に位置づけられるのかは、現在のところ明らかになっていません。ただし、報道どおりGeminiへの特化度が高いのであれば、汎用的なTPUよりもモデルとチップの協調設計を重視した構想だと考えられます。
「Geminiをチップに焼き込む」とは何か
「Geminiのアーキテクチャをシリコンに焼き込む」という表現は刺激的ですが、モデルの全パラメータをそのままチップへ固定配線するという意味だとは限りません。
現実には、次のような処理を専用化する構想だと考えるのが自然です。
- 頻繁に使われる演算パターンの固定回路化
- 特定のテンソル形状やデータ型への最適化
- 量子化された重みやKVキャッシュの処理方式の専用化
- Transformerの一部処理のアクセラレータ化
- Geminiの実行パターンに合わせたメモリ配置とデータ移動
- 推論時のスケジューリングやチップ間通信の最適化
つまりFrozen v2は、「Geminiそのものを一枚のチップへ格納する」というより、Geminiが頻繁に行う処理を、汎用的な命令実行よりも短い経路で処理するチップと解釈するのが妥当です。
これは報道内容をもとにした技術的な推測です。Frozen v2の具体的な回路やソフトウェア構成が公開されるまでは、確定的な仕様として扱うべきではありません。
なぜGoogleはGemini専用チップを必要とするのか
AI推論のボトルネックは演算性能だけではない
AIチップを評価するとき、TOPSやTFLOPSは分かりやすい指標です。しかし、大規模言語モデルの推論では、演算器のピーク性能だけでなく、システム全体のデータ処理が性能を大きく左右します。
主なボトルネックには、モデルの重みをメモリから読み出す時間、KVキャッシュへのアクセス、チップ内外のデータ移動、チップ間通信、ホストCPUとの転送、カーネル起動やスケジューリングのオーバーヘッドなどがあります。
また、動的に変化する入力長・出力長に対応しながら、バッチ処理とリアルタイム応答を両立させる必要もあります。
NVIDIAのTensorRT公式ドキュメントでも、推論性能をGPUの演算時間だけでなく、ホスト側処理、データ転送、エンキュー時間、メモリ使用量、アプリケーション全体の処理時間に分けて評価しています。
特にLLMの生成処理では、入力を一括処理するPrefillと、トークンを一つずつ生成するDecodeで、必要な計算資源やメモリアクセスの性質が異なります。
Prefillでは大量の入力トークンを並列処理するため、演算性能が効きやすくなります。一方、Decodeでは1トークンずつ生成するため、メモリ帯域やKVキャッシュへのアクセスが重要になります。
Frozen v2がGemini向けに最適化されるのであれば、特にDecode段階のデータ移動とメモリアクセスを削減する設計が重要になる可能性があります。これは単に「演算速度が速いチップ」を作るという話ではありません。
電力効率がサービスの経済性を左右する
生成AIのコストは、チップの購入費だけでは決まりません。電力、冷却、データセンターの電源容量、ネットワーク、メモリ、チップ間通信、保守、モデル更新、ソフトウェア最適化、障害対応まで含めて考える必要があります。
そのため、仮にFrozen v2が報道どおり6〜10倍の電力効率を実現したとしても、重要なのはチップ単体の性能ではなく、サービス全体でどれだけ有効な出力を生み出せるかです。
実用価値は、次のように考えられます。
実用価値 ＝ 有効な生成トークン数
÷（電力＋冷却費＋運用費＋失敗・再試行コスト）
ここでいう「有効な生成トークン」とは、単に出力されたトークン数ではありません。エラー、タイムアウト、再生成、品質基準未達の出力を除き、実際にサービス価値へ変換された出力を指します。
MLCommonsのMLPerf Inference Datacenterでも、アクセラレータ単体ではなく、システム全体の性能や電力、エネルギー効率を評価する考え方が採用されています。
Frozen v2が示すモデルとチップの協調設計
汎用チップから専用チップへ
GPUや汎用TPUの強みは、さまざまなモデルやフレームワークに対応できることです。新しいモデルが登場しても、コンパイラやカーネルを更新すれば、同じハードウェアを使い続けられます。
一方、Frozen v2のような専用チップは、特定のモデルに対して高い性能と効率を実現できる可能性があります。
| 観点 |
汎用GPU・汎用AIアクセラレータ |
Frozen v2のような専用チップ |
| 対応モデル |
幅広い |
Gemini中心に限定される可能性 |
| 初期性能 |
高いが汎用的 |
特定処理で非常に高い可能性 |
| モデル変更への対応 |
比較的容易 |
回路との不整合が問題になりやすい |
| ソフトウェア資産 |
豊富 |
専用コンパイラやランタイムが必要 |
| 電力効率 |
高い |
条件が合えばさらに高い可能性 |
| ベンダーロックイン |
ある |
より強くなる可能性 |
| 投資回収 |
複数用途で分散可能 |
Geminiの利用量に大きく依存 |
この構図は、単純な「GPU対ASIC」の比較ではありません。Frozen v2は、GoogleがGeminiを自社サービスの中心に据え、モデル、クラウド、データセンター、チップを一体運用するからこそ成立する戦略です。
専用化は性能を高める一方で、未来を固定する
専用チップの利点は、不要な汎用性を削れることです。特定の行列演算、テンソル形状、低精度フォーマット、KVキャッシュの読み書き、Attentionの一部、Mixture-of-Expertsの制御、チップ間通信などを専用化できる可能性があります。
しかし、専用化には代償もあります。
Geminiの設計が大きく変わった場合、Frozen v2の最適化が逆に足かせになる可能性があります。新しいAttention方式、異なるMoE構造、新しい推論アルゴリズム、別のマルチモーダル処理方式へ移行すれば、チップ上の固定機能が十分に活用されないかもしれません。
Frozen v2の本質的なリスクは、性能不足ではなく、将来のモデル進化に対する硬直性です。
報道された「6〜10倍」をどう読むべきか
Frozen v2について報道された「6〜10倍」という数字は、現時点では慎重に扱う必要があります。少なくとも、次の条件が分からなければ比較できません。
比較対象がどの世代のTPUなのか、Geminiのどのモデルを使ったのか、入力トークン長と出力トークン長はいくつなのか、PrefillとDecodeのどちらを測ったのか、バッチサイズや同時実行数はいくつなのかといった条件です。
さらに、量子化の有無、生成品質の維持、チップ単体かサーバー全体か、冷却やネットワークを含むのか、どの程度の稼働率で測ったのかも明記されなければなりません。
「トークンあたりの電力」が6倍良くても、品質低下によって再生成が増えれば、実効的な効率は下がります。低負荷時には高速でも、高い同時実行数でp99レイテンシが急激に悪化するなら、対話サービスには使いにくい可能性があります。
したがって、Frozen v2は単一の効率倍率ではなく、次のような曲線で評価する必要があります。
- 同時実行数とTTFT
- 同時実行数とTPOT
- 負荷率とp95・p99レイテンシ
- モデル品質と量子化率
- tokens/secとtokens/watt
- 稼働時間とメモリ使用量
- エラー率と再試行率
LLMでは平均値より末尾遅延が重要
チャットサービスでは、平均レイテンシだけではユーザー体験を評価できません。
平均応答時間が短くても、一部のユーザーが数秒以上待たされるなら、実際のサービス品質は悪い可能性があります。特にストリーミング応答では、以下の指標を分けて確認する必要があります。
- TTFT：最初のトークンが返るまでの時間
- TPOT：トークンごとの生成時間
- E2E latency：応答全体が完了するまでの時間
- p50・p95・p99：遅延分布
- キュー待ち時間
- タイムアウト率
- キャンセル率
- 再試行率
MLCommonsのMLPerf Endpointsも、生成AIサービスの評価では、モデルやチップ単体ではなく、エンドポイントとしてのTTFT、TPOT、tokens/sec、同時実行数などを確認する必要があることを示しています。
Frozen v2を評価するために固定すべき条件
下書きにあった「固定構成を一定期間測定する」という発想は、Frozen v2の評価方法として再利用できます。ただし、Frozen v2という製品名の定義ではなく、専用AIチップを検証するための評価プロトコルとして位置づけるべきです。
ハードウェア条件
チップの型番・ステッピング、チップ数、HBM容量と帯域、ノード構成、チップ間接続、ホストCPU、ネットワーク構成、電力上限、冷却条件、ファームウェア、サーバー温度などを固定・記録します。
モデルとソフトウェア条件
Geminiのモデル世代、チェックポイント識別子、量子化方式、精度形式、コンパイラ、ランタイム、ドライバー、カーネル実装、推論サーバー、トークナイザー、プロンプトテンプレート、サンプリング設定、乱数シード、フォールバック処理を記録します。
特に専用チップでは、未対応演算子がCPUや別のアクセラレータへフォールバックしていないかを確認する必要があります。チップ単体のベンチマークでは高速に見えても、一部の処理が別デバイスへ移動していれば、サービス全体の性能は大きく変わります。
ワークロード条件
LLMの評価では、入力長と出力長を平均値だけで示してはいけません。短文チャット、長文要約、コード生成、エージェント処理、大規模バッチ、マルチモーダル処理など、実際の用途に近いシナリオへ分ける必要があります。
| シナリオ |
入力 |
出力 |
主な評価対象 |
| 短文チャット |
短い |
短い |
TTFT、操作感 |
| 長文要約 |
長い |
中程度 |
Prefill、メモリ帯域 |
| コード生成 |
中程度 |
長い |
TPOT、総時間 |
| エージェント処理 |
可変 |
可変 |
ツール呼び出し、再試行 |
| 大規模バッチ |
長い |
長い |
スループット、電力 |
| マルチモーダル |
画像・音声を含む |
可変 |
前処理、異種データ処理 |
MLPerf Inferenceの公式提出ガイドでも、Server、Offline、Interactiveなどのシナリオを分け、用途に応じて異なる測定要件を定めています。
量子化と専用化のトレードオフ
Frozen v2が高い電力効率を実現するには、量子化や専用データパスが重要になる可能性があります。
FP16やBF16からFP8、INT8、さらに低ビット形式へ移行すれば、メモリ使用量とデータ移動量を削減できます。しかし、量子化によって数値誤差、長文推論の品質劣化、コード生成の正確性低下、多言語性能の偏り、ツール呼び出しの失敗、安全性判定の不安定化などが生じる場合もあります。
そのため、量子化後の性能は、単に「何倍高速か」だけでは評価できません。
量子化の実用価値 ＝（処理量の増加＋コスト削減）
÷（品質低下＋失敗率増加＋保守負担）
Frozen v2のようにハードウェアとモデルを強く結びつける設計では、量子化方式そのものがチップ設計に組み込まれる可能性があります。その場合、後から別の量子化方式へ変更する自由度が低くなり、モデル更新とチップ更新のタイミングを一致させる必要があります。
Frozen v2が抱える主な懸念
モデルの進化速度と半導体開発速度の不一致
AIモデルは数か月単位で更新されます。一方、専用チップの設計、検証、製造、量産には長い時間がかかります。
Frozen v2が2028年頃の導入を目指すとすれば、設計時点のGeminiと、実際の導入時点のGeminiの構造が異なる可能性があります。専用化の度合いが強いほど、この時間差は大きなリスクになります。
ハードウェアへの依存が強くなる
GeminiがFrozen v2に最適化されると、GoogleのAIサービスは独自チップ、コンパイラ、ランタイム、データセンター構成に依存することになります。
Googleにとっては競争力になりますが、利用者側には、他社クラウドとの互換性低下、ベンチマークの比較困難、移行コストの増大、ベンダーロックイン、障害発生時の代替手段不足といった問題が生じる可能性があります。
チップの性能がサービス全体に直結しない可能性
チップが高速でも、APIゲートウェイ、認証、トークナイズ、モデルルーティング、キュー、ネットワーク、データベース、外部ツール呼び出し、出力フィルタリング、ログや監視がボトルネックになる場合があります。
そのため、Frozen v2の評価では、チップ内部のレイテンシとユーザーが観測するエンドツーエンドレイテンシを分けて報告しつつ、最終的には両方を確認する必要があります。
効率化が利用拡大によって相殺される可能性
推論コストが下がると利用量が増え、データセンター全体の電力消費が減らない可能性もあります。
Frozen v2が1トークンあたりの電力を削減しても、Geminiが検索、広告、オフィス、開発支援、エージェント、動画、ロボティクスなどへ広く組み込まれれば、総推論量が増加する可能性があります。
したがって、評価対象は「1トークンあたりの効率」だけでは不十分です。tokens/wattやtokens/dollarといった原単位の効率に加え、データセンター全体の電力、冷却、水使用量、設備投資といった総量の影響も確認する必要があります。
評価で見るべき指標
Frozen v2の評価では、性能だけでなく、品質、効率、信頼性を分けて測定する必要があります。
性能では、TTFT、TPOT、エンドツーエンドレイテンシ、p50・p95・p99・p99.9、tokens/sec、queries/sec、同時実行数、キュー待ち時間、タイムアウト率などを確認します。
品質では、正解率、コード実行成功率、ツール呼び出し成功率、長文タスクの完遂率、マルチモーダル処理精度、量子化前後の品質差、重大エラー率、安全性評価の失敗率などが重要です。
効率では、tokens/watt、tokens/dollar、1リクエストあたりの消費電力量、サーバー全体の平均電力、ピーク電力、冷却を含む電力、低負荷時と高負荷時の効率を測定します。
信頼性では、長時間稼働時の性能劣化、メモリリーク、リクエスト失敗率、ノード障害からの復旧時間、リトライ連鎖の有無、ロールバック時間、モデル更新時の互換性、異常入力に対する挙動を確認します。
NISTのAI Risk Management FrameworkとGenerative AI Profileも、AIシステムを開発時のベンチマークだけでなく、設計、導入、運用、監視、評価を含むライフサイクル全体で管理する考え方を示しています。
評価結果を単一スコアにまとめない
Frozen v2を評価する際、最も避けるべきなのは「総合スコア1位」という結論です。
例えば、システムAは非常に高速で電力効率も高いものの、p99レイテンシと障害復旧に弱いかもしれません。一方、システムBは速度や効率では劣っていても、品質と安定性に優れている可能性があります。
リアルタイムチャットではAが有利でも、金融、医療、企業業務では、p99の安定性や障害復旧を重視してBを選ぶ方が合理的な場合があります。
したがって、採用基準は単一スコアではなく、制約条件付き評価にするべきです。品質が基準値以上であること、p99レイテンシがSLO以内であること、重大エラー率が上限以下であること、tokens/wattが既存システムを上回ること、長時間運用で性能劣化がないこと、モデル更新後も一定の互換性を維持すること、障害発生時に規定時間内で復旧できることなどを個別に確認します。
この方式なら、電力効率だけが高く、品質や安定性に問題のあるチップを、総合点の高さだけで採用するリスクを減らせます。
Frozen v2の本当の意味
Frozen v2の重要性は、単にGoogleが新しいAIチップを作っていることではありません。
より本質的には、GoogleがGeminiのモデル設計、推論ランタイム、専用コンパイラ、AIチップ、メモリ階層、チップ間ネットワーク、データセンター、サービスの負荷分布を一体化しようとしている点にあります。
これまでAIシステムでは、モデル、チップ、クラウド、アプリケーションは比較的別々に評価されてきました。Frozen v2は、その境界を曖昧にする構想です。
そのため、評価の単位も「このチップは何TOPSか」から、次の問いへ移る必要があります。
Geminiを、現実の入力、現実の負荷、現実の電力制約、現実の障害条件のもとで、どれだけ安定して、安く、安全に提供できるのか。
現時点でFrozen v2の仕様や性能を断定することはできません。しかし、もし報道どおりGeminiに深く特化したチップが実現すれば、AIアクセラレータの競争は、汎用的な演算性能の競争から、特定のモデルをどれだけ効率よくサービス化できるかという垂直統合の競争へ進む可能性があります。
重要なのは、「6倍速いのか」「10倍効率的なのか」という数字そのものではありません。その数字が、どのモデルで、どの入力条件で、どの負荷に対して、どの品質を維持し、どの範囲の電力とコストを含め、どれほど長く再現できるのかを明らかにすることです。
Frozen v2は、現時点では確定した製品ではなく、GoogleがGeminiをハードウェアのレベルから最適化しようとしていることを示す、重要だが未検証の開発計画です。
