算子开发这件事，最让人抓狂的从来不是数学公式推不出来，而是逻辑写完了、单测跑通了，一上板子发现性能只有理论值的十分之一，查半天发现是搬运没对齐。昇腾AI处理器软件栈里的张量加速引擎（TBE，Tensor Boost Engine）就是专门用来对付这类问题的算子开发框架。简单说，它干的事是把"你想让芯片算什么"翻译成"芯片能高效执行的指令流"，中间那些内存分层、数据搬运、流水排布、多核切分的脏活累活，它替你兜掉一大半。这篇东西主要面向三类人：刚接手昇腾平台算子开发、被Tiling参数搞得头晕的新手；从通用GPU编程模型转过来、想搞清楚达芬奇架构差异的老手；以及做模型迁移、发现某些算子跑不动需要自己动手补的中高级工程师。我会把TBE的两条技术路线、算子从原型定义到上板测试的完整链路、Tiling和双缓冲的真实计算过程，以及我踩过的那些坑，一条一条摊开讲。

1. 先搞清楚TBE在整条软件栈里站哪一级

1.1 从模型到指令，中间隔了多少层

很多人一上来就闷头写算子实现，结果编译报错一堆看不懂的字段，本质是没搞明白自己写的这段代码最终会落到哪一层。昇腾AI处理器软件栈大致可以按"越往下越贴近硬件"来理解：最上面是各类训练和推理框架，往下一层是图引擎，负责整张计算图的优化、算子融合、内存规划；再往下是算子库和算子开发框架，也就是TBE所在的位置；最底下是运行时和驱动，负责把编译好的二进制下发到AI Core上执行。

TBE处在一个承上启下的关键位置。往上，它要接受图引擎传来的算子描述——输入输出的形状、数据类型、属性参数；往下，它要产出能在AI Core上跑的二进制。中间这一段的转换，正是TBE存在的意义。你可以把它理解成一个"翻译官加调度员"：翻译官负责把数学语义翻译成硬件指令，调度员负责安排这些指令按什么顺序、在哪个计算单元、用哪块内存执行。

这里有个容易混淆的点：TBE不是一个算子库，它是一套开发框架。昇腾内置的算子库里有大量已经写好的算子，日常调用直接用就行；但当你的模型里出现了内置库覆盖不到的算子，或者某个算子在你的场景下性能不达标，就需要用TBE自己动手写。所以TBE的定位更接近"造工具的工具"，而不是"工具本身"。

理解这个分层还有个实际好处：出问题的时候能快速定位是哪一层的锅。比如报错说找不到某个算子的实现，那是算子注册和信息库的问题；报错说内存越界，那是Tiling算错了；跑出来结果不对但单算子测试是对的，那多半是图优化阶段的融合出了问题。层次清楚了，排查方向就不会跑偏。

1.2 达芬奇架构决定了TBE必须"分层"设计

要理解TBE为什么长成现在这个样子，得先看一眼它服务的硬件。昇腾AI处理器采用的是达芬奇架构，一个AI Core内部并不是一块统一的计算资源，而是被切成了好几块各司其职的单元：Cube单元专门做矩阵乘加，算力最猛；Vector单元做逐元素运算、激活函数、类型转换这类向量操作；Scalar单元做标量控制和地址计算。与之配套的还有一套层级分明的存储：最外层是全局内存GM，容量大但带宽有限；往里是L1 Buffer，再往里是Cube专用的L0A、L0B、L0C；Vector单元则主要依赖统一缓冲区UB。

这种"计算单元分离加存储分层"的设计，带来一个很直接的后果：数据不会自己跑到计算单元旁边，必须显式搬运。而且搬运的单位不是字节，是32字节一个block，所有地址都得按这个粒度对齐。这就解释了为什么TBE的TIK路线里，你会看到密密麻麻的data_move调用和stride参数——这些不是啰嗦，是硬件真的需要你把每一趟搬运的起止、跨度、重复次数说清楚。

