Google Gemma 3 270M: 超高効率AI向けのコンパクトモデルを公開
(developers.googleblog.com)- Gemma 3 270Mは2億7,000万パラメータの軽量モデルで、強力な指示追従能力とテキスト構造化機能を備える
- 256kトークンの大規模語彙セットにより、希少トークンの処理に強く、特定ドメインや言語に合わせたファインチューニング向けモデルとして設計
- Pixel 9 Pro SoCでは、INT4量子化モデルが25回の対話でバッテリー消費0.75%にとどまるなど、エネルギー効率に優れる
- 大規模な汎用モデルの代わりに小型の特化モデルを多数運用し、速度・コスト・精度をすべて確保する戦略に適合
- オンデバイス実行、高速な反復実験、低コスト運用が必要な定型業務に最適化され、多様なAIアプリケーションを構築可能
Gemma 3 270Mの概要
- GoogleがGemma 3およびGemma 3 QATに続いて新たに公開した小型特化ファインチューニング向けモデル
- 270Mパラメータのうち1億7,000万は埋め込み、1億はトランスフォーマーブロックに割り当て
- 256kトークンの大規模語彙により、希少・特殊トークンの処理が可能
- 事前学習済み（pretrained）版と指示チューニング済み（instruction-tuned）版の両方を提供
主な特徴
- コンパクトながら強力な構造: 特定ドメイン／言語向けのカスタムファインチューニングに最適
- 極めて高いエネルギー効率: Pixel 9 Pro SoCでINT4モデルが25回の対話時にバッテリーを0.75%しか使用しない
- 指示実行能力: 汎用会話よりもタスク中心に最適化され、初期状態でも指示実行が可能
- 量子化対応（QAT）: INT4精度で性能低下を最小限に抑え、リソース制約のある環境に適する
「適材適所」の哲学
- AI設計において効率性重視のアプローチを強調
- 小型モデルにより高速応答と低コスト運用が可能
- テキスト分類、データ抽出など明確なタスクに特化した場合に高い性能を発揮
実際の適用事例
- Adaptive MLはSK Telecomの多言語コンテンツモデレーション向けにGemma 3 4Bモデルをファインチューニングし、大規模な独自モデルを上回る性能を達成
- 270Mモデルはこのアプローチをさらに小規模に拡張し、特化作業群ごとに「専門モデル」を大量生成可能
- Hugging FaceのWebベースのBedtime Story Generatorアプリは、Gemma 3 270MによりオフラインまたはWebブラウザ内でリアルタイムのコンテンツ生成が可能
適した利用シナリオ
- 明確かつ大量のタスク処理: 感情分析、エンティティ抽出、クエリルーティング、テキスト変換、創作、コンプライアンス検査など、特定分野のタスクに最適
- 最高水準の経済性と速度: 軽量インフラまたはオンデバイスで極めて低コストに運用でき、即時応答を提供可能
- 高速な開発とデプロイ: モデルサイズが小さいため、ファインチューニング実験や最適化／テスト工程を数時間以内で進められる
- プライバシー保護: クラウドへ送信せずデバイス上で処理できるため、機密情報の保護に有利
- カスタム特化モデルの運用: 予算負担を抑えながら、目的別の多様なモデルを同時に構築・デプロイ可能
ファインチューニングとデプロイ
- Hugging Face、Ollama、Kaggle、LM Studio、Dockerなどからモデルをダウンロード可能
- Vertex AI、llama.cpp、Gemma.cpp、LiteRT、Keras、MLXなど多様な推論ツールをサポート
- Hugging Face、UnSloth、JAXベースの完全なファインチューニングガイドを提供
- ローカル環境からGoogle Cloud Runまで柔軟にデプロイ可能
結論
- Gemma 3 270Mは小さいながら強力な基盤モデルであり、特定タスクに最適化されたAIソリューション構築を加速
- 低コスト・高効率・高速デプロイを同時に求める開発者にとって理想的な選択肢
3件のコメント
.taskファイルにしてくれたら、Androidスマートフォンで思う存分試せるのに..誰かが作っておいた .task（non web）ファイルがあったので、モバイルで試してみたところ、簡潔で素早く、きちんと回答してくれます。
ただ、qwen3:0.6b のほうが（もちろんこちらのほうが重いでしょうが）より優秀な気がします。
Hacker Newsの意見
私は素晴らしいチームと一緒にこれらのモデルを作りました。オープンモデルのエコシステム全体でダウンロードできるので、ぜひ皆さんにも試してみてほしいです。私たちはモデルサイズに対して強力な性能を目指して設計し、誰でも用途に合わせて簡単にファインチューニングできるようにしました。小さなモデルサイズのおかげでさまざまなハードウェアで動作し、ファインチューニングのコストも非常に安価です。無料のColabで5分以内に自分でファインチューニングを試せます。Gemmaのサイズ選びのガイドとして、私が直接収録した1b〜27b、そして最近追加された270m版の紹介動画を参考にするとよいです YouTubeリンク。私はGoogleで研究者として働いていますが、ここでの意見はすべて個人的な見解です。技術的な質問を中心に、できるだけ多く共有するつもりです
Gemma 3モデルは本当に素晴らしいと思います。ノルウェー語の生成も悪くなく、インストラクションフォローもほとんどの場合は良好です。ただ、検閲に関係していそうな問題があり、とくに深刻な話題では指示と違って過度に保守的に振る舞います。たとえば、プレイヤー同士が殺し合えるゲームで、会話メッセージが実際の脅迫なのかゲーム内の脅しなのか分類するよう頼んでも、うまく機能しません。ゲーム内の脅しか不明なときはゲーム関連として分類するようにしても、安全寄りに偏る傾向があります。ヘルプラインを出してくることさえあります。モデルが安全に動作するよう訓練された影響だと思うのですが、理由をご存じなら知りたいです
BSidesSFで会った素晴らしいGoogleエンジニアを思い出しました。質問にとても誠実に答えてくれた方だったのですが、動画をクリックしたらまさにあなたでした！ とても刺激を受けた瞬間でした、ありがとう
ファインチューニング済みバージョンの実例があれば共有してもらえると嬉しいです。説明だけでも構いませんし、デモや、できればモデルウェイト（GGUF形式だとさらに嬉しいです）をダウンロードできるなら最高です
これは本当に素晴らしい仕事です。実際、270Mパラメータ級のモデルがこれほど効率的に出てくるのは珍しいです。アーキテクチャの選択も新しくて興味深いです。もし可能なら、もう少し詳しい学習情報を共有してもらえないでしょうか。埋め込みパラメータが170Mあるのに、学習中に埋め込み崩壊なしで埋め込み行列をどう安定して維持したのか気になります。パラメータ分割（170m/100m）に関する内部実験や性能トレードオフについて、さらに知れる資料があるのかも気になります。モデルシリーズ全体に感謝します
本当に印象的な仕事です。このモデルは要約や自動補完のような単発タスクでとても良いと感じます。リリース日にquantized aware training版まで公開したのも非常に良く、そのおかげでモデルがさらに小さくなりました
270M-F16モデルとの対話は印象的でした。「地球で2番目に高い山は？」と聞くと「エベレスト」と答え続けます。「では1番目は？」にも「エベレスト」と答えます。「3番目は？」「4番目は？」にもすべて「エベレスト」と答えます。「もう一番高い山はエベレストだと言ったよね」と言うと「そうです、嬉しいです」という反応を見せます。その後も2番目に高い山を尋ね続けても「エベレスト」と答えるだけでした。結局、「1〜5位の山のリスト」を求めたときにようやく、1. エベレスト、2. K2、3. Sahel、4. Fuji、5. McKinley と答えを変えました。「じゃあ2番目に高い山はK2だよね？」と聞いても、相変わらず「エベレスト」と答え続けます。こうした小型モデルは素晴らしいですが、本当に幼児と会話している気分です
このモデルは270M程度のパラメータで、1Bの3分の1ほどです。本質的には少しの行列積をしているだけなので、多くの知識、文法、一貫性を期待することはできません。こうした1B未満のモデルは、特定用途に最適化された特化型モデルです。たとえば、顧客レビューからJSONオブジェクトとして情報を抽出するなど、入力テキストをプログラムで意味のある形に変換する用途に向いています。こうしたモデルは、期待するデータに対してかなり積極的にファインチューニングしてやる必要があります。結局のところ、270MBのモデルがファインチューニングで望む結果を出せるなら、わざわざ32GBの汎用モデルを使う必要はありません
付け加えると、私たちはそもそも完璧な事実対応性を目標にはしていませんでした。モデルサイズに関係なく、この重みはすでに固定されています。おすすめしたいのは、RAGシステムとつないで外部知識に依存させるか、必要な事実だけを含めて自分でファインチューニングすることです。新しい知識もすぐに習得します
270Mモデルを百科事典的な知識テストに使うのは、強く圧縮されたJPGファイルを見て「画質が荒れてるね」と感想を言うようなものです
プロンプトを見る限り知識評価をしようとしているようですが、このモデルはその用途には向いていません。ブログ記事でも触れられていた通り、「テキスト分類やデータ抽出などにおいて、正確性、速度、コストの面で優れた性能を示す」です
「パリ2日旅行の旅程を作って」と頼んだときの返答として、パリの名所、ランドマーク、美術館巡り、多彩なグルメ体験、マレ地区やカルチェ・ラタンの散策、オルセー美術館訪問など、具体的な旅行日程を時間ごとに案内していました。旅行準備のヒントも丁寧に提供していました
このモデルは本当に面白いです。241MBほどと非常に小さくてとても速いのに、ほとんど何でも自由に「幻覚」で作り出します。たとえば「自転車に乗るペリカンのSVGを生成して」と頼むと、モデルは詩を書いてくれました（たとえば「これは猫、大きな翼と幸せな尻尾」「自転車のライトが明るく輝く」「冒険の準備ができている」など）。いくつかの試行結果を Gist に上げました。今後、選ばれたタスクに使える有用な成果物を出せるようにファインチューニングされたモデルが出てくることを期待しています
この試行 では大笑いしました。詩なのか歌なのか何かを生成したあと、それぞれの行がSVGにどう反映されるか説明して、最後に「このSVGコードは場面を明確かつ視覚的に伝えます」で締めくくっていました
ollamaのggufsを使っているのを見ました。デフォルトではQ4_0量子化モデルを取得しますが、
gemma3:270m-it-bf16を使うか、unsloth ggufsのhf.co/unsloth/gemma-3-270m-it-GGUF:16を使うと、より良い結果が得られます役に立たないトークンをたくさん生成することもありますが、本当にとんでもない量のトークンを吐き出します
241MBのダウンロードなら、フロッピーディスクが170枚以上必要です
「ユリウス・カエサルはいつ生まれましたか？」という質問に、「ユリウス・カエサルは ローマ で生まれました」と返ってきました。美しい :D（けなしたいのではなく、しつけるにはもっと努力が必要だという意味です）
Appleもこういうモデルをやるべきだと思います。もし検索契約をAI契約に置き換えることが目的でないのなら、Appleがこんなに存在感がないのはあまりに不思議です。Tim Cookは「私たちが取るべき機会だ」と言っていましたが、最近の動きを見ると方向を見失っているように感じます。Googleがんばれ
HNのすべてのLLMスレッドで出てくる話ですが、LLMはまだ馬鹿っぽくて役に立たないと言う人がいます。私はその意見には同意しませんが、これまでのところ、どの企業も長期的な投資価値が十分に証明されたAI活用法を見つけていないのは事実です。Appleはいつも市場参入が遅くても（例: MP3、スマートフォン、スマートウォッチ）、革新的な製品で競争を圧倒してきた実績があります
GPT2レベルのモデルはすでにAppleの自動補完で使われています 詳しい内容へのリンク
もし「こういう」モデルがSLM（小型言語モデル）を指すなら、Appleがかなり前から関連研究を進めてきたのは事実です
Appleもやっています。公式ドキュメントもあります Foundation Models Doc。最新ベータを入れれば自分でAPIを呼べます。さらに、ほぼすべてのデバイスに適用されるモデルについて、ファインチューニングも公式にサポートしています 関連ドキュメント
Appleはこういうモデルを出さないと思います。すでに他のコメントでもわかる通り、現時点では性能が足りません。実運用で妥当な速度でトークンを出しつつ、端末を過熱させず、でたらめを言わないモデルを見つけるのは本当に難しいです（実際にいくつも使ってみました）。Appleはいつも未完成あるいは完成度の低い製品を好まず、むしろ発売を遅らせます
私はDistilBERTを使ってwordpressの記事分類をしています。データは10万件以上あり、ファインチューニング後にレポートまで十分作れます。分布が偏っていても、工夫である程度は解決できます。今後このモデルに置き換えて性能を比較し、変化があれば共有するつもりです
ユーザーがこんなに小さなモデルを実際にファインチューニングして本番環境に適用した現実的な事例があるのか気になります
RAGシステム用のrerankerを小さなモデルで作った経験があります。候補生成（ベクトル検索+BM25）とビジネスロジック、ACLフィルタの後に残ったテキストチャンクが本当にクエリと関連しているかをtinyモデルで判定してフィルタリングしていました。実際に本番投入されましたが、モデルのコンテキストサイズが大きくなるにつれて、価格面と品質面の問題からそのモジュールは結局外されました。それでも、しばらくは運用されていたのは事実です
うちの会社では、小さなモデルで選別して、信頼度が高ければChatGPTで確認する方式でスケールさせています。この方法を言語検出にも適用してみるつもりです。既存のオープンソースMLモデルは、混在言語、文の長さ、特定ドメインに弱点があります（たとえば聖書翻訳だけで訓練されている場合など）
どこに使うかは曖昧ですが、タグ生成くらいには使えそうです。この程度のサイズのエンコーダは、他の特定タスクでむしろ大きく勝ることもあります
記憶が正しければ、Android（特にPixel）のオンデバイスアシスタントなどでfine-tuned Gemmaモデルが使われています
9gag.comのコメント用
最近はモデル最適化競争が激しいので、不要な言語やドメイン情報を取り除けばどれだけパラメータを減らせるのか気になっていました。たとえば英語だけをサポートするなら、中国語や欧州言語を削って同じパラメータ内でより多くのタスクをこなせるようにできるのか、という疑問です
この質問こそ、私たちがこのモデルを作るときに最も悩んだ部分です。「どれだけ多くのタスクを、どれだけうまくこなしたいのか」によってトレードオフが生じます。異なるデータ、異なるトレーニング戦略を選んで性能を測る必要があります。実際に自分のタスクセットでモデルを訓練して、性能のトレードオフを評価してみることを勧めます。こうした試みを通じて、LLMの能力変化を自分で実感できます
実際にはそこまで単純ではありません。transfer learning（転移学習）を見るとよいです
2025年に発表されたLLMを、自分のiPhoneで、BF16のフル精度で動かすことになるとは本当に思いませんでした。iPhone 16 Proで毎秒80トークンほど出ます
記事に補足すると、Gemma 3 270Mの正確なIFEvalスコアは51.2です。Qwen 3は散布図上で (0.6, 59.2) に位置しています
プロンプトの選び方がこのモデルの性能に非常に大きな影響を与える点は言及しておきます。NERやPOSタグ付けはやや期待外れでした。しかし、非インド・ヨーロッパ語の翻訳（たとえばタイ語やインドネシア語から英語への翻訳）は驚くほどよく機能しました