从苦涩的教训到硬件彩票：AI 方法如何用好算力

做 AI 系统时，我们经常遇到两种解释：一种说，方法成功是因为它能持续利用更多算力；另一种说，方法成功是因为硬件和软件恰好对它友好。把 Richard Sutton 的《The Bitter Lesson》（苦涩的教训）和 Sara Hooker 的《The Hardware Lottery》（硬件彩票）放在一起读，可以把这两个问题看得更清楚。

我的理解是：Sutton 关注方法如何吸收新增计算，Hooker 关注不同方法能获得怎样的计算条件。两篇文章大体互补，同时在计算红利能否持续、能否惠及不同研究路线的问题上存在张力。对工程实践来说，它们帮助我们追问：新增资源通过什么机制改善结果，观察到的效果又有多少依赖当前的实现环境？

苦涩的教训：给方法留下扩展空间

Sutton 在 2019 年 3 月 13 日发表的原文中，回顾了棋类、语音识别和计算机视觉的发展。他认为，随着单位计算成本下降，能够利用更多计算的通用方法，长期往往比大量手工编码领域知识的方法更有优势。其中最重要的两类机制是搜索（Search）和学习（Learning）。

“苦涩”来自一种研究经历：精心设计的规则和表示带来了短期进步，后来却被更能利用新增计算的方法超越。人的投入是真实的，短期收益也是真实的，但这些设计可能逐渐成为继续扩展的限制。

我把这个观点转成一个工程问题：

如果计算预算增加一个数量级，这套方法通过什么机制把新增计算转化为更好的结果？

以代码修复为例。一套系统依靠人工编写的错误模式与修复模板；另一套系统可以提出多个候选补丁，在可重复的环境里运行测试，再根据反馈选择或修改补丁。前者可以快速解决熟悉的问题，后者则提供了扩大探索范围的途径。

不过，更多候选并不自动意味着更好的修复。测试如果只覆盖表面现象，搜索可能选中一个隐藏着回归的补丁。计算投入、探索机制和评价质量，需要一起检查。 这是我从 Sutton 的观点得到的工程推论。

硬件彩票：方法的表现带着环境条件

Hooker 的《The Hardware Lottery》于 2020 年发布预印本，后发表于 2021 年的《Communications of the ACM》。她用“硬件彩票”描述一种现象：研究方向的胜出可能来自对现有软硬件的适配，当前成绩不足以证明它相对于其他路线具有普遍优势。

理解这一点，可以设想两种算法。算法 A 的数学运算较多，但运算规则、连续、容易并行；算法 B 的运算较少，却依赖不规则访存和动态控制。如果芯片、编译器与计算库对 A 支持得更好，A 就可能运行得更快，也更容易被研究者反复试验。

于是，三个问题需要分别回答：哪个方法需要更少的运算，哪个方法在现有设备上更快，哪个方法在充分研究和不同实现条件下更有潜力。它们未必指向同一个答案。

Hooker 还提醒我们，围绕成熟方法发展的专用硬件，可能使探索其他方向的成本越来越高。研究机会会受到工具条件影响：实现越成熟，试验越便宜；试验越多，又越容易获得后续优化。

对当前产品选型来说，实际速度和成本当然有意义。对长期研究判断来说，还需要知道：一个方向表现不佳，究竟是方法本身的问题，还是实现条件限制了它？后者是一种待检验的解释，不能直接推出“获得支持后一定会胜出”。

两种视角如何放在一起

下面的对照是我的分析性概括：

问题	Sutton 带来的关注点	Hooker 带来的关注点
方法为什么能进步？	是否能持续利用新增计算	实际获得了怎样的计算支持
如何理解当前领先？	检查搜索与学习的扩展能力	检查软硬件适配的影响
投入应警惕什么？	人工知识可能带来的扩展瓶颈	基础设施可能造成的探索限制

图 1：本文对两种视角的概念性整理。箭头表示分析关系，不代表已测量的因果效应。点击可查看大图。

首先，“通用方法”和“通用硬件”属于不同层次。一种适用于多个任务的学习方法，可以运行在专门优化矩阵运算的硬件上。评价一个加速器时，我们既可以检查它提高了多少效率，也可以检查它是否方便支持其他方法。效率收益与探索空间收缩可能同时发生。

其次，算法包含人工设计，也不能直接说明它缺乏长期价值。架构、优化器、数据表示和搜索过程都需要设计。需要观察的是，这些设计如何帮助系统学习和探索，以及它们会不会限制后续改进。

两篇文章的张力在于计算红利的分配。Sutton 把单位计算成本持续下降作为重要依据；Hooker 则提醒我们，专用化可能让不同研究路线获得不均等的收益。从两种视角出发，“算力会变便宜”需要进一步展开：什么计算会变便宜，对什么方法变便宜，实现和迁移又要付出多少成本？

这些文章提供历史分析和研究战略判断。具体系统是否受益，仍然需要实验来回答。

Transformer 与 FlashAttention：设计改变计算的利用方式

以下是把两篇文章的视角用于后续工作的分析，并非 Sutton 或 Hooker 对这些工作的原文评价。

