Kimi K3 与 Fable 性能对标

Kimi K3 登陆 Fireworks：你可以拥有的前沿智能

两个模型胜过一个

在 Fireworks 上，K3 的成本最多可降低至原来的 1/50。🫳🎤

不要只选一个模型，而要做路由

K3 针对所有工作类型都做了成本优化

单一模型既浪费，也不再代表 SoTA

K3 是一个具备前沿水准的开放模型，成本却低得多。更重要的是，它能以可预测的方式与 Fable 形成互补，因此可以通过任务路由，以最高质量获得智能能力。

🧭 简而言之：我们让 Kimi K3（开放模型）与 Fable 5（闭源模型）在约 1,000 个 Agent 任务上展开了对比，结果发现：

通过在 K3 和 Fable 之间进行路由，我们实现了 93% 的准确率。

在长链路 Agent 循环中，其成本效益最高可达到单独使用 Fable 的约 50 倍；而且在所有用例中，成本都始终更低。

我们综合了多个 benchmark，每个 benchmark 分别针对一种不同类型的工作，并让 K3 和 Fable 5 使用同一套测试框架运行。总计约 1,030 个任务，全部在真实的 Agent 循环中执行。

在深入结果之前，先快速解释一个概念。Oracle routing 是一种衡量理论最优性能的方法：让每个模型都执行同一个任务，然后从正确完成任务的模型中选出成本最低的那个，从而得到成本与性能的理论上限。在实际的 router 中，你不可能让多个模型同时运行你的任务。Router 会预测哪个模型能够提供最佳的成本与质量权衡，但归根结底，这仍然是一种猜测。

在这项研究中，Oracle routing 在 72%～96% 的任务中选择了 K3。这意味着，我们或许能够通过学习日常任务与真正属于前沿工作长尾部分的任务之间的差异，实现一个接近完美的 router。不过，要得出确定结论，还需要数量级更大的路由数据，以及真实环境中的性能表现。

从宏观视角来看，很容易把两个模型的正面对比视为平局。例如，在最受关注的 SWE benchmark 中，K3 得分为 92.4%，Fable 为 92.6%。在我们测试的五种任务类型中，两个模型通常只相差几个百分点；Fable 凭借更广泛的编程语言覆盖能力，在多语言任务（Multi-lang）上略微领先。

看到这里，人们很容易就此打住，并得出“它们差不多”的结论。但真正值得关注的是：它们分别在不同的任务类型上展现出了明确更好的性能。

两个模型胜过一个

如果深入观察单个 benchmark，你会发现，除了表面的整体准确率之外，还有更多值得关注的信息。以 SWE 为例，两个模型的总体表现完全持平。但如果按问题领域拆分 SWE，就能看出各自的优势所在。K3 在符号数学和开发工具任务上最为出色；Fable 则在 Web 和数据可视化工作中胜出。同样的规律也贯穿多语言测试集：Fable 凭借语言覆盖广度，在 Java、Python 和 C++ 上占据优势，而 K3 在 JavaScript 和 Rust 上与之持平。

对于需要在终端中长时间执行的任务——操控 shell，并在数十轮交互中不断探索和处理系统——K3 展现出了真正的实力。它完成了一批 Fable 始终未能解决的任务，包括 7z hash、FEAL 密码分析、泄露的 secret、真实存在的漏洞，以及失控的 async job。

在 Fireworks 上，K3 的成本最多可降低至原来的 1/50。🫳🎤

虽然从整体来看，两者在质量上几乎打成平手，但价格却完全不在一个量级。

如此巨大的价格差距究竟来自哪里？答案是 token 定价、prompt caching，以及完成每项任务所投入的工作量。以 SWE 为例，K3 比 Fable 努力得多：每个任务大约需要 55 轮交互和 130 万个 token，而 Fable 只需要 21 轮交互和 13 万个 token。但在长链路终端任务中，情况正好相反：陷入循环的是 Fable，它会一路跑到 64 轮交互和 150 万个 token，有时甚至直接超时。

Prompt caching 在将这些额外工作量转化为 K3 的价格优势时发挥了主要作用：即使 K3 读取的 token 数量达到 Fable 的十倍，得益于缓存命中，SWE 任务的运行成本仍然低于 Fable。当然，这里存在权衡。更多的交互轮次通常意味着每次运行需要更多的实际时间，也就是运行速度更慢。如果你必须在两秒内得到答案，这一点非常重要；但如果你正在大规模运行后台 Agent，那么账单只有原来的几分之一，往往重要得多。

不要只选一个模型，而要做路由

如果把每项任务都交给最擅长处理它的模型，最终得到的效果并不是介于两个模型之间，而是同时超越两者。

按任务进行路由，始终优于任何单一模型的运行结果：

Oracle router 会在 72%～96% 的任务流量中选择 K3。采用这种方式设计 router，可以让整体质量超过单独使用任一模型，同时将成本控制在接近仅使用成本优化模型的水平。

K3 针对所有工作类型都做了成本优化

把质量和成本放在同一张图中来看。在全部五类任务中，蓝色的 K3 都位于红色 Fable 的左侧，也就是成本效益更高的一侧。准确率则互有胜负：Fable 在多语言任务上领先，K3 在终端和法律任务上领先，其余任务大致持平。

单一模型既浪费，也不再代表 SoTA

将 Kimi K3 与 Fable 结合起来进行路由，可以用最优价格释放两者各自最强的能力。

依赖单一模型提供商、疯狂堆叠 token 的时代正在走向终结。任务级数据表明，这些模型是定价差异巨大的不同领域专家。最好的 AI 不再来自某一家实验室，而是来自多个模型的组合。

这在实践中意味着：

开放模型应当成为默认选择。像 K3 这样成本低至 1/50 的开放模型应该成为你的基础方案，因为 Oracle router 本来就会把大部分流量交给它。

Router 才是你的护城河。Router 必须根据你的具体工作负载量身定制；持续学习任务与模型之间的最佳分配方式，是你保持领先的最大机会。