Zum Hauptinhalt springen

Ember-1: Kimi K3s Antworten für 40 % weniger Tokens (Sep. 2026)

Fortgeschritten

Am 23. September 2026 veröffentlichte Fireworks Ember-1: keine neue Architektur, kein neues Pre-Training — Kimi K3 mit nachtrainierter Reasoning-Gewohnheit. Derselbe Körper mit 2,8 Billionen Parametern, derselbe 1M-Kontext, derselbe Preis pro Token. Es denkt einfach nicht mehr so viel. Fireworks berichtet 35–50 % weniger Reasoning-Tokens ohne Genauigkeitsverlust, und in zwei von fünf veröffentlichten Benchmarks übertrifft Ember-1 K3 bei dessen maximaler Effort-Einstellung und kostet dabei weniger.

Vier Tage später war es die Top-KI-Story auf Hacker News. Der interessante Teil ist nicht das Modell — es ist die Behauptung darunter: Der günstigste Weg, ein Reasoning-Modell zu betreiben, ist nicht mehr, ihm zu sagen, es solle weniger denken. Diese Seite nimmt diese Behauptung auseinander, zeigt dir die Arithmetik, die die Launch-Tabelle implizit enthält, aber nie ausdruckt, und gibt dir eine Möglichkeit, das an einem Nachmittag an deinem eigenen Traffic zu testen.

What you'll learn
  • Die zwei Dinge trennen, die einen Agenten teuer machen: Preis pro Token und Anzahl der Tokens — Ember-1 verändert nur das Zweite
  • Die Launch-Tabelle ehrlich lesen, einschließlich des Benchmarks, in dem Effort buchstäblich nichts bringt, und desjenigen, in dem jedes Modell unter 22 % punktet
  • Die Kosten pro Aufgabe herleiten, die der Blogpost nicht ausdruckt (und entdecken, dass ein einzelner Benchmark-Durchlauf 5–535 $ kostet)
  • Verstehen, warum ein 71-prozentiger Schnitt bei Reasoning-Tokens nur einen 39-prozentigen Schnitt bei den Gesamt-Tokens ergab — und was dieses Verhältnis über deine eigene Rechnung sagt
  • Den Anteil der Reasoning-Tokens an deiner Arbeitslast mit einem Feld messen, das die meisten SDK-Wrapper wegwerfen
  • Das Kleingedruckte kennen, bevor du migrierst: Research-Preview-Status, keine freigegebenen Gewichte, eine verlorene Input-Modalität und die umsatzgestaffelte Kimi-K3-Lizenz, die unter allem liegt

Die Version in einem Absatz​

Kimi K3 verbringt wie jedes Reasoning-Modell die meisten seiner generierten Tokens mit internem Reasoning — Fireworks setzt es auf manchmal mehr als 90 %. In einem Multi-Turn-Agenten wird dieses Reasoning in jeden späteren Call zurückgespielt, sodass der Kontext etwa quadratisch mit der Turn-Zahl wächst und frühes Denken für den Rest des Durchlaufs erneut abgerechnet wird. Fireworks' Kunden verlangten K3s Coding-Qualität bei niedrigeren Kosten; reasoning_effort herunterzudrehen gab zu viel Qualität auf, also trainierte Fireworks stattdessen das Verhalten — über 50 Trainingsläufe und 200+ Evaluationen — und lehrte dem Modell, die Selbstreflexion zu behalten, die Fehler auffängt, und den Rest zu verwerfen. Das Ergebnis wird als accounts/fireworks/models/ember-1 zu genau K3s Tarifen ausgeliefert: 3 $ / M ungecachter Input, 0,30 $ / M gecachter Input, 15 $ / M Output.

Drei Dinge, die die Schlagzeile verbirgt​

1. Nichts wurde günstiger. Das Modell kauft nur weniger.​

