企业官网建设流程全解析

PyTorch：一种参考语言

参考实现是系统的简化但完整的版本，它牺牲性能以换取清晰性。参考“语言”是构建这些实现的 API 和约定的基础。乍一看，PyTorch 显然是一种参考语言，毕竟它常被称为现代深度学习的通用语言。但仔细思考，就会发现一些令人困惑的地方：参考实现通常不会部署到生产环境，但有人却用 PyTorch 进行训练任务；大家都在用内核领域特定语言（kernel DSLs）编写内核，如果 PyTorch 只是将内核粘合在一起，它的作用是什么；人工智能编程最终意味着任何技术栈都可以从头重写，那么用 PyTorch 编写代码又有什么重要性。

PyTorch 的双重角色

最近有观点认为，将 PyTorch 视为扮演双重角色，既是参考语言，也是实现语言。当规模不是太大或者编译器运行良好时，参考实现可以部署到生产环境。并且将参考实现视为与实际生产实现分离的软件产物很自然，可以用它来验证生产实现的正确性。即一个用于研究的实现，一个用于扩展的实现，还有一个验证器在幕后确保一切无误。

内核 DSLs 的体现

内核 DSLs 的现代应用是上述观点的最清晰体现。传统的、编译器至上的观点认为，终端用户应使用高级 API（如 Numpy/PyTorch 风格的 API）编写神经网络模块的实现，再由编译器将其编译成优化形式。但对于像矩阵乘法和注意力机制这样最重要的操作，编译器很难保证达到最佳性能。内核 DSLs 的大量出现，让人们通过明确指定分块和数据移动来实现最佳性能变得简单多了。不过，用普通的 PyTorch 编写参考实现非常有用，大多数内核开发者会在开发优化内核的同时维护一个参考实现，并通过数值测试来验证其正确性。

编码智能体对训练步骤的影响

内核 DSLs 改变了算子生产实现的编写方式，编码智能体也会改变训练步骤生产实现的编写方式。传统上，自动求导（autograd）是 PyTorch 价值主张的核心部分，因为它能保证得到正确的导数。然而，在大规模场景下，隐式的反向图成了一个负担：大部分计算过程都隐藏起来了，无法使用常规调试工具与之交互，也不能像在即时前向代码中那样进行融合操作。虽然可以使用编译器通过模式匹配等方式修改反向图，但这种方法很脆弱，体验也不如直接将参考实现的调用替换为手写内核。已经停用的 [Tangent] 库就是基于源到源自动微分可能有用这一理念构建的。

新的方法

新的方法是将传统的 PyTorch 自动求导友好代码作为参考实现，使用大语言模型（LLMs）生成代码的显式前向 - 反向版本，这个版本可以与参考实现分开进行优化。与模式匹配不同，不必担心优化无法应用。但代价是参考实现和实际实现可能会出现差异，所以需要一个验证器来证明它们是等价的。这个验证器可以简单地通过按位等价测试来实现，也可以按照翻译验证的传统，以某种图捕获和结构等价的方式实现。为了确保验证器在一方有融合操作而另一方没有时也能正常工作，只需要提供融合操作的参考实现（可以理解为反向模式匹配）。

方法适用性与前景

这种方法并非适合所有人。作为参考语言的 PyTorch 是一个相当不错的可执行规范，真正重要的是能多快得到所需的实验结果。最近花了很多时间思考 PyTorch 在前沿训练中脱颖而出意味着什么，特别是随着规模的不断扩大，PyTorch 是否有必要自我革新。这种观点有助于弥合新旧方法之间的差距。Horace He 去年提出了一个开放性问题：“我们如何在获得即时模式执行的所有控制权的同时，享受图级抽象的一些便利？”这种方法是一个很有前景的答案，而 PyTorch 仍将处于核心地位。