Ember-1 vs Gemma 4 12B: Der eine vermietet dir weniger Tokens, der andere übergibt dir die Gewichte

Ember-1 und Gemma 4 12B konkurrieren nicht um dieselbe Zeile auf einer Bestellung, und der schnellste Weg zu erkennen, warum, ist die Frage, was man am Ende eines jeden Monats besitzen würde. Gemma 4 12B ist Googles dichtes multimodales Modell mit 11,95 Mrd. Parametern, veröffentlicht am 3. Juni 2026 unter Apache 2.0 – man lädt es herunter, und der Checkpoint gehört einem. Ember-1 ist ein spezialisiertes Derivat von Fireworks Research auf Basis von Moonshot AIs Kimi K3, veröffentlicht am 23. September 2026 als Research Preview auf der Serverless-Plattform des Anbieters – man ruft es auf, und man besitzt nichts außer der Rechnung. Das eine ist ein Mietkauf-Argument über Tokens; das andere ein Kapitalkauf. Stellt man sie nebeneinander, ist der nützliche Vergleich nicht, welches Modell besser ist, denn nichts Veröffentlichtes erlaubt es, das zu klären. Sondern welche der beiden Beschaffungsformen zu dem passt, was man gerade baut.

Die beiden Verträge, klar formuliert

Gemma 4 12B ist ein fertiges Open-Weights-Release. Google veröffentlicht die Gewichte, die Architektur, das Benchmark-Sheet und die Lizenz, und eine Community von Runtimes – llama.cpp, vLLM, MLX, SGLang, Transformers – stellt es auf Hardware bereit, die Sie selbst kontrollieren. Die Kosten eines Tokens nach dem Kauf sind Strom und Abschreibung, kein Rechnungsposten eines Anbieters. Was Sie aufgeben, ist das, was Open Weights immer kosten: Sie übernehmen die Kapazitätsplanung, und Ihre Qualitätsobergrenze ist bei 11,95B Parametern festgelegt.

Ember-1 ist das Gegenteil. Es gibt keine Gewichte zum Herunterladen – es existiert als Serving-Option auf der Plattform des Anbieters selbst – und keinen veröffentlichten Preis. Was es stattdessen bietet, ist eine engere Behauptung, ausgeführt auf einem viel größeren Modell: die Genauigkeit von Kimi K3, mit rund 40 % weniger Tokens, die dafür aufgewendet werden. Fireworks Research hat es speziell darauf trainiert, Reasoning-Traces zu verkürzen, ohne Antworten zu verändern, und berichtet, dass die Reasoning-Länge um 35–50 % ohne Genauigkeitsverlust über sieben Benchmarks und zwei A/B-Tests in Kundenproduktion hinweg gesenkt werden konnte. Jede Zahl dort ist vom Anbieter angegeben und nicht reproduziert.

Was das Token-Argument wert ist, hängt völlig davon ab, wer für die Tokens bezahlt.

Der Pitch für Ember-1 geht von einer Abrechnung pro Token aus. Diese Annahme ist korrekt für die Zielgruppe, für die er konzipiert wurde – Teams, die lange Agent-Loops gegen ein gehostetes Frontier-Modell laufen lassen, wobei Fireworks Research anmerkt, dass Kimi K3 mehr als 90 % der generierten Token für internes Reasoning aufwenden kann, und wobei jede Runde vorherige Runden erneut abspielt, sodass früheres Reasoning erneut gelesen und erneut abgerechnet wird. In diesem Szenario ist eine Verkürzung der Trace-Länge eine direkte Senkung der Monatsabrechnung, und das A/B-Ergebnis von 29,9K Output-Tokens gegenüber K3s 49,3K ist die Zahl, auf die es ankommt.

Wendet man dasselbe Modell auf die Bedingungen von Gemma 4 12B an, löst sich das Argument auf. Wenn du einen Apache-2.0-Checkpoint selbst hostest, kosten zusätzliche Reasoning-Tokens Wall-Clock-Zeit und GPU-Belegung, nicht Dollar pro Million. Eine ausführliche Reasoning-Spur auf deinem eigenen 16-GB-Laptop ist eine langsamere Antwort, keine größere Rechnung. Das macht die Ineffizienz nicht harmlos – in einem Agenten-Loop summiert sie sich weiterhin, und sie zeigt sich weiterhin als Latenz –, aber der Wechselkurs ist ein anderer, und eine 40-prozentige Token-Reduktion als 40-prozentige Ersparnis auf selbst gehosteter Hardware zu behandeln, ist ein Kategorienfehler.

