Aller au contenu principal

Ember-1 : les réponses de Kimi K3 pour 40 % de tokens en moins (sept. 2026)

Intermédiaire

Le 23 septembre 2026, Fireworks a publié Ember-1 : ni une nouvelle architecture, ni un nouveau pré-entraînement — Kimi K3 avec son habitude de raisonnement ré-entraînée. Même corps de 2 800 milliards de paramètres, même contexte d'un million, même prix par token. Il arrête simplement de tant réfléchir. Fireworks rapporte 35 à 50 % de tokens de raisonnement en moins sans perte de précision, et sur deux des cinq benchmarks publiés, Ember-1 dépasse K3 tournant à son réglage d'effort maximal tout en coûtant moins cher.

Quatre jours plus tard, c'était le premier sujet IA sur Hacker News. La partie intéressante n'est pas le modèle — c'est l'affirmation qui le sous-tend : la façon la moins chère de faire tourner un modèle de raisonnement n'est plus de lui dire de moins réfléchir. Cette page démonte cette affirmation, vous montre l'arithmétique que le tableau de lancement implique sans jamais l'imprimer, et vous donne un moyen de la tester sur votre propre trafic en une après-midi.

What you'll learn
  • Séparer les deux choses qui rendent un agent coûteux : le prix par token, et le nombre de tokens — Ember-1 ne change que le second
  • Lire honnêtement le tableau de lancement, y compris le benchmark où l'effort n'achète littéralement rien et celui où tous les modèles scorent sous 22 %
  • Déduire le coût par tâche que le billet n'imprime pas (et découvrir qu'une seule exécution de benchmark coûte entre 5 et 535 $)
  • Comprendre pourquoi une réduction de 71 % des tokens de raisonnement n'a produit qu'une baisse de 39 % du total des tokens — et ce que ce ratio dit de votre propre facture
  • Mesurer la part de tokens de raisonnement sur votre charge de travail avec un champ que la plupart des wrappers de SDK jettent
  • Connaître les petits caractères avant de migrer : statut de research preview, poids non publiés, une modalité d'entrée perdue, et la licence Kimi K3 à paliers de revenus qui sous-tend le tout

La version en un paragraphe​

Kimi K3, comme tout modèle de raisonnement, dépense la majeure partie de ses tokens générés en raisonnement interne — Fireworks l'évalue à parfois plus de 90 %. Dans un agent multi-tours, ce raisonnement est rejoué dans chaque appel ultérieur : le contexte croît donc à peu près quadratiquement avec le nombre de tours, et la réflexion initiale est refacturée pendant tout le reste de l'exécution. Les clients de Fireworks demandaient la qualité de codage de K3 à moindre coût ; baisser reasoning_effort sacrifiait trop de qualité, alors Fireworks a entraîné le comportement à la place — plus de 50 entraînements et plus de 200 évaluations — en apprenant au modèle à conserver l'auto-réflexion qui permet de se rattraper après une erreur, et à abandonner le reste. Le résultat est servi sous accounts/fireworks/models/ember-1 aux tarifs exacts de K3 : 3 $/M d'entrée non mise en cache, 0,30 $/M d'entrée en cache, 15 $/M de sortie.

Trois choses que le titre dissimule​

1. Rien n'est devenu moins cher. Le modèle achète simplement moins.​

C'est la partie qui recadre votre façon de penser le coût d'un modèle. La grille tarifaire d'Ember-1 est identique à celle de Kimi K3, sur Fireworks comme sur OpenRouter (3 $ d'entrée / 15 $ de sortie le million, contexte de 1 048 576 tokens des deux côtés). Il n'y a aucune remise. Chaque dollar économisé provient de tokens qui ne sont jamais générés au départ — et, dans une boucle d'agent, du fait que ces mêmes tokens ne sont jamais rejoués en entrée lors des dix-neuf tours suivants.

Cela a une conséquence pratique : le $/token est le mauvais chiffre sur votre tableau de bord. Deux modèles au même prix affiché peuvent différer d'un facteur 2 sur la même tâche, et le modèle au prix affiché le plus élevé est régulièrement le moins cher par tâche terminée. L'article Ce que coûte l'IA selon les fournisseurs d'AILmanac fait le même constat du côté de la tarification ; Ember-1 en est l'expérience naturelle la plus propre à ce jour, parce que la variable prix est figée et que seul le nombre de tokens bouge.

2. Baisser l'effort n'est pas la même chose, et le tableau le prouve​

K3 expose reasoning_effort aux niveaux low, high et max. Fireworks a exécuté les trois comme des bras distincts, ce qui rend leur tableau plus utile que la plupart des tableaux de lancement :

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

