StableHLO（Stable High Level Operations）

重要声明：本页撰写时外部检索全部返回 403 错误，以下内容基于公开可查的 GitHub 仓库（openxla/stablehlo）、MLIR 官方文档及 Google/XLA 公开博客等已知事实撰写。凡无法精确验证的规格数字均以定性表述标注，绝不凭记忆编造。

3 秒看懂

一句话： StableHLO 是由 Google 主导、基于 MLIR 的机器学习编译器中间表示（IR）标准操作集，为 ML 框架与异构硬件后端之间提供版本化、可移植、稳定的编译接口层。

类比： 如果把 AI 模型编译比作”翻译”，StableHLO 就是一套标准化的中间语言——框架端只管把模型翻译成这套中间语言，硬件端只管把这套中间语言翻译成自己的机器码，两端解耦。

3 分钟产业解释

问题背景：AI 编译的”巴别塔”

当前 AI 产业面临一个关键的编译碎片化问题：

• 框架侧：PyTorch、TensorFlow、JAX、ONNX 等框架各有自己的算子定义和 IR 表达；
• 硬件侧：NVIDIA GPU、Google TPU、AMD GPU、Intel Gaudi、以及数十家 AI 芯片初创公司的加速器各有自己的编译器栈；
• 现状：每家芯片公司都需要为每个框架写前端适配，组合爆炸（M 个框架 × N 个硬件 = M×N 条路径）。

StableHLO 的定位

StableHLO 提供一个稳定的标准操作集，将 M×N 问题降维为 M+N：

框架 (M 个) ──→ StableHLO（标准中间层）──→ 硬件后端 (N 个)

这意味着：

1. 框架方只需将模型导出为 StableHLO，无需关心底层硬件；
2. 硬件方只需实现从 StableHLO 到自家 ISA 的编译，无需逐框架适配；
3. 模型分发可以 StableHLO 为中间格式，一次编译、多处部署。

产业格局

StableHLO 是 OpenXLA 生态的核心组件之一。OpenXLA 是 Google 联合多家公司发起的开源 ML 编译器项目，StableHLO 作为其定义的稳定 IR 层，承担”通用中间语言”的角色。

15 分钟专家深入

1. 从 HLO 到 StableHLO 的演进逻辑

Google 内部的 XLA（Accelerated Linear Algebra）编译器长期使用 HLO（High Level Operations） 作为其内部 IR。HLO 的问题是：

• 不稳定：Google 内部可以随时修改 HLO 操作语义和版本，外部生态无法依赖；
• 缺乏版本化保证：没有正式的版本号和兼容性策略；
• 绑定 XLA 实现：HLO 与 XLA 的具体实现紧密耦合。

StableHLO 在 2022 年左右随 OpenXLA 项目公开推出，核心改进是：

2. 三层架构：StableHLO + VHLO + CHLO

StableHLO 实际上不是单一 IR，而是一个分层体系：

┌─────────────────────────────────────┐
│      CHLO (Compatibility HLO)       │  ← 向后兼容操作（已从稳定规范中移除的旧操作）
│     可被 legalize 为 StableHLO       │
├─────────────────────────────────────┤
│          StableHLO Ops              │  ← 核心操作集（~100+ 操作）
│    语义稳定、面向编译器优化           │
├─────────────────────────────────────┤
│         VHLO (Versioned HLO)        │  ← 版本化序列化格式
│    每个操作有明确版本号              │
│    用于跨版本兼容和模型持久化        │
└─────────────────────────────────────┘

• CHLO：Compatibility HLO，用于容纳那些因语义演进等原因已从稳定规范中移除、但仍需向后兼容的旧版本操作。它可以被“legalize”（合法化/降级）为当前的 StableHLO 操作组合。CHLO 不包含 softmax（softmax 由多个 StableHLO 基础操作组合而成），dot_general 也属于 StableHLO 核心操作集而非 CHLO；
• StableHLO：核心操作集，定义了 ML 编译中常用的计算原语；
• VHLO：Versioned HLO，通过目标版本属性（target_version）在方言级别管理版本兼容性，版本号是整体 StableHLO 版本（如 0.9.0），以此确保序列化后的 IR 在不同编译器版本间可被正确解析和升级。

3. 在 MLIR 生态中的位置

StableHLO 是一个 MLIR Dialect，完全构建在 MLIR 基础设施之上：

