企业官网建设流程全解析

3月17日直播丨CANN全链路算子开发体验提升

关注CANN算子开发的朋友，应该都有这种感觉：网上关于算子的资料不少，但真正从零开始把一个算子写好、调通、性能调到位的完整流程，讲清楚的不多。CANN的全链路算子开发，本质上就是一条从算法公式到NPU上高效运行的“生产线”，每个环节都有各自的学问。我自己在接触这套东西的过程中，踩过不少坑，也总结了一些经验，借着这次直播前的机会，把这些东西整理出来，希望能帮到正在入门或者已经在做算子开发的人。

先说下这篇内容适合谁看。如果你正准备接触NPU编程，或者已经在用CANN做算子迁移、性能优化，但对整个开发流程还没有形成完整认识，那这篇内容应该能给你一个清晰的路线图。即使你只是对AI芯片底层实现感兴趣，想搞清楚一个算子从数学定义到硬件执行的完整过程，这也能帮上忙。围绕“全链路”这三个字，我会从开发方式选型、工程环境搭建、实现步骤、性能优化、问题排查这几个维度展开，把我在实操中用到的思路和方法都写出来。

1. 先把话说透：算子开发到底在做什么

1.1 为什么算子开发如此关键

算子这个词，在很多人的理解里就是一个框架里的一个函数，比如卷积、矩阵乘、归一化，好像调一下接口就行了。但到了芯片层面，算子是硬件执行的基本单元，是软件算法和硬件电路之间的“翻译官”。在CANN这套体系里，算子开发质量直接决定了最终的上层性能表现。同样一个算法，用高效的算子实现和用一般的实现去跑，性能差距可能有一倍甚至好几倍，这不是框架能帮你在后段弥补的，必须在算子层面就把它做对。

我在实际接触中有一个体会：很多业务侧的性能问题，追到根上都是算子在硬件上执行效率不高导致的。数据搬运多、计算单元空转、内存访问不连续，这些在纯软件层面看不太出来，但到NPU上运行就会被放大。因此，算子开发不只是把功能实现出来，还要结合硬件架构去思考怎么做才最合理。

1.2 开发方式选型：TBE DSL、DSL API 与 Ascend C 怎么选

CANN环境里开发算子，主要有三种路径：基于TBE DSL的Python开发、基于DSL API的开发，以及基于Ascend C的C/C++开发。这三条路并不是谁替代谁的关系，它们有各自的定位，选择时主要看你的使用场景。

TBE DSL是偏快速验证的方式，适合算法原型验证和逻辑探索。如果一个算子需要快速确认在NPU上能不能跑通，用DSL在Python环境里写一版，运行结果对比一下对错，这个阶段用它是比较高效的。但它的问题在于性能和灵活性受编译器自动调度能力限制，想要精确控制数据搬运和核内流水，就会觉得使不上劲。

Ascend C则是更贴近硬件的一层。它能直接表达矢量计算、矩阵计算、数据搬入搬出、同步等底层操作，可控性强，也更容易做深度性能优化。对于要长期维护上线、对性能要求比较高的算子，用Ascend C来写是更稳的选择。

DSL API则介于两者之间，有一定的接口抽象，同时也能做一些手工控制。按照实际需要来选就行。我自己在选用时通常参考这样的原则：先看算子最终要跑到什么场景，如果只是为了实验验证，选快的；如果是要上线做产品，就直接上Ascend C。另外，团队的技术栈也很重要，如果团队熟悉Python，前期切入用DSL，再逐步向Ascend C过渡，学习曲线会更平滑。

2. 全链路开发流程：从算子的“出生”到“上岗”

2.1 环境准备：不要急着写代码，先把工程骨架搭好

算子开发第一步并不是写算子本身，而是准备一套干净、可复现的工程环境。我在刚开始接触时也犯过这个错误，一上来就想把某个算子写出来，结果环境里缺依赖、版本不匹配、样例跑不通，浪费了不少时间。

一个标准的环境至少包含这几个部分：适配的硬件驱动和固件、对应版本的CANN工具包、开发框架（如果涉及模型调用，要有配套的框架版本），以及用于做精度对比的参考实现。比如你写一个自定义算子，最终要和CPU上的计算结果做对比，那就得先准备一个能跑通的标准算法实现作为参照。

