Ember-1 vs Gemma 4 12B：一方はより少ないトークンで借りられ、もう一方は重みを手渡してくれる

Ember-1とGemma 4 12Bは、発注書の同じ明細行を争っているわけではない。その理由を最速で知る方法は、毎月末に何を所有していることになるのかを問うことだ。Gemma 4 12Bは、Googleの11.95Bパラメータのdenseマルチモーダルモデルで、2026年6月3日にApache 2.0の下でリリースされた。ダウンロードすれば、チェックポイントはあなたのものだ。Ember-1は、Fireworks ResearchによるMoonshot AIのKimi K3の特化派生版で、2026年9月23日にベンダー自身のサーバーレスプラットフォーム上で研究プレビューとして公開された。呼び出せば、請求書以外に何も所有しない。一方はトークンに関するレント・トゥ・オウンの議論であり、もう一方は資本購入だ。両者を並べてみても、有用な比較はどちらのモデルが優れているかではない。公開されているものではそれを決着できないからだ。そうではなく、2つの調達形態のどちらが、あなたが構築しているものに合うかである。

二つの契約を、平易に述べると

Gemma 4 12B は完成したオープンウェイトのリリースです。Google は重み、アーキテクチャ、ベンチマーク表、ライセンスを公開しており、ランタイムのコミュニティ — llama.cpp、vLLM、MLX、SGLang、Transformers — が、あなたが管理するハードウェア上でそれを動作させます。購入後のトークンあたりのコストは電気代と償却費であり、ベンダーからの請求項目ではありません。あなたが犠牲にするものは、オープンウェイトが常に代償として伴うものです。キャパシティプランニングは自分で担うことになり、品質の上限は 11.95B パラメータに固定されます。

Ember-1はその逆です。ダウンロードすべき重みはなく、ベンダー自身のプラットフォーム上で提供されるオプションとして存在しており、公表された価格もありません。代わりに提供するのは、はるかに大規模なモデルの上に実装された、より限定的な主張です。Kimi K3の精度を、そこに到達するために消費するトークンを約40%削減して実現するというものです。Fireworks Researchは、回答を変えずに推論トレースを短縮することに特化してこれを訓練し、7つのベンチマークと2件の顧客本番A/Bテストにおいて、精度を損なわずに推論長を35～50%削減できたと報告しています。そこにあるすべての数値はベンダー報告であり、再現されていません。

トークンに関する議論がどれほどの価値を持つかは、トークンの代金を誰が払うかによって完全に決まる。

Ember-1のピッチは、トークン単位の課金を前提としている。その前提は、それが想定している対象にとって正しい——ホスト型のフロンティアモデルに対して長いエージェントループを回すチームにとってだ。Fireworks Researchが指摘するように、Kimi K3は生成トークンの90%以上を内部推論に費やしうるし、各ターンが以前のターンを再生するため、以前の推論が再読され、再課金される。その状況では、トレース長を削ることは月次請求額を直接削ることになり、29.9Kの出力トークン対K3の49.3KというA/B結果こそが重要な数字だ。

同じモデルをGemma 4 12Bの条件で動かすと、その議論は成立しなくなる。Apache-2.0チェックポイントをセルフホストする場合、追加の推論トークンが消費するのは100万トークンあたりのドルではなく、実時間とGPU占有率だ。自分の16GBラップトップ上で冗長な推論トレースを出すことは、より大きな請求ではなく、より遅い回答を意味する。とはいえ、それで非効率が無害になるわけではない——エージェントループでは依然として積み重なり、依然としてレイテンシーとして現れる——が、為替レートは異なる。セルフホストのハードウェア上で40%のトークン削減を40%の節約として扱うのは、カテゴリー錯誤だ。

仕様書、寸法ごとに1行

• 概要 — Ember-1：Kimi K3の研究プレビュー版派生モデルで、より短い推論向けに再トレーニングされたもの。Gemma 4 12B：Goog​leのGemma 4ファミリーの、密な11.95Bオープンウェイト・マルチモーダルモデル。

• 重み — Ember-1: 公開されているものはなし。ベンダーのプラットフォーム経由でのみ提供。Gemma 4 12B: Apache 2.0、ダウンロード可能、ゲートなし。

• サイズ — Ember-1: 非公開。Kimi K3 のアーキテクチャから継承。Gemma 4 12B: 11.95B のデンス、48 層、BF16 で重みはおよそ 18GB。

• コンテキストウィンドウ — Ember-1: プレビュー版では未公開。ベースモデルは1,048,576トークンを搭載。Gemma 4 12B: 256Kトークン。

• 入力 — Ember-1: テキスト。Gemma 4 12B: エンコーダー不要の統合設計によるテキスト、画像、音声。一部の情報源では動画も記載。

• 価格 — Ember-1：公開なし。ベンチマークシートのドル額はKimi K3の料金表から算出。Gemma 4 12B：ダウンロードは無料。ハードウェア費用は自己負担。

• ハードウェアの最低ライン — Ember-1：ベンダーが予定する内容次第。Gemma 4 12B：Googleの位置づけによれば、VRAMまたはユニファイドメモリを16GB。

• 根拠 — Ember-1: ベンダーのベンチマークと、ベンダーが実施した2件のA/Bテスト（未再現）。Gemma 4 12B: Goog​leが報告した評価に加え、独立したローカル実行のエコシステム。

