想象你拿到一本米其林三星法餐厅的菜谱，上面写着“将胡萝卜切成小丁”“黄油小火翻炒”“真空低温慢煮”。这些基本动作，就是 AI 模型里的“算子”（Operator）。但你家厨房没有真空低温慢煮机，只有一口炒锅和一个电饭煲——算子映射（Operator Mapping）要做的，就是把这本书翻成你家厨房能执行的操作：没有慢煮机，就用小火慢炖替代；没有烤箱，就用平底锅加盖焖。翻译的唯一原则是：端上桌的菜，味道必须和原作一致——这叫作“语义等价”（Semantic Equivalence）。为了翻译得更高效，翻译官还会把菜谱里“先焯水再爆炒”的连续步骤合并成“热油快炒”——这就是算子融合。为了让菜谱能跨厨房交流，厨师界还发明了“世界语菜谱”——这就是 ONNX 这类中间格式。本文就用这个“厨房翻译”的故事，带你完整走一遍算子映射的原理、算法、优化与实战。

岗位关联

掌握算子映射，你就能看懂 AI 模型从框架到硬件之间经历的“最后一公里”，成为能落地部署、定位性能问题的 AI 系统工程师。

目录
  1. 可视化演示
  2. 算子基础：菜谱上的基本动作
  3. 映射原理：翻译不改变味道
  4. 核心算法：翻译官的工作流程
  5. 格式序列化：世界语菜谱
  6. 优化策略：厨房效率大作战
  7. 工程实践：开火营业
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示框架间算子映射转换、算子融合优化、自定义算子注册回退三阶段交互探索。

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

框架间算子映射 源框架算子逐一映射到目标框架 语义等价算子建立映射关系 支持PyTorch到ONNX等格式转换 Op_dst = Map(Op_src) 算子映射是模型跨框架部署的基础

算子基础：菜谱上的基本动作

翻开一本米其林法餐菜谱，你会发现再复杂的菜品，拆到底也就是“切丁”“翻炒”“炖煮”“调味”这些基本动作。AI 模型也一样——再深再大的神经网络，拆到底都是“卷积”“矩阵乘”“激活”“归一化”这类基本计算单元。在 AI 编译器的世界里，这些基本计算单元有一个统一的称呼：算子（Operator）。

算子是神经网络计算图中的最小可执行单位。如果用菜谱类比，菜谱的每一步就是一个算子，整本菜谱就是一张计算图。框架（PyTorch、TensorFlow）里的高层 API，例如 torch.nn.Conv2d，就是写好的“法式动作”。而目标硬件不认识这些高层动作，只认识更底层的指令——这就是后面要讲的映射问题的起点。

算子可以从三个维度去认识。一是类型：卷积（Conv）、池化（Pool）、矩阵乘（MatMul）、激活（ReLU/Sigmoid）、归一化（BatchNorm）、逐元素运算（Add/Mul）等。二是属性：比如卷积的 stride、padding、kernel_size，它们精确决定算子的计算行为，翻译时一点都不能错。三是数学表达：大多数算子的本质，是对输入张量做一次确定性的数学变换。

理解算子，就像厨师必须分清“切丁”“切丝”“剁末”的差别——同样是切，刀法不同，出来的菜就完全不同。只有把每个基本动作吃透，才能在翻译时保证法国大厨的意图不打折扣。

y=φ(W×x+b)y = \varphi(W \times x + b)
通俗说明：一次典型的全连接层计算——输入 x 乘以权重 W，加上偏置 b，再经过激活函数 φ，得到输出 y。
  1. 输入特征 x上一层的输出数据，通常是一个多维张量。
    xx
  2. 权重矩阵 W存储了神经元之间连接强度的参数。
    WW
  3. 线性变换 Wx+b权重与输入做矩阵乘法并叠加偏置。
    W×x+bW \times x + b
  4. 激活函数 φ引入非线性的运算，如 ReLU。
    φ(⋅)\varphi(\cdot)
  5. 输出 y本层计算结果，传递给下一层作为输入。
    yy

映射原理：翻译不改变味道

