Passa al contenuto principale

Ember-1: le risposte di Kimi K3 con il 40% di token in meno (set 2026)

Intermedio

Il 23 settembre 2026 Fireworks ha pubblicato Ember-1: non una nuova architettura, non un nuovo pre-training — Kimi K3 con la sua abitudine di ragionamento ri-addestrata. Stesso corpo da 2,8 trilioni di parametri, stesso contesto da 1M, stesso prezzo per token. Semplicemente smette di pensare così tanto. Fireworks riporta 35-50% di token di ragionamento in meno senza perdita di accuratezza, e su due dei cinque benchmark pubblicati Ember-1 supera K3 impostato sul massimo sforzo costando meno.

Quattro giorni dopo era la notizia AI in cima a Hacker News. La parte interessante non è il modello — è l'affermazione che ci sta sotto: il modo più economico di far girare un modello di ragionamento non è più dirgli di pensare meno. Questa pagina smonta quell'affermazione, mostra l'aritmetica che la tabella di lancio implica ma non stampa mai, e ti dà un modo per testarla sul tuo traffico in un pomeriggio.

What you'll learn
  • Separare le due cose che rendono costoso un agente: prezzo per token e numero di token — Ember-1 cambia solo il secondo
  • Leggere la tabella di lancio con onestà, compresi il benchmark in cui lo sforzo non compra letteralmente nulla e quello in cui ogni modello resta sotto il 22%
  • Ricavare il costo per task che il blog non stampa (e scoprire che una singola esecuzione di benchmark costa tra 5 e 535 dollari)
  • Capire perché un taglio del 71% sui token di ragionamento ha prodotto solo un taglio del 39% sui token totali — e cosa dice quel rapporto sulla tua bolletta
  • Misurare la quota di token di ragionamento sul tuo carico di lavoro con un campo che la maggior parte dei wrapper SDK butta via
  • Conoscere le clausole in piccolo prima di migrare: stato di research preview, pesi non rilasciati, una modalità di input persa e la licenza Kimi K3 a soglie di ricavo che sta sotto a tutto

La versione in un paragrafo​

Kimi K3, come ogni modello di ragionamento, spende la maggior parte dei token che genera sul ragionamento interno — Fireworks lo quantifica a volte oltre il 90%. In un agente multi-turno quel ragionamento viene rigiocato dentro ogni chiamata successiva, quindi il contesto cresce più o meno in modo quadratico con il numero di turni e il pensiero iniziale viene rifatturato per tutto il resto dell'esecuzione. I clienti di Fireworks chiedevano la qualità di K3 sul codice a costi più bassi; abbassare reasoning_effort sacrificava troppa qualità, così Fireworks ha addestrato direttamente il comportamento — oltre 50 run di training e più di 200 valutazioni — insegnando al modello a tenere l'auto-riflessione che permette di recuperare dagli errori e a lasciare il resto. Il risultato è servito come accounts/fireworks/models/ember-1 esattamente alle tariffe di K3: 3 $ / M di input non in cache, 0,30 $ / M di input in cache, 15 $ / M di output.

Tre cose che il titolo nasconde​

1. Nulla è diventato più economico. Il modello compra solo meno.​

Questa è la parte che riformula il modo in cui dovresti pensare al costo di un modello. Il listino di Ember-1 è identico a quello di Kimi K3, sia su Fireworks sia su OpenRouter (3 $ di input / 15 $ di output per milione, contesto da 1.048.576 token su entrambi). Non c'è nessuno sconto. Ogni dollaro risparmiato viene da token che non vengono generati affatto — e, in un loop agentico, dal fatto che quegli stessi token non vengono rigiocati come input nei diciannove turni successivi.

Questo ha una conseguenza pratica: $/token è il numero sbagliato sulla tua dashboard. Due modelli allo stesso prezzo di listino possono differire di 2× sullo stesso task, e il modello con il prezzo di listino più alto è regolarmente quello più economico per task completato. Quanto costa l'AI tra i vari provider di AILmanac fa lo stesso ragionamento dal lato dei prezzi; Ember-1 è l'esperimento naturale più pulito finora, perché la variabile prezzo è fissata e si muove solo il conteggio dei token.

2. Abbassare lo sforzo non è la stessa cosa, e la tabella lo dimostra​

K3 espone reasoning_effort con i valori low, high e max. Fireworks ha eseguito tutti e tre come rami separati, ed è questo che rende la loro tabella più utile della maggior parte delle tabelle di lancio:

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

