Kimi K3是开源模型,Fable 5是闭源模型。Fireworks把两者扔进约1030个真实智能体任务里对练,涵盖修bug、跑终端、写算法、多语言编程和法律陪练五类活儿。
跑完之后,Fireworks给出的结论标题很抓眼:两个模型打平,但按任务路由能把综合准确率做到93%,长链路任务成本最高能差50倍。这套约1030个任务的测试集,是Fireworks自己搭建、自己评测、自己发布的,不是行业公认的标准基准,这一点需要先说清楚。
真正该细看的是93%和50倍这两个数字的来路。它们不是两个模型直接对战跑出来的成绩,而是Fireworks先把每个任务同时喂给两边、事后挑出又对又便宜的那个算出来的——这是理论上限,不是今天任何团队能直接买到的路由器。
打平的两个模型,分工却不同
总分上两边几乎分不出胜负:SWE基准里K3拿到92.4%,Fable是92.6%,差距不到一个百分点。拆开子类看,风向完全不同。
K3更擅长符号数学和开发工具类任务。终端安全、密码学这类要跑几十轮的长链路活儿上,K3拿下的独有胜场比Fable多出一倍。Fable则在网页/数据可视化和多语言覆盖(尤其是Java、Python、C++)上占优。
| 对比项 | Kimi K3 | Fable 5 |
|---|---|---|
| SWE综合准确率 | 92.4% | 92.6% |
| 强项任务 | 符号数学、开发工具 | 网页/数据可视化、多语言 |
| 终端安全/密码学长链路 | 独有胜场多一倍 | 常态超时 |
| SWE任务耗轮/token | 约55轮 / 130万token | 约21轮 / 13万token |
| 终端长任务耗轮/token | 轮次更少,更省 | 约64轮 / 150万token |
93%和50倍,是什么又不是什么
这套93%的算法叫oracle routing:先把每个任务同时喂给K3和Fable,事后挑出又对又便宜的那个,再统计整体表现。现实里的路由器做不到这件事,它必须在任务开始前就预测该派给谁,不能先跑两遍再选。
按这套理想算法,K3被选中处理了72%到96%的任务,说明大多数活儿其实用不着更贵的闭源模型。Fireworks自己也承认,想把这个上限变成能用的路由器,还差一个数量级的路由训练数据和真实业务场景的检验。
50倍的成本差同理,只出现在特定长链路任务里。它靠的是token定价、prompt caching命中率和实际轮次三样东西凑出来的,不是所有任务的普遍倍率。换一个推理平台、换一套缓存策略,这个数字大概率会变。
这对选型团队意味着什么
对正在做智能体产品的团队,这份测试给出的信息很具体:K3和Fable没有全面优劣之分,分工可以按任务类型来定。终端安全、密码学这类长链路活儿,K3值得优先跑;网页可视化和多语言编码,Fable更稳。
对负责推理成本和平台选型的技术决策者,更该谨慎对待"50倍"和"93%"这两个数字。它们来自Fireworks自己设计、自己跑、自己发布的测试,而Fireworks同时也是Kimi K3的托管平台,成本口径大概率按自家费率算。想验证,得拿自己的真实任务量和价格卡跑一遍,而不是直接照搬这份报告的倍率去做预算。
在拿到可用的路由器之前,更现实的做法是把开源模型当默认底座,把闭源模型留给测试验证过、确实处理不好的长尾任务,而不是一次性把所有流量都切到oracle routing许诺的理论上限。
接下来值得盯的,是有没有独立第三方用不同的任务集、不同的价格卡复现类似结论,以及Fireworks或其他平台会不会真的推出一版可上线的路由器,而不只是停留在报告里的oracle上限。
两个模型打平的地方,恰好是路由器该出场的地方。亚当·斯密两百多年前讲分工提高产出,放到这里依然成立:K3和Fable不是谁更强,是各自守住了不同的活儿。
开源模型正在变成默认地板价,这个判断目前站得住;但护城河从模型能力转移到路由能力,还只是一个方向性判断,不是已经验证的结论——Fireworks自己都承认还差一个数量级的数据。真正决定胜负的,不是这次基准打了多平,是谁先把路由器从理论上限训练成日常好用的东西。