Kimi K3はFableと競合し、両モデルの組み合わせは最高水準の性能を達成

 (fireworks.ai)
1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • 約1,030件のエージェントタスクで Kimi K3 と Fable 5 を比較した結果、タスクごとのルーティングは93%の精度で単一モデルを上回る品質を達成
  • SWE・ターミナル・アルゴリズム・多言語・法務タスクで全体性能は近かったが、両モデルが強みを示すタスク領域は異なっていた
  • オラクルルーティングではタスクの72〜96%を K3 に割り当て、K3 は5つのタスク群すべてで Fable よりコスト効率が高かった
  • 長いエージェントループでは K3 は Fable 単独利用より最大約50倍高いコスト効率を示したが、実行ステップが多いため処理時間は長くなりうる
  • 安価なオープンモデルを基本にし、高難度タスクを別モデルへ送るワークロード特化ルーターは、品質とコストの両方を改善できる可能性がある

実際のエージェントタスクで測定

  • Kimi K3 と Fable 5 を同一のハーネスで実行し、実際のエージェントループ形式の約1,030件のタスクを処理
    • SWE: 実リポジトリのバグ修正に近いタスク 460件
    • ターミナル: セキュリティ・暗号・リバースエンジニアリング・システム管理などの長期エージェントタスク 89件
    • アルゴリズム: LeetCode・AtCoder 系の問題 100件
    • 多言語: 6言語の実装タスク 225件
    • 法務: 弁護士が採点する法務エージェントタスク 120件
  • 複数のタスク種別を対象にしたベンチマーク結果を平均して両モデルを比較

オラクルルーティングの意味と限界

  • オラクルルーティングは、各タスクをすべてのモデルで実行したうえで、正解した選択肢の中から最も安価なモデルを選ぶ理論的な測定方式
  • 実際のルーターはタスクを複数モデルで事前実行できないため、コストと品質のバランスが最も良いモデルを事前に予測する必要がある
  • この方式では、全タスクの72〜96%で K3 が選択された
  • 日常的なタスクと最上位モデルが必要なロングテールのタスクを見分けるルーターは実現可能かもしれない
    • これを確定するには、一桁規模ではなく10倍規模の追加ルーティングデータと実環境での性能検証が必要

総合性能は近いが強みは異なる

  • 代表的な SWE の結果は K3 92.4%、Fable 92.6% でほぼ同等
  • 5つのタスク種別全体でも両モデルの差は概ね数パーセントポイント以内で、Fable は多言語コーディング領域でやや優位だった
  • 総合スコアは近い一方、詳細なタスクでは各モデルが明確に優勢な領域を示した

タスク領域ごとの差

  • SWE を問題領域別に分けると、K3 は記号数学と開発ツール、Fable は Web とデータ可視化タスクで優位だった
  • 多言語タスクでは Fable が Java・Python・C++ で先行し、K3 は JavaScript・Rust で互角だった
  • 数十回にわたってシェルを操作する長期ターミナルタスクでは K3 が強みを示した
    • Fable が解けなかった 7z ハッシュ、FEAL の暗号解析、流出した秘密情報、実際の脆弱性、制御不能な非同期タスクを解決
  • 精度とコストを合わせて比較すると、Fable は多言語、K3 はターミナルと法務で優位で、残りは概ね近かった

コスト差を生む構造

  • K3 のコスト優位はトークン価格・プロンプトキャッシュ・タスクごとの投入量から生じる
  • SWE タスク1件あたり、K3 は約55ターンと130万トークンを使ったのに対し、Fable は約21ターンと13万トークンを使用
  • 長いターミナルタスクでは逆に Fable が約64ターンと150万トークンまで使い、ときにはタイムアウトに達した
  • K3 は SWE で10倍多くのトークンを読んでも、プロンプトキャッシュのヒットにより実行コストは Fable より低かった
  • 実行ステップが増えると実際の処理時間は長くなりうる
    • 2秒以内に答える必要があるタスクではレイテンシが重要
    • 大規模なバックグラウンドエージェントでは、より低い課金額が重要になる

