Ember-1 是 Fireworks Research 推出的专用模型，能达到 Kimi K3 的质量，token 用量却少 40%。它基于 K3 构建，学会砍掉不必要的推理，只保留真正重要的思考，并在外部基准、客户 A/B 测试和内部编码与 agent 任务中验证质量未降。用户此前需要 K3 的编码能力，但长推理链让规模化自动编码成本过高，调低推理力度又损失太多质量，因此团队只能训练它更高效地推理，为此做了 50 多次训练实验和 200 多次评估。

Ember-1：一半的 token，同样的答案

Ember-1 是 Fireworks Research 推出的新专用模型，用比 Kimi K3 少 40% 的 token 达到同等质量。它基于 Kimi K3 构建，学会了削减不必要的推理，同时保留真正重要的思考。我们在外部基准、客户线上 A/B 测试，以及自家的编码和 agent 负载上测试，质量在每个场景都稳住了。Ember-1 今天可用，也开启了 Fireworks 持续推出专用模型的系列，方向由开发者需求塑造。

Fireworks Research 如何构建 Ember-1

用户反馈需要更低成本的 K3 编码能力，因为长推理链让规模化自动编码太贵。调低 K3 的推理力度解决不了问题——低力度设置牺牲了太多质量。要保住质量又减少 token，模型必须学会更高效地推理，这需要训练。

团队跑了 50 多次训练实验和 200 多次评估，过程中开发了新训练算法来缩短推理而不损失准确率。所有这些都在 Fireworks Serverless Training 上完成。不用配置或管理 GPU，有想法就能立刻开实验，只为实际运行付费，从研究到发布的时间和成本都大幅缩减。

我们在广泛任务上训练，让节省的 token 能迁移到多种负载。随后在 Specialized Intelligence Index、公开基准和线上生产流量上评估 Ember-1，确认它用了更少 token 而质量不降。Ember-1 是 Fireworks 自己的模型，也是 Fireworks Research 系列的第一个。

问题：思考模型想得太多

像 Kimi K3 这样的推理模型，把大部分生成 token——有时超过 90%——花在内部推理而非答案本身。这种思考结构在单次请求上就贵，在多轮 agent 负载中更糟。每一轮都会把之前的推理重新注入模型，上下文随轮数大致平方增长。早轮的长推理链在之后每次调用中都被重读（并重新计费）。

这些推理都必要吗？实验说不是。Kimi K3 输出的推理远长于任务所需，多余部分可以去掉而不影响答案。Ember-1 就是这样造出来的——基于专用智能的经济版 Kimi K3。

从一个观察到一款优质模型

K3 的推理并非全是浪费。有些是自我反思：重新审视假设、回应反馈、把结果追溯到早先的决定，帮助模型从错误中恢复。机会在于保留这种能力，同时减少不必要推理、跳出低效循环。从任务和环境反馈中学习，可以教会模型更高效地推理，同时维持能力。

对 agent 任务，这种学习跨整个交互过程。模型探索可能的动作、纳入新观察、随进展改进推理。反馈把决定与后果连起来，鼓励任务全程做有用的反思。

这些见解被带入一个训练集合，涵盖数学、编码、指令跟随、对话、搜索、工具使用和软件工程，既包括独立问题，也包括延伸交互，强制模型适应观察和结果。任务反馈引导 on-policy 规划与学习，重点是在这一系列场景中保持能力。

公开基准和线上 A/B 测试支持这个方向：在七个基准和两个客户的生产流量上，Kimi K3 的推理可以缩短 35–50% 而不牺牲准确率。内化的行为还表现出对不成功尝试的克制 token 使用，减少冗长无效的推理。

Specialized Intelligence Index：Ember-1 为 Bedside Bench 设定帕累托前沿

