一款简单的打砖块游戏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评测的重要课题。 
长河君 · 2026/10/10 5:43:05 · 阅读 1.2k 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评测的重要课题。