メインコンテンツまでスキップ

Ember-1: Kimi K3 と同じ答えを、トークン40%減で（2026年9月）

中級

2026年9月23日、Fireworks は Ember-1 を公開した。新しいアーキテクチャでもなく、新規の事前学習でもない — Kimi K3 の「推論する癖」を再学習させたものだ。本体は同じ2.8兆パラメータ、コンテキストも同じ1M、トークン単価も同じ。ただ、考えすぎるのをやめただけである。Fireworks は精度を落とさずに推論トークンを35〜50%削減したと報告しており、公開された5つのベンチマークのうち2つでは、Ember-1 が最大 effort 設定で動く K3 を上回るスコアを、より低いコストで出している。

その4日後、これは Hacker News のトップ記事になった。興味深いのはモデルそのものではなく、その下にある主張だ — 推論モデルを最も安く動かす方法は、もはや「あまり考えるな」と指示することではない。 このページはその主張を分解し、ローンチ時の表が示唆しているのに一度も印字していない算術を見せ、自分のトラフィックで半日で検証する方法を提示する。

What you'll learn
  • エージェントを高価にする2つの要素 — トークン単価とトークン数 — を切り分ける。Ember-1 が変えるのは後者だけである
  • ローンチ時の表を正直に読む。effort が文字通り何も買っていないベンチマークと、全モデルが22%未満のベンチマークを含めて
  • ブログが印字していない1タスクあたりのコストを導出する（そしてベンチマーク1回の実行が $5〜$535 かかることを知る）
  • 推論トークン71%削減がなぜ総トークン39%削減にしかならなかったのか — そしてその比率が自分の請求額について何を語るのかを理解する
  • ほとんどの SDK ラッパーが捨てているフィールド1つで、自分のワークロードの推論トークン比率を測る
  • 移行前に細字部分を把握する: リサーチプレビューという位置づけ、未公開の重み、失われた入力モダリティ、そしてその下にある収益連動型の Kimi K3 ライセンス

1段落で言うと​

Kimi K3 は、あらゆる推論モデルと同様、生成トークンの大半を内部推論に費やす — Fireworks はときに90%以上だとしている。マルチターンのエージェントではその推論が後続の呼び出しすべてに再投入されるため、コンテキストはターン数に対しておおよそ二次関数的に膨らみ、初期の思考が実行の残り全体にわたって再課金される。Fireworks の顧客は K3 のコーディング品質をより低いコストで求めた。reasoning_effort を下げると品質を失いすぎたため、Fireworks は挙動そのものを学習させた — 50回を超える学習ランと200回以上の評価を重ね、ミスから立ち直るための自己内省は残し、それ以外を落とすようモデルに教えたのである。その結果は accounts/fireworks/models/ember-1 として、K3 とまったく同じレートで提供されている: 入力（未キャッシュ）$3 / M、入力（キャッシュ済み）$0.30 / M、出力 $15 / M。

見出しが隠している3つのこと​

1. 何も安くなっていない。モデルが買う量が減っただけだ。​

ここがモデルコストの考え方を組み替える部分である。Ember-1 の料金表は Fireworks でも OpenRouter でも Kimi K3 と完全に同一だ（入力 $3 / 出力 $15 per million、コンテキストはどちらも1,048,576トークン）。割引は存在しない。節約された1ドルはすべて、そもそも生成されなかったトークンから来ている — そしてエージェントループでは、その同じトークンが続く19ターンの入力として再投入されないことからも来る。

これには実務上の帰結がある: $/token はダッシュボードに載せる数字として間違っている。 同じ定価の2つのモデルが同じタスクで2倍違うことはあり、定価の高い方が完了タスクあたりでは安いというのはよくある話だ。AILmanac のプロバイダー横断の AI コストは同じ論点を価格側から述べている。Ember-1 はその最もきれいな自然実験であり、価格という変数が固定され、動くのはトークン数だけだからである。

2. effort を下げることは同じではない。表がそれを証明している​

K3 は reasoning_effort を low、high、max で公開している。Fireworks はこの3つを別のアームとして実行しており、それが彼らの表を他のローンチ表より有用にしている:

ベンチマークNK3 lowK3 highK3 maxEmber-1Ember-1 vs K3 max
Terminal Bench 2.18976.4%77.6%80.9%82.0%−51.9% / −23.1 USD
SWE-bench Verified50080.4%86.0%93.2%92.2%−15.5% / −68.1 USD
SWE-Interact756.7%13.3%21.3%20.0%−32.5% / −60.8 USD
DeepSWE 1.111355.8%62.8%66.4%75.2%−23.7% / −126.9 USD
τ-2 Bench Airline5064%64%64%66%−5.9% / −0.3 USD

