想象真实的全球物流：上海港同时停着日式木箱、美式纸箱和德式编织袋，起重机只能夹统一规格的角件，货船甲板的绑扎座也只认标准尺寸——没有统一集装箱，再繁忙的港口也会瘫痪。AI 的世界曾经历过同样的混乱：TensorFlow 导出一套 XLA HLO，JAX 又导出一套，两边说的“矩阵乘”细节并不完全一样，版本一升级，模型编译结果就可能漂移。StableHLO 就是给 AI 计算图定下的“国际集装箱标准”——一套稳定、精确、可版本化的中间表示规范。本文从概念定位、算子体系、类型系统、版本兼容、编译集成到工程实践，带你把这条“AI 物流大动脉”完整看一遍。

岗位关联

对AI从业者的价值：读懂 StableHLO 规范，你就握住了 AI 编译器中间的“通用语言”，无论是做框架适配、算子开发还是性能优化，都能站在全链路视角快速定位问题。

目录
  1. 可视化演示
  2. 概念定位：为什么需要一个标准货柜
  3. 算子体系：货柜内的码放单元
  4. 类型系统：货柜壁上的规格标签
  5. 版本兼容：箱规升级，旧箱不废
  6. 编译集成：中转站的分拣流水线
  7. 工程实践：物流员的工具箱
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示StableHLO可移植AI算子规范：算子分类演示张量运算/控制流/数据移动/归约四类算子；统一前端演示PyTorch/TensorFlow/JAX训练图统一编译为StableHLO IR复用后端；动态shape展示动态维度类型与shape计算的动态模型支持。

本节配有交互动效（进入视口后自动加载，约 3KB）。

算子分类体系 张量运算+控制流+数据移动+归约 stablehlo.add 每类算子有严格语义定义和类型约束

概念定位：为什么需要一个标准货柜

想象一个繁忙的国际港口：一边是主打日式木箱的东京工厂，一边是打包美式纸箱的纽约仓库，还有德式编织袋，它们统统要装上同一艘货船。货船的绑扎座是统一尺寸的，起重机抓钩是统一规格的，工人们只能干瞪眼——没有标准集装箱，货物再多也流动不起来。早期的 AI 编译世界正是这幅光景。

TensorFlow 有自己的 XLA HLO，JAX 也有 HLO，它们共享前缀却各有脾性：同一条 add 在不同版本里可能代表不同语义，程序里还残留大量“未定义行为”，编译器想怎么发挥就怎么发挥。OpenXLA 社区因此推出了 StableHLO——把 HLO 语义“提纯固化”的稳定中间表示。它把每个算子、每个类型、每条规则都写进规范，让前端框架与后端硬件能照着同一张图纸对接。

在编译栈中，StableHLO 位于“前端框架 — 设备无关优化 — 后端代码生成”的中间层。前端工具把 TensorFlow、JAX 的计算图转换为 StableHLO；编译器在 StableHLO 层做与设备无关的优化；随后经合法化（legalization，即把高级货拆成基础件的工序）落入后端 IR，最终生成机器码。这个分层让“模型怎么表达”与“芯片怎么执行”彻底解耦。

就像标准集装箱把“生产端”与“运输端”解耦：工厂只需把货装进标准箱，港口只需按标准箱作业，彼此不必知道对方内部细节。StableHLO 就是 AI 计算图的那只标准箱。