Leggi in verticale le colonne di K3 prima di leggere quella di Ember. Su SWE-bench Verified, scendere da max a low ti costa 12,8 punti — è questo il "sacrificare troppa qualità" di cui parla Fireworks, ed è il motivo per cui una manopola dello sforzo da sola non poteva risolvere il problema dei loro clienti. Ember-1 si colloca sopra K3 high su ogni riga e sopra K3 max su due su cinque, a un costo inferiore a max su tutte e cinque. Contro K3 low è strettamente migliore su entrambi gli assi.

Due righe meritano attenzione a parte:

  • τ-2 Bench Airline: 64% / 64% / 64%. Tre livelli di sforzo, un solo punteggio. Su questo benchmark ogni token di pensiero in più che K3 genera è puro spreco — paghi prezzi da max per risultati da low. Se il tuo carico di lavoro in produzione assomiglia a τ²-bench (una policy di customer service scriptata, turni brevi, chiamate a tool su un'API fissa), la manopola dello sforzo è un'impostazione di costo senza significato di qualità, e avresti dovuto misurarlo invece di accettare il default. L'abitudine generale — fare uno sweep dello sforzo sulla tua eval prima di fidarti di un default — sta in Tuning dello sforzo e Modelli di ragionamento a confronto.
  • SWE-Interact: nessuno supera il 22%. Gli stessi modelli che risolvono il 92-93% di SWE-bench Verified risolvono un task su cinque quando il benchmark richiede di interagire con un utente a metà task. SWE-bench Verified è vicino alla saturazione e non dice quasi più nulla su un modello di frontiera; la variante interattiva è dove vive il vero divario di capacità. Tieni presenti entrambi ogni volta che un post di lancio apre con un numero di SWE-bench sopra il 90. È il divario capacità-affidabilità che si manifesta come due colonne nella stessa tabella.

3. La colonna "−51,9% / −23,1 USD" ti dice quanto costa un'esecuzione di benchmark​

Fireworks non etichetta mai le due cifre in quell'ultima colonna. Lette come riduzione di costo relativa e dollari assoluti risparmiati sull'intera esecuzione, sono internamente coerenti — e dividendo una per l'altra si recupera un numero che nessuno pubblica: quanto costa eseguire questi benchmark una volta.

L'aritmetica qui sotto è nostra, non di Fireworks — è un'inferenza dalle loro due cifre pubblicate, quindi trattala come un ordine di grandezza, non come una citazione:

BenchmarkNCosto implicito dell'esecuzione K3-maxCosto implicito per task
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 $

Un singolo sweep di DeepSWE 1.1 su K3 al massimo sforzo arriva a circa mezzo migliaio di dollari — per 113 task. È la vera ragione per cui "basta far girare le tue eval su ogni modello" è un consiglio che la gente approva con la testa e non segue, e vale la pena saperlo prima di promettere a uno stakeholder un confronto a cinque modelli. È anche il numero che rende rilevante un risparmio del 24%: ripetuto ogni notte, quel singolo benchmark è una voce di costo da 46.000 dollari all'anno.

Perché il 71% in meno di ragionamento è stato solo il 39% in meno sulla bolletta​

La validazione interna di Fireworks riporta 71,3% di token di ragionamento in meno e 39% di token totali in meno sullo stesso traffico. Il divario tra questi due numeri è la cosa più utile dell'annuncio, e si generalizza a qualunque affermazione di efficienza ti venga mai proposta.

I token di ragionamento sono una quota dei token generati. Il resto della tua bolletta è fatto di cose che un post-training di efficienza non può toccare:

  • System prompt e definizioni dei tool, rimandati a ogni turno (spesso il blocco singolo più grande in un agente).
  • Risultati dei tool — contenuti di file, risultati di ricerca, risposte HTTP — che arrivano dal mondo esterno con la loro dimensione.
  • La risposta finale, quella che volevi davvero.
  • I turni precedenti, rigiocati come input.

Quindi il tetto a qualunque risparmio da "meno token di pensiero" è la tua quota di token di ragionamento, non quella del vendor. Un agente i cui turni sono per l'80% output di tool vedrà una frazione del guadagno pubblicizzato; un carico di lavoro conversazionale con prompt corto e deliberazione lunga ne vedrà la maggior parte. Prima di migrare qualsiasi cosa, misura la quota — la sezione successiva mostra come. Perché gli agenti bruciano token copre le altre tre voci di quell'elenco.

Watch out
  • La percentuale di riduzione dei token di un vendor è misurata sul mix di traffico del vendor. Il tuo risparmio è limitato dalla tua quota di token di ragionamento — misurala prima di stimare qualsiasi cosa.

Misuralo sul tuo traffico in un pomeriggio​

Fireworks restituisce il pensiero del modello in un campo reasoning_content (il contenuto che altrimenti starebbe dentro i tag think) invece che in content. Molti wrapper OpenAI-compatibili scartano i campi che non conoscono, ed è così che i team finiscono per non poter rispondere a "che quota del nostro output è pensiero?" — e, peggio, è così che rompono in silenzio la qualità multi-turno.

Guided walkthrough1 of 5
  1. Registra la lunghezza di reasoning_content accanto alla lunghezza di content per ogni messaggio dell'assistente, per una giornata di traffico reale. Il rapporto è la tua quota di token di ragionamento e il tetto a qualunque risparmio di efficienza qualcuno possa venderti.

Una chiamata contro Ember-1 sull'endpoint OpenAI-compatibile

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
}'

