前言

在昇腾NPU上进行深度学习算子开发，传统方式要求开发者深入理解硬件架构细节与复杂的底层编程接口，学习曲线相当陡峭。atvoss（ATVOSS，Ascend C Templates for Vector Operator Subroutines）作为昇腾CANN生态中的重要开源项目，致力于为开发者提供一套基于Ascend C的高层次Vector算子模板库，通过表达式模板技术将复杂的Tiling计算和底层API封装为简洁易用的编程接口。借助atvoss，开发者可以用接近数学表达式的声明式风格描述计算逻辑，而不必纠缠于寄存器分配、流水线编排等硬件层面的繁琐实现。本文将围绕atvoss的定位与架构展开，结合完整实战案例，带你从零掌握这一工具的核心用法与可视化分析能力。

atvoss的定位：不是Profiler，而是执行仿真可视化器

初次接触atvoss时，容易将其与传统的性能分析工具（Profiler）混淆。实际上两者的关注点有本质区别。传统Profiler侧重于在真实硬件上测量算子执行的耗时分布，输出的是数值化的性能报告，适合在开发后期做性能调优。而atvoss的定位是一个执行仿真可视化器，其核心价值在于模拟算子在AI Core上的执行时序，帮助开发者在没有真实NPU硬件的环境下，直观地理解算子内部数据搬运与计算流水线的时空关系。换句话说，atvoss解决的是"算子跑对了没有"和"算子是怎么跑的"这两个问题，而不是"算子跑得有多快"。

这一区别在工程实践中非常有意义。开发一个新算子时，最痛苦的阶段往往不是做性能优化，而是早期验证逻辑是否正确、以及数据流是否按预期在各个Tile块之间流转。atvoss通过生成可视化的时序图，将原本抽象的硬件执行过程具象化，开发者可以直接看到一次计算中数据何时进入GMEM、何时搬运到UB、计算核何时启动、各阶段有无气泡。这种所见即所得的调试体验，是传统printf加日志方式根本无法提供的。

核心功能解析：三大可视化维度

atvoss提供的可视化分析能力覆盖了算子执行过程的三个核心维度，每个维度都针对开发中常见的痛点问题。

算子时序可视化是最基础的功能。开发者可以清楚看到算子在一个AI Core内的完整执行时间线，包括数据准备阶段、计算阶段和结果回传阶段的起止时刻。当发现某个阶段耗时异常长时，可以快速定位到对应的代码逻辑。例如，如果数据搬运阶段占据了过多时间，往往意味着Tile形状配置不合理，或者double buffer机制没有启用。

内存访问模式可视化帮助开发者理解UB（Unified Buffer）的读写时序。由于昇腾NPU的UB空间有限且访问模式对性能影响巨大，理解数据在GMEM和UB之间的搬运时机、次数和重叠关系至关重要。atvoss会标注出每次内存读写的地址范围和持续时间，开发者可以据此判断是否存在不必要的往返搬运，或者是否可以合并多次小数据量为一次大数据量传输。

数据流可视化则呈现了多核之间以及核内多个Tile块之间的数据依赖关系。在融合算子场景中，多个计算步骤之间往往存在先后的数据依赖，不理清这些关系就容易写出错误的调度逻辑。通过atvoss的数据流图，开发者可以验证融合算子中各个子步骤的执行顺序是否符合预期，尤其是在涉及Broadcast、Reduce等跨数据维度的操作时，数据流视图能有效避免逻辑错误。

五层架构：从顶层到底层的分层设计

理解atvoss的分层架构是掌握这一工具的前提。整个项目采用五层设计，从Device层到Basic层，抽象程度逐步递减，每一层都有明确的职责边界和核心组件。

Device层是面向Host侧的总入口，负责参数校验、ACL资源管理、Host与Device之间的数据搬运、计算任务的切分以及Workspace管理。在实际开发中，开发者通常不会直接操作这一层，而是通过DeviceAdapter这个封装好的接口来使用Device层功能。这种封装的好处在于，即使不熟悉ACL复杂接口的细节，也能顺利完成算子的调用和资源管理。