在搭建环境时，我比较推荐用脚本把环境检查做成自动化。因为算子开发过程中，环境变量配置是否正确、工具包是否安装完整，这些基础问题会反复遇到。写一个脚本把关键的校验点跑一遍，比如npu-smi信息查看、工具包版本号确认、依赖库检查，能省掉很多排查环节的时间。

2.2 从算子原型到NPU上运行的完整闭环

算子开发不是写完代码就结束了，全链路的流程涉及多个阶段。我这里把我常用的流程拆解一下：

第一步是算法分析。先把算子的数学定义梳理清楚，输入输出是几维张量、数据类型是什么、维度顺序怎么处理、有没有特殊的边界情况。这一步直接决定后续代码怎么写。举例来说，一个ReduceSum算子，你要明确是沿哪个维度做归约，输出维度形状是什么，这关系到后续的tiling策略和核间分工。

第二步是Kernel实现。手写Kernel时，要理清数据的生命周期：先把数据从外部存储搬运到片上，计算完成后再搬运出去。中途要考虑数据切块、内存复用、同步机制等细节。用Ascend C来实现时，Kernel代码有固定的结构，包括数据搬入、计算、数据搬出这三个环节，核心逻辑集中在这三步的编排上。

第三步是Host侧的调用逻辑。Kernel跑起来还需要Host侧代码做任务分发，申请设备内存、准备tiling参数、调用Kernel入口。这一步看起来像“胶水代码”，但任何一处错误都可能导致算子跑不起来。实践下来，先把Host侧跑通，再去优化Kernel，是一个比较稳妥的顺序。

第四步是精度对比与验证。用同样的输入在参考实现里跑一遍，得到标准结果，再和NPU算子输出做对比。一般要求误差在指定阈值内（比如余弦相似度大于0.9999），具体指标视算子类型而定。精度不过时，优先查数据搬运是否完整、计算顺序是否与参考实现一致。

第五步是性能评估和调优。在标准数据集上测速，对比优化前后的耗时，定位性能瓶颈。这一步通常需要借助profiling工具，看算子的执行时间花在哪，是数据搬运占大头还是计算占大头，然后针对性优化。

这一步一步走下来，才算完成了一个算子的全流程开发。我在实践中体会到，整个流程中最容易出问题的，往往不是Kernel计算逻辑本身，而是数据搬运和tiling参数设计，这两个环节出错时隐蔽性很强，需要格外留意。

3. 算子性能优化：从“能跑”到“跑得快”

3.1 搞清楚性能瓶颈在哪里

性能优化虽然在流程最后面，但它的优先级应该在动手写代码之前就设定好。因为算子实现的结构，很大程度上决定了后续的性能天花板。一个关键原则是：先把“能做对”的结构想清楚，再动手写代码。如果刚开始结构就不合理，后面再怎么微调参数，都只是在局部优化，无法突破结构带来的瓶颈。

在做性能分析时，我一般从三个维度看：计算效率、访存效率和并行效率。计算效率看的是计算单元是否被充分利用；访存效率看的是数据搬运是否冗余、是否利用了片上内存，比如通过L2缓存命中降低外部存储访问开销；并行效率看的是多个计算核心是否均衡分担了工作。

拿矩阵乘这类计算密集型算子来说，如果计算单元利用率不高，问题往往出在数据切块不够好，导致计算过程中频繁等待数据。而像求和、归一化这类访存密集型算子，主要问题往往是数据搬运占了大头，计算本身反而很快。这时候的优化重点应该放在减少搬运次数、提高数据复用率上。

3.2 关键优化参数与配置原则

在整个开发过程中，tiling、block dim、buffer size这几个参数是性能优化的关键，值得仔细说明。

• Tiling是核心。NPU上算子的计算能力是固定的，但算子的数据量可能非常大，比如几百兆的输入张量。如果一下子把数据都塞到片上内存，明显不现实。Tiling做的就是数据切块。合理的tiling策略是让每个核处理的数据块大小适中，既要充分利用片上内存，又要避免切得太碎导致调度开销变大。比如一个二维矩阵的操作，可以把矩阵按行切块，每个核处理若干行；也可以按列切，或者在行列两个方向都切，这取决于数据在内存中是行优先还是列优先。