• 使用 MLIR 的 Operation、Type、Attribute 系统；
• 利用 MLIR 的 Pass 基础设施进行变换和优化；
• 与 MLIR 的其他 Dialect（如 linalg、tensor、memref）可互操作；
• 采用 MLIR 的 ODS（Operation Definition Specification） 以声明式方式定义操作。

这意味着 StableHLO 可以利用 MLIR 生态的全部工具链（验证器、打印器、pass pipeline 等）。

4. 核心操作集特征

StableHLO 的操作集覆盖 ML 编译的典型计算模式，大致包括（具体操作数量随版本迭代变化，此处仅作定性列举）：

• 张量运算：reshape、transpose、broadcast_in_dim、concatenate、slice、pad
• 算术运算：add、mul、div、neg、abs、exp、log、sqrt、rsqrt 等元素级操作
• 归约运算：reduce、reduce_window
• 线性代数：dot_general（通用矩阵乘法/点积，涵盖 GEMM/BMM 等）、convolution
• 比较与选择：compare、select、clamp
• 类型转换：convert（数据类型转换）、bitcast_convert
• 控制流：while、if（条件执行）
• RNG：rng（随机数生成，有不同算法变体）
• Collective 通信：all_reduce、all_gather、collective_permute、all_to_all 等分布式原语
• FFT、Iota、Constant 等其他操作

关键设计特点：

1. 纯函数式语义：StableHLO 操作是纯函数式的（无副作用），输入张量 → 输出张量，便于编译器做代数化简和重排；
2. 显式形状传播：张量的形状信息在 IR 中显式表达；
3. 动态形状支持：支持维度为 ? 的动态形状张量；
4. 类型丰富：支持 float（f16/bf16/f32/f64/f8 等多种位宽）、integer（i8/i16/i32/i64/u8 等）、complex、boolean、quantized 类型等。

5. dot_general 操作详解（核心中的核心）

dot_general 是 StableHLO 中最重要的操作之一，它统一了矩阵乘法的各种变体：

// 伪码语义
dot_general(lhs, rhs, 
            lhs_batching_dimensions, rhs_batching_dimensions,
            lhs_contracting_dimensions, rhs_contracting_dimensions)

• 通过指定 batching 维度和 contracting 维度，同一个操作可以表达：
  • 向量点积（1D × 1D）
  • 矩阵乘法（2D × 2D）
  • 批量矩阵乘法（3D × 3D，第一维为 batch）
  • 更高维的张量缩并

这与 numpy 的 einsum 或 PyTorch 的 torch.tensordot 类似，但以结构化的方式指定维度关系，而非使用字符串表达。

技术原理（最深层）

编译流程中的 StableHLO

StableHLO 在整体 AI 编译流程中的典型位置如下（以 JAX 为例）：

用户 Python 代码 (JAX/TF/PyTorch)
        │
        ▼
  框架级 IR（JAXPR / TF Graph / TorchScript）
        │  [框架导出/转换]
        ▼
  ┌─────────────┐
  │  StableHLO   │  ← 统一中间层
  └─────────────┘
        │
        ├──→ StableHLO 优化 Pass（形状推断、常量折叠、代数化简等）
        │
        ├──→ 转换为目标相关 IR
        │         │
        │         ├──→ (GPU) Linalg → GPU Dialect → LLVM NVVM/ROCDL → PTX/GCN
        │         ├──→ (TPU) 转换为内部 XLA HLO → TPU 编译器
        │         ├──→ (其他加速器) 转换为对应后端 IR
        │         └──→ (IREE 等) 转换为 VM bytecode + HAL 执行
        │
        ▼
  硬件可执行代码

StableHLO 优化 Pass 举例

StableHLO 层可以进行的常见优化变换（定性列举，具体 pass 实现细节可能随版本变化）：

与 XLA HLO 的技术差异

┌──────────────────────────────────────────────┐
│              XLA 内部编译流程                   │
│                                              │
│  HLO Graph                                   │
│    │                                         │
│    ├── HLO Pass: Fusion, Layout, Tiling...   │  ← 硬件感知优化
│    │                                         │
│    ├── Buffer Assignment                     │  ← 内存分配
│    │                                         │
│    └── Codegen（Emitter）                     │  ← 生成目标代码
│                                              │
│  （以上全在 XLA 内部，HLO 是内部 IR）          │
└──────────────────────────────────────────────┘