把法餐菜谱翻译给中国厨房时，最怕什么？最怕端出来的菜不是原来那个味道。算子映射的“味道”，就是数学结果。编译器把一个高层算子翻译成目标硬件的底层内核时，第一条铁律是语义等价：映射前后，对同样的输入，输出必须在容差范围内一致。

语义等价不是“差不多”，而是严格约束。比如卷积算子，无论把它映射成 GPU 上的 cuDNN 调用，还是 NPU 上的自定义指令，只要输入一致，输出特征图就得一致。反过来，如果数值对不上，再快的执行也是错的——就像做菜忘了放盐，端上桌才发现是另一道菜。

映射原理还包括布局变换与形状推导。布局（Layout）指张量各维度在内存中的排列顺序，训练框架常用 NCHW，而某些推理引擎偏好 NHWC；算子映射时必须插入一层数据重排（transpose/permute），否则内核读到的数据顺序是乱的。形状推导则是沿着计算图逐节点推断每张张量的形状，确保下游算子拿到的输入尺寸合法。

映射关系还有三种典型形态：一对一（Conv 直接被硬件卷积指令支持）、一对多（某些高级算子拆成多个底层算子逐步实现）、多对一（多个算子融合成一个内核）。这就像翻译复杂的法式甜点：有的直接能找到对应做法，有的要拆成几步完成，有的则能把几个步骤合并成烤箱一锅烤。

offsetNCHW=n×C×H×W+c×H×W+h×W+w\text{offset}_{\text{NCHW}} = n \times C \times H \times W + c \times H \times W + h \times W + w
offsetNHWC=n×H×W×C+h×W×C+w×C+c\text{offset}_{\text{NHWC}} = n \times H \times W \times C + h \times W \times C + w \times C + c
通俗说明：同一份数据，不同布局下第 n 张图、第 c 个通道、位置 (h,w) 的存储地址计算公式完全不同。
  1. n、c、h、w 四个下标分别代表批次、通道、高度和宽度位置。
    n,c,h,wn, c, h, w
  2. NCHW 的偏移量通道维排在最内层之前，先按 c 连续摆放。
    offsetNCHW=n×C×H×W+c×H×W+h×W+w\text{offset}_{\text{NCHW}} = n \times C \times H \times W + c \times H \times W + h \times W + w
  3. NHWC 的偏移量空间位置排在最内层之前，先按 h、w 连续摆放。
    offsetNHWC=n×H×W×C+h×W×C+w×C+c\text{offset}_{\text{NHWC}} = n \times H \times W \times C + h \times W \times C + w \times C + c
  4. 布局重排的本质把物理存储顺序整体搬移，地址计算公式随之切换。
    transpose(n,c,h,w)→(n,h,w,c)\text{transpose}(n, c, h, w) \to (n, h, w, c)

核心算法：翻译官的工作流程

翻译官拿到菜谱，不会逐字逐句机械地翻，而是先扫一遍有没有“熟面孔”——比如“法式炖菜”这种固定套路。AI 编译器也一样，它会在计算图上做图匹配（Graph Matching），寻找形状已知、可整体优化的子图结构。

图匹配的本质，是在大计算图中寻找与“模式图”同构或语义等价的子图。匹配到之后，编译器执行模式替换：把匹配到的子图整体替换为等价的更优实现。替换规则通常写成“左模式 → 右模式”的重写规则，左模式是一组高层算子，右模式是优化后的算子序列。

最有名的模式替换是算子融合。以 Conv+BN+ReLU 为例：训练好的模型里这三步依次执行，每步都要把中间结果写回内存、再读出来。融合的做法，是把 BN 的参数折进 Conv 的权重与偏置，让“卷积+归一化+激活”变成一次计算，中间张量彻底消失。

任何替换都要过合法性检查：数值类型是否支持、形状是否兼容、融合后的数值误差是否在可接受范围。这就像翻译官改完译文要请人校对——改得再巧，原意变了就是失败。通过检查，编译器才敢把融合后的内核交给目标硬件执行。