本周早些时候，我们推出了 Specialized Intelligence Index (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/M token，缓存输入 $0.30/M，输出 $15/M）计算每个基准的成本，与通过率对照，比较四组：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% | 82.0% | -51.9% / -23.1 USD | | SWE-bench Verified | 500 | 80.4% | 86.0% | 93.2% | 92.2% | -15.5% / -68.1 USD | | SWE-Interact | 75 | 6.7% | 13.3% | 21.3% | 20.0% | -32.5% / -60.8 USD | | DeepSWE 1.1 | 113 | 55.8% | 62.8% | 66.4% | 75.2% | -23.7% / -126.9 USD | | τ-2 Bench Airline | 50 | 64% | 64% | 64% | 66% | -5.9% / -0.3 USD |

运行 K3 最具成本效益的方式，不再是让它少想，而是运行 Ember-1——一个学会高效思考的模型。

客户验证：线上 A/B 测试

基准只能说明一部分。正如 SII 结果所示，我们想在更真实的工作负载上测模型，用生产流量测。真正的考验往往是模型能否在用户依赖的产品生产流量中站住。

我们与两个客户在其生产编码负载上做了线上 A/B 测试。两种情况下，Ember-1 都带来可观的 token 节省，每个任务约少 35% 的 token，质量相当。多数下游产品指标保持或改善，任务完成、成功评分和失败率都朝对的方向走，token 成本大幅降低。A/B 测试后，一个客户已在生产环境运行 Ember-1，计划扩大规模完全替换基础模型。

| Score | Steps | Output Tokens | Reasoning Token reduction | Total token reduction | | --- | --- | --- | --- | --- | | Kimi K3 | 0.751 | 23.8 | 49.3K | - | - | | Ember-1 | 0.753 | 21.4 | 29.9K | 71.3% | 39% |

内部验证：自家开发者没有察觉

Fireworks 内部很大一部分编码/协作流量由自家推理服务支撑。在任何客户看到模型之前，我们先让内部开发者用它做日常编码工作，包括在真实任务上大规模 vibe testing。

最自豪的结果是：没有新闻。没有新闻就是好消息。开发者继续编码负载而没注意到切换，同时消耗的 token 大幅减少。对于一个价值主张就是「同样的答案，更少的 token」的模型，内部流量的无感上线是最强的信号。

下一步

Ember-1 作为 Research Preview 版本在 Serverless 上与基础 Kimi K3 模型并排推出。为支持快速增长的生态，我们推出研究版本，让开发者有两周的 serverless 访问新研究模型，再根据社区需求转为永久。对 agent 编码和其他推理 token 占主要成本的工作负载，它以大约一半的 token 成本提供同等质量。

Fireworks Research 将继续推进模型效率前沿，把专用智能带到更多 Ember 模型，让你部署最经济的模型、减少 token 支出。Token 效率正成为 Fireworks 的主题。

想把 Ember-1 再推进一步，为你的用例做优化？我们也在推出 Ember-1 的训练支持，让企业用自己的数据构建定制、token 高效的模型。开放模型的未来，是在你特定工作负载上训练的专用模型。

想在自己的负载上试试 Ember-1？我们很想听听你的体验，在 X 上 @ 我们（@FireworksAI_HQ），告诉我们你在构建什么。

讨论整体认可这项工作的迭代价值，但分歧集中在「省 token 省思考」是否值得、指标叙事是否可信，以及开源与闭源谁能借此更快前进。少数人则更关心训练基建的开放性和实际用途。

认为推理模型想得太多，快模型反而更有价值

• 分析瘫痪不只拖累人类智能，也拖累其他智能；大家开始欣赏那些能低成本处理简单任务的快速模型，并有动力去大量试验新场景（高赞 / 较多人） > 问题在于推理模型想得太多，分析瘫痪不只拖累人类智能，也拖累其他智能。（@andsoitis）
• 小模型同样有极端思考的毛病，因此这套压缩思路能否泛化到其他模型值得关注（较多人）

认为 Pareto 前沿被滥用，基准测试只说了一半故事

• 近期几乎所有 AI 文章都在提 Pareto 前沿，这个词的边界需要更清晰的定义；更关键的是要交代减少 token 之后损失了什么能力，比如原本很擅长 Go、现在是否变差（较多人） > 基准测试只讲了一半故事，得说清减少 token 后究竟丢了什么能力，比如原本 Go 写得很溜、现在是不是不太行了。（@tomrod）
• 有人直接数了文章里「Pareto」出现 8 次、而「Opus 5.5」出现 0 次，借版本号混乱调侃指标被过度包装（少数人）
• 也有人追问到底是 Opus 5.5 还是 Opus 5，并认为若测了同类模型，结果可能和某款 Flash 模型相近（少数人）

看好开源与托管训练把迭代能力交到更多人手里

• 开源模型正靠这类做法快速推进，而闭源模型很难照做，Linux 和 Wikipedia 就是这么反超它们的「前沿」的（较多人） > 开源模型会因为这类做法快速进步，而闭源的那边做不到——Linux 和 Wikipedia 不就是这样超越它们的「前沿」的吗？（@jamienk）
• 托管式训练基础设施是关键前提：除非在少数几个大实验室工作，否则很难搭起任何训练流水线，把训练做成托管服务让更多人能上手（较多人）
• 有人现身说法，说现在自己攒数据、拿小基座模型微调，两天就得到一个意外好用的专用模型（较多人）

质疑拿开源权重训练却不回馈开源

• 如果确实基于开放权重训练，却没有放出权重，那这个「开放」的含义就值得追问（少数人）
• 也有人希望同样的事情发生在 DeepSeek 上，最好直接做 Flash 档的模型（少数人）

更关心实际用途与竞品性价比

• 有人直接问这模型适不适合创意写作，也有人拿它做英文转 Bash 命令，省去查语法（少数人）
• 有跑题但被顶起来的观点：竞品降价后某家的性价比就没那么有吸引力了，内部测试里质量更好、成本更低；按 2/10 对 3/15 的定价差距，那家需要跟进降价（少数人）

有价值的补充

• 社区在逐字核对文章措辞，统计「Pareto」8 次、「Opus 5.5」0 次，说明版本号和指标术语的一致性是这轮讨论的一个隐性槽点。
• 一个人分享的实测数字很有说服力：用子代理生成 14 万多条样本，拿 Qwen 3 0.6B 基座、指向 Astra 训练，断断续续跑了两天，自己主动投入只有几个小时，效果仍在提升。
• 类似的改造在 /r/LocalLLaMA 已形成小圈子，有人专门为 Qwen 27B 等模型做同类工作，并在 Hugging Face 上公开了成果。
• 思路可以类比：分类器和其他小型 ML 模型早就承担这类任务，真正变化的是现在玩得起、试得便宜，于是被解锁的工作流数量大幅增加。