DeepSeek V4 Pro 在一个 Python 架构悖论题里想了 3 分多钟，消耗更多推理 token，最后仍给出一个结构完整但错误的方案。GLM-5.2 用约 12 秒、约 800 个推理 token，就判断这个设定不可行。
这个对比来自开发者 Oliver Shrimpton 6 月 18 日的文章《Bigger models are not the way》。原文借 GLM-5.2、GPT-5.5、DeepSeek V4 Pro、Fable 5 等模型的基准和幻觉率，提出一个不太舒服的问题：继续堆参数、堆训练数据、堆推理预算，换来的是真能力，还是更会把错误讲圆？
这篇文章不能当行业定论。它依赖 Artificial Analysis 的 AA 指标，以及 OpenRouter 上的有限测试环境。题集、部署方式、temperature、推理强度都会影响结果。
但它点中了模型选型里的硬问题：大模型仍然强，可“更大”已经不等于“更可靠”。
GLM-5.2让闭源大模型的领先没那么绝对
原文里最值得看的是 GLM-5.2。
它是 Z.ai 的 MIT 许可开源权重模型，753B 参数，约 40B active。在 Artificial Analysis Intelligence Index 上，它接近 GPT-5.5 和 Fable 5：与 GPT-5.5 约差 4 分，与 Fable 5 约差 9 分。
这不是说 GLM-5.2 全面超过闭源模型。AA 指标只能代表一部分能力面。
但对采购和技术负责人来说，信号已经够明确：闭源巨模型的优势还在，差距却不再天然大到“不用测”。
| 模型 | 原文提到的规模信息 | AA-Omniscience 幻觉率 | 该怎么理解 |
|---|---|---|---|
| DeepSeek V4 Pro | 原文列为 1.6T 参数、49B active | 94% | 能力强，不等于会承认不知道 |
| GPT-5.5 | 闭源，规模为外部估算 | 86% | 纸面能力高，但真实性风险需要单独测 |
| Fable 5 | 闭源 | 48% | 领先仍在，可靠性不是最优 |
| Opus 4.8 | 闭源，规模为外部估算 | 36% | 幻觉控制相对更好 |
| GLM-5.2 | 753B 参数、约 40B active，MIT 开源权重 | 28% | 分数接近，幻觉率更低 |
这里要特别小心：GPT-5.5、Opus 4.8 的 1-2T 规模只是外部估算，不是官方确认。不能把它们写成确定参数。
更稳妥的判断是：至少在这组指标里，一个开放权重模型已经把“可用性差距”拉小了。企业如果只按品牌和参数下单，容易多付一笔没有被业务结果证明的钱。
真正危险的不是答错，而是自信地答错
AA-Omniscience 测的是另一件事：模型遇到无法回答的问题时，是否愿意承认不知道。
原文给出的幻觉率很刺眼：DeepSeek V4 Pro 为 94%，GPT-5.5 为 86%，Fable 5 为 48%，Opus 4.8 为 36%，GLM-5.2 为 28%。
如果这个指标成立，问题就不是“模型会不会犯错”。所有模型都会犯错。
问题是：有些模型在不确定时，仍会把答案包装得很像真的。
Python 架构悖论题就是这个意思。题目要求单线程任务在不让出执行权、也不使用系统轮询的情况下处理多路 I/O。这个设定本身不可行。
DeepSeek V4 Pro 在 OpenRouter 环境中使用更多推理 token，耗时约 3 分 26 秒，仍输出了错误方案。GLM-5.2 更快识别了不可行。
这个案例不能推出 DeepSeek V4 Pro 在所有编程任务上更差。原文测试有变量：temperature 1、高推理强度、不同服务商的 FP8 部署，都可能改变表现。
但它足以提醒两类人。
做 AI 产品的人，不该只看模型“能不能答难题”。还要看它在合规问答、风控审核、架构评审里，能不能停下来。
做开发工具的人，也不该只奖励“完整代码”和“长推理链”。在不可满足条件下，拒答和指出矛盾，本身就是能力。
选型要从参数榜，改成三本账
我更在意的是，模型选型流程要变。
过去很多团队先看榜单、上下文长度、供应商品牌，再看价格。现在不够了。一个模型如果多花十倍推理 token 才产出错误答案，贵的不只是 API 账单。
后面还有人工复核、线上回滚、客户解释，以及安全事故的责任链。
更现实的做法，是把评测拆成三本账：
- 能力账.在自家业务集上的真实正确率，而不是通用榜单名次。
- 真实性账.遇到缺信息、条件矛盾、不可执行任务时，是否能承认不确定。
- 效率账.完成一次可验收任务的总 token、延迟和人工复核成本。
这会影响具体动作。
AI 产品负责人如果正在换模型，不妨把“一步迁移”改成灰度测试。先拿历史工单、失败案例、合规边界题跑一轮，再决定是否扩大流量。
开发团队如果在做 Agent 或代码助手，应把“陷阱题”和“拒答质量”放进评测集。不要只看模型写了多少，而要看它什么时候不该写。
现实约束也要讲清楚。
OpenAI、Anthropic、Google、Meta 仍在训练更强模型，规模路线没有消失。大模型在复杂推理、长上下文、多模态和工具调用上，仍可能有优势。
开源阵营也不是天然便宜。部署、量化、显存、工程维护、合规审查，都会变成成本。
所以这不是“闭源不行，开源胜利”的故事。更像是模型采购从看招牌，进入看账本。
接下来最该看的也不是谁宣布更大参数，而是三件事：同一业务集上的正确率，模型承认不确定性的稳定性，完成一次可验收任务的总成本。
如果这三项没有同时变好，“更大”就只是更贵的风险放大器。