Gemma 4 12Bが公開するもの、そしてそれが読み取る方法

Google自身の数値では、Gemma 4 12Bはエッジ向けサイズのGemma 4 E4Bと、より大型の26B MoEの中間に位置づけられている。GPQA Diamond 78.8%、MMLU Pro 77.2%、ツールなしのAIME 2026 77.5%、LiveCodeBench v6 72.0、Codeforces ELO 1659、τ-2平均69.0%、MMMU Pro 69.1%、DocVQA 94.9、BigBench Extra Hard 53.0%。これらもベンダー報告の数値だ——Googleが自社モデルを評価してその表を公開したものだ——しかし、誰でもダウンロードして再実行できるチェックポイントについて述べているという利点がある。だからこそ、オープンウェイトの主張は第三者による確認を素早く得る傾向があり、クローズドなプレビューの主張はそうではない。

このモデルの実際の違いは、数値的というより構造的だ。Gemma 4 12Bには独立した視覚エンコーダも音声エンコーダもなく、画像パッチと音声波形は直接トークン空間に投影される。まさにこれによって、12Bモデルがスクリーンショットや録音をそもそも入力として受け取れるのである。また、投機的デコーディング用のマルチトークン予測ドラフターも搭載しているが、これは品質のためではなくレイテンシのための機能だ。自分でモデルを動かし、プリフィルの1ミリ秒ごとが自分の支払い対象になるようなときに効いてくる類のものである。

二つが実際に衝突する場所

両モデルはエージェント型コーディングとツール利用向けに販売されており、実際に選択の余地があるのはこの領域だけだ。Ember-1のTerminal Bench 2.1の数値は82.0%で、Kimi K3 Maxの80.9%に対してであり、トークン数は51.9%少ない。そのSWE-bench Verifiedの結果は92.2%で、K3 Maxの93.2%に対してである。Gemma 4 12Bには、Googleの公開セットにTerminal BenchもSWE-benchの数値もまったくない。そのエージェント型に関する根拠はτ-2の69.0%だ。したがって、両者を共通のベンチマークで並べることはできず、そうしている記事は比較をでっち上げていることになる。

言えるのは、それらはコスト曲線上の異なる位置にあるということだ。エージェントのワークロードがホスト型のフロンティアモデル上で動作し、請求額の大半が推論トークンによるものであるなら、Ember-1 はまさにその項を攻める——その代償として、2週間のアクセス期間と、公開された料金がない。ワークロードを自分で管理するハードウェア上で実行する必要がある場合、スクリーンショットを処理する必要がある場合、あるいはベンダーがプレビューを継続しないと決めても生き残る必要がある場合、Gemma 4 12B は、この2つのうちそもそもその問いに答える唯一のものだ。

中道、そしてそれをどこに見出すか

どちらのモデル自身のマーケティングも前提にしていない第三の選択肢があります。より大きな Gemma 4 のティアをハイブリッドのホスト側として使う、というものです。OrcaRouter は Google の Gemma 4 26B-A4B とGemma 4 31Bを、200 以上の他のモデルとともにプロバイダーの定価で単一の API の背後にマークアップ 0% でルーティングします。つまり、中規模の Gemma に到達するのと同じキーが、本来なら別途契約が必要になるフロンティアモデルにも到達するのです。Gemma 4 12B 自体は当社のプラットフォームにはありませんし、Ember-1 も同様です。12B をローカルで必要とするならダウンロードしてください。より大きな Gemma が先にその差を埋めるかどうかを試したいなら、そのテストにかかるのはエンドポイント 1 つ分だけです。

その取り決めはまた、研究プレビューを評価するうえで誠実な方法でもある。プロバイダー間の自動フェイルオーバーとは、プレビュー期間からモデルが消えても、それがあなたのアプリケーションを巻き添えにしないことを意味する。これはEmber-1のリリース状況がもたらす特定のリスクであり、そのベンチマーク表のどこにも対処されていない特定のリスクでもある。

どれをロードマップに載せるべきか

所有が要件なら——プライバシー、オフライン動作、固定されたコスト下限、あるいはベンダーが気変わりしても動き続けなければならない製品——Gemma 4 12Bを選びましょう。その公表された上限性能はフロンティアモデルの派生版より低く、そのマルチモーダル入力は真に差別化要素ですが、どちらの事実も他人のロードマップには依存しません。

長いエージェント実行でのトークン単位の請求が課題で、プレビュー版のリスクを許容できるなら、Ember-1 を選びなさい。与えられた2週間、現行のものに対してシャドーで走らせ、自分のトラフィックで完了タスクあたりのトークン数を測定し、40%は実測レートではなく仮説として扱いなさい。してはいけないのは、品質で両者を選ぶことだ。なぜなら、Ember-1 を作ったラボを含め、誰もそれを可能にする比較を公開していないからだ。

より大きな要点は、これら2つのリリースが、2026年後半に能力が売られる2つの方法を表しているということだ。一方のラボはチェックポイントを公開し、エコシステムがその実力を見極めるに任せる。もう一方は、他者が訓練したモデルを手に取り、その振る舞いの1つの軸を改善し、その改善をサービスとして販売する。どちらも正当であり、失敗の仕方は異なる。オープンウェイトはゆっくりと公の場で失敗し、プレビューは突然、発表によって失敗する。