想象一座刚刚验收的自动化中央厨房：切菜机只会切丁切丝，自动炒锅只会翻锅，蒸柜只会定时定温。这时你拿到一本米其林外文菜谱，上面写着“牛肉切 3 厘米见方”“大火翻炒两分钟”——设备认不出这些模糊动作，菜谱也听不懂设备语言。要让菜真正在这座厨房里做出来，必须有一个人：认出菜谱每一步是什么动作，指派给对的设备，合并冗余步骤，安排案板上的食材流转，用现有量勺替代克秤，再一遍遍试菜计时。这个人就是翻译总厨，而 TA 的工作，就是 NPU 编译。在这篇内容里，模型是菜谱，NPU 是只认固定动作的专用厨房，AI 编译器则是那位翻译总厨。我们将跟着 TA，看 PyTorch 模型如何一步步被改写成 NPU 芯片上的高效指令。

岗位关联

掌握 NPU 编译，等于掌握了模型部署的最后一公里：无论把大模型搬到昇腾、寒武纪，还是为端侧芯片做推理加速，你都能从底层看懂并优化整条软件栈——这是 AI 编译器与部署工程师的核心竞争力。

目录
  1. 可视化演示
  2. NPU架构特点
  3. 算子识别映射
  4. 内存数据调度
  5. 量化精度校准
  6. 图优化策略
  7. 主流编译框架
  8. 性能调优方法
  9. 兼容性适配
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

展示NPU编译工具链的完整流程：从模型前端解析到IR转换、图优化、算子映射、内存调度和代码生成，支持切换不同阶段视图。

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

NPU编译流程 前端解析→IR→优化→映射→调度→生成 INT8量化吞吐×4倍 SRAM << HBM → 搬运调度关键

NPU架构特点

先看这座中央厨房的“设备清单”：切菜机只会切丁切片切丝，自动炒锅只会翻锅，蒸柜只会定温蒸制。每台设备都极其擅长一件事，但都不认识“翻炒”这种模糊说法。NPU 就是这样的厨房——芯片里没有 CPU 那种通用运算器堆场，而是一排排专用卷积引擎、矩阵乘单元、激活单元和池化单元。PyTorch 模型要在这里跑，必须被改写成这些专用单元能执行的形态。

这种差异带来三个硬件特征。第一是指令集差异化：NPU 的一条指令往往就是一个算子的一个数据块（tile），粒度远大于 CPU 的“取数—运算—写回”微指令。第二是多核并行：模型按通道或 batch 切成小块，分给几十上百个计算核同时做。第三是片上缓存层级：SRAM 速度快但容量小，DDR 容量大但带宽有限。总厨必须先弄清每台设备的脾气，才谈得上翻译菜谱。

为了量化“一个算子到底适不适合在片上算”，我们用计算强度 R 来判断：

理解架构就是理解设备上限：切菜机刀口多宽、锅多大、案板多长。NPU 编译的所有后续步骤——映射、调度、量化、优化——都是在围绕这套硬件约束做文章。

R=CM\displaystyle R = \frac{C}{M}
  1. 计算量 C该算子一次前向需要的浮点运算次数，由特征图形状与卷积核大小决定。
    C=2×Hout×Wout×Cin×Cout×K×K\displaystyle C = 2 \times H_{out} \times W_{out} \times C_{in} \times C_{out} \times K \times K
  2. 访存量 M权重与输入输出特征图的总字节数，即需要从内存搬运的数据量。
    M=∣W∣+∣Ain∣+∣Aout∣\displaystyle M = |W| + |A_{in}| + |A_{out}|
  3. 计算强度 R每搬运 1 字节能完成的运算量。R 越高，算子越“怕计算不怕搬运”，越适合在 NPU 上跑。
    R=CM\displaystyle R = \frac{C}{M}

算子识别映射

现在总厨开始逐行读菜谱：“牛肉切 3 厘米块”→ 切菜机；“下锅大火翻炒”→ 自动锅；“摆盘”→ 装盘台。这就是算子映射：编译器扫描计算图里的每个算子（Conv、ReLU、MatMul…），在“支持矩阵”里找到对应的硬件原语。就像切菜机有不同的刀盘规格，每个硬件原语也有自己的数据布局和 shape 约束。