W^=γσ2+ϵ×W,b^=γ×(b−μ)σ2+ϵ+β\hat{W} = \frac{\gamma}{\sqrt{\sigma^2 + \epsilon}} \times W, \qquad\hat{b} = \frac{\gamma \times (b - \mu)}{\sqrt{\sigma^2 + \epsilon}} + \beta
通俗说明：把 BN 层的缩放 γ 和平移 β 折算到卷积的权重 W 和偏置 b 上，使得“卷积后接 BN”可以等价地用一个卷积完成。
  1. BN 统计量 μ、σ²训练阶段累积的均值与方差。
    μ,σ2\mu, \sigma^2
  2. 归一化系数γ 除以标准差，并加上极小量 ε 防止除零。
    γσ2+ϵ\frac{\gamma}{\sqrt{\sigma^2 + \epsilon}}
  3. 新权重 Ŵ原卷积权重乘上归一化系数。
    W^=γσ2+ϵ×W\hat{W} = \frac{\gamma}{\sqrt{\sigma^2 + \epsilon}} \times W
  4. 新偏置 b̂原偏置经过缩放后，再叠加 BN 的平移项 β。
    b^=γ×(b−μ)σ2+ϵ+β\hat{b} = \frac{\gamma \times (b - \mu)}{\sqrt{\sigma^2 + \epsilon}} + \beta
  5. 融合后的计算y = Ŵx + b̂，一步完成原先三步。
    W^×x+b^\hat{W} \times x + \hat{b}

格式序列化：世界语菜谱

世界各地厨房各说各话，法国大厨看不懂中国菜谱里的“少许盐”。为了让菜谱能跨厨房流传，厨师界需要一门“世界语”。在 AI 世界，这门世界语就是中间表示（Intermediate Representation，IR）。模型转换的第一步，通常是把 PyTorch/TensorFlow 模型导出成标准格式，再统一进入编译器处理。

最常见的标准格式之一是 ONNX（Open Neural Network Exchange）。ONNX 把模型描述成一张计算图：节点是算子，边是张量，每个算子附带属性与参数。无论模型来自哪个框架，只要导出的 ONNX 合法，下游编译器就能用一套统一逻辑处理——这份“世界语菜谱”让框架与硬件解耦。

序列化不只是存一张图，还要存权重。权重排布决定了加载速度和后续布局转换的代价：权重在磁盘上按什么顺序排列、是否与目标硬件的内存布局对齐，直接影响反序列化效率。此外还有版本兼容问题——ONNX 的算子集（opset）版本、IR 版本都在演进，高版本导出的模型，可能包含低版本编译器不认识的算子。

当然，“世界语菜谱”只是便于交流，真要让本地厨房做出来，还得翻译成本地方言——也就是继续走算子映射与内核生成。你在实际工程里遇到“ONNX 模型跑不起来”，十有八九不是格式本身的问题，而是后面的方言翻译还没做好。

G=(V,E,A)G = (V, E, \mathcal{A})
通俗说明：一个模型在序列化层面就是一张图——节点集合 V 是算子，边集合 E 是张量流动，属性集合 A 是每个算子的配置参数。
  1. 节点集合 V图中的全部算子，如 Conv、ReLU、Add。
    V={v1,v2,…,vm}V = \{v_1, v_2, \dots, v_m\}
  2. 边集合 E连接算子的张量，表示数据的依赖关系。
    E={eij=(vi,vj)}E = \{e_{ij} = (v_i, v_j)\}
  3. 属性集合 A每个算子携带的 stride、padding、axis 等配置。
    A={ak=(vi,attr)}\mathcal{A} = \{a_k = (v_i, \text{attr})\}

优化策略：厨房效率大作战

菜已经能做了，但客人催单怎么办？真正高效的厨房会提前备好食材、多个灶台同时开火、尽量减少厨师来回走动。映射完成后的内核同样要过三关：内存规划、并行调度、访存优化——也就是 AI 编译器里常说的性能调优。

内存规划，是给中间张量分配缓冲区时，优先复用已经死掉（不再被引用）的张量的内存。这就像炒完一道菜，盘子洗了马上给下一道用，避免每道菜都买新盘子。并行调度，则是把互相没有依赖的算子分配到多个计算单元并行执行——直观理解就是两个灶台同时煎牛排和煮汤。