• Block dim是另一个关键参数。它表示这次任务要用多少个AI Core来并行计算。理论上核心数越多越好，但实际要看你算子的计算特性。如果算子本身计算量不大，分配过多核反而导致同步和通信开销过大，性能不升反降。

• Buffer size决定的是数据在计算过程中暂存的空间大小。对齐到硬件支持的粒度会很关键，如果buffer分配过小，数据搬运次数会增加；分配过大，又可能浪费片上空间，导致其他模块可用内存不足。

以下是我在做优化时比较常关注的几个方面：

• 减少Host与Device之间的数据拷贝。能复用的数据就放在设备端，不要频繁来回搬运，有些场景可以用算子融合的方式，把多个操作合并成一个，减少中间结果的写回和重读。
• 尽量使用向量化指令。批量处理数据比逐元素循环要快得多，尽量让编译器识别到可以向量化的循环。
• 深入理解内存层次结构。比如经常访问的数据放在片上，大块数据尽量顺序访问，避免跨步式的随机访问，否则cache命中率会大幅下降。

拿我做过的一个归一化算子来举例。第一版实现采用了最简单的写法，每个元素都单独处理，性能很差。分析profiling数据后发现，问题主要出在两个地方：一是整个输入被分成了非常多小块，搬运次数过多；二是每个小块的尺寸没对齐到硬件的处理宽度，导致计算单元利用率偏低。调整了tiling参数和block dim之后，整体耗时下降了大概40%多。这个例子说明，性能优化不能靠感觉，要用数据说话，先找到瓶颈，再针对性调整。

4. 调试与问题排查：那些年我们踩过的“坑”

4.1 常见问题与排查要点

算子开发中，遇到的问题类型相对集中，我把它们归纳成几类，做成一个速查表，方便快速定位：

编译错误通常是最容易解决的，但也是出现频率最高的。对于这类问题，先看编译日志中提到的第一个错误，大概率能顺着找到问题所在。

运行时错误中，内存访问越界是最常见的。这类问题隐蔽性强，有时候表面上的错误提示并不是真正的原因。比如算子崩溃，报的错误可能是一个完全看不出关联的地址，但实际原因是Kernel里某个计算索引越界了。排查这类问题时，可以先把tiling参数打印出来，人工核对一遍，确认每个核处理的数据范围没有超过输入张量的边界。

精度误差是最费时间的。我遇到过的精度问题里，相当一部分是类型转换导致的。比如输入是float16，计算过程中某个中间量被隐式转换成了float32，或者反过来，就会产生细微差异。如果误差是固定出现的，优先检查计算顺序，因为加减法顺序不同也会导致浮点误差。如果误差是偶发的，那大概率是内存访问存在竞争，需要用同步机制来修复。

4.2 一套实用的排查步骤总结

这里是我建议的一套排查顺序，配合实际操作可以快速收敛问题：

1. 先确认环境。工具包版本、驱动版本和硬件是否匹配。环境不匹配时，后面的排查都没有意义。
2. 最小化复现。用一个固定的、小的输入样例跑算子，逐步简化，直到能用最小规模稳定复现问题。
3. 验证Host侧参数。把传给Kernel的tiling参数、数据指针、形状信息打印出来，手动核对。大量问题出在参数对不上，比如一个4维张量传成了3维的形状。
4. Kernel分步检查。在Kernel中关键阶段设置中间结果，可以先通过Host侧调用或调试模式获取中间数据，和参考实现对比，确定错误发生在哪个环节。
5. 性能问题单独处理。等正确性确认了再分析性能。性能优化时一次只改一个变量，改了之后立刻测速，避免多个因素混在一起无法判断哪个生效。

我在排查时有个习惯：把所有“中间变量”用日志或文件输出下来，即使现在已经有了更高级的调试工具，这个习惯也保留着。因为有些问题只在特定数据分布下出现，没有中间过程数据，很难还原现场。

5. 工具链与体验提升：把开发门槛再降一截

