Fireworks AI Ember-1 降低 Kimi K3 的 Token 负载，但证据仍由厂商主导
Fireworks AI 发布 Ember-1 时提出了一个直接承诺：在保持 Kimi K3 任务表现的同时，生成的 Token 数量减少约 40%。Fireworks AI Ember-1 模型瞄准了推理系统中代价高昂的一个弱点，尤其是那些会在后续轮次中反复携带早先推理内容的编程智能体。
关键对比并非 Ember-1 与某个无关的前沿模型之间的较量，而是经过训练的效率与一种更简单替代方案之间的比较：在推理时降低 Kimi K3 的推理强度。Fireworks 表示，较低设置虽然能节省 Token，却会损失过多准确性；而后训练则让 Ember-1 学会保留哪些推理内容。
这一主张之所以重要，是因为高 Token 消耗的推理会在长时间智能体会话中累积放大。不过，相关证据主要来自 Fireworks 自身。Ember-1 也是一项仅限 API 使用的研究预览版，外部研究人员无法检查其权重，也无法独立复现训练过程。
Fireworks AI Ember-1 改变了 Kimi K3 的成本结构
Ember-1 将推理长度转化为一种可训练的行为，而不是将其视为模型质量的固定成本。
Fireworks 于 2026 年 9 月 23 日发布 Ember-1。根据官方的 Ember-1 release，这款专用模型基于 Moonshot AI 的 Kimi K3 开放权重进行了后训练。
后训练是指基础模型学会通用能力后所进行的额外训练。在这里，目标比构建一个新的基础模型更为聚焦。Fireworks 希望 K3 使用更短的推理轨迹，同时不放弃有价值的分析能力。
该公司表示，客户认可 K3 的编程能力，但认为其冗长推理在大规模使用时成本过高。其研究人员得出的结论是，降低可用推理强度无法保留足够的质量。因此，他们训练 Ember-1 去除冗余循环，同时保留有效的反思。
Fireworks 称，其团队完成了超过 50 项训练实验和超过 200 次评估。训练集覆盖数学、编程、指令遵循、对话、搜索、工具使用和软件工程。
这些类别很重要，因为 Token 效率可能会对某一种狭窄工作负载产生过拟合。一个只针对简短编程问题训练的模型，在智能体需要搜索、调用工具、修订计划并从错误中恢复时，可能会表现不佳。
Fireworks 表示，任务反馈和环境反馈引导了在策略学习。在策略学习使用当前模型在训练期间生成的行为，使反馈能够塑造它实际产生的推理模式。
该公司还表示，使用的是自有数据而非客户数据。它尚未披露完整数据集、训练算法、训练代码或 Ember-1 权重。
Ember-1 目前通过 Fireworks Serverless 以研究预览版形式提供。Fireworks 将此类预览描述为有限的无服务器发布；当社区需求证明持续提供服务具有合理性时，它们可能转为长期可用。
这种分发方式带来了第一个重大限制。开发者可以通过 API 测试该模型，但无法自行托管或检查其参数。因此，独立评估者只能在由 Fireworks 控制的条件下测试托管端点。
Kimi K3 为这项比较提供了基础。Moonshot 于 7 月推出 K3，这是一款拥有 2.8 万亿参数、原生视觉能力和一百万 Token 上下文窗口的模型。其官方 Kimi K3 specifications 将其定位为适用于长时间编程会话、知识工作和推理的模型。
Moonshot 还提供低、高和最高推理强度设置。这使 K3 成为 Fireworks 论证中一个特别有价值的基线。同一底层模型家族可以在不同推理设置下，以及与单独后训练的变体之间进行比较。
因此，这一事件比又一次模型发布更具针对性。Fireworks 提出，提供商应通过训练消除浪费，而不是要求客户接受浪费或手动降低推理深度。
这一理念同时给推理平台和模型厂商带来压力。如果 Token 高效的后训练能够在生产工作负载中奏效，原始基准质量就只是采购决策的一部分。
为什么长推理轨迹会成为智能体的成本问题
冗长的推理轨迹不只是更长的回答，因为智能体可能会在每一步后续操作中携带这段轨迹。
推理模型会在生成最终回答之前产生中间分析。Fireworks 表示，这些内部推理 Token 有时会占模型生成输出的 90% 以上。
这一比例是公司报告的观察结果，并非所有推理模型的普遍属性。不过，它确实指出了多步骤智能体中一个真实的架构问题。
一次较长的响应只会产生一次成本。然而，当智能体再次调用工具、审查结果或尝试修正时，往往会将先前消息重新发送给模型。
早先的推理内容因此可能被反复处理。Fireworks 将这种上下文增长描述为与轮次数量大致呈二次关系，因为每一新轮次都可能重放不断扩展的历史记录。
这种实际影响在编程系统中尤为明显。智能体可能检查代码仓库、提出补丁、运行测试、诊断失败，并修订多个文件。每增加一轮，都可能包含已不再有助于下一次决策的早期分析。
仅仅向用户隐藏推理过程，并不一定能消除这种负担。取决于其 API 设计和上下文处理规则，提供商仍会生成和处理推理 Token。
降低推理强度设置是一种显而易见的应对方式。模型分析时间更少、生成的 Token 更少，返回速度也更快。
Fireworks 认为，这种做法会连同冗余推理一起移除有价值的推理。其基准结果显示，在若干接受评估的编程任务中，低强度 K3 落后于最高强度 K3。
例如，Fireworks 报告称，K3 Low 在 Terminal-Bench 2.1 上的通过率为 76.4%。K3 Max 达到 80.9%，而 Ember-1 达到 82.0%。
该基准包含 89 项基于终端的任务，涵盖软件工程、系统管理、数据处理、安全及相关命令行工作。其维护者在发布 Terminal-Bench 2.1 时修订了 28 项任务。
较低强度与经训练效率之间的差异，正是核心机制所在。较低设置为原始模型提供更少的推理预算；后训练则试图改变模型分配这部分预算的方式。
有益的自我反思可能包括核查某项假设、发现一条失败的命令，或在获得环境反馈后修订计划。冗余推理则包括重复摘要、被放弃的循环，以及不会改变最终行动的长篇权衡。
Ember-1 理应能够区分这两类推理。Fireworks 表示，该模型会保留能够提高任务完成率的反思，同时抑制无效循环，包括在尝试失败期间。
仅从最终答案很难验证这种区分。两个模型可能生成同样正确的补丁，却经历了截然不同的内部路径。它们也可能表现出相近的总体分数，但在不同任务上失败。
因此，生产团队需要的不只是平均 Token 数。他们需要看到压缩在何时有效、哪些任务会损失准确性，以及罕见失败是否变得更难发现的分布情况。
延迟同样值得关注。更少的输出 Token 通常会缩短生成时间，但工具执行和输入处理在某些智能体工作流程中可能占据主导地位。Fireworks 尚未发布足够的独立证据，无法将延迟影响概括到不同部署环境。
即使存在这些限定，这一机制依然具有战略重要性。如果后训练能够持续消除浪费，推理效率就会成为模型自身的一项属性，而非应用侧的妥协。
经训练的效率优于低强度的捷径
Fireworks 最有力的证据并不是 Ember-1 总能获胜，而是它以更少的生成 Token 接近 K3 Max 的质量。
Fireworks 将 Ember-1 与处于低、高和最高推理设置下的 Kimi K3 进行了评估。该公司使用相同的公开 K3 费率计算基准成本，以隔离由更短输出带来的节省。
最有利的结果出现在 Terminal-Bench 2.1 和 DeepSWE 1.1 上。Ember-1 在 Terminal-Bench 上得分 82.0%，而 K3 Max 为 80.9%。
在 DeepSWE 1.1 上，Fireworks 报告 Ember-1 得分为 75.2%，K3 Max 为 66.4%。该评估涵盖 113 项任务。
DeepSWE 测试跨活跃代码仓库和多种编程语言的长周期工程工作。其发布的 DeepSWE methodology 强调使用原创任务，旨在降低数据暴露和污染方面的担忧。
结果并非一贯有利于 Ember-1。Ember-1 在 SWE-bench Verified 上得分 92.2%，而 K3 Max 得分 93.2%。它在 SWE-Interact 上也达到 20.0%，而 K3 Max 为 21.3%。
这些损失以百分点计很小，但仍然重要。它们表明，“相同质量”描述的是一种总体判断，而非在每项测试上都具备完全相同的能力。
Ember-1 在 τ-2 Bench 的航空部分达到 66%，而所有三种 K3 推理强度设置均为 64%。该结果覆盖 50 个样本，这是 Fireworks 用于公开比较的最小样本量。
Fireworks 表示，在七项基准和两项客户工作负载中，它在不牺牲整体准确性的情况下，将 K3 的推理长度缩短了 35% 至 50%。该公司将 Ember-1 定位在质量与成本 Pareto 前沿之上或附近。
Pareto 前沿描述的是这样一组选择：改善一个维度必须以牺牲另一个维度为代价。在这里，当没有任何替代方案能够同时提供更高质量和更低任务成本时，模型就位于或接近该前沿。
这种框架比单一排行榜排名更有用。企业用户关心的是以可接受的成本完成任务，而不仅仅是附在某个模型名称后的最高百分比。
不过，Pareto 主张高度依赖所选择的任务、智能体脚手架、提示词、重试策略和成本假设。改变其中任何一项输入，都可能改变模型的位置。
Fireworks 还在 Bedside Bench 上评估了 Ember-1；这是一个由医生验证、涵盖 10 个类别的 500 个临床案例集合。该公司表示，在其 Specialized Intelligence Index 所纳入的模型中，Ember-1 建立了新的每任务成本前沿。
这一结果将模型的叙事拓展到编程以外。不过，医疗基准并不能证明该模型适合用于临床部署、诊断或无监督医疗决策。
更恰当的理解是，它提供了关于结构化专业推理的证据。它展示了 Fireworks 希望如何在真实任务类别中评估专用模型，而不仅仅依赖一般学术测试。
生产环境的采购方还应区分百分点差异与运营可靠性。很小的平均改进，可能掩盖在某家公司最看重任务上的退步。
因此，恰当的比较应当针对具体工作负载。团队应使用固定的智能体脚手架、相同的工具权限和一致的成功标准，重放具有代表性的任务。
它们应综合衡量总 token 数、完成的任务数、重试次数、完成耗时和失败严重程度。只有在系统仍能达成可用结果时，减少 token 才有价值。
这种严谨的评估方式也有助于建立一个可搜索的知识库。在比较快速变化的模型端点时，团队需要保留提示词、评估记录和失败案例。
Ember-1 为反对“低投入捷径”提供了可信的论据。但它尚不足以证明，某一家厂商的后训练方案能够泛化到所有 Agent、代码库或专业领域。
生产测试让这一主张更具体
客户 A/B 测试为 Ember-1 提供了最具实用价值的证据，不过 Fireworks 尚未披露客户身份或其评估数据。
Fireworks 表示，它与两家客户一道，使用真实的生产级编程工作负载测试了 Ember-1。据称，两者在质量相当的情况下，每项任务生成的 token 均减少约 35%。
该公司公布了其中一组对比的更详细数据。Kimi K3 组得分为 0.751，而 Ember-1 组得分为 0.753。
平均步骤数从 23.8 降至 21.4。每项任务的输出 token 从 49,300 降至 29,900。
Fireworks 报告称，推理 token 减少了 71.3%，总 token 减少了 39%。它还表示，完成、成功和失败指标总体保持稳定或有所改善。
据称，一家参与客户已将 Ember-1 投入实时生产环境，并计划将其规模化部署，用以替代基础模型。该客户的身份、样本规模、工作负载构成和评估标准均未披露。
这些缺失信息使得外部无法独立评估统计显著性。0.751 到 0.753 的变化，可能意味着性能相当、随机波动，或是小幅提升。
由于 token 变化的幅度大得多，因此更难被忽视。不过，读者仍需了解，这些平均值是否受到任务长度、失败运行、缓存行为或停止条件变化的影响。
平均步骤数提供了一条线索。Ember-1 使用的步骤更少，这表明部分节省来自更短的执行轨迹，而不仅是每一步内部推理更短。
当模型避免不必要的工具调用时，这可能是有益的。但若成功指标无法捕捉未完成的工作，它也可能掩盖过早终止的问题。
Fireworks 表示，Ember-1 未成功的尝试同样保持较低的 token 消耗。这一特征可能有助于限制 Agent 无法解决任务时的支出。
低成本失败并不天然等于有价值的失败。开发者仍需要清晰的错误状态、可见的执行轨迹和升级规则，以避免较短的尝试将未完成工作悄然传递到下游。
内部测试还增加了另一项信号。Fireworks 在向客户开放该模型之前，已将其自身部分编程和 cowork 流量路由至 Ember-1。
该公司称，其开发者并未察觉模型切换，而 token 消耗有所下降。这是一项有意义的可用性观察，因为理想情况下，效率模型的使用体验应当平稳无感。
不过，这仍属于轶事性证据。Fireworks 没有公布开发者人数、内部测试时长、任务构成或受控的满意度衡量指标。
尽管如此，以生产环境为框架的评估，使 Ember-1 区别于那些仅针对公开排行榜优化的模型。真实 Agent 工作负载包含混乱的代码库、不断变化的需求、失败的工具调用和反复交互。
这恰恰是推理膨胀变得昂贵的地方。与此同时，如果模型跳过了干净基准测试中不需要的检查，压缩推理也可能带来隐蔽风险。
最站得住脚的结论比 Fireworks 的营销表述更为有限：在该公司的评估中，Ember-1 显著降低了 token 消耗，同时大体保持了所衡量的任务质量。
这一结果值得大规模运营编程 Agent 的团队关注。但在切换生产系统之前，仍有必要进行工作负载层面的测试。
缺失的权重限制了独立验证
Ember-1 继承了开放权重基础模型，但其仅 API 发布的方式，使外部人士无法复现该模型或审计其所称的训练机制。
Fireworks 将 Ember-1 称为自研模型，也是其计划推出的一系列专用模型中的首个版本。不过，该公司尚未发布 Ember-1 的权重、训练代码或精确算法。
这与更广泛的开放模型叙事之间形成了张力。Kimi K3 为研究人员和基础设施团队提供了更多控制权，而 Ember-1 则将这一专用衍生模型转化为托管服务。
开发者可以比较端点行为，但无法检查模型 checkpoint。他们也无法确认，所报告的改进能否在不同推理基础设施或解码实现下延续。
预览版形式又增加了一层不确定性。Fireworks 表示，研究模型会获得有限的 serverless 访问权限，并可能依据社区需求转为永久提供。
对于需要稳定模型标识符、可重复评估或漫长采购周期的团队而言，临时端点会增加采用难度。一次成功测试并不能保证其会在相同条件下持续可用。
基准测试证据也需要谨慎解读。Fireworks 自行运行评估，并选择了对比设置。
其 Terminal-Bench 和 DeepSWE 成绩看起来很强，但独立排行榜提交会更具说服力。外部团队的重复测试可能揭示方差、脚手架敏感性或特定工作负载下的性能退化。
SWE-bench Verified 带来了额外问题。2026 年 2 月，OpenAI 表示已停止报告该基准测试结果，因为数据暴露正在削弱它衡量前沿编程能力的效力。
基准污染警告建议，应使用更新的评估方法来判断当前编程能力。Fireworks 的 92.2% 结果仍具有描述价值，但不应成为整个论证的支柱。
DeepSWE 和 Terminal-Bench 有助于使证据更加多元化。即便如此，没有任何基准测试能够完整复现拥有私有代码、组织专属工具和业务后果的生产 Agent。
生产 A/B 测试在一定程度上弥补了这一缺口，但匿名性限制了审查。Fireworks 尚未提供任务级结果、置信区间或客户自行撰写的说明。
围绕“token 减少 40%”还存在语义问题。Fireworks 有时将降幅描述为推理 token，有时则讨论输出 token 或总 token。
其详细的生产案例报告显示，推理 token 减少 71.3%，总 token 减少 39%，输出 token 则从 49,300 降至 29,900。这些指标存在重叠，但不可互换。
买方应询问哪一种衡量方式适用于自身工作负载。模型可能大幅减少隐藏推理，却让可见输出保持不变；也可能通过缩短最终回复来降低总输出。
在评估前，也必须先定义质量。精确完成任务、人工偏好、测试通过率和业务成功率，可能会对同一次运行得出不同结论。
对安全敏感的团队应检查，更短的推理是否会改变工具决策。一个调用更少工具的 Agent 可能节省 token，却也可能减少验证步骤或绕过防御性检查。
这些问题都不会否定 Fireworks 的结果。它们界定了将这一主张从有前景的厂商证据转化为可重复的行业结论所需完成的工作。
目前可以进行独立端点测试。除非 Fireworks 发布专用权重、训练方法，或提供足以让其他团队重建该过程的实验细节，否则完整的科学复现仍不可能实现。
三个信号将决定 Ember-1 能否持续存在
下一阶段取决于独立测试、永久可用性，以及 token 节省能否在 Fireworks 偏好的工作负载之外保持有效的证据。
第一个信号是在 Terminal-Bench 2.1 和 DeepSWE 1.1 上进行独立复现。评估者应使用有文档记录的脚手架，公布完整配置，并报告多次重复运行之间的变化。
若结果接近 Fireworks 公布的分数，将增强效率主张的可信度。若出现大幅退化或 token 节省不稳定，则表明 Ember-1 高度依赖该公司的评估设置。
第二个信号是 Fireworks 对可用性的决定。永久提供 Ember-1 端点，将表明需求和运营信心已足以支持真实部署。
预览版若被终止，并不能证明技术理念失败。但这将限制 Ember-1 作为产品的重要性，并使关注点转向 Fireworks 的训练平台。
第三个信号是更广泛的生产证据。具名客户、更大的任务样本，或第三方案例研究，应在报告总 token 和延迟的同时，报告任务完成率。
跨不同代码库、语言和 Agent 框架的证据，将支持 Fireworks 关于训练后效率可泛化的主张。若节省仅集中在一种编程工作流中，则会缩小该模型的价值范围。
竞争对手的行为将提供辅助背景。Moonshot 可以提升 K3 的原生效率，其他推理服务提供商也可以对开放模型进行后训练，以实现更短的推理。
如果这种模式扩散，Ember-1 将作为更大转变的早期实例而变得重要。模型买方将比较每个 token 产生的有效工作量，而不再只看智能分数或上下文窗口大小。
这种方法也改变了团队评估 Agent 的方式。长执行轨迹不应再被视为系统进行了更深入或更优推理的证据。
冗长分析可能反映富有成效的验证、反复的不确定性，或单纯的低效。只有任务结果和受控测试能够区分它们。
Fireworks AI Ember-1 针对这一问题提出了聚焦且合理的回应。该公司提供了有意义的基准和生产证据，但仍保留了足够多的细节，使完整验证无法实现。
开发者应在自身的任务分布上，将该模型与 K3 Max 和 K3 Low 进行测试。所有组别都应保持相同的提示词、工具、停止规则和评分体系。
应像跟踪 token 总量一样仔细跟踪失败情况。检查 Ember-1 是否跳过验证、是否更早退出困难任务，或是否改变错误的严重程度。
最终问题很实际：Fireworks AI Ember-1 能否以更少的 token 完成你的真实工作，同时不把风险转移到更不易察觉的地方？应在预览结束前进行这一对比，并保留足够证据，以便日后重复验证。