映射并不总是一对一。输入数据的排布方式不对时，要先插入布局转换（NHWC 与 NCHW 互转）；找不到原语时就要降级——把一个大算子拆成多个小原语组合，或者干脆回退到 CPU 执行。映射方案的好坏直接决定执行时间，因为 NPU 上每个算子的耗时可以拆成两段：

映射表就是那本“菜谱—设备对照手册”。总厨手上的手册越全，能直接落灶的步骤越多，需要临场发挥的降级就越少。

top=tcalc+tmove\displaystyle t_{op} = t_{calc} + t_{move}
  1. 计算耗时 t\_calc数据就绪后，硬件单元执行运算的时间，由单元算力决定。
    tcalc=CPunit\displaystyle t_{calc} = \frac{C}{P_{unit}}
  2. 搬运耗时 t\_move权重和激活从 DDR 搬到片上 SRAM 的时间，由总线带宽决定。
    tmove=MBbus\displaystyle t_{move} = \frac{M}{B_{bus}}
  3. 串行相加映射时两段都要压低，例如选择访存更友好的数据布局来缩小 M。
    top=tcalc+tmove\displaystyle t_{op} = t_{calc} + t_{move}

内存数据调度

操作台只有一张小案板，半成品不能全堆在上面。总厨得决定：葱姜先备、鱼片后切、做完立刻腾台。NPU 的内存调度就是给每个中间张量安排片上 SRAM 的位置和生命周期，并决定数据从 DDR 搬到 SRAM 的时机，目标是让搬运别挡住计算。

最经典的手段是双缓冲：准备两块缓冲，一块在搬下一批数据时，另一块正在被计算单元使用。这样“搬运”和“计算”像两条并行的流水线，互相掩护。大张量装不进 SRAM 时，还要做 tiling——把张量切成小块逐块处理；同时要小心内存 bank 冲突，避免多核同时访问同一存储体而互相踩踏。

双缓冲相当于把“等料→炒菜”改成“上一锅炒着、下一锅的料已经备好”。总厨再也不用站在灶前干等，厨房的出菜效率立刻上一个台阶。

Ttotal=n×max⁡(Tload,Tcompute)\displaystyle T_{total} = n \times \max(T_{load}, T_{compute})
  1. 单块搬运 T\_load一块数据从 DDR 搬入片上缓冲所需时间。
    Tload=MtileB\displaystyle T_{load} = \frac{M_{tile}}{B}
  2. 单块计算 T\_compute该块数据在计算单元上执行所需时间。
    Tcompute=CtileP\displaystyle T_{compute} = \frac{C_{tile}}{P}
  3. 双缓冲流水n 个数据块流水执行后，每块耗时由较慢的一侧主导，总时间近似为二者较大者乘以块数。
    Ttotal=n×max⁡(Tload,Tcompute)\displaystyle T_{total} = n \times \max(T_{load}, T_{compute})

量化精度校准

菜谱要求“盐 0.8 克”，可厨房只有 5 克和 10 克两种量勺。总厨先做了一锅实验，摸清这道菜的整体咸度范围，再选定一把误差最小的勺。量化就是这个思路：把 FP32 的权重和激活映射到 INT8 的整数台阶。直接截断会因个别极端值毁掉整体精度，所以要先在代表性输入（校准集）上统计数值范围，算出缩放因子 scale 和零点 zero point。

实践中还要选对称还是非对称量化、按整张张量还是按通道算 scale；对敏感层要保留 FP16——这就是混合精度策略。量化效果好不好，用 cosine similarity 或 SQNR 这类误差度量来验收。

量勺选对了，味道几乎不变，食材（内存占用）却省下四分之三。这就是为什么量化是 NPU 部署里性价比最高的一步。

q=round(xs)+z\displaystyle q = \mathrm{round}(\frac{x}{s}) + z
  1. 缩放因子 s校准集统计出的数值范围除以整数台阶数，决定每个台阶的“粒度”。
    s=xmax−xmin2b−1\displaystyle s = \frac{x_{max} - x_{min}}{2^{b} - 1}
  2. 零点 z让浮点 0 在整数域也有对应，避免非对称分布浪费台阶。
    z=round(−xmins)\displaystyle z = \mathrm{round}(-\frac{x_{min}}{s})
  3. 整数映射 q每个浮点值乘上缩放并取整，得到 INT8 表示；反量化时用 $\hat{x} = s \times (q - z)$ 还原。
    q=round(xs)+z\displaystyle q = \mathrm{round}(\frac{x}{s}) + z