访存优化是重头戏。现代加速器的算力远高于内存带宽，很多算子根本跑不满算力，而是在“等数据”。所以优化的核心原则是提高数据复用、减少片外内存读写——把数据留在片上缓存里多用几次。衡量这一点的关键指标是算术强度（Arithmetic Intensity）：单位字节数据上完成多少次浮点运算。

最后一招是内核优化：针对特定硬件手写汇编、使用向量化指令或张量指令（TensorCore），相当于大厨的独门秘制酱料。普通做法能出菜，秘方能更快更好地出菜。算子映射的工程魅力，就藏在这层层优化里。

AI=FLOPsBytes\text{AI} = \frac{\text{FLOPs}}{\text{Bytes}}
通俗说明：每从内存搬 1 字节数据，能完成多少次浮点运算？这个比值越高，算子越“计算密集”，越容易把硬件算力吃满。
  1. AI（算术强度）衡量计算密集程度的指标。
    AI\text{AI}
  2. FLOPs一次推理需要的总浮点运算次数。
    FLOPs\text{FLOPs}
  3. Bytes执行过程中从内存读取的数据总量。
    Bytes\text{Bytes}
  4. 比值越高越优尽量让每次取数都能支撑更多计算。
    FLOPsBytes\frac{\text{FLOPs}}{\text{Bytes}}

工程实践：开火营业

理论再漂亮，餐厅一开业还是会各种翻车：菜炒糊了、上菜慢了、客人投诉味道不对。算子映射落地时，也会遇到数值对不上、性能上不去、模型跑不动等问题。工程实践要解决的，就是这些“厨房事故”。

调试定位的第一原则是逐层比对：把原框架的每一层输出作为基准，与映射后在同一输入下的输出逐层对比，找出第一个产生偏差的算子，再分析偏差来源——布局错了、精度掉了（float32 变成 float16），还是融合规则本身有 Bug。这就像一道菜尝一口，马上锁定是盐放多了还是火候大了。

性能剖析靠 profiler：统计每个内核的执行时间、访存量、启动开销，画出热点分析。如果某个映射后的算子耗时异常，检查是否没走融合、数据布局与硬件期望不一致、或者并行度不足。常见陷阱包括：忽略 layout 导致大量非连续访存、低版本编译器不兼容高版本算子、融合后数值范围变化导致后续算子溢出。

以一个案例收尾：把 ResNet18 映射到某款 NPU，初始版本延迟 45ms；经过算子融合（Conv+BN+ReLU）、布局转换（NCHW→NHWC）、内存复用三步优化后，延迟降到 8ms，加速比超过 5 倍。翻译官的工作，从“能做”走到“做好”，靠的就是这些工程手段的层层打磨。

S=TbeforeTafterS = \frac{T_{\text{before}}}{T_{\text{after}}}
通俗说明：加速比等于优化前耗时除以优化后耗时，是衡量映射与优化效果最直观的指标。
  1. T_before映射优化前的推理耗时。
    TbeforeT_{\text{before}}
  2. T_after映射优化后的推理耗时。
    TafterT_{\text{after}}
  3. 加速比 S前后耗时的比值，大于 1 表示有提速。
    S=TbeforeTafterS = \frac{T_{\text{before}}}{T_{\text{after}}}

AI 应用场景

端侧 NPU 模型部署：把菜谱端上手机

阶段：模型转换与部署优化

解决的问题：手机 NPU 只认自家指令，不认 PyTorch 算子。算法工程师手动改写每个算子，效率低且容易出错，急需编译器自动完成映射。

具体案例：部署 MobileNetV3 到手机 NPU，先导出 ONNX，再由编译器完成布局转换、算子融合与量化映射。推理延迟从 80ms 降至 12ms，内存占用减少 40%，模型顺利通过端侧功耗测试。

多后端推理引擎统一适配：一家厨房三种灶台

阶段：推理引擎研发

解决的问题：同一模型要跑 CPU、GPU、NPU 三套硬件，每套硬件一套 SDK，重复开发量大且难以维护。

