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 仍将处于核心地位。