大模型云服务商 Fireworks AI 最近做了一件反常的事:上线专用推理模型 Ember-1。它的底座是月之暗面开源的 Kimi K3,参数量依然是庞大的 2.78T MoE,输出单价也维持在每百万 Token 15 美元,分文未降。官方宣称它能在基本不掉点的前提下,直接削减约 40% 的生成 Token。
在同行普遍用打折、蒸馏小模型卷价格时,Fireworks 选择在 2.78T 骨干网络上动刀,定向剪掉模型冗长的自言自语。但这并非无私的开源贡献。Fireworks 既没有公开微调权重,也没有开源训练代码,只把 Ember-1 挂在自家 Serverless API 上提供两周测试。
这是一次针对长思维链通胀的工程剪枝,也是一次云厂商借开源基座修筑专有管道的典型尝试。
冗长思考演变成账单灾难
复杂编程进入长思维链时代后,推理模型普遍患上严重的反刍病。为了排查一段边界错误,模型往往在内部生成数万个自我怀疑的思考 Token。在单次交互中,真正写出来的有效代码经常只占一成,其余九成全是推演草稿。
单次耗时还能忍受,但在多轮编程智能体工作流里,自言自语直接变成了账单黑洞。智能体每一轮排错,都会把上一轮所有的思考轨迹原样塞回输入上下文。输入长度随交互轮次呈二次方膨胀,开发者每一次微小的代码调整,都在为前几轮早已失效的思考反复埋单。
以往工程团队通常直接调低思考力度参数,结果几乎必然导致推理能力断崖式下跌。单纯强行打断思考,等于逼模型闭眼交卷。
Fireworks 做了 50 多次训练实验和 200 余次评估,通过环境反馈让模型学会识别死循环,主动放弃无效推演。在两家真实客户的生产环境 A/B 测试中,单任务输出 Token 从 49.3K 降到 29.9K,思考 Token 压掉了 71.3%,平均交互轮数从 23.8 轮降到 21.4 轮,任务得分基本持平在 0.753 对比 0.751。
从工程上看,这种定向剪枝确实比蛮力调参高明得多。
50 倍非对称计费下的算力账本
Token 减少 39%,并不等于企业的月结账单能降 39%。
Ember-1 的计费规则和 Kimi K3 完全一样:未缓存输入每百万 Token 收取 3.00 美元,缓存命中后输入为 0.30 美元,输出 Token 则高达 15.00 美元。输出单价是缓存输入的整整 50 倍。
Fireworks 的降本逻辑完全建立在让模型少吐字上,而不是自己让出利润。
这种非对称结构带来了一个致命变量:重试代价。在机械执行的 Terminal-Bench 2.1 上,成本降幅达到 51.9%;但在依赖复杂业务逻辑的 τ²-Bench Airline 里,成本降幅骤跌至 5.9%。
| 基准测试项目 | 样本量 (N) | K3 Max 准确率 | Ember-1 准确率 | 报告成本降幅 / 差额 |
|---|---|---|---|---|
| DeepSWE 1.1 | 113 | 66.4% | 75.2% | -23.7% (-$126.90) |
| Terminal-Bench 2.1 | 89 | 80.9% | 82.0% | -51.9% (-$23.10) |
| SWE-bench Verified | 500 | 93.2% | 92.2% | -15.5% (-$68.10) |
| SWE-Interact | 75 | 21.3% | 20.0% | -32.5% (-$60.80) |
| τ²-Bench Airline | 50 | 64.0% | 66.0% | -5.9% (-$0.30) |
更值得警惕的是高难基准的退步。在严苛的 SWE-bench Verified 评测中,Ember-1 准确率从 93.2% 跌至 92.2%;在考验长程决策的 SWE-Interact 上,也从 21.3% 滑落到 20.0%。
在冷启动的单次深水区排错里,穷举搜索必不可少。剪掉的那些冗长自问自答,有时恰恰包含定位长尾缺陷的关键线索。多轮系统一旦因少想两步而导致任务失败、触发重新规划,新一轮全量上下文输入产生的费用,会瞬间吞掉之前节省的所有输出成本。
借开源之梯,筑私有之墙
比技术取舍更尖锐的是商业控制权的转移。
战国策里讲借途灭虢,如今下游云厂商正在上演类似的戏码。月之暗面开源 Kimi K3 权重,下游托管商接过来后,用私有数据做一层闭门后训练,转手封装成只能在自家平台调用的专有 API。既不开源权重,也不公开训练集。
这不是单纯的算力搬运工,而是把开源资产转变成自家的专有护城河。
对技术团队而言,接入 Ember-1 意味着彻底放弃私有化部署可能,直接绑定在 Fireworks 单一供应商身上。更现实的隐患是,这个模型目前只承诺了两周 Research Preview,后续如果调用量不达标随时可能下线。平台自身的信息也在打架:发布博文声称支持深度企业微调,控制台详情页却赫然标着暂不支持。
至今没有任何独立第三方完成对 Ember-1 推理表现的完整复现。DeepSWE 官方榜单尚未收录该模型,社区公开评测仅验证了它继承 K3 的分词器。
技术团队如果在多轮工具调用、高频自纠错场景中被账单压得喘不过气,拿一部分样本灰度测试 Ember-1 是合理的。但若业务依赖长程代码修复与严苛边界逻辑,仅凭官方平均节约率盲目迁移,被剪掉的思考很可能会在不可预知的地方反噬整个系统。
