PyTorch: 一种参考语言

# 一种参考语言——PyTorch 开发日志 原文链接：https://docs.pytorch.org/devlogs/compiler/2026-07-25-pytorch-a-reference-language/ Edward Z. Yang（@ezyang）· 2026 年 7 月 25 日 · 4 分钟阅读 · compiler torch.compile autograd verification llm 参考实现是系统的一个简化但完整的版本，它以牺牲性能为代价换取清晰性。那么，我们可以说一门“参考语言”是由这些实现所依托的 API 和约定构成的框架。乍一看，PyTorch 显然是一门参考语言：毕竟，它常被称为现代深度学习的通用语言。但仔细审视，会发现一些困惑： - 参考实现通常不会部署到生产环境。但我却用 PyTorch 来做训练任务！ - 每个人都在用内核 DSL 编写内核。如果 PyTorch 只是用来拼接内核，那它的角色是什么？ - AI 编程最终意味着任何栈都可以从头重写；用 PyTorch 编写又有什么意义？ 因此，对我而言，最近一个格外清晰的视角是将 PyTorch 视作扮演双重角色：既是参考语言，也是实现语言。当规模不大或编译器工作良好时，参考实现可以直接上线。但我越来越觉得，将参考实现视为一个与实际生产实现分开的软件制品会更自然，我们可以用它来验证生产实现的正确性。一个实现用于研究，一个实现用于规模扩展，而一个验证器则在黑暗中将它们绑定在一起。 这一点最清晰的体现是内核 DSL 的现代用法。传统的编译器最大化观点认为，最终用户应该使用高级 API（例如 Numpy/PyTorch 风格的 API）来编写神经网络模块的实现，然后由编译器决定如何将其编译成优化形式。但对于矩阵乘法和注意力这类最重要的操作，编译器很难保证达到峰值性能；内核 DSL 的普及使得人们能够通过显式指定分块和数据移动来更容易地获得最优性能。这消灭了高级 API 吗？通常不会：用纯 PyTorch 编写参考实现非常有用，大多数内核作者会同时维护一个参考实现和一个优化内核，并通过数值测试来验证正确性。 就像内核 DSL 改变了算子生产实现的编写方式一样，我认为代码智能体会改变训练步骤生产实现的编写方式。传统上，我们认为自动求导是 PyTorch 核心价值主张的一部分，因为它保证你能得到正确的导数。然而，在规模扩展时，隐式反向图会成为一个沉重的负担：大部分计算被隐藏起来，无法用常规调试工具与之交互，也无法像在即时前向代码中那样对它应用融合。有了编译器，可以通过模式匹配等方式修改反向图，但这很脆弱，并且体验不如简单地将一个调用从参考实现替换为手工编写内核那样好。这并非新观点：现已废弃的 Tangent (https://github.com/google/tangent) 库就是建立在源到源自动微分可能很有用这一命题之上的。 新的做法如下。保留传统的 PyTorch 自动求导友好的代码作为参考实现。使用 LLM 生成代码的显式前向-反向版本，该版本可以与参考实现分开优化。与模式匹配不同，你永远不必担心优化无法应用。代价是参考实现和实际实现可能会发生偏离：我们需要一个验证器来证明它们是等价的。这个验证器可以简单地通过逐位等价测试来实现，也可以实现为某种图捕获和结构等价，遵循翻译验证的传统。为了确保验证器在一方有融合而另一方没有时仍能工作，你只需要提供融合的参考实现（可以理解为一种逆模式匹配）。 我不打算断言这种做法对每个人都适用。事实证明，作为参考语言的 PyTorch 是一个相当不错的可执行规范，而最终真正重要的是你多快能获得所需的实验结果。但最近我花了很多时间思考 PyTorch 在前沿训练中表现出色意味着什么——特别是随着规模扩展，PyTorch 是否需要颠覆自身——我觉得这种视角有助于连接新旧两方面。Horace He 去年提出的一个开放问题是：“我们如何既能获得即时执行模式的所有控制力，又能拥有图级抽象的某些便利？”我认为这种做法是一个相当有前景的答案，而 PyTorch 仍然处于其核心。