Ember の列を読む前に、K3 の列を縦に読むこと。SWE-bench Verified では max から low に落とすと12.8ポイント失う — それが Fireworks の言う「品質を失いすぎた」であり、effort ダイヤルだけでは顧客の問題を解けなかった理由だ。Ember-1 は全行で K3 high を上回り、5行のうち2行で K3 max を上回り、5行すべてで max より低コストである。K3 low に対しては両方の軸で厳密に優れている。

特に注目すべき行が2つある:

  • τ-2 Bench Airline: 64% / 64% / 64%。 effort 3段階、スコアは1つ。このベンチマークでは K3 が生成する追加の思考トークンはすべて純粋な無駄である — low の結果に max の料金を払っていることになる。本番ワークロードが τ²-bench のような形（スクリプト化されたカスタマーサービスのポリシー、短いターン、固定 API へのツール呼び出し）なら、effort ダイヤルは品質的な意味を持たないコスト設定であり、デフォルトに任せるのではなく測っておくべきだった。より一般的な習慣 — デフォルトを信じる前に自分の評価で effort をスイープする — はEffort チューニングと推論モデル比較にある。
  • SWE-Interact: 誰も22%を超えない。 SWE-bench Verified で92〜93%を解決するのと同じモデルたちが、タスク中にユーザーとやり取りすることを求められると5問に1問しか解けない。SWE-bench Verified は飽和に近く、もはやフロンティアモデルについてほとんど何も語らない。実際の能力ギャップが存在するのは対話版の方だ。ローンチ記事が90台の SWE-bench の数字を前面に出しているときは、常にこの2つを念頭に置くこと。これは能力と信頼性のギャップが1つの表の2つの列として現れたものである。

3.「−51.9% / −23.1 USD」の列は、ベンチマーク1回の実行コストを教えてくれる​

Fireworks はこの最後の列の2つの数値にラベルを付けていない。相対的なコスト削減率と*実行全体での節約額（絶対ドル）*として読むと、両者は内部的に整合している — そして一方を他方で割ると、誰も公表していない数字が復元できる: これらのベンチマークを1回走らせるとどれだけかかるのか。

以下の算術は Fireworks のものではなく私たちのものである — 公表された2つの数値からの推論なので、引用ではなくオーダー感として扱ってほしい:

ベンチマークN推定される K3-max の実行コスト推定される1タスクあたりコスト
Terminal Bench 2.189約 $44約 $0.50
SWE-bench Verified500約 $439約 $0.88
SWE-Interact75約 $187約 $2.49
DeepSWE 1.1113約 $535約 $4.74
τ-2 Bench Airline50約 $5約 $0.10

K3 を最大 effort で走らせた DeepSWE 1.1 のスイープ1回は、113タスクでおよそ500ドルに達する。これが「全モデルで自分の評価を走らせればいい」という助言に人がうなずきながら実行しない本当の理由であり、ステークホルダーに5モデルの比較検証を約束する前に知っておく価値がある。そしてこれは24%の節約が意味を持つ理由の数字でもある: 毎晩繰り返せば、そのベンチマーク1つで年間46,000ドルの費目になる。

推論71%削減が、請求額39%削減にしかならなかった理由​

Fireworks の社内検証では、同じトラフィックで推論トークン71.3%削減、総トークン39%削減と報告されている。この2つの数字の差が発表の中で最も有用な部分であり、これから提示されるあらゆる効率化の主張に一般化できる。

推論トークンは生成トークンの一部である。請求額の残りは、効率化のための追加学習では手を付けられないもので構成されている:

  • システムプロンプトとツール定義 — 毎ターン再送される（エージェントでは単一のブロックとして最大になることが多い）。
  • ツールの結果 — ファイル内容、検索結果、HTTP レスポンス — これらは外の世界から、それぞれのサイズで届く。
  • 最終的な回答 — 本来欲しかったもの。
  • 過去のターン — 入力として再投入される。

したがって「思考トークンを減らす」系の節約の上限は、ベンダーのものではなくあなたの推論トークン比率である。ターンの80%がツール出力であるエージェントは宣伝された効果の一部しか得られない。プロンプトが短く熟考が長いチャット系ワークロードはほぼ全部を得る。何かを移行する前に、この比率を測ること — 次のセクションでその方法を示す。上記リストの残り3行についてはエージェントがトークンを燃やす理由が扱っている。

Watch out
  • ベンダーのトークン削減率はベンダーのトラフィック構成で測られている。あなたの節約幅は自分の推論トークン比率で上限が決まる — 何かを見積もる前にそれを測ること。

自分のトラフィックで半日で測る​

Fireworks はモデルの思考を（本来 think タグの内側に入る内容を）content ではなく reasoning_content フィールドで返す。多くの OpenAI 互換ラッパーは未知のフィールドを捨てるため、チームは「出力のうち思考は何割か」に答えられなくなる — さらに悪いことに、マルチターンの品質を静かに壊すことになる。

