企业官网建设流程全解析

一个 NPU 编译后端真正难做的，不是把算子的计算逻辑翻译成指令，而是在翻译的过程中把所有硬件约束都处理好：数据该怎么排、缓存怎么复用、指令流水怎么穿插、哪一层融合值得做、哪一层做了反而更慢。ATVOSS 这套面向 NPU 的 TVM 编译后端与张量优化系统，解决的就是这个问题。它不是一个简单的“把 Relay 图往下拧几圈”的代码生成器，而是把调度决策、内存布局、算子融合和指令生成串成一个整体流程，让模型在跑上 NPU 之前，就已经按照硬件的脾气把计算重新组织过一遍。

这篇文章把 ATVOSS 的设计思路、核心模块和实际调试过程拆开讲一遍。适合两类人看：一类是刚接触 NPU 编译，想知道 TVM 后端到底在做什么的；另一类是自己也在搭类似后端，想看看别人在算子调度、 tiling、数据排布上是怎么踩坑和收口的。

1. ATVOSS 是什么？——NPU 编译为什么需要独立后端

1.1 NPU 和 GPU 在编译上面到底差在哪

很多人会把 NPU 编译简单理解成“编译器把算子变成芯片驱动能读的指令”，但如果真这么做，性能会很难看。NPU 和 GPU 的结构差异决定了编译器的优化重点完全不同。

GPU 本质上是一个通用并行处理器，计算核心很多但单个核心不复杂，它靠大量线程并行来掩盖访存延迟，编译层面主要关注并行度、向量化、以及尽量让相邻线程访问相邻内存。编译器可以相对放心地把调度决策交给运行时，因为硬件本身有很成熟的线程调度机制来兜底。

NPU 不一样。很多 NPU 的算力来自脉动阵列或者类脉动结构，矩阵乘法和卷积会被拆成大量乘累加操作映射到计算阵列上。这个阵列的计算节奏完全由数据流动方式和控制信号决定，片上内存通常是一个紧挨着计算阵列的 SRAM，容量有限但访问带宽极高，外部 DRAM 的访问带宽则相对小得多。这样一来，编译器的核心工作就不是“把算子翻译成指令”，而是“决定什么数据、以什么顺序、在什么时间点放到片上”，让计算阵列持续跑满。

我把这个区别总结成一张表，方便对照：

ATVOSS 在电视节目生态里的定位，就是为了把 TVM 相对通用的编译流水线落到一个具体的 NPU 上，同时补上通用后端根本没覆盖的那些东西——数据排布选择、片上缓冲管理、特殊指令生成、以及一整套针对 NPU 内存模型的调优手段。

1.2 ATVOSS 在 TVM 生态里的角色

TVM 本身有比较清晰的层次：最上层是 Relay，负责图级别优化和算子融合；中间层是 TIR，负责循环变换、向量化、tiling 这类底层计算描述；再往下是 codegen，把 TIR 变成 CPU/GPU 能执行的代码。

对多数通用架构，TVM 自带的 codegen 已经足够。但 NPU 往往不是简单用 C 语言就能描述的，很多指令是显式的数据搬移指令、barrier 同步指令、矩阵计算指令，这些指令需要编译器专门生成。ATVOSS 做的事情，就是把“图优化之后的 Relay 算子”变成“目标 NPU 上真正可以跑的指令序列”，并且在这个过程中把调度决策做掉。

它在 TVM 生态里的角色可以拆成三层看：

• 算子层：识别 Relay/TIR 里的卷积、矩阵乘、激活、池化等算子，匹配到 NPU 上可用的计算指令。
• 调度层：针对 NPU 的存储层次，重新设计循环顺序、分块大小、数据流水方式。
• 代码生成层：最终生成目标 NPU 的指令序列，并且把中间计算产生中间缓冲区的情况管理好。

这三层不是脱节的。调度的结果直接影响代码生成，代码生成时发现的指令约束又会反向影响调度策略的选择。ATVOSS 把这三层放在一起考虑，所以它更像一个“张量优化系统”，而不是一个单纯的“指令生成器”。

1.3 它能做什么、不能做什么

