A generated title card reading "Ember-1 vs Gemma 4 12B" with the subhead "Fewer tokens on a rented endpoint, or your own weights", above two cards: Ember-1 — "Kimi K3 derivative" and "no weights, no published price"; Gemma 4 12B — "11.95B dense, Apache 2.0" and "256K context, multimodal".
Guides & Insights

Ember-1 vs Gemma 4 12B: One Rents You Fewer Tokens, the Other Hands You the Weights

Author

Magnus Corvin

Date Published

Latest models · 20View all models
Benchmarks: Artificial Analysis · updated daily
Back to all posts

Ember-1 and Gemma 4 12B are not competing for the same line on a purchase order, and the fastest way to see why is to ask what you would own at the end of each month. Gemma 4 12B is Goog​le's 11.95B-parameter dense multimodal model, released 3 June 2026 under Apache 2.0 — you download it, and the checkpoint is yours. Ember-1 is Fireworks Research's specialized derivative of Moonshot AI's Kimi K3, published 23 September 2026 as a research preview on the vendor's own serverless platform — you call it, and you own nothing but the invoice. One is a rent-to-own argument about tokens; the other is a capital purchase. Put them side by side and the useful comparison is not which model is better, because nothing published lets you settle that. It is which of the two procurement shapes fits the thing you are building.

The two contracts, stated plainly

Gemma 4 12B is a finished open-weights release. Goog​le publishes the weights, the architecture, the benchmark sheet and the license, and a community of runtimes — llama.cpp, vLLM, MLX, SGLang, Transformers — serves it on hardware you control. The cost of a token after purchase is electricity and amortization, not a line item from a vendor. The things you give up are the things open weights always cost: you own capacity planning, and your quality ceiling is fixed at 11.95B parameters.

Ember-1 is the inverse. There are no weights to download — it exists as a serving option on the vendor's own platform — and no published price. What it offers instead is a narrower claim, executed on top of a much larger model: Kimi K3's accuracy, with roughly 40% fewer tokens spent getting there. Fireworks Research trained it specifically to shorten reasoning traces without changing answers, and reports that reasoning length could be cut by 35–50% without accuracy loss across seven benchmarks and two customer production A/B tests. Every figure there is vendor-reported and unreproduced.

A two-column scoreboard titled "Ember-1 vs Gemma 4 12B — the scoreboard" comparing six dimensions. Ember-1: a Kimi K3 derivative retrained for shorter reasoning; no published weights; context not published (base model 1M); text-only input; price not published, preview only; evidence is vendor benchmarks plus two vendor-run A/B tests. Gemma 4 12B: a dense 11.95B multimodal generalist; Apache 2.0 weights, downloadable; 256K-token context; text, image and audio input; free to download with hardware costs; evidence is Google evaluations plus an independent local-run ecosystem.

What the token argument is worth depends entirely on who pays for the tokens

The pitch for Ember-1 assumes a per-token bill. That assumption is correct for the audience it was designed for — teams running long agent loops against a hosted frontier model, where Fireworks Research notes Kimi K3 can spend more than 90% of generated tokens on internal reasoning, and where each turn replays prior turns so earlier reasoning is re-read and re-billed. In that setting, cutting trace length is a direct cut to the monthly statement, and the A/B result of 29.9K output tokens against K3's 49.3K is the number that matters.

Run the same model on Gemma 4 12B's terms and the argument dissolves. When you self-host an Apache-2.0 checkpoint, extra reasoning tokens cost wall-clock time and GPU occupancy, not dollars per million. A verbose reasoning trace on your own 16GB laptop is a slower answer, not a bigger bill. That does not make the inefficiency harmless — in an agent loop it still compounds, and it still shows up as latency — but the exchange rate is different, and treating a 40% token reduction as a 40% saving on self-hosted hardware is a category error.

The spec sheet, one line per dimension

• What it is — Ember-1: a research-preview derivative of Kimi K3, retrained for shorter reasoning. Gemma 4 12B: a dense 11.95B open-weights multimodal model from Goog​le's Gemma 4 family.

• Weights — Ember-1: none published; served only through the vendor's platform. Gemma 4 12B: Apache 2.0, downloadable, ungated.

• Size — Ember-1: undisclosed; inherited from Kimi K3's architecture. Gemma 4 12B: 11.95B dense, 48 layers, roughly 18GB of weights in BF16.

• Context window — Ember-1: not published for the preview; its base model carries 1,048,576 tokens. Gemma 4 12B: 256K tokens.

• Inputs — Ember-1: text. Gemma 4 12B: text, image and audio through an encoder-free unified design, with video listed by some sources.

• Price — Ember-1: none published; the benchmark sheet's dollars are computed from Kimi K3's rate card. Gemma 4 12B: free to download; you pay for the hardware.

• Hardware floor — Ember-1: whatever the vendor schedules. Gemma 4 12B: 16GB of VRAM or unified memory, per Goog​le's positioning.

