Ember-1 kürzt das Reasoning von Kimi K3 um 40 % – und das Kleingedruckte ist die eigentliche Geschichte

Die Zahl, die zitiert werden wird, ist 40 %. Fireworks Research veröffentlichte Ember-1 am 23. September 2026 und beschrieb es als spezialisierten Ableger von Moonshot AIs Kimi K3, der die Genauigkeit von K3 beibehält, dabei aber ungefähr 40 % weniger Tokens verbraucht, um dorthin zu gelangen. Das ist eine reale und ungewöhnlich spezifische Behauptung, und sie kommt mit drei Dingen daher: einer vollständigen Benchmark-Tabelle mit Token-Reduktionsspalten, zwei Kunden-A/B-Tests aus Produktions-Coding-Traffic und einem Release-Status, der nicht allgemeine Verfügbarkeit ist. Ember-1 ist als Research Preview verfügbar, auf der hauseigenen serverlosen Plattform des Anbieters, mit einem zweiwöchigen Zugriffsfenster und einer Entscheidung über die dauerhafte Verfügbarkeit, die von der Nachfrage abhängt. Zu verstehen, welcher Teil davon ein ausgeliefertes Produkt ist und welcher Teil ein gut begründetes Forschungsergebnis, ist die eigentliche Übung.

Außerdem gibt es eine Namenskollision, die vor allem anderen geklärt werden sollte. Ein separates offenes Forschungsprojekt namens Ember (v0.1.5, von Slow Lit Labs) verbrachte 2026 damit, Evaluierungen zur Langhorizont-Kohärenz zu veröffentlichen, und es steht in keinerlei Verbindung zu diesem Modell. Alles, was Sie darüber lesen, dass Ember Qwen3-8B unter identischen Inferenzeinstellungen nicht schlägt, bezieht sich auf jenes Projekt. Ember-1, das hier behandelte Modell, ist ein Kimi-K3-Derivat von Fireworks Research.

Was Ember-1 tatsächlich ist

Ember-1 ist keine neue Architektur und kein neues Basismodell. Es ist Kimi K3, neu trainiert, um prägnanter zu schlussfolgern. Fireworks Research führte mehr als 50 Trainingsexperimente und über 200 Evaluierungen auf seinem eigenen serverlosen Trainings-Stack durch, in den Bereichen Mathematik, Coding, Anweisungsbefolgung, Konversation, Suche, Tool-Nutzung und Software-Engineering, mit dem ausdrücklichen Ziel, Reasoning zu entfernen, das die Antwort nicht verändert. Das Labor sagt, die Reasoning-Länge ließe sich um 35–50 % reduzieren, ohne Genauigkeitsverlust, über sieben Benchmarks und zwei Produktions-Traffic-Sets von Kunden hinweg. Jede dieser Zahlen stammt vom Anbieter und wurde nicht unabhängig reproduziert; bis zum Zeitpunkt des Verfassens hat kein Dritter einen Lauf von Ember-1 veröffentlicht.

Das Framing ist wichtig, weil die naheliegende Alternative bereits existierte. Kimi K3 wird mit Reasoning-Effort-Einstellungen ausgeliefert, und der günstige Weg, weniger Tokens zu verbrauchen, besteht darin, den Aufwand herunterzudrehen. Fireworks Research sagt, man habe das ausprobiert, und die niedrige Einstellung habe zu viel Qualität eingebüßt — ein vertrautes Ergebnis für alle, die schon einmal Aufwandsstufen bei einem Reasoning-Modell abgestimmt haben. Ember-1s Behauptung ist, dass der Aufwandsregler grob ist und Retraining fein.

Warum Reasoning-Tokens so viel Aufwand wert sind

Die Abrechnung eines Reasoning-Modells wird nicht von seiner Antwort dominiert. Fireworks Research merkt an, dass K3 mehr als 90 % seiner generierten Tokens für internes Reasoning aufwenden kann, bevor es irgendetwas schreibt, das ein Nutzer sieht. Bei einer einzelnen Anfrage ist das lediglich teuer. In einer Multi-Turn-Agent-Schleife summiert es sich, weil jeder Turn die vorherige Konversation erneut abspielt, sodass die Reasoning-Spuren aus früheren Turns bei jedem folgenden Aufruf erneut gelesen und erneut abgerechnet werden. Fireworks Research beschreibt, dass der Kontext mit der Anzahl der Turns ungefähr quadratisch wächst. Das ist das eigentliche Ziel dieser Veröffentlichung, und deshalb ist die Schlagzeilen-Metrik etwa 40 % weniger Tokens statt eines Qualitätssprungs.