分层设计的另一个后果是，同一份计算逻辑，放在Cube上跑和放在Vector上跑，写法完全不同。矩阵乘这类适合Cube的算子，核心是把大矩阵切成能塞进L0A、L0B的小块，让Cube单元连续不断地做乘加；而像加法、ReLU这种逐元素算子，核心是把数据搬进UB，凑够一个repeat的长度做向量运算，再搬回去。TBE的DSL路线帮你把后者的调度自动化了，TIK路线则把前者的控制权完全交给你。

1.3 谁会真正用到TBE：三类典型场景

第一类是自定义算子补齐。你去部署一个从研究侧传过来的模型，图解析完发现有个算子内置库里没有，比如某种特殊结构的归一化或者自定义的损失函数，这时候只能自己写。第二类是性能调优。内置算子为了通用性，往往在Tiling上偏保守，如果你的场景形状固定、数据量大，手写一个针对性Tiling的版本，性能提升三到五成很常见。第三类是精度对齐。某些算子在不同精度模式下行为不一致，模型精度掉点找不到原因，最后定位到某个算子的累加精度上，这种情况也得改算子实现。

这三类场景对开发者的要求是不一样的。第一类重在"能跑通"，写完能出正确结果就行；第二类重在"跑得快"，需要懂Tiling、懂流水、会看profiling数据；第三类重在"抠细节"，得把数据类型转换、累加器位宽、舍入模式这些搞明白。我建议刚上手的人先把第一类走通一遍，完整经历从原型定义到上板验证的全流程，心里有个整体地图，再去碰优化。

2. DSL和TIK两条路线，到底该走哪条

2.1 DSL路线：用表达式描述"算什么"，让框架决定"怎么算"

TBE DSL这条路线建立在开源深度学习编译器TVM之上，核心思路是计算与调度分离。你只需要用Python写清楚输出张量的每个元素是怎么由输入元素算出来的，至于这个计算怎么切块、怎么并行、怎么搬数据，交给调度器去推导。举个最直白的例子，写一个逐元素相加：

from tbe import tvm from tbe import dsl def add_compute(input_x, input_y, output_z, attrs): shape = input_x.shape dtype = input_x.dtype data_x = tvm.placeholder(shape, name="data_x", dtype=dtype) data_y = tvm.placeholder(shape, name="data_y", dtype=dtype) res = tvm.compute(shape, lambda i: data_x[i] + data_y[i], name="res") with tvm.target.cce(): sch = tvm.create_schedule(res.op) sch[res].parallel(res.axis[0]) return sch

这段代码里，tvm.compute那一行描述的是语义——第i个输出元素等于两个输入第i个元素之和。parallel那一行是唯一的调度干预，告诉编译器沿第0维做多核并行。剩下的切块、对齐、搬运，框架会自己生成。写起来确实舒服，代码量小，可读性高，改逻辑也方便。

但舒服是有代价的。调度器自动推导出来的方案，是按照一套通用启发式规则生成的，它不知道你的形状有多大、也不知道你的数据有什么特殊规律。对于形状规则、计算简单的逐元素算子，自动方案通常够用；可一旦碰上规约、转置、卷积这种访存模式复杂的算子，自动生成的代码往往离硬件峰值差得远。而且DSL的调试体验不太好，出错时你看到的是一层层lower之后的中间表示，很难直接对应回自己写的那几行。

我的经验是：DSL适合拿来快速验证算法正确性，或者写那些结构简单、后续也不太需要极限优化的算子。如果你的目标是先跑通再说，这条路省时省力。但如果这个算子将来会成为模型的热点，别指望DSL自动生成的版本能让你满意。

2.2 TIK路线：像写汇编一样，亲手安排每一次搬运

TIK全称Tensor Iterator Kernel，走的是完全相反的思路。它给你一套Python接口，但这套接口几乎是一一映射到硬件指令上的：声明一块UB上的buffer、从GM往UB搬多少个block、对UB里的数据做一次向量加、再把结果搬回GM。每一步都是你显式指定，框架不替你做任何决策。