• Evidence — Ember-1: vendor benchmarks and two vendor-run A/B tests, unreproduced. Gemma 4 12B: Goog​le-reported evals plus an independent ecosystem of local runs.

What Gemma 4 12B publishes, and how it reads

Goog​le's own numbers for Gemma 4 12B put it between the edge-sized Gemma 4 E4B and the larger 26B MoE: GPQA Diamond 78.8%, MMLU Pro 77.2%, AIME 2026 without tools 77.5%, LiveCodeBench v6 72.0, Codeforces ELO 1659, τ-2 average 69.0%, MMMU Pro 69.1%, DocVQA 94.9 and BigBench Extra Hard 53.0%. Those are vendor-reported too — Goog​le evaluated its own model and published the sheet — but they have the advantage of describing a checkpoint anyone can download and re-run, which is why open-weights claims tend to acquire third-party confirmation quickly and closed preview claims do not.

The model's actual distinction is structural rather than numerical. Gemma 4 12B has no separate vision or audio encoder: image patches and audio waveforms project directly into the token space, which is what lets a 12B model take a screenshot or a recording as input at all. It also ships multi-token-prediction drafters for speculative decoding, which is a latency feature rather than a quality one — the kind of thing that matters when you are running the model yourself and every millisecond of prefill is yours to pay for.

Where the two actually collide

Both models are sold into agentic coding and tool use, and this is the only territory where a real choice exists. Ember-1's Terminal Bench 2.1 figure is 82.0% against Kimi K3 Max's 80.9%, with 51.9% fewer tokens; its SWE-bench Verified result is 92.2% against K3 Max's 93.2%. Gemma 4 12B has no Terminal Bench or SWE-bench number in Goog​le's published set at all — its agentic evidence is τ-2 at 69.0%. So you cannot line the two up on a shared benchmark, and any article that does is inventing the comparison.

What you can say is that they sit at different points on a cost curve. If your agent workload runs against a hosted frontier model and the bill is dominated by reasoning tokens, Ember-1 attacks exactly that term — at the price of a two-week access window and no published rate. If your workload needs to run on hardware you control, handle a screenshot, or survive a vendor deciding not to continue a preview, Gemma 4 12B is the only one of the two that answers the question at all.

A screenshot of the Hugging Face model card for google/gemma-4-12B, showing 97,559 downloads in the last month, a safetensors model size of 12B parameters in BF16, the Apache 2.0 licence, any-to-any modality, and a model tree listing 7 adapters, 62 fine-tunes and 49 quantizations. The Inference Providers panel reads "This model isn't deployed by any Inference Provider."

A middle path, and where to find it

There is a third option that neither model's own marketing is built around: use the larger Gemma 4 tiers as the hosted half of a hybrid. OrcaRouter routes Goog​le's Gemma 4 26B-A4B and Gemma 4 31B alongside 200+ other models behind one API at provider list price with 0% markup, so the same key that reaches a mid-size Gemma also reaches the frontier models you would otherwise need a second contract for. Gemma 4 12B itself is not on our platform, and Ember-1 is not either — if you need the 12B locally, download it; if you want to test whether a bigger Gemma closes the gap first, that test costs one endpoint.

That arrangement is also the honest way to evaluate a research preview. Automatic failover across providers means a model that disappears from a preview window does not take your application with it, which is the specific risk Ember-1's release status introduces and the specific risk nothing in its benchmark table addresses.

Which one belongs on your roadmap

Choose Gemma 4 12B if ownership is a requirement — privacy, offline operation, a fixed cost floor, or a product that has to keep working if a vendor changes its mind. Its published ceiling is lower than a frontier derivative's and its multimodal input is genuinely differentiating, and neither of those facts depends on anyone else's roadmap.

Choose Ember-1 if your problem is a per-token bill on long agent runs and you can absorb preview risk. Run it in shadow against your incumbent for the two weeks you have, measure tokens per completed task on your own traffic, and treat the 40% as a hypothesis rather than a rate. What you should not do is pick between them on quality, because no one — including the lab that built Ember-1 — has published a comparison that would let you.

A screenshot of OrcaRouter's model page for Gemma 4 31B, showing the google/gemma-4-31b-it listing priced at $0.13 per 1M input tokens and $0.38 per 1M output tokens, a p50 time-to-first-token of 1.44s, 375.3K tokens of traffic over seven days, a 256K-token context window and a Python snippet calling api.orcarouter.ai/v1.

The larger point is that these two releases represent the two ways capability is being sold in late 2026. One lab publishes a checkpoint and lets the ecosystem find its level; another takes a model somebody else trained, improves one axis of its behaviour, and sells the improvement as a service. Both are legitimate, and they fail in different ways: open weights fail slowly and in public, previews fail suddenly and by announcement.

Compared in this article1

Detected from this article · Benchmarks: Artificial Analysis · updated daily