把五款开放权重编码模型和 Anthropic 的 Claude Fable 5.1 放在一起比较，得到的结果可能让你怀疑自己看错了：GLM-5.3 在一个基准版本上领先 32 分，在另一个版本上又落后 27 分。这不是模型精神分裂，而是各家实验室在完全不同的基准版本上发布成绩，让排行榜上的数字几乎失去了横向比较的意义。

作者直接从供应商模型卡里提取数据，对比了 Claude Fable 5.1、Kimi K3、DeepSeek V4 Pro、GLM-5.3、MiniMax M2.5 和 Qwen3.8-27B 这六款编码模型。核心问题出在基准版本碎片化上：同一个 Terminal-Bench 测试，有的实验室用 2.1 版本，有的用 3.0，还有的已经上了 4.0，而难度在这些版本之间剧烈波动。

基准版本不匹配：排行榜数字为何不可信

最典型的例子就是 GLM-5.3。它在 Terminal-Bench 2.1 上拿到 88.2 分，到了 3.0 版本直接掉到 28.3 分；而 Claude Fable 5.1 在 4.0 版本上的成绩是 55.8%。如果把这三个数字放进同一个排行榜，GLM-5.3 既显得遥遥领先，又显得大幅落后，这种矛盾恰恰说明跨版本比较只会制造噪音，而不是提供洞察。

Z.ai 的 GLM-5.3 模型卡是唯一一个在单一测试平台上跑了多个竞争对手的，但它的参照对象是 Claude Fable 5，而不是更新的 5.1。这份模型卡在六个基准上纳入了 Claude Fable 5、GPT-5.6 Sol 和 Kimi K3，结果显示在 DeepSWE 这类任务上差距很小，但在 Agents' Last Exam 上排名会发生翻转。问题在于，Anthropic 报告称 Fable 5.1 相比 5.0 在这些任务上有显著提升，这让 Z.ai 的评估时效性打了折扣。

开放权重模型的实际水平：单问题修复追平，长时域智能体仍落后

独立机构 Vals AI 的评估给出了一个更接近真实的参照：Fable 5.1 在 Terminal-Bench 2.1 上得分为 85.02%，与自报的 Kimi K3（88.3%）和 GLM-5.3（88.2%）相近，尽管测量方式仍存在不对称。文章把 2026 年 9 月的实际前沿概括为：开放权重模型在单问题错误修复上已经追平上一代封闭模型，但在长时域智能体工作上仍有差距。

具体来看，DeepSeek V4 Pro 在 SWE-bench Verified 上拿到 80.6%，MiniMax M2.5 拿到 80.2%，与 Claude Opus 4.5/4.6 的约 80.8% 基本持平。而 Fable 5.1 是专门为智能体终端工作调优的，所以在 Terminal-Bench 上保持领先。这意味着如果你只需要修单个 bug，开放权重模型已经够用；但如果要处理需要长时间自主运行的智能体任务，差距依然存在。

许可证和活跃参数：决定你能不能真正用起来

模型能力之外，部署可行性由两个因素决定：许可证条款和活跃参数数量。MIT/Apache 2.0 阵营的 DeepSeek 和 Qwen 没有任何商业限制；Kimi K3 和 GLM-5.3 的许可证都包含收入触发条款，Kimi 还额外要求 UI 署名。文章的建议很直接：根据你的收入来读许可证，而不是根据偏好。

硬件成本则与活跃参数数量挂钩，而不是总参数。Qwen3.8-27B 是 27B 密集模型，可以塞进一块 24 GB GPU；MiniMax M2.5 约 10B 活跃参数，能放进 8 GPU 节点；Kimi K3 的 104B 活跃参数和 DeepSeek V4 Pro 的 49B 活跃参数则需要多节点集群，租用比自建更现实。

决策流程：先对齐任务，再在自己的代码库上验证

文章给出的选择框架分四步：把基准版本与任务类型对齐—— Terminal-Bench 对应智能体任务，SWE-bench Verified 对应单问题修复；根据许可证兼容性过滤；根据自有硬件选择模型规模；最后在承诺之前，用 LLM Token Cost Calculator 和 AI Token Counter 这类工具在自己的代码库上跑私有评估。

作者反复强调的一点是：模型卡上的每一个数字都来自公共任务测试平台，没有一个来自你的代码库。公共基准能帮你缩小候选范围，但真正决定模型是否适合你的工作负载的，只有你自己的测试集。