from tbe import tik def add_tik(input_x, input_y, output_z, kernel_name="add"): tik_instance = tik.Tik() x_gm = tik_instance.Tensor("float16", (4096,), name="x_gm", scope=tik.scope_gm) y_gm = tik_instance.Tensor("float16", (4096,), name="y_gm", scope=tik.scope_gm) z_gm = tik_instance.Tensor("float16", (4096,), name="z_gm", scope=tik.scope_gm) with tik_instance.for_range(0, 8, block_num=8) as blk: x_ub = tik_instance.Tensor("float16", (512,), name="x_ub", scope=tik.scope_ubuf) y_ub = tik_instance.Tensor("float16", (512,), name="y_ub", scope=tik.scope_ubuf) z_ub = tik_instance.Tensor("float16", (512,), name="z_ub", scope=tik.scope_ubuf) tik_instance.data_move(x_ub, x_gm[blk * 512], 0, 1, 32, 0, 0) tik_instance.data_move(y_ub, y_gm[blk * 512], 0, 1, 32, 0, 0) tik_instance.vec_add(4, z_ub, x_ub, y_ub, 1, 8, 8) tik_instance.data_move(z_gm[blk * 512], z_ub, 0, 1, 32, 0, 0) tik_instance.BuildCCE(kernel_name=kernel_name, inputs=[x_gm, y_gm], outputs=[z_gm])

这段代码里有几个数字不是随便写的。data_move的第五个参数是burst_len，单位是32字节的block，512个fp16元素正好是1024字节，也就是32个block。vec_add的第一个参数是repeat次数，一个repeat处理256字节，512个fp16元素是1024字节，需要4次repeat。后面那几个8是repeat之间的地址步长，单位也是block，因为源和目标都是连续排布的，步长按最紧凑的方式给。

这些参数只要有一个给错，要么结果不对，要么性能崩。但反过来说，正因为每个参数都在你手里，你可以做出非常激进的优化：把搬运和计算交错起来做双缓冲、把尾块单独拎出来处理、针对特定形状把repeat次数拉满减少循环开销。这些手段在DSL里基本没法精细控制。

2.3 选型对照：别凭感觉，按这张表来

实际项目里这两条路线不是互斥的。我见过比较务实的做法是：先用DSL快速出一个正确版本，把整条链路跑通、精度对齐做掉；等确认这个算子确实是性能热点之后，再用TIK重写一遍，两版并存，通过配置切换。这样既不耽误进度，又给后续优化留了口子。

还有一个常被忽略的选型因素：团队维护成本。TIK代码和硬件绑得紧，将来硬件迭代，参数可能要跟着调；DSL代码抽象层高，迁移成本低。如果这个算子只是临时补丁、长期看会被内置库覆盖，那用DSL写完扔那儿更划算。

3. 算子开发全流程：从契约定义到上板验证

3.1 算子原型与信息库：接口契约必须先钉死

很多人写算子喜欢直接冲实现，结果写完发现框架侧传进来的数据类型和自己预期的不一样，返工。正确顺序是先定契约，再写实现。契约由两部分组成：算子原型和算子信息库。

算子原型定义的是这个算子对外长什么样——有几个输入、几个输出、有哪些属性、属性的类型和取值范围。这部分通常用框架提供的原型定义接口来写，把输入输出按顺序注册进去，属性用指定类型声明。原型一旦定下来，上层框架在构图时就会按这个契约校验，传错参数会直接在构图阶段报错，而不是等到运行期才炸。

from tbe.common.register import register_op @register_op("AddCustom") def add_custom(input_x, input_y, output_z, attrs): pass