┌──────────────────────────────────────────────┐
│           StableHLO 生态编译流程                │
│                                              │
│  StableHLO（稳定接口层）                       │
│    │                                         │
│    ├── StableHLO 优化 Pass                    │  ← 硬件无关优化
│    │                                         │
│    └── Convert to Lower-level IR             │  ← 向下转换
│         │                                    │
│         ├──→ XLA HLO (TPU)                   │
│         ├──→ Linalg/其他 (GPU/其他)           │
│         └──→ 自定义后端                       │
└──────────────────────────────────────────────┘

关键区别：StableHLO 的设计目标是通用性和稳定性，而非特定硬件的极致优化。StableHLO保持与XLA HLO相当的硬件无关抽象层次，并增加了版本化和稳定性保证。硬件相关的 tiling、buffer 分配、指令选择等优化在后续编译流程中进行。

序列化与 VHLO 版本控制

模型以 StableHLO 格式分发时，实际序列化为 VHLO（Versioned HLO） 格式：

• VHLO 的版本兼容性通过目标版本属性（target_version）在方言级别管理，版本号是整体 StableHLO 版本（如 0.9.0），而非每个操作类型有独立版本变体；
• 不同版本的编译器可以通过版本升级 pass（upgrade pass）将旧版本 VHLO 转换为目标版本；
• 这保证了向后兼容：旧格式的模型可以在新版本编译器中正确解析。

此机制对于模型分发场景至关重要——用户导出的模型文件不会因为编译器升级而失效。

技术演进史

注意：以上时间线为基于公开信息的合理梳理，具体日期请以 OpenXLA 官方博客和 GitHub release 为准。

技术路线对比

ML 编译器 IR 路线对比

关键洞察：StableHLO 的差异化在于训练场景的完整支持（包括分布式通信原语、动态形状、复杂控制流），这是 ONNX 和 TOSA 相对薄弱的领域。

选择逻辑

需要模型交换/推理部署？  ──→ ONNX
需要端侧/嵌入式推理？   ──→ TOSA
需要通用 ML 编译（训练+推理）？ ──→ StableHLO ← 本文主角
需要 MLIR 原生的细粒度优化？ ──→ Linalg on Tensor

上下游

上游（谁产生 StableHLO）

下游（谁消费 StableHLO）

在 AI 编译栈中的位置

┌────────────────────────────────────────────────────┐
│                 框架层 (JAX/TF/PyTorch)              │
├────────────────────────────────────────────────────┤
│     ★ StableHLO ★  ← 【本文主角】                   │
│        (稳定、可移植的 ML 编译 IR)                    │
├────────────────────────────────────────────────────┤
│          MLIR 中层 (Linalg/Tensor/Memref)           │
├────────────────────────────────────────────────────┤
│       MLIR 低层 (SCF/Vector/GPU/LLVM Dialect)       │
├────────────────────────────────────────────────────┤
│             硬件 ISA / 机器码                        │
└────────────────────────────────────────────────────┘

关键指标

供需与市场数据

⚠️ 声明：StableHLO 是开源编译器 IR，不直接产生营收。以下从产业价值角度进行定性分析。

需求侧驱动

1. AI 芯片碎片化：全球有数十家公司开发 AI 加速器（[行业报告常见估算，如 McKinsey/BCG 报告曾提及数十家]），每家都需要编译器栈，StableHLO 降低了前端适配成本；
2. 框架多元化：PyTorch 占据训练主导地位，但 JAX 在 Google 生态和学术界增长迅速，TensorFlow 仍有大量存量部署，统一 IR 减少框架-硬件矩阵适配；
3. 模型分发标准化：随着 AI 模型从”自己训练自己用”转向”训练一次、多方部署”，稳定的中间格式成为刚需。

供给侧格局

潜在市场规模估算逻辑

StableHLO 的价值不直接独立计量，但可从以下角度估算其产业影响力：

• AI 编译器工具链市场（包含各种 compiler-as-a-service、工具授权）处于早期，[未充分披露] 具体市场规模；
• StableHLO 的价值在于降低每个 AI 芯片公司编译器研发成本中的前端适配部分——保守估计每家芯片公司前端编译器团队在数十人量级，StableHLO 可节省相当比例的人力。

代表公司与资本映射

核心贡献方

生态采纳方（公开信息可查的）

注意：以上采纳关系基于公开可查的信息（如 OpenXLA 官方列出的合作方、MLIR 社区贡献者等），各公司对 StableHLO 的实际投入程度未充分披露，投资者需独立验证。

投资逻辑

直接投资标的

StableHLO 本身是开源基础设施，没有直接的投资标的。但它的存在影响以下投资逻辑：

间接受益分析

1. AI 芯片初创公司（编译器成本下降）