Das Datenblatt, eine Zeile pro Dimension

• Worum es sich handelt — Ember-1: ein Derivat von Kimi K3 als Forschungsvorschau, das für kürzere Denkprozesse neu trainiert wurde. Gemma 4 12B: ein dichtes multimodales Open-Weights-Modell mit 11,95 Mrd. Parametern aus Googles Gemma-4-Familie.

• Gewichte — Ember-1: nicht veröffentlicht; nur über die Plattform des Anbieters bereitgestellt. Gemma 4 12B: Apache 2.0, herunterladbar, ohne Zugangsbeschränkung.

• Größe — Ember-1: nicht offengelegt; von Kimi K3s Architektur übernommen. Gemma 4 12B: 11,95B dense, 48 Schichten, rund 18GB Gewichte in BF16.

• Kontextfenster — Ember-1: nicht für die Vorschau veröffentlicht; sein Basismodell umfasst 1.048.576 Token. Gemma 4 12B: 256K Token.

• Eingaben — Ember-1: Text. Gemma 4 12B: Text, Bild und Audio durch ein encoderfreies, einheitliches Design, wobei Video von einigen Quellen aufgeführt wird.

• Preis — Ember-1: keiner veröffentlicht; die Dollar-Beträge im Benchmark-Blatt werden aus Kimi K3s Preisliste berechnet. Gemma 4 12B: kostenlos herunterladbar; Sie zahlen für die Hardware.

• Hardware-Mindestanforderung — Ember-1: was auch immer der Anbieter vorsieht. Gemma 4 12B: 16 GB VRAM oder Unified Memory, gemäß Googles Positionierung.

• Belege — Ember-1: Anbieter-Benchmarks und zwei vom Anbieter durchgeführte A/B-Tests, nicht reproduziert. Gemma 4 12B: von Goog​le gemeldete Evaluierungen plus ein unabhängiges Ökosystem lokaler Durchläufe.

Was Gemma 4 12B veröffentlicht, und wie es liest

Googles eigene Zahlen für Gemma 4 12B verorten es zwischen dem auf Edge-Größe ausgelegten Gemma 4 E4B und dem größeren 26B MoE: GPQA Diamond 78,8 %, MMLU Pro 77,2 %, AIME 2026 ohne Tools 77,5 %, LiveCodeBench v6 72,0, Codeforces ELO 1659, τ-2 Durchschnitt 69,0 %, MMMU Pro 69,1 %, DocVQA 94,9 und BigBench Extra Hard 53,0 %. Auch das sind Herstellerangaben – Google hat sein eigenes Modell evaluiert und das Datenblatt veröffentlicht –, doch sie haben den Vorteil, einen Checkpoint zu beschreiben, den jeder herunterladen und erneut ausführen kann, weshalb Behauptungen zu offenen Gewichten schnell Bestätigung durch Dritte erhalten, Behauptungen zu geschlossenen Vorabversionen hingegen nicht.

Die eigentliche Unterscheidung des Modells ist struktureller und nicht numerischer Natur. Gemma 4 12B hat keinen separaten Vision- oder Audio-Encoder: Bild-Patches und Audio-Wellenformen projizieren direkt in den Token-Raum, was es einem 12B-Modell überhaupt erst ermöglicht, einen Screenshot oder eine Aufnahme als Eingabe zu akzeptieren. Es bringt außerdem Multi-Token-Prediction-Drafter für spekulatives Decoding mit, wobei es sich um ein Latenz- und nicht um ein Qualitätsmerkmal handelt – so etwas zählt, wenn man das Modell selbst betreibt und jede Millisekunde Prefill selbst bezahlen muss.

Wo die beiden tatsächlich kollidieren

Beide Modelle werden für agentisches Coding und Tool-Nutzung vermarktet, und dies ist der einzige Bereich, in dem eine echte Wahl besteht. Der Wert von Ember-1 bei Terminal Bench 2.1 liegt bei 82,0 % gegenüber 80,9 % bei Kimi K3 Max – mit 51,9 % weniger Tokens; sein Ergebnis bei SWE-bench Verified liegt bei 92,2 % gegenüber 93,2 % bei K3 Max. Gemma 4 12B hat überhaupt keinen Wert bei Terminal Bench oder SWE-bench im veröffentlichten Set von Google – seine agentischen Belege sind τ-2 bei 69,0 %. Man kann die beiden also nicht anhand eines gemeinsamen Benchmarks gegenüberstellen, und jeder Artikel, der das tut, erfindet den Vergleich.

