爱德华·Z·杨 (@ezyang) · 2026年7月25日 · 4分钟阅读 编译器 torch.compile 自动求导 验证 llm 参考实现是一个简化但完整的系统版本，以清晰度换取性能。我们可以说参考“语言”是这些实现所依赖的 API 和约定的结构。从表面上看，PyTorch 显然是一种参考语言：毕竟，它通常被称为现代深度学习的通用语言。但仔细观察后会发现有些混乱：参考实现通常不会部署到生产环境中。但我用 PyTorch 完成我的训练工作！每个人都在使用内核 DSL 编写内核。如果 PyTorch 只是将内核连接在一起，那么它的角色是什么？人工智能编码最终将意味着任何堆栈都可以从头重写；用 PyTorch 编写有什么意义？所以最近，对于我来说，一个异常明确的视角是将 PyTorch 看作扮演双重角色：既是参考语言又是实现语言。当规模不太大或编译器运行良好时，参考实现可以交付到生产环境中。但我越来越认为，将参考实现视为一种与实际生产实现不同的软件工件会变得越来越自然，通过它我们可以验证生产实现的正确性。一种用于研究的实现，一种用于扩展的实现，以及一个验证器，在黑暗中绑定它们。这一点在现代内核 DSL 的使用中得到了最清晰的展示。传统的编译器极端主义观点认为，最终用户应使用高级 API（例如，Numpy/PyTorch 风格的 API）来编写神经网络模块的实现，然后编译器负责将其编译成优化形式。但对于矩阵乘法和注意力等最重要的操作，编译器很难保证最佳性能；内核 DSL 的普及使人们通过显式描述平铺和数据移动来更容易地达到最佳性能。这样会消除高级 API 吗？通常不会：在普通 PyTorch 中拥有参考实现非常有用，大多数内核作者会在优化内核的同时维护一个并行版本，通过数值测试验证正确性。同样，内核 DSL 改变了运算符的生产实现方式，我认为编码代理也改变了训练步骤的生产实现方式。传统上，我们认为自动求导是 PyTorch 价值主张的核心部分，因为它保证你将获得正确的导数。然而，当规模扩大时，隐式反向图成为一种负担：你大部分的计算都被隐藏起来，无法使用普通的调试工具与之互动，或以与急切前向代码相同的方式对其进行融合。使用编译器，可以通过模式匹配来修改反向图，但这是一种脆弱且不太好的体验，远不如简单地将调用从参考实现切换到手动编写的内核。这不是一个新观察：现已停止更新的 Tangent 库的构建基于源到源自动微分可能是有用的。新的方案看起来是这样的。保持传统的 PyTorch 自动求导友好代码作为参考实现。使用大型语言模型生成代码的显式前向-反向版本，该版本可以与参考实现分开进行优化。与模式匹配不同，你无需担心优化未能应用。缺点是参考和真实实现可能会出现分歧：我们需要一个验证器来展示它们是等价的。这个验证器可以通过位级等价测试简单实现，也可以按照图捕获和结构等价的方式实现，遵循翻译验证的传统。为了确保在一方有融合而另一方没有融合时验证器工作，你只需提供融合的参考实现（如果你愿意的话，进行反向模式匹配！）。我并不想声称这个方案适合所有人。事实证明，作为参考语言的 PyTorch 是一个相当好的可执行规范，归根结底，真正重要的是你多快能获得所需的实验结果。但是，最近我花了很多时间思考 PyTorch 在边界训练中表现出色的意义——尤其是在扩展继续过程中，PyTorch 是否需要自我颠覆——我觉得这个视角有助于桥接旧与新。霍拉斯·赫去年提出的一个开放问题是：“我们如何能够在保持图级抽象的某些便利的同时，获得急切模式执行的所有控制？”我认为这个方案是一个相当有前途的答案，PyTorch 继续发展。