Fireworks Ember-1：號稱少用 40% token，品質能守住？（2026）

2026 年 9 月 23 日，Fireworks Research 在官網發布了 〈Introducing Ember-1〉。這篇文章談的 Ember-1 推理成本，不只是模型回話變短：Fireworks 主張它以 Kimi K3 為底，重新訓練推理方式，在品質相近時減少約 40% token。這裡先還原原文的實驗和產品主張，再對照公開規格與測試邊界，最後看它能否真的替長流程 Agent 省錢。

Fireworks 想解的問題：思考越長，帳單越厚

原文的起點是寫程式 Agent 的多輪工作：每次產生的推理文字要付輸出費；若後續請求又帶入先前內容，舊內容也可能增加輸入費。Fireworks 認為，單純把 Kimi K3 的 reasoning effort 調低會傷及品質，因此用跨數學、程式、搜尋與工具使用的任務回饋來訓練 Ember-1。它自述做過逾 50 次訓練實驗、逾 200 次評估，並稱訓練資料沒有使用客戶資料；這些都是 Fireworks 對自身流程的陳述。

Turning down K3's reasoning effort didn't solve this.

中文：只把 K3 的推理努力程度調低，沒有解決他們看到的品質與成本取捨。

Fireworks〈Introducing Ember-1〉

這個區分很重要：限制輸出長度可能把必要的查錯步驟一併砍掉；訓練模型選擇何時反省，理論上才可能保留難題所需的計算。原文想證明的是後者，但訓練演算法的細節與可重跑的完整逐題記錄仍需更多公開材料，讀者應把以下結果視為公司測得的案例。

原文數字怎麼讀：40% 是一個摘要，差異藏在任務裡

Fireworks 列出五組公開任務比較：Terminal Bench 2.1 的樣本數為 89，Ember-1 通過率 82.0%，K3 max 為 80.9%；SWE-bench Verified 是 500 題，分別為 92.2% 與 93.2%；DeepSWE 1.1 是 113 題，分別為 75.2% 與 66.4%。這些數字都出自 Fireworks 的評估，不等於各基準主辦單位對 Ember-1 的獨立認證。尤其 SWE-bench Verified 評的是能否修復指定軟體問題，分數還受 Agent scaffold、工具與評分設定影響；其官方頁面也提醒不同執行設定的結果需要分開比較。

Doximity 對 Bedside Bench 的原始介紹確認題庫有 500 個醫師驗證案例、分成 10 組。Fireworks 把 Ember-1 放進這個題庫，畫出品質與成本的散點圖；它支持「值得進一步測」的訊號，卻不能由圖上位置推論臨床部署的安全性，也不能把發布題庫與測出 Ember-1 分數混成同一個獨立驗證。

更接近產品現場的是兩家客戶的 coding A/B。Fireworks 說每項任務約少用 35% token、品質相近；其中一份摘要表的 K3 與 Ember-1 分數為 0.751／0.753，平均步數 23.8／21.4，輸出 token 49.3K／29.9K，表列總 token 減少 39%。輸出量按表計算約少 39.4%，與標題的「約 40%」相符；但 0.002 的分數差本身不能證明兩者品質統計上等價。另一家客戶的逐題分布、樣本規模與評分規則，讀者仍須向 Fireworks 索取後才能檢查外推範圍。

Ember-1 推理成本：token 少 40%，費用也少 40% 嗎？

Every turn replays all prior reasoning back to the model

中文：Fireworks 認為，早期推理若反覆進入後續上下文，會放大多輪任務的花費。

Fireworks〈Introducing Ember-1〉

這句話描述一種常見的上下文累積方式，不是所有 Agent 的必然帳單。系統可以摘要或刪除舊推理，也可能命中輸入快取；不同工作流的工具呼叫與重試更會改變總量。因而要比較的是「完成同一任務的總費用」，並同時計入成功率、補救成本與延遲，而不是只看某一次回覆的 reasoning token。

截至本文核對時，Fireworks 的 Ember-1 產品頁與 Kimi K3 產品頁都列出相同 Serverless 標價：每百萬 uncached input／cached input／output token 為 US$3／US$0.30／US$15。若只看表中的單項任務輸出，49.3K 與 29.9K token 對應約 US$0.74 與 US$0.45，差約 US$0.29；這只算輸出，並非完整任務帳單。輸入、快取與失敗重試若佔比較高，實際節省率就會不同。

我的判讀：方向有價值，證明還停在有限場景

我同意：把「想多久」變成可訓練的能力

對固定任務，冗長推理若沒有提高完成率，就是花錢買重複。Fireworks 的數據至少提出一個可檢驗假說：同一底座模型經任務回饋訓練，可能比直接壓低努力檔位更有效率。其 SWE-bench 與客戶 A/B 摘要在方向上互相呼應，值得用自己的任務集做對照。

我存疑：平均品質掩蓋尾端失敗

一個 Agent 若省下大多數簡單題的 token，卻在少數高代價任務多錯一次，平均分數與平均費用可能同時好看。臨床題庫與程式修復題庫也不是同一種風險。評估時應把困難程度、失敗重試、人工接手和長對話累積成本分開；尤其要看最差的一成任務，而不只看總平均。

公司商業利益與可驗證範圍要一起看

Fireworks 同時銷售 Ember-1 的推理服務和後續客製訓練。這使「同樣品質、更低成本」成為很強的產品敘事，卻不自動否定它的測試。更合理的態度是承認公司提供了具體比較數字，同時要求同一套 Agent 設定、逐題結果和完整帳單，讓其他人可檢查哪些任務真的受益。Research Preview 的供應安排也應納入採用決策；原文說初期提供兩週 Serverless 研究試用，再視社群需求決定長期供應。

如果你正在選模型，先做這個小型對照

從現有任務挑一組簡單、一般、困難案例，固定提示詞、工具、資料與停止條件，交替送給 Kimi K3 和 Ember-1。每題記下是否真正完成、輸入／快取輸入／輸出 token、重試次數、端到端時間與人工修正分鐘數。把「完成任務的總費用」和失敗案例並列，再決定是否擴大流量；研究預覽階段尤其適合先保留回退路徑。這不是 AlphaLab 已完成的實測，而是讓團隊檢查 Fireworks 主張能否轉移到自己工作流的驗收方式。

想理解為何模型單價與任務成本會分離，可接著讀 Opus 5.5 的任務成本分析；若要辨認程式基準的測法差異，SWE-2 成本與分數的對照提供另一個案例。