先说能做什么。ATVOSS 可以完整替代 TVM 默认的 C/OpenCL 目标，把编译后的模型跑到 NPU 上；它可以对图做算子融合，比如把卷积和后面的激活、归一化融合成一个指令序列；它可以灵活调整数据排布，在输入输出和中间计算之间自动插入转置操作；它还可以对同一个算子尝试多种 tiling 策略，然后根据后端代价模型选择其中最合适的一种。

还有一点容易被忽略但很实用：ATVOSS 通常带一个分析工具，可以统计计算图里每次数据搬移的字节数、片上缓存占用、算子之间的数据重排开销。这些数据在性能调优时非常关键，没有它们你只能靠猜。

不能做什么，同样要认识清楚。ATVOSS 不会帮你自动提升模型精度，量化、蒸馏这类工作要单独做。它也不会自动把你的任何模型都编译得很好——遇到非常规算子，比如某种自定义的池化变体，它可能回退到通用实现，性能就会打折扣。你给它一个图，它能做的是尽量在固定硬件约束下把执行计划逼近最优，但前提是算子本身已经被降到了它认识的范围里。

2. 整体设计思路：为什么把“张量优化”单独拎出来做

2.1 编译流水线拆解

了解 ATVOSS 怎么工作，可以先看一遍它的完整编译流程。

第一步是前端解析。各种框架导出的模型，经过转换器变成 Relay 表示。这里模型通常是用 ONNX 或者 TFLite 格式导入，经过 Relay 的 pass 系列，完成常量折叠、死代码消除、形状推断这类基础优化，把图整理成一个更干净的中间表达。

第二步是算子落到 TIR。Relay 里的每个算子会被映射为计算函数，比如nn.conv2d会变成一个嵌套循环并声明对输出张量的计算定义。这一步对 CPU/GPU 来说更像是“规则展开”，但 ATVOSS 在这里往往要额外做一件事：判断这个算子到底应该用通用 TIR 描述，还是直接切换到一个已经内置好的 NPU 实现模板。

第三步是调度变换。TIR 提供了循环分块、向量化、并行化、流水线化这些基础能力，ATVOSS 基于这套能力实现自己的调度策略。它不只用 TIR 的通用调度原语，而是针对 NPU 的存储结构设计了一套类似“外层循环切块到片上，内层循环驱动计算阵列”的模式。

第四步是代码生成。TIR 经过调度之后，逐语句转换成 NPU 指令。这一层最重要的不是“翻译”的正确性，而是要让指令排列顺序和同步方式满足硬件的规则，比如计算指令之前必须已经有数据放到位、矩阵指令之间需要插入 barrier 等。

从全局来看，ATVOSS 的优化动作更多发生在第一和第三步，越靠后越忙于处理细节约束。很多时间复杂度高的问题，比如对整体数据搬移量的估算，必须在图优化阶段提前考虑，否则走到调度阶段会发现数据结构已经定死了，再调也没用。

2.2 张量优化的核心矛盾：访存调度 vs 计算排布

NPU 上最容易出现的性能问题不是计算不够快，而是计算阵列等数据。

举一个具体场景。某款 NPU 的矩阵乘单元在某个频率下每秒可以算上万亿次乘累加，外部 DRAM 的访问带宽可能只有每秒几十 GB。一次输出大小为 128x128 的矩阵乘，如果完全没有数据复用，需要搬到片上的数据量可能是几十 KB，按带宽算访存时间已经不小。真正的问题是，计算时间远小于访存时间时，计算单元大部分时间在空转。

所以 ATVOSS 在张量优化里第一个考虑的问题是：数据复用率够不够。一个卷积核在一个通道上滑动时，权重数据可以被多个输出位置重复使用；一块输入数据可以被多个输出通道重复使用。编译器必须把这些复用关系变成片上内存里的固定布局，防止同一块数据反复从外部 DRAM 拿。

第二个考虑的问题是：数据以什么排布进入计算阵列。很多 NPU 对输入和权重的数据排布有硬性要求，比如矩阵乘一侧需要数据按 K 维连续存放，卷积的输入可能需要在片上先做一个 im2col 式的重排。这个重排不能放在指令序列里随便做，因为它会引入额外访存，必须先判断这个重排对上层的图改动有多大，能不能提前做掉。

