我们根本不需要什么张量库：用自定义WebGPU内核解决扑克问题

# 我们根本不需要什么臭烘烘的张量库 来源：https://phulin.me/blog/poker/ ### 2026\-07\-30T14:16:04\.000Z (https://phulin.me/blog/poker) ## 用自定义 WebGPU 解决扑克问题 编程智能体是否已经足够强大，以至于我们不再需要依赖库了？这篇文章讲述了一个案例，其中的答案是“不需要”：我需要一个张量库在 WebGPU 上运行我的扑克模型。我想要的库并不存在。结果发现，我根本不需要它。 ## 背景 过去一年，我一直对扑克求解器的现状感兴趣。简单来说：求解器能为扑克中的任何游戏局面找到近似纳什均衡策略。在实践中，它们接收一个“局面”（一组公共牌和押注历史），并输出一个策略。由于该策略近似于均衡，因此它被证明（在 epsilon 范围内）是*不可被利用的*：如果对手采取与你均衡策略不同的策略，他们在期望上无法击败你。 商用求解器已经存在多年，但通常价格不菲。我想制作一个开源的、在浏览器中运行的求解器，并免费提供。考虑到计算需求，我需要找到一种在浏览器中运行神经网络和算法的方法。使用 WebGL 或 WebGPU 评估模型有很好的方法，但并没有像 PyTorch1 (https://phulin.me/blog/poker/#user-content-fn-1) 那样通用的张量库。我花了数月时间在 PyTorch 中构建和测试不同的模型。即使我对最终在电脑上运行的结果感到满意，也无法实现在浏览器中提供它的目标。 ## 参考实现 但现在是 2026 年。我只需要能产生相同输出、快速在 WebGPU 中执行的代码（同一函数，不同平台）。我已经学会在任何地方识别参考实现模式：PyTorch 是一个正确性预言机 (https://docs.pytorch.org/devlogs/compiler/2026-07-25-pytorch-a-reference-language/)。于是我指示 Codex 为我构建一组 WebGPU 内核，能够评估模型和核心算法，并确认与 PyTorch 参考实现一致。它在一个提示后便通过了均等性测试，所以我让它整夜循环运行以优化内核。通过这种简单的方法，Codex 在第一次尝试中就比自己原来的实现提速了 10 倍以上——它还指出我需要切换模型的激活函数以提高性能。 要求 Codex 创建自定义内核的原始提示 大致来说，库之所以存在，是因为编写正确、快速、架构良好的代码成本高昂，所以我们把成本分摊到成千上万的用户身上，并接受通用性带来的抽象代价。如果生成成本低廉且可验证，这种权衡就可能发生反转：在这种情况下，一个完全针对我的计算定制的内核可以击败通用库。正如其他人所指出的 (https://simonwillison.net/2025/Dec/15/porting-justhtml/)，在 LLM 时代，一个你信任并能覆盖所有相关行为的测试套件可能比一份规范说明更好。 这并非在所有地方都适用。计算必须定义明确，参考实现必须可靠，测试必须能够捕捉到重要的行为。 ## 实际应用 均衡求解依赖于一种称为**反事实遗憾最小化（CFR）** (https://www.ma.imperial.ac.uk/~dturaev/neller-lanctot.pdf) 的搜索式算法。传统的求解器带有巨大的表格，记录不同局面下的策略和期望值；它们使用一种称为抽象的技巧将相似局面合并到同一个桶中。更现代的方法则对每个局面进行有限搜索深度的“重新求解”，并在深度截止处使用神经网络作为近似函数。现有的商用求解器既有表格型（如 Piosolver），也有神经网络型（如 GTOWizard）。 去年秋天，我大部分手动编写了 CFR 算法的第一个实现。那时，LLM 基本上只能用于调试和增强 Google 搜索。它们很难生成能工作的代码，更别说是我真正想提交的代码了。即使对于热切的 PyTorch 代码，它们也经常引入对张量进行迭代的 for 循环（这是大忌）。而当我尝试制作自定义内核时，它们完全无法处理非标准、复杂的操作。 几个月后，情况大为不同。模型并非总能一次写出完美的代码，但现在它们通常能完全正确地从头实现一篇论文。我可以让智能体调研文献中关于 CFR 变体，实现它们，并对比性能。它可以自主运行短时试验来优化超参数，并推导出基本的扩展规律。所有那些我去年秋天因为不在通往可用模型的关键路径上而推迟的事情，现在都可以完成了。特别是在 WebGPU 任务上，可验证的奖励意味着我可以让 LLM 运行数小时（甚至数天），直到它产生我想要的输出。 尽管现在基本上所有代码都是由智能体编写的，但我仍然是上层的规划和判断层——在我的实验中，模型还不具备这种能力。这个项目仍然花了我几个月的时间来监督 LLM 编码和实验。换句话说，我把越来越多的任务委托给智能体，但它们仍然难以决定要构建什么。 ## 结论 库和语言的选择从未像现在这样不具约束力。这一原则的延伸是：重写不再是禁果 (https://simonwillison.net/2026/Jul/8/rewriting-bun-in-rust/)。 该求解器可在 holdem.computer (https://holdem.computer/) 上访问，所有代码均在 https://github.com/phulin/poker2 上提供。 ### 附言 我是在参与 Recurse Center (https://recurse.com/) 期间完成这项工作的，这是一个面向程序员的静修项目，也是我在世界上最喜欢的地方之一。如果你在考虑是否申请，去就对了！ 该项目结合了学术文献中不同论文的方法。特别是，我发现 DeepStack (https://arxiv.org/abs/1701.01724) 和 ReBeL (https://arxiv.org/abs/2007.13544) 非常有帮助，但这里无法列出我所依赖的所有论文。 当前的在线模型并不是最强的扑克求解器，它只支持两人（“单挑”）游戏。它还缺少商用求解器的功能，例如“节点锁定”（用于告诉你如何针对对手的非均衡策略进行利用）。要使底层模型成为真正强大的玩家，我需要更多的 GPU 时间，因为它训练所用的算力可能比学术文献中的模型少 100 倍。 1. 有一个名为 TFJS 的 TensorFlow 项目，但它似乎已被基本放弃，不支持我需要的几种基本操作，而且测试中速度很慢。↩ (https://phulin.me/blog/poker/#user-content-fnref-1)