算子信息库则是给编译器看的说明书，一般是一个ini格式的配置文件，里面要写清楚每个输入的name、dtype、format，输出的对应信息，以及这个算子由哪个引擎实现、精度模式怎么选、是否支持动态形状推导。这里最容易出问题的是dtype列表——你得把实际可能出现的所有数据类型组合都列全，比如fp16配fp16输出fp16，fp32配fp32输出fp32，少写一种，跑模型时就报"算子不支持该数据类型"。

注意：信息库里format字段的填写要和实际内存排布一致。昇腾平台上有ND、NZ、NC1HWC0等多种格式，卷积类算子常用NZ，逐元素算子一般是ND。格式写错不会立刻报错，但会在图编译阶段触发插入转换算子，性能莫名其妙掉一截，而且很难查。

我踩过一次坑：信息库里只写了fp16，测试用的也是fp16，一路顺畅；结果线上模型某层被混合精度策略改成了fp32，直接报错。后来养成的习惯是，只要信息库里写了某种dtype，就一定配一条对应的单算子测试用例，避免纸上谈兵。

3.2 计算逻辑实现：先把边界情况想清楚

实现阶段最考验功力的是边界处理。形状不整除是最常见的情况：总元素数不是tile大小的整数倍，最后一块要么补零，要么单独走一套逻辑。补零看着省事，但如果算子里有规约操作，补进去的零会影响结果，这时候必须老老实实把尾块单独拿出来算，或者在规约时把无效元素排除掉。

另一类边界是类型转换。fp16的表示范围有限，做累加时如果中间结果一直用fp16存，很容易溢出成inf。标准做法是搬进UB之后先转成fp32做累加，累加完再转回fp16输出。这个转换不是免费的，会多占UB空间、多花指令周期，但对于求和、均值、方差这类算子，不做转换精度基本没法看。

# 累加场景：先升精度再累加，最后降回输出类型 acc_ub = tik_instance.Tensor("float32", (tile_elems,), name="acc_ub", scope=tik.scope_ubuf) x_fp32 = tik_instance.Tensor("float32", (tile_elems,), name="x_fp32", scope=tik.scope_ubuf) tik_instance.vec_conv(2, tile_elems, x_fp32, x_ub, 8, 8) tik_instance.vec_add(1, acc_ub, acc_ub, x_fp32, repeat, 8, 8, 8)

还有一类容易被忽视的边界是空张量。某些模型在特定配置下会传出元素数为0的张量，如果代码里直接按元素数算tile、算循环次数，可能算出0次循环或者负值，直接段错误。稳妥做法是在入口处判断一下，元素数为0直接返回。

3.3 编译、单算子测试与精度对齐

实现写完只是开始，接下来是编译和验证。TBE会把你的Python代码编译成设备侧可执行的二进制，这个过程会暴露大量问题：接口参数个数不对、buffer大小超过UB容量、指令参数越界、循环边界算错。编译报错信息通常比较具体，对着提示改就行，难的是编译通过但结果不对。

单算子测试是这一阶段的主力工具。它的做法是构造一组输入数据，在CPU侧用参考实现算一遍，在设备侧跑一遍，然后逐元素比对。比对时要注意容差设置：浮点运算有舍入误差，累加顺序不同结果也会有细微差异，所以不能要求逐位相等。一般fp16场景设相对误差1e-3、绝对误差1e-3，fp32场景设1e-6量级。容差设太严会误报，设太松会漏掉真实错误。

我一般会准备三组测试数据：第一组是常规的随机数据，检查基本正确性；第二组包含极值，比如最大值、最小值、零、负数，检查溢出和边界；第三组故意构造不整除的形状，比如总元素数是tile大小的1.5倍，检查尾块逻辑。三组都过了，才敢往模型里集成。

精度对齐这块还有个隐性问题：不同框架对同一个算子的语义定义可能有细微差异。比如某些归一化算子里的epsilon加在哪个位置、除法用的是倒数还是真除，这些细节在单算子测试时如果参考实现和框架行为不一致，测试能过但模型精度会掉。稳妥做法是直接拿框架侧的输出来做参考，而不是自己另写一份。

