推理模型「想得太多」：Fireworks 用 Ember-1 把 token 砍掉四成

推理模型的钱，花在「想」上而不是「答」上

9 月，Fireworks Research 发布了一个叫 Ember-1 的模型，宣传语只有一句：同样的答案，token 少一半。它的底座是擅长写代码的推理模型 Kimi K3。团队说，用户反复提的需求是「要 K3 的编码能力，但别那么贵」——因为 K3 的推理链太长，规模化跑自动编码时成本很快失控。

问题出在推理模型的 token 结构上：像 K3 这样的模型，生成的大部分 token（有时超过九成）用在内部推理，真正给答案的只占零头。单次请求已经很贵，多轮 agent 场景更糟：每一轮都会把此前的推理重新回放给模型，上下文开销随轮数近似二次增长，早几轮的长推理在之后每一次调用里被重读、重计费。

把「推理强度」调低解决不了问题

直觉做法是把模型的思考强度调低。Fireworks 试过，这条路走不通：强度降下来，质量掉得太多，省的钱不够赔准确率。于是他们转去做训练——让模型学会更高效地思考，而不是少思考。

按官方说法，这条路上跑了 50 多次训练实验、200 多轮评估，还顺手开发了新的训练算法来压缩推理长度。整个研究跑在自家的 Serverless Training 上：不用预配、不用自己管 GPU，有想法就能起实验，这也是「从研究到上线」被压缩得很短的直接原因。

成绩单：质量基本不动，成本明显下降

官方给了两组验证。第一组是公开基准：在 7 个基准加上两家客户的真实生产流量 A/B 测试中，K3 的推理过程可以缩短 35%–50% 而准确率不降。几个具体数字：SWE-bench Verified 从 93.2% 到 92.2%，每任务成本降 15.5%（-68.1 美元）；Terminal Bench 2.1 从 80.9% 提到 82.0%，成本降 51.9%；DeepSWE 1.1 从 66.4% 提到 75.2%，成本降 23.7%。

第二组是客户侧：两家客户的编码生产流量 A/B 显示，每任务约少 35% 的 token，质量相当，任务完成率与失败率指标持平或向好，其中一家已把 Ember-1 放进生产，并计划整体替换原来的基座模型。另外：Fireworks 先让自家开发者的日常编码流量切到 Ember-1，结果是没人发现换了模型。对一个卖「同样的答案、更少的 token」的模型来说，这大概是最有说服力的验证。

为什么这件事值得关注

它把模型竞争的标尺换了一根：过去比「每百万 token 多少钱」，现在更该比完成一个任务要花多少钱。同一个模型，思考强度调低便宜但掉质量、调高又贵，而 Ember-1 想在这条曲线上占一个新位置——用更少的 token 拿到同等准确率。官方还提到，在医生验证的临床基准 Bedside Bench 上，Ember-1 建立了新的成本 / 任务帕累托前沿。发布方式也很务实：作为研究预览与 K3 并列提供服务，按社区需求决定是否长期保留，同时开放训练支持，让企业用自有数据定制更省 token 的版本。

对做企业数字化的实际启发

第一，先算 token 账，再算单价账。如果是多轮 agent 场景，成本大致随轮数二次增长，真正吃预算的是每一轮被回放的历史推理。评估模型时别只看价目表，要拿自己的任务跑一遍「每任务总成本」。

第二，把模型当成可替换的组件。今天省 token 的模型明天可能被另一个替代，接口层要留好切换位，别把业务逻辑写进某家的提示词习惯里。这次两个客户的验证方式也值得抄：不看榜单，用自己流量的 A/B 说话，指标盯任务完成率。

第三，对小团队来说，省下来的不是抽象的效率，而是能多跑的验证次数。