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 個)

這意味著：

架構方只需將模型匯出為 StableHLO，無需關心底層硬體；
硬體方只需實現從 StableHLO 到自家 ISA 的編譯，無需逐架構適配；
模型分發可以 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 專案公開推出，核心改進是：

維度	HLO	StableHLO
穩定性	內部 API，可隨時變更	有正式相容性保證
版本化	無明確版本策略	VHLO 層提供版本化序列化
所有權	Google XLA 內部	OpenXLA 社群治理
MLIR 整合	不適用	原生 MLIR Dialect
目標使用者	Google 內部 TPU 編譯	跨硬體通用編譯

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 等其他操作

關鍵設計特點：

純函式式語義：StableHLO 操作是純函式式的（無副作用），輸入張量 → 輸出張量，便於編譯器做代數化簡和重排；
顯式形狀傳播：張量的形狀資訊在 IR 中顯式表達；
動態形狀支援：支援維度為 ? 的動態形狀張量；
型別豐富：支援 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 實現細節可能隨版本變化）：

最佳化型別	描述
常量摺疊	將編譯期可計算的子圖摺疊為常量
代數化簡	如 `x + 0 → x`、`x * 1 → x`、`exp(log(x)) → x`
形狀推斷/傳播	自動推導動態形狀維度
Layout 排列最佳化	為後續硬體後端選擇最優記憶體版面配置
操作融合	將多個元素級操作融合為單個 kernel
Quantization 傳播	量化資訊的傳播與校正

與 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 轉換為目標版本；
這保證了向後相容：舊格式的模型可以在新版本編譯器中正確解析。

此機制對於模型分發場景至關重要——使用者匯出的模型檔案不會因為編譯器升級而失效。

技術演進史

時間節點	事件
約 2017	Google 內部 XLA 編譯器使用 HLO 作為 IR，服務於 TPU
2019–2020	MLIR 專案在 LLVM 社群興起，提供多層 IR 基礎設施
約 2022 年中	Google 將 StableHLO 作為 MLIR Dialect 開源（GitHub: openxla/stablehlo）
2022 年末	OpenXLA 專案正式釋出，StableHLO 成為生態核心元件
2023	JAX 率先支援將計算圖匯出為 StableHLO；TensorFlow XLA 路徑整合
2023–2024	torch-mlir / SHARK 等專案支援 PyTorch → StableHLO 轉換；ONNX → StableHLO 路徑逐步完善
持續進行中	操作集持續擴充套件，Quantization 支援增強，VHLO 版本策略迭代

注意：以上時間線為基於公開資訊的合理梳理，具體日期請以 OpenXLA 官方部落格和 GitHub release 為準。

技術路線對比

ML 編譯器 IR 路線對比

維度	StableHLO	ONNX	TOSA	Linalg on Tensor	torch-mlir
主導方	Google / OpenXLA	Microsoft / LF	Arm	Google / LLVM 社群	LLVM / PyTorch 社群
定位	通用 ML 編譯中間層	模型交換格式	嵌入式/行動端編譯 IR	MLIR 原生的線性代數 IR	PyTorch → MLIR 的橋接
抽象層次	中等（原子操作級）	較高（運算元級）	中等（嵌入式友好）	較低（結構化迴圈級）	中等
MLIR 原生	✅ 是	❌ 獨立 IR 體系	✅ 是	✅ 是	✅ 是
版本化保證	✅ VHLO	✅ ONNX opset	✅ 版本化	❌ 無正式版本策略	⚠️ 不穩定
動態形狀	✅ 支援	⚠️ 部分支援	✅ 支援	✅ 支援	✅ 支援
Collective/分散式	✅ 有原語	❌ 不支援	❌ 不支援	⚠️ 需額外擴充套件	⚠️ 有限
量化型別支援	⚠️ 增強中	✅ 較好	✅ 原生支援	⚠️ 通過外部擴充套件	⚠️ 有限
主要服務場景	訓練+推論通用	模型交換/推論	端側/嵌入式推論	通用編譯後端	PyTorch 生態

關鍵洞察：StableHLO 的差異化在於訓練場景的完整支援（包括分散式通訊原語、動態形狀、複雜控制流），這是 ONNX 和 TOSA 相對薄弱的領域。

選擇邏輯

需要模型交換/推論部署？  ──→ ONNX
需要端側/嵌入式推論？   ──→ TOSA
需要通用 ML 編譯（訓練+推論）？ ──→ StableHLO ← 本文主角
需要 MLIR 原生的細粒度最佳化？ ──→ Linalg on Tensor

上下游

上游（誰產生 StableHLO）

來源	轉換路徑	成熟度
JAX	JAX → JAXPR → StableHLO（最原生的路徑）	★★★★★
TensorFlow	TF Graph → XLA HLO → StableHLO	★★★★☆
PyTorch	PyTorch → torch-mlir → StableHLO	★★★☆☆
ONNX	ONNX → onnx-mlir/onnx2stablehlo → StableHLO	★★☆☆☆
手動建置	通過 StableHLO C++/Python API 直接構造 IR	★★★★☆

