Googleは2026年6月5日、Gemma 4ファミリーにQuantization-Aware Training、つまりQATで最適化したチェックポイントを追加しました。これは単なる「軽量版が出た」という話ではなく、ローカルLLMやオンデバイスAIを試す人が、モデルサイズ、量子化形式、実行ランタイム、端末メモリを先にそろえて読むべき更新です。
この記事では、公式発表、Google AI for DevelopersのGemma 4 overview、Gemma 4 model card、Google公式Hugging Faceコレクションをもとに、Q4_0、Mobile、compressed tensors、MTP、メモリ要件を利用者目線で整理します。Redditや専門メディアでの実測投稿は需要シグナルとして確認しましたが、仕様や性能の根拠には使いません。
Alphabet Watch JapanはAlphabetおよびGoogleとは非提携の独立サイトです。商標、製品名、公式情報は各社に帰属します。
3行まとめ
このテーマをもう少し広げて見るなら、Kaggle Benchmarksローカル作成の確認点：AI評価タスクをCLI、SDK、エージェントで作る前に と Gemini 3.5 Flashの導入判断：Vertex AIで見るモデルID・価格・移行前チェック も合わせて確認してください。Gemma 4 QATを導入する前後で、ローカル評価タスクや比較条件をどう作るかにつなげやすい。
Gemma 4ファミリーにQAT最適化チェックポイントが追加され、Q4_0やMobileなどの選択肢が増えた。
ローカル検証はGGUF、端末内実行はMobile、サーバー配信はcompressed tensorsを候補にする。
メモリ、KVキャッシュ、発熱、バッテリー、ライセンス、禁止用途を確認してから導入判断に進む。
QATは軽量化の入口を増やすが、すべての環境で同じ速度や品質を保証するものではない。
- Gemma 4 QATは、Gemma 4の既存ファミリーにQATチェックポイントを追加し、Q4_0やMobileなどの導入形式を増やす更新です。
- E2B/E4BはMobile形式でオンデバイス候補になりやすい一方、12B、26B A4B、31BはQ4_0でもKVキャッシュや長文入力を含めて余裕を見て計画する必要があります。
- まずは用途から、GGUF、compressed tensors、Mobile、unquantized/assistantを選び、最後にライセンス、禁止用途、発熱、バッテリー、再現性を確認するのが安全です。
Gemma 4 QATで何が変わったのか
- 1Gemma 4ファミリー
新しい別系統モデルではなく、既存ファミリーにQAT最適化チェックポイントが加わった。
- 2QATで品質低下を抑える
学習中に量子化の影響を意識し、後から圧縮するPTQとは違う考え方で軽量化する。
- 3Q4_0とMobileを追加
Q4_0はローカルLLMの入口になりやすく、MobileはE2B/E4Bの端末内検証に向く。
- 4ランタイムごとに選ぶ
llama.cpp、LiteRT-LM、vLLM、SGLang、Ollama、LM Studioなどで選ぶ形式が変わる。
速度や安定性は端末、ランタイム、入力モード、コンテキスト長で変わるため、形式だけで判断しない。
Googleの発表で変わった点は、Gemma 4という名前の新しい別系統モデルが出たことではありません。Gemma 4ファミリーに、QATで最適化された新しいチェックポイントが追加されたことです。
Google Blogの発表では、QATによってGemma 4を日常的なエッジデバイスやコンシューマーGPUで動かしやすくすると説明されています。対象は、Q4_0形式のチェックポイントと、モバイル用途に特化した新しい量子化形式です。
発表で確定している追加点
公式発表から確認できる主な追加点は次の通りです。
| 確認する項目 | 公式情報で確認できる内容 | 読者への意味 |
|---|---|---|
| QATチェックポイント | Gemma 4向けにQAT最適化チェックポイントを追加 | 既存のGemma 4モデルを、より軽い形式で試す選択肢が増える |
| Q4_0 | ローカルLLMで広く使われるQ4_0形式に対応 | llama.cpp、LM Studio、Ollamaなどの入口になりやすい |
| Mobile形式 | モバイル用途向けの特化形式を追加 | E2B/E4Bを端末内実行の候補として検討しやすくなる |
| E2Bのメモリ削減 | Mobile形式でGemma 4 E2Bのメモリフットプリントを1GB規模に下げたと説明 | 短いテキスト用途から端末内検証しやすくなる |
| ツール連携 | Hugging Face、LiteRT-LM、llama.cpp、vLLM、SGLang、Ollama、LM Studio、Transformers.jsなどに言及 | 実行環境ごとに選ぶ形式が変わる |
ここで大事なのは、QATが「すべての環境で同じように速く、安く、品質を落とさず動く」ことを保証するものではない点です。QATは、量子化を学習段階から意識して品質劣化を抑えるための方法であり、実際の速度や安定性は端末、ランタイム、コンテキスト長、入力の種類で変わります。
QATとPTQをどう読み分けるか
量子化には大きく、学習済みモデルを後から圧縮するPost-Training Quantization、つまりPTQと、学習中に量子化の影響をシミュレートするQuantization-Aware Training、つまりQATがあります。
Gemma 4 QATの読みどころは、Googleが「後から小さくする」だけでなく、「小さくした状態での品質低下を抑える」方向に公式チェックポイントを出したことです。ローカルLLMを試す個人にとっては、Q4_0 GGUFを選びやすくなります。プロダクト担当者にとっては、Mobile形式やLiteRT-LMを使った端末内PoCの検討材料が増えます。
ただし、QATだから本番投入してよい、という結論にはなりません。たとえば社内検索、コード支援、画像OCR、音声入力、チャット履歴の長い会話では、品質、遅延、メモリピーク、発熱、バッテリー、ログ保全、モデル更新のすべてを別に見る必要があります。
Q4_0、Mobile、CTをどう選ぶか
形式名は入口であり、実際の快適さは対応ランタイム、GPUオフロード、チャットテンプレート、コンテキスト長で変わる。
Gemma 4 QATで読者が最初に迷うのは、モデル名の接尾辞です。Hugging Faceの公式コレクションを見ると、同じGemma 4でも、GGUF、unquantized、assistant、compressed tensors、Mobile向けなど複数の形式が並びます。
まずはモデル名ではなく、使いたい場所から逆引きすると読みやすくなります。
| 形式・接尾辞 | 主な想定ランタイム | 向いている用途 | 最初に確認すること |
|---|---|---|---|
-qat-q4_0-gguf | llama.cpp、LM Studio、Ollamaなど | 手元のローカルLLM検証、会話UI、ローカルAPI | ツール側のGemma 4対応、GPUオフロード、チャットテンプレート |
-qat-q4_0-unquantized | 変換、研究、独自量子化 | ほかの形式へ変換したい場合 | 変換先の対応状況、ライセンス、再配布条件 |
-assistant | MTPのdraft model用途 | speculative decodingで速度を検証したい場合 | 主モデルとの組み合わせ、ランタイム側のMTP対応 |
-qat-w4a16-ct | vLLM、SGLangなど | サーバー配信、高スループット推論 | 対応モデル、GPUメモリ、同時実行数 |
-qat-mobile-transformers | モバイル向け参照実装や変換 | E2B/E4Bの端末内検証 | 対象モデル、入力モード、端末メモリ |
-qat-mobile-ct | LiteRT-LMなどのエッジ配備 | アプリ組み込み、端末内AI | LiteRT-LM対応、NPU/GPU/CPU、更新配布 |
Q4_0 GGUFはローカルLLMの入口として読む
個人がまず試すなら、Q4_0 GGUFが入口になりやすい形式です。Google公式のQ4_0コレクションには、E2B、E4B、12B、26B A4B、31BのGGUFが並びます。ローカルLLM界隈で使われるツールに載せやすく、環境を作り替えずに検証できるためです。
とはいえ、GGUFがあることと、手元の環境で快適に動くことは別です。CPUだけで動かすのか、GPUへどこまでオフロードするのか、Apple Siliconのユニファイドメモリを使うのか、コンテキスト長をどこまで伸ばすのかで体感は変わります。
確認項目
既存のGemma 4 12BのローカルAI導入条件では、12B単体を16GB級ローカル環境でどう読むかを整理しています。本稿では、その前提を一段広げて、QAT形式とモデルサイズの選び方に焦点を当てます。
Mobileとcompressed tensorsは用途で分ける
Mobile形式は、E2B/E4Bを端末内で使うための選択肢として読むのが自然です。Google Blogでは、モバイル向けの量子化スキーマとして、静的アクティベーション、チャネル単位量子化、targeted 2-bit quantization、EmbeddingとKV cacheの最適化が説明されています。
一方、-w4a16-ct のcompressed tensorsは、vLLMやSGLangのような高スループット推論を意識した形式です。端末内アプリへそのまま入れるというより、サーバー側で効率よく配信したいチームが見る形式です。
形式の分け方
つまり、MobileとCTはどちらも「軽くする」文脈にありますが、目的が違います。端末で動かすならMobile、サーバーで多人数に出すならcompressed tensors、手元で試すならGGUFと分けると、モデル選定の迷いが減ります。
モデルサイズ別のメモリ計画
表の数値は主にベース重みの目安であり、OS、ランタイム、KVキャッシュ、画像や音声入力は別に上乗せして考える。
Google AI for DevelopersのGemma 4 overviewには、Gemma 4各モデルの推論時メモリ要件の目安が示されています。ここでの数値は、モデルをロードするためのGPUまたはTPUメモリの目安です。実際の利用では、ランタイム、OS、KVキャッシュ、長いプロンプト、画像や音声の入力で追加のメモリが必要になります。
公式表を導入判断用に読むなら、次のように整理できます。
| モデル | BF16 | SFP8 | Q4_0 | Mobile | Mobile Text-only |
|---|---|---|---|---|---|
| Gemma 4 E2B | 11.4GB | 5.7GB | 2.9GB | 1.1GB | 0.84GB |
| Gemma 4 E4B | 17.9GB | 8.9GB | 4.5GB | 2.5GB | 2.2GB |
| Gemma 4 12B | 26.7GB | 13.4GB | 6.7GB | – | – |
| Gemma 4 26B A4B | 57.7GB | 28.8GB | 14.4GB | – | – |
| Gemma 4 31B | 69.9GB | 34.9GB | 17.5GB | – | – |
この表だけを見ると、E2BやE4Bはかなり小さく見えます。ただし、ここで油断しない方がいいです。Googleの説明では、これらの値は静的なモデル重みをロードする目安であり、追加のVRAMやコンテキストウィンドウは別に考える必要があります。
E2B/E4BはMobileで初めてオンデバイス候補になる
E2B/E4Bは、Gemma 4の中でモバイルやブラウザ寄りの候補です。特にMobile形式では、E2Bが1.1GB、Text-onlyなら0.84GB、E4Bが2.5GB、Text-onlyなら2.2GBという目安が示されています。
ここで「E2Bだから2GB未満で必ず動く」と読むのは危険です。Gemma 4 overviewでは、E2B/E4Bの「E」はeffective parametersを示し、Per-Layer Embeddingsを使うため、静的重みのロード量は単純な有効パラメータ数だけでは決まりません。
検証の順番
端末内で試すなら、最初は次の順に条件を削るのが現実的です。
- テキストのみで短い会話から始める
- コンテキスト長を控えめにする
- 画像、音声、動画を同時に使わない
- 発熱とバッテリーをログで確認する
- モデル更新とロールバック方法を決める
- 利用規約と禁止用途をチームで確認する
Googleの発表でも、音声や視覚エンコーダーが不要な用途では、必要なモダリティだけを配備することでメモリをさらに抑えられると説明されています。これは、オンデバイスAIの設計ではかなり重要です。何でも載せるのではなく、用途に必要な入力だけに絞るほど、端末側の現実に近づきます。
12B、26B A4B、31BはQ4_0でも余裕を見て計画する
12B、26B A4B、31Bは、Q4_0にしても端末内で気軽に扱うモデルではありません。公式表では、12BのQ4_0が6.7GB、26B A4Bが14.4GB、31Bが17.5GBの目安です。これはモデル読み込みの目安であって、長い会話や大量の入力を含めた総必要メモリではありません。
特に26B A4BはMixture-of-Expertsモデルです。Gemma 4 model cardでは、26B A4Bが1トークンあたり約4Bのactive parametersを使う一方、速いルーティングと推論のために全重みをメモリへロードする必要があると説明されています。「A4Bだから4B分だけ用意すればよい」と読むと、メモリ計画を誤ります。
12B以上を使うなら、まずはローカルの実験環境やクラウドGPUで、モデル読み込み、初回応答、長文時のメモリピーク、tokens/sec、MTPの有無を分けて確認するのが安全です。手元端末が足りない場合は、Google Colab CLIの提供条件のようなGPU/TPU検証ルートも候補になります。
実行環境別の導入ルート
- 1手元で会話UIを試す
Q4_0 GGUFを候補にし、llama.cpp、LM Studio、OllamaのGemma 4対応を見る。
- 2ローカルAPIを立てる
GPUオフロード、CPU速度、チャットテンプレート、モデル入れ替え時のログを確認する。
- 3サーバーで配信する
compressed tensors、vLLM、SGLangを候補にし、同時実行数とKVキャッシュを見積もる。
- 4アプリに組み込む
E2B/E4BのMobile形式とLiteRT-LMを見ながら、端末差と更新配布を確認する。
- 5Webや研究で扱う
Transformers.js、MLX、Hugging Face Transformersなど、変換や実行の入口を分けて選ぶ。
他人のtokens/secだけでは判断せず、同じ条件でメモリ、初回応答、出力長、長文時の挙動を測る。
Gemma 4 QATは、同じモデル名でも実行環境によって選ぶファイルが変わります。ここを間違えると、モデルをダウンロードした後に「自分のツールでは読めない」「速くならない」「MTPが使えない」ということが起きます。
デスクトップで試すならllama.cpp、LM Studio、Ollama
ローカルで会話UIやAPI互換サーバーを試したいなら、まずGGUF形式を見ます。llama.cpp、LM Studio、Ollamaは、個人や小規模チームが試しやすい入口です。
このルートでは、次の項目を確認します。
- ツール側がGemma 4のチャットテンプレートに対応しているか
- QAT Q4_0 GGUFを正しく読めるか
- GPUオフロードをどこまで使うか
- CPUのみで許容できる速度か
- MTP assistantを使う場合、ランタイムが対応しているか
- コンテキスト長を伸ばしたときにメモリがどこまで増えるか
- モデルの入れ替えとログの取り方を決めているか
ここで実測投稿を参考にしたくなりますが、他人のtokens/secだけで判断しない方がいいです。同じモデル名でも、CPU、GPU、メモリ帯域、ランタイムのバージョン、プロンプト、出力長で数字は変わります。
サーバー、Web、モバイルでは選ぶ形式が変わる
サーバー配信を検討するなら、vLLMやSGLangとcompressed tensorsの組み合わせを見ます。高スループットや同時実行を考えるなら、単にモデルが軽いかどうかではなく、バッチング、KVキャッシュ、メモリ断片化、スケールアウトの方法も合わせて見る必要があります。
Web寄りならTransformers.js、Apple Silicon寄りならMLX、研究や変換ならHugging Face Transformersが候補になります。アプリ組み込みや端末内実行を狙うなら、Google AI EdgeやLiteRT-LMのドキュメントを見ながら、E2B/E4BのMobile形式を検討します。
Android文脈では、Gemini Intelligenceの対応条件で見たように、端末、地域、権限、提供時期が体験を左右します。Gemma 4 QATも、モデルファイルだけでなく、ランタイムと端末条件をセットで読む必要があります。
MTP、マルチモーダル、長文コンテキストで増える確認点
主モデル、assistant、ランタイム実装、量子化後の組み合わせがそろって初めて効果を見られる。
128Kや256Kを使えることと、常に最大まで使うべきことは別で、KVキャッシュが増える。
入力モードを増やすほど前処理とメモリの負担が増え、テスト範囲も広がる。
速度だけでなく、制約順守、回答の安定性、ログ、同じ条件での再測定を確認する。
オンデバイス検証では、短いテキスト会話、長文要約、画像や音声の順に段階を分けると判断しやすい。
QATの話は、メモリだけに閉じると誤解しやすくなります。Gemma 4は、モデルカード上でテキスト、画像、動画、音声、thinking、function calling、長文コンテキスト、MTPなどの機能が説明されています。使う機能が増えるほど、メモリ、遅延、テスト範囲も増えます。
MTPは速さの可能性と実装条件を分けて読む
Gemma 4 overviewでは、E2B、E4B、12B、26B A4B、31BにMulti-Token Prediction、つまりMTP用のdraft modelがあると説明されています。QAT Q4_0コレクションにもassistant系のモデルが並ぶため、速度検証の候補になります。
ただし、MTPは主モデルだけで成立するものではありません。対応するdraft model、ランタイム側の実装、量子化後の組み合わせ、プロンプトの性質がそろって初めて効果を見られます。「MTPがあるから必ず高速」とは読まず、次のように分けて確認します。
実装条件
| 確認項目 | 見る理由 |
|---|---|
| 主モデルとassistantの組み合わせ | 対応しない組み合わせでは期待通り動かない可能性がある |
| ランタイムのMTP対応 | モデルがあっても実行側が対応していないと使えない |
| 短文と長文の差 | 生成長やプロンプト長によって速度差が変わる |
| 品質変化 | 速度だけでなく、制約順守や回答の安定性を見る |
| ログと再現性 | チーム検証では同じ条件で再測定できる必要がある |
画像、音声、動画、長文はメモリ見積もりを変える
Gemma 4 model cardでは、E2B、E4B、12Bがテキスト、画像、音声に対応し、31Bや26B A4Bはテキストと画像を中心に扱うことが示されています。また、小型モデルは128K、12B/26B A4B/31Bは256Kのコンテキスト長が説明されています。
ただし、長いコンテキストを使えることと、常に最大まで使うべきことは違います。長文にするとKVキャッシュが増え、画像や音声を足すと入力処理の負荷も増えます。オンデバイスで使うなら、まず短いテキスト会話、次に長文要約、最後に画像や音声を加えるくらいの段階検証が向いています。
| 用途 | 増えやすいコスト | 最初に見ること |
|---|---|---|
| 短いテキスト会話 | 生成速度、履歴管理 | 初回応答、tokens/sec、履歴削除 |
| 長文要約 | KVキャッシュ、入力長 | メモリピーク、失敗時の再試行 |
| 画像OCR | 画像処理、入力トークン | 画像サイズ、OCR品質、個人情報 |
| 音声入力 | エンコーダー、前処理 | 音声長、端末負荷、遅延 |
| MTP併用 | 主モデルとdraft model | 組み合わせ、対応ランタイム、品質差 |
モバイル導入で見る端末条件と切り捨てる機能
- 1テキストのみから始める
E2B/E4BのMobile形式を候補にし、短い会話と控えめな履歴で検証する。
- 2応答長を抑える
長い出力や長い履歴を避け、遅延、メモリピーク、クラッシュの有無を先に見る。
- 3必要な入力だけ残す
画像、音声、動画は用途に必要なものだけを加え、不要なエンコーダーは外す前提で考える。
- 4端末ログを取る
発熱、バッテリー、推論時間、メモリ、クラッシュを同じ条件で記録する。
- 5更新手順を決める
モデルファイルの配布サイズ、古い端末の扱い、ロールバック、禁止用途対応を確認する。
プライバシーやオフライン性は強みになる一方、端末差、発熱、配布、回収は運用コストとして残る。
Gemma 4 QATのいちばん大きな意味は、オンデバイスAIの検証が現実に近づくことです。ただし、端末内実行は「プライバシーに良い」だけで判断すると危ういです。ユーザー体験としては、速いこと、熱くなりすぎないこと、バッテリーを食いすぎないこと、モデル更新を配れることも同じくらい重要です。
Mobile形式はE2B/E4Bを中心に見る
Google公式のGemma 4 QAT Mobileコレクションでは、E2B/E4Bのmobile-transformersとmobile-ctが中心です。12B、26B A4B、31Bまでモバイル端末にそのまま載せる話ではありません。
端末内で動かす候補として見るなら、E2B/E4Bで次の順に削るのが現実的です。
| 判断項目 | まず取る選択 |
|---|---|
| 入力モード | テキストのみから始める |
| 応答長 | 短い応答で検証する |
| コンテキスト | 長い履歴を持たせすぎない |
| モダリティ | 画像、音声、動画を必要なものだけにする |
| 実行場所 | 検証端末と本番端末を分ける |
| ログ | メモリ、遅延、発熱、クラッシュを記録する |
Google Blogの説明では、必要ない音声や視覚エンコーダーを外すことで、さらにメモリフットプリントを最適化できるとされています。これは、オンデバイスAIの設計で「何を入れるか」より「何を入れないか」が重要になることを示しています。
端末内実行の価値はプライバシーだけで判断しない
オンデバイスAIの価値には、プライバシー、オフライン性、低遅延、クラウド費用の抑制があります。一方で、モデル更新、端末差、バッテリー、発熱、不具合時の回収、禁止用途対応は運用コストになります。
本番候補にする前に、少なくとも次のチェックを置きたいところです。
- 端末メモリに余裕があるか
- 連続利用で発熱とバッテリーが許容できるか
- モデルファイルの配布サイズをユーザーが受け入れられるか
- 古い端末や低メモリ端末をどう扱うか
- 個人情報や機密情報を端末ログに残さないか
- 禁止用途や高リスク用途をどう制御するか
- モデル更新とロールバックをどう配るか
GoogleのGemma関連ページには、Apache 2.0、Gemma 4 license、Prohibited Use Policyなどの参照先があります。法務判断は各組織で行うべきですが、少なくとも利用前に公式条件を確認する導線はチーム内に置くべきです。
導入判断を3段階に分ける
医療、法律、金融など高リスク用途では単純な勝敗ではなく、規約、監査、品質保証の条件差を先に確認する。
Gemma 4 QATは、ローカルLLMを試す人にはかなり魅力的な更新です。一方で、プロダクトに組み込む場合は、モデルが小さくなったことだけで導入判断を終わらせない方がいいです。
いますぐ試してよい読者
個人の検証、研究、ローカルLLMの比較、短いテキスト会話、既存ツールでの動作確認なら、Gemma 4 QATは早めに触る価値があります。Q4_0 GGUFを使って、E2B/E4B/12Bの違いを手元で見られるためです。
この段階では、次のように割り切ります。
- 本番データを入れない
- ユーザー向け機能に直結させない
- tokens/secだけで順位を決めない
- チャットテンプレートとMTP対応を確認する
- 公式コレクションの更新を再確認する
検証してから使う読者
社内PoCや限定ユーザー向けの機能に使うなら、メモリ、速度、品質、利用条件のゲートを置きます。
| ゲート | 見る内容 |
|---|---|
| 形式 | GGUF、CT、Mobile、unquantizedのどれを使うか |
| メモリ | ベース重み、KVキャッシュ、長文時のピーク |
| ランタイム | llama.cpp、LiteRT-LM、vLLM、SGLangなどの対応 |
| 品質 | 制約順守、専門用語、長文、画像/音声の安定性 |
| 運用 | モデル更新、ログ、ロールバック、禁止用途対応 |
クラウドとローカルを併用するチームは、Vertex AI生成AI SDKの移行期限も合わせて読むと、Gemini API、Vertex AI、ローカルGemmaの役割分担を考えやすくなります。
まだ待つ、またはクラウド併用にする読者
長文、マルチモーダル、監査、再現性、チーム配布、法務確認が重い用途では、ローカル単独に寄せすぎない方が安全です。端末スペックが足りない場合や、ユーザー環境のばらつきが大きい場合も、まずはクラウド側で品質とログを固める方が現実的です。
Gemma 4 QATは、オンデバイスAIの入口を広げる更新です。ただし、どの読者にも同じ答えを出す更新ではありません。小さくなったから使うのではなく、用途から形式とランタイムを選び、最後にメモリと運用を合わせる。この順番で読むのが、今回の発表のいちばん実用的な受け止め方です。
次に読むなら
参照した主な情報源
- Google Blog, "Gemma 4 QAT models: Optimizing model compression for mobile and laptop efficiency"
https://blog.google/innovation-and-ai/technology/developers-tools/quantization-aware-training-gemma-4/
- Google AI for Developers, "Gemma 4 model overview"
https://ai.google.dev/gemma/docs/core
- Google AI for Developers, "Gemma 4 model card"
https://ai.google.dev/gemma/docs/core/model_card_4
- Hugging Face, Google collection, "Gemma 4 QAT Q4_0"
https://huggingface.co/collections/google/gemma-4-qat-q4-0
- Hugging Face, Google collection, "Gemma 4 QAT Mobile"
https://huggingface.co/collections/google/gemma-4-qat-mobile
- Google AI for Developers, "Apache License 2.0"
https://ai.google.dev/gemma/apache_2
- Google AI for Developers, "Gemma Terms of Use"
https://ai.google.dev/gemma/terms
- Google AI for Developers, "Gemma Prohibited Use Policy"
https://ai.google.dev/gemma/prohibited_use_policy