4. 性能优化实战：Tiling、对齐与流水线

4.1 Tiling不是一个拍脑袋的数字

Tiling的本质是把大张量切成能塞进UB的小块，块太大装不下，块太小搬运开销占比高。理想值怎么算？先看UB的可用容量。假设某型号的UB可用空间是192KB，做一个逐元素加法，单缓冲下每处理一个元素需要三份空间——两个输入一个输出，fp16每份2字节，那么单次能处理的元素数是 192×1024 ÷ 3 ÷ 2 ≈ 32768。但实际不能这么满打满算，因为还有中间变量、还有对齐填充。

如果要做双缓冲，空间直接砍半，tile元素数降到16384左右。再考虑对齐，fp16下32字节对应16个元素，tile大小取16的整数倍。综合下来取8192或者16384都是合理区间。

提示：上面这个算法是给手动Tiling用的估算起点，实际还要看算子里有没有额外的中间buffer。有规约、有转置的算子，中间结果往往比输入还占地方，得重新算。

比手动算更省事的是自动Tiling。框架提供了一套根据算子输入形状和UB约束自动推导切分方案的机制，你只要把每个buffer的大小需求描述清楚，它会帮你算出合理的切分和循环次数。对于形状变化频繁的场景，自动Tiling是首选，写起来省心，适应性强。缺点是它保守，遇到极端形状可能切得不够优。

我的策略是：先上自动Tiling保证通用性，同时用profiling看几个典型形状的耗时，如果发现某个高频形状明显拖后腿，再针对这个形状注册一套手动Tiling规则，两者并存，运行时按形状匹配。这样既覆盖长尾，又优化了头部。

4.2 对齐这件事，差一个字节就差一截性能

32字节对齐这条规则，几乎所有TBE的文档都会提，但真正理解它为什么重要的人不多。硬件搬运数据是按block走的，一个block 32字节。如果你的起始地址没有按32字节对齐，硬件要么搬不了，要么得拆成两次搬再拼接，效率立刻打折。更麻烦的是，这种问题不会报错，只会让你的算子慢，而且慢得很隐蔽——profiling里看到的只是搬运时间变长，看不出具体原因。

具体要注意几个地方。一是GM上的张量起始地址，如果上游算子输出的形状不是32字节的整数倍，下一个算子的输入地址就可能不对齐。这时候要么在Tiling时把每块的大小凑成32字节的整数倍，要么在搬运用stride参数把不对齐的部分跳过去，单独处理。

二是UB内buffer的偏移。你在UB里连续声明好几个buffer，如果前一个的大小不是32字节整数倍，后一个的起始地址就歪了。我的习惯是声明时就把每个buffer的尺寸向上取整到16个fp16元素（也就是32字节），宁可浪费一点空间，也别让地址错位。

三是repeat之间的步长。用向量指令时，如果源数据在UB里不是连续排布，需要靠stride参数跨过去。stride的单位是block，算的时候得把元素数除以16再取整，除不尽就得调整buffer布局，改成连续排布。这一步算错是最常见的"结果对但慢"的原因。

4.3 双缓冲与多核：把搬运时间藏起来

一个算子跑得慢，profiling打开一看，往往不是计算单元忙，而是它在等数据。数据从GM搬到UB需要时间，如果搬完才开算、算完才搬下一块，那计算和搬运是串行的，总耗时等于两者之和。双缓冲要解决的就是这个：准备两块buffer，搬块A的同时算块B，算完B的时候A已经搬好了，如此交替，总耗时趋近于两者中的较大值。

实现上，双缓冲需要配合事件同步。标准写法是给每块buffer配一对事件，搬运前等对应事件、搬运后置位，计算前等搬运完成事件、计算后置位。这套逻辑在TIK里有现成的封装，但参数得自己算对，事件数量和buffer数量要匹配，少配一个就会死锁或者读到脏数据。

