Fireworks发布Ember-1：同等质量，少用40% Token

Fireworks在9月23日发布了Ember-1，这是该公司首个以Fireworks品牌推出的模型。它不是一个单纯追求参数规模的新模型，而是Fireworks Research围绕“如何让每一个Token发挥更大作用”训练出的专用推理模型。

Ember-1的核心卖点是：在与Kimi K3保持相近质量的前提下，生成Token数量减少约40%。这意味着，同一个编码任务、Agent工作流或长链路推理任务，模型可以用更短的思考轨迹完成，开发者需要支付的输出Token费用也会相应下降。

这条消息的重点不在于Fireworks又接入了一个模型，而在于它开始从模型基础设施提供商，向模型研发者转变。过去Fireworks更像是一个面向开发者的模型部署和推理平台；Ember-1则代表它开始直接参与模型能力竞争。

Ember-1是什么

Ember-1是Fireworks Research推出的专用推理模型，基于Kimi K3进行针对性训练和优化，重点服务编码、工具调用和Agent工作流。

这里的“专用模型”并不等于功能缩水的小模型。Ember-1支持文本和图片输入、函数调用、隐式推理以及100万Token上下文窗口，能力范围覆盖当前开发者最常见的复杂任务场景。它的差异在于训练目标更集中：减少无效推理、压缩冗余输出，同时尽量保留模型在代码生成、任务拆解和工具使用上的稳定性。

从产品定位看，Ember-1与通用聊天模型的关系，更接近“针对生产环境优化的工作版本”。通用模型可以处理更广泛的问题，但在Agent场景里，真正影响成本和体验的往往不是一次回答是否惊艳，而是模型能否少走几步、少调用几次工具、少输出一大段重复分析。

Fireworks没有公布Ember-1的参数规模，也没有在公开资料中给出完整的训练配方或推理轨迹压缩方法。因此，目前更准确的说法是：Ember-1是一个基于Kimi K3、经过Fireworks专门后训练和推理优化的研究预览模型，而不是一个完全从头训练的基础模型。

40%更少Token，价值到底有多大

“少40% Token”只有在质量没有明显下降时才有意义。否则，它可能只是把答案写短了，而不是让模型更高效。

Fireworks给出的说法是，Ember-1在保持Kimi K3相近质量的前提下，将生成Token减少约40%。如果一次任务原本需要生成10,000个输出Token，Ember-1大约只需要6,000个Token。按照Fireworks公开的价格，输入价格为每百万Token 3美元，输出价格为每百万Token 15美元，单次任务的输出成本可以从0.15美元降至0.09美元，理论上下降40%。

| 项目 | Kimi K3参考值 | Ember-1公开信息 | 变化 | |---|---:|---:|---:| | 输出Token | 10,000 | 约6,000 | 减少约40% | | 输出价格 | 15美元/百万Token | 15美元/百万Token | 标价相同 | | 单次输出成本 | 0.15美元 | 0.09美元 | 理论下降40% | | 上下文窗口 | 100万Token | 100万Token | 保持一致 | | 视觉输入 | 支持 | 支持 | 保持一致 | | 工具调用 | 支持 | 支持 | 面向Agent优化 |

这个计算没有考虑缓存、重试和输入Token，但它能说明Ember-1的商业逻辑：模型单价没有便宜，真正降低的是完成任务所需要的Token数量。

对于普通聊天，这种节省未必明显。用户每天问几十个问题，输出Token减少40%带来的绝对金额有限；但对持续运行的代码Agent、自动化客服、数据分析机器人和浏览器操作Agent来说，差别会快速放大。

假设一个编码Agent每天处理10万次任务，每次平均生成8,000个Token。按照15美元/百万输出Token计算，原模型每天需要12,000美元；如果Ember-1把生成量降低40%，在任务质量和成功率不变的情况下，每天可以减少4,800美元的理论输出成本。现实账单还会受输入长度、缓存命中率、失败重试和并发调度影响，但量级不会改变。

更重要的是，Token减少通常还会带来延迟下降。模型生成速度不变时，输出长度从8,000个Token降到4,800个Token，纯生成阶段的时间理论上也减少40%。对于需要多次调用模型的Agent链路，减少的不只是账单，还有用户等待时间和后续工具调用的排队压力。

它为什么适合编码和Agent