图优化策略

总厨发现菜谱里“焯水”和“滑炒”之间，牛肉要先捞出来放凉再下锅——这纯属多余搬运。他把两步合并成“焯水后直接入锅”，半成品根本不用回案板。图优化就是在高层 IR 上做这类等价变换，最常见的算子是融合：Conv 的输出直接喂给 ReLU，中间张量不必写回 DDR，两者合成一个 FusedConv 算子。

图优化还包括常量折叠（把能提前算出的常量在编译期算掉）、布局转换（把整张图的张量统一成 NPU 友好的 NHWC）、并行切分（把算子按通道切到多个核上）。这些变换都要靠模式匹配加代价模型来驱动，目标是减少搬运、提高核利用率。

融合不是越多越好——压得太狠会挤爆片上存储、降低并行度。总厨的原则是：省掉多余的来回，但不让任何一台设备闲等。

r=1−MfusedMorig\displaystyle r = 1 - \frac{M_{fused}}{M_{orig}}
  1. 融合前访存 M\_orig两个算子各自把中间结果写回内存再读出来，访存量是二者之和。
    Morig=Ma+Mb\displaystyle M_{orig} = M_{a} + M_{b}
  2. 融合后访存 M\_fused中间激活留在片上寄存器或缓冲里，不再进出 DDR。
    Mfused=Ma+Mb−2×∣Amid∣\displaystyle M_{fused} = M_{a} + M_{b} - 2 \times |A_{mid}|
  3. 访存减少率 r衡量融合省下的搬运比例，r 越大说明优化越显著。
    r=1−MfusedMorig\displaystyle r = 1 - \frac{M_{fused}}{M_{orig}}

主流编译框架

餐饮集团有三本手册：总部发的《通用操作手册》是 TVM，中央厨房自编的《专岗手册》是 CANN，主厨随手记的《快手菜本》是 Triton。三本手册服务同一个目标——把外文菜谱改写成这座厨房能执行的指令。TVM 是开源端到端编译器：前端吃进 PyTorch/ONNX 模型，中间用 Relay/TIR 做图优化和调度搜索，后端生成目标代码，可移植到多种芯片。CANN 是华为昇腾的异构计算架构，包含图引擎 GE、AscendCL 运行接口和配套算子库，深度绑定昇腾硬件做商业级优化。Triton 则允许你用类 Python 的 DSL 编写算子 kernel，编译器自动映射到 GPU/NPU 原语，开发效率高，特别适合探索新算子。

三者的编译流程殊途同归：解析前端模型 → 构图与算子映射 → 图优化 → 内存调度 → 代码生成。选哪本手册，取决于你手里是哪座厨房、要应付什么菜。部署完成后，总厨要用一个数字汇报成果——加速比：

手册是死的，总厨是活的。真正决定加速比的，还是能不能把映射、融合、调度、量化这四板斧组合到位。

S=TbaseTnpu\displaystyle S = \frac{T_{base}}{T_{npu}}
  1. 基线耗时 T\_base同模型在 CPU/GPU 或未优化图上的执行总时间。
    Tbase=∑iti\displaystyle T_{base} = \sum_{i} t_{i}
  2. NPU 编译后耗时 T\_npu经过映射、融合、调度后的执行总时间。
    Tnpu=∑iti′\displaystyle T_{npu} = \sum_{i} t'_{i}
  3. 加速比 SS 大于 1 代表 NPU 更快，是部署汇报中最直观的指标。
    S=TbaseTnpu\displaystyle S = \frac{T_{base}}{T_{npu}}

性能调优方法

总厨上菜前要先试菜：哪一道最慢？是灶火不够旺，还是备菜太慢？改一次试一次，直到整条流水线没有闲人。NPU 性能调优的第一步是用 profiler 量出每个算子的耗时、访存耗时、核利用率和“气泡”（等待时间）。瓶颈通常分三类：计算受限（算力到顶）、访存受限（带宽被吃满）、并行度不足（核没被喂饱）。