• 逻辑：StableHLO 降低了新 AI 芯片的编译器”冷启动”成本。芯片公司不再需要从零为每个框架写前端，可集中资源在后端优化。
• 受益方：处于早期、编译器团队较小的 AI 芯片公司。
• 风险：StableHLO 的覆盖度和成熟度仍在演进中，是否能满足特定芯片的需求存在不确定性。

2. Google 生态（护城河与平台效应）

• 逻辑：StableHLO + JAX + TPU 构成 Google 的 AI 全栈。StableHLO 成为事实标准意味着更多框架和硬件”接入” Google 主导的生态。
• 受益方：Google Cloud 的 TPU 服务（GOOGL）。
• 风险：如果 PyTorch 生态持续主导训练市场，JAX/StableHLO 的影响力可能受限。

3. 编译器工具链/基础设施公司

• 逻辑：围绕 MLIR/StableHLO 的商业编译器服务（如优化、验证、性能调优）可能存在商业机会。
• 现状：目前以开源社区为主，商业变现路径不清晰。

关键观察点

• PyTorch 官方是否原生集成 StableHLO 导出：目前 PyTorch → StableHLO 依赖第三方（torch-mlir），如果 PyTorch 官方采纳，StableHLO 的生态位将大幅增强；
• ONNX 与 StableHLO 的关系：两者存在功能重叠（推理场景），长期是竞争还是互补值得观察；
• 其他芯片厂商是否采纳：如果 NVIDIA、AMD 等主流厂商的编译器栈原生支持 StableHLO 输入，将标志其成为事实标准。

常见误读纠偏

❌ 误读 1：“StableHLO 就是 XLA HLO 的公开版本”

纠正：StableHLO 和 XLA HLO 是不同的东西。

• XLA HLO 是 Google 内部 XLA 编译器使用的 IR，没有稳定性保证，与 TPU 编译器深度耦合；
• StableHLO 是一个新的、独立定义的操作集，目标是通用性和稳定性，其操作语义经过社区评审；
• StableHLO 可以被转换为 XLA HLO 用于 TPU 编译，但两者不是同一个 IR。

❌ 误读 2：“StableHLO 是一种新的模型格式，将取代 ONNX”

纠正：

• StableHLO 的首要定位是编译器中间表示，而非面向用户层的模型交换格式；
• ONNX 更侧重于推理场景的模型交换，有丰富的算子集、工具链和生态（ONNX Runtime 等）；
• StableHLO 可以作为模型存储和分发的格式（通过 VHLO 序列化），但这不是其核心差异点；
• 两者在推理场景有一定重叠，但 StableHLO 的独特价值在于训练场景支持（分布式通信原语、动态形状、复杂控制流），这是 ONNX 不覆盖的领域。

❌ 误读 3：“使用 StableHLO 就能实现零成本跨硬件移植”

纠正：

• StableHLO 保证的是语义正确性（同一操作在不同平台上语义一致），而非性能等价性；
• 不同硬件的最佳实现策略差异巨大（如 Tensor Core 的 tile 大小、内存层次等），这些差异需要在 StableHLO 之后的编译阶段处理；
• 某些操作在特定硬件上可能不支持或需要软件模拟，降级路径由后端决定；
• 因此更准确的说法是：StableHLO 实现了可移植的正确性，但可移植的性能仍是各后端编译器的竞争差异点。

❌ 误读 4：“StableHLO 只面向 Google TPU 生态”

纠正：StableHLO 是 OpenXLA 生态的一部分，其设计目标是跨硬件通用性。虽然其起源与 Google TPU/XLA 紧密相关，但它：

• 是一个原生 MLIR Dialect，可以被任何 MLIR 兼容的编译器栈消费；
• IREE 项目（非 TPU 特定）广泛使用 StableHLO 作为入口 IR；
• 多家非 Google 的硬件公司关注和评估 StableHLO。

学习路径

🟢 入门（1–2 天）

1. 阅读 StableHLO 官方网站（openxla.org/stablehlo）了解定位和设计目标
2. 浏览 GitHub 仓库（github.com/openxla/stablehlo）的 README 和 spec
3. 动手体验：用 JAX 导出一个简单模型的 StableHLO IR，观察 IR 结构

🟡 中级（1–2 周）

4. 学习 MLIR 基础：阅读 MLIR 官方文档，理解 Dialect、Operation、Pass、Type 等核心概念
5. 深入 StableHLO 规范：逐个学习 StableHLO 的核心操作（从 dot_general、convolution、reduce