Lisez les colonnes K3 de haut en bas avant de lire la colonne Ember. Sur SWE-bench Verified, passer de max à low vous coûte 12,8 points — c'est le « trop de qualité sacrifiée » dont parle Fireworks, et c'est pourquoi une simple molette d'effort ne pouvait pas résoudre le problème de leurs clients. Ember-1 se place au-dessus de K3 high sur chaque ligne et au-dessus de K3 max sur deux sur cinq, à un coût inférieur à max sur les cinq. Face à K3 low, il est strictement meilleur sur les deux axes.

Deux lignes méritent une attention séparée :

  • τ-2 Bench Airline : 64 % / 64 % / 64 %. Trois niveaux d'effort, un seul score. Sur ce benchmark, chaque token de réflexion supplémentaire généré par K3 est du pur gaspillage — vous payez le tarif max pour un résultat low. Si votre charge de production ressemble à τ²-bench (une politique de service client scriptée, des tours courts, des appels d'outils sur une API fixe), la molette d'effort est un réglage de coût sans signification qualitative, et vous auriez dû le mesurer plutôt que de l'adopter par défaut. L'habitude générale — balayer l'effort sur votre évaluation avant de faire confiance à une valeur par défaut — se trouve dans Réglage de l'effort et Comparaison des modèles de raisonnement.
  • SWE-Interact : personne ne dépasse 22 %. Les mêmes modèles qui résolvent 92 à 93 % de SWE-bench Verified en résolvent une sur cinq lorsque le benchmark exige d'interagir avec un utilisateur en cours de tâche. SWE-bench Verified est proche de la saturation et ne vous apprend presque plus rien sur un modèle de frontière ; c'est dans la variante interactive que se loge le véritable écart de capacité. Gardez les deux à l'esprit chaque fois qu'un billet de lancement ouvre sur un score SWE-bench à plus de 90. C'est l'écart capacité–fiabilité qui apparaît sous forme de deux colonnes dans un même tableau.

3. La colonne « −51,9 % / −23,1 USD » vous dit ce que coûte une exécution de benchmark​

Fireworks n'étiquette jamais les deux chiffres de cette dernière colonne. Lus comme une réduction relative de coût et des dollars absolus économisés sur toute l'exécution, ils sont cohérents entre eux — et diviser l'un par l'autre restitue un nombre que personne ne publie : ce que coûte une exécution de ces benchmarks.

L'arithmétique ci-dessous est la nôtre, pas celle de Fireworks — c'est une inférence à partir de leurs deux chiffres publiés, alors traitez-la comme un ordre de grandeur, pas comme une citation :

BenchmarkNCoût implicite d'une exécution K3-maxCoût implicite par tâche
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 seul balayage DeepSWE 1.1 sur K3 à effort maximal revient à environ un demi-millier de dollars — pour 113 tâches. C'est la vraie raison pour laquelle « lancez simplement vos propres évaluations sur chaque modèle » est un conseil que les gens approuvent de la tête sans le suivre, et cela vaut la peine de le savoir avant de promettre à une partie prenante un comparatif sur cinq modèles. C'est aussi le chiffre qui rend une économie de 24 % significative : répétée chaque nuit, ce seul benchmark est un poste de 46 000 $ par an.

Pourquoi 71 % de raisonnement en moins n'a fait que 39 % de facture en moins​

La validation interne de Fireworks rapporte 71,3 % de tokens de raisonnement en moins et 39 % de tokens au total en moins sur le même trafic. L'écart entre ces deux chiffres est la chose la plus utile de l'annonce, et il se généralise à n'importe quelle promesse d'efficacité qu'on vous fera un jour.

Les tokens de raisonnement sont une part des tokens générés. Le reste de votre facture est fait de choses qu'un post-entraînement d'efficacité ne peut pas toucher :

  • Le prompt système et les définitions d'outils, renvoyés à chaque tour (souvent le plus gros bloc unique d'un agent).
  • Les résultats d'outils — contenus de fichiers, résultats de recherche, réponses HTTP — qui arrivent du monde extérieur à leur propre taille.
  • La réponse finale, celle que vous vouliez réellement.
  • Les tours précédents, rejoués en entrée.

Le plafond de toute économie de type « moins de tokens de réflexion » est donc votre part de tokens de raisonnement, pas celle de l'éditeur. Un agent dont les tours sont à 80 % de la sortie d'outils ne verra qu'une fraction du gain annoncé ; une charge conversationnelle avec un prompt court et une longue délibération en verra l'essentiel. Avant de migrer quoi que ce soit, mesurez la part — la section suivante montre comment. Pourquoi les agents brûlent des tokens couvre les trois autres lignes de cette liste.

Watch out
  • Le pourcentage de réduction de tokens d'un éditeur est mesuré sur le mix de trafic de cet éditeur. Votre économie est bornée par votre propre part de tokens de raisonnement — mesurez-la avant d'estimer quoi que ce soit.