Das ist der Teil, der umrahmt, wie du über Modellkosten denken solltest. Ember-1s Preisliste ist identisch mit der von Kimi K3, bei Fireworks wie bei OpenRouter (3 $ Input / 15 $ Output pro Million, 1.048.576-Token-Kontext bei beiden). Es gibt keinen Rabatt. Jeder gesparte Dollar kommt von Tokens, die überhaupt nie generiert werden — und, in einer Agentenschleife, davon, dass genau diese Tokens in den nächsten neunzehn Turns nie wieder als Input zurückgespielt werden.

Das hat eine praktische Konsequenz: $/Token ist die falsche Zahl auf deinem Dashboard. Zwei Modelle zum gleichen Listenpreis können bei derselben Aufgabe um den Faktor 2 auseinanderliegen, und das Modell mit dem höheren Listenpreis ist regelmäßig das günstigere pro fertiggestellter Aufgabe. AILmanacs Was KI bei den verschiedenen Anbietern kostet macht denselben Punkt von der Preisseite aus; Ember-1 ist das bisher sauberste natürliche Experiment dafür, weil die Preisvariable festgepinnt ist und sich nur die Token-Zahl bewegt.

2. Den Effort herunterzudrehen ist nicht dasselbe, und die Tabelle beweist es​

K3 stellt reasoning_effort in den Stufen low, high und max bereit. Fireworks hat alle drei als separate Arme laufen lassen, und das macht ihre Tabelle nützlicher als die meisten Launch-Tabellen:

BenchmarkNK3 lowK3 highK3 maxEmber-1Ember-1 vs. K3 max
Terminal Bench 2.18976,4 %77,6 %80,9 %82,0 %−51,9 % / −23,1 USD
SWE-bench Verified50080,4 %86,0 %93,2 %92,2 %−15,5 % / −68,1 USD
SWE-Interact756,7 %13,3 %21,3 %20,0 %−32,5 % / −60,8 USD
DeepSWE 1.111355,8 %62,8 %66,4 %75,2 %−23,7 % / −126,9 USD
τ-2 Bench Airline5064 %64 %64 %66 %−5,9 % / −0,3 USD

Lies die K3-Spalten, bevor du die Ember-Spalte liest. Bei SWE-bench Verified kostet dich der Wechsel von max zu low 12,8 Punkte — das ist das "zu viel Qualität aufgeben", von dem Fireworks spricht, und deshalb konnte ein Effort-Regler allein das Problem ihrer Kunden nicht lösen. Ember-1 landet in jeder Zeile über K3 high und in zwei von fünf über K3 max, bei in allen fünf niedrigeren Kosten als max. Gegen K3 low ist es auf beiden Achsen strikt besser.

Zwei Zeilen verdienen besondere Aufmerksamkeit:

  • τ-2 Bench Airline: 64 % / 64 % / 64 %. Drei Effort-Stufen, ein Ergebnis. In diesem Benchmark ist jedes zusätzliche Denk-Token, das K3 generiert, reine Verschwendung — du zahlst max-Preise für low-Ergebnisse. Wenn deine Produktionsarbeitslast wie τ²-bench aussieht (eine skriptete Kundenservice-Policy, kurze Turns, Tool-Calls gegen eine feste API), dann ist der Effort-Regler eine Kosteneinstellung ohne Qualitätsbedeutung, und du hättest das messen sollen, statt es als Default zu übernehmen. Die allgemeine Gewohnheit — Effort auf deiner Eval durchfahren, bevor du einem Default vertraust — steht in Effort-Tuning und Reasoning-Modelle im Vergleich.
  • SWE-Interact: niemand durchbricht 22 %. Dieselben Modelle, die 92–93 % von SWE-bench Verified lösen, lösen eine Aufgabe von fünf, wenn der Benchmark verlangt, mitten in der Aufgabe mit einem Nutzer zu interagieren. SWE-bench Verified ist nahe an der Sättigung und sagt über ein Frontier-Modell kaum noch etwas; die interaktive Variante ist der Ort, an dem die tatsächliche Fähigkeitslücke lebt. Behalte beide im Kopf, wann immer ein Launch-Post mit einer SWE-bench-Zahl in den Neunzigern aufmacht. Das ist die Fähigkeits-Zuverlässigkeits-Lücke, die als zwei Spalten in einer Tabelle auftaucht.