# 双缓冲骨架示意 for i in range(loop_times): cur = i % 2 if i >= 2: tik_instance.wait_event(evt_calc[cur]) tik_instance.data_move(ub[cur], gm[i * tile], 0, 1, burst, 0, 0) tik_instance.set_event(evt_load[cur]) tik_instance.wait_event(evt_load[cur]) tik_instance.vec_add(repeat, out_ub[cur], ub[cur], ub[cur], 1, 8, 8) tik_instance.set_event(evt_calc[cur])

注意：双缓冲的收益不是线性的。搬运时间远大于计算时间时，重叠能带来的提升有限，这时候该优化的是搬运本身，比如减少搬运次数、增大单次搬运块大小。反过来计算远大于搬运时，双缓冲收益也不明显。它最见效的场景是两者量级相当，重叠后总耗时能砍掉将近一半。

多核并行是另一条路子。一个AI Core的算力有限，多个Core同时干活能把吞吐拉上去。做法是把总数据按核数切分，每个核处理一段连续的区间。切分时同样要考虑对齐，不能让某个核的起始地址歪掉。核数也不是越多越好，切得太碎，每个核的启动开销和尾块处理成本会吃掉并行收益。经验值是单核处理的数据量不要低于几十KB，低于这个量级并行反而变慢。

实测过一组数据，同样是形状为4096×4096的fp16逐元素加法：单缓冲单核跑下来大约是基准值，改成双缓冲后耗时降到约六成，再叠加上8核并行，最终耗时压到基准的两成出头。这个提升幅度在不同算子上会有差异，但量级大致如此。

5. 那些年踩过的坑：问题排查实录

5.1 结果不对但测试通过：融合引入的坑

最让人头疼的一类问题是单算子测试全绿，集成到模型里精度就掉。这种情况八成是算子融合惹的祸。图引擎在优化阶段会把相邻的算子合并成一个融合算子，如果融合规则写得不对，或者你的算子在融合场景下的行为与单独执行时不一致，就会出问题。

排查思路是从融合边界入手：先把融合关掉，用纯单算子跑一遍，确认结果正确；再打开融合，看从哪一层开始输出出现偏差。定位到具体融合规则后，检查它的输入输出映射是否完整、属性传递有没有遗漏。我遇到过一次，融合规则里漏传了一个epsilon属性，融合后这个值取了默认的1e-5，而实际模型里传的是1e-3，精度自然对不上。

还有一类是内存复用导致的。图引擎会做内存规划，让生命周期不重叠的张量共用一块GM。如果你的算子存在异步操作——比如搬运还没完成就返回了——那这块内存可能已经被下一个算子覆写了。这种问题在单算子测试时不会暴露，因为只有它自己在用那块内存。解决办法是把同步点补全，确保所有异步操作完成后再返回。

5.2 性能断崖式下跌：先看对齐再看Tiling

性能问题我一般按这个顺序查：先看profiling里各个引擎的占用率，再看搬运和计算的时间占比，最后看是不是有明显的等待空洞。

如果发现搬运的带宽利用率极低，第一个怀疑对象就是对齐。用工具把每次搬运的起始地址、长度打出来，逐个对32取模，不整除的就是嫌疑。这种情况在小形状上尤其常见，比如某个张量总共就100个元素，按32字节切只能切出几个完整block，剩下全是尾块，怎么搬都慢。

如果发现计算单元经常空转，那多半是Tiling切得太碎，循环次数太多，每次循环的启动开销累积起来很可观；或者双缓冲没配对，导致计算在等搬运。还有一种可能是核数设得太多，每个核分到的数据量太少，并行收益被启动开销抵消。

如果发现整体耗时比理论值高出好几倍，检查一下是不是插入了格式转换算子。前面提过，信息库里format写错会导致框架自动插入转换，这个转换算子本身也要花时间，而且往往是在你最不希望有额外开销的地方出现。

5.3 编译期报错：八成是契约没对齐