L'A/B che vuoi davvero: stesso task, tre rami, una tabella

# 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

Le clausole in piccolo prima di migrare​

È una Research Preview. Fireworks rilascia i nuovi modelli di ricerca con due settimane di accesso serverless e li rende permanenti "in base alla richiesta della community". Non metterci dietro una migrazione non messa a budget. Costruisci l'A/B, tieni K3 come percorso di fallback e ricontrolla la disponibilità prima di fare il passaggio — è esattamente il caso per cui esistono i fallback lato server e i pattern di routing dei modelli.

I pesi non sono stati rilasciati, ed è legale. La confusione più votata nel thread di Hacker News era una qualche versione di "hanno addestrato su pesi aperti e non rilasciano i propri — possono farlo?". Possono. La licenza di Kimi K3 concede il diritto di "usare, copiare, modificare, unire, pubblicare, distribuire, sublicenziare e/o vendere copie del Software; di eseguire, distribuire, fare fine-tuning o altrimenti modificare il Software e creare opere derivate da esso" — senza alcun obbligo di copyleft a pubblicare ciò che costruisci. Ciò che invece allega sono due condizioni a soglie di ricavo, e vale la pena conoscerle a prescindere da quanto ti interessi Ember-1:

  • Model-as-a-Service sopra i 20 milioni di dollari. Se tu (e le tue affiliate) gestisci un business MaaS — dando a terzi accesso all'inferenza o al fine-tuning di un modello, per esempio via API, con controllo significativo su input, parametri o dati di addestramento — i cui ricavi combinati superano i 20 milioni di dollari in qualunque periodo di 12 mesi consecutivi, devi stipulare un accordo separato con Moonshot AI prima dell'uso commerciale del Software o delle sue opere derivate.
  • Attribuzione sopra i 100 milioni di utenti attivi mensili o i 20 milioni di dollari al mese. Un prodotto o servizio costruito su di esso che superi i 100 milioni di utenti attivi mensili o i 20 milioni di dollari di ricavi mensili deve mostrare "Kimi K3" in modo visibile nella propria interfaccia utente.

L'uso interno che non espone il modello o le sue capacità a terzi è esente dalla clausola MaaS. La lettura pratica: una licenza open-weight può avere la forma della MIT in cima e comunque mettere un cancello davanti alle due situazioni in cui un business serio finisce. Leggi la licenza prima dei benchmark — lo stesso consiglio vale per ogni rilascio "aperto" di frontiera in DeepSeek, Qwen e l'onda dei pesi aperti.

Controlla le tue modalità di input. OpenRouter elenca Kimi K3 come text+image+video e Ember-1 come text+image. La pagina del modello di Fireworks pubblicizza l'input immagine per Ember-1 e non dice nulla sul video. Se una qualunque parte della tua pipeline manda frame video a K3, verifica quel percorso in modo esplicito prima di passare — una modalità che sparisce in silenzio è un guasto molto peggiore di un calo di qualità, perché di solito emerge come richiesta malformata in produzione invece che come punteggio più basso in una eval.

Controlla anche i tuoi parametri di sampling. L'elenco dei parametri di OpenRouter per Ember-1 omette seed e min_p, entrambi elencati per K3. Se il tuo harness di eval fissa un seed per la riproducibilità, verifica il comportamento sull'endpoint che chiamerai davvero invece di dare per scontato che la superficie del modello padre sia stata trasferita. Portare i prompt tra modelli diversi ha la checklist più ampia.

Come leggere lo Specialized Intelligence Index​