具体案例：推理引擎内置统一 IR，把 PyTorch 模型映射到一张“方言对照表”，各后端按需取用。新增硬件时，团队只需新写一份后端映射表，模型侧代码零改动，开发周期从三个月缩到两周。

大模型推理的算子融合优化：大模型上菜提速

阶段：高性能计算优化

解决的问题：LLM 推理时，注意力机制中的投影、旋转位置编码（RoPE）与 KV Cache 写入涉及大量显存读写，访存成为瓶颈。

具体案例：把 Llama-7B decode 阶段的 QKV 投影与 RoPE 融合成一个自定义内核，减少中间张量写回，decode 速度提升 2.3 倍，显存带宽压力显著缓解。

Python 演示

python109 行
"""Simplified operator mapper demo: map a high-level graph to hardware kernels."""from dataclasses import dataclass  @dataclassclass OpNode:    name: str    op_type: str    inputs: list    outputs: list  @dataclassclass Kernel:    arch: str    pattern: str    impl: str    fused: bool = False  class KernelRegistry:    """Kernel table of the target hardware, like a kitchen's tool list."""     def __init__(self, arch="NPU"):        self.arch = arch        self.kernels = [            Kernel(arch, "Conv", "npu_conv2d_fp16"),            Kernel(arch, "ReLU", "npu_relu"),            Kernel(arch, "Add", "npu_add"),            Kernel(arch, "Conv+BN", "npu_conv_bn_fused", fused=True),            Kernel(arch, "Conv+BN+ReLU", "npu_conv_bn_relu_fused", fused=True),        ]     def query(self, pattern):        # 在硬件内核清单上查找能执行某种模式的 kernel        for k in self.kernels:            if k.pattern == pattern:                return k        return None  class GraphMapper:    """Map graph ops to hardware kernels with pattern-based fusion."""     FUSION_RULES = [        (("Conv", "BN", "ReLU"), "Conv+BN+ReLU"),        (("Conv", "BN"), "Conv+BN"),    ]     def __init__(self, graph, registry):        self.graph = list(graph)        self.registry = registry        self.instructions = []        self.fused_clusters = 0     def try_fuse_at(self, idx):        """Try to fuse ops starting at position idx, return (fused_name, span)."""        for pattern, fused_name in self.FUSION_RULES:            if idx + len(pattern) > len(self.graph):                continue            matched = all(                self.graph[idx + i].op_type == pattern[i]                for i in range(len(pattern))            )            if matched:                return fused_name, len(pattern)        return None, 1     def map_graph(self):        """Walk the graph, fuse when possible, then lookup target kernels."""        i = 0        plan = []        while i < len(self.graph):            fused_name, span = self.try_fuse_at(i)            if fused_name is not None:                kernel = self.registry.query(fused_name)                self.fused_clusters += 1            else:                kernel = self.registry.query(self.graph[i].op_type)            if kernel is None:                missing = fused_name if fused_name is not None else self.graph[i].op_type                raise ValueError("unsupported op on %s: %s" % (self.registry.arch, missing))            plan.append(kernel)            i += span if fused_name is not None else 1        return plan  def build_graph():    ops = ["Conv", "BN", "ReLU", "Conv", "BN", "ReLU", "Add"]    return [        OpNode("op%d" % i, op, ["in%d" % i], ["out%d" % i])        for i, op in enumerate(ops)    ]  def main():    graph = build_graph()    registry = KernelRegistry("NPU")    mapper = GraphMapper(graph, registry)    plan = mapper.map_graph()    print("== Operator Mapping Result ==")    for idx, k in enumerate(plan):        tag = " [fused]" if k.fused else ""        print("step %d: %-14s -> %s%s" % (idx + 1, k.pattern, k.impl, tag))    print("fused clusters: %d, instructions: %d" % (mapper.fused_clusters, len(plan)))  if __name__ == "__main__":    main()
目的：演示算子映射的核心流程——遍历计算图、模式识别、融合、查内核表，最终把高层算子序列翻译成目标硬件可执行的指令序列。
  1. FUSION_RULES = [("Conv", "BN", "ReLU")...]定义映射器认得出来的“套路”，就像翻译官脑中的法式菜谱模板。
  2. def try_fuse_at(self, idx)检查当前位置开始的连续算子是否命中融合模式。
  3. matched = all(self.graph[idx + i].op_type == pattern[i] ...)逐个位置比对算子类型，是图匹配的核心逻辑。
  4. kernel = self.registry.query(fused_name)在目标硬件的内核清单上查找对应实现。
  5. raise ValueError(...)合法性检查失败时立即报错，避免把错误图交给硬件执行。
  6. main()构造一张含有 7 个算子的计算图，映射后输出 4 条指令，其中两组融合簇。