第三是流水线的穿插。数据搬移和计算之间必须用双缓冲或者类似机制隐藏访存延迟。ATVOSS 调度器的不少工作，其实就是在反复回答这种问题：这一块数据要不要提前一个循环迭代加载？片上缓冲区够不够同时放下正在计算的数据和下一块要搬进的数据？如果不够，循环分块应该怎么调整？

这几件事单独看都还好，但它们互相牵扯。tiling 大小会影响数据复用率，数据复用率影响缓冲区排布，缓冲区排布又影响能否双缓冲。这也是为什么调度器很难用一个简单启发式一把梭，只能在约束空间里遍历候选方案再代入代价模型。

2.3 设计取舍：通用自动调度与专用后端的边界

用 TVM 的人都知道，Ansor 和 AutoTVM 这类自动调度器在 CPU/GPU 上很有效，它们在一个又一个搜索空间里尝试不同的循环变换组合，然后靠实测或预测模型挑一个快的。ATVOSS 没有直接全盘照搬这套，而是选择了“在通用自动调度框架里做一套 NPU 专用模板”的路线。

这个取舍背后是有原因的。NPU 的指令集和内存模型不像 GPU 那样能被 OpenCL/CUDA 这类抽象完全盖住，很多 NPU 的矩阵乘指令是直接操作某个固定尺寸的数据块，循环变换只是在数据怎么喂给这个固定尺寸块上做文章，搜索空间比 GPU 小得多。与其在一个通用搜索空间里乱撞，不如把这几个固定尺寸的指令用模板固化下来，再在模板参数上做搜索，比如每个维度的分块大小、流水深度、数据重排策略。

这个设计带来的好处是鲁棒性显著提升。生成优化后的卷积基本不会产生内存访问越界或者数据竞争，因为模板已经通过正确性验证，搜索只发生在参数维度上。代价也很明显，遇到新的算子结构，比如非对称 padding 的卷积、混合精度的矩阵乘，模板来不及覆盖就只能回退，需要人工介入设计新模板。

我的看法是，这个取舍对于目标明确的量产芯片后端是对的。通用自动调度的价值在于无人干预的泛化能力，但当硬件形态趋于固定，且你有足够多的时间为每种典型算子打磨模板时，专用模板的收益更容易控制。ATVOSS 保留了通用调度器作为保底路径，但把性能的大量提升都寄托在专用模板上，这和很多工业级后端的做法其实是一致的。

3. 核心细节与实操要点：算子降低与张量优化怎么做

3.1 算子降低：从图 IR 到 NPU 指令的路径

算子降低是后端里最容易出错的一层。它的输入是一个已经完成图优化的 Relay 函数，输出是一段明确指定了数据缓存位置、计算循环顺序和指令类型的 TIR 代码。

最常见的降算子是卷积。把nn.conv2d往下降低，不是一个单一的循环展开，而是包含三个层次的选择：

第一，卷积怎么实现。可能的选择有直接卷积、基于矩阵乘的高效实现、基于 FFT 的变换实现、以及 NPU 硬件直接支持的某种二维计算指令。大多数 NPU 上有专门的卷积指令或者很好映射的矩阵乘指令，直接卷积往往不会是最优方案。ATVOSS 的算子模式匹配器会扫描这个卷积的特征——kernel size、stride、dilation、通道数，然后决定走哪条实现路径。

第二，如果是走矩阵乘映射，输入数据需要重排。卷积的滑动窗口展开成矩阵乘法，生成一个隐含了更大存储消耗的虚拟视图。理想情况下这个重排应该发生在把数据放到片上之后，而不是在外部 DRAM 里先铺一个大矩阵。ATVOSS 在降低时会把重排表达成对数据张量的一个 layout 变换操作，让后续调度器来决定具体插在哪个位置。

第三，计算精度和指令类型的选择。NPU 常常同时支持 fp16 和 fp32 的指令，有些还支持 int8/int16 的量化计算。算子降低的时候会根据输入输出的精度，以及目标指令对精度的适配情况，选择对应的指令。