编码Agent最怕的不是模型偶尔答错，而是模型在错误方向上持续消耗Token。一个模型可能先分析需求，再重复解释约束，接着生成一份过长的计划，最后才修改代码。只要中间任何一步判断错误，后续输出都会变成成本。

Ember-1的优化方向，正好针对这种低效。它试图把推理过程压缩成更短的有效轨迹，让模型更快进入“检查文件、修改代码、运行测试、根据结果修正”的循环，而不是长时间停留在自我解释上。

对Agent系统而言，Token效率通常由四个环节决定：

• 任务拆解：能否把复杂请求拆成少量可执行步骤。
• 工具选择：能否直接调用正确工具，而不是反复尝试。
• 上下文管理：能否从大量历史信息中提取真正相关的内容。
• 错误恢复：失败后能否根据报错修正，而不是重复原操作。

Ember-1支持函数调用，意味着它可以被放进需要调用搜索、文件系统、数据库或代码执行器的工作流。它还支持视觉输入，这对处理截图、网页界面、流程图、设计稿和带有图表的技术文档有实际意义。

不过，支持工具调用不等于Agent一定可靠。工具调用的成功率、参数正确率、是否会陷入循环，以及模型在长上下文中的信息取舍能力，都需要开发者通过真实任务评估。Ember-1目前是研究预览版本，Fireworks公开资料也没有给出完整的函数调用成功率、SWE-Bench成绩或多轮Agent基准结果，因此不能仅凭“40%更少Token”判断它已经全面超过Kimi K3或其他主流编码模型。

100万Token上下文不是越大越好

100万Token上下文窗口是Ember-1的另一个重要参数。上下文窗口是模型一次能够接收和处理的最大输入信息量，100万Token大致可以容纳大型代码库、长篇技术文档或多轮Agent运行记录。

但超长上下文的实际价值，不是把所有文件一股脑塞给模型。真正的难点是检索和取舍：模型能否在100万Token中准确找到某个接口定义、历史报错或配置约束，并把它用于当前决策。

在代码场景里，100万Token可以支持更大的仓库级任务。例如，开发者可以同时提供多个服务目录、数据库迁移文件、测试用例和部署配置，让模型理解一个功能从前端到后端的完整链路。这比只打开当前文件，更接近真实的软件工程。

但长上下文也可能造成两个问题。第一是成本问题，100万Token的输入即使只发送一次，也会产生可观的账单；第二是注意力稀释，信息越多，模型越可能把无关内容当成重要线索。因此，Ember-1的长上下文更适合经过检索、摘要和分层加载后的复杂任务，而不是作为“把整个硬盘丢给模型”的理由。

Fireworks同时提供缓存读取价格，每百万Token为0.3美元。对于反复访问同一份代码库、产品文档或系统规则的Agent，这个价格明显低于标准输入价格。开发者可以把稳定的系统提示、项目规范和基础代码放入可复用上下文中，再为每次任务追加变化部分，从而降低重复输入的费用。

与Kimi K3相比，Ember-1该怎么选

Ember-1与Kimi K3的关系，是这次发布最值得关注的部分。Fireworks没有把它包装成完全不同的基础模型，而是强调在Kimi K3质量基础上的专门优化。对开发者来说，选择重点不应只是看模型名称，而应看任务是否需要更高的Token效率。

| 模型 | 定位 | 上下文窗口 | 输入价格 | 输出价格 | 主要特点 | |---|---|---:|---:|---:|---| | Ember-1 | Fireworks专用推理模型 | 100万Token | 3美元/百万Token | 15美元/百万Token | 约少40%生成Token，面向编码和Agent | | Kimi K3 | 通用推理模型 | 100万Token | 3美元/百万Token | 15美元/百万Token | 通用能力和长上下文能力更完整 | | DeepSeek-V4-Flash | 高性价比通用模型 | 100万Token | 需以平台最新价格为准 | 需以平台最新价格为准 | 偏向大规模调用和成本控制 | | 通用小型模型 | 低成本基础任务模型 | 通常较短 | 通常较低 | 通常较低 | 适合分类、抽取和简单问答 |

如果任务是代码生成、仓库级修改、自动修复和多步骤工具调用，Ember-1值得优先测试。它的优势不在于每次回答都比通用模型更聪明，而在于能够以更短输出完成相同工作。

