Kimi K3 对比 Claude Fable 5：数学、物理、编程与文本推理实测

Kimi K3 对比 Claude Fable 5：四类高难度任务实测#

kimi-k3 和 claude-fable-5 都已经出现在 Crazyrouter 的模型列表中。为了避免只看简单问答或单一 benchmark，我在同一接口、同一提示词和同一输出上限下，安排了四类更接近实际使用的任务：概率模式停止时间、碰撞与弹簧物理题、生产日志聚合代码，以及带多个条件的文本约束推理。

先给结论：

• 数学题：两者都得到正确主结论 $E[T]=715/54$，但 Fable 5 的中间状态回代出现算术错误；Kimi K3 的状态方程和独立边界公式都一致。
• 物理题：两者都正确算出最大压缩量约 0.221 m，并识别出完全非弹性碰撞损失 21.6 J。
• 编程题：第一轮两者都在 max_tokens=4000 处截断；提高到 7000 后，两者都输出完整代码，并通过同一组 8 个断言。
• 文本推理题：两者都找到唯一排班：周一 Eli、周二 Bo、周三 Ada、周四 Cici、周五 Deng。
• 速度方面，本轮 Fable 5 明显更快。第一轮四题平均延迟约 37.1 s，Kimi K3 约 108.0 s。这只是本次 API 请求的观测值，不代表固定 SLA。

测试设置#

测试日期为 2026-07-17，使用 Crazyrouter 的 OpenAI-compatible 接口：

GET  https://cn.crazyrouter.com/v1/models
POST https://cn.crazyrouter.com/v1/chat/completions
model A: kimi-k3
model B: claude-fable-5
temperature: 0.2

模型列表确认同时包含 kimi-k3 和 claude-fable-5。四道题均使用同一 system 指令，要求“只给可验证结论，控制篇幅”，不启用工具和联网。第一轮统一设置 max_tokens=4000，每个模型各请求四次，共 8 个请求；随后只针对编程题做一次 max_tokens=7000 的补充复测。

评价不只看 HTTP 200，而是同时检查：

1. 是否给出可复核的数值或逻辑结论；
2. 是否满足题目中的推导、边界和验证要求；
3. finish_reason 是否为 stop，还是因为预算达到 length；
4. 代码是否能在同一 Python 3.11 环境通过断言。

第一轮结果总表#

第一轮的 API usage 汇总为：Kimi K3 completion tokens 13,975，其中接口报告的 reasoning tokens 约 12,500；Fable 5 completion tokens 10,187，本次响应没有报告 reasoning tokens。reasoning token 只作为接口观测字段记录，本文的正确性判断只基于最终可见答案和可执行验证。

数学题：模式重叠处理决定答案#

题目是：正面概率 p=3/5、反面概率 q=2/5，不断投掷直到第一次出现 HHTH，允许模式重叠，求停止时间期望。

正确的前缀状态为：

S0 = 空前缀
S1 = H
S2 = HH
S3 = HHT
S4 = HHTH（吸收）

对应方程：

E0 = 1 + pE1 + qE0
E1 = 1 + pE2 + qE0
E2 = 1 + pE2 + qE3
E3 = 1 + qE0

解得：

E0 = 715/54 ≈ 13.2407407407

Kimi K3 给出了完整的 KMP 状态转移，并额外用模式的 border 公式复核：HHTH 的有效前后缀只有完整模式和单字符 H，因此 1/(p³q)+1/p=715/54。公平硬币特例也回到经典值 18。

Fable 5 同样给出了正确的最终答案和状态方程，但在回代段把 E3 写成 421/135、把 E2 写成 1517/270。按原方程，正确值应为：

E1 = 625/54
E2 = 475/54
E3 = 170/27

这不是最终结论错误，而是“主答案正确、局部验证不一致”。对于需要把中间状态继续交给程序或后续推导的场景，这类算术尾差仍然值得单独标记。

物理题：碰撞损失不能带入弹簧阶段#

设置为：m1=2.0 kg、v1=6.0 m/s，静止小车 m2=3.0 kg，完全非弹性碰撞；之后组合体受 μ=0.20 的动摩擦并压缩 k=500 N/m 的弹簧，g=9.8 m/s²。

两车碰撞后的共同速度为：

V = (2×6)/(2+3) = 2.4 m/s