Mesurez-le sur votre propre trafic en une après-midi​

Fireworks renvoie la réflexion du modèle dans un champ reasoning_content (le contenu qui se trouverait sinon à l'intérieur des balises think) plutôt que dans content. Beaucoup de wrappers compatibles OpenAI suppriment les champs inconnus, ce qui explique pourquoi des équipes se retrouvent incapables de répondre à « quelle part de notre sortie est de la réflexion ? » — et, pire, pourquoi elles cassent silencieusement la qualité multi-tours.

Guided walkthrough1 of 5
  1. Consignez la longueur de reasoning_content à côté de celle de content pour chaque message d'assistant, sur une journée de trafic réel. Le ratio est votre part de tokens de raisonnement et le plafond de toute économie d'efficacité que quiconque peut vous vendre.

Un appel vers Ember-1 sur l'endpoint compatible OpenAI

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 que vous voulez vraiment : même tâche, trois bras, un tableau

# 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

Les petits caractères avant de migrer​

C'est une Research Preview. Fireworks livre ses nouveaux modèles de recherche avec deux semaines d'accès serverless et les rend permanents « selon la demande de la communauté ». Ne placez pas une migration non budgétée derrière cela. Construisez l'A/B, gardez K3 comme voie de repli, et revérifiez la disponibilité avant de basculer — c'est exactement le cas d'usage des replis côté serveur et des schémas de routage de modèles.

Les poids ne sont pas publiés, et c'est légal. La confusion la plus votée dans le fil Hacker News était une variante de « ils se sont entraînés sur des poids ouverts et ne publient pas les leurs — ont-ils le droit ? ». Oui. La licence Kimi K3 accorde le droit d'« utiliser, copier, modifier, fusionner, publier, distribuer, sous-licencier et/ou vendre des copies du Logiciel ; d'exécuter, déployer, affiner ou autrement modifier le Logiciel et d'en créer des œuvres dérivées » — sans obligation de copyleft de publier ce que vous construisez. Ce qu'elle attache en revanche, ce sont deux conditions à paliers de revenus, bonnes à connaître, que vous vous souciiez ou non d'Ember-1 :

  • Model-as-a-Service au-delà de 20 M$. Si vous (et vos sociétés affiliées) exploitez une activité MaaS — donner à des tiers l'accès à l'inférence ou au fine-tuning du modèle, par exemple via une API, avec un contrôle significatif sur les entrées, les paramètres ou les données d'entraînement — dont le chiffre d'affaires cumulé dépasse 20 millions de dollars sur 12 mois consécutifs quelconques, vous devez conclure un accord séparé avec Moonshot AI avant toute utilisation commerciale du Logiciel ou de ses œuvres dérivées.
  • Attribution au-delà de 100 M d'utilisateurs actifs mensuels ou de 20 M$/mois. Un produit ou service bâti dessus qui dépasse 100 millions d'utilisateurs actifs mensuels ou 20 millions de dollars de revenus mensuels doit afficher « Kimi K3 » de manière visible dans son interface utilisateur.

L'usage interne qui n'expose ni le modèle ni ses capacités à des tiers est exempté de la clause MaaS. La lecture pratique : une licence de poids ouverts peut avoir la forme d'une MIT en surface et tout de même verrouiller les deux situations dans lesquelles une entreprise sérieuse finit par se trouver. Lisez la licence avant les benchmarks — le même conseil s'applique à chaque publication « ouverte » de frontière dans DeepSeek, Qwen et la vague des poids ouverts.

Vérifiez vos modalités d'entrée. OpenRouter liste Kimi K3 en text+image+video et Ember-1 en text+image. La page de modèle de Fireworks elle-même annonce l'entrée image pour Ember-1 et ne dit rien de la vidéo. Si une partie de votre pipeline envoie des images de vidéo à K3, vérifiez explicitement ce chemin avant de basculer — une modalité qui disparaît silencieusement est une bien pire défaillance qu'une baisse de qualité, parce qu'elle se manifeste généralement par une requête malformée en production plutôt que par un score plus bas dans une évaluation.

Vérifiez aussi vos paramètres d'échantillonnage. La liste de paramètres d'OpenRouter pour Ember-1 omet seed et min_p, tous deux listés pour K3. Si votre harnais d'évaluation fige une seed pour la reproductibilité, confirmez le comportement sur l'endpoint que vous appellerez réellement plutôt que de supposer que la surface du modèle parent a été reprise. Porter des prompts d'un modèle à l'autre contient la liste de contrôle élargie.

Lire le Specialized Intelligence Index​

L'autre titre d'Ember-1 — « établit une nouvelle frontière de Pareto sur Bedside Bench parmi les modèles ouverts et fermés, y compris GPT-5.6 Sol, GPT-6 Astra et Claude Opus 5 » — provient du Specialized Intelligence Index, que Fireworks a lancé le 22 septembre 2026, un jour avant Ember-1. La même entreprise gère l'index et livre le modèle. Ce n'est pas automatiquement disqualifiant, mais cela change la manière de le lire.

Ce que le SII fait mieux que le classement habituel :

  • Les benchmarks viennent de praticiens, pas du monde académique — BedsideBench de Doximity (500 cas cliniques validés par des médecins) pour la santé, les benchmarks d'agents juridiques de Harvey pour le droit, τ-Banking et τ-Voice de Sierra et DuetBench de Decagon pour le support, Rogo pour la finance, PWNBench de Novee et dfbench de depthfirst pour la sécurité, et une grappe logicielle incluant DeepSWE de Datacurve et FrontierSWE V2 de Proximal.
  • Il rapporte le coût par tâche et la durée réelle à côté du score, depuis les grilles tarifaires des fournisseurs — les axes que toute cette page défend.
  • Il étiquette chaque résultat selon qui peut le reproduire : tout le monde, Fireworks-avec-partenaire, ou partenaire uniquement. Cette seule étiquette est la métadonnée de classement la plus utile publiée cette année ; traitez une ligne « partenaire uniquement » comme une affirmation d'éditeur entourée d'un plus joli tableau.
  • Il refuse un score composite. Aucun agrégat entre domaines, aucun chiffre unique d'« intelligence » — ce qui est le bon choix, et c'est rare.

Ce qu'il faut garder à l'esprit malgré tout : la suite de benchmarks, les bras choisis, les réglages d'effort et le modèle gagnant sont tous sélectionnés par la même partie. Comparez ses lignes à celles d'un index géré par quelqu'un qui n'a aucun modèle à vendre avant de les citer dans un document de conception. La discipline générale est décrite dans Le goulot d'étranglement de la vérification.

Alors, faut-il basculer ?​

  • Codage agentique sur K3 à effort max, en volume : lancez l'A/B cette semaine. C'est exactement la charge de travail sur laquelle Ember-1 a été entraîné, les économies rapportées sont de 15 à 52 % du coût, et DeepSWE 1.1 suggère que vous pourriez gagner en précision plutôt que la troquer.
  • Vous faites déjà tourner K3 en low ou high parce que max était trop cher : candidat sérieux. Ember-1 bat K3 high sur les cinq lignes publiées et domine low sans appel.
  • Charges de travail de la forme de τ²-bench (tours courts, politique scriptée, forte sortie d'outils) : attendez-vous à des économies modestes — la molette d'effort ne vous apportait déjà rien, et votre part de tokens de raisonnement est faible.
  • Tout ce qui nécessite une entrée vidéo, une seed figée ou un endpoint garanti 12 mois : restez sur K3 pour l'instant et réévaluez quand la preview sera convertie.
  • Vous n'êtes pas du tout sur Kimi K3 : la leçon transférable est la mesure, pas le modèle. Trouvez votre part de tokens de raisonnement, balayez la molette d'effort sur votre propre évaluation, et commencez à reporter le coût par tâche terminée au lieu du $/M de tokens. La version de cette question chez chaque fournisseur est la même question.

Check yourself

0/6
  1. Ember-1 coûte exactement le même prix par token que Kimi K3 (3 $ en entrée / 15 $ en sortie le million). D'où vient l'économie rapportée de 35 à 50 % ?
  2. Sur τ-2 Bench Airline, Kimi K3 obtient 64 % aux efforts low, high ET max. Qu'est-ce que cela vous dit ?
  3. Fireworks rapporte 71,3 % de tokens de raisonnement en moins mais seulement 39 % de tokens au total en moins sur le même trafic. D'où vient l'écart ?
  4. Tous les modèles du tableau de lancement obtiennent 80 à 93 % sur SWE-bench Verified mais 6,7 à 21,3 % sur SWE-Interact. Quelle est la bonne conclusion ?
  5. Fireworks a construit Ember-1 sur les poids ouverts de Kimi K3 et n'a pas publié les poids d'Ember-1. Sous la licence Kimi K3, est-ce autorisé ?
  6. Votre équipe exploite un agent dont les tours sont dominés par de grosses sorties d'outils (contenus de fichiers, résultats de recherche). Quelle part de l'économie annoncée de 40 % devriez-vous budgéter ?
Appuyez sur Entrée ou Espace pour retourner la carte. Utilisez les flèches gauche et droite pour naviguer entre les cartes.Terme affiché.
1 / 9

Suite​

Sources et lectures complémentaires​