当速度反而拖慢你：大模型选型中的时间-正确率权衡

0 阅读

速度不等于效率：重新定义模型“性能”

我们总爱谈大模型有多快、多聪明。但在真实世界里，尤其是涉及自主智能体、编程助手或研究系统时，这两个指标常常误导人。真正该问的问题是：哪个模型能最快给出正确的结果？

这听起来只是措辞上的微调，实则彻底改变了我们评估模型的方式。一个推理更强的模型单次耗时60秒，成功率85%；另一个稍弱但每15秒就能跑一次，成功率65%。表面看前者更优，但如果后者能在60秒内尝试四次，并且每次失败后都能从编译错误、测试失败等反馈中学到东西，那它很可能在第一个模型还没输出完时就已成功。

这种“通过快速试错逼近正确答案”的能力，是一种截然不同的性能维度。

稠密 vs 稀疏：Qwen3.8 与 Qwen3.5 MoE 的实战对比

以Qwen的两款模型为例：

  • Qwen3.8-27B 是一个270亿参数的稠密模型，官方强调其在编码、专业推理和长周期任务上的优势。它在GPQA Diamond、LiveCodeBench等基准上得分更高，显然是更“聪明”的那个。
  • Qwen3.5-35B-A3B 则是一个约350亿参数的稀疏混合专家（MoE）模型，但每次推理仅激活约30亿参数。它的设计目标是高吞吐、低成本。

在没有外部验证的一次性问答中，Qwen3.8无疑是首选。但如果任务是在一个能提供即时反馈的环境中（比如写代码），情况就变了。代码能否编译、单元测试是否通过、API返回是否符合预期——这些都是廉价而客观的评判标准。

此时，Qwen3.5 MoE的高速度让它能反复利用这些反馈进行修正。即使单次成功率低，多次迭代后的最终成功率可能反超。当然，前提是任务难度没超过它的能力上限。如果问题本身它就解不了，再快也只是重复失败。

量化选择：快一点，还是准一点？

同一个模型的不同量化版本，也面临类似的权衡。拿Qwen3.8-27B的Q4_K_M和Q5_K_M来说：

  • Q4_K_M 占用内存更少，在带宽受限的硬件上通常更快，但量化误差更大，可能导致更多细微错误。
  • Q5_K_M 保留了更多信息，推理质量更高，但速度稍慢，内存占用更大。

假设Q4平均40秒完成一次尝试，成功率72%；Q5需50秒，成功率90%。计算期望成功时间：40/0.72 ≈ 55.6秒，50/0.90 ≈ 55.6秒。两者打平。

但现实更复杂。并非所有错误代价相同。一个拼写错误，智能体秒改；一个架构性错误，可能让它在错误的道路上狂奔好几轮。更糟的是静默逻辑错误——程序能跑，但结果不对，智能体还以为自己成功了。

在这种情况下，Q5看似“慢”，实则因减少了纠错循环，端到端完成任务的总时间反而更短。这就是“通过更慢的单次推理实现更快的整体交付”。

错误的放大效应

任务越长，模型可靠性的影响就越呈指数级放大。一个简单的聊天回复，可能只涉及一次推理链。而一个自主编程任务，却包含上百个决策点：理解需求、阅读代码库、选择文件、编写代码、调用工具、编译、测试、诊断、修改……

早期的一个小错误，会像滚雪球一样，导致后续所有工作都建立在错误的假设之上。这意味着，模型在每个决策点上哪怕只有3%的准确率下降，在长任务中也可能导致大量无效的回溯、工具调用和重复生成。

这也是为什么，在常规语言模型基准上几乎看不出差别的量化损失，在长周期智能体任务中会变得至关重要。

没有所谓“最佳量化”

因此，“Q4_K_M是最好的量化”这类说法，充其量是个经验法则，而非普适真理。最佳选择完全取决于任务类型和运行硬件：

  • 闲聊或头脑风暴：Q4的高速度和多轮生成更有价值。
  • 高吞吐摘要：速度是王道。
  • 数学推理（无自动验证器）：必须保住Q5的额外精度。
  • 有强环境反馈的智能体：Q4的快速迭代可能扳回一城。
  • 硬件限制：如果Q5能完全放入显存而Q4不能，或者反过来导致CPU卸载，实际速度差距会天差地别。

模型从来不是孤立存在的，它的表现和运行它的机器深度耦合。

我们需要什么样的新基准？

当前的大模型评测体系是割裂的：一堆分数测智商，一堆分数测手速。但用户真正关心的是：在给定时间内，你能帮我搞定多少件实事？

为此，文章构想了一个名为“持续挑战完成度”（Persistent Challenge Completion, PCC）的新基准。

PCC的核心思想

给模型一个困难但可客观验证的任务（比如修复一个开源项目的bug），设定一个固定的“墙钟时间”预算，然后看它能不能在时间耗尽前，通过不断尝试、读取反馈、修正错误，最终交出一个通过验证器检验的成果。

评判标准不是第一次回答的质量，而是最终是否成功以及成功所花的时间。

任务设计要点

  • 明确目标：用自然语言描述任务。
  • 受控环境：提供代码库、浏览器或模拟API等。
  • 固定工具集：规定可用的工具。
  • 客观验证器：自动判断任务是否完成（如运行隐藏测试用例）。
  • 记录全过程：追踪所有动作、输出、失败和重试。

任务难度应分层，从简单的本地修复到复杂的长周期工程，甚至包含有迷惑性症状的对抗性任务。

关键指标

  • 验证工作每秒（VWS）：成功任务数 / 总耗时。
  • PCC分数：综合考虑完成率和完成速度的归一化得分。
  • 恢复质量：首次失败后最终成功的概率。
  • 进度效率：区分有效迭代和无意义的重复提交。

这个基准能清晰揭示一个模型是“强但慢”、“弱但快”，还是“善于从失败中学习”。

结论：追求“有效工作每秒”

最终，模型选型不应再纠结于“最聪明”或“最快”，而应回归到一个更本质的问题：哪种配置能在单位时间内产出最多经过验证的、正确的成果？

这取决于一个复杂的函数，输入包括模型的初始智能、输出质量、推理速度、环境反馈质量、错误恢复能力、失败成本以及可用的时间预算。

当失败代价低廉且易于修正时，速度就是王道；当失败会引发连锁灾难时，可靠性压倒一切。而一旦任务超出了模型的能力边界，再快的速度也无济于事。

所以，别再只盯着token/s或benchmark分数了。真正的性能，是成功的工作每秒。