3. Die Spalte "−51,9 % / −23,1 USD" sagt dir, was ein Benchmark-Durchlauf kostet​

Fireworks beschriftet die beiden Zahlen in dieser letzten Spalte nie. Gelesen als relative Kostenreduktion und absolut gesparte Dollar über den gesamten Durchlauf sind sie in sich konsistent — und eine durch die andere geteilt liefert eine Zahl, die niemand veröffentlicht: was es kostet, diese Benchmarks einmal laufen zu lassen.

Die folgende Arithmetik ist unsere, nicht Fireworks' — sie ist eine Inferenz aus deren zwei veröffentlichten Zahlen, behandle sie also als Größenordnung, nicht als Zitat:

BenchmarkNImplizierte Kosten eines K3-max-DurchlaufsImplizierte Kosten pro Aufgabe
Terminal Bench 2.189~44 $~0,50 $
SWE-bench Verified500~439 $~0,88 $
SWE-Interact75~187 $~2,49 $
DeepSWE 1.1113~535 $~4,74 $
τ-2 Bench Airline50~5 $~0,10 $

Ein einziger DeepSWE-1.1-Durchlauf auf K3 bei max Effort kommt auf grob eine halbe Tausend Dollar — für 113 Aufgaben. Das ist der echte Grund, warum "lass einfach deine eigenen Evals auf jedem Modell laufen" ein Ratschlag ist, bei dem Leute nicken und den sie nicht befolgen, und es ist wissenswert, bevor du einem Stakeholder einen Fünf-Modell-Vergleich versprichst. Es ist auch die Zahl, die eine 24-prozentige Einsparung bedeutsam macht: nächtlich wiederholt ist dieser eine Benchmark ein Posten von 46.000 $ pro Jahr.

Warum 71 % weniger Reasoning nur 39 % weniger Rechnung waren​

Fireworks' interne Validierung berichtet 71,3 % weniger Reasoning-Tokens und 39 % weniger Gesamt-Tokens bei identischem Traffic. Die Lücke zwischen diesen beiden Zahlen ist das Nützlichste in der Ankündigung, und sie verallgemeinert sich auf jede Effizienzbehauptung, die dir jemals verkauft wird.

Reasoning-Tokens sind ein Anteil der generierten Tokens. Der Rest deiner Rechnung besteht aus Dingen, die ein Effizienz-Post-Training nicht anfassen kann:

  • System-Prompt und Tool-Definitionen, in jedem Turn erneut gesendet (oft der größte Einzelblock in einem Agenten).
  • Tool-Ergebnisse — Dateiinhalte, Suchergebnisse, HTTP-Antworten — die aus der Außenwelt in ihrer eigenen Größe ankommen.
  • Die endgültige Antwort, die du eigentlich wolltest.
  • Frühere Turns, als Input zurückgespielt.

Die Obergrenze jeder "weniger Denk-Tokens"-Einsparung ist also dein Reasoning-Token-Anteil, nicht der des Anbieters. Ein Agent, dessen Turns zu 80 % aus Tool-Output bestehen, sieht einen Bruchteil des angekündigten Gewinns; eine Chat-Arbeitslast mit kurzem Prompt und langer Abwägung sieht den größten Teil davon. Bevor du irgendetwas migrierst, miss den Anteil — der nächste Abschnitt zeigt wie. Warum Agenten Tokens verbrennen behandelt die anderen drei Zeilen dieser Liste.

Watch out
  • Der Token-Reduktionsprozentsatz eines Anbieters ist auf dem Traffic-Mix des Anbieters gemessen. Deine Einsparung ist durch deinen eigenen Reasoning-Token-Anteil begrenzt — miss ihn, bevor du irgendetwas schätzt.

Miss es an einem Nachmittag an deinem eigenen Traffic​