这个流程可以简化成一段伪代码，便于理解：

def lower_conv(op, target_npu): if match(op, "conv2d", (n, c, h, w), k_h, k_w, stride, pad): if target_npu.has_conv2d_hw_accel(k_h, k_w): plan = plan_conv_implicit_gemm(op) else: plan = plan_conv_as_matmul(op) plan.set_layout("NHWC") # 根据后端偏好 plan.tile(input_dims=(tile_n, tile_h, tile_w, tile_c)) plan.pipeline(stage_count=2) # 双缓冲 return plan.to_tir()

这套逻辑写起来不复杂，难在分支太多。任何一个分支没覆盖到，算子就掉回通用实现，性能立刻回到一个不可接受的水平。所以算子库维护者在增加新 NPU 支持的时候，主要工作量永远在扩充匹配模板。

3.2 数据排布与内存布局策略

很多第一次做 NPU 移植的人会在这里栽跟头：明明 TIR 代码里的循环逻辑都对，编译出来的程序也能跑，性能就是上不去。一查发现，数据在外部 DRAM 里的排列方式和计算阵列要求的不匹配，每次计算前都要先做一次整体转置。

数据排布对 NPU 性能的影响很大，我甚至愿意说它是决定成败的那一个细节。同样的卷积算子，如果输入从 NCHW 切成 NHWC，那么对于很多以矩阵乘为底层的 NPU 来说，访存连续性会有数量级的提升，因为输出的通道维和空间维在地址空间里的相对位置发生了变化。

但这不代表总是要选 NHWC。实际上最优排布取决于算子和数据在哪个维度上做复用。比如第一层卷积的输入是图像，通道数少，空间尺寸大，此时用 NHWC 更自然；中间层通道数变多，可能在 NCHW 下做通道维的连续访问更好。ATVOSS 的做法是在每一层的边界上做排布选择，也就是说，同一份计算结果给上一层用是一种排布，给下一层用可能就切成另一种排布，中间插入必要的转换操作。

实操中我总结一个重要经验：排布转换本身也是访存开销，不能无脑插。除非转换可以融合到上一个算子或者下一个算子的计算过程中，否则一个 100MB 的中间张量做一次排布转换，代价可能抵消掉你在计算指令上优化的全部收益。

所以 ATVOSS 里有一类 pass 专门做 layout 规划。它先推断每个算子的输入输出最合适的排布，然后沿计算图传递这个排布偏好，最后在排布偏好冲突的地方插入 layout 变换，并尝试把变换折叠到相邻算子的实现里。

3.3 循环分块与流水线调度

循环分块很容易被理解为“把大循环切成小块”，但在 NPU 后端，它的真正目的是让片上 SRAM 的内容可复用，同时给数据搬移创造流水机会。

拿一个典型的卷积循环来看。外层循环是 batch 和输出通道，中间是输出位置循环，内层是输入通道和 kernel 循环。如果不做 tiling，整个计算过程需要把输入特征图整个搬进片上，这几乎不可能；即使放得下，数据也不会被充分复用。

ATVOSS 的调度器通常会在三个维度做 tiling：输出通道块、输出空间块、输入通道块。切完之后，一个片上缓冲区块对应的计算任务是：读取一小块输入和一小块权重，计算出一小块输出，再把这小块输出写回外部 DRAM。

这时可以引入双缓冲。具体做法是准备两块片上缓冲区 A 和 B。当前用 A 里的数据做计算时，DMA 已经往 B 里搬运下一块数据；下一次迭代切换到 B 做计算，DMA 再往 A 里搬新数据。这样一来，外部 DRAM 的访存延迟被计算时间盖住了，只要计算时间大于数据搬移时间，流水就不会断开。

关键参数有两个：一个是片上缓冲区大小，另一个是每次搬移的数据块大小。缓冲区太大可能被操作系统拒绝或者放不下其他临时数据，太小则流水切换太频繁，DMA 启动开销占比过高。