Kernel层是多核间任务调度的核心。开发者在这里决定将任务分配到多少个AI Core上、采用均匀分段还是动态负载均衡策略。KernelBuilder和KernelPolicy是这一层的关键组件，前者负责构建多核调度的具体实例，后者定义了分核策略的参数。KernelSchedule则实现了不同的并行调度策略，根据任务的计算密度和数据分布特征，选择最优的多核分配方案。

Block层处理单核内部的任务分解。一个AI Core上可能需要处理多个Tile块，Block层负责编排这些Tile块之间的数据搬运和计算流水线，同时管理TPipe（传输管道）和double buffer机制。BlockBuilder和BlockPolicy是核心组件，BlockPolicy定义了单核内存使用的上限和Tile的形状，BlockSchedule则控制具体的调度执行。理解Block层对于后续做性能优化至关重要，因为核内流水线的编排方式直接决定了计算单元的利用率。

Tile层封装了Ascend C的基础API，提供更高层次的抽象接口。VecIn、VecOut用于数据搬运，Add、Mul、Sqrt等封装了基础计算操作，ReduceSum、Broadcast则处理归约和广播语义。开发者大部分时间都是在Tile层工作，通过表达式模板的方式声明计算逻辑。Assign系列函数（如AddAssign、SqrtAssign）是Tile层最常用的接口，组合这些接口即可构建复杂的融合算子。

Basic层直接使用Ascend C的底层API，是整个架构的性能上限保障。虽然日常开发中很少直接操作这一层，但它的存在保证了当Tile层提供的抽象无法满足特殊需求时，开发者仍然有下探到底层的能力。这种分层策略兼顾了易用性和灵活性，是atvoss架构设计中最值得称道的地方。

手把手实战：从环境准备到首次仿真分析

接下来以一个完整的abs算子（绝对值运算）为例，演示如何从零搭建环境并运行atvoss进行仿真分析。整个过程分为环境准备、源码获取、编译执行和仿真可视化四个阶段。

第一步是环境准备。atvoss的运行依赖CANN（Compute Architecture for Neural Networks）软件包，开发者需要在华为官网下载社区版CANN安装包。下载时选择对应架构的.run文件，例如x86_64架构下载Ascend-cann-toolkit_${version}_linux-x86_64.run。安装前确保系统已安装cmake（≥3.16.0）、python（≥3.7.0，建议不超过3.10）、gcc（≥7.3.0）等基础依赖。安装命令如下，需要注意安装路径需要有足够的权限。

chmod +x Ascend-cann-toolkit_${cann_version}_linux-x86_64.run
./Ascend-cann-toolkit_${cann_version}_linux-x86_64.run --install --force --install-path=/usr/local/Ascend

安装完成后，需要配置环境变量使CANN工具链生效。不同安装路径对应的命令略有差异，如果使用默认路径安装，以root用户身份执行source /usr/local/Ascend/cann/set_env.sh即可。验证安装是否成功可以通过查看version.info文件的内容来判断，执行cat /usr/local/Ascend/cann/opp/version.info能看到版本信息输出即表示CANN环境正常。

第二步是获取atvoss源码。项目托管在AtomGit平台，使用git克隆命令即可获取最新代码。

git clone -b master git@gitcode.com:cann/atvoss.git

克隆完成后，进入项目目录，可以看到标准的开源项目结构。docs目录包含详细的使用文档，examples目录下有abs、muls、rms_norm等多个参考实现，scripts目录中的build.sh提供了自动化编译脚本，include目录则包含了所有公共头文件。开发者应该先通读docs/quick_start.md了解完整的构建流程，然后再深入到具体的样例中学习。

第三步是编译abs算子示例。atvoss提供的一键式编译脚本大幅简化了构建过程，开发者只需指定目标硬件平台即可完成编译。对于abs这个最简单的逐元素算子，执行以下命令即可完成编译。

bash scripts/build.sh -DSOC=ascend950 abs

-DSOC参数指定了目标平台，atvoss当前支持Ascend 950PR和Ascend 950DT两款硬件。编译完成后，生成的可执行文件位于output/bin/abs。如果编译过程中遇到依赖缺失的问题，通常是因为CANN环境变量未正确配置，或者cmake版本不符合要求，需要针对性地检查和修复。