常见误区

误区以为每个算子都能在目标硬件上找到一个对应的底层指令，像查字典一样一一对应，找不到就没办法了。

正解现实中算子映射有三种形态：一对一、一对多、多对一。卷积在 GPU 上有专门内核可能是一对一，但某些高级算子（如 LayerNorm 这类融合了均值、方差、归一化多个子操作的算子）在缺乏专用指令的硬件上，会被分解成多个底层内核执行；反过来，Conv+BN+ReLU 三个算子又可以融合成一个卷积内核。真实的翻译不是逐词翻字典，而是按厨房条件重写整段工序，只要最终味道不变。

为何常见：高级框架把算子封装得很干净，让人误以为它们是不可拆分的“原子操作”。

误区张量的 NCHW 和 NHWC 只是排列顺序不同，数学上完全等价，所以无所谓。

正解布局直接决定内核读取数据时是否连续访问。假设硬件内核按 NHWC 顺序读取，而内存中数据按 NCHW 存储，那么每次取数都要跳到相距很远的地址，缓存命中率大跌，性能可能差 3-5 倍。数学上张量是同一个，物理存储却天差地别。就像厨房把调料按字母顺序摆，厨师按使用频率取，来回绕路，炒菜自然慢。

为何常见：写框架代码时很少需要关心内存排布，容易忽略物理存储层面的差异。

误区看到“ONNX 是标准格式”，就以为导出成 ONNX 后能在任何设备上直接推理，不需要额外转换。

正解ONNX 是模型交换的中间表示，本质是“菜谱”而不是“菜”。要让 ONNX 模型跑在某个硬件上，必须由编译器把计算图映射成该硬件的内核指令：布局转换、算子替换、融合、内存分配，一步都不能少。ONNX Runtime 在运行时做这件事，但同样经过编译或解释过程，不是“零成本直接执行”。菜谱不能直接吃，世界语菜谱也一样。

为何常见：ONNX Runtime 的 API 太顺滑，掩盖了背后的编译过程。

误区觉得算子融合、内存复用这类优化顶多提升 5% 的性能，不值得投入精力。

正解以算子融合为例，它消除了中间张量的写回与重读，还减少了内核启动次数。对含大量小算子的模型，融合常带来 2-10 倍加速。内存复用和布局调整的收益同样可观。把这些“锦上添花”乘上整个模型的算子数量，就是数量级的差距。这就像把“炒完盛出来再倒回去”改成“一锅到底”，省下的不是一点半点。

为何常见：在小型实验模型上感知不明显，到了大模型或小算子密集的场景才暴露差距。

面试题

Q1. 算子映射的核心目标是什么？

单选题 · easy

  • A.增加网络层数以提升精度
  • B.在目标硬件上等价实现算子← 正确答案
  • C.压缩权重以减小模型体积
  • D.自动生成训练数据的标签

答案：B。算子映射是把高层算子翻译成目标硬件可执行的底层内核，核心约束是语义等价。A 是网络结构设计，C 是模型压缩，D 是数据工程，都与映射无关。

Q2. 下列哪一组是典型的算子融合？

单选题 · easy

  • A.Conv 与 ReLU 融合为单个内核← 正确答案
  • B.Softmax 与 Dropout 融合
  • C.Embedding 与 Adam 融合
  • D.Loss 与 Accuracy 融合