编译报错里最常见的是两类：一类是接口参数不匹配，一类是buffer超限。

接口参数不匹配大多是信息库和实现没有对齐。信息库里声明了三个输入，实现里只处理了两个；或者信息库里写的是ND格式，实现里按NZ来搬。这类问题的特点是报错信息指向性较强，通常会点出是哪个输入、哪个字段的问题，照着改就行。

buffer超限是指你申请的总UB空间超过了物理容量。TBE在编译期会做静态检查，超了直接报错。这里要注意的是双缓冲会让占用翻倍，很多人算的时候按单缓冲算的，开了双缓冲就超了。还有一种情况是编译期看不出来、运行期才炸的——动态Tiling时根据实际形状算出的buffer大小超限，这种情况得在Tiling函数里做好上限保护，超出就降档。

5.4 动态形状：最容易翻车的地方

动态形状是算子开发里的深水区。模型里很多算子的输入形状要到运行期才能确定，比如序列长度可变、batch大小可变，这时候Tiling就没法在编译期算死了。

标准做法是把Tiling逻辑拆出来，做成一个能在运行期执行的函数，输入是运行时的形状，输出是切分方案和循环参数。设备侧的执行代码则通过参数接收这些运行时信息，不在代码里写死。听起来简单，实际做的时候有两个坑：一是Tiling函数的输出要能正确传到设备侧，参数传递的顺序和类型必须严格匹配；二是设备侧代码里不能有任何依赖编译期形状的常量，包括buffer大小和循环边界，这些都得在运行期读。

我见过一个更隐蔽的坑：Tiling函数里用了整数除法，形状不能整除时结果向下取整，导致最后一块数据没被处理到。单算子测试用的是能整除的形状，一路通过；换成实际模型的不规则形状，尾部数据静默丢失。这类问题不会报错，只会让精度缓慢下降，查起来极费劲。稳妥做法是Tiling里所有除法都显式处理余数，尾块单独走一条分支。

5.5 几条掏心窝子的实操建议

第一，先跑通再优化，别一上来就冲着极限性能去。我见过不少人第一版就手写TIK加双缓冲加多核，结果卡在精度不对上，回头一查是Tiling算错了，前面所有优化工作全部作废。正确顺序是先DSL出正确版本，验证精度，再用TIK重写，重写时保持同样的Tiling参数和逻辑，只改实现方式，这样出问题容易对比定位。

第二，善用编译期的静态检查。TBE在编译阶段会做大量校验，包括地址对齐、buffer越界、参数类型。这些检查虽然有时报错很啰嗦，但都是免费的护城河，别想着绕过。遇到检查报错就老老实实改代码，绕过去的问题迟早会在运行期找回来。

第三，无论如何都要准备一组"脏数据"用例。常规的随机测试覆盖不到极值、零、负数、非常规形状，而这些恰恰是线上最容易出问题的地方。我的习惯是每个算子至少准备五组数据：随机、全零、全最大、含负数、不能整除的形状。这五组过完，心里才踏实。

第四，profiling数据要看趋势不要只看单点。某一次运行慢可能是噪声，连续多次都慢才是真问题。看的时候关注三类指标：Cube和Vector的占用率、各级搬运的带宽、以及等待事件的耗时。这三个数字能覆盖绝大多数性能问题的方向。

第五，算子命名和版本管理要有规矩。模型里同一个算子可能同时存在内置版本和自定义版本，命名不清晰很容易调错。我一般会在自定义算子名里带上明确的标识和版本号，配置文件里也标注清楚，避免上线时张冠李戴。

写到这里，最后分享一个我觉得最值钱的习惯：每次调完一个算子，把关键的Tiling参数、踩过的坑、以及当时的profiling截图整理成一份短文档存起来。半年后再遇到类似形状的算子，翻出来改改就能用，比从头推一遍快得多。TBE这套东西细节太多，靠脑子记不住，靠文档才能滚雪球。