第四步是运行仿真并生成可视化报告。这一步是atvoss区别于普通算子测试的关键所在。通过cannsim工具可以在不依赖真实NPU硬件的情况下模拟算子的执行过程，并生成详细的执行报告。

./output/bin/abs --shape=512,512
chmod +x run.sh
cannsim record ./run.sh -s Ascend950 --gen-report

将执行命令写入一个run.sh脚本文件，然后使用cannsim的record模式启动仿真。执行完成后，当前目录下会生成一个cannsim_xxx的结果文件夹，其中包含了时序数据、内存访问日志和可读的仿真报告。如果看到"Accuracy verification passed."的输出，说明算子的功能逻辑正确通过验证。仿真报告中的时序数据就是后续可视化分析的基础素材。

代码解读：abs算子的完整实现逻辑

理解abs算子的源代码是深入掌握atvoss编程范式的起点。虽然abs只是一个取绝对值的简单操作，但它完整展示了使用atvoss开发算子的全部核心要素。

abs算子的核心实现在include目录下对应的头文件中。从架构上看，一个完整的atvoss算子通常包含以下几部分：是头文件导入，其中kernel_operator.h是Ascend C的底层API定义，atvoss.h是框架的核心头文件；是Tile形状的定义，这决定了数据在UB中的分块方式；然后是Compute结构体，这是整个算子的计算逻辑所在，开发者在这里用表达式模板声明输入输出和计算表达式；是策略配置，包括Block策略（单核分块方式）和Kernel策略（多核分配策略）。

在Compute结构体中，开发者用PlaceHolder声明各个输入输出张量的角色和用途。ParamUsage枚举指定了每个张量是输入（IN）、输出（OUT）还是同时作为输入输出（INOUT）。然后用表达式描述计算逻辑，对于abs算子来说，核心就是取输入的绝对值并写入输出。整个Compute函数返回的是一连串表达式的最终赋值结果。

Block策略和Kernel策略的配置同样重要。Block策略定义了单个AI Core内部的数据分块方式，包括Tile形状的大小和单核内存使用的上限。Kernel策略则控制多核间的任务分配，默认的UniformSegment策略会将任务均匀分配到各个可用核上，适合计算量均衡的逐元素算子。对于计算密度不均匀的特殊算子，开发者可以自定义KernelPolicy来实现动态负载均衡。

时序图解读：发现计算瓶颈与访存瓶颈

拿到仿真报告后，最关键的一步是正确解读时序图。时序图中蕴含了算子执行的全部时空信息，但需要掌握一定的解读方法才能从中提取有价值的信息。

观察时序图时，第一个关注点是流水线的气泡（bubble）。在理想情况下，算子的执行应该是完全流水线化的，即数据搬运和计算重叠进行，没有空闲等待。但实际上，气泡的产生有多种原因。计算气泡通常发生在UB中的数据被消耗完毕后、新数据还未搬运完成的间隙，说明计算速度超过了数据供应速度，解决方向是优化数据预取策略或增大Tile块以增加UB中数据的存活时间。搬运气泡则相反，数据早已搬运到位，但计算核还未就绪，可能是因为计算逻辑过于复杂或者存在不必要的同步等待。

第二个关注点是各阶段的时间占比。atvoss的仿真报告会量化列出数据准备、搬运、计算和结果回传各阶段的耗时。在abs这样的简单逐元素算子中，计算的绝对耗时非常短，大部分时间花在数据从GMEM到UB的搬运上。如果这个比例异常高（比如超过80%），说明算子的计算强度（Compute Intensity）太低，AI Core大部分时间都在等待数据而非真正做计算。解决方法包括增大Tile块以增加UB复用数据的次数，或者调整数据布局以提升Cache命中率。

第三个关注点是Tile块之间的执行间隙。当一个Tile块的计算还未结束时，下一个Tile块的数据已经开始搬运，这种重叠程度直接反映了double buffer机制的效果。如果两个Tile块之间存在明显的先后依赖导致无法重叠，说明Compute结构体中的数据流设计可能存在问题，需要检查是否存在不必要的跨Tile数据依赖。