判断受限类型可以用 roofline 模型：把算子的计算强度 R 画在图上，和芯片的“拐点”比较，就知道该优化计算还是优化搬运。接下来，可以用自动调优工具（如 TVM 的 Ansor）在 tiling 切块大小、循环顺序、向量化宽度等维度上自动搜索，也可以手动一次只改一个变量做对比实验。

调优是一个“测—改—再测”的循环。总厨的耐心有限，所以要优先处理占比最大的那几道菜，而不是纠结无关紧要的小环节。

U=PactualPpeak\displaystyle U = \frac{P_{actual}}{P_{peak}}
  1. 峰值算力 P\_peak芯片理论最大运算速度，由主频、MAC 单元数量和并发度决定。
    Ppeak=fclk×Nmac\displaystyle P_{peak} = f_{clk} \times N_{mac}
  2. 实际算力 P\_actualprofiler 统计出的有效运算量除以墙钟时间。
    Pactual=FLOPsdoneTwall\displaystyle P_{actual} = \frac{FLOPs_{done}}{T_{wall}}
  3. 利用率 UU 偏低说明存在气泡——搬运等待、并行度不足或融合不够，都是调优的下手点。
    U=PactualPpeak\displaystyle U = \frac{P_{actual}}{P_{peak}}

兼容性适配

菜谱里突然出现一道“分子料理”，厨房没有对应设备。总厨的应对顺序是：先换家常做法（用已有算子等价替换）；换不了就把这一步外包给隔壁小灶（CPU fallback）；再不行就请钳工现做专用工具（自定义算子）。算子缺失是 NPU 部署最常见的坑。查支持矩阵、找等价组合、CPU 兜底，最后才轮到自定义算子开发——编写算子的 compute 描述与 schedule，注册进 TVM 或 CANN 工具链，再做单元测试。

版本兼容同样重要：驱动、框架、算子库的版本必须匹配，模型里的小版本算子（如某个自定义 NMS 变体）也要逐一验证。适配完成前，跑一遍全量算子测试与精度对比，确认输出和原始模型一致。

覆盖率不必强求 100%。热路径上的算子全在片内、边缘算子有兜底，这桌菜就能顺利开张。总厨要的是“整桌菜出得来”，而不是“每道菜都有专用设备”。

Ccov=NokNtotal\displaystyle C_{cov} = \frac{N_{ok}}{N_{total}}
  1. 总算子类型数 N\_total模型去重后的算子类型集合大小。
    Ntotal=∣{Conv,ReLU,Pool,… }∣\displaystyle N_{total} = |\{ \text{Conv}, \text{ReLU}, \text{Pool}, \dots \}|
  2. 已支持算子数 N\_ok能在 NPU 上高效执行、有硬件原语对应的算子类型数。
    Nok=∣Ssupported∣\displaystyle N_{ok} = |\mathbf{S}_{supported}|
  3. 覆盖率 C\_cov覆盖率越高，模型越“原生可跑”；剩余部分靠降级与自定义算子补齐。
    Ccov=NokNtotal\displaystyle C_{cov} = \frac{N_{ok}}{N_{total}}

AI 应用场景

大模型推理上昇腾

阶段：模型部署与推理优化

解决的问题：大语言模型参数动辄几十上百亿，直接用 PyTorch 在 CPU/GPU 上推理，算子调度零散、访存浪费严重，吞吐上不去。传统手写服务端逻辑又不懂芯片底层，无法榨出 NPU 的性能。

具体案例：某团队把 7B 对话模型迁移到昇腾 910B：用 CANN 做静态图编译、算子映射与融合，对权重做 INT8 量化，再对 KV Cache 做内存调度优化。最终首 token 延迟下降 40%，整体吞吐提升 2.3 倍。

车载视觉模型移植

阶段：算子适配与自定义开发

解决的问题：YOLOv8 里的自定义 NMS 变体在 NPU 支持矩阵中缺失，直接转换会报“算子不支持”而失败；换模型又伤筋动骨。需要按映射—降级—自定义的路径逐层解决。

具体案例：把 YOLOv8 移植到地平线征程系列芯片：先用“矩阵运算 + 排序”等价替换部分算子，再对瓶颈 Decode 核编写自定义算子并注册进工具链，最后对残留子图做 CPU fallback。端到端推理稳定在 30ms 以内，通过车规验收。