Frontend (TF/JAX)→ convert StableHLO IR→ optimize StableHLO IR′→ legalize Backend IR→ codegen Executable\displaystyle \text{Frontend (TF/JAX)} \xrightarrow{\ \text{convert}\ } \text{StableHLO IR} \xrightarrow{\ \text{optimize}\ } \text{StableHLO IR}' \xrightarrow{\ \text{legalize}\ } \text{Backend IR} \xrightarrow{\ \text{codegen}\ } \text{Executable}
这是一条“从计算图到机器指令”的流水线：StableHLO 卡在正中，两端都只需要跟这一个标准箱打交道。
  1. 前端转换框架把模型计算图“装柜”，导出为 StableHLO 格式的 IR。
    convert:GraphTF↦StableHLO\displaystyle \text{convert}: \text{Graph}_{\text{TF}} \mapsto \text{StableHLO}
  2. 设备无关优化在 StableHLO 级别做算子融合、常量折叠等改写，不动后端细节。
    optimize:StableHLO↦StableHLO′\displaystyle \text{optimize}: \text{StableHLO} \mapsto \text{StableHLO}'
  3. 合法化下降把 StableHLO 翻译到后端 IR，进入目标硬件的地盘。
    legalize:StableHLO′↦IRbackend\displaystyle \text{legalize}: \text{StableHLO}' \mapsto \text{IR}_{\text{backend}}
  4. 代码生成后端 IR 最终生成设备可执行代码。
    codegen:IRbackend↦Executable\displaystyle \text{codegen}: \text{IR}_{\text{backend}} \mapsto \text{Executable}

算子体系：货柜内的码放单元

有了标准货柜，里面的货也不能乱堆。StableHLO 规范的核心之一就是“装柜手册”——一套经过严格定义的算子集合（operations），每个算子都明确声明它的操作数（operands）、属性（attributes）和输出类型。

算子大致分四大家族：数值计算（dot_general、add、multiply、convolution 等）、数据搬运与变形（reshape、transpose、concatenate、slice 等）、通信与并行（all_reduce、gather 等）和控制流（while、cond、case）。每个算子都像一页“装箱说明”，把输入输出行为写得滴水不漏。

一个典型例子是 dot_general：它不只管二维矩阵乘，还能处理任意维张量的批量收缩——通过属性指定“把哪几根轴收缩求和”。规范同时定义“合理近似”边界：允许后端在极小误差内做更激进的数值重排，但不允许凭空改变语义。这就像箱单写明了“承重上限”，吊装时可以微调角度，但不能超重发货。

分拣员拿到一箱印着 dot_general 的货，只需按箱单上的收缩轴逐项求和，不管货来自东京还是纽约——算子规范让“读箱”变成机械动作，整条编译链路的自动化才成为可能。

result[i,j]=∑klhs[i,k]×rhs[k,j],lhs_contracting=[1], rhs_contracting=[0]\displaystyle \text{result}[i,j] = \sum_{k} \text{lhs}[i,k] \times \text{rhs}[k,j],\qquad \text{lhs\_contracting}=[1],\ \text{rhs\_contracting}=[0]
收缩维度属性就是“把哪两根轴捏在一起求和的旋钮”，旋钮拧法不同，矩阵乘就变成了批量矩阵乘。
  1. 操作数绑定每个算子固定操作数的个数、顺序与类型约束。
    dot_general:(lhs, rhs)↦result\displaystyle \text{dot\_general}: (\text{lhs},\ \text{rhs}) \mapsto \text{result}
  2. 属性驱动收缩维度由属性给出，控制“哪根轴求和”。
    lhs_contracting=[1], rhs_contracting=[0]\displaystyle \text{lhs\_contracting}=[1],\ \text{rhs\_contracting}=[0]
  3. 逐元素映射对逐元素算子，输出各位置只依赖同位置的输入。
    yi=f(xi)\displaystyle y_i = f(x_i)

类型系统：货柜壁上的规格标签

走进集装箱堆场，每只箱壁都印着长宽高、最大载重、温控要求。StableHLO 的类型系统就是这套标签：编译器不打开“货柜”就能知道里面装的是什么、占多大地方。

StableHLO 中的核心类型是张量类型（tensor type）：一个张量由形状（shape）与元素类型（element type）共同决定。元素类型覆盖浮点（f32、f64、bf16）、整数（i1、i8、i32、i64）与复数（complex64、complex128）等。bf16 这类“半精浮点”恰恰是 AI 训练的最爱——就像冷链箱写明了温控范围，谁都不会拿普通干散货去装冻虾。