进阶技巧与局限性

掌握了基础用法后，有几个进阶技巧可以帮助开发者更好地利用atvoss进行算子优化。融合算子场景是atvoss最擅长的领域，多个计算步骤串联时，通过合理配置Block策略可以实现计算与数据搬运的最大化重叠。例如在rms_norm算子中，均方根计算和归一化步骤之间的数据依赖关系直接影响流水线编排，理解atvoss的分层架构后，可以通过调整Tile块的数量和形状来改善整体吞吐。

自定义KernelPolicy是进阶开发的另一条路径。当默认的UniformSegment策略无法满足特殊需求时，开发者可以分析算子的计算密度分布特征，设计自定义的分核策略。对于计算量随输入数据动态变化的算子，动态负载均衡策略可能比均匀分段带来更好的多核利用率。

但必须承认atvoss目前仍有局限。是硬件支持的局限性，当前版本仅支持Ascend 950PR和Ascend 950DT两款硬件平台，对更新型号的支持还在持续开发中。是算子类型的局限性，atvoss的表达式模板最适合Vector类逐元素算子和规约类算子，对于涉及复杂索引操作、不规则数据访问模式或者非线性控制流的算子，模板的表达能力会受到限制，这类场景可能需要回归到底层的Ascend C API进行开发。另外，atvoss的仿真结果与真实硬件之间存在一定差异，仿真环境无法完全模拟真实NPU上的Cache行为、内存带宽波动和核间通信延迟，因此仿真通过的算子仍需要在真实硬件上进行最终验证。

使用前后的效率对比

atvoss的核心价值在于让开发者不必等到算子上板运行就能发现问题。以下从几个维度对比使用atvoss前后在算子开发流程中的差异：

场景	未使用atvoss（传统开发流程）	使用atvoss（仿真驱动开发）
算子逻辑验证	需要在真实NPU上编译部署后再验证，编译部署周期长，发现问题后需重新编译部署	在主机端通过仿真环境即可验证算子逻辑正确性，发现问题后修改模板代码即刻重仿真
执行时序分析	需要依赖profiling工具在真实硬件上采集数据，数据量大且难以定位具体指令级别的问题	atvoss可视化输出直接展示指令级别的时序关系，Cube指令与Vector指令的流水线等待一目了然
内存访问优化	通过profiling数据推测内存访问模式，信息粒度粗，难以发现bank conflict等细节问题	仿真输出展示每个buffer的物理地址分配和访问时序，bank conflict和数据依赖等待可直观识别
融合算子调试	多个子算子融合后整体调试困难，单个子算子的中间状态不易观察	仿真模式下可以单独查看融合算子内部每个子操作的输出，逐步验证融合逻辑
开发迭代速度	每次修改都需要完整的编译部署运行周期，迭代效率受硬件资源限制	仿真运行在主机CPU上，无需NPU硬件资源，多名开发者可并行调试不同算子

从对比可以看出，atvoss的价值不在于替代真实硬件上的最终验证，而在于将大部分逻辑错误和明显性能问题前移到仿真阶段解决，从而大幅缩短从算子设计到上板验证的整体周期。对于团队协作而言，atvoss还降低了对NPU硬件资源的占用压力——仿真环境只需要主机CPU和内存，而真实硬件往往是共享的稀缺资源。

atvoss作为昇腾CANN生态中专注于Vector算子开发的开源模板库，通过表达式模板技术极大降低了昇腾NPU上融合算子的开发门槛。五层分层架构兼顾了易用性和灵活性，仿真可视化能力帮助开发者在早期阶段就发现逻辑错误和性能隐患。虽然在硬件支持和算子类型覆盖上还有成长空间，但其设计理念和工程实践已经为昇腾算子开发生态注入了新的活力。对于需要在昇腾硬件上开发高性能Vector算子的团队和个人开发者而言，atvoss是一个值得关注和投入时间的工具选择。

---

仓库地址：https://atomgit.com/cann/atvoss