Der Mechanismus erklärt auch das Risiko. Kompression, die verschwendetes Abwägen entfernt, ist kostenlos; Kompression, die einen Schritt entfernt, den das Modell gebraucht hätte, ist es nicht. Der weithin berichtete Fehlermodus einer überaggressiven Reduktion des Schlussfolgerns ist ein Modell, das eine Zwischenkontrolle überspringt und zu einer Schlussfolgerung springt, was sich bei einem Agenten viel später als fehlerhafter Tool-Aufruf statt als falscher Satz zeigt. Die wiederholte Betonung gleichwertiger Qualität durch Fireworks Research liest sich wie eine Antwort auf diese Sorge, und die A/B-Zahlen sind das, was einem Beleg dafür am nächsten kommt – mit dem üblichen Vorbehalt, dass die Testsätze, die Bestehenskriterien und die Stichprobengrößen allesamt von der Partei gewählt wurden, die die Behauptung aufstellt.

Die Benchmark-Tabelle samt beigefügter Provenienz.

Dies sind die Zahlen von Fireworks Research, nicht reproduziert. Die rechte Spalte ist der Teil, der ein genaues Lesen lohnt: Sie stellt jeder Punktzahl gegenüber, wie viele Tokens und Dollar im Verhältnis zu K3 Max nötig waren.

• Terminal Bench 2.1 (n=89) — Ember-1 82,0 % vs. K3 Max 80,9 %, K3 High 77,6 %, K3 Low 76,4 %; 51,9 % weniger Tokens, 23,10 $ weniger pro Aufgabe.

• SWE-bench Verified (n=500) — Ember-1 92,2 % vs. K3 Max 93,2 %; 15,5 % weniger Tokens, 68,10 $ weniger pro Aufgabe.

• SWE-Interact (n=75) — Ember-1 20,0 % gegenüber K3 Max 21,3 %, K3 High 13,3 %, K3 Low 6,7 %; 32,5 % weniger Tokens.

• DeepSWE 1.1 (n=113) — Ember-1 75,2 % gegenüber K3 Max 66,4 %; 23,7 % weniger Tokens, 126,90 $ weniger pro Aufgabe.

• τ-2 Bench Airline (n=50) — Ember-1 66 % vs. K3 Max 64 %, K3 High und Low beide 64 %; 5,9 % weniger Tokens, 0,30 $ weniger pro Aufgabe.

Zwei Dinge stechen hervor. Erstens gewinnt Ember-1 auf Terminal Bench 2.1 und DeepSWE 1.1 klar, während es auf SWE-bench Verified und SWE-Interact knapp verliert – ein Muster, das zu einem Modell passt, das nicht so sehr an Fähigkeit verloren hat, als vielmehr geändert hat, auf welche Aufgaben es Denkzeit verwendet. Zweitens sind die Token-Einsparungen extrem ungleichmäßig: 51,9 % auf Terminal Bench gegenüber 5,9 % bei τ-2 Airline. Was auch immer Ember-1 gelernt hat, es ist kein pauschaler 40-%-Abschlag beim Denken. Das „etwa 40 %“ in der Schlagzeile ist ein Durchschnitt über eine Spanne, die von ungefähr 6 % bis ungefähr 52 % reicht, und ein Team, dessen Arbeitslast wie τ-2 Airline aussieht, sollte nicht erwarten, das zu spüren.

Die Produktions-A/B-Tests sind die überzeugenderen Belege, gerade weil sie nicht als Benchmarks konzipiert wurden. In der Coding-Workload eines Kunden erzielte Ember-1 0,753 gegenüber 0,751 von K3, benötigte 21,4 Schritte gegenüber 23,8 und gab 29,9K Ausgabe-Token gegenüber 49,3K aus — eine Reduzierung der Reasoning-Token um 71,3 % und der Gesamt-Token um 39 % bei etwa gleichwertiger Qualität. Ein zweiter Kunde verzeichnete bei vergleichbarer Qualität etwa 35 % weniger Token pro Aufgabe, und Fireworks Research gibt an, den Wechsel zuerst im eigenen internen Coding- und Coworking-Traffic durchgeführt zu haben, mit dem berichteten Ergebnis, dass es niemandem aufgefallen ist. Behandeln Sie all dies als Anbieterberichte, aber behandeln Sie es als die stärkste Form von Anbieterberichten: A/B-Präferenz- und Aufgabenabschlussdaten sind schwieriger zu manipulieren als eine Bestenliste.

Es gibt noch eine weitere Bewertung, auf Doximity's Bedside Bench – 500 von Ärzten validierte klinische Fälle aus zehn Kategorien –, bei der Fireworks Research behauptet, Ember-1 habe eine neue Pareto-Grenze bei den Kosten pro Aufgabe erreicht, wobei es mit offenen und geschlossenen Modellen verglichen wurde, darunter GPT-5.6 Sol, GPT-6 Astra und Claude Opus 5. Das ist eine Anbieterbehauptung über eine Pareto-Position, also eine Aussage über einen zweidimensionalen Trade-off statt über eine einzelne Punktzahl, und sie ist nur so gut wie die Kostenannahmen, die dahinterstehen. Diese Annahmen stammten aus der öffentlichen API-Preisliste von Kimi K3. Womit wir zu dem Teil der Geschichte kommen, den ein Leser heute tatsächlich überprüfen kann.

