Ember-1 réduit de 40 % le raisonnement de Kimi K3 — et tout se joue dans les petits caractères

Le chiffre qui sera cité est 40 %. Fireworks Research a publié Ember-1 le 23 septembre 2026, en le présentant comme un dérivé spécialisé de Kimi K3 de Moonshot AI, qui conserve la précision de K3 tout en dépensant environ 40 % de tokens en moins pour y parvenir. Il s'agit d'une affirmation bien réelle et inhabituellement précise, et elle s'accompagne de trois éléments : une fiche de benchmarks complète avec des colonnes de réduction de tokens, deux tests A/B clients issus du trafic de codage en production, et un statut de publication qui n'est pas celui d'une disponibilité générale. Ember-1 est disponible en aperçu de recherche, sur la plateforme serverless de l'éditeur, avec une fenêtre d'accès de deux semaines et une décision de pérennisation qui dépend de la demande. Comprendre quelle part de tout cela relève d'un produit livré et quelle part relève d'un résultat de recherche solidement argumenté, c'est là tout l'exercice.

Il y a également une homonymie à dissiper avant toute autre chose. Un projet de recherche ouvert distinct appelé Ember (v0.1.5, de Slow Lit Labs) a passé 2026 à publier des évaluations de cohérence à long horizon, et il n'a aucun lien avec ce modèle. Tout ce que vous lisez sur le fait qu'Ember ne parvient pas à surpasser Qwen3-8B dans des paramètres d'inférence identiques concerne ce projet-là. Ember-1, dont il est question ici, est un dérivé de Kimi K3 issu de Fireworks Research.

Ce qu'Ember-1 est réellement

Ember-1 n'est pas une nouvelle architecture ni un nouveau modèle de base. C'est Kimi K3, réentraîné pour raisonner de manière plus concise. Fireworks Research a mené plus de 50 expériences d'entraînement et plus de 200 évaluations sur sa propre pile d'entraînement sans serveur, couvrant les mathématiques, la programmation, le suivi d'instructions, la conversation, la recherche, l'utilisation d'outils et l'ingénierie logicielle, avec l'objectif explicite de supprimer le raisonnement qui ne change pas la réponse. Le laboratoire affirme que la longueur du raisonnement pourrait être réduite de 35 à 50 % sans perte de précision sur sept benchmarks et deux ensembles de trafic de production client. Chacun de ces chiffres est rapporté par le fournisseur et n'a pas été reproduit indépendamment ; aucun tiers n'a publié d'exécution d'Ember-1 à ce jour.

Le cadrage compte parce que l’alternative évidente existait déjà. Kimi K3 est livré avec des paramètres d’effort de raisonnement, et la façon économique de dépenser moins de jetons consiste à réduire l’effort. Fireworks Research affirme avoir essayé cela et que le réglage faible sacrifiait trop de qualité — un résultat familier pour quiconque a ajusté des niveaux d’effort sur un modèle de raisonnement. L’affirmation d’Ember-1 est que le curseur d’effort est grossier et que le réentraînement est fin.

Pourquoi les jetons de raisonnement valent tout cet effort

La facture d’un modèle de raisonnement n’est pas dominée par sa réponse. Fireworks Research note que K3 peut consacrer plus de 90 % de ses jetons générés au raisonnement interne avant d’écrire quoi que ce soit qu’un utilisateur voie. Sur une seule requête, cela n’est que coûteux. Dans une boucle d’agent multi-tours, l’effet s’amplifie, car chaque tour rejoue la conversation précédente, de sorte que les traces de raisonnement des tours antérieurs sont relues et refacturées à chaque appel suivant. Fireworks Research décrit un contexte qui croît approximativement de façon quadratique avec le nombre de tours. C’est la cible réelle de cette version, et c’est pourquoi l’indicateur mis en avant est une réduction d’environ 40 % des jetons plutôt qu’un bond de qualité.

Le mécanisme explique aussi le risque. La compression qui élimine de la délibération superflue ne coûte rien ; celle qui élimine une étape dont le modèle avait besoin, non. Le mode de défaillance largement constaté d’une réduction trop agressive du raisonnement est un modèle qui saute une vérification intermédiaire et passe directement à une conclusion, ce qui, dans un agent, se manifeste bien plus tard par un appel d’outil erroné plutôt que par une phrase erronée. L’insistance répétée de Fireworks Research sur une qualité équivalente se lit comme une réponse à cette préoccupation, et les chiffres A/B sont ce qui ressemble le plus à une preuve de cela — avec la réserve habituelle que les jeux de test, les critères de réussite et les tailles d’échantillon ont tous été choisis par la partie qui avance cette affirmation.