实际做调度时我会先定一个保守的初值，比如把片上 SRAM 的一半留给双缓冲，然后分别把三个维度从 1 开始往上试探。对于一个常见尺寸的卷积，最优的 tiling 往往是让单个输出块的计算时间略大于一次 DMA 搬移时间，这样流水刚好无缝衔接，又不会为了追求无缝而让缓冲区大到不必要的程度。

3.4 计算图优化：算子融合与冗余消除

算子融合在图优化阶段就已经开始了，但 NPU 后端的融合思路和 GPU/CPU 略有不同。CPU/GPU 融合主要想节省内核启动开销和中间张量的读写；NPU 融合更多是省掉一次中间数据的外部 DRAM 往返。

这个差异非常重要。GPU 上中间张量可能留在缓存里，不一定要落回显存；NPU 的片上内存是显式管理的，中间张量一旦不能停留在片上，就必须写回 DRAM，下一算子再从 DRAM 读出来。一次不必要的写回+读取，可能比计算本身还贵。

ATVOSS 的融合逻辑会优先处理三类模式：

• 激活融合：conv2d + relu、matmul + gelu这类，直接嵌到计算指令的 epilogue 位置，不产生单独的输出张量。
• 归一化融合：conv2d + batch_norm或conv2d + layer_norm，把归一化的缩放和偏移参数先折算到前一个算子的权重和偏置里。
• 元素级算子连乘：几个 elementwise 算子合并成一个，中间结果全部留在片上。

融合之后，计算图里会出现一些不再被引用的张量，以及一些只产生中间值的算子，冗余消除 pass 会把这些清理掉。特别是融合会导致某些输入通道不再被下一层单独引用，那么层间重排就可能被省掉。

融合也不是越多越好。有一个常见误区是试图把所有东西都塞进一个融合算子里，结果片上缓冲区放不下，反而触发额外的 spill。ATVOSS 在融合时会在片上内存预算内做收益判断，如果融合后的缓冲区超出预算，它宁可保留两次写回也绝不硬融。

4. 实操过程：把一个模型编译到 ATVOSS 后端

4.1 环境准备与工具链

我这里以 Linux 环境为例。ATVOSS 是 TVM 的一个扩展后端，编译之前需要准备近期稳定版的 LLVM/Clang，一组支持目标 NPU 的交叉编译工具链，以及 Python 3.8 以上的环境用于跑前端脚本。

先有一个编译环境，才是第一步。很多问题都出在版本不匹配上，所以开工前建议先固定一套依赖版本。我通常这么配：

改造已有的依赖关系，会非常琐碎，但可控。

基础环境： - Ubuntu 22.04 - LLVM/Clang 15 - Python 3.10 + onnx 1.14 + numpy - TVM 主线版本（带 ATVOSS 补丁分支） - NPU 固件库 v2.3

编译 TVM 时，需要确认use_llvm和target.backend配置被正确打开。ATVOSS 后端通常不是默认启用的，需要传一个开关让 TVM 在构建时把src/target/codegen_npu.cc纳入编译，否则编译出的 TVM 根本没有 NPU target。

4.2 构建和启用 ATVOSS target

ATVOSS target 在 TVM 里的注册名类似npu，但具体型号可能需要加上变体。实际使用时，我会在 build 脚本里显式指定：

cd build cmake .. -DUSE_LLVM=ON \ -DUSE_ATVOSS_NPU=ON \ -DNPU_TOOLCHAIN_PATH=/opt/npu-toolchain make -j$(nproc)

构建完成后，可以用一段很快的 Python 脚本验证 target 是否生效：

import tvm target = tvm.target.Target("npu") print(target.kind)

如果这里能输出类似npu的 kind 而不报错，后端的基础编译路径就通了。接下来建议先跑一个最简单的卷积算子，做真实的编译和运行冒烟测试，不要直接上整个模型。这一步如果跑不过，后面排查起来会非常痛苦，因为图优化引入的问题会增加很多干扰项。

4.3 编译一个卷积模型并在 NPU 上部署

下面用一个单卷积子图做示例，跑一条完整的编译流程。