推荐系统稀疏模型压缩

阶段：内存调度与量化压缩

解决的问题：DLRM 等推荐模型的 Embedding 表巨大，塞不进片上 SRAM。传统做法要么直接爆内存，要么频繁访问 DDR 导致延迟飙升。

具体案例：用编译器把 Embedding 表按行分片：热点表放 SRAM、冷门表走 DDR 预取，再配合 INT8 量化把表压缩四倍。线上推荐服务的 p99 延迟减半，单机 QPS 翻倍。

Python 演示

python82 行
# -*- coding: utf-8 -*-"""迷你NPU编译器:把一张简单的算子图翻译成虚拟NPU指令。"""  class MiniNPU:    def __init__(self):        self.unit_map = {            'Conv': 'CONV_ENGINE',            'MatMul': 'MMA_UNIT',            'ReLU': 'ACT_UNIT',            'Add': 'ACT_UNIT',            'Pool': 'POOL_UNIT',        }        self.instructions = []        self.mem_used = 0        self.total_mem = 8192     def _fuse(self, graph):        """图优化:相邻的Conv+ReLU融合成一个FusedConv节点。"""        fused, i = [], 0        while i < len(graph):            if i + 1 < len(graph) and graph[i]['type'] == 'Conv' and graph[i + 1]['type'] == 'ReLU':                node = dict(graph[i])                node['type'] = 'FusedConv'                node['extra'] = 'ReLU'                fused.append(node)                i += 2            else:                fused.append(graph[i])                i += 1        return fused     def _quantize(self, node):        """量化校准:根据数值范围计算int8的scale。"""        lo, hi = node.get('min', 0.0), node.get('max', 1.0)        node['scale'] = round((hi - lo) / 255.0, 6)        node['dtype'] = 'int8'        return node     def _schedule(self, node):        """内存调度:累计片上占用,小流量双缓冲,大流量直通。"""        self.mem_used += node.get('tensor_mb', 2)        node['stage'] = 'double' if self.mem_used < self.total_mem * 0.75 else 'direct'        return node     def _codegen(self, node):        """代码生成:按硬件单元发出一条类汇编指令。"""        unit = self.unit_map.get(node['type'], 'GENERIC_UNIT')        self.instructions.append('{:10s} {:10s} scale={}'.format(unit, node['type'], node['scale']))        return node     def compile(self, graph):        """完整流水线:识别->融合->映射->量化->调度->生成。"""        fused = self._fuse(graph)        fused_types = [n['type'] for n in fused]        for n in fused:            self._quantize(n)            self._schedule(n)            self._codegen(n)        return fused_types, self.instructions  def main():    graph = [        {'type': 'Conv', 'min': -6.0, 'max': 6.0, 'tensor_mb': 4},        {'type': 'ReLU', 'min': 0.0, 'max': 6.0, 'tensor_mb': 4},        {'type': 'Pool', 'min': 0.0, 'max': 6.0, 'tensor_mb': 2},        {'type': 'MatMul', 'min': -3.0, 'max': 3.0, 'tensor_mb': 6},        {'type': 'Add', 'min': -6.0, 'max': 6.0, 'tensor_mb': 2},    ]    npu = MiniNPU()    fused_types, code = npu.compile(graph)    print('origin ops:', [n['type'] for n in graph])    print('fused ops:', fused_types)    print('instructions:')    for ins in code:        print(' ', ins)    print('mem used: {} MB / {} MB'.format(npu.mem_used, npu.total_mem))  if __name__ == '__main__':    main()
目的：在 Python 里搭一个极简版 NPU 编译器，演示“算子识别→融合→量化→调度→代码生成”的完整流水线，并输出融合后的算子列表和虚拟指令。
  1. if i + 1 < len(graph) and graph[i]['type'] == 'Conv' and graph[i + 1]['type'] == 'ReLU':图优化用模式匹配找到可融合的算子对，像总厨扫一眼菜谱就认出“焯水后滑炒”这种可合并步骤。
  2. node['type'] = 'FusedConv'把两个相邻算子打包成一个新算子，中间激活不再写回内存。
  3. lo, hi = node.get('min', 0.0), node.get('max', 1.0)量化校准的输入：从校准统计里取出数值范围。
  4. node['scale'] = round((hi - lo) / 255.0, 6)按 INT8 的 256 个台阶计算缩放因子，相当于选量勺。
  5. self.mem_used += node.get('tensor_mb', 2)内存调度累计片上占用，防止数据总量超过 SRAM。
  6. node['stage'] = 'double' if self.mem_used < self.total_mem * 0.75 else 'direct'空间够用就启用双缓冲，紧张时改直通模式。
  7. unit = self.unit_map.get(node['type'], 'GENERIC_UNIT')查映射表；查不到就落到通用单元，等价于真实世界的自定义算子或降级路径。
  8. fused_types, code = npu.compile(graph)一条命令跑完整个编译流水线，输出融合结果与指令序列。
  9. print('fused ops:', fused_types)验证卷积和 ReLU 确实被融合成了一个节点。