2つのモデルを組み合わせた結果

  • タスクごとにより適したモデルへ送ることで、両モデルの中間ではなく各単一モデルを上回る性能を得られる
  • タスク別のオラクルルーティングは単一モデル実行より常に高い性能を示し、全体精度は**93%**に達した
  • トラフィックの72〜96%をコスト最適化モデルである K3 に送っても、全体品質は各モデルを上回り、コストは K3 単独利用に近づいた
  • K3 は5つのタスク群すべてで Fable よりコスト効率が高く、長いエージェントループでは最大約50倍高いコスト効率を記録した

単一モデルよりワークロード別ルーティング

  • Kimi K3 と Fable を組み合わせてルーティングすれば、異なる強みを活かしながらコストを下げられる
  • モデルごとに価格と得意領域が異なるため、最高品質の AI は単一プロバイダーより複数モデルの組み合わせから生まれる可能性がある
  • コストが最大50倍低く、オラクルが大半のトラフィックを割り当てた K3 のようなオープンモデルを基本選択肢にできる
  • ルーターは実際のワークロードに合わせる必要があり、タスクとモデルの適合関係を継続的に学習しなければならない

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Hacker Newsの意見

  • 実際に動かして試してみると、これらのモデルはどれもベンチマークに過剰適合している。ある指標で最前線モデルに迫っていても、実務では崩れ、トークン効率もばかげて低い
    Fireworksはクローズドモデルと違ってK3のホスティングで大きな利益を得るため、こうした見出しを打ち出す動機が非常に大きい

    • 数日かけてK3、Qwen 3.8 Max Preview、Fable、Solを試した結果、ベンチマークは信用しにくく、中国モデルは遅く、トークン効率も低いという点には一部同意する
      それでも前世代の最上位モデルであるOpus 4.8・GPT 5.5とだいたい同程度で、https://senko.net/vibecode-bench/でも比較できる
      公式APIと各コーディングツールを使い、詳細な仕様だけでシンプルだが簡単ではないWebアプリを作らせたところ、K3・Qwen 3.8・Fableの結果はユーザーテストでほぼ同じで、Solのコードレビューでも全て合格し、Fableがわずかに先行した
      実務では依然としてOpus 4.8とSolを好むが、代替が必要ならK3とQwen 3.8も十分実用になる
    • どれもベンチマークに過剰適合しているが、重要なのは互いに比べてどれだけ過剰適合しているかだ
      正解セットがなく、エージェント同士が相互作用するオープンなマルチエージェント環境で主にコーディング能力を評価しているが、中国モデルは宣伝されているモデルカードよりも米国モデル比で低めに出る傾向がある
      Kimi K3は例外的に本当に最前線に近いが、非常に遅い。Muse Spark 1.1はFableとSolに次ぐ強さで、かつコスト効率が最も高く、Llama 4以降で大きく巻き返した。データはhttps://gertlabs.com/rankingsにある
    • Fableはかなり大きなコードベースでも非常によく動く。何度か修正したり方向づけしたりする必要はあったが、ほとんどはプロンプトの要件が不十分だったためで、本当に間違っていたのは2回ほどしかなく、自分の職業人生よりもエラー率が低い
      コード品質は自分が書く水準と同じで、慣れていない領域ではそれ以上だ。リファクタリングや統合・回帰テスト、監査ログやエラー通知の点検のような、人間が先延ばしにしたり退屈に感じたりする作業も着実にこなし、ソフトウェアエンジニアリング全体の水準を引き上げている
      PostgreSQLを使う比較的複雑なRuby on Railsの本番サービスで、月額200ドルのMaxプランではトークン予算は問題にならず、コストにも十分見合う
    • 記事は読んでいないが、推論サービス事業者が自社提供のMythos級モデルを前面に出す見出しの時点で怪しかった。Kimi K3よりパラメータが3分の1にも満たないGLM 5.2が依然として主力モデルだ
    • この評価にはすべて現時点ではという留保が必要だ。流れを見る限り、まだコーディングに十分な水準でなくても、まもなく到達するのは明らかで、公開モデルがほぼあらゆるソフトウェア作業を担う世界に備える必要がある

  • 約1,000件のタスクをソフトウェア工学・法律など5分野に分けてKimi K3とFableを試した点が興味深い
    正答を出すのにどのモデルがより安く済むかを予測するルーターモデルを前段に置き、最終的には各自のワークロードで継続学習させるべきだと見ている
    ルーターは分野別に72〜96%のタスクでKimiを選び、分野に応じて1.5〜50倍のコスト削減を達成した

    • ここでのルーターは、両モデルを実行して通過可否を確認したうえで、より安いモデルを選ぶオラクル基準点だ
      同じ結果を事前に予測するルーターが存在するならコストを削減できる、というFireworksの仮定にすぎず、その存在自体が大きな前提になっている
    • 同様のルーターはhttps://openrouter.ai/openrouter/autoなど複数ある

  • 人のように会話するモデルなら、ベンチマークスコアが5%下がることも受け入れられる

    • むしろ人間っぽく話そうとしないモデルのほうが好みだ
    • 5%を捨てる必要はなく、Fableの出力をGemini Flashに入れて、より読みやすい文章に書き直させればよい
    • モデルには自分の人間的な話し方を真似してほしくないと強く思う。Claudeが友人のように振る舞い、冗談に LOL と返すのは滑稽なだけでなく有害ですらある
    • Opusはデフォルトで、私がClaude語と呼ぶ文体を出力する。過度に単純化され、文法的にも不完全な文で、読むのがつらい。モデルにとっては読み書きしやすいのかもしれないが、人間にとってはそうではない
      例えば長い論文の案内を、「今ざっと目を通し、Part IIを読みながら再参照せよ」といった命令形の断片と太字キーワード、矢印を密集させて1行で出力していた
    • LLMは人間ではないのだから、わざわざ人のように話す理由はない

  • Anthropicはローマ帝国の早回しのようで、IPOする前にすでに頂点を過ぎ、衰退局面に入ったように見える

  • Kimi K3のコーディングプランを契約する際に、データガバナンスとプライバシー保護がどう適用されるのか気になる。Anthropicから移行したい

    • https://platform.kimi.ai/docs/agreement/modeluse によれば、コンテンツはサービスの提供・維持・開発・改善などに利用でき、学習制限が必要な顧客は別途エンタープライズ契約または書面合意を協議する必要がある。
      Claudeと違ってモデル学習へのオプトアウトがなく、規約上Kimiは顧客コードを学習に使える
    • 西側のプロバイダーがホスティングを始めるまで待つしかない
    • いちばん簡単な方法はOpenRouterに登録して、データ保持なし（ZDR） ではないプロバイダーをすべて除外すること。ただしAPI料金はコーディングプランより高くなる可能性があり、MiniMaxの月額20ドルプランで提供される17億トークンは、入出力・キャッシュ比率によってはAPI基準で200〜500ドル超の価値がある。
      中国企業と直接やり取りしたくないなら、AtlasCodeの月額20ドル、OpenCode Goの月額10ドル、Cline Passの月額10ドルで、一部の人気公開ウェイトモデルに対して2〜6倍の使用量が得られる。
      個人的にはZ.aiを月額17ドルで契約し、MiMo v2.5、Hy3、Qwen 3.7 Plus、DeepSeek v4はそれぞれ元の提供元にAPI料金を払っている
    • プライバシーポリシーは https://www.kimi.com/user/agreement/zh/userPrivacy で確認できる

  • 公開モデルを持ち上げるために報酬を受けてこういう記事を書けるのか、もしそうなら目的は何なのか気になる。
    現代的なSaaS製品でFastAPI・PythonとSpring Boot・Javaの作業をしてきたが、うまく動いて効率的な公開モデルはQwen 3.7 Maxだけだった。
    GLM 5.2とKimiは、コードを書く前にほぼ7万〜8万トークン分コードベースを探索した末に、結局コードを壊してしまうことが多い。1年前のように非常に詳細な仕様を与えればうまくやるが、Qwen 3.7は特に手間をかけなくても仕事を終える

    • 優れたコンテンツマーケティングだ。FireworksはKimi K3へのアクセス権を販売する大手モデル推論プロバイダーだ
    • Fireworksは公開モデルの高速実行に特化しており、収益の大半を中国モデルから得ているので、経済的インセンティブはそのまま事業モデル全体でもある
    • テック分野のインフルエンス事業には金が多く流れるが、その大半はOpenAIのtbpn買収や、一部インフルエンサー向け早期アクセスのように大手企業から出ている
    • Lin QiaoはFireworks AIの共同創業者兼CEOだ。LLMは米中冷戦における宇宙開発競争に相当するので、金銭よりも民族・文明的優越性を証明したいというインセンティブのほうが強いかもしれない

  • ここでKimiだけが特別に優れている点があるのか気になる。価格はSonnet 5とほぼ同じだと思うが、Sonnet 5とFableを使う、あるいはもっと安いGrok 4.5を使うのではどうなのか疑問だ

    • 記事ではKimiが一部タスクでFableより優れているとしているが、Sonnetには当てはまらない可能性が高い
    • 公開モデルには、大企業が自社データセンターでローカル実行とファインチューニングを行える利点がある

  • 中国モデルがとても好きでDeepSeekだけを使っていたが、今ではKimi K3も高度なコーディング作業の優秀な計画支援役として活用している。
    DeepSeek v4 Flashは非常に高速で、Rust、PostgreSQL、Angular、Terraformで任せたほぼすべての作業をこなす。
    BifrostをLLMゲートウェイとしてセルフホストしているが、各社には前払いチャージや自動リチャージではなく、VPSのように月次・日次の実使用量を自動請求してほしい。返金されない最低残高を複数社に維持するより、正確な使用量だけ払いたい。
    OpenRouterは助けになるが、サービス自体と追加料金は気に入らない

    • 最近はDeepSeek v4 Proを主力で使っていて、同時進行の作業が多いので速度の重要性は低い。失敗したら会話の途中でGPT 5.5に切り替えて問題を見つけさせ、その分析を文脈に残したまま再びDeepSeekへ戻す。
      Kimi k2.5/6はさらに遅く性能も落ち、engine overloaded エラーも増えたし、k3は長く考えるわりに結果が目に見えて良くならない。計算資源の圧迫で一時的にモデルを量子化した可能性があると思う。
      最近は主にDeepSeek v4 Proを使い、強力なモデルが必要なときはGPT 5.5を使う。GLM 5.2は一部の作業には良かったが別の作業では非常に悪く、GoogleやAnthropicのモデルはまだ印象的ではなかった
    • reasonixやwhaleのようなツールを使うと、キャッシュヒット率約98% を達成でき、リクエストコストは実質無料に近くなる。CloudflareやDigitalOceanのような補助金なしの米国プロバイダーでも可能だ
    • 前払い制は、ユーザーが推論資源を大量消費したあとカードを止めて消えるのを防いでくれる。VPSは長期投資なので乗り換えが難しく、一部ユーザーが1か月分を踏み倒してもプロバイダー側のコストは相対的に小さい
    • Bifrostを検討中なので、なぜLLMゲートウェイを選んだのか気になる。
      OpenRouterはほぼすべてのモデルを公開初日から提供するが、Bifrostを使えば後でOpenRouterを離れても他の技術構成に手を入れる必要がない点が魅力的だ。セルフホストが現実的になれば、OpenAI・Anthropic・OpenRouterへの依存を減らせるし、依存していたモデルが突然廃止されるリスクも下げられる
    • 追加料金以外で、OpenRouterのサービスのどんな点が気に入らないのか気になる

  • 公開モデルをホストする会社が、公開モデルは素晴らしいと言っている状況だ

    • 方法論と結果は公開されており、他では見たことのないKimiとFableの相対的な長所と短所が分かった。モデルホスティング事業をしているからといって、結果を共有する資格まで失うわけではない
    • Fireworksは公開ウェイトモデルだけをホストしているわけではなく、大きな話題が新規顧客の獲得につながるとしても、それで内容が虚偽になるわけではない
    • 実際に使ったことがある人なら、彼らの評価が事実だと分かる

  • 記事で説明されているように、Claude Code と一緒に使えるルーティングツールや、ほかに良いルーティングプラットフォームを探している。この記事のルーターがオラクル方式であることは理解している

    • https://github.com/code-yeongyu/oh-my-openagent は、元記事のオラクルパターンを11の役割にわたって実装している
      各役割ごとに複数プロバイダーの推奨 LLM ランキングがあり、たとえば Sisyphus (claude-opus-4-8 / kimi-k3 / glm-5) をメインのオーケストレーターとして使っている