2017 年的《Attention Is All You Need》提出 Transformer，并在机器翻译实验中报告了更好的并行性和更少的训练时间。这个例子让我看到，架构设计可以改变计算的组织方式，从而让已有硬件更有效地参与训练。学习效果与实现效率共同影响一种方法的实际表现。

2022 年的FlashAttention进一步说明，计算速度还取决于数据怎样移动。它是一种考虑存储读写的精确注意力算法，通过分块减少 GPU 高带宽内存与片上 SRAM 之间的读写。原论文也指出，某些降低理论计算复杂度的近似注意力方法，未能获得对应的实际运行加速。

这两个例子把两种视角连接起来：理解硬件与存储层级，可以帮助学习方法更有效地使用计算，进而扩大能够研究的模型和任务范围。因此，评价 AI 系统时，算法创新、系统优化与计算投入应放在同一个实验条件下观察。

对大模型 Agent 的工程启发

下面的建议是我的工程推论，适用于代码 Agent、数据分析、根因分析与 Computer Use 系统。

让新增计算对应可检验的行动

增加思考 token、尝试次数或 Agent 数量，首先意味着资源投入增加。它们能否带来收益，需要进一步观察：更多尝试是否探索了不同方案，系统能否识别更好的结果，失败反馈是否改变了后续行动，以及人工接管是否减少。

例如，根因分析 Agent 提出十个原因，如果没有证据检验和排除过程，就很难判断这些解释的价值。候选原因应当对应日志查询、时间线核对或可复现的反证。代码 Agent 也需要把候选补丁与有效的验收连接起来。

这里还要区分反馈与学习：在一次任务中根据测试结果修改补丁，可以改进本次搜索；是否形成跨任务的持续学习，则取决于系统是否保存并利用经验，不能由一次重试直接推断。

图 2：把新增计算连接到行动、证据与验收的工程示意。重试有预算边界，反馈是否形成持续学习需要另行验证。点击可查看大图。

随模型升级重新检查工作流

复杂编排的价值应该通过比较来确认。可以使用相同任务集和验收标准，设置四组实验：

配置	要回答的问题
当前模型＋完整流程	现有系统达到什么水平？
更强模型＋完整流程	模型升级带来多少收益？
更强模型＋简化流程	哪些提示分支和人工拆解可以删减？
更强模型＋精简流程，但保留反馈与验收	执行环境和评价机制贡献了多少？

这些比较应固定输入数据、工具权限和验收方式，并记录实际消耗。若要判断单位计算的收益，还需要在每种配置内设置多个预算档位。工作流比较回答“设计有没有帮助”，预算比较回答“增加资源有没有帮助”。

模型变强后，一些提示分支的收益可能消失；执行环境、工具反馈和验收机制则可能继续有用。根据测量结果调整流程，才能知道哪些复杂度值得保留。

分别评价接口覆盖与执行可靠性

Computer Use 可以通过 GUI 操作多个应用；API、命令行和浏览器结构化接口也提供不同的行动方式。接口覆盖面会影响 Agent 能完成哪些工作，但还需要分别测量策略适应性，以及时间、成本和成功率。

一个系统能进入很多应用，并不意味着它在每项任务上都达到相同的效率。对于既有 GUI 又有 API 的任务，可以保持输入和验收一致，比较两种执行路径。遇到新状态或失败时能否调整行动，也应进入评价。

看完整任务的成本

对于业务系统，我会持续记录任务成功率、每次成功的总成本、完成时长、人工接管率，以及换模型、工具或环境后的变化。

其中，“每次成功的总成本”需要包含失败尝试与重试消耗；完成时长则应关注很慢的那部分任务，例如 P95。一次请求便宜、一次回答很快，都还不能说明完整任务同样便宜和快速。

这些测量能帮助定位瓶颈：模型能力不足，工具反馈不清楚，串行等待太多，还是实现效率偏低。找到瓶颈后，才有依据决定下一份计算预算应投向哪里。

回到两个问题

我会把《苦涩的教训》放在 AI 研究方法论与计算可扩展性的讨论中，把《硬件彩票》放在技术演化、基础设施选择与路径依赖的讨论中。它们给工程判断增加了两个需要同时回答的问题：

我的系统通过什么机制，把更多计算转化为更好的结果？

我观察到的领先或落后，有多少取决于当前软硬件提供的试验条件？

回答前一个问题，需要设计探索、反馈与评价；回答后一个问题，需要测量实现条件与完整任务成本。对我来说，值得持续投入的，是那些能在不同预算和环境下，用可检验的结果说明自己如何进步的系统。

参考资料

Richard Sutton：The Bitter Lesson，2019 年 3 月 13 日。
Sara Hooker：The Hardware Lottery，2020 年预印本；Communications of the ACM 版本，2021 年。
Ashish Vaswani 等：Attention Is All You Need，2017 年。
Tri Dao 等：FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness，2022 年。

本文依据一次关于两篇文章的讨论整理，并核对了上述原始资料。关于 Agent 的评价方法与工程例子，是本文的延伸分析。