“正确答案”和“可信的答案”之间，往往隔着一整套验证工序。当模型给出一个看似合理的最终数值，中间的计算步骤是否经得起推敲？生成的代码能否跑通全部断言？这才是生产环境真正关心的问题。

近日，一项针对Kimi K3与Claude Fable 5的实测对比发布，测试将焦点从“答没答对”进一步延伸到“中间状态是否自洽”以及“代码是否完整可执行”。结果显示，两款模型在不同维度上呈现出明显分化。

打开网易新闻 查看精彩图片

最直观的差异体现在响应速度上。在相同的测试条件下，Claude Fable 5的平均延迟为37.1秒，而Kimi K3达到108.0秒。对于追求低延迟的应用场景，这几乎是三倍的时间差。不过，速度的快慢并不能直接等同于回答质量的高低，这一点在数学问题的验证环节表现得尤为突出。

测试从数学推理、代码生成、物理问题以及约束推理四个方向展开，所有任务采用完全相同的提示词与评判标准。测试方强调，判断成功与否的依据并不是HTTP状态码返回200，而是比对了最终值、中间状态、finish_reason字段、代码的可执行性以及断言是否一致。

在代码任务中，要求实现一个包含请求ID重试合并、ISO-8601时间处理、半开区间过滤、token与延迟聚合及多键排序功能的Python函数。首轮测试将max_tokens限制在4000，两个模型的响应都因达到长度上限而终止。重试时将max_tokens扩大至7000，Kimi K3耗时145.2秒，生成5199个completion tokens；Claude Fable 5耗时46.6秒，生成3710个completion tokens。最终两者的Python实现都通过了全部8项断言。

值得注意的是token消耗规模。Kimi K3首轮报告了约12500个reasoning tokens，整轮completion tokens为13975个；Fable 5的completion tokens则为10187个。更大体量的内部推理虽然带来了更细致的校验过程，但也推高了延迟，并可能导致在有限输出预算下可见代码篇幅被压缩。

数学题的测试把“中间一致性”摆上台面。题目是一个偏置硬币问题，设定正面概率为3/5，允许模式重叠，要求计算首次出现“HHTH”序列的期望次数。正确期望值为715/54，约等于13.2407。Kimi K3在求解时对状态方程、模式边界以及公平硬币特例下的数值做了交叉验证。Claude Fable 5交出的最终数值与正确答案一致，但在推导过程中有两个中间状态值与模型自身列出的方程无法匹配。

物理题方面，两道题的表现没有拉开差距。一个涉及完全非弹性碰撞、摩擦和弹簧压缩的两阶段问题，两个模型都正确算出了碰撞后速度2.4米/秒、碰撞中损失能量21.6焦耳以及弹簧最大压缩量约0.2212米。另一道约束推理题要求确定Eli、Bo、Ada、Cici、Deng五人唯一可行的日程安排，两者同样给出了一致的结果。

基于以上表现差异，测试方提出了一个按任务类型做模型路由的思路：对于需要产出大规模可测试代码的任务，可以从Claude Fable 5开始评估；涉及严密数学推导的场景，则继续保留Kimi K3。针对长篇代码，特别建议将finish_reason字段和实际执行测试列为必查项，以防止输出被截断却未察觉的情况。

同时，测试方也明确指出了本次比较的边界。这是基于小样本量的实测记录，并不是通用的排行榜。真正的生产环境评估，每个类别需要重复20到50次，并系统性地测量成功率、截断比例、首token时间、P50/P95/P99延迟、completion tokens消耗以及每单位获批结果的成本。

在这轮样本范围内，Claude Fable 5展示了一条更快的交付路径，而Kimi K3对于数学推理的中间状态执行了更审慎的校验。至于优先选速度还是优先选验证深度，这个问题并没有一刀切的答案。