为IBM Spyre加速器扩展Inductor后端

机器学习编译技术的格局正在向统一且灵活的框架演进。近期，IBM Spyre加速器的基于PyTorch的软件栈迎来了重大的架构演进，将其 torch.compile 的后端从完全从零构建的独立编译栈 sendnn 迁移到了 backend=inductor。这一转变标志着企业级硬件集成的一个重要里程碑，它允许专用企业加速器利用 PyTorch Inductor 强大的开源优化管道，而无需维护专有的编译生态系统。

在这篇深度技术评测中，我们将探讨为新型企业加速器扩展 Inductor 所面临的工程挑战，分析从自定义运行时向 PyTorch 原生编译主干的架构转变，并展示开发者如何使用如 n1n.ai 这样高效的可扩展工具无缝集成现代 LLM API 与自定义后端。

架构转变：从自定义 sendnn 到 Inductor

从历史上看，开发专用 AI 加速器的硬件厂商面临着艰难的选择：要么从零构建一个端到端的专用编译框架，要么艰难地将硬件原语塞入僵化的编译器抽象中。IBM 最初为其 Spyre 加速器选择了前者，开发了专用的编译栈 sendnn。尽管 sendnn 提供了对硬件特定执行路径的严格控制，但它也带来了沉重的维护负担、对新引入的 PyTorch 算子支持滞后的问题，以及尝试优化大语言模型和计算机视觉管道的开发人员所面临的高昂学习曲线。

通过转向 backend=inductor，IBM 和 PyTorch 的工程团队解锁了一种模块化架构。Inductor 基于 FX 图进行操作，根据目标设备将其降低为 Triton 内核或 C++ 代码。为 IBM Spyre 加速器扩展 Inductor 涉及实现自定义的代码生成目标，并将核心 ATen 算子映射到 Spyre 的底层指令集架构（ISA）上。

import torch
from torch._dynamo import optimize

# 针对自定义硬件后端标准的 torch.compile 用法
@torch.compile(backend="inductor