Ember-1 是 Fireworks Research 推出的一款全新专用模型，它以少 40% 的 token 实现了 Kimi K3 的质量。它基于 Kimi K3 构建，学会了削减不必要的推理，同时保留真正重要的思考。我们在外部基准测试、真实客户 A/B 测试，以及我们自己的编码和智能体工作负载上对它进行了测试，质量在每一种场景下都保持住了。Ember-1 今日即可使用，它开启了 Fireworks 一系列持续推出的专用模型，这些模型由开发者接下来的需求所塑造。Ember 只是你用 Fireworks 训练平台所能构建之物的起点。
我们从用户那里得知，他们需要以更低的成本获得 K3 的编码能力，因为其冗长的推理轨迹使自动化编码在大规模应用时变得昂贵。降低 K3 的推理投入并没有解决这个问题。较低的投入设置牺牲了太多质量。要在保持质量的同时削减 token，模型必须学会更高效地推理，而这意味着要对它进行训练。
实现这一目标需要认真的研究。我们的团队进行了 50 多次训练实验和 200 多次评估，并在此过程中开发了新的训练算法，以在不损失准确性的前提下缩短推理。我们全程都在 Fireworks Serverless Training 上完成。由于我们无需配置或管理 GPU，因此一有想法就能立即启动实验，只为实际运行的部分付费，并以通常所需时间与成本的一小部分从研究推进到发布。
我们在广泛的任务集上进行训练，以便节省的 token 能延续到多种工作负载中。我们使用自己的数据训练该模型，没有使用任何客户数据。随后，我们在专用智能指数、公开基准测试和实时生产流量上评估了 Ember-1，以确认它在使用更少 token 的同时质量没有下降。Ember-1 是 Fireworks 自有模型，也是 Fireworks Research 系列模型中的第一个。
像 Kimi K3 这样的推理模型，其生成 token 的大部分——有时超过 90%——都花在内部推理上，而非答案本身。这种思考结构在单次请求中就很昂贵，但在多轮智能体工作负载中会变得更糟。每一轮都会把所有先前的推理重新回放给模型，因此上下文大致随轮数呈二次方增长。早期轮次中冗长的推理轨迹会在随后的每一次调用中被重新读取（并重新计费）。
所有这些推理真的必要吗？我们的实验表明并非如此。Kimi K3 输出的推理远超任务所需，而多余的部分可以在不影响答案的情况下被移除。我们正是以此方式创建了 Ember-1——一个由专用智能构建的经济版 Kimi K3。
K3 的推理并非全是浪费。其中一部分是自我反思：重新审视某个假设、回应反馈，或将某个结果追溯到更早的决策，都能帮助模型从错误中恢复。机会在于保留这种能力，同时减少不必要的推理并摆脱无成效的循环。我们相信，从任务和环境反馈中学习，可以教会模型更高效地推理，同时保持其能力。
对于智能体任务，这种学习贯穿整个交互过程。模型探索可能的行动，纳入新的观察，并在推进过程中不断精炼其推理。反馈将决策与其后果联系起来，鼓励在整个任务过程中进行有益的反思。
我们将这些洞见带入一个训练集合，涵盖数学、编程、指令遵循、对话、搜索、工具使用和软件工程，既包括独立问题，也包括扩展交互，以强化对观察和结果的适应能力。任务反馈引导同策略规划与学习，重点是在这一系列场景中保持能力。
公开基准测试和线上 A/B 测试的结果支持这一方向：在七个基准测试和两个客户的生产流量中，Kimi K3 的推理可缩短 35–50%，而不牺牲准确率。这种内化的行为还表现为在未成功的尝试中克制 token 使用，减少冗长而无产出的推理。
本周早些时候，我们推出了专业智能指数（SII），以行业专家创建的真实世界任务为基准，对开放、闭源和专用模型进行评估。
我们在 Doximity 的 Bedside Bench 上评估了 Ember-1，这是一个经医生验证的基准，涵盖 10 个专业类别的 500 个临床案例。
结果如何？Ember-1 在 Bedside Bench 上为开放和闭源模型（包括 GPT-5.6 Sol、GPT-6 Astra 和 Claude Opus 5）在成本/任务维度上设定了新的帕累托前沿。
我们还在其他一些行业基准上评估了 Ember-1 的质量-成本前沿。我们使用公开的 Kimi K3 API 定价（未缓存输入 $3/百万 token，缓存输入 $0.30/百万，输出 $15/百万）计算每个基准的成本，并将其与三个配置的通过率进行绘图：K3 推理强度低、K3 推理强度高、K3 推理强度最高（默认），以及 Ember-1。在每一个测试样本超过 50 个的基准上，Ember-1 都位于或接近帕累托前沿，以极低的成本达到 K3-max 的质量，并严格优于 K3-low。我们还分析了 GPT-6 Astra、Claude Opus-5 和 GLM 5.3，发现 Ember-1 在帕累托前沿上处于领先地位。
我们深入查看了直接将 Ember-1 与原始 K3 进行比较的结果，发现如下：
| N | K3 Low | K3 High | K3 max | Ember-1 | Ember-1 vs. K3 Max | |
|---|---|---|---|---|---|---|
| Terminal Bench 2.1 | 89 | 76.4% | 77.6% | 80.9% | ||
| -51.9% / -23.1 USD | ||||||
| SWE-bench Verified | 500 | 80.4% | 86.0% | |||
| 92.2% | -15.5% / -68.1 USD | |||||
| SWE-Interact | 75 | 6.7% | 13.3% | |||
| 20.0% | -32.5% / -60.8 USD | |||||
| DeepSWE 1.1 | 113 | 55.8% | 62.8% | 66.4% | ||
| -23.7% / -126.9 USD | ||||||
| τ-2 Bench Airline | 50 | 64% | 64% | 64% | ||
| -5.9% / -0.3 USD |
运行 K3 最具成本优化的方式不再是让它少思考，而是运行 Ember-1，这个学会了高效思考的模型。
基准测试只能告诉你这么多。正如我们在专业智能指数结果中所发现的，我们希望用更多真实工作负载来测试模型，并使用生产流量来测试模型。真正的考验往往在于模型能否在生产流量中、在用户所依赖的产品中经受住考验。
我们在两个客户的生产编码工作负载上进行了实时 A/B 测试。在这两种情况下，Ember-1 都实现了令人印象深刻的 token 节省，在质量相当的情况下，每个任务大约减少 35% 的 token。大多数下游产品指标保持或有所改善，包括任务完成率、成功分数和失败率都在朝着正确的方向发展，同时 token 成本大幅降低。在 A/B 测试之后，一个客户现在正在生产环境中运行 Ember-1，并计划扩大规模以完全取代基础模型。
| Score | Steps | Output Tokens | Reasoning Token reduction | Total token reduction | |
|---|---|---|---|---|---|
| Kimi K3 | |||||
| - | |||||
| Ember-1 | 0.753 | ||||
| 39% |
Fireworks 内部编码/协作流量的大部分由我们自己的推理服务提供支持。在任何客户看到该模型之前，我们就在内部将 Ember-1 投入使用，并让我们自己的开发人员将其用于日常编码工作，包括在真实任务上进行大规模 vibe 测试等。
我们最引以为豪的结果是：没有新闻。 没有新闻就是好消息。开发人员继续他们的编码工作负载，没有注意到切换，同时消耗的 token 大幅减少。对于一个其全部价值主张是“相同答案，更少 token”的模型来说，在内部流量上实现无感部署是最强有力的信号。
Ember-1 正作为基础 Kimi K3 模型之外的一个服务选项推出，作为 Serverless 上的 Research Preview 版本。为了支持快速增长的开放源代码生态系统，我们推出研究版本，让开发人员能够获得为期两周的新研究模型的无服务器访问权限，并根据社区需求将其永久化。对于代理编码和其他推理 token 占大部分成本的工作负载，它以大约一半的 token 成本提供相同的质量。
Fireworks Research 将继续推动模型效率的前沿，为更多 Ember 模型带来专业化智能，使您能够部署最经济的模型，并减少您的 token 支出。Token 效率正在成为 Fireworks 的一个主题。
希望将 Ember-1 更进一步，并针对您的用例进行优化？我们还推出了对 Ember-1 的训练支持，使企业能够使用自己的数据构建定制的、token 高效的模型，以满足其需求。开放模型的未来是在您的特定工作负载上训练的专用模型。
想在工作负载上试用 Ember-1？我们很乐意听到您的体验，所以在 X 上标记我们（@FireworksAI_HQ），并告诉我们您正在构建什么！