Fireworks AI Ember-1、Kimi K3のトークン負荷を削減するが、根拠は依然としてベンダー主導
Fireworks AIは、Kimi K3のタスク性能を維持しつつ生成トークンを約40%削減するという明確な約束とともにEmber-1を発表した。Fireworks AI Ember-1モデルは、特に以前の推論を後続ターンへ繰り返し持ち越すコーディングエージェントにおいて、推論システムのコスト高という弱点を狙っている。
重要な比較対象は、Ember-1と無関係な最先端モデルとの対決ではない。推論時にKimi K3の推論努力を抑えるという単純な代替策に対し、学習による効率化がどれほど有効かという比較だ。Fireworksによれば、低い設定ではトークンを節約できる一方で精度の低下が大きすぎるため、後学習によってEmber-1に残すべき推論を学習させたという。
この主張が重要なのは、トークン量の多い推論が長時間のエージェントセッションで累積するためだ。ただし、根拠の大半はFireworks自身によるものである。Ember-1はAPI限定の研究プレビューでもあり、外部研究者は重みを調査したり、学習プロセスを独立して再現したりできない。
Fireworks AI Ember-1はKimi K3のコスト構造を変える
Ember-1は、推論の長さをモデル品質に伴う固定コストではなく、学習可能な振る舞いとして扱う。
Fireworksは2026年9月23日にEmber-1を発表した。公式のEmber-1リリースによると、この特化モデルはMoonshot AIのKimi K3オープンウェイトを基に後学習された。
後学習とは、基盤モデルが一般的な能力を獲得した後に追加で行う学習を指す。ここでの目的は、新しい基盤モデルの構築よりも限定的だった。Fireworksは、有用な分析を放棄せずにK3がより短い推論トレースを使えるようにしたかったという。
同社によれば、顧客はK3のコーディング能力を高く評価する一方で、大規模利用では長い推論が高コストだと感じていた。研究チームは、利用可能な推論努力を下げるだけでは十分な品質を維持できないと結論づけた。その代わりに、生産的な熟考を保ちながら冗長なループを取り除くようEmber-1を学習させた。
Fireworksは、チームが50件を超える学習実験と200件を超える評価を完了したと報告している。学習セットは、数学、コーディング、指示追従、会話、検索、ツール利用、ソフトウェアエンジニアリングを対象とした。
これらのカテゴリーは重要だ。なぜなら、トークン効率は一つの狭いワークロードに過度に適合する可能性があるからだ。短いコーディング問題だけで学習したモデルは、エージェントが検索、ツール呼び出し、計画の修正、エラーからの回復を行わなければならない状況で苦戦するかもしれない。
Fireworksによれば、オンポリシー学習ではタスクフィードバックと環境フィードバックが用いられた。オンポリシー学習では、学習中に現在のモデルが生成した振る舞いを使うため、実際に生成する推論パターンにフィードバックを反映できる。
同社はまた、顧客データではなく自社データを使用したとしている。完全なデータセット、学習アルゴリズム、学習コード、Ember-1の重みは公開していない。
Ember-1は現在、研究プレビューとしてFireworks Serverless経由で提供されている。Fireworksはこの種のプレビューを、コミュニティ需要が継続提供を正当化する場合に恒久化される可能性がある、限定的なサーバーレス提供だと説明している。
この配布形態は最初の大きな制約を生む。開発者はAPI経由でモデルを試せるが、自前でホストしたり、パラメータを調べたりはできない。したがって独立した評価者は、Fireworksが管理する条件下でホスト型エンドポイントをテストすることになる。
比較の基盤となるのはKimi K3だ。Moonshotは7月にK3を発表し、ネイティブな視覚機能と100万トークンのコンテキストウィンドウを備える2.8兆パラメータモデルとして位置づけた。公式のKimi K3仕様では、長時間のコーディングセッション、ナレッジワーク、推論を用途としている。
Moonshotは低・高・最大の推論努力設定も提供している。このためK3は、Fireworksの主張にとって特に有用なベースラインとなる。同じ基盤モデルファミリーを、推論設定ごと、さらに別途後学習された派生モデルと比較できるからだ。
したがって、この出来事は単なる新モデルの発表以上の意味を持つ。Fireworksは、プロバイダーが無駄を学習によって取り除くべきであり、顧客にそれを受け入れさせたり、手動で推論深度を下げさせたりすべきではないと提案している。
この考え方は、推論プラットフォームとモデルベンダーの双方に圧力をかける。トークン効率の高い後学習が本番ワークロード全体で機能するなら、ベンチマークの素の品質は購入判断の一要素にすぎなくなる。
長い推論トレースがエージェントのコスト問題になる理由
冗長な推論トレースは単に長い回答ではない。エージェントはそのトレースを後続のあらゆるステップに持ち越す可能性があるからだ。
推論モデルは、最終回答を出す前に中間的な分析を生成する。Fireworksによれば、こうした内部推論トークンは、モデルが生成する出力全体の90%超を占める場合がある。
この割合は同社報告による観測であり、すべての推論モデルに共通する性質ではない。それでも、マルチステップのエージェントにおける実際のアーキテクチャ上の懸念を示している。
単一の長い応答であれば、コストは一度だけ発生する。しかしエージェントは、別のツールを呼び出したり、結果を確認したり、修正を試みたりする際に、以前のメッセージをモデルへ再送することが多い。
その結果、以前の推論は繰り返し処理されうる。Fireworksは、このコンテキストの増大をターン数に対しておおむね二次的だと説明している。新しいターンごとに、拡大していく履歴全体が再処理される可能性があるためだ。
実務上の影響はコーディングシステムで見えやすい。エージェントはリポジトリを調査し、パッチを提案し、テストを実行し、失敗を診断し、複数のファイルを修正することがある。追加のターンには、次の判断にもう役立たない以前の分析が含まれる可能性がある。
ユーザーから推論を隠すだけでは、必ずしもこの負担はなくならない。API設計とコンテキスト処理のルール次第では、プロバイダー側では依然として推論トークンが生成・処理される。
推論努力の設定を下げることは、明白な対応策だ。モデルは分析に費やす時間が短くなり、生成トークンが減り、より速く応答する。
Fireworksは、このアプローチでは冗長な推論とともに価値ある推論も失われると主張する。同社のベンチマーク結果では、低努力設定のK3は、評価された複数のコーディングタスクにおいて最大努力設定のK3を下回った。
たとえばFireworksは、Terminal-Bench 2.1においてK3 Lowの合格率が76.4%だったと報告している。K3 Maxは80.9%、Ember-1は82.0%に達した。
このベンチマークは、ソフトウェアエンジニアリング、システム管理、データ処理、セキュリティ、および関連するコマンドライン作業を対象とする89件のターミナルベースのタスクで構成される。管理者はTerminal-Bench 2.1の公開時に28件のタスクを改訂した。
低努力設定と学習済み効率化の違いこそが、中核となる仕組みだ。低い設定は、元のモデルに少ない推論予算を与える。後学習は、その予算をモデルがどのように配分するかを変えようとする。
有用な自己反省には、前提の確認、失敗したコマンドへの気付き、環境からのフィードバックを受けた計画の修正などが含まれる。冗長な推論には、繰り返しの要約、放棄されたループ、最終的な行動を変えない長い熟考が含まれる。
Ember-1には、これらのカテゴリーを区別することが期待されている。Fireworksによれば、このモデルは、タスク完了を改善する熟考を保持する一方、失敗した試行の最中も含め、非生産的なループを抑制する。
この区別を最終回答だけから検証するのは難しい。同じ正しいパッチを生成する2つのモデルでも、内部では大きく異なる経路をたどる可能性がある。また、集計スコアが同等でも、異なるタスクで失敗する場合がある。
そのため本番チームには、平均トークン数以上の情報が必要だ。圧縮がいつ機能するのか、どのタスクで精度が低下するのか、まれな失敗が検出しにくくなるかを示す分布が求められる。
レイテンシーにも注意が必要だ。出力トークンが少なければ通常は生成時間が短縮されるが、一部のエージェントワークフローではツール実行と入力処理が支配的になる。Fireworksは、デプロイメント全般にわたるレイテンシーへの影響を一般化できるほど十分な独立証拠を公開していない。
こうした留保があっても、この仕組みは戦略的に重要だ。後学習が一貫して無駄を取り除けるなら、推論効率はアプリケーション側の妥協ではなく、モデルそのものの特性になる。
学習済み効率化は低努力設定という近道を上回る
Fireworksにとって最も強い根拠は、Ember-1が常に勝つことではなく、より少ない生成トークンでK3 Maxに近い品質へ到達する点にある。
Fireworksは、低・高・最大の推論設定におけるKimi K3とEmber-1を比較評価した。同社は同じ公開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の方法論は、露出と汚染に関する懸念を減らすためのオリジナルタスクを重視している。
結果が一様に有利というわけではない。Ember-1はSWE-bench Verifiedで92.2%を記録したのに対し、K3 Maxは93.2%だった。SWE-InteractでもEmber-1は20.0%で、K3 Maxの21.3%を下回った。
これらの差はパーセンテージポイントでは小さいが、重要である。「同等の品質」という表現が、すべてのテストで同一の能力を意味するのではなく、集計的な判断を表していることを示すためだ。
Ember-1はτ-2 Benchの航空会社部門で66%に達し、K3の3つすべての努力設定の64%を上回った。この結果は、Fireworksが公開比較で用いた最小サンプル数である50サンプルに基づく。
7つのベンチマークと2つの顧客ワークロードにおいて、Fireworksは全体的な精度を犠牲にせずK3の推論を35%から50%短縮したとしている。同社はEmber-1を、品質対コストのパレートフロンティア上、あるいはその近傍に位置づけている。
パレートフロンティアとは、一方の次元を改善するには別の次元を犠牲にしなければならない選択肢を表す。ここでは、品質がより高く、タスクコストもより低い代替案が存在しない場合、そのモデルはフロンティア近くに位置する。
この枠組みは、単一のリーダーボード順位より有用だ。企業ユーザーが重視するのは、モデル名に付随する最高得点だけでなく、許容可能なタスクを完了するためのコストだからだ。
ただし、パレートに関する主張は、選定されたタスク、エージェントの足場、プロンプト、再試行ポリシー、コスト仮定に大きく依存する。これらの入力のいずれかを変えれば、モデルの位置も変わりうる。
Fireworksは、10カテゴリーにまたがる500件の臨床ケースからなる、医師検証済みのBedside BenchでもEmber-1を評価した。同社は、Specialized Intelligence Indexに含まれるモデル全体で、Ember-1がタスク当たりコストの新たなフロンティアを確立したとしている。
この結果は、モデルの用途をコーディング以外にも広げるものだ。ただし、医療ベンチマークは、そのモデルが臨床導入、診断、あるいは監督なしの医療判断に適していることを示すものではない。
このテストは、構造化された専門的推論に関する証拠として理解するのが適切だ。これは、一般的な学術テストだけでなく、実際のタスクカテゴリー全体で特化モデルを評価すべきだというFireworksの考え方を示している。
本番環境の購入者は、パーセンテージポイントの差と運用上の信頼性も区別すべきだ。小さな平均改善の裏に、特定の企業にとって最も重要なタスクでの後退が隠れている可能性がある。
したがって、適切な比較はワークロード固有のものとなる。チームは、固定されたエージェントの足場、同一のツール権限、一貫した成功基準のもとで、代表的なタスクを再実行すべきである。
トークン総数、完了タスク数、再試行回数、完了までの時間、失敗の重大度をまとめて測定すべきです。システムが実用的な成果に到達できる場合に限り、トークン削減には価値があります。
このような評価の規律は、検索可能なナレッジベースも支えます。急速に変化するモデルエンドポイントを比較する際、チームはプロンプト、評価メモ、失敗事例を保持しておく必要があります。
Ember-1は、手間の少ない近道に対する説得力ある反論を提示しています。ただし、あるベンダーのポストトレーニング手法が、あらゆるエージェント、リポジトリ、専門領域に一般化できることまでは、まだ示されていません。
本番テストが主張をより具体的にする
顧客とのA/BテストはEmber-1にとって最も実践的な証拠を提供していますが、Fireworksは顧客を特定しておらず、評価データも公開していません。
Fireworksによると、実稼働中のコーディングワークロードを用い、2社の顧客とEmber-1をテストしました。報告によれば、両社とも同等の品質を維持しつつ、タスクあたりの生成トークン数を約35%削減しました。
同社は、ある比較についてより詳細な数値を公開しています。Kimi K3群のスコアは0.751、Ember-1群は0.753でした。
平均ステップ数は23.8から21.4へ低下しました。出力トークン数は、タスクあたり49,300から29,900に減少しました。
Fireworksは、推論トークンが71.3%減少し、総トークン数が39%減少したと報告しています。また、完了、成功、失敗の指標は概ね維持または改善したとしています。
参加顧客の1社は、Ember-1を本番環境に導入し、ベースモデルの代替として拡大する計画だと報じられています。顧客の身元、サンプル数、ワークロード構成、評価基準は明らかにされていません。
こうした情報の欠落により、統計的有意性を独立して評価することはできません。0.751から0.753への変化は、同等の性能、ランダムなばらつき、あるいは小幅な改善を示している可能性があります。
トークン数の変化は、その規模がはるかに大きいため、簡単には無視できません。それでも読者は、平均値がタスクの長さ、失敗した実行、キャッシュの挙動、あるいは変更された停止条件の影響を受けていないかを知る必要があります。
平均ステップ数は一つの手がかりになります。Ember-1はより少ないステップで処理しており、削減の一部は各ステップ内の推論短縮だけでなく、軌跡自体が短くなったことによる可能性を示しています。
モデルが不要なツール呼び出しを避けるなら、これは有益です。一方で、成功指標が未完了の作業を捉えられない場合、早期終了を隠してしまう可能性もあります。
Fireworksによると、失敗したEmber-1の試行でもトークン消費は抑制されます。この特性により、エージェントが解決できないタスクへの支出を抑えられる可能性があります。
しかし、安価な失敗が自動的に有用な失敗になるわけではありません。短い試行によって未完了の作業が気付かれないまま下流へ渡されないよう、開発者には明確なエラー状態、トレースの可視性、エスカレーションのルールが必要です。
社内テストも別のシグナルを加えています。Fireworksは、顧客に公開する前に、自社のコーディングおよびcoworkトラフィックの一部をEmber-1経由にしました。
同社によれば、トークン消費が減少する中でも、開発者は切り替えに気付きませんでした。効率化モデルは理想的には何事もなかったかのように感じられるべきであり、これは意味のある使いやすさの観察です。
ただし、これは逸話的な証拠にとどまります。Fireworksは、開発者数、社内テストの期間、タスク構成、統制された満足度指標を公開していません。
それでも本番環境という枠組みは、Ember-1を公開リーダーボード向けにのみ最適化されたモデルと区別します。実運用のエージェントワークロードには、複雑なリポジトリ、変化する要件、失敗するツール、繰り返しのやり取りが含まれます。
まさにこうした場面で、推論の肥大化は高コストになります。同時に、クリーンなベンチマークでは不要な確認をモデルが省略すれば、圧縮された推論は隠れたリスクを生む可能性があります。
最も妥当な結論は、Fireworksのマーケティング文句より限定的です。Ember-1は、測定されたタスク品質を概ね維持しながら、同社の評価において大幅なトークン削減を実現しました。
この結果は、大規模にコーディングエージェントを運用するチームにとって注目に値します。ただし、本番システムを切り替える前にワークロード単位でテストする必要性がなくなるわけではありません。
非公開の重みが独立検証を制限する
Ember-1はオープンウェイトの基盤モデルを継承していますが、API限定での提供により、外部の研究者はモデルを再現したり、主張されるトレーニング手法を監査したりできません。
FireworksはEmber-1を自社モデルであり、専門特化型リリースの計画シリーズにおける第1弾だと位置付けています。しかし同社は、Ember-1の重み、トレーニングコード、正確なアルゴリズムを公開していません。
これは、より広いオープンモデルの物語との間に緊張関係を生みます。Kimi K3は研究者やインフラチームにより多くの制御を与える一方、Ember-1はこの特化型派生モデルをホステッドサービスへと変えています。
開発者はエンドポイントの挙動を比較できますが、チェックポイントを調査することはできません。また、報告された改善が異なる推論インフラやデコーディング実装でも維持されるかを確認することもできません。
プレビュー形式は、別の不確実性を加えます。Fireworksによれば、研究モデルには限定的なサーバーレスアクセスが提供され、コミュニティの需要に応じて恒久化される可能性があります。
一時的なエンドポイントは、安定したモデル識別子、再現可能な評価、長い調達サイクルを必要とするチームにとって導入を難しくします。テストの成功は、同じ条件での継続的な利用可能性を保証しません。
ベンチマークの証拠も慎重に解釈する必要があります。Fireworksは評価を実行し、比較設定を選定しました。
同社のTerminal-BenchおよびDeepSWEの結果は強力に見えますが、独立したリーダーボードへの提出の方が重みを持つでしょう。外部グループによる繰り返しテストは、ばらつき、スキャフォールドへの感度、ワークロード固有の性能低下を明らかにする可能性があります。
SWE-bench Verifiedには追加の問題があります。2026年2月、OpenAIは、このベンチマークへの露出が最先端のコーディング進歩を測定する能力を弱めているとして、結果の報告を停止したと述べました。
ベンチマーク汚染に関する警告は、現在のコーディング能力に関する主張には新しい評価を推奨しています。Fireworksの92.2%という結果は記述的な情報としては残りますが、主張全体の根拠にすべきではありません。
DeepSWEとTerminal-Benchは、証拠の多様化に役立ちます。それでも、プライベートコード、組織固有のツール、ビジネス上の結果を伴う本番エージェントを完全に再現できるベンチマークはありません。
本番A/Bテストはこの隔たりに部分的に対処していますが、匿名性により精査は制限されます。Fireworksは、タスク単位の結果、信頼区間、顧客自身による報告を提供していません。
「トークン数を40%削減」という表現には、意味上の問題もあります。Fireworksは、この削減を推論トークンとして説明することもあれば、出力トークンまたは総トークン数について述べることもあります。
詳細な本番例では、推論トークンを71.3%削減、総トークン数を39%削減し、出力を49,300から29,900へ削減したと報告されています。これらの指標は重なり合いますが、同一ではありません。
購入者は、自身のワークロードにどの指標が当てはまるのかを確認すべきです。モデルは隠れた推論を大幅に削減する一方で、可視の出力を変えないこともあります。また、より短い最終応答によって総出力を減らすこともあります。
評価の前に品質も定義しなければなりません。厳密なタスク完了、人間の選好、テストの合格、ビジネス上の成功は、同じ実行結果から異なる結論を導く可能性があります。
セキュリティに敏感なチームは、短い推論がツールの判断を変えるかを検討すべきです。少ないツールを呼び出すエージェントはトークンを節約できる一方で、検証の回数を減らしたり、防御的なチェックを回避したりする可能性があります。
こうした懸念はいずれもFireworksの結果を無効にするものではありません。これらは、有望なベンダーの証拠を再現可能な業界の知見へ進めるために必要な作業を定義するものです。
独立したエンドポイントテストは現在でも可能です。Fireworksが特化型の重み、トレーニング手法、あるいは別のグループがプロセスを再現できるだけの実験詳細を公開しない限り、完全な科学的再現は不可能なままです。
Ember-1が定着するかを決める三つのシグナル
次の段階は、独立したテスト、恒久的な提供、そしてトークン削減がFireworksの好むワークロード以外でも持続するという証拠にかかっています。
第1のシグナルは、Terminal-Bench 2.1とDeepSWE 1.1における独立した再現です。評価者は文書化されたスキャフォールドを使用し、完全な構成を公開し、繰り返し実行における変動を報告すべきです。
Fireworksのスコアに近い結果は、効率性の主張を強めるでしょう。大幅な性能低下や不安定なトークン削減が見られれば、Ember-1が同社の評価設定に大きく依存していることを示唆します。
第2のシグナルは、Fireworksによる提供可否の決定です。恒久的なEmber-1エンドポイントは、実際の導入を支えるのに十分な需要と運用上の確信を示すことになります。
プレビューが終了しても、技術的なアイデアが失敗したことの証明にはなりません。しかし、製品としてのEmber-1の重要性は制限され、注目はFireworksのトレーニングプラットフォームへ向かうことになります。
第3のシグナルは、より広範な本番証拠です。実名の顧客、より大きなタスクサンプル、第三者のケーススタディでは、総トークン数やレイテンシーと併せて完了率を報告すべきです。
異なるリポジトリ、言語、エージェントフレームワークにわたる証拠は、訓練された効率性が一般化するというFireworksの主張を支えるでしょう。削減効果が一つのコーディングワークフローに集中するなら、モデルの価値は限定されます。
競合他社の動きも補足的な文脈を提供します。MoonshotはK3のネイティブな効率性を改善でき、他の推論プロバイダーはオープンモデルを短い推論向けにポストトレーニングできます。
この傾向が広がれば、Ember-1はより大きな変化の初期例として重要になります。モデルの購入者は、知能スコアやコンテキストウィンドウのサイズだけでなく、トークンあたりの有用な作業量を比較するようになるでしょう。
このアプローチは、チームがエージェントを評価する方法も変えます。長いトレースを、システムがより深い、あるいはより良い推論を行った証拠と見なすべきではなくなります。
冗長な分析は、生産的な検証、繰り返される不確実性、あるいは単純な非効率性を反映している可能性があります。それらを区別できるのは、タスクの結果と統制されたテストだけです。
Fireworks AI Ember-1は、この問題に対する焦点の合った、もっともらしい対応を示しています。同社は意味のあるベンチマークおよび本番の証拠を提示する一方、完全な検証を妨げるほど多くの詳細を非公開にしています。
開発者は、自身のタスク分布でK3 MaxおよびK3 Lowとモデルを比較すべきです。すべての比較群で、同じプロンプト、ツール、停止ルール、スコアリングシステムを維持する必要があります。
失敗もトークン総数と同じくらい慎重に追跡してください。Ember-1が検証を省略していないか、困難なタスクを早期に終了していないか、あるいはミスの重大度を変えていないかを確認してください。
最後の問いは実践的です。Fireworks AI Ember-1は、リスクを見えにくい場所へ移すことなく、より少ないトークンで実際の仕事を完了できるでしょうか。プレビューが終わる前に比較を実行し、後から繰り返せるだけの証拠を保持してください。