5.1 从编程到调试：常用工具与使用场景

前面提到过profiling工具，这在算子开发里基本属于必备工具。通过它可以看到算子在设备端执行的详细时间线：数据搬运耗时、计算耗时、核间同步耗时、内存访问情况等。有了这些数据，性能问题的定位基本不是靠猜，而是看数据说话。

调试方面，CANN也提供了断点调试能力，可以在代码中设置断点，查看变量值，单步执行。对于逻辑复杂的Kernel，这一步能直接看到数据在每一步的变换情况。不过需要注意的是，断点调试会引入额外的性能开销，不适合在性能测试时开启。没有断点调试能力或调试器操作不便的情况下，用日志输出中间结果也是一种实用的替代方案。

5.2 直播中提到的体验提升，我们还能做些什么

这次3月17日的直播，重点讲的是“全链路算子开发体验提升”。我理解这里的“体验提升”不只是工具界面好不好看，而是整个开发流程中的摩擦能不能减少：从算子开发到调优到部署，中间的步骤能不能更少？反馈能不能更即时？错误提示能不能指向更明确？

在实际工作中，有几个体验上的提升是很有价值的：

• 更智能的tiling参数推荐。对新手来说，tiling策略往往是最难把握的。如果工具链能根据算子的输入形状和硬件资源情况，给出一组合理的推荐参数，然后允许开发者手动微调，会比从零开始设置方便很多。
• 更明确的报错信息。现在很多报错信息仍然偏向底层，直接指向某个内存地址或者某条汇编指令。如果能把错误信息转换成“第几行代码的什么操作导致什么问题”，调试成本能大幅下降。
• 更完整的性能分析视图。如果能对算子的性能数据做时间线对齐，看到数据搬运和计算之间的重叠情况，判断等待是否可以通过异步机制来避免，会比只看到一个整体耗时要有用得多。

5.3 如何跟进这类学习资源与社区经验

关于CANN算子开发的资料，现在主要有几个来源：官方文档和样例、技术博客与社区分享、以及直播这种实时交流形式。我建议三种都配合使用。官方文档和样例是基础，用来建立完整的知识框架，确保版本和接口都是最新的；技术博客和社区分享用来补充实操经验，特别是那些文档里不会写的“坑”；直播则适合用来了解当前工具链的最新变化和提问交流。

观看直播前，如果有一些基础更好：对CANN的基本架构有个了解，至少知道AI Core、tiling这些概念；用官方样例跑通过一个最简单的算子，有基本的实操体感。这样听直播时能更快跟上讲解思路，也能提出更有针对性的问题。直播这类形式最大的价值在于交流，带着问题去听，收获会大不一样。

说到具体跟进方法：从官方文档里的样例库入手，跑通一个样例，把自己当成开发者，去理解这个算子从定义到运行的全部过程。然后尝试修改参数，观察性能和数据变化。最后试着去写一个自己的算子，哪怕是很简单的功能，也比只看样例有效果。动手和不动手的差别，在这个领域真的很大。

6. 一些个人体会和后续建议

踩过几次坑之后，我对算子开发这件事最大的体会是：它是一个“慢工出细活”的工程，不是靠灵感能写好的。结构设计、参数调优、问题定位，都需要时间和耐心，一步一个脚印地来。如果你正在经历算子性能不达标、精度对不上的阶段，不用太怀疑自己，这是几乎每个人都要走的路，关键是找到系统的方法去定位问题，而不是东一榔头西一棒子地改。

关于工具链的体验提升，我从使用者角度比较期待的方向：一是更智能的自动化工具，比如根据算子特征自动生成部分代码，减少重复劳动；二是更全面的性能分析能力，一眼能看出瓶颈在哪；三是更好的社区生态，让问题能被更快找到答案、经验能被更好地沉淀。

如果你正准备学算子开发，或者正在为某个算子的性能发愁，建议从这几点开始：先把一个最简单算子从零到一完整跑通，再去做性能分析，最后才是大规模算子的开发。顺序走对了，投入产出比会高很多。也希望你看完这篇文章，对全链路算子开发有了更清楚的认知，后面在直播里看到相关内容时，能更从容地理解和消化。