La fiche de benchmark, avec sa provenance jointe

Voici les chiffres de Fireworks Research, non reproduits. La colonne de droite est la partie qui mérite une lecture attentive : elle associe chaque score au nombre de tokens et de dollars qu’il a fallu par rapport à K3 Max.

• Terminal Bench 2.1 (n=89) — Ember-1 82,0 % contre K3 Max 80,9 %, K3 High 77,6 %, K3 Low 76,4 % ; 51,9 % de jetons en moins, 23,10 $ de moins par tâche.

• SWE-bench Verified (n=500) — Ember-1 92,2 % vs K3 Max 93,2 % ; 15,5 % de jetons en moins, 68,10 $ de moins par tâche.

• SWE-Interact (n=75) — Ember-1 20,0 % vs K3 Max 21,3 %, K3 High 13,3 %, K3 Low 6,7 % ; 32,5 % de tokens en moins.

• DeepSWE 1.1 (n=113) — Ember-1 75,2 % contre K3 Max 66,4 % ; 23,7 % de tokens en moins, 126,90 $ de moins par tâche.

• τ-2 Bench Airline (n = 50) — Ember-1 66 % contre K3 Max 64 %, K3 High et Low tous deux à 64 % ; 5,9 % de jetons en moins, 0,30 $ de moins par tâche.

Deux choses ressortent. Premièrement, Ember-1 l'emporte nettement sur Terminal Bench 2.1 et DeepSWE 1.1, tout en perdant de justesse sur SWE-bench Verified et SWE-Interact — un schéma cohérent avec un modèle qui n'a pas tant perdu en capacité qu'il a changé les tâches auxquelles il consacre sa délibération. Deuxièmement, les économies de tokens sont extrêmement inégales : 51,9 % sur Terminal Bench contre 5,9 % sur τ-2 Airline. Quoi qu'Ember-1 ait appris, ce n'est pas une réduction uniforme de 40 % de la réflexion. Le « environ 40 % » du titre est une moyenne sur une fourchette qui va d'environ 6 % à environ 52 %, et une équipe dont la charge de travail ressemble à celle de τ-2 Airline ne devrait pas s'attendre à le ressentir.

Les tests A/B en production constituent la preuve la plus convaincante, précisément parce qu'ils n'ont pas été conçus pour servir de benchmarks. Dans la charge de travail de codage d'un client, Ember-1 a obtenu 0,753 contre 0,751 pour K3, a réalisé 21,4 étapes contre 23,8, et a émis 29,9 K de jetons de sortie contre 49,3 K — soit une réduction de 71,3 % des jetons de raisonnement et de 39 % des jetons totaux, pour une qualité à peu près équivalente. Un second client a observé environ 35 % de jetons en moins par tâche, à qualité comparable, et Fireworks Research affirme avoir d'abord effectué le basculement sur son propre trafic interne de codage et de coworking, avec le résultat rapporté que personne ne l'a remarqué. Considérez tout cela comme des informations rapportées par le fournisseur, mais considérez-les comme la forme la plus solide d'informations rapportées par un fournisseur : les données de préférence A/B et d'achèvement des tâches sont plus difficiles à manipuler qu'un classement.

Il y a une évaluation supplémentaire, sur Bedside Bench de Doximity — 500 cas cliniques validés par des médecins répartis en dix catégories — où Fireworks Research affirme qu’Ember-1 a établi une nouvelle frontière de Pareto sur le coût par tâche, en le comparant à des modèles ouverts et fermés, notamment GPT-5.6 Sol, GPT-6 Astra et Claude Opus 5. Il s’agit d’une affirmation de fournisseur concernant une position de Pareto, c’est-à-dire une affirmation portant sur un compromis bidimensionnel plutôt que sur un score unique, et elle ne vaut que par les hypothèses de coût qui la sous-tendent. Ces hypothèses provenaient de la grille tarifaire publique de l’API de Kimi K3. Ce qui nous amène à la partie de l’histoire qu’un lecteur peut réellement vérifier aujourd’hui.