Was man sagen kann, ist, dass sie an unterschiedlichen Punkten auf einer Kostenkurve liegen. Wenn Ihre Agent-Workload gegen ein gehostetes Frontier-Modell läuft und die Rechnung von Reasoning-Tokens dominiert wird, setzt Ember-1 genau an diesem Posten an – zum Preis eines zweiwöchigen Zugriffsfensters und ohne veröffentlichten Tarif. Wenn Ihre Workload auf Hardware laufen muss, die Sie kontrollieren, einen Screenshot verarbeiten oder es überstehen muss, dass ein Anbieter beschließt, eine Preview nicht fortzuführen, ist Gemma 4 12B das einzige der beiden, das die Frage überhaupt beantwortet.

Ein Mittelweg – und wo man ihn findet

Es gibt eine dritte Option, auf die das Marketing keines der beiden Modelle ausgerichtet ist: die größeren Gemma 4-Stufen als gehostete Hälfte eines Hybrids zu nutzen. OrcaRouter routet Googles Gemma 4 26B-A4B und Gemma 4 31B neben über 200 anderen Modellen hinter einer einzigen API zum Listenpreis des Anbieters mit 0 % Aufschlag, sodass derselbe Schlüssel, der ein mittelgroßes Gemma erreicht, auch die Frontier-Modelle erreicht, für die Sie sonst einen zweiten Vertrag bräuchten. Gemma 4 12B selbst ist nicht auf unserer Plattform, und Ember-1 auch nicht — wenn Sie das 12B lokal benötigen, laden Sie es herunter; wenn Sie zuerst testen möchten, ob ein größeres Gemma die Lücke schließt, kostet dieser Test einen Endpunkt.

Diese Regelung ist auch die ehrliche Art, eine Research Preview zu bewerten. Automatisches Failover über Anbieter hinweg bedeutet, dass ein Modell, das aus einem Vorschaufenster verschwindet, Ihre Anwendung nicht mitnimmt – und das ist das spezifische Risiko, das der Release-Status von Ember-1 mit sich bringt, und das spezifische Risiko, auf das nichts in seiner Benchmark-Tabelle eingeht.

Welche davon gehört auf deine Roadmap?

Wählen Sie Gemma 4 12B, wenn Eigentümerschaft eine Voraussetzung ist – Datenschutz, Offline-Betrieb, eine feste Kostenuntergrenze oder ein Produkt, das weiterhin funktionieren muss, falls ein Anbieter seine Meinung ändert. Seine veröffentlichte Obergrenze ist niedriger als die eines Frontier-Derivats, und sein multimodaler Input ist ein echtes Differenzierungsmerkmal, und keiner dieser Punkte hängt von der Roadmap von jemand anderem ab.

Wählen Sie Ember-1, wenn Ihr Problem eine Abrechnung pro Token bei langen Agent-Läufen ist und Sie das Risiko einer Vorschauversion tragen können. Lassen Sie es im Schattenbetrieb für die zwei Wochen, die Ihnen zur Verfügung stehen, gegen Ihr bestehendes System laufen, messen Sie Token pro abgeschlossener Aufgabe mit Ihrem eigenen Traffic und behandeln Sie die 40 % als Hypothese statt als Rate. Was Sie nicht tun sollten, ist, zwischen ihnen anhand der Qualität zu wählen, denn niemand – auch nicht das Labor, das Ember-1 entwickelt hat – hat einen Vergleich veröffentlicht, der Ihnen das ermöglichen würde.

Der größere Punkt ist, dass diese beiden Veröffentlichungen die zwei Arten darstellen, wie Fähigkeiten im späten 2026 verkauft werden. Ein Labor veröffentlicht einen Checkpoint und lässt das Ökosystem sein Niveau finden; ein anderes nimmt ein Modell, das jemand anderes trainiert hat, verbessert eine Achse seines Verhaltens und verkauft die Verbesserung als Dienst. Beide sind legitim, und sie scheitern auf unterschiedliche Weise: offene Gewichte scheitern langsam und öffentlich, Previews scheitern plötzlich und per Ankündigung.