常见误区

误区NPU 编译不就是格式转换吗？把 .pt 导出成 .onnx，再转成昇腾的 .om 文件就完事了，剩下全是芯片自己干的。

正解格式转换只是第一步入口。真正的性能来自算子映射、图优化融合、内存调度（双缓冲/tiling）和量化校准。同一个模型，瞎转换和精心编译可能差出十倍速度。编译是“翻译 + 排产 + 试菜”一体化的工程，绝不是换个文件后缀。

为何常见：现代工具链封装得太傻瓜——一条命令行就能导出，掩盖了背后庞大的编译器流水线。

误区量化就是把 float32 的权重直接截断成 int8，省内存不就行了？数值变小一点，精度差一点也可以接受。

正解直接截断会因为个别极端值把整体分布毁掉，模型可能直接失效。正确做法是先用校准集统计数值范围，再算 scale 和 zero point，必要时对敏感层做混合精度。就像不能拿 5 克的勺子硬舀 0.8 克的盐，得先知道这道菜的整体咸度。

为何常见：“减小数据类型”在直觉上就是截位，容易忽略量化是一个需要统计和校准的过程。

误区图优化里的算子融合能减少访存，那当然是能融合就融合，越多越快。

正解融合减少搬运，但会增加片上寄存器/缓冲占用，降低并行度，甚至引入数据依赖让多核空转。当带宽充足、核数很多时，过度融合反而更慢。要用代价模型和实测数据决定融合范围。

为何常见：“少搬数据一定快”的直觉在访存不是瓶颈的场合会失效。

误区NPU 只认自家框架，PyTorch 模型必须用 C++ 或专用语言重写一遍才能部署上去。

正解借助 TVM 的前端导入器和 CANN 的模型转换工具，绝大多数 PyTorch/ONNX 模型可以自动转换并编译。只有支持矩阵缺失的算子才需要改写或自定义开发。重写是最后手段，不是默认流程。

为何常见：早期 NPU 生态不成熟，确实经常要手工改模型，给人留下了“必须重写”的刻板印象。

误区支持矩阵必须 100% 覆盖模型里所有算子，否则这模型就废了，没法上 NPU。

正解部署关心的是正确性、精度和性能。少量低频算子缺失，可以用已有算子组合等价替换、CPU fallback 或自定义算子补偿。覆盖率只是参考指标，热路径算子的性能才是关键。

为何常见：把厂商的“算子支持矩阵”表格当成了唯一的硬性标准，忽略了编译器的降级和自定义能力。

面试题

Q1. NPU 之所以需要专属编译器，最主要的原因是？

单选题 · easy

  • A.NPU 无法运行任何 Python 代码
  • B.NPU 的硬件单元与指令集高度专用← 正确答案
  • C.PyTorch 编译器对 NPU 完全不兼容
  • D.NPU 只能执行 C++ 编写的程序

答案：B。NPU 内部是卷积引擎、矩阵乘单元等专用硬件，指令粒度大且高度定制，通用框架无法直接生成高效指令，所以需要专属编译器做映射与调度。Python 能否运行、是否兼容 C++ 都不是根本原因。

Q2. 算子映射的核心任务是？

单选题 · easy

  • A.把计算图节点匹配到硬件原语← 正确答案
  • B.把模型权重转成二进制文件
  • C.把数据集预处理为张量格式
  • D.把训练日志整理成报表输出