类型系统还承担形状推导：reshape、broadcast、slice 等算子的输出形状可以由输入形状与属性静态算出来。形状不匹配的错误在编译期就被“打回”，而不是等到了目标硬件上才崩溃。这相当于报关单提前核对尺寸，货不对板就地退回，绝不进港。

堆场的计划调度员靠标签规划泊位，编译器靠类型标签规划寄存器与内存。标签越清晰，规划就越从容——这就是 StableHLO 把类型系统当作一等公民的原因。

TensorType=([d1,d2,…,dn], T),di∈Z≥0, T∈{f32, bf16, i32, complex64,…}\displaystyle \text{TensorType} = \big( [d_1, d_2, \ldots, d_n],\ T \big), \qquad d_i \in \mathbb{Z}_{\ge 0},\ T \in \{\text{f32},\ \text{bf16},\ \text{i32},\ \text{complex64},\ldots\}
张量类型 = 形状列表 + 元素类型，二者合起来就是编译器眼中的“货物规格标签”。
  1. 形状表每个维度一个非负整数，维度个数即张量的秩。
    shape(x)=[ d1, d2, …, dn ]\displaystyle \text{shape}(x) = [\,d_1,\ d_2,\ \ldots,\ d_n\,]
  2. 元素类型决定每个元素占用的字节数与解读方式。
    T∈{f32, bf16, i32, complex64, …}\displaystyle T \in \{\text{f32},\ \text{bf16},\ \text{i32},\ \text{complex64},\ \ldots\}
  3. 静态推导输出形状是输入形状的函数，无需运行即可求出。
    shape(reshape(x,S′))=S′\displaystyle \text{shape}\big(\text{reshape}(x, S')\big) = S'

版本兼容：箱规升级，旧箱不废

集装箱规格并非一成不变，但每一次修订都必须守住底线：老箱子在新起重机上依然吊得起来。StableHLO 与 HLO 最大的分野，就是它把“版本”和“兼容”正式写进了契约。

规范从 v1.0 起对变化进行版本化，并承诺：新版本编译器必须能读入旧版本生成的 IR，并保持其数学语义。新功能以“新增算子”或“放宽约束”的方式加入，绝不去改写旧算子的既有行为。这就像货柜规格每年升级，但每一代新码头都保留老规格的绑扎座。

更深一层，规范用“精确行为契约”锁定细节：舍入方向、溢出行为、NaN 传播等都有明确说法。这保证了同一模型在不同版本、不同后端之间可以获得可复现的结果——训练作业不会因为编译器偷偷更新而“翻车”。AI 基础设施的升级，从此不再是一场赌博。

港口十年一换的闸口设备，从来不敢让旧船进不了港——兼容性是基础设施的信用。StableHLO 把这份信用写进规范，AI 编译器才能放心地年复一年升级。

Semv′(IRv)=Semv(IRv),v′≥v\displaystyle \text{Sem}_{v'}\big(\text{IR}_v\big) = \text{Sem}_{v}\big(\text{IR}_v\big), \qquad v' \ge v
只要编译器版本不低于 IR 版本，读入旧 IR 后执行的数学语义就与旧版本一致。
  1. 旧档可读解析器不许拒收旧版本 IR。
    parsev′(IRv)≠error, v′≥v\displaystyle \text{parse}_{v'}(\text{IR}_v) \neq \text{error},\ v' \ge v
  2. 语义等价读入后执行结果与旧版本语义一致。
    Semv′(IRv)=Semv(IRv)\displaystyle \text{Sem}_{v'}(\text{IR}_v) = \text{Sem}_{v}(\text{IR}_v)
  3. 增量演进新特性通过“并集”方式加入算子集，而不是改写旧成员。
    OpSetv+1=OpSetv∪Δnew\displaystyle \text{OpSet}_{v+1} = \text{OpSet}_v \cup \Delta_{\text{new}}

编译集成：中转站的分拣流水线

集装箱货轮到达枢纽港后，还要经过一道道分拣工序：卸船、扫描、归类、装车。在 StableHLO 的世界里，这个“枢纽港”就是 MLIR——一套可复用的多级中间表示基础设施，专门用来调度各种 IR 之间的转换。

StableHLO 以 MLIR 方言（dialect，即挂在 MLIR 上的一套专用词汇表）的身份落地：程序由 module、func、program 等结构承载，算子形如 stablehlo.dot_general、stablehlo.while。MLIR 提供统一的 pass 框架，开发者像写作业指导书一样，把一系列优化 pass 串成流水线。

前端工具链负责“装柜与拆柜”：导入工具把 TensorFlow/JAX 的计算图翻译成 StableHLO；合法化把 StableHLO 高级算子逐步降级成 arith、index 等低层方言；再经 LLVM 转换进入目标硬件。多级 IR 让“通用优化”和“硬件特化”各司其职，互不干扰——通用优化在货柜还封着时完成，硬件特化等拆箱后再动手。

港口分拣线的效率决定整条物流链的吞吐。MLIR + StableHLO 把“优化”拆成一道道标准工序，每一道都在货柜还封着时完成，减少拆包重装的浪费——这正是多级 IR 的智慧。

Module0SHLO→ Pass1 Module1SHLO→ Pass2 ⋯→ legalize Modulelow-level→ convert LLVM IR\displaystyle \text{Module}_0^{\text{SHLO}} \xrightarrow{\ \text{Pass}_1\ } \text{Module}_1^{\text{SHLO}} \xrightarrow{\ \text{Pass}_2\ } \cdots \xrightarrow{\ \text{legalize}\ } \text{Module}^{\text{low-level}} \xrightarrow{\ \text{convert}\ } \text{LLVM IR}
一条典型的 StableHLO 编译流水线：先在高层做通用优化，再合法化下降，最后转成 LLVM 交给后端。
  1. 方言注册StableHLO 作为 dialect 挂载，每个算子有统一操作定义。
    stablehlo.add:tensor×tensor↦tensor\displaystyle \text{stablehlo.add}: \text{tensor} \times \text{tensor} \mapsto \text{tensor}
  2. Pass 串联编译流水线按顺序改造 Module，后一个 pass 的输入是前一个的输出。
    Module0↦Module1↦⋯↦Modulek\displaystyle \text{Module}_0 \mapsto \text{Module}_1 \mapsto \cdots \mapsto \text{Module}_k
  3. 合法化下降高级算子拆成低层方言组合，逐步逼近机器指令。
    stablehlo.if⟶scf.if⟶llvm branches\displaystyle \text{stablehlo.if} \longrightarrow \text{scf.if} \longrightarrow \text{llvm branches}

工程实践：物流员的工具箱

再好的标准，最终要由一线的物流员用好。对 AI 工程师来说，“用好 StableHLO”意味着三件事：会调试、会剖析、会定位性能瓶颈。

常用招数包括：用 IR dump 工具（如 mlir-opt）查看每个 pass 前后的图结构；用验证器（verifier）检查 IR 的类型与形状是否合法；用剖析工具统计各算子耗时占比。常见问题有：前端转换后形状不匹配、版本升级后出现兼容告警、算子融合不生效导致 kernel 过多。这些问题就像“箱门尺寸填错、旧箱规格看漏、柜内货物压坏”——标准无法消除失误，但工具能让你快速发现失误。

优化实践围绕三大抓手：常量折叠（把能算的提前算掉）、算子融合（把多个算子合成一个，减少中间读写）、布局优化（为硬件选择最佳内存排布）。判断收益的标准永远是端到端测量，而不是纸面推理——物流界的老话：不上秤的货物不叫货。

物流员靠卷尺、磅秤和 PDA 把标准落到实处；AI 工程师靠 IR dump、profiler 和 benchmark 把 StableHLO 的能力发挥出来。标准把复杂度聚拢，工具把它打薄——这就是工程实践的全部秘密。

speedup=TbaselineToptimized,ri=TopiTtotal\displaystyle \text{speedup} = \frac{T_{\text{baseline}}}{T_{\text{optimized}}}, \qquad r_i = \frac{T_{\text{op}_i}}{T_{\text{total}}}
加速比看端到端时延，瓶颈看单算子耗时占比，二者结合才能精准发力。
  1. 端到端测速优化前后完整运行时间作比，衡量真实收益。
    speedup=Tbefore/Tafter\displaystyle \text{speedup} = T_{\text{before}} / T_{\text{after}}
  2. 热点占比统计单个算子/子图耗时比例，锁定瓶颈。
    ri=Topi/Ttotal\displaystyle r_i = T_{\text{op}_i} / T_{\text{total}}
  3. 融合收益融合省去的中间张量读写时间。
    ΔT≈Tstore+Tload−Tfused_overhead\displaystyle \Delta T \approx T_{\text{store}} + T_{\text{load}} - T_{\text{fused\_overhead}}

AI 应用场景

跨框架模型统一部署

阶段：模型导出与编译（部署链路）

解决的问题：传统做法里，TensorFlow 用 SavedModel、JAX 走 jax2tf、PyTorch 又一套，后端适配要写 N 份代码；一旦切换硬件，整条链路重来。AI 的解法是把各框架计算图统一转成 StableHLO，让一份 IR 面向多个后端编译，硬件切换只改 target。

具体案例：某推荐团队用 JAX 训练、TF Serving 部署同一模型。过去每次升级硬件都要改两套编译配置，接入 StableHLO 后，前端统一导出，编译流水线一次优化，后端从 GPU 切到 TPU 只需改一行目标参数。

新硬件后端的快速适配

阶段：后端代码生成与算子实现

解决的问题：新芯片接入时，以往要为每个框架各写一套算子库，工作量以月计；StableHLO 固化算子语义后，新后端只需实现“StableHLO → 自家指令”的合法化翻译，语义由规范兜底。

具体案例：某 AI 芯片团队接入全新 NPU 时，只实现 StableHLO 常用子集加 custom_call（自定义算子扩展），三周内跑通主流视觉模型，而此前适配单一框架就需要两个月。

模型可复现性与回归基准

阶段：CI/CD 持续集成测试

解决的问题：HLO 语义漂移导致同一模型在不同框架版本下数值结果不同，回归基准形同虚设；StableHLO 的精确语义与版本兼容承诺，让测试基准稳定可比。

具体案例：某自动驾驶团队在 nightly 构建中对比每次编译产物的数值偏差。接入 StableHLO 后，偏差来源从“编译器语义漂移”收敛为“后端合理近似”，质量问题定位时间缩短约一半。

Python 演示

python91 行
# mini_stablehlo.py# 一个极简的 StableHLO 风格内存 IR,演示规范的四个核心概念:#   1. 张量类型(形状 + 元素类型)#   2. 算子语义(dot_general / add / relu)#   3. 常量折叠 pass(规范化优化)#   4. 版本兼容检查(新编译器可读旧 IR)# 运行: python mini_stablehlo.py class TensorType:    # 规格标签: 形状(shape)+ 元素类型(elem)    def __init__(self, shape, elem="f32"):        self.shape = tuple(shape)        self.elem = elem     def numel(self):        n = 1        for d in self.shape:            n *= d        return n     def __str__(self):        return "tensor<%s x %s>" % (list(self.shape), self.elem)  class Op:    # 一个 StableHLO 算子: opcode + 操作数 + 属性 + 输出类型    def __init__(self, opcode, operands, out_type, attrs=None):        self.opcode = opcode        self.operands = list(operands)        self.out_type = out_type        self.attrs = attrs or {}     def __str__(self):        names = ", ".join(str(o) for o in self.operands)        return "%s(%s) %s -> %s" % (self.opcode, names, self.attrs, self.out_type)  def build_mlp():    # 构造 y = relu(x @ W + b) 的小计算图    x = TensorType([2, 3])    w = TensorType([3, 4])    b = TensorType([4])    dot = Op("stablehlo.dot_general", [x, w], TensorType([2, 4]),             {"lhs_contract": [1], "rhs_contract": [0]})    add = Op("stablehlo.add", [dot, b], TensorType([2, 4]),             {"const_bias": 0})    relu = Op("stablehlo.relu", [add], TensorType([2, 4]), {})    return [dot, add, relu]  def canonicalize(ops):    # Pass: 把 x + 0 折叠掉,并重写后续引用(常量折叠)    fold_map = {}    kept = []    for op in ops:        if op.opcode == "stablehlo.add" and op.attrs.get("const_bias") == 0:            fold_map[id(op)] = op.operands[0]        else:            kept.append(op)    for op in kept:        for i, t in enumerate(op.operands):            if id(t) in fold_map:                op.operands[i] = fold_map[id(t)]    return kept  def is_compatible(ir_version, compiler_version):    # 版本兼容: 编译器版本不低于 IR 版本即可编译旧 IR    v_ir = tuple(int(x) for x in ir_version.split("."))    v_shc = tuple(int(x) for x in compiler_version.split("."))    return v_ir <= v_shc  def main():    prog = build_mlp()    print("== StableHLO program (before pass) ==")    for op in prog:        print(" ", op)     print("\n== after canonicalization ==")    for op in canonicalize(prog):        print(" ", op)     print("\nversion check: IR v1.0 / compiler v1.2 ->",          is_compatible("1.0", "1.2"))    print("version check: IR v2.0 / compiler v1.2 ->",          is_compatible("2.0", "1.2"))  if __name__ == "__main__":    main()
目的：用约半个百行的迷你内存 IR，把 StableHLO 规范的四个核心思想——张量类型、算子语义、常量折叠 pass、版本兼容——全部跑通一遍。
  1. class TensorType:定义“规格标签”：形状与元素类型合起来描述一个张量。
  2. self.shape = tuple(shape)把形状固化成不可变元组，防止误改。
  3. Op("stablehlo.dot_general", [x, w], ...)构造一个高维收缩点积算子。
  4. {"lhs_contract": [1], "rhs_contract": [0]}声明收缩轴：左边收缩第 1 维、右边收缩第 0 维。
  5. if op.opcode == "stablehlo.add" and op.attrs.get("const_bias") == 0:判断这个 add 是否属于“可折叠的 x+0”。
  6. fold_map[id(op)] = op.operands[0]记下“被折叠算子的替身”，供后续引用重写。
  7. for op in kept:遍历保留的算子，把指向被折叠算子的引用统一替换。
  8. def is_compatible(ir_version, compiler_version):实现向后兼容契约。
  9. v_ir = tuple(int(x) for x in ir_version.split("."))把"1.0"解析成可比较的元组，完成语义化版本比较。

常见误区

误区既然 StableHLO 是从 HLO 来的，名字也只差一个 "Stable"，那它跟 XLA 里的 HLO 就是一回事，开发时直接用 HLO 也可以。

正解StableHLO 是对 HLO 的“提纯固化”：它删掉了大量未定义行为，把每个算子、类型、版本都写成确切契约，并承诺向后兼容；而 XLA HLO 的语义随版本漂移，同一个程序在不同 TensorFlow 版本下的编译结果可能不同。就像把各家自制木箱统一成标准集装箱——外形像，但规格完全不同。

为何常见：两者共用 "HLO" 这个缩写，且 StableHLO 早期确实由 HLO 派生，初学者很容易把它们当成同一件事。

误区印象里 StableHLO 常出现在导出、部署的流程里，所以认为它只是推理侧的工具，训练时用不到。

正解StableHLO 面向训练与推理两条链路。训练的前向、反向、梯度更新都可以在 StableHLO 中表达和优化，OpenXLA 官方路线图也把训练场景作为重点。就像标准货柜既运原材料也运成品，不区分“训练品”和“推理品”。

为何常见：部署/推理的资料更多、示例更常见，训练侧大多还停留在 XLA HLO 的旧习惯里。

误区听说是“优化过的 IR”，所以觉得只要接入了 StableHLO，代码就会自动加速。

正解StableHLO 是“规范”而非“优化器”。它保证语义正确、可移植、可版本化，但提速来自后续的 pass 流水线与后端代码生成。标准箱不会让货物自己跑起来，效率取决于港口设备（编译器）和运输网络（硬件）。

为何常见：把“中间表示”与“编译器优化”混为一谈，忽略了 IR 本身不产生性能。

误区规范支持的算子越多，表达能力越强，后端实现也越方便，所以应该多多益善。

正解StableHLO 遵循精简算子集原则（KISS），一个 dot_general 就覆盖了从矩阵乘到高维批量收缩的多种情形，减少各后端重复实现与维护成本。每增加一个算子，都要付出兼容性、验证器和后端移植的代价，所以规范对新增算子非常克制。货柜型号太多，码头反而要建更多绑扎座。

为何常见：直觉上觉得“更多=更强大”，但没看到算子数量与生态维护成本之间的权衡。

误区既然承诺了向后兼容，那同一份 IR 用新编译器编译，数值结果应该和旧编译器一模一样。

正解兼容指的是“语义等价”：新版本能读旧 IR、能保持数学语义；但规范允许后端在“合理近似”范围内做数值重排，融合策略不同也可能带来微小数值差异。集装箱保证了货物种类不串味，但不保证每个苹果的长相完全相同。

为何常见：把 “compatible“ 理解成 ”bitwise identical”，混淆了语义等价与位级一致。

面试题

Q1. StableHLO 在 AI 编译生态中的核心定位是什么？

单选题 · mid

  • A.一种新型深度学习框架
  • B.可版本化的中间表示规范← 正确答案
  • C.TensorFlow 的运行时调度器
  • D.专为 GPU 设计的驱动接口

答案：B。StableHLO 是一套可版本化、精确定义的中间表示（IR）规范，位置在框架与后端之间，相当于 AI 编译的“标准集装箱”。A 错在它是 IR 而非框架；C 错在不是调度器；D 错在它与具体硬件驱动无关。前后端只认这一套中间箱规。

Q2. StableHLO 主要解决了 XLA HLO 的什么痛点？

单选题 · mid

  • A.算子运行速度太慢
  • B.语法表达过于晦涩
  • C.语义含糊且随版本漂移← 正确答案
  • D.不支持浮点张量运算

答案：C。HLO 的最大痛点是未定义行为多、语义随版本漂移，同一程序在不同版本下可能编译出不同结果。StableHLO 通过精确行为契约和版本化承诺解决这一问题。A 错在 IR 本身不决定速度；B 错在语法不是核心痛点；D 明显错误，浮点张量一直是 HLO 的基本能力。

Q3. 下列哪项属于 dot_general 的属性（attribute）信息？

单选题 · easy

  • A.操作数的元素类型
  • B.输出的形状约束
  • C.收缩维度的具体位置← 正确答案
  • D.后端的设备编号

答案：C。dot_general 通过 lhs_contracting、rhs_contracting 属性指明收缩轴，这正是“把哪两根轴捏在一起求和”的旋钮。A、B 属于类型系统层面而非算子属性；D 是运行时环境信息，与规范无关。货箱上的标签（类型）与箱单上的说明（属性）是两回事。

Q4. StableHLO 的张量类型由哪些成分构成？

多选题 · mid

  • A.张量形状的描述← 正确答案
  • B.元素类型的定义← 正确答案
  • C.算子融合的开关
  • D.硬件内存的地址

答案：AB。张量类型 = 形状（shape）+ 元素类型（element type），前者描述维度结构，后者描述每个元素的字节与解释方式，二者如同集装箱壁上的尺寸与温控标签。C 是编译策略，D 是运行时信息，都不属于类型定义。

Q5. StableHLO 与 MLIR 的关系是？

单选题 · mid

  • A.两者是互相独立的项目
  • B.StableHLO 是 MLIR 的方言← 正确答案
  • C.MLIR 是 StableHLO 的前端
  • D.MLIR 最后会被 StableHLO 替代

答案：B。StableHLO 以 MLIR 方言（dialect）的形式落地，借用 MLIR 的 pass 框架与多级 IR 生态。A 错在二者并非互不相干；C 方向反了，MLIR 是宿主基础设施而非 StableHLO 的前端；D 错在 StableHLO 不可能反向取代承载它的 MLIR。就像货物不会取代港口。

Q6. 关于 StableHLO 版本兼容性承诺，下列哪项正确？

单选题 · easy

  • A.新版本可以修改旧算子语义
  • B.新编译器必须能读旧版本 IR← 正确答案
  • C.每个大版本都重新设计算子
  • D.兼容性仅对推理场景有效

答案：B。版本兼容的核心是“向后兼容”：新版本编译器必须能读入旧版本 IR 并保持语义等价，旧箱在新起重机上依然吊得起来。A、C 违背兼容承诺；D 错误，兼容性对训练与推理一视同仁。

Q7. 以下哪些优化通常发生在 StableHLO 层级？

多选题 · hard

  • A.常量折叠与代数化简← 正确答案
  • B.算子融合减少中间读写← 正确答案
  • C.物理寄存器的分配
  • D.布局与形状的规范化← 正确答案

答案：ABD。StableHLO 层做的是与设备无关的图优化，包括常量折叠、算子融合、布局与形状规范化，就像在货柜封箱前先把货物归置整齐。C 的物理寄存器分配发生在后端代码生成（LLVM）阶段，属于拆箱后的工序，不属于 StableHLO 层。

Q8. 关于 dot_general 的运算语义，下列说法正确的是？

单选题 · mid

  • A.仅支持二维矩阵乘法
  • B.可对任意维张量按指定轴收缩← 正确答案
  • C.收缩轴必须位于最后一维
  • D.等价于逐元素的乘法

答案：B。dot_general 通过属性指定收缩轴，支持任意维张量的批量收缩，是“标准柜里的万能码放单元”。A、C 都错误地限制了它的能力；D 错在它做的是收缩求和而不是逐元素相乘。收缩轴位置完全由属性决定，不限定在最后一维。

Q9. 同一 StableHLO 程序用新旧编译器编译，数值结果略有不同，最可能的原因是什么？

单选题 · hard

  • A.StableHLO 规范被破坏
  • B.合理近似或融合策略不同← 正确答案
  • C.程序源代码存在语法错误
  • D.目标硬件设备不支持

答案：B。规范允许后端在“合理近似”范围内做数值重排，新编译器可能采用不同的融合策略或舍入顺序，带来微小数值差异，这是语义等价内的正常现象。A 过于绝对；C 若语法错误则根本编译不过；D 与数值差异无直接关系。集装箱不保证两个苹果完全一样。

Q10. StableHLO 出现在编译流程的哪些环节？

多选题 · easy

  • A.前端框架的计算图导出← 正确答案
  • B.设备无关的图优化阶段← 正确答案
  • C.操作系统内核的调度
  • D.指令缓存替换的策略

答案：AB。前端框架把计算图导出为 StableHLO，随后在 StableHLO 层做设备无关优化，这两步正是标准箱的“装柜”与“封箱前整理”。C 和 D 是操作系统/硬件底层机制，与中间表示规范无关。后端代码生成发生在 StableHLO 之后，不属于它的环节。