import tvm from tvm import relay # 构造一个简单的 conv2d + relu 计算图 shape = (1, 3, 224, 224) inputs = relay.var("data", shape=shape, dtype="float16") weight = tvm.relay.Constant( tvm.nd.array(np.random.randn(16, 3, 3, 3).astype("float16")) ) conv = relay.nn.conv2d( inputs, weight, strides=(2, 2), padding=(1, 1), kernel_size=(3, 3) ) act = relay.nn.relu(conv) func = relay.Function([inputs], act) mod = tvm.IRModule.from_expr(func) # 构建 target 和 runtime target = tvm.target.Target("npu") lib = relay.build(mod, target=target) # 导出部署用的文件 lib.export_library("npu_model.so")

这段代码走完后，ATVOSS 会做一系列自动处理：把 conv2d 和 relu 判定为可融合、选择卷积的矩阵乘映射路径、把输入从 NCHW 做了排布变换、为那一小块计算生成 tiling 和双缓冲。你不需要手动指定融合，但你可以通过修改 target 参数来影响融合倾向，比如：

target = tvm.target.Target("npu -fusion=2 -max-sram-bytes=1048576")

fusion=2表示更积极的融合策略，max-sram-bytes告诉 ATVOSS 片上可用缓冲上限。调这些参数往往比改代码更直接。

部署的时候有一个我反复强调的点：不要直接在设备上边编译边推理。NPU 的编译阶段生成的调度参数需要跑过一轮 autotuning 或者至少是静态性能分析，否则默认参数只是“能跑”，距离“跑得好”还有不小距离。先交叉编译得到动态库，再部署到设备上做推理，这是更合理的流程。

4.4 性能调优的关键参数调优方法

跑通之后进入调优阶段，主要接触的参数有这么几个：

• max-sram-bytes：控制片上缓冲区预算。数值调大，tiling 可以更大，数据复用率提升，但超过硬件实际 SRAM 就会出现溢出。最好通过实测把可用值探出来，不要照抄规格书。
• pipeline-stages：流水深度。设为 1 表示不做双缓冲，设为 2 是常见的双缓冲，设为 3 对某些 DMA 延迟特别高的硬件有效，但也提高缓冲区开销。
• layout-pref：后端优先使用的数据排布。通过-layout-pref=NHWC或者-layout-pref=NCHW指定，这个参数多组合卷积网络影响最大。
• tile-min/max：循环分块的搜索范围下限和上限，配合自动调优搜索运行。

调优顺序也很重要，不要一上来就全参数自动搜索，那样时间成本很高，而且结果无法解释。我一般这样安排：

先把 layout-pref 定为与硬件 DMA 最吻合的排布，然后观察基线性能。再锁定一个维度，比如 pipeline-stages，从 1 到 3 各跑一遍，选最好的。接着在max-sram-bytes和 tiling 区间里做网格搜索。最后再看融合开关有没有帮助。

4.5 实测效果和瓶颈分析

一个常见的项目里，我从偏保守的基线参数出发，单算子卷积推理时间在 37ms 左右。当时用 ATVOSS 的效果分析工具扫了一下，发现瓶颈不在计算单元，而在一个奇怪的转置操作上——上层算子输出 NCHW 排布，卷积内部偏好 NHWC，系统在图层自动插入了一次显式转置，这个转置把整层性能拖得很明显。

之后我把融合策略调成允许转置折叠到上层算子中，编译器改变了上层算子的输出排布，转置被直接消掉，卷积推理时间从 37ms 降到 21ms，再配合双缓冲参数微调，最终稳定在 16ms 附近。这个过程中我没有改任何算子实现，全部是通过 ATVOSS 的布局规划和调度参数完成的。

这个案例比较典型，说明一个问题：NPU 后端优化里，数据搬移和布局带来的收益经常超过计算指令优化。编译器不只是“把计算变快”，更要“让计算不要等数据”。

5. 常见问题与排查技巧实录

5.1 性能上不去：访存时间总是盖过计算时间

在 ATVOSS 上做性能分析时，如果是访存瓶颈，现象通常是计算单元的利用率很低，但 DMA 队列一直满。这个问题的根源总结起来有三个：

一是数据复用不够。op 被分割成的计算块太小，每个块都从 DRAM 里现取数据。排查时看分析工具里的“片上命中率”或者“每算子外部搬移字节数”，如果字节数和输出张量大小几乎一致，说明几乎没有复用。