碰撞前后的动能分别为 36.0 J 和 14.4 J，所以碰撞损失：

ΔK = 21.6 J

进入弹簧阶段后，应该只用碰撞后的 14.4 J：

14.4 = 1/2·500·x² + 0.20·5·9.8·x
250x² + 9.8x - 14.4 = 0
x ≈ 0.2212 m ≈ 22.12 cm

Kimi K3 和 Fable 5 都得到 0.221 m 左右，并正确说明如果错误地把碰撞当作弹性碰撞，会得到约 0.360 m 的虚高结果。Fable 5 还检查了弹性碰撞下两车会分离，这与题设的“组合体”前提矛盾；Kimi K3 则把碰撞损失比例 60% 作为额外校验。

编程题：首轮不是代码失败，而是输出预算失败#

编程题要求实现 aggregate(records, start, end)，处理以下生产日志细节：

• 同一 request_id 多次重试，只取按时间排序后的最终记录；
• 只统计最终记录落在半开区间 [start,end) 内的请求；
• 计算成功率、延迟和 input/output/cache token；
• 明细按失败数降序、平均延迟降序、请求 ID 升序；
• 兼容 Z 时区、缺失 cache_read_tokens 和空输入。

第一轮两者的 finish_reason 都是 length。Kimi K3 的可见内容甚至没有形成完整代码块，主要预算消耗在 reasoning；Fable 5 已经输出了大部分代码，但在说明段被截断。因此第一轮不能直接判定谁的 Python 实现更好。

提高预算后的补充复测#

将提示词压缩为“只输出代码和不超过 10 行说明”，并把 max_tokens 提高到 7000：

两份代码都在 Python 3.11 标准库环境执行成功。验证覆盖了：最终重试覆盖旧状态、半开区间右边界、缺失 cache 字段、空输入、相同时间戳的稳定取值、失败数和平均延迟排序。Kimi K3 的实现额外把所有时间统一转换成 UTC，并保留 attempts 字段；Fable 5 的实现更短，使用分组后排序并在明细中统计全部尝试。

这里可以得出一个更准确的工程结论：两者都能完成这道代码题，但 Kimi K3 需要更大的输出预算和更长等待时间；在默认输出上限过低时，二者都会因为截断而让调用方拿到不可直接运行的结果。

文本推理题：约束传播结果一致#

题目给出六条条件：Ada 不在周一或周五；Bo 早于 Deng 且不相邻；Cici 是 Ada 的下一天；Eli 不在周二；Deng 不在周四；周三不是 Cici。

两者都通过同样的排除链：

1. Ada 只能在周二、周三、周四；Ada=周二会使 Cici=周三，直接违反条件，因此排除；
2. Ada=周四、Cici=周五时，Bo/Deng/Eli 只能占周一至周三，但所有合法的 Bo-Deng 组合都会把 Eli 推到周二，违反 Eli 条件；
3. 只剩 Ada=周三、Cici=周四；再由 Bo 早于 Deng 且不相邻，得到 Bo=周二、Deng=周五、Eli=周一。

唯一排班为：

Kimi K3 的答案更像形式化枚举，明确列出两个 Ada 分支；Fable 5 的答案更短，直接按分支排除。两种写法都能让读者复核，不需要额外补充条件。

综合评价#

如果把“正确性、完整性、速度、输出稳定性”拆开看，而不是给一个笼统总分：

因此，本轮更适合这样理解：

• 如果优先看复杂推导的自检和边界解释，Kimi K3 的数学答案更可靠，但它会花费大量 reasoning token，响应明显更慢。
• 如果优先看快速得到结构清晰的答案，Fable 5 更占优势；不过数学题的局部回代错误说明“最终数字正确”不等于“每一步都可靠”。
• 对编程任务，先确认输出预算是否足够比争论模型智力更重要。两者在 7000 token 上限下都通过了同一套本地断言。

复现实验#

原始响应、提示词、延迟和 usage 字段保存在仓库的临时结果文件中：

.tmp/kimi-k3-vs-fable5-results.json
.tmp/kimi-fable-programming-retry.json

复测时建议保留相同的模型 ID、temperature、max_tokens 和题目文本；模型渠道、上游负载和缓存状态变化后，延迟与 token 数可能不同。本文的结论只针对这次 Crazyrouter API 实测，不把一次请求当作绝对排名。