Gemma 3 270Mは、Googleが2025年8月14日に公開したオープンモデルGemma 3の最小サイズです。2億7,000万パラメータのうち1億7,000万を語彙の埋め込みに割いた変則的な構成で、Googleは最初から「特定タスク向けにファインチューニングして使う土台」と位置づけています。この記事では公式の仕様とベンチマークを押さえたうえで、日本語の抽出タスクをそのまま解かせた結果、48件で学習させた結果、Ollamaでの生成速度とJSONスキーマ指定の効果、派生モデルFunctionGemmaにツールを渡した結果を当社で実測し、2026年11月時点で270Mを選ぶ条件を整理します。
まとめ:Gemma 3 270Mの要点と選ぶ条件
- 中身:総パラメータ約2.7億(埋め込み1.7億+Transformer本体1億)、語彙256K、入力コンテキスト32K、テキストのみ。学習は6兆トークン、知識は2024年8月まで。
- 実力:IT版のIFEvalは51.2で、Gemma 3 1B IT(80.2)とは大きな差があります。事前学習版(PT)のTriviaQAは15.4で、モデル内の知識だけに頼る用途には向きません。
- 速度:Ollamaの
gemma3:270m(Q8_0・292MB)は、2019年発売のノートPC向けCPU(Core i9-9880H)だけで毎秒22〜30トークンを生成しました。QAT版(241MB)は毎秒27〜32トークンです。 - 日本語:「15万9900円」「4万9980円」のような万を含む価格を取り違えます。JSONスキーマを指定すると出力形式は揃いますが、数値の誤りは直りませんでした(当社実測)。
- 真価は学習後:48件の合成データで3エポックのフルファインチューニングをすると、価格抽出の正解が4問中2問から3問に増え、出力形式も揃いました(CPUで約16分)。それでも数値の検証は外せません。
- 2026年11月時点:Gemma 4に270Mサイズは無く、最小はE2Bです。関数呼び出しなら派生のFunctionGemmaを学習させて使い、汎用の小型モデルならGemma 4を先に検討します。
最新世代の一覧と必要スペックはGemma 4とは|モデル一覧・必要スペック(VRAM)・GGUF/QAT・MTPの使い方【2026年10月】にまとめています。以下では270Mに固有の話に絞ります。
Gemma 3 270Mの仕様:パラメータ内訳と語彙・コンテキスト
公式ブログの説明は「総270M、うち埋め込み170M、Transformerブロック100M」です。当社でモデルを読み込んでパラメータを数えたところ、総数268,098,176、埋め込み行列167,772,160(語彙262,144×隠れ次元640)、それ以外100,326,016で、公称値どおりでした。
| 項目 | 値 | 出典 |
|---|---|---|
| 公開日 | 2025年8月14日 | Google Developers Blog |
| 総パラメータ | 268,098,176(公称270M) | 当社実測 |
| 埋め込み/本体 | 167,772,160/100,326,016 | 当社実測 |
| 語彙サイズ | 262,144(公称256K) | config.json |
| 層数・隠れ次元 | 18層・640 | config.json |
| アテンション | 4ヘッド・KV 1ヘッド・スライディング窓512 | config.json |
| 入力コンテキスト | 32Kトークン | モデルカード |
| 入力モダリティ | テキストのみ | モデルカード |
| 学習トークン数 | 6兆 | モデルカード |
| 知識カットオフ | 2024年8月 | モデルカード |
| 配布形態 | 事前学習版(PT)と指示調整版(IT) | Hugging Face |
パラメータの6割強が埋め込みなので、「270Mの言語モデル」というより「大きな辞書に1億パラメータの頭脳が付いたモデル」と捉えるほうが実態に近いです。Googleは大きな語彙の利点を「専門用語や珍しいトークンを扱えるため、特定ドメインや言語向けに追加学習する土台になる」と説明しています。日本語の「Gemma 3 270Mは小型モデルです。」は15トークンに収まりました。
Gemma 3のうち画像入力に対応するのは4B以上だけで、270Mと1Bはテキスト専用です。コンテキストも4B以上の128Kに対して32Kです。学習トークン数は1B(2兆)より270M(6兆)のほうが多く、小さい分を学習量で補う設計になっています。
Gemma(ジェマ)とGeminiの違い・Gemma 3シリーズでの位置づけ
Gemmaの読み方
当社が確認したGoogleの日本語ブログとドキュメントは「Gemma」と英字で表記しており、公式のカナ表記は見当たりません。一般には英語の人名Gemmaの発音に沿って「ジェマ」と読まれています。初代Gemmaの発表では、名前の由来をラテン語で「宝石」を意味するgemmaと説明していました。
Geminiとの違い
GeminiはGoogleがAPIやアプリで提供する非公開のモデルで、重みは配布されません。Gemmaは「Geminiと同じ研究と技術から作った」とGoogleが説明するオープンモデルで、重みをダウンロードして自分のPCやサーバー、スマートフォンで動かせます。データを端末内で処理したい場合や外部APIの従量料金を避けたい場合はGemmaが候補です。ただし計算資源や運用の費用はかかり、Geminiとの性能差も対象タスクで比較して選びます。
Gemma 3の5サイズの中での位置
Gemma 3は2025年3月に1B・4B・12B・27Bで公開され、8月に270Mが加わって5サイズになりました。
| サイズ | 入力コンテキスト | 画像入力 | 学習トークン |
|---|---|---|---|
| 270M | 32K | なし | 6兆 |
| 1B | 32K | なし | 2兆 |
| 4B | 128K | あり | 4兆 |
| 12B | 128K | あり | 12兆 |
| 27B | 128K | あり | 14兆 |
1世代前の構成やライセンスの変遷はGemma 2とは|2B・9B・27Bの仕様・ライセンス・日本語版と2026年に選ぶかの判断で扱っています。
ベンチマーク:モデルカードの数値とIFEval 51.2の読み方
公式ブログが強調するのは、検証可能な指示にどれだけ従えるかを測るIFEvalで「このサイズとして新しい水準」を示したという点です。ただし比較の相手は同じ規模の小型モデルであり、1つ上のGemma 3 1Bと並べると差ははっきりします。事前学習版(PT)は、Hugging Faceのモデルカードで同じn-shot条件の値が並ぶので直接比べられます。
| ベンチマーク | n-shot | PT 270M | PT 1B |
|---|---|---|---|
| HellaSwag | 10 | 40.9 | 62.3 |
| BoolQ | 0 | 61.4 | 63.2 |
| PIQA | 0 | 67.7 | 73.8 |
| TriviaQA | 5 | 15.4 | 39.8 |
| ARC-c | 25 | 29.0 | 38.4 |
| ARC-e | 0 | 57.7 | 73.0 |
| WinoGrande | 5 | 52.0 | 58.2 |
指示調整版(IT)の270Mは、IFEvalが51.2、BIG-Bench Hard(few-shot)が26.7です。1B ITのIFEvalは80.2なので、指示追従でも約29ポイントの開きがあります。なお270M ITのHellaSwagやARC-cは0-shotで測られており、上のPT版の表とはモデルの調整状態と評価条件が異なるため、数値を直接比較できません。
読み取るべきは、TriviaQAが15.4にとどまる点です。事実知識を引き出す力が弱く、質問に答えるチャットボットの中核には使えません。Googleも「複雑な会話用途向けではない」と明記しています。一方でBoolQ(はい・いいえの判定)は1Bとほぼ差がなく、入力を読んで決まった形で返すタスクなら小ささの割に戦えます。
日本語での実測:そのままのGemma 3 270Mが間違えること
公式のベンチマークは英語中心なので、日本語の典型タスクをIT版にそのまま与えました。条件はIntel Core i9-9880HのCPU、PyTorch 2.2.2・Transformers 4.53.3、fp32、貪欲デコードです(2026年10月7日・Hugging Faceの非gatedミラーunsloth/gemma-3-270m-itを使用)。
| 入力(要旨) | 出力 | 判定 |
|---|---|---|
| 英文から商品名と価格をJSON抽出 | name: The Pixel 9 Pro/price: 999 | 概ね正しい |
| 「Pixel 9 Proは15万9900円です。」をJSON抽出 | price: 15000000 | 誤り |
| 英語レビューの感情を1語で分類 | Negative | 正しい |
| 日本の首都を一文で | 東京 | 正しい |
| 東京タワーの高さ | 1,028メートル | 誤り(実際は333m) |
短い分類や英語の抽出は指示どおりに返す一方、日本語の「万」を含む数値変換と事実知識で崩れました。どちらもベンチマークの傾向(指示追従は中程度、知識は弱い)と一致します。この非量子化・fp32の実行では生成が毎秒4〜5トークン、プロセスの最大メモリが約2GBでした。量子化版をOllamaで動かしたときの速度は、後述の使い方の章で測っています。
270Mを「そのまま使う日本語アシスタント」として評価すると失敗します。使い道は、出力の形が決まった分類・抽出を自前のデータで学習させることです。
ファインチューニングの効果:日本語の価格抽出を48件で学習した結果
CPUでのフルファインチューニング実測
前章で失敗した価格抽出を、合成データ48件で学習させました。文例は「〇〇は2万4980円です。」のような3つの型で、正解を {“name”: …, “price”: 整数} のJSONにしています。テスト文は学習データに含めていません。
| テスト文 | 学習前のprice | 学習後のprice |
|---|---|---|
| Pixel 9 Proは15万9900円です。 | 150000000(誤り) | 15900(誤り) |
| 新発売の電子書籍リーダー、価格は2万4980円(税込)。 | 24980 | 24980 |
| コーヒーメーカーを8900円で購入した。 | 8900 | 8900 |
| ゲーム機を4万9980円で購入した。 | 49990(誤り) | 49980 |
正解は4問中2問から3問に増えました。数値以外の変化も大きく、学習前はJSONをコードフェンスで囲んだり、商品名に「新発売の」を含めたりしていましたが、学習後は素のJSONに揃い、商品名も「電子書籍リーダー」だけを返しました。一方で「15万9900円」は15900と「万」を落としたままです。前章と比べてプロンプトに「priceは円単位の整数」を足しているため、学習前の誤り方も前章(15000000)とは違います。学習は3エポックでCPU約16分(970秒)、プロセスの最大メモリは約5.6GBでした。
学習データ48件の価格はすべて100円単位で、件数だけでなく数値パターンの偏りも誤りの原因になり得ます。本番に出す前に、「〇万〇〇〇〇円」などのパターンを網羅した数百件規模のデータを用意し、学習に使っていない検証セットで正解率を測ります。なおTransformersは学習時に「Gemma 3はsdpaでなくeagerのアテンション実装で学習することを強く推奨」と警告を出すので、本格的に学習するときは attn_implementation="eager" を指定します。
以下は学習ループの抜粋で、単独では実行できません。torchのインポート、modelとtokの読み込み、trainへの(入力文, 正解JSON文字列)のペアの格納が必要です。プロンプト部分のラベルは -100 とし、回答部分だけで損失を計算します。
PROMPT = "次の文から商品名と価格をJSONで抽出してください。キーはnameとprice。priceは円単位の整数。「{}」"
def enc(sentence, answer_json):
prompt = tok.apply_chat_template(
[{"role": "user", "content": PROMPT.format(sentence)}],
add_generation_prompt=True, tokenize=False)
full = prompt + answer_json + "<end_of_turn>\n"
p_ids = tok(prompt, add_special_tokens=False)["input_ids"]
f_ids = tok(full, add_special_tokens=False)["input_ids"]
labels = [-100] * len(p_ids) + f_ids[len(p_ids):]
return torch.tensor([f_ids]), torch.tensor([labels])
opt = torch.optim.AdamW(model.parameters(), lr=5e-5)
model.train()
for epoch in range(3):
for sentence, answer_json in train:
x, y = enc(sentence, answer_json)
loss = model(input_ids=x, labels=y).loss
loss.backward(); opt.step(); opt.zero_grad()
公式の学習レシピとツール
Googleのドキュメントには、Hugging Face TransformersとTRLのSFTTrainerで270Mをフルファインチューニングするガイドがあります。前提はGoogle ColabのNVIDIA T4(16GB)で、学習率5e-5・5エポックの設定例です。より少ないメモリで済ませたい場合は、2025年10月8日の公式ブログが、QLoRAなら無料のT4で数分で学習できると紹介しています。QLoRAの仕組みと設定はQLoRAとは?4bit量子化+LoRAの仕組み・VRAM目安・実装手順と採用判断を解説【2026年版】、学習を速く回すツールはUnslothとは?読み方とDesktopの使い方、Studio・Coreとの違い【2026年10月】を参照してください。
同じブログでは、テキストを絵文字に変換するモデルを学習し、量子化してメモリ300MB未満でブラウザ上に載せるまでを1時間以内の手順として示しています。学習済みモデルの配布先は、MediaPipe LLM Inference API向けのLiteRT形式か、Transformers.js向けのONNX形式です。業務データで分類・抽出モデルを作り、社内システムへ組み込むところまで進める場合は、当社の生成AI導入支援でも学習データの設計から検証まで支援しています。
Gemma 3 270Mの使い方:Ollama・Transformers・スマートフォンで動かす手順
Ollamaで動かす:配布タグと生成速度の実測
最も手軽なのはOllamaです。Hugging Faceのような同意手続きなしに取得できます。
ollama run gemma3:270m
配布タグと、当社のIntel Core i9-9880H(GPUは使わずCPUのみ)で測った生成速度は次のとおりです。Ollama v0.40.15で英文の短い作文を3回ずつ生成し、APIが返す eval_count と eval_duration から計算しました。2026年11月7日の早朝と、その約2時間後に同じ条件で2回測った値の範囲です。
| タグ | サイズ | 中身 | 生成速度(CPU) |
|---|---|---|---|
| gemma3:270m | 292MB | IT版・Q8_0 | 毎秒22〜30トークン |
| gemma3:270m-it-qat | 241MB | 量子化考慮学習(QAT)版 | 毎秒27〜32トークン |
| gemma3:270m-it-q8_0 | 292MB | Q8_0 | (270mと同じ中身) |
| gemma3:270m-it-fp16/bf16 | 543MB | 非量子化 | 未測定 |
初回の読み込みは2〜3秒で、プロンプトの処理は毎秒190〜420トークンでした。同じマシンで別の処理が動いていると1〜2割ぶれるため、速度は桁の目安として読んでください。Transformersのfp32(毎秒4〜5トークン)とはプロンプトや実行基盤が異なるため、厳密な速度倍率は比較できません。抽出リクエスト全体の応答時間は今回のログには記録しておらず、生成速度とは別に測定が必要です。モデルの用途は変わらず、汎用チャットの候補には入りません。会話や要約を試すならGemma 4のE2B以上を選び、270Mは分類・抽出・ルーティングを自前データで学習させる前提で入れます。Ollamaでローカル環境を組む全体の流れはローカルLLMとは?クラウド型との違い・必要スペック・Ollamaでの構築手順を解説にあります。
Ollama APIのJSONスキーマ指定と抽出精度
抽出タスクでは、Ollamaの format にJSONスキーマを渡すと、出力をその形に制約できます。当社の測定で使ったリクエストは次の形です。
curl http://localhost:11434/api/chat -d '{
"model": "gemma3:270m-it-qat",
"messages": [{"role": "user", "content": "次の文から商品名と価格をJSONで抽出してください。キーはnameとprice。priceは円単位の整数。「イヤホンは3,980円です。」"}],
"format": {"type": "object", "properties": {"name": {"type": "string"}, "price": {"type": "integer"}}, "required": ["name", "price"]},
"stream": false,
"options": {"temperature": 0, "seed": 1}
}'
6つの日本語の文で、スキーマの有無とモデルの版を変えて価格の正解を数えました。
| テスト文の価格 | Q8_0 | Q8_0+スキーマ | QAT | QAT+スキーマ |
|---|---|---|---|---|
| 15万9900円 | 150000000 | 15000000 | 159900 | 159900 |
| 2万4980円 | 24980 | 24980 | 24980 | 24980 |
| 8900円 | 8900 | 8900 | 8900 | 8900 |
| 4万9980円 | 49990 | 49990 | 49990 | 49990 |
| 12万8000円 | 1208000 | 1208000 | 128000 | 120000 |
| 3,980円 | 3980 | 3980 | 3980 | 3980 |
| 正解数 | 3/6 | 3/6 | 5/6 | 4/6 |
スキーマ指定によって全問で揃ったのは出力形式です。指定しないとQ8_0もQAT版も全問で “`json のコードフェンス付きで返しましたが、指定すると素のJSONになり、パースの前処理が要らなくなりました。数値の誤りは直らず、QAT版では「12万8000円」がスキーマ指定時だけ120000に変わっています。スキーマは形式の保証であって、中身の正しさの保証ではありません。
QAT版が6問中5問とQ8_0版を上回ったのは意外でしたが、6問での差なので「QATのほうが日本語の数値に強い」とまでは言えません。容量と速度で選ぶならQAT版、どちらにするかは自分のデータで決めます。どちらでも「4万9980円」は49990と誤ったため、価格のような数値は正規表現などで元の文と突き合わせる検証を後段に置きます。
Hugging Face Transformersでの認証と推論コード
公式リポジトリは事前学習版が google/gemma-3-270m、指示調整版が google/gemma-3-270m-it です。どちらもgatedリポジトリで、モデルページでGemmaの利用規約に同意し、アクセストークンを設定してから取得します。次のコードは当社の実測で使ったものと同じ手順です。
import torch
from transformers import AutoTokenizer, AutoModelForCausalLM
model_id = "google/gemma-3-270m-it"
tok = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(model_id, torch_dtype=torch.float32)
messages = [{"role": "user", "content": "Classify the sentiment as positive or negative: 'The battery died after two hours.'"}]
ids = tok.apply_chat_template(messages, add_generation_prompt=True, return_tensors="pt")
out = model.generate(ids, max_new_tokens=32, do_sample=False)
print(tok.decode(out[0][ids.shape[1]:], skip_special_tokens=True))
INT4で動かす前提なら、量子化考慮学習済みの google/gemma-3-270m-it-qat-q4_0-unquantized(事前学習版は google/gemma-3-270m-qat-q4_0-unquantized)から始めると、量子化による劣化を抑えられます。GGUFなど量子化形式の違いはGGUFとは?量子化モデルフォーマットの仕組みとGPTQ・AWQとの違い・採用判断を解説【2026年版】で解説しています。
スマートフォン・ブラウザ向けの配布ファイルと消費電力
端末に載せる場合は、Googleの変換済みリポジトリ litert-community/gemma-3-270m-it から始めます。2026年11月時点で、LiteRT-LM用の .litertlm(Q8の汎用版と、Qualcomm SM8550/SM8650/SM8750/SM8850、MediaTek MT6991/MT6993向けのSoC別ファイル)と、ブラウザ用の .task(q4_0とq8)が置かれています。AndroidではGoogle AI Edge Galleryアプリで試せ、iOSとWebはMediaPipe LLM Inferenceのサンプルが案内の対象です。ただし同リポジトリには、AndroidでのGPU実行は準備中と書かれています。LiteRTへの改称と変換の流れはTensorFlow Lite(LiteRT)とは?改称後の位置づけ・モデル変換・NPU実行を実装目線で解説で扱いました。
消費電力については、Pixel 9 ProのSoC上でINT4量子化した270Mが25回の会話でバッテリーの0.75%しか消費しなかったと、Googleが社内テストの結果を公表しています。会話の長さなどの測定条件は公開されていないため、自社アプリの見積もりには使えない数字です。
FunctionGemma・Gemma 4・EmbeddingGemma 2との違いと選び方
270Mの公開後、Googleはこのサイズを土台にした派生モデルを出す一方、次の世代であるGemma 4には270Mを用意しませんでした。2026年11月時点の関係は次のとおりです。
| モデル | 公開 | 規模 | 役割 | ライセンス |
|---|---|---|---|---|
| Gemma 3 270M | 2025-08-14 | 約2.7億 | 汎用の小型テキストモデル | Gemma Terms of Use |
| FunctionGemma | 2025-12-18 | 270M | 270Mを関数呼び出し向けに調整 | Gemma Terms of Use |
| T5Gemma 2 270M-270M | 2025-12-18 | 約785M(画像部込み) | 埋め込み共有のエンコーダー・デコーダー型 | Gemma Terms of Use |
| Gemma 4 | 2026-03-31〜 | E2B〜31B | 次世代の汎用モデル(270M無し) | Apache 2.0 |
| EmbeddingGemma 2 | 2026-10-06 | 総計740M | 埋め込み(Gemma 4系) | Apache 2.0 |
Gemma 4は2026年3月31日にE2B・E4B・26B A4B・31Bで公開され、6月3日に12Bが加わりました。最小のE2Bでも270Mよりはるかに大きく、画像入力にも対応します。「gemma4 270m」で探しても該当モデルはありません。Google以外では、Microsoftの埋め込みモデル harrier-oss-v1-270m がconfig.json上でGemma3TextModelの構成をとっており、270Mの骨格は埋め込み用途にも使われています(Microsoft Harrierとは?harrier-oss-v1の27b・0.6b・270mの違いと使い方)。
FunctionGemmaをOllamaで呼んだ結果
FunctionGemmaは「Gemma 3 270Mが出てから開発者の要望が最も多かったのが関数呼び出し」として公開されたモデルで、チャット形式が専用です。モデルカードは「直接の対話モデルとしての使用を意図していない」「追加のファインチューニング後に高い性能を発揮するよう設計」と明記しています。Androidの操作(カレンダー登録やライト点灯など)を関数呼び出しに変換するMobile Actionsの評価では、学習前58%が学習後85%に上がりました。
学習前の状態を確かめるため、Ollamaの functiongemma:270m(301MB)に、予定登録・ライト点灯・天気取得の3関数を tools で渡し、7つの依頼を送りました(temperature 0)。同じリクエストを gemma3:270m に送ると、HTTP 400で「does not support tools」と返されます。Ollamaでツールを渡せるのはFunctionGemmaのほうだけです。
| 依頼 | 返った関数呼び出し |
|---|---|
| Turn on the flashlight. | なし(空の応答) |
| What’s the weather in Osaka? | なし(空の応答) |
| Add a meeting called Design Review on 2026-11-20 at 15:00. | create_calendar_event(date: 2026、time: 15) |
| ライトをつけて | なし(空の応答) |
| 大阪の天気を教えて | なし(天気には答えられない旨の英文) |
| 2026年11月20日15時にデザインレビューの予定を入れて | create_calendar_event(date: 2026、time: 15) |
| こんにちは | なし(予定管理はできない旨の英文) |
関数が選ばれたのは7件中2件だけで、その2件も日付が「2026」、時刻が「15」という整数に化け、スキーマの「YYYY-MM-DD」を守っていません。ライト点灯のような引数の無い関数は英語でも呼ばれませんでした。この結果は、公式が必須とする関数呼び出し用のdeveloper指示文をリクエストに含めなかったOllama環境での観測です。指示文をsystemメッセージとして追加した別試験もHTTP 500で中断しており、モデル本体の能力と入力形式・ランタイムの影響は切り分けられていません。アプリ操作のエージェントに使うなら、Googleが公開しているMobile Actionsのデータセットと学習レシピに沿って、自社の関数で学習させてから評価します。
2026年11月時点でGemma 3 270Mを選ぶ条件
選ぶのは、分類・抽出・ルーティングのように出力の形が決まったタスクがあり、数十〜数百件の学習データを用意でき、300MB前後に収めて端末内やブラウザで動かしたい場合です。モデル規模はGemma 4より小さいものの、学習・推論費用は必要な精度、学習回数、処理件数を揃えて比較します。CPUだけのサーバーで大量の短文を処理する場合は、今回の単一リクエストの生成速度に加え、同時実行時の処理件数と待ち時間を測って採否を判断します。
逆に、学習データを用意せずにそのまま使いたい場合、日本語の自由な質問に答えさせたい場合、画像を扱う場合は選ぶべきではありません。前述の実測のとおり事実を誤り、数値を取り違えます。その用途にはGemma 4のE2B/E4Bを使います。ライセンスの扱いを単純にしたい場合も、Apache 2.0のGemma 4が有利です。小型モデル全般の採用判断はSLMとは?小規模言語モデルの仕組み・LLMとの違いと実装判断を解説で比較しています。
ライセンス:Gemma Terms of Useで商用利用するときの条件
Gemma 3 270MにはGemma Terms of Use(最終更新2026年4月1日)が適用されます。個人・企業とも無料で商用利用でき、生成した出力についてGoogleは権利を主張しません。ただしApache 2.0などのOSSライセンスとは別物で、次の制約があります。
- 禁止用途ポリシー(Gemma Prohibited Use Policy)に反する使い方はできず、Googleは違反と合理的に判断した利用を制限できる。
- モデルや派生モデル(ファインチューニング後の重みを含む)を第三者に配布する場合は、利用制限条項を契約に組み込み、規約のコピーを渡し、改変したファイルにはその旨を明示し、所定のNoticeファイルを添付する(APIなどのホステッドサービス経由の提供はNoticeファイルが不要)。
社内だけで使う場合は配布に当たりませんが、規約の定義では第三者へのAPI提供も「配布」に含まれ、利用制限条項の組み込みや規約コピーの提供が必要です(Noticeファイルだけは不要)。学習済みの重みを顧客に納品する場合は、Noticeファイルを含む4つの条件をすべて満たします。FunctionGemmaやT5Gemma 2も同じ規約です。重みの納品が前提の案件では、Apache 2.0のGemma 4を先に検討します。
よくある質問
Gemma 3 270Mは日本語に対応していますか?
日本語の入力も出力もできます。ただし当社の実測では、そのままでは「15万9900円」や「4万9980円」の価格を取り違え、事実を問う質問にも誤答しました。日本語の業務タスクでは対象データで精度を評価し、必要に応じて追加学習します。価格のような数値は、追加学習後も別途検証します。
Gemma 3 270Mのパラメータ数の内訳は?
公称は総270Mで、埋め込みが170M、Transformerブロックが100Mです。当社で数えた実数は総268,098,176、埋め込み167,772,160、それ以外100,326,016でした。
Gemma 4に270Mのモデルはありますか?
ありません。Gemma 4の公式サイズはE2B・E4B・12B・26B A4B・31Bの5種類で、最小はE2Bです。270Mクラスを使うならGemma 3 270Mか、その派生のFunctionGemmaになります。
Gemma 3 270MはGPUなしで動きますか?
動きます。当社のIntel Core i9-9880HのCPUだけで、Ollamaの gemma3:270m は毎秒22〜30トークン、QAT版は毎秒27〜32トークンで生成しました。Transformersでfp32のまま動かした別の測定では毎秒4〜5トークンだったので、CPUで使うなら量子化版から試します。
Gemma 3 270Mは商用利用できますか?
Gemma Terms of Useの範囲で商用利用できます。禁止用途ポリシーに従い、第三者への配布では利用制限の契約への組み込みと通知、規約コピーの提供、改変ファイルへの明示が必要です。API等のホステッドサービス以外の配布には、所定のNoticeファイルも必要です。