★ FEATURED ARTICLE 做深度学习工程的人大概都经历过这种尴尬模型在 Python 里跑得挺好某一段前处理或者某个新激活函数的性能就是上不去翻遍算子库也没有现成实现。于是你动手写了一个 C 扩展算子本地训练验证一切正常可到了要去端侧、去异构硬件上推理的那一步模型导出成一纸交换格式自定义算子在里面变成了一个谁也不认识的空壳节点runtime 直接报找不到算子实现。这条链路——PyTorch 自定义 C 拓展算子、导出交换格式模型、再到运行时部署——是近两年我见得最多、也踩坑最多的技术路径之一。它的核心价值在于你既拿到了接近底层的算子性能又保住了模型的可移植性不至于被某一个训练框架彻底绑死。但它不像调一个 API 那么简单中间横跨三种语言、两套类型系统、两种算子注册机制任何一环没对齐报错信息都极其抽象。这篇文章面向的是已经能跑通普通模型导出、但卡在自定义算子怎么活着走到部署端这一步的开发者。下面我会用一个虚构的小算子暂称relu6融合缩放算子作为贯穿案例把工程骨架、注册规范、符号映射、运行时适配、数值对齐这条完整链路拆开讲每一步都说说为什么这么做以及我实际踩过的那些坑。1. 自定义算子的落地路线怎么选三条路的真实取舍1.1 先想清楚你为什么要写 C 算子在动手写第一行 C 之前值得先问自己一个问题这个算子非写 C 不可吗我在实际项目里见过太多为了性能而写结果性能反而更差的案例。常见的三个真实动机优先级其实是不一样的。第一种是算子库确实缺。比如某个新论文里的激活函数、某种特殊的归一化方式、某个带方向参数的池化变体。这类需求的本质是表达能力不够Python 层拼几个基础算子理论上能凑出来但中间张量一多显存和带宽就先崩了。第二种是性能敏感的前后处理。比如图像解码后的归一化加通道重排用 Python 写要循环几十次在 C 里一次遍历就做完了这类收益非常实在。第三种是算子融合把三个小算子合成一个 kernel减少访存次数这个收益最大但也最难做对。我自己的判断标准是如果这个算子在前向里被调用次数很少、且不在瓶颈路径上那纯 Python 实现完全够用写 C 反而是负债——多了一份需要维护、需要编译、需要跨平台适配的代码。只有当你在 profiler 里明确看到它占了可观的耗时比例或者它确实无法用现有算子表达时才值得上 C。案例设定上我用了relu6的变体y clamp(x * scale, 0, 6)其中scale是一个编译期不确定的 float 参数。这个算子在数学上极其简单但它同时具备三个教学价值——有额外标量参数考验 schema 设计、有反向传播考验 Autograd 注册、形状推理是逐元素考验 meta 实现而且真实业务里缩放 截断的融合确实常见。1.2 三条路线的横向对比为了让选择更有依据我把常见的三种落地方式列了个表都是我在不同项目里真实用过的路线训练侧性能部署侧性能移植难度适用场景纯 Python 组合算子一般一般极低调用频率低、非瓶颈图编译器自动融合好取决于后端中目标是单一硬件栈自定义 C 算子 交换格式 运行时好好高多硬件、多端部署纯 Python 组合的上限很明显Python 解释器开销、多次 kernel launch、中间张量显存占用三座大山压着一旦进入高频调用路径就没救了。图编译器路线在这两年进步很大但对它不认识的新算子依然束手无策你只能退回去用它能理解的算子重写。自定义 C 算子路线最大的代价是工程复杂度。你需要维护一份 C 源码、一套编译配置、一份符号映射、以及部署端的算子库。换来的是算子行为完全可控、可以针对特定硬件手写优化、导出后依然能保持结构完整。提示如果你的团队只有一两个人做推理部署且模型里自定义算子数量少于三个我建议优先考虑用现有算子等价重写而不是引入自定义算子。维护成本经常被低估。1.3 这条链路上真正的难点在哪很多人以为难点在写 C其实不是。写一个正确的前向 kernel 对熟悉 C 的人来说一天就能搞定。真正的难点是三个翻译环节第一是类型系统的翻译。Python 侧的torch.Tensor、C 侧的at::Tensor、交换格式里的TensorProto、运行时侧的Ort::Value四套类型各有各的生命周期和内存语义转换时机的选择直接决定了你会不会遇到悬垂指针。第二是算子注册机制的翻译。训练框架有一套分派机制按设备类型、按是否求导分派交换格式有一套算子定义规范域 算子名 属性运行时又有第三套注册接口。三者的名字必须严格对齐差一个字符就是算子未找到。第三是数值语义的翻译。训练侧默认 float32、某些算子内部可能用 double 累加、运行时可能开图优化把相邻算子折叠掉这些差异在简单模型上看不出来在深层网络上会累积成可观误差。我见过最典型的一次翻车算子在前向里用了int做索引计算训练时 batch size 小没溢出部署时 batch 变成几百索引乘法溢出成负数读到了错误的内存区域输出是一堆看起来合理但完全错误的数值。这种 bug 根本不会报错只能靠逐层比对抓出来。2. 工程骨架与注册规范让算子先在自己的框架里跑通2.1 目录结构与构建方式的选择构建自定义扩展有两种主流方式一是直接用即时编译接口torch.utils.cpp_extension.load二是走标准的setuptools打包流程。前者适合快速验证改一行编译一次反馈快后者适合长期维护产出的是可安装的 wheel 包便于在 CI 里复现。我的建议是验证阶段用即时编译稳定后立刻切到 setuptools。因为即时编译的缓存机制在多人协作、多 CUDA 架构的环境下经常抽风而且它默认把编译产物丢到用户缓存目录版本管理非常混乱。一个能长期维护的目录结构大概是这样的myops/ ├── setup.py ├── myops/ │ ├── __init__.py │ ├── _C.py # 加载编译产物 │ └── symbolic.py # 交换格式符号映射 └── csrc/ ├── ops.cpp # 算子实现与注册 └── ops_onnx.cpp # 部署端算子实现setup.py里的关键配置项我一般会写死这几条from setuptools import setup from torch.utils.cpp_extension import BuildExtension, CppExtension setup( namemyops, ext_modules[ CppExtension( namemyops._C, sources[csrc/ops.cpp], extra_compile_args[-O3, -stdc17, -fvisibilityhidden], ) ], cmdclass{build_ext: BuildExtension.with_options(use_ninjaTrue)}, )这里三个编译参数都有讲究。-O3是必须的否则模板展开后的代码性能会差一大截。-stdc17是因为较新的框架头文件已经要求这个标准了低于它编译会失败。-fvisibilityhidden是我踩过坑之后加的默认符号全部导出会让动态库体积膨胀、加载变慢而且不同扩展之间的符号可能冲突导致莫名其妙的段错误。use_ninjaTrue在多文件场景下能把编译时间从几分钟压到几十秒但如果你的机器没装ninja构建会直接失败所以 CI 脚本里记得先把依赖装上。2.2 算子注册的三件套schema、实现、求导框架的算子注册机制本质上是先声明再实现。声明用一段类似函数签名的字符串描述入参、出参和默认值实现则按不同的分派键设备类型、是否处于求导模式分别注册。三者缺一不可。声明部分#include torch/extension.h TORCH_LIBRARY(myops, m) { m.def(relu6_scale(Tensor x, float scale, float max_val6.0) - Tensor); }这段 schema 字符串不是随便写的它定义了算子的对外契约输入是一个张量加两个浮点标量输出是一个张量max_val有默认值。部署端解析节点属性时就是靠这段字符串里的参数名去找对应的属性字段。参数名一旦发布就不能随便改因为交换格式文件里存的是属性名字符串改了名老模型就加载不了。设备实现部分torch::Tensor relu6_scale_cpu(torch::Tensor x, double scale, double max_val) { TORCH_CHECK(x.scalar_type() torch::kFloat32, only float32 supported); return torch::clamp(x * scale, 0.0, max_val); } TORCH_LIBRARY_IMPL(myops, CPU, m) { m.impl(relu6_scale, relu6_scale_cpu); }求导实现部分我习惯用torch::autograd::Function封装而不是手写backwardclass Relu6ScaleFunction : public torch::autograd::FunctionRelu6ScaleFunction { public: static torch::Tensor forward(torch::autograd::AutogradContext* ctx, torch::Tensor x, double scale, double max_val) { ctx-saved_data[scale] scale; ctx-saved_data[max_val] max_val; ctx-save_for_backward({x}); return torch::clamp(x * scale, 0.0, max_val); } static torch::autograd::tensor_list backward( torch::autograd::AutogradContext* ctx, torch::autograd::tensor_list grad_outputs) { auto saved ctx-get_saved_variables(); auto x saved[0]; auto scale ctx-saved_data[scale].toDouble(); auto max_val ctx-saved_data[max_val].toDouble(); auto grad grad_outputs[0]; auto mask (x * scale 0.0) (x * scale max_val); return {grad * mask.to(grad.dtype()) * scale, torch::Tensor(), torch::Tensor()}; } }; TORCH_LIBRARY_IMPL(myops, Autograd, m) { m.impl(relu6_scale, TORCH_FN(Relu6ScaleFunction::apply)); }这里有个细节值得单独说反向返回的列表长度必须和 forward 的入参数量严格一致标量参数对应位置要返回空张量torch::Tensor()。我第一次写的时候只返回了一个运行时直接报返回的梯度数量不匹配排查了半天才发现是标量占位的问题。还有一个隐蔽的坑saved_data里存的标量在反向时读出来是IValue类型得用toDouble()显式转换。如果你存的是int64却用toDouble()读不会报错但会得到诡异的数值这个我在调一个量化算子时中招过。2.3 meta 实现这一步不做导出一定会挂三件套之外还有第四件很多人第一次写扩展时会漏掉——形状推理实现也叫 meta 实现或 fake 实现。它的作用是在不真正分配内存的前提下告诉框架如果这个算子被执行输出张量应该长什么样、是什么类型、在哪个设备上。TORCH_LIBRARY_IMPL(myops, Meta, m) { m.impl(relu6_scale, [](const torch::Tensor x, double scale, double max_val) { return torch::empty_like(x); }); }为什么这一步是必需的因为现代导出流程会先在一个符号化的假张量上跑一遍前向用来推导整张图的形状和类型信息。如果你的算子没有 meta 实现框架就会退化成真的分配一块内存去执行——在小模型上这可能只是慢一点但在大模型上直接显存爆掉更糟的情况是导出的图里形状信息标成动态未知部署端每帧都要重新做形状推导性能掉一大截。我遇到过一个更隐蔽的后果缺少 meta 实现时某些导出路径会把这个算子整体当成不透明节点处理后续的常量折叠、算子融合全部失效。你以为只是少了个形状推断实际上整个图优化的收益都没了。顺带一提meta 实现里我用了torch::empty_like等于声明输出和输入形状、类型完全一致。如果你的算子会改变形状比如池化这里必须精确算出来不能图省事。曾经有同学在池化算子里也写empty_like结果导出的图里形状标注是错的运行时输入尺寸一变就崩而且报错信息指向的是离池化十万八千里的另一个节点。2.4 编译阶段最容易撞上的三个问题问题一ABI 不一致。如果你的扩展依赖的第三方库用了不同的 C ABI 设置加载时会报undefined symbol或者更糟——加载成功但调用时崩溃。解决办法是在setup.py的编译参数里显式加上-D_GLIBCXX_USE_CXX11_ABI0或者 1取决于你依赖的库保持和主框架一致。问题二CUDA 架构没对齐。如果你的扩展要跑在多种显卡上编译时得指定多个目标架构。只编一个架构的话换一张卡就是no kernel image is available。这个报错非常常见尤其是把开发机上的产物直接拷到部署机上。问题三头文件路径污染。同一台机器上装了多个版本的框架编译时用 A 版本的头文件、运行时加载 B 版本的主库症状是注册的算子找不到。我的做法是在_C.py加载时打印实际加载的动态库路径把这个信息写进日志出问题第一件事就是核对路径。3. 导出交换格式让自定义算子不在图上变成黑洞3.1 默认导出会发生什么把上面写好的算子直接导出图里会出现一个形如myops::relu6_scale的节点。它带着一个自定义的域前缀属性也原样带过去了但部署端的运行时根本不认识这个名字。加载模型时会直接报错找不到该域下的算子实现。这就是整条链路上最关键的一道坎。解决办法有四种按实现难度从低到高排列我建议先试最简单的不行再往下走。3.2 走法一映射到标准算子如果自定义算子的语义恰好能用标准算子表达这是最省事的方案。上面的案例里clamp(x * scale, 0, 6)完全可以拆成乘法 截断两个标准算子。import torch from torch.onnx import register_custom_op_symbolic def relu6_scale_symbolic(g, x, scale, max_val6.0): scaled g.op(Mul, x, g.op(Constant, value_ttorch.tensor(scale, dtypetorch.float32))) return g.op(Clip, scaled, min_f0.0, max_fmax_val) register_custom_op_symbolic(myops::relu6_scale, relu6_scale_symbolic, 17)注意这里的17是算子集版本号。版本号不匹配时注册会静默失效导出时依然得到自定义域名。这个问题极其难查因为不报错。我的习惯是注册完之后立刻导出一次并打印图里所有节点的op_type确认没有残留的自定义前缀再往下走。映射到标准算子的好处很明显部署端不需要任何额外适配任何支持该算子集版本的运行时都能加载。坏处是性能收益会打折——你原本写 C 是为了融合成一个 kernel现在又拆回两个节点了如果运行时没有做算子融合性能可能还不如纯 Python 版本。所以这个方案适合语义能对上、且性能不那么敏感的场景。3.3 走法二用基础算子拼出等价结构有些算子无法直接对应单个标准算子但可以用一组标准算子组合出来。比如某种带权重的归一化拆成减均值、除标准差、乘权重、加偏置四步。这种方案的实现方式是在符号函数里连续调用g.op构造子图。代价是图会变大节点数增加而且一旦组合逻辑写错数值对不上时排查会很痛苦。我的经验是组合节点数超过五个就不要再拼了直接走自定义域方案更划算因为调试成本比性能收益高得多。3.4 走法三保留自定义域 部署端提供实现这是保性能最彻底的方案。导出时不做任何映射让节点带着自定义域原样落到文件里部署端则注册一份同名同签名的算子实现。导出侧不需要额外代码但要确认两件事一是算子集版本足够新低于 15 的版本对自定义域支持不好二是导出时不要开启过于激进的图优化某些优化器会因为不认识这个算子而把它删掉或者改错。部署侧的注册Python 接口大概是这样import onnxruntime as ort opts ort.SessionOptions() opts.register_custom_ops_library(./libmyops_runtime.so) sess ort.InferenceSession(model.onnx, opts, providers[CPUExecutionProvider])而那个.so的实现核心是一个继承自自定义算子基类的结构体需要覆写四个方法构造函数描述输入输出数量和类型、Compute真正的计算、GetInputMemoryType内存类型声明、以及可选的GetMayInplace。这里最容易出错的是输入输出数量必须和导出时的 schema 完全一致包括标量参数算不算输入。注意标量参数在交换格式里通常是作为节点属性存在的不占输入槽位。但如果你在导出时把标量转成了张量再传进去它就会变成一个输入。这两种情况在部署端的算子实现写法完全不同一定要在导出后打开文件看一眼节点的input数量和attribute列表。3.5 导出参数与上线前的检查清单不管走哪种方案导出这一段的参数配置都值得仔细过一遍torch.onnx.export( model, dummy_input, model.onnx, opset_version17, input_names[input], output_names[output], dynamic_axes{input: {0: batch}, output: {0: batch}}, do_constant_foldingTrue, dynamoFalse, )几个参数的意义和踩坑点opset_version要和你部署端运行时支持的版本区间取交集太高导出的模型老运行时加载不了太低某些算子表达不出来。dynamic_axes是必填项如果你的业务输入 batch 会变不声明的话导出的图会硬编码形状部署时换 batch 就报错。do_constant_folding开启后会把能算的常量提前算掉图会小很多但如果你的自定义算子有副作用比如写文件折叠会导致副作用被执行两次或零次。dynamoFalse这个参数值得单独说。较新的框架版本默认走的是新的导出路径它对新算子的兼容性和老的追踪路径不一样。我在一个项目里遇到过新路径下自定义算子的属性丢失了一半换成老路径就正常。如果你在导出后发现属性缺失第一件事就是试试切回老路径。导出完成后上线前我固定会跑这三个检查检查项方法不通过说明图结构合法性结构校验工具属性类型或必需字段有问题无残留自定义域若走映射方案遍历节点打印域前缀符号映射没生效输入输出形状与类型打印图输入输出信息动态维度声明有误另外强烈建议做一次图简化。简化器能合并冗余节点、折叠常量、把某些冗余的转置消掉。我见过一个模型简化后节点数从 1200 降到 400推理延迟直接降了将近三成。但简化有风险——如果简化器不认识你的自定义算子可能会把它和前后节点错误合并。所以简化之后必须重跑一遍数值比对不能想当然。4. 运行时侧部署会话配置比算子实现更容易出问题4.1 会话配置的五个关键项模型能加载不等于跑得快。运行时的会话配置项很多但真正影响生产环境的一共就那几个配置项作用我的常用值图优化级别控制融合、折叠的激进程度全部优化线程数控制算子内部并行度物理核数执行模式串行还是并行执行节点串行低延迟场景内存模式是否复用中间张量内存开启日志级别排错时临时提升生产环境关闭图优化级别这里有个权衡全部优化性能最好但如果你的自定义算子参与了错误的融合结果会错。我一般会在第一次部署时用较低级别跑一遍作为基准确认数值正确后再切到全部优化对比两者结果。如果结果不一致说明融合逻辑有问题这时候要么关掉特定优化要么在算子上标注不可融合。线程数不是越多越好。在服务端多并发场景下每个会话内部开满线程会导致线程超订实际吞吐反而下降。我的做法是把会话内的线程数设成较小值比如 2靠外层请求并发来吃满 CPU。4.2 自定义算子库的加载时机如果你走的是自定义域方案算子库的加载顺序很讲究。必须在创建会话之前完成注册否则会话初始化时就已经判定算子缺失并抛异常了。另一个坑是动态库的依赖链。你的算子库可能依赖数学库、依赖框架的运行时库如果这些依赖不在系统搜索路径里加载时会报找不到符号。稳妥的做法是给算子库设置RPATH把依赖目录写死进去而不是依赖环境变量。我吃过一次亏开发机上环境变量配得好好的上了容器环境变量没继承加载直接失败而错误信息只说是无法加载库完全没提依赖缺失。Python 侧注册还有个细节register_custom_ops_library接受的路径最好用绝对路径。相对路径在不同工作目录下表现不一致尤其是在容器里启动时工作目录往往是根目录。4.3 输入输出的内存绑定默认情况下每次推理都要把数据从你的内存拷进运行时的内存再把输出拷回来。对于小张量这没什么但对于大分辨率图像或者长序列这两次拷贝能占到总耗时的两三成。优化手段是绑定输入输出内存让运行时直接在你的缓冲区上计算。核心思路是先创建一个绑定对象把输入缓冲区绑定到指定输入名上然后调用带绑定的推理接口最后从绑定的输出上取结果。io sess.io_binding() io.bind_cpu_input(input, input_array) io.bind_output(output) sess.run_with_iobinding(io) result io.copy_outputs_to_cpu()[0]这段代码看起来简单但有几个必须注意的地方。第一绑定的输入内存必须是连续且对齐的如果你的数组是某个大数组的切片很可能不连续结果就是读到垃圾数据。第二绑定的输出在调用完成后才有效提前访问会拿到未初始化的内存。第三如果你的模型有多个输出而只绑定了一个运行时不会报错但另一个输出会消失。我实际测下来在 1080p 图像输入、中等规模网络的场景下绑定内存相比默认路径能省 15% 到 25% 的耗时输入越大收益越明显。但如果你的输入本身就是从别的框架张量转过来的转换本身就要拷贝一次那收益会被抵消这种情况得先看看能不能让上游直接产出连续内存。4.4 量化部署时自定义算子的额外工作如果部署端要做低精度量化自定义算子会带来额外麻烦。量化工具通常只认识标准算子遇到自定义域的节点会直接跳过导致这张图里一部分是量化算子、一部分是浮点算子中间还得插入类型转换节点反而更慢。我的处理原则是能在量化前映射成标准算子的就不要保留自定义域。如果确实必须保留那就得手写量化版本的算子实现也就是同时提供浮点和定点两套 kernel并且保证两者的数值误差在可接受范围内。这部分工作量不小得有心理准备。另外量化之后一定要做完整的数据集级比对不能只测几张图。我见过量化误差只在特定输入分布下才暴露的情况单张测试图完全看不出来上线后才发现某类样本全错。5. 数值对齐与联调排错出错时按这个顺序查5.1 建立逐层比对的基线跨框架联调最有效的手段是把训练侧的中间结果逐层 dump 出来和部署侧逐节点比对。做法是给模型每一层挂钩子把输出存成二进制文件部署端则在每个节点后插入提取逻辑。比对时不要用绝对误差要用相对误差加绝对误差的组合判据相对误差看整体趋势绝对误差防止在接近零的值上相对误差爆炸。经验阈值是float32 情况下最大绝对误差低于 1e-5 基本可以认为一致如果超过 1e-3一定有语义问题而不只是精度问题。定位到第一个出错的节点之后问题范围就缩小到这一个算子。这时候再去看它的输入数据比较训练侧和部署侧的输入是否一致。如果输入就已经不同说明问题在上游继续往前找。5.2 常见差异来源对照表现象可能原因验证方式全部输出为零自定义算子没被调用走了空实现打印节点执行日志前几层正常后面崩某个算子的属性丢失检查文件里的属性列表小 batch 正常大 batch 错索引计算溢出或形状假设单测不同 batch 尺寸误差随层数累积累加精度不同float vs double对比中间层统计量某些通道全错内存布局或步长假设错误检查张量是否连续这张表里的每一条我都真实遇到过。其中索引计算溢出那条最坑因为它不报错、不崩溃只是输出微妙地不对。发现它靠的是一个朴素的办法把同一批数据在训练侧和部署侧各跑一遍然后把差值最大的那个位置索引打印出来看它是不是有规律地出现在某些特殊位置比如每 256 个元素一组靠这个规律反推出是整数位宽的问题。5.3 一个完整的排查链路复盘说一个印象比较深的案例。某次部署一个带自定义算子的检测模型输出框的坐标整体偏移了大约两个像素置信度却完全正常。第一步逐层比对发现自定义算子输出完全一致问题出在它后面的重排节点。第二步检查重排节点的输入形状发现部署侧的形状标注比训练侧少了一维——原来导出时这个节点的形状是从自定义算子的 meta 实现推出来的而 meta 实现里我图省事写了个通用形状没考虑特殊情况。第三步修正 meta 实现重新导出形状对上了但坐标还是偏。第四步比对重排后的数据发现偏移量恰好等于一个像素对应的归一化值反推到前处理阶段发现训练侧做归一化用的是像素中心对齐部署侧用的角点对齐差半个像素经过两次缩放放大成两个像素。整个排查花了将近两天其中一天半在第二步和第三步。这就是我为什么反复强调 meta 实现不能图省事——它错的时候报错点往往在很远的地方。5.4 我总结的联调纪律最后分享几条我用血换来的纪律都是些不起眼但能省大量时间的做法。第一写单元测试时就带上形状变化。每个自定义算子至少测三种形状单元素、典型尺寸、极端尺寸比如 1×1 特征图。很多 bug 只在极端形状下出现。第二导出产物要入库管理并带版本号。模型文件、算子库、运行时版本三者必须能对应上。我见过最混乱的情况是线上跑的是上个月的算子库配这个月的模型行为完全不可预测。第三任何改动后先跑小样本端到端。不要直接上全量测试集先拿十张图跑通确认误差在阈值内再扩大规模。这个习惯能让你在改动引入问题时五分钟内发现而不是半小时后拿到一堆无法归因的结果。第四给自定义算子加一个自检开关。在 C 实现里加一个可选的校验分支检查输入是否连续、是否有 NaN、形状是否符合预期调试期打开生产期关掉。这个开关帮我抓到过至少三次输入不连续导致读到错位数据的问题。第五别迷信跑通了就等于对了。能跑出结果和结果正确之间隔着一整个太平洋。每次部署新算子我都会拿训练侧的完整输出做一次全量比对包括最大值、最小值、均值、方差四个统计量任何一个对不上就不算通过。这套流程走下来确实繁琐但比线上发现问题再回滚要划算得多。我现在的习惯是新算子从写第一行代码开始就把比对脚本一起写好让它成为开发流程的一部分而不是上线前的最后一道关卡。我个人在实际操作中的体会是这条链路的复杂度并不集中在任何一个单点上而是集中在跨越这个动作上——每跨一次边界Python 到 C、框架到交换格式、文件到运行时就多一层需要显式对齐的契约。写代码的时候多花十分钟把 schema 和 meta 实现写严谨后面能省下好几个小时的排查。真正稳定跑起来的自定义算子往往不是性能最强的那个而是契约写得最清楚的那个。
阅读完成 · 觉得有帮助？