答案：A。Conv+ReLU 是经典的算子融合模式，融合后跳过中间张量写回。B、C、D 的组合要么在不同计算阶段，要么涉及训练优化器，都不属于推理图的常见融合模式。

Q3. NCHW 与 NHWC 讨论的是什么问题？

单选题 · easy

  • A.改变权重数值的存储精度
  • B.调整张量各维度的存储次序← 正确答案
  • C.修改网络层之间的连接方式
  • D.改变卷积核的尺寸大小

答案：B。NCHW 与 NHWC 是张量在内存中的维度排列顺序，属于布局（Layout）问题。它不影响数学结果，但影响访存连续性和性能，是算子映射中必须处理的一环。

Q4. 算子映射关系包含哪些类型？

多选题 · mid

  • A.单算子映射为单个硬件内核← 正确答案
  • B.一个算子拆分映射为多个内核← 正确答案
  • C.多个算子融合映射为一个内核← 正确答案
  • D.任何算子都可以零开销直接跳过

答案：ABC。一对一、一对多、多对一是映射的三种基本关系。D 完全错误——算子在计算图中承担具体功能，不能被“跳过”，除非它是恒等变换等特殊情况。

Q5. 算子融合为什么能显著提速？

单选题 · mid

  • A.减少内核启动次数与中间访存← 正确答案
  • B.让模型收敛得更快更稳定
  • C.提升浮点运算的数值精度
  • D.减少训练数据中的噪声干扰

答案：A。融合消除了中间张量的写回与重读，同时减少了内核启动开销。它不改变训练收敛行为，也不提升精度（甚至可能引入微小舍入差异），更与数据噪声无关。

Q6. 语义等价要求映射前后什么保持一致？

单选题 · mid

  • A.参数量级和形状完全一致
  • B.输出结果在容差范围内一致← 正确答案
  • C.训练损失曲线完全一致
  • D.计算图拓扑结构完全一致

答案：B。语义等价关注的是“同样的输入产生同样的输出”，允许浮点舍入带来的微小误差。映射后计算图结构通常会变化（融合、替换），参数量也会因融合而改变，所以 A、C、D 都不成立。

Q7. 图匹配在算子映射中的作用是什么？

多选题 · mid

  • A.识别可融合或替换的子图模式← 正确答案
  • B.为模式替换提供候选位置← 正确答案
  • C.自动搜索神经网络的超参数
  • D.过滤掉数值异常的权重值

答案：AB。图匹配在大计算图中寻找与模式图同构的子图，找到的位置就是模式替换的候选点。C 是超参搜索，D 是权重剪枝/清洗，都和图匹配无关。

Q8. 访存优化的核心原则是什么？

单选题 · hard

  • A.提高片上数据复用，减少片外读写← 正确答案
  • B.把所有参数常驻在外部内存中
  • C.使用更高精度的数据类型
  • D.增加中间张量的写入次数

答案：A。现代加速器算力远超内存带宽，瓶颈常在“等数据”。核心策略是让数据在片上缓存多复用几次，减少 DRAM 访问。B、D 恰好相反，C 会增大访存量而非优化。

Q9. ONNX 作为中间表示的价值体现在哪些方面？

多选题 · hard

  • A.提供跨框架的模型交换标准← 正确答案
  • B.统一描述算子与图结构信息← 正确答案
  • C.可将模型直接运行在任何硬件
  • D.序列化权重以简化部署流转← 正确答案

答案：ABD。ONNX 让 PyTorch/TensorFlow 导出的模型共享同一套图与算子描述，权重也一并序列化，方便流转。但它只是“菜谱”，仍需要编译映射才能上硬件执行，C 错误。

Q10. 融合后的数值与融合前存在微小差异，最可能的原因是什么？

单选题 · extreme

  • A.融合改变了运算顺序的舍入← 正确答案
  • B.缓存命中变化改变了数学值
  • C.编译器版本号发生变化
  • D.模型文件名长度发生变化

答案：A。融合后中间结果不再写出，原先分步计算的舍入顺序改变，浮点结果会有微小偏差。缓存命中只影响速度不影响数值，编译版本与文件名对数值无影响。这提醒我们：语义等价允许容差，而不是要求位级一致。