Guided walkthrough1 of 5
  1. 実トラフィック1日分について、すべてのアシスタントメッセージで reasoning_content の長さを content の長さと並べて記録する。その比率があなたの推論トークン比率であり、誰が売り込んでくる効率化であってもその節約幅の上限になる。

OpenAI 互換エンドポイントで Ember-1 を1回呼ぶ

curl https://api.fireworks.ai/inference/v1/chat/completions \
-H "Authorization: Bearer $FIREWORKS_API_KEY" \
-H "Content-Type: application/json" \
-d '{
  "model": "accounts/fireworks/models/ember-1",
  "max_tokens": 8192,
  "messages": [
    {"role": "system", "content": "You are a senior engineer. Reply with a unified diff and one paragraph of rationale."},
    {"role": "user", "content": "The test suite in ./tests fails on macOS only. Log and module attached: ..."}
  ]
}' | jq '{
  reasoning_chars: (.choices[0].message.reasoning_content // "" | length),
  answer_chars: (.choices[0].message.content // "" | length),
  usage: .usage
}'

本当に欲しい A/B: 同じタスク、3本のアーム、1つの表

# Arm 1 — the incumbent at full effort
MODEL="accounts/fireworks/models/kimi-k3" EFFORT="max"  ./run-evals.sh > k3-max.jsonl

# Arm 2 — the cheap way people try first
MODEL="accounts/fireworks/models/kimi-k3" EFFORT="low"  ./run-evals.sh > k3-low.jsonl

# Arm 3 — the efficiency post-train (no effort setting to choose)
MODEL="accounts/fireworks/models/ember-1"               ./run-evals.sh > ember.jsonl

# Then the only comparison that matters:
#   dollars spent / tasks that passed the gate
jq -s 'group_by(.arm)[] | {arm: .[0].arm,
      passed: (map(select(.passed)) | length),
      usd: (map(.usd) | add),
      cost_per_pass: ((map(.usd) | add) / (map(select(.passed)) | length))}' *.jsonl

移行前に読む細字部分​

これはリサーチプレビューである。 Fireworks は新しいリサーチモデルを2週間のサーバーレスアクセス付きで出荷し、「コミュニティの要望に応じて」恒久化する。予算化されていない移行をそれに賭けてはいけない。A/B を組み、K3 をフォールバック経路として残し、切り替える前に可用性を再確認すること — まさにサーバーサイドフォールバックとモデルルーティングのパターンが存在する理由である。

重みは公開されていない。そしてそれは合法である。 Hacker News のスレッドで最も票を集めた混乱は「オープンな重みで学習して自分のは公開しない — それは許されるのか？」という趣旨のものだった。許される。Kimi K3 のライセンスは「本ソフトウェアの複製を使用、複製、改変、結合、公開、頒布、サブライセンスおよび/または販売する権利、ならびに本ソフトウェアを実行、デプロイ、ファインチューニングその他改変し、そこから派生物を作成する権利」を与えており、構築したものを公開するコピーレフト義務はない。ライセンスが付けているのは収益連動の2つの条件であり、Ember-1 に関心があるかどうかに関わらず知っておく価値がある:

  • $20M を超える Model-as-a-Service。 あなた（および関連会社）が MaaS 事業 — 第三者にモデルの推論やファインチューニングへのアクセスを、例えば API 経由で、入力・パラメータ・学習データに対する実質的な制御を伴って提供する事業 — を運営し、その合計収益が連続する任意の12か月間で2,000万ドルを超える場合、本ソフトウェアまたはその派生物の商用利用の前に Moonshot AI と別途契約を締結しなければならない。
  • 100M MAU または月間 $20M を超える場合の帰属表示。 これを基に構築された製品・サービスが月間アクティブユーザー1億人または月間収益2,000万ドルを超える場合、ユーザーインターフェースに「Kimi K3」を目立つ形で表示しなければならない。

モデルやその能力を第三者に公開しない内部利用は MaaS 条項の対象外である。実務的な読み方: オープンウェイトのライセンスは上の方は MIT 的な形でありながら、本気のビジネスが行き着く2つの状況をきちんとゲートしうる。ベンチマークより先にライセンスを読むこと — 同じ助言はあらゆる「オープンな」フロンティアリリースに当てはまり、DeepSeek、Qwen とオープンウェイトの波でも扱っている。

入力モダリティを確認すること。 OpenRouter は Kimi K3 を text+image+video、Ember-1 を text+image と記載している。Fireworks 自身のモデルページは Ember-1 の画像入力を告知しているが、動画には触れていない。パイプラインのどこかが K3に動画フレームを送っているなら、切り替える前にその経路を明示的に検証すること — 静かに消えるモダリティは品質低下よりずっと悪い障害であり、通常は評価のスコア低下ではなく本番の不正リクエストとして表面化する。

サンプリングパラメータも確認すること。 OpenRouter の Ember-1 のパラメータ一覧には seed と min_p がなく、どちらも K3 には記載されている。評価ハーネスが再現性のために seed を固定しているなら、親モデルの表面がそのまま引き継がれていると仮定せず、実際に呼び出すエンドポイントで挙動を確認すること。より広いチェックリストはモデル間でのプロンプト移植にある。

Specialized Intelligence Index の読み方​

Ember-1 のもう1つの見出し — 「GPT-5.6 Sol、GPT-6 Astra、Claude Opus 5 を含むオープン・クローズド両方のモデルにわたり、Bedside Bench で新たなパレートフロンティアを設定」 — は、Fireworks が Ember-1 の1日前、2026年9月22日に立ち上げた Specialized Intelligence Index から来ている。指標を運営する会社とモデルを出荷する会社が同じである。それが自動的に失格になるわけではないが、読み方は変わる。

SII が通常のリーダーボードより優れている点:

  • ベンチマークが学術界ではなく実務家から来ている — ヘルスケアは Doximity の BedsideBench（医師が検証した500件の臨床ケース）、法務は Harvey のリーガルエージェントベンチマーク、サポートは Sierra の τ-Banking と τ-Voice および Decagon の DuetBench、金融は Rogo、セキュリティは Novee の PWNBench と depthfirst の dfbench、そして Datacurve の DeepSWE と Proximal の FrontierSWE V2 を含むソフトウェアクラスタ。
  • スコアの隣に1タスクあたりコストと実時間を報告する — プロバイダーの料金表に基づいて。まさにこのページ全体が主張している軸である。
  • すべての結果に再現可能な主体のラベルを付ける: 誰でも、Fireworks とパートナー、あるいはパートナーのみ。そのラベル1つは今年公開されたリーダーボードのメタデータとして最も有用であり、パートナーのみの行はきれいな表を付けたベンダーの主張として扱うべきだ。
  • 合成スコアを拒んでいる。 ドメイン横断の集計も、単一の「知能」値もない — これは正しい判断であり、しかも稀である。

それでも留意すべきこと: ベンチマークの構成、選ばれたアーム、effort 設定、そして勝つモデルは、すべて同一の当事者が選んでいる。設計文書で引用する前に、売るモデルを持たない者が運営する指標の行と比較すること。一般的な規律は検証のボトルネックにある。

で、乗り換えるべきか？​

  • K3 を max effort で、量をこなすエージェント的コーディング: 今週 A/B を走らせること。Ember-1 がまさに学習対象としたワークロードであり、報告されている節約はコストの15〜52%、そして DeepSWE 1.1 は精度を犠牲にするどころか得られる可能性を示している。
  • max が高すぎて K3 を low か high で動かしている: 有力な候補。Ember-1 は公開された5行すべてで K3 high を上回り、low は完全に凌駕している。
  • τ²-bench のような形のワークロード（短いターン、スクリプト化されたポリシー、ツール出力が重い）: 節約は控えめと見込むこと — effort ダイヤルはもともと何もしていなかったし、推論トークン比率も小さい。
  • 動画入力、固定 seed、あるいは12か月保証のエンドポイントが必要なもの: 当面は K3 に留まり、プレビューが本採用になったら再評価すること。
  • そもそも Kimi K3 を使っていない: 転用できる教訓はモデルではなく計測である。自分の推論トークン比率を見つけ、自分の評価で effort ダイヤルをスイープし、$/M トークンではなく完了タスクあたりコストを報告し始めること。どのプロバイダーでも、この問いは同じ問いである。

Check yourself

0/6
  1. Ember-1 のトークン単価は Kimi K3 とまったく同じ（入力 $3 / 出力 $15 per million）である。報告されている35〜50%の節約はどこから来るのか？
  2. τ-2 Bench Airline では、Kimi K3 は low、high、max のすべてで64%だった。これは何を意味するか？
  3. Fireworks は同じトラフィックで推論トークン71.3%削減、しかし総トークンは39%削減と報告している。この差はなぜか？
  4. ローンチ表のすべてのモデルは SWE-bench Verified で80〜93%、SWE-Interact では6.7〜21.3%である。正しい結論はどれか？
  5. Fireworks は Kimi K3 のオープンな重みの上に Ember-1 を構築し、Ember-1 の重みは公開しなかった。Kimi K3 ライセンスの下でこれは許されるか？
  6. あなたのチームは、ターンの大半が大きなツール出力（ファイル内容、検索結果）で占められるエージェントを運用している。宣伝されている40%の節約のうち、どれだけを見込むべきか？
Enter キーまたはスペースキーでカードを裏返します。左右の矢印キーでカードを移動できます。用語を表示しました。
1 / 9

次に読む​

出典と参考資料​