Le modèle de base est la partie que vous pouvez déjà router

Tout l'argumentaire de coût d'Ember-1 est mesuré par rapport aux tarifs publiés de Kimi K3. Kimi K3 est disponible sur OrcaRouter à 3,00 $ par million de tokens d'entrée, 0,30 $ par million de tokens d'entrée en cache et 15,00 $ par million de tokens de sortie, avec une fenêtre de contexte de 1 048 576 tokens. C'est la même grille tarifaire que celle qu'utilise la comparaison Fireworks Research, et il est bon de savoir que les économies indiquées dans ces colonnes de réduction de tokens sont calculées par rapport à des chiffres que vous pouvez vérifier vous-même plutôt que par rapport au modèle de coûts interne d'un fournisseur.

Ember-1 lui-même n'est pas sur OrcaRouter. Il n'est disponible que via la plateforme serverless propre au fournisseur, en tant qu'aperçu de recherche, et Fireworks Research n'a pas publié de prix pour lui — ainsi, les montants en dollars du tableau de benchmark sont dérivés des tarifs K3 et du nombre de tokens, et non d'une grille tarifaire Ember-1 qui existerait. Si c'est l'arithmétique qui vous intéresse, l'ordre honnête est de chiffrer la charge de travail selon la route K3 aujourd'hui, de prendre les pourcentages de réduction de tokens comme la limite supérieure de ce qu'un basculement pourrait apporter, et d'attendre qu'un tarif publié soit disponible avant de modéliser l'économie en termes monétaires.

Là où OrcaRouter aide vraiment ici, c’est pour la couverture. Un aperçu de recherche avec une fenêtre d’accès de deux semaines est exactement le genre de modèle que vous voulez essayer sans parier un chemin de production dessus, et la façon de le faire sans un second contrat consiste à le placer derrière le même point de terminaison que tout ce que vous appelez.OrcaRouter sert plus de 200 modèlesderrière une seule API avec basculement automatique, donc un modèle d’aperçu qui s’avère indisponible le mois prochain constitue un changement de routage plutôt qu’une migration. Rien dans Ember-1 ne l’exige — mais rien dans une fenêtre de deux semaines ne plaide contre non plus.

Que faire de cette version

Si vous exécutez déjà Kimi K3 dans une boucle d'agent, les chiffres d'Ember-1 décrivent votre facture. Le problème de rejeu multi-tours est réel, c'est le coût dominant dans les longues exécutions d'agents, et un modèle qui raccourcit ses propres traces sans modifier ses réponses vaut le temps d'évaluation. Le bon test n'est pas le tableau de benchmark ; c'est votre propre trafic, exécuté en shadow — envoyez une part de requêtes réelles aux deux modèles, comparez les sorties, gardez les résultats en production intacts pendant une semaine ou deux avant de changer quoi que ce soit. C'est aussi le conseil que donne le lectorat critique de la version, et il est judicieux.

Si vous exécutez une charge de travail à faible délibération, ou dominée par de courts appels à tour unique, les économies s'évaporent en grande partie et la ligne τ-2 Airline correspond à votre attente réaliste. Et si vous avez besoin d'un engagement de niveau production — un prix, un niveau de service, une garantie que le point de terminaison existera dans six mois — Ember-1 n'en propose pas encore. Il s'agit d'un aperçu de recherche dont Fireworks Research lie explicitement la permanence à la demande. La question intéressante au cours du mois prochain est de savoir si la fenêtre de deux semaines deviendra une option de service permanente et si un tiers reproduira l'un de ces chiffres. Jusqu'à ce que l'un de ces événements se produise, c'est un résultat solide à lire et un piètre résultat sur lequel bâtir un budget.

Rien de tout cela ne doit être lu comme une minoration du travail. Retirer le raisonnement sans retirer la précision est un problème plus difficile que d'en ajouter, et le faire par-dessus le modèle de frontière de quelqu'un d'autre plutôt qu'en entraînant le vôtre correspond à la forme qu'a prise une grande partie du travail sur les capacités en 2026. Ember-1 est la première sortie de ce que Fireworks Research présente comme une série appelée à se poursuivre, et le modèle — prendre un modèle déjà bon, réentraîner un axe de son comportement, vendre le delta en jetons — mérite qu'on y prête attention, quelle que soit la manière dont cet aperçu particulier sera accueilli.