StableHLO与MHLO编译中间表示对比

可视化演示

背景动机：多框架的“巴别塔”困境

假设你是一家国际物流公司的调度员，PyTorch 工厂把模型装进圆形桶，TensorFlow 工厂送来方形箱，JAX 工厂则直接散装发货。你想把货物送往 CPU、GPU、TPU 这几个不同的“国家”，但每批货都要单独设计一套搬运流程，工作量惊人。AI 编译领域最初也面临同样的困境：每个深度学习框架都有自己的计算图格式，后端硬件又各有各的指令集，接口组合爆炸式增长。

这正是中间表示（Intermediate Representation，IR）登场的理由。IR 像是一个“标准集装箱”：前端框架负责把模型装进箱子，后端硬件负责从箱子里取出货物，中间的运输环节只认这一种箱子。这样一来，每新增一个后端，不需要为所有框架各写一遍适配；每新增一个框架，也不需要重写所有后端。编译流程可以抽象为一条流水线：

所以，MHLO 与 StableHLO 正是这套流程中最重要的“集装箱规格”：规格设计得好不好，直接决定了港口是井然有序还是天天堵船。

MLIR基础：编译器界的港口基础设施

有了集装箱，还需要一个能高效装卸和管理它们的港口。这个港口就是 MLIR（Multi-Level Intermediate Representation）。MLIR 是 LLVM 社区推出的多级 IR 框架，它不规定某一层 IR 应该长什么样，而是提供一系列统一的基础设施，让不同团队都能在上面搭建自己的“方言”。

MLIR 中的“方言”（Dialect）是最核心的概念，可以把它理解成不同语言的报关单据。每个方言定义自己的算子（Op）、类型（Type）、属性（Attr）和接口（Interface）。例如 tensor 方言描述张量操作，linalg 方言描述线性代数计算。MHLO 和 StableHLO 正是在 MLIR 基础上注册的两个方言。用一个简洁的集合来表示：

如果没有 MLIR 这个港口基础设施，每个 IR 都要从零造轮子；有了它，StableHLO 团队可以把精力集中在集装箱规范本身，而不是反复重写港口吊机。

MHLO概述：集装箱草案

MHLO（Meta HLO）可以看作“港口的第一版集装箱草案”。它不是凭空出现的，而是来自 TensorFlow 和 XLA 早年的 HLO（High Level Optimizer）体系。HLO 是 XLA 编译器中描述计算图的格式，后来 TensorFlow 团队将其迁入 MLIR 生态，形成了一个独立的 MLIR 方言，即 mhlo dialect。

MHLO 最大的价值在于：第一次把 TensorFlow 的高层计算语义放进了 MLIR 的标准容器里，让 TF 模型可以经由 MHLO 被多个后端消费。它继承了很多 HLO 时代的算子命名和语义，比如 mhlo.dot_general、mhlo.conv。但由于与 TensorFlow/XLA 耦合紧密，MHLO 更像是为了解决 TF 内部问题而设计的“半官方草案”，缺少对外部生态的稳定承诺：

初版草案解决了“有箱子可用”的问题，但箱子的生产商、尺寸、版号都尚未标准化，长期大规模出海仍令人担忧。

StableHLO演进：标准化之路

StableHLO 的出现，像是一次彻底的国际标准修订。它从 MHLO 中 fork 出来，却不再以 TensorFlow 为父系统，而是自立为独立标准。2023 年前后，Google 推动 StableHLO 成为机器学习编译器领域的高层方言标准，目标非常明确：为前端框架和后端编译器之间提供一个稳定、版本化、可演进的高层 IR。

与 MHLO 的“事实标准”不同，StableHLO 引入了正式版本规范。用集装箱比喻，就是每个箱子都印着“ISO 标准 + 版本号”。任何 IR 程序都明确声明自己属于 v0、v1 还是 v2，编译器根据版本规则决定如何解析和执行。同时，StableHLO 的算子集更完整，对动态形状、复数类型、量化类型等高级语义也有更精确的规范：

从此，码头工人不用再猜测下一批箱子是什么规格：看版本号，就知道该用哪一套吊装流程。

算子集差异：箱内货物清单

集装箱统一后，下一步是统一“货物清单”。MHLO 与 StableHLO 都提供了一套算子集合，但两者在覆盖范围、命名规范、语义精确度上有明显差异。简单说，StableHLO 的箱子数量更多、标签更细、对货物的描述更准确。

从覆盖范围看，StableHLO 算子集实质上覆盖了 MHLO 绝大多数核心算子，同时还补充了一些 MHLO 中表达不清晰的边界情况。从语义精确度看，StableHLO 对动态形状、可变形算子、混合精度等特性有更明确的约束，让编译优化不必猜测算子隐含行为。MHLO 因为长期跟随 TF 演进，部分算子语义要参考 TF 文档才能确定，给下游编译开发者带来隐性负担：

