AI写个小游戏，竟折腾了百万Token？

一款简单的打砖块游戏，AI竟然可能消耗上百万Token！

更让人意外的是，最终生成的游戏看起来还相当不错。代码能够运行，功能基本完整，放到常见的AI编程评测中，很可能拿到一个不错的成绩。

但如果把AI完成任务的全过程拆开，情况就有些不同了。写错代码、执行失败、重新修改、反复尝试……有时还需要打开推理模式，才能让模型找到正确的解决办法。

最近，知名科技博主Wendell与AI内容创作者Alex进行了一场近30分钟的对谈。两人聊到了RTX PRO 6000、GB10、DGX Station GB300等硬件，也分享了自己使用本地大模型编程的经历。

其中一个话题尤其值得关注：当4-bit量化模型和BF16高精度模型都能完成相同的任务时，它们的真实能力究竟有多大差别？为了回答这个问题，他们尝试一种新的操作方法：把Agent的执行过程全部拆开，看看模型究竟是怎么完成工作的。

同样完成任务，4-bit模型可能走了更多弯路

Alex最近搭建了一套由四张RTX PRO 6000组成的计算集群，同时还在Dell Pro Max GB10等设备上测试不同模型。

随着硬件越来越强，本地运行大型AI模型已经能够完成不少复杂任务。过去需要数周才能完成的开发工作，现在借助AI可能只需要几个小时。但在持续测试过程中，两人发现，传统的性能指标已经越来越难解释模型之间的差异。

目前，本地大模型评测通常关注两个方面：一是每秒生成多少Token，二是能否完成指定任务。例如，让模型编写一个打砖块游戏，或者查找并修复GitHub代码仓库中的Bug。

如果一个4-bit量化模型成功完成任务，而另一个运行在DGX Station GB300上的BF16模型也完成了任务，那么仅从最终结果看，两者似乎没有太大区别。

问题出在执行过程。Wendell发现，某些低比特量化模型虽然能够交出不错的结果，却需要不断尝试和修正。模型可能先生成一段错误代码，随后发现无法运行，再重新分析问题、修改代码，直到获得正确结果。

他用打砖块游戏举例，提到过消耗约百万Token才完成任务的情况。在这种情况下，模型最终生成的游戏依然可能十分出色，但整个执行过程已经暴露出不少能力上的不足。

更复杂的是，影响结果的因素还有很多。例如，低比特权重量化可能损失部分模型能力，KV Cache量化也可能对输出质量产生明显影响。开启推理模式后，模型解决问题的能力又可能得到改善。

因此，即便最终任务成功率相同，模型在执行效率、推理稳定性和资源消耗方面也可能存在显著差异。不过，这些现象还需要通过严格的对照实验，才能确定其中有多少差异来自量化本身。

一个好的Harness，能让弱模型交出漂亮作业

随着测试深入，Wendell又注意到了另一个变量：Agent Harness。Harness可以理解为运行在大模型周围的一套执行与控制机制，负责组织任务、调用工具、检查结果，并在必要时让模型重新尝试。

Wendell提到，NVIDIA曾提出过一个观点：即使模型本身没有那么聪明，只要配备足够优秀的Harness，也可能取得非常好的任务结果。例如，让AI编写一段程序。

模型生成代码后，Harness可以自动运行测试脚本、进行代码静态检查，并判断程序有没有真正实现需求。如果代码存在错误，就把错误信息反馈给模型，让它继续修复。

这套机制能够有效减少模型幻觉带来的问题。即使模型第一次没有写对，也可以通过多轮验证和重试，逐渐得到正确答案。但代价同样存在，每一次重新读取错误信息、分析问题、修改代码，都会消耗更多Token，也需要额外的执行时间。

相比之下，一个能力更强、上下文处理更稳定的BF16模型，可能在第一次尝试时就避开部分错误，从而减少后续的修复成本。于是，新的问题出现了。假设两套Agent最终都成功完成任务，其中一套调用了大量工具、经历十几次重试，另一套只需要少数几步，那么该如何评价它们的能力？

如果只看最终结果，两套系统都可能获得相同的分数。而且，Harness本身也存在差异。不同的工具调用策略、测试机制和错误反馈方式，都可能影响模型最终表现。这意味着，在评测Agent时，需要同时考察模型、Harness以及两者配合所产生的实际成本。

把Agent的每一步都测清楚

为了更深入地分析这些差异，Wendell开始尝试用一些工具辅助。目标是深入模型执行过程，观察每一步究竟发生了什么。例如，当模型完成一个编程任务后，除了检查最终代码，还可以进一步分析模型在不同阶段的表现：

它在哪一步犯了错误？有没有重复尝试相同的方法？开启推理模式后是否改善？哪些错误由Harness发现并纠正？最终为了完成任务，又付出了多少Token和时间成本？通过这些执行记录，就能看到最终任务成功率难以体现的细节。

Wendell发现，一些模型虽然能完成相当复杂的工作，但执行过程中仍会表现出明显的挣扎。尤其在低比特量化条件下，这些问题值得进一步研究。

Alex也正在开发类似的评测项目。按照他的设想，新的评测体系需要同时覆盖运行速度和结果质量，并在两者之间加入更细致的执行效率分析。例如，一个模型每秒可以生成100 Token，另一个只能生成50 Token。

单看生成速度，前者明显领先。但如果前者完成任务需要生成10万Token，后者只需要2万Token，那么最终完成工作的时间和资源成本，就可能出现截然不同的结果。

这还只是模型层面的评测。当模型进一步接入Agent Harness，整个系统涉及任务规划、工具调用、结果验证和错误恢复，评测工作也会更加复杂。

Alex希望能够继续扩展自己的项目，分析Agent的实际工作过程，并自动验证任务完成质量。两人甚至讨论了未来合作制定相关评测标准的可能性。不过，目前这些工作仍处于探索阶段，视频中也没有展示完整的标准化对照实验或可复现的量化结果。

随着AI Agent越来越多地承担真实工作，评测中需要考虑的因素也在不断增加。过去，一张模型性能排行榜或一组Token/s数据，往往就能成为判断本地AI设备性能的重要依据。现在，同一个模型在不同Harness下可能表现迥异，不同量化精度也可能带来额外的重试成本。

对于真正使用AI编程、运行多步骤Agent任务的用户而言，除了最终答案是否正确，还需要知道它花了多长时间、消耗多少Token，以及过程中需要多少次人工或自动纠错。Wendell和Alex正在尝试回答的，正是这个问题。

当AI已经能够完成越来越复杂的任务，如何衡量它完成任务的整个过程，可能会成为下一阶段Agent评测的重要课题。