2026-07-30T14:16:04.000Z 用定制 WebGPU 解决扑克 代码代理是否已经足够聪明，以至于我们不再需要库？这篇文章叙述了一个案例，其中的答案是“我们不需要”：我需要一个张量库来在 WebGPU 中运行我的扑克模型。所需的库并不存在，但结果证明我并不需要它。 背景 在过去的一年里，我一直对扑克求解器的状态感兴趣。对不熟悉的人来说：求解器为扑克中的任何游戏情况寻找近似的纳什均衡策略。实际上，它们接受一个“情形”，一组公共牌和投注历史，并产生输出策略。由于策略近似于均衡，证明了它是（至多 epsilon）不可利用的：如果一个玩家采取与您的均衡不同的策略，他们在期望上无法胜过您。 商业求解器已经存在多年，但通常价格昂贵。我想制作一个开源的浏览器求解器，可以免费提供。考虑到计算要求，我需要找到一种方法在浏览器中运行神经网络和算法。使用 WebGL 或 WebGPU 有很好的模型评估方法，但没有相当于 PyTorch 的通用张量库。 我花了几个月的时间在 PyTorch 中构建和测试不同的模型。即使在我对最终输出感到满意时，也没有办法实现我在浏览器中提供它的目标。 参考实现 但这是2026年。我所需要的只是能够快速在 WebGPU 中产生相同输出的代码（相同功能；不同平台）。我学会了随处发现参考实现模式：PyTorch 是一个正确性的神谕。因此，我指示 Codex 为我构建一组 WebGPU 内核，以允许模型和核心算法的评估，并确认与 PyTorch 参考的一致性。经过一次提示，它就通过了相等性测试，因此我让它在循环中运行过夜以优化内核。 通过这种简单的方法，Codex 在第一次尝试中实现了超过 10 倍的速度提升——它还指出我需要更改模型的激活函数以提高性能。 从第一原则来看，库存在是因为编写正确、快速、架构良好的代码是昂贵的，因此我们将这一成本在成千上万的用户之间摊分，并接受随着通用性而来的抽象惩罚。如果生成是便宜且可验证的，这种权衡可能会反转：在这种情况下，执行我精确计算的定制内核可以胜过通用库。 正如其他人所指出的，一个你信任的测试套件来检验所有相关行为可能比 LLM 时代的规范更好。这并不是在任何地方都有效。计算必须定义清晰，参考实现必须可靠，测试必须捕捉到重要的行为。 实践中 均衡求解依赖于一种称为反事实遗憾最小化（CFR）的搜索风格算法。传统求解器带有巨大表格，列出不同情形中的策略和期望值；它们使用一种叫做抽象的技术将相似的情形归入同一个类别。更现代的方法则是对每个情形“重新求解”到有限的搜索深度，并在深度截止点使用神经网络作为近似函数。商业求解器有表格型（例如 Piosolver）和神经型（例如 GTOWizard）可供使用。 我去年秋天手动编写了 CFR 算法的第一实现。那时，LLM 仅在于错误排查和增强 Google 时才有用。它们很难生成有效的代码，更不用说我实际想要提交的代码。即使在急切的 PyTorch 代码中，它们也会定期引入 for 循环来遍历张量（这是一种巨大的禁忌）。当我试图制作定制内核时，它们根本无法处理不标准的复杂操作。 经过几个月，情况发生了很大变化。模型并不总是在第一次就写出完美的代码，但现在它们通常能够从头正确实现整篇论文。我可以要求代理调查 CFR 变体的文献，实现它们，并比较性能。它可以自主运行短期试验以优化超参数并推导基本的缩放法则。所有我去年秋天推迟的事情，因为它们不在工作模型的关键路径上，现在都可以完成。 尤其是在 WebGPU 任务中，可验证的奖励意味着我可以让 LLM 运行数小时（数天），直到它产生我想要的结果。尽管现在代理几乎写出我所有的代码，但我仍然是计划和判断的层次——在我的实验中，模型还没有这方面的能力。这个项目仍然让我花了几个月的时间监督 LLM 编码和实验。 换句话说，我在逐渐将更多的任务委托给代理，但他们在决定构建什么方面仍然很挣扎。 结论 库和语言的选择比以往任何时候都不重要。这个原理的一个延伸是：重写是不再重要的。