答案：A。算子映射就是为计算图里每个节点在硬件原语库里找匹配实现，像总厨给每道菜指派设备。权重转格式、数据预处理、日志整理都不是编译器的映射职责。

Q3. 算子融合（如 Conv+ReLU）带来的主要收益是？

单选题 · mid

  • A.减少中间张量的搬运与写回← 正确答案
  • B.增加模型的可训练参数量
  • C.降低量化校准所需样本数
  • D.提升训练时的梯度收敛速度

答案：A。融合让中间激活留在片上，不必写回 DDR 再读出来，核心收益是减少访存。参数量、校准样本、梯度收敛都和算子融合无关。

Q4. 关于双缓冲（double buffering），正确说法是？

单选题 · mid

  • A.用两份缓冲让搬运与计算重叠← 正确答案
  • B.用两份权重备份防止数据丢失
  • C.把训练集复制两份加速加载
  • D.将激活值缓存两份以省内存

答案：A。双缓冲的核心思想是一块缓冲在搬运下一批数据、另一块在供计算使用，让两个环节像流水线一样重叠。它不是为了备份、复制训练集或省内存，而是掩盖访存延迟。

Q5. 量化校准中 scale 的计算依赖什么？

单选题 · mid

  • A.校准集上统计的数值范围← 正确答案
  • B.训练时使用的随机种子
  • C.模型的参数量大小
  • D.数据集的类别总数

答案：A。scale 由校准集上统计出的最大最小值除以整数台阶数得到，所以校准集要能代表真实部署分布。随机种子、参数量和类别数都不参与 scale 计算。

Q6. 关于 TVM、CANN、Triton 的描述，正确的是？

单选题 · mid

  • A.CANN 是华为昇腾芯片的软件栈← 正确答案
  • B.TVM 只能用于英伟达显卡
  • C.Triton 是一个数据集格式
  • D.三者都无法做算子融合

答案：A。CANN 是昇腾的异构计算架构，包含图引擎和算子库；TVM 是开源且可移植到多芯片的编译器；Triton 是类 Python 的 kernel 描述语言。三者都支持算子融合，B、C、D 均错误。

Q7. 下列哪些属于 NPU 编译流程的环节？

多选题 · mid

  • A.算子映射与降级← 正确答案
  • B.内存调度与访存优化← 正确答案
  • C.量化校准与混合精度← 正确答案
  • D.数据清洗与特征工程

答案：ABC。编译流程包含算子映射、图优化、内存调度、量化校准、代码生成等环节。数据清洗与特征工程属于训练前的数据处理，不在编译范围内。

Q8. 模型在 NPU 上遇到算子缺失，合理的处理手段有哪些？

多选题 · hard

  • A.用多个已有算子组合等价替换← 正确答案
  • B.对该子图回退到 CPU 执行← 正确答案
  • C.编写自定义算子并注册到工具链← 正确答案
  • D.随机更换模型结构放弃该算子

答案：ABC。按成本从低到高依次是：等价组合替换、CPU fallback、自定义算子开发。随机更换模型结构会破坏模型语义，不是合理手段。

Q9. 性能剖析发现某算子的计算强度 R 很低（访存量远大于计算量），其瓶颈最可能是？

单选题 · mid

  • A.内存带宽不足导致访存受限← 正确答案
  • B.计算单元频率过低导致算力受限
  • C.编译器优化导致指令冗余
  • D.算子本身输出通道过多

答案：A。R 低意味着每搬运一个字节只有很少运算，这类算子通常被内存带宽卡住，属于访存受限。算力受限恰好对应 R 高的情况，指令冗余和输出通道多都不是 R 低的直接瓶颈。

Q10. 对 NPU 编译结果做性能调优，常用手段包含？

多选题 · hard

  • A.修改 tiling 切块大小与循环顺序← 正确答案
  • B.调整算子融合与布局转换策略← 正确答案
  • C.使用自动调优搜索调度方案← 正确答案
  • D.增大训练时的 batch 提高精度

答案：ABC。tiling、循环顺序、融合策略、布局转换和自动调优都是编译层面常用的调优手段。增大训练 batch 属于训练环节，与 NPU 编译调优无关。