Das Basismodell ist der Teil, den Sie bereits routen können.

Ember-1s gesamte Kostenargumentation wird an Kimi K3s veröffentlichten Preisen gemessen. Kimi K3 ist auf OrcaRouter verfügbar zu 3,00 $ pro Million Eingabe-Token, 0,30 $ pro Million gecachter Eingabe-Token und 15,00 $ pro Million Ausgabe-Token, mit einem Kontextfenster von 1.048.576 Token. Das ist dieselbe Preisliste, die der Vergleich von Fireworks Research verwendet, und es lohnt sich zu wissen, dass die Einsparungen in diesen Token-Reduktionsspalten anhand von Zahlen berechnet werden, die Sie selbst sehen können, und nicht anhand eines internen Kostenmodells eines Anbieters.

Ember-1 selbst ist nicht auf OrcaRouter. Es ist ausschließlich über die eigene serverlose Plattform des Anbieters verfügbar, als Research Preview, und Fireworks Research hat keinen Preis dafür veröffentlicht – die Dollarzahlen in der Benchmark-Tabelle stammen daher aus K3-Tarifen und Token-Zahlen, nicht aus einer existierenden Ember-1-Preiskarte. Wenn Sie die Arithmetik interessiert, ist die ehrliche Reihenfolge: den Workload heute über K3s Route bepreisen, die Token-Reduktionsprozentsätze als Obergrenze dessen nehmen, was ein Wechsel bringen könnte, und auf einen veröffentlichten Tarif warten, bevor Sie die Ersparnis als Geld modellieren.

Womit OrcaRouter hier tatsächlich hilft, ist die Absicherung. Eine Forschungsvorschau mit einem zweiwöchigen Zugriffsfenster ist genau die Art von Modell, die man ausprobieren möchte, ohne darauf einen Produktionspfad zu setzen, und um das ohne einen zweiten Vertrag zu tun, muss man es nur hinter denselben Endpunkt legen wie alles andere, was man aufruft. OrcaRouter bietet 200+ Modelle hinter einer einzigen API mit automatischem Failover, sodass ein Vorschaumodell, das sich nächsten Monat als nicht verfügbar erweist, eine Routing-Änderung statt einer Migration ist. Nichts an Ember-1 erfordert das – aber nichts an einem zweiwöchigen Fenster spricht auch dagegen.

Was ist mit dieser Veröffentlichung zu tun?

Wenn Sie Kimi K3 bereits in einer Agent-Loop laufen lassen, beschreiben die Zahlen von Ember-1 Ihre Abrechnung. Das Multi-Turn-Replay-Problem ist real, es ist der dominierende Kostenfaktor bei langen Agent-Läufen, und ein Modell, das seine eigenen Traces verkürzt, ohne seine Antworten zu ändern, ist die Evaluierungszeit wert. Der richtige Test ist nicht die Benchmark-Tabelle; es ist Ihr eigener Traffic, im Shadow-Modus ausgeführt – senden Sie einen Teil echter Anfragen an beide Modelle, vergleichen Sie die Ausgaben, lassen Sie die Live-Ergebnisse ein oder zwei Wochen lang unangetastet, bevor Sie irgendetwas ändern. Das ist auch der Rat, den die kritische Leserschaft des Releases selbst gibt, und er ist fundiert.

Wenn Sie einen Low-Deliberation-Workload ausführen oder einen, der von kurzen Single-Turn-Aufrufen dominiert wird, verschwinden die Einsparungen weitgehend, und die τ-2-Airline-Zeile ist Ihre realistische Erwartung. Und wenn Sie eine produktionsreife Zusage brauchen — einen Preis, ein Service-Level, eine Garantie, dass der Endpoint in sechs Monaten noch existiert —, bietet Ember-1 noch keine. Es ist eine Research Preview, deren Bestand Fireworks Research ausdrücklich an die Nachfrage knüpft. Die interessante Frage im kommenden Monat ist, ob das Zwei-Wochen-Fenster zu einer dauerhaften Serving-Option wird und ob ein Dritter eine der Zahlen reproduziert. Bis eines davon eintritt, ist dies ein starkes Ergebnis zum Lesen und ein schlechtes, auf das man ein Budget stützen sollte.

Nichts davon sollte als Schmälerung der Arbeit verstanden werden. Reasoning zu entfernen, ohne die Genauigkeit zu entfernen, ist ein schwierigeres Problem, als es hinzuzufügen, und es auf dem Frontier-Modell von jemand anderem aufzubauen, statt ein eigenes zu trainieren, ist die Gestalt, die ein Großteil der Capability-Arbeit im Jahr 2026 angenommen hat. Ember-1 ist die erste Veröffentlichung in einer Reihe, die laut Fireworks Research fortlaufend sein wird, und das Muster – ein Modell nehmen, das bereits gut ist, eine Achse seines Verhaltens neu trainieren, das Delta in Tokens verkaufen – ist eines, das es wert ist, beobachtet zu werden, unabhängig davon, wie diese spezielle Vorschau ankommt.