下游（誰消費 StableHLO）

消費方	使用方式
XLA/TPU	StableHLO → XLA HLO → TPU 編譯器
IREE	StableHLO → Linalg → IREE HAL → LLVM → CPU/GPU/…
各 AI 晶片編譯器	StableHLO → 各家自定義後端 IR → 加速器
模型儲存/分發	StableHLO IR 序列化為 .mlirbc 或 .stablehlo 格式

在 AI 編譯棧中的位置

┌────────────────────────────────────────────────────┐
│                 架構層 (JAX/TF/PyTorch)              │
├────────────────────────────────────────────────────┤
│     ★ StableHLO ★  ← 【本文主角】                   │
│        (穩定、可移植的 ML 編譯 IR)                    │
├────────────────────────────────────────────────────┤
│          MLIR 中層 (Linalg/Tensor/Memref)           │
├────────────────────────────────────────────────────┤
│       MLIR 低層 (SCF/Vector/GPU/LLVM Dialect)       │
├────────────────────────────────────────────────────┤
│             硬體 ISA / 機器碼                        │
└────────────────────────────────────────────────────┘

關鍵指標

指標	說明	備註
運算元量	在數百個量級	隨版本迭代變化，具體數字請查 GitHub
支援的資料型別	f8/f16/bf16/f32/f64、i8/i16/i32/i64、u8 等、complex、bool、quantized	覆蓋主流 ML 資料型別
IR 格式	MLIR textual (.mlir) 和 bytecode (.mlirbc)	bytecode 更緊湊適合分發
版本策略	VHLO 語義化版本號	相容性保證程度請參考官方文件
語言繫結	C++（核心）、Python（API 和繫結）
依賴	MLIR/LLVM（主要）、abseil 等	LLVM 版本需匹配
License	Apache 2.0

供需與市場資料

⚠️ 宣告：StableHLO 是開源編譯器 IR，不直接產生營收。以下從產業價值角度進行定性分析。

需求側驅動

AI 晶片碎片化：全球有數十家公司開發 AI 加速器（[行業報告常見估算，如 McKinsey/BCG 報告曾提及數十家]），每家都需要編譯器棧，StableHLO 降低了前端適配成本；
架構多元化：PyTorch 佔據訓練主導地位，但 JAX 在 Google 生態和學術界增長迅速，TensorFlow 仍有大量存量部署，統一 IR 減少架構-硬體矩陣適配；
模型分發標準化：隨著 AI 模型從”自己訓練自己用”轉向”訓練一次、多方部署”，穩定的中間格式成為剛需。

供給側格局

角色	代表參與者
核心開發者	Google（XLA/OpenXLA 團隊）、LLVM/MLIR 社群
採納方（編譯器）	IREE（Google/開源）、各晶片公司編譯器團隊
採納方（架構）	JAX（原生）、TF XLA、torch-mlir、SHARK

潛在市場規模估算邏輯

StableHLO 的價值不直接獨立計量，但可從以下角度估算其產業影響力：

AI 編譯器工具鏈市場（包含各種 compiler-as-a-service、工具授權）處於早期，[未充分揭露] 具體市場規模；
StableHLO 的價值在於降低每個 AI 晶片公司編譯器研發成本中的前端適配部分——保守估計每家晶片公司前端編譯器團隊在數十人量級，StableHLO 可節省相當比例的人力。

代表公司與資本對映

核心貢獻方

公司/組織	與 StableHLO 的關係	資本市場對映
Google / Alphabet	StableHLO 發起者和主要開發者；XLA/TPU 生態原生使用	GOOGL
LLVM Foundation	提供 MLIR 基礎設施（StableHLO 建置其上）	非上市，社群治理

生態採納方（公開資訊可查的）

公司/組織	採納方式	資本對映
AMD	參與 OpenXLA 社群；ROCm 編譯棧關注 MLIR/StableHLO	AMD
Intel	IREE 專案參與（編譯器棧使用 StableHLO）；Habana/Gaudi 編譯器關注	INTC
Qualcomm	AI Engine Direct SDK 關注 MLIR 生態	QCOM
多家 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 天）

閱讀 StableHLO 官方網站（openxla.org/stablehlo）瞭解定位和設計目標
瀏覽 GitHub 倉庫（github.com/openxla/stablehlo）的 README 和 spec
動手體驗：用 JAX 匯出一個簡單模型的 StableHLO IR，觀察 IR 結構

🟡 中級（1–2 周）

學習 MLIR 基礎：閱讀 MLIR 官方文件，理解 Dialect、Operation、Pass、Type 等核心概念
深入 StableHLO 規範：逐個學習 StableHLO 的核心操作（從 dot_general、convolution、reduce