二是排布不匹配导致底层出现大量碎片化访问。比如 DMA 只支持连续 32 字节对齐块，但你的数据地址恰好错位，那么一次逻辑读会被拆成多次物理读。解决办法通常是强制 layout 统一，或者在数据源头做一次对齐重排。

三是流水断断续续。DMA 搬移时间和计算时间的比率不健康，计算很快，搬移慢，且没有做深流水。此时调pipeline-stages往往能直接看到效果。

5.2 算子融合失效或“看起来融合了但没效果”

融合失效有两种情况：一种是在图层面根本没匹配到融合模式，另一种是融合了，但输出中间张量仍然被写回外部存储。

前一种情况需要检查 Relay pass 的下发顺序。ATVOSS 的融合 pass 通常要求在某个特定的 pass 顺序之后执行，如果前面有 pass 把算子表达式改得不再满足模式匹配条件，融合就不触发。查法很直接：编译时打开 pass 详情输出，看conv2d和relu之间是否有常量标记被插入。

后一种情况更隐蔽。融合后的内部计算会出现一个虚拟中间张量，它本应留在片上，但如果后续算子需要按不同排布访问它，或者它的尺寸超过了片上剩余缓冲，ATVOSS 会保守地把它 spill 到 DRAM。你在性能图上看到算子时间下降，但整体时间没变，多半就是这个原因。对策不是关闭融合，而是调大 SRAM 预算，或者让前一个算子直接输出后续算子想要的排布。

5.3 调度失败或搜索空间爆炸

自动调优时，偶尔会遇到调度失败，报错通常是某个 buffer 尺寸为负、或者某个边界条件没满足。ATVOSS 的模板一般不会出现随机错误，会出问题的地方几乎都在自定义算子模板上。如果你照着模板格式写了新的调度规则，但约束条件给漏了，最常见的就是 tiling 切分不能整除导致的边界溢出。

这类问题排查时，先关掉自动搜索，把候选参数固定为最保守的一组，比如所有维度都不 tiling，然后逐步放开某一条约束，看哪一步开始冒烟。这虽然慢，但比看模板调度代码快得多。

搜索空间爆炸一般是tile-min和tile-max范围设得太大导致的，尤其是多个维度同时存在时，组合数量会指数增长。解决办法是先固定两个维度，只放开一个维度搜索；找到较优值之后再固定它，换另一个维度。

5.4 排查速查表

我把常用的问题对应关系和排查手段整理一下：

每个问题实际上都是可以先通过分析工具定位，再通过参数变化验证的。不要指望改一处就解决，多数问题是一层一层叠加出来的，先消除最大的那个瓶颈，再回头处理次一级的。

6. 实操心得与扩展方向

跑过几轮完整的 ATVOSS 编译和部署之后，我最大的感受是：做 NPU 后端，所谓经验，往往是调参之前先看懂瓶颈分布。不是看到哪个参数有性能提升就一路拧下去，而是先问一句，这个参数解决的是访存瓶颈，还是计算瓶颈，还是流水衔接问题。答案认准了，调参才会有效果。

还有一个实用的体会：ATVOSS 里最有价值的通常不是编译生成的指令，而是它对“中间状态”的管理能力。整个计算图经过融合、layout 规划、tiling 之后，会产生大量中间张量，这些张量的生命周期和数据位置决定了最终性能。这比单个算子的指令选择要难得多，也重要得多。后来的项目里我看任何后端，先看它怎么处理中间张量，不看指令集覆盖度，这个判断标准没有失手过。

后续继续扩展的话，我觉得有两条路值得走。一条是往混合精度方向走深，目前不同算子的精度选择和 NPU 指令之间的匹配还比较保守，如果能把量化误差的估计也放进调度决策里，就能在保精度的前提下更大胆地选低精度指令。另一条是往端到端自动调优走，把 layout、tiling、pipeline、融合策略都并进一个统一的搜索空间，然后加一个基于目标硬件的学习型代价模型，而不是再用静态启发式。这两件事做到了，ATVOSS 这类后端才真正算得上是一个会自己长大的编译系统。