如果任务涉及开放式写作、复杂知识问答、风格控制或需要更广泛的通用能力，Kimi K3仍然可能更稳妥。Fireworks目前没有公开足够多的跨基准结果，无法证明Ember-1在所有任务上都优于原模型。

至于DeepSeek、Qwen、GLM等其他模型，比较时应把“每次任务成本”而不是“每百万Token价格”作为核心指标。一个单价更低但需要多轮重试的模型，最终成本可能高于单价更高、一次完成率更高的模型。Agent产品尤其如此，因为失败会带来额外的模型调用、工具执行和上下文传递。

对开发者意味着什么

Ember-1释放出的信号是，模型竞争正在从“谁的参数更大”转向“谁能更高效地完成任务”。当基础模型能力逐渐接近时，后训练、推理轨迹、工具调用和部署成本会成为更直接的竞争维度。

这也是Fireworks开始发布自有模型的原因。单纯提供推理基础设施，容易陷入价格和吞吐量竞争；拥有针对特定任务优化的模型，则可以把平台能力、调度系统和模型训练结合起来。Fireworks此前已经在开放模型部署、推理优化和模型路由方面积累了基础，Ember-1是把这些经验向模型层延伸。

对使用方而言，建议在真实工作流中做四项评估：

1. 任务成功率：代码是否能通过测试，工具调用参数是否正确，Agent是否能完成最终目标。
2. 有效Token数：不要只看平均输出长度，要记录完成成功任务所消耗的总Token。
3. 端到端延迟：分别统计首Token延迟、完整输出时间和整个Agent任务耗时。
4. 失败重试成本：一个看似便宜的模型，如果经常需要重试，实际成本会迅速上升。

可以把同一批真实任务分别交给Ember-1、Kimi K3和当前生产模型，固定提示词、工具定义和最大重试次数，再比较总成本与成功率。单看公开基准或演示案例，无法替代这类面向业务的评估。

目前仍有三个问号

第一，Ember-1的完整模型规格尚未公开。包括参数规模、训练数据范围、具体后训练方法和推理机制在内，目前都缺少足够细节。Fireworks称其为研究预览模型，也意味着正式生产使用前需要关注版本变化。

第二，40%的Token减少是否覆盖所有任务，还有待验证。编码Agent、数学推理、结构化输出和长文写作的输出特征不同。一个模型在代码修复中更简洁，不代表它在复杂研究任务里同样高效。

第三，质量对齐的依据是什么。Fireworks目前强调与Kimi K3保持相近质量，但公开信息中没有完整列出使用的基准、样本数量、置信区间和失败案例。对于需要稳定性的企业用户，最好等待更多第三方测试，或者直接使用自身历史任务进行A/B评估。

结论：Ember-1值得试，但还不到盲选的时候

Ember-1是Fireworks从模型平台走向模型研发的重要一步。它没有用更大的参数规模制造话题，而是把重点放在一个更接近生产现实的问题上：同样的任务，模型能不能少生成一些无效Token、少调用几次工具，并更快交付结果。

目前公开信息显示，Ember-1基于Kimi K3优化，支持100万Token上下文、视觉输入和函数调用，输入价格为3美元/百万Token，输出价格为15美元/百万Token，Fireworks宣称其生成Token减少约40%。这些参数让它特别适合编码Agent、自动化工作流和高频推理任务。

但它的真实竞争力仍取决于任务成功率和第三方评测。对开发者来说，Ember-1值得加入测试池，尤其适合与Kimi K3进行同任务对照；对需要马上上线的生产系统，则应先验证长上下文表现、工具调用稳定性和失败重试成本，再决定是否切换。

Fireworks这次发布的真正看点，不是又多了一个模型名称，而是模型厂商开始把“更少Token完成同一件事”作为产品能力来竞争。随着Agent调用量继续上升，这种效率优化可能比单次跑分提升更快转化为真实的成本优势。

参考来源

• Hugging Face 模型搜索：Ember-1：用于核对公开模型条目与社区收录情况。
• GitHub 代码搜索：Ember-1：用于查看开发者社区中的相关集成和评测线索。
• Fireworks 官方博客《Introducing Ember-1》：本文关于模型定位、Kimi K3基础、Token减少比例和产品参数的主要信息来源。由于原始页面域名不属于本文指定的可引用域名范围，未在文中保留外部链接。