如果把算子比作货物条目，MHLO 的表格里写着“一箱日用品”，StableHLO 则写清“12 支牙膏、24 块肥皂、保质期至 2026 年”。下游装卸队当然更愿意按后者操作。

稳定性设计：从“能跑”到“永不坏”

一个国际标准若年年改尺寸，码头设备就要年年换，任何公司都不敢投资。StableHLO 的稳定性设计正是为打消这种顾虑而产生的。它把“能跑”升级为“能长期跑、可预期地跑”，这也是它与 MHLO 最本质的差距。

具体而言，StableHLO 定义了三个兼容级别：首先，同一版本内算子语义不可随意改变；其次，跨版本升级必须提供显式升级路径；最后，新版本不能静默破坏旧版本 IR 的合法程序。编译器领域常说“可升级”比“不变”更现实，StableHLO 用版本策略解决了这一点：每个 IR 程序都带版本号，工具链可以根据版本执行升级或降级：

这也解释了为什么许多大厂愿意把生产环境切换到 StableHLO：标准一旦靠谱，生态投资才有安全感。

前向兼容：让老箱子还能上岸

前向兼容是一个容易被忽略却至关重要的设计。想象三十年前制造的集装箱，今天仍然能被全世界的港口设备抓起，这就是“前向兼容”的价值。StableHLO 承诺：用旧版本编写的 IR 程序，在未来版本的工具链中依然可以正常解析和运行，或者通过自动升级工具无损迁移。

为什么这很重要？因为 AI 模型的训练和部署周期很长，一个生产模型可能要在编译器生态里存活好几年。如果框架升级或编译器升级导致旧 IR 失效，企业将被迫返工。StableHLO 的兼容承诺包含两层：一是不动旧程序，二是迁移有保障。于是我们可以形式化地写：

前向兼容给了生态参与者一个“长期保险”：今天写的模型，明天、后年还能继续用，不用永远追赶编译器更新的浪潮。

工程价值：降低跨硬件适配成本

回到物流公司的账本：如果每个发货国都用自己的容器规格，适配成本是乘法级的；统一标准后，成本降为加法级。StableHLO 的工程价值正在于此。它让 PyTorch、JAX、TensorFlow 等框架的共同子集可以共享同一个 IR，再分发到 CPU、GPU、TPU、NPU 等硬件后端。

这种设计直接降低了生态各方的开发成本。框架侧不再需要为每个硬件维护专属导出；硬件厂商只需消化 StableHLO，就能接入所有主流框架的用户。编译器社区则可以围绕 StableHLO 共建优化 Pass，例如布局推断、算子融合、量化匹配，让每份优化工作都能被复用：

从短期看，迁入 StableHLO 需要学习新规范；从长期看，它让整个 AI 编译器生态拥有了更低的维护基线和更确定的协作契约，就像国际集装箱标准推动了全球贸易繁荣一样，StableHLO 也在推动 AI 模型跨硬件的高效流转。

AI 应用场景

Python 演示

class Op:    def __init__(self, name, args):        self.name = name        self.args = list(args)  class StableProgram:    """迷你 StableHLO：带版本号的中间表示"""     def __init__(self, version=0):        self.version = version        self.ops_list = []     def add_op(self, op):        self.ops_list.append(op)     def upgrade(self, new_version):        old = self.version        self.version = max(new_version, self.version)        return f"IR 已从 v{old} 升级到 v{self.version}"     def lower_to(self, backend):        result = []        for op in self.ops_list:            if backend == "gpu" and op.name.startswith("matmul"):                result.append(f"mma_{op.name}")            elif backend == "cpu":                result.append(f"avx_{op.name}")            else:                result.append(op.name)        return result  def build_mlp_graph():    prog = StableProgram(version=1)    prog.add_op(Op("matmul_0", ["x", "w0"]))    prog.add_op(Op("relu_0", ["matmul_0"]))    prog.add_op(Op("matmul_1", ["relu_0", "w1"]))    return prog  if __name__ == "__main__":    graph = build_mlp_graph()    print(graph.upgrade(4))    print("GPU 后端:", graph.lower_to("gpu"))    print("CPU 后端:", graph.lower_to("cpu"))

1. class StableProgram:用版本号模拟 StableHLO 的版本化容器。
2. def upgrade(self, new_version):模拟 StableHLO 的版本升级机制，直接提升版本号。
3. def lower_to(self, backend):模拟后端分发，GPU 走 mma_ 指令，CPU 走 avx_ 指令。
4. if __name__ == "__main__":程序入口，分别调用升级和后端分发函数。
5. print("GPU 后端:", graph.lower_to("gpu"))演示同一份 IR 转换为不同后端指令。

常见误区

面试题