Fireworks liefert das Denken des Modells in einem reasoning_content-Feld zurück (der Inhalt, der sonst in Think-Tags stehen würde) und nicht in content. Viele OpenAI-kompatible Wrapper verwerfen unbekannte Felder, und so kommt es, dass Teams nicht beantworten können "welcher Anteil unseres Outputs ist Denken?" — und, schlimmer, dass sie stillschweigend die Multi-Turn-Qualität zerstören.

Guided walkthrough1 of 5
  1. Logge die Länge von reasoning_content neben der Länge von content für jede Assistant-Nachricht, für einen Tag echten Traffics. Das Verhältnis ist dein Reasoning-Token-Anteil und die Obergrenze jeder Effizienzeinsparung, die dir irgendwer verkaufen kann.

Ein Call gegen Ember-1 auf dem OpenAI-kompatiblen Endpunkt

curl https://api.fireworks.ai/inference/v1/chat/completions \
-H "Authorization: Bearer $FIREWORKS_API_KEY" \
-H "Content-Type: application/json" \
-d '{
  "model": "accounts/fireworks/models/ember-1",
  "max_tokens": 8192,
  "messages": [
    {"role": "system", "content": "You are a senior engineer. Reply with a unified diff and one paragraph of rationale."},
    {"role": "user", "content": "The test suite in ./tests fails on macOS only. Log and module attached: ..."}
  ]
}' | jq '{
  reasoning_chars: (.choices[0].message.reasoning_content // "" | length),
  answer_chars: (.choices[0].message.content // "" | length),
  usage: .usage
}'

Das A/B, das du wirklich willst: gleiche Aufgabe, drei Arme, eine Tabelle

# Arm 1 — the incumbent at full effort
MODEL="accounts/fireworks/models/kimi-k3" EFFORT="max"  ./run-evals.sh > k3-max.jsonl

# Arm 2 — the cheap way people try first
MODEL="accounts/fireworks/models/kimi-k3" EFFORT="low"  ./run-evals.sh > k3-low.jsonl

# Arm 3 — the efficiency post-train (no effort setting to choose)
MODEL="accounts/fireworks/models/ember-1"               ./run-evals.sh > ember.jsonl

# Then the only comparison that matters:
#   dollars spent / tasks that passed the gate
jq -s 'group_by(.arm)[] | {arm: .[0].arm,
      passed: (map(select(.passed)) | length),
      usd: (map(.usd) | add),
      cost_per_pass: ((map(.usd) | add) / (map(select(.passed)) | length))}' *.jsonl

Das Kleingedruckte, bevor du migrierst​

Es ist eine Research Preview. Fireworks liefert neue Forschungsmodelle mit zwei Wochen serverlosem Zugang aus und macht sie "based on community demand" permanent. Setze keine unbudgetierte Migration darauf. Baue das A/B, behalte K3 als Fallback-Pfad und prüfe die Verfügbarkeit erneut, bevor du umschaltest — genau für diesen Fall existieren serverseitige Fallbacks und Modell-Routing-Muster.

Die Gewichte sind nicht freigegeben, und das ist legal. Die am höchsten bewertete Verwirrung im Hacker-News-Thread war eine Variante von "sie haben auf offenen Gewichten trainiert und geben ihre nicht frei — dürfen die das?" Sie dürfen. Die Kimi-K3-Lizenz gewährt das Recht, "use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software; to run, deploy, fine-tune, or otherwise modify the Software and create derivative works from it" — ohne Copyleft-Pflicht, das Gebaute zu veröffentlichen. Was sie anhängt, sind zwei umsatzgestaffelte Bedingungen, und die sind wissenswert, ob dich Ember-1 interessiert oder nicht:

  • Model-as-a-Service über 20 Mio. $. Wenn du (und Verbundene) ein MaaS-Geschäft betreibst — Dritten Zugang zu Modell-Inferenz oder Fine-Tuning gebend, z. B. über eine API, mit substanzieller Kontrolle über Inputs, Parameter oder Trainingsdaten —, dessen kombinierter Umsatz 20 Millionen Dollar über beliebige aufeinanderfolgende 12 Monate übersteigt, musst du vor der kommerziellen Nutzung der Software oder ihrer Derivate eine separate Vereinbarung mit Moonshot AI eingehen.
  • Namensnennung über 100 Mio. MAU oder 20 Mio. $/Monat. Ein darauf aufgebautes Produkt oder Dienst, das 100 Millionen monatlich aktive Nutzer oder 20 Millionen Dollar Monatsumsatz überschreitet, muss "Kimi K3" prominent in seiner Benutzeroberfläche anzeigen.

Interne Nutzung, die das Modell oder seine Fähigkeiten Dritten nicht zugänglich macht, ist von der MaaS-Klausel ausgenommen. Die praktische Lesart: Eine Open-Weight-Lizenz kann oben MIT-förmig sein und trotzdem genau die zwei Situationen abriegeln, in denen ein ernstes Unternehmen landet. Lies die Lizenz vor den Benchmarks — derselbe Rat gilt für jede "offene" Frontier-Veröffentlichung auf DeepSeek, Qwen und die Open-Weight-Welle.

Prüfe deine Input-Modalitäten. OpenRouter listet Kimi K3 als text+image+video und Ember-1 als text+image. Fireworks' eigene Modellseite bewirbt Bild-Input für Ember-1 und sagt nichts zu Video. Wenn irgendein Teil deiner Pipeline Video-Frames an K3 schickt, verifiziere diesen Pfad explizit vor dem Wechsel — eine Modalität, die still verschwindet, ist ein viel schlimmerer Fehlschlag als ein Qualitätsabfall, weil sie üblicherweise als fehlerhafter Request in der Produktion auftaucht und nicht als niedrigerer Score in einer Eval.

Prüfe auch deine Sampling-Parameter. OpenRouters Parameterliste für Ember-1 lässt seed und min_p aus, die es beide für K3 listet. Wenn dein Eval-Harness einen Seed für Reproduzierbarkeit festpinnt, bestätige das Verhalten auf dem Endpunkt, den du tatsächlich aufrufen wirst, statt anzunehmen, die Oberfläche des Elternmodells sei übernommen worden. Prompts über Modelle hinweg portieren hat die breitere Checkliste.

Den Specialized Intelligence Index lesen​

Ember-1s andere Schlagzeile — "setzt eine neue Pareto-Frontier auf Bedside Bench über offene und geschlossene Modelle hinweg, einschließlich GPT-5.6 Sol, GPT-6 Astra und Claude Opus 5" — stammt vom Specialized Intelligence Index, den Fireworks am 22. September 2026 startete, einen Tag vor Ember-1. Dieselbe Firma betreibt den Index und liefert das Modell. Das ist nicht automatisch disqualifizierend, aber es verändert, wie du ihn liest.

Was der SII besser macht als die üblichen Leaderboards:

  • Benchmarks kommen von Praktikern, nicht von der Akademie — Doximitys BedsideBench (500 von Ärzten validierte klinische Fälle) für Gesundheit, Harveys juristische Agenten-Benchmarks für Recht, Sierras τ-Banking und τ-Voice sowie Decagons DuetBench für Support, Rogo für Finanzen, Novees PWNBench und depthfirsts dfbench für Security und ein Software-Cluster mit Datacurves DeepSWE und Proximals FrontierSWE V2.
  • Er berichtet Kosten pro Aufgabe und Wanduhrdauer neben dem Score, aus den Preislisten der Anbieter — genau die Achsen, für die diese ganze Seite argumentiert.
  • Er beschriftet jedes Ergebnis damit, wer es reproduzieren kann: jeder, Fireworks-mit-Partner oder nur der Partner. Diese eine Beschriftung ist das nützlichste Stück Leaderboard-Metadaten, das dieses Jahr veröffentlicht wurde; behandle eine partner-only-Zeile als Anbieterbehauptung mit einer schöneren Tabelle darum.
  • Er verweigert einen Gesamtscore. Kein Rollup über Domänen hinweg, keine einzelne "Intelligenz"-Zahl — was die richtige Entscheidung und selten ist.

Was man trotzdem im Kopf behalten sollte: Die Benchmark-Suite, die gewählten Arme, die Effort-Einstellungen und das Modell, das gewinnt, werden alle von derselben Partei ausgewählt. Vergleiche seine Zeilen gegen einen Index, der von jemandem betrieben wird, der kein Modell zu verkaufen hat, bevor du sie in einem Design-Dokument zitierst. Die allgemeine Disziplin steht in Der Verifikations-Flaschenhals.

Solltest du also wechseln?​

  • Agentisches Coding auf K3 bei max Effort, im Volumen: Mache das A/B diese Woche. Das ist genau die Arbeitslast, auf die Ember-1 trainiert wurde, die berichteten Einsparungen liegen bei 15–52 % der Kosten, und DeepSWE 1.1 legt nahe, dass du Genauigkeit gewinnen könntest, statt sie zu tauschen.
  • Läuft schon K3 bei low oder high, weil max zu teuer war: starker Kandidat. Ember-1 schlägt K3 high in allen fünf veröffentlichten Zeilen und dominiert low vollständig.
  • Arbeitslasten in der Form von τ²-bench (kurze Turns, skriptete Policy, viel Tool-Output): erwarte moderate Einsparungen — der Effort-Regler hat für dich ohnehin nichts getan, und dein Reasoning-Token-Anteil ist klein.
  • Alles, was Video-Input, einen festgepinnten Seed oder einen garantierten 12-Monats-Endpunkt braucht: bleib vorerst bei K3 und bewerte neu, wenn die Preview umgewandelt wird.
  • Überhaupt nicht auf Kimi K3: Die übertragbare Lektion ist die Messung, nicht das Modell. Finde deinen Reasoning-Token-Anteil, fahre den Effort-Regler auf deiner eigenen Eval durch und beginne, Kosten pro abgeschlossener Aufgabe statt $/M Tokens zu berichten. Die Version dieser Frage bei jedem Anbieter ist dieselbe Frage.

Check yourself

0/6
  1. Ember-1 kostet pro Token exakt dasselbe wie Kimi K3 (3 $ rein / 15 $ raus pro Million). Woher kommt die berichtete Einsparung von 35–50 %?
  2. Bei τ-2 Bench Airline erreicht Kimi K3 64 % bei low, high UND max Effort. Was sagt dir das?
  3. Fireworks berichtet 71,3 % weniger Reasoning-Tokens, aber nur 39 % weniger Gesamt-Tokens bei identischem Traffic. Warum die Lücke?
  4. Jedes Modell in der Launch-Tabelle erreicht 80–93 % auf SWE-bench Verified, aber 6,7–21,3 % auf SWE-Interact. Was ist die richtige Schlussfolgerung?
  5. Fireworks hat Ember-1 auf den offenen Gewichten von Kimi K3 gebaut und Ember-1s Gewichte nicht freigegeben. Ist das unter der Kimi-K3-Lizenz erlaubt?
  6. Dein Team betreibt einen Agenten, dessen Turns von großen Tool-Outputs dominiert werden (Dateiinhalte, Suchergebnisse). Wie viel der angekündigten 40 % Einsparung solltest du einplanen?
Drücke Enter oder die Leertaste, um die Karte umzudrehen. Nutze die Pfeiltasten links und rechts, um zwischen den Karten zu wechseln.Begriff angezeigt.
1 / 9

Weiter​

  • Kimi K3: die Open-Weight-Frontier — das Elternmodell, auf dem Ember-1 aufbaut: die MoE-Arithmetik, KDA-Attention und wo K3 gegenüber Claude steht
  • Effort-Tuning — wie du einen Reasoning-Regler auf deiner eigenen Eval durchfährst, statt einen Default zu erben
  • Warum Agenten Tokens verbrennen — die anderen Posten auf der Rechnung, die kein Effizienz-Post-Training schrumpfen lässt

Quellen & weiterführende Literatur​