L'altro titolo di Ember-1 — "stabilisce una nuova frontiera di Pareto su Bedside Bench tra modelli aperti e chiusi, inclusi GPT-5.6 Sol, GPT-6 Astra e Claude Opus 5" — viene dallo Specialized Intelligence Index, che Fireworks ha lanciato il 22 settembre 2026, un giorno prima di Ember-1. La stessa azienda gestisce l'indice e rilascia il modello. Non è automaticamente squalificante, ma cambia il modo in cui lo leggi.

Ciò che il SII fa meglio della leaderboard tipica:

  • I benchmark vengono da chi lavora nel settore, non dall'accademia — BedsideBench di Doximity (500 casi clinici validati da medici) per la sanità, i benchmark per agenti legali di Harvey per il diritto, τ-Banking e τ-Voice di Sierra e DuetBench di Decagon per il supporto, Rogo per la finanza, PWNBench di Novee e dfbench di depthfirst per la sicurezza, e un cluster software che include DeepSWE di Datacurve e FrontierSWE V2 di Proximal.
  • Riporta il costo per task e la durata effettiva accanto al punteggio, partendo dai listini dei provider — gli assi per cui questa pagina intera sta argomentando.
  • Etichetta ogni risultato in base a chi può riprodurlo: chiunque, Fireworks-con-partner, o solo-partner. Quella singola etichetta è il pezzo di metadato da leaderboard più utile pubblicato quest'anno; tratta una riga solo-partner come un'affermazione del vendor con una tabella più bella intorno.
  • Rifiuta un punteggio composito. Nessun aggregato tra domini, nessun singolo numero di "intelligenza" — che è la scelta giusta, e rara.

Cosa tenere comunque a mente: la selezione dei benchmark, i rami scelti, le impostazioni di sforzo e il modello che vince sono tutti selezionati dalla stessa parte. Confronta le sue righe con un indice gestito da qualcuno che non ha modelli da vendere prima di citarle in un documento di progetto. La disciplina generale sta in Il collo di bottiglia della verifica.

Quindi dovresti passare?​

  • Coding agentico su K3 a sforzo max, a volume: fai l'A/B questa settimana. È esattamente il carico di lavoro su cui Ember-1 è stato addestrato, i risparmi riportati sono il 15-52% del costo, e DeepSWE 1.1 suggerisce che potresti guadagnare accuratezza invece di scambiarla.
  • Già su K3 a low o high perché max era troppo costoso: candidato forte. Ember-1 batte K3 high su tutte e cinque le righe pubblicate e domina low in modo netto.
  • Carichi di lavoro con la forma di τ²-bench (turni brevi, policy scriptata, molto output dai tool): aspettati risparmi modesti — la manopola dello sforzo non stava già facendo nulla per te, e la tua quota di token di ragionamento è piccola.
  • Qualunque cosa richieda input video, un seed fissato o un endpoint garantito per 12 mesi: resta su K3 per ora e rivaluta quando la preview si consoliderà.
  • Non sei su Kimi K3 affatto: la lezione trasferibile è la misurazione, non il modello. Trova la tua quota di token di ragionamento, fai uno sweep della manopola dello sforzo sulla tua eval, e inizia a riportare il costo per task completato invece dei $/M token. La versione di questa domanda di ogni provider è la stessa domanda.

Check yourself

0/6
  1. Ember-1 costa esattamente come Kimi K3 per token (3 $ in ingresso / 15 $ in uscita per milione). Da dove viene il risparmio riportato del 35-50%?
  2. Su τ-2 Bench Airline, Kimi K3 fa 64% a sforzo low, high E max. Cosa ti dice questo?
  3. Fireworks riporta 71,3% di token di ragionamento in meno ma solo 39% di token totali in meno sullo stesso traffico. Perché il divario?
  4. Ogni modello nella tabella di lancio fa 80-93% su SWE-bench Verified ma 6,7-21,3% su SWE-Interact. Qual è la conclusione corretta?
  5. Fireworks ha costruito Ember-1 sui pesi aperti di Kimi K3 e non ha rilasciato i pesi di Ember-1. Secondo la licenza di Kimi K3, è permesso?
  6. Il tuo team gestisce un agente i cui turni sono dominati da grandi output dei tool (contenuti di file, risultati di ricerca). Quanto del 40% di risparmio pubblicizzato dovresti mettere a budget?
Premi Invio o Spazio per girare la carta. Usa le frecce sinistra e destra per spostarti tra le carte.Termine mostrato.
1 / 9

Prossimi passi​

Fonti e approfondimenti​