人工智能深度学习算子库CANNAscend【免费下载链接】asc-devkit本项目是CANN 推出的昇腾AI处理器专用的算子程序开发语言原生支持C和C标准规范主要由类库和语言扩展层构成提供多层级API满足多维场景算子开发诉求。项目地址https://gitcode.com/cann/asc-devkit点击查看免费下载在 asc-devkit 提供的 Tiling 调测工具链中ContextBuilder::NodeIoNum是最基础也最容易被忽视的一步——它负责声明算子 IR 原型定义中的输入与输出个数是后续AddInputTd、AddOutputTd、BuildTilingContext等接口能够正确构建TilingContext的前提。读懂这个接口及其与IrInstanceNum的协作关系你才能在脱离框架环境的情况下独立调测 Tiling 函数复现框架内部构造上下文的完整过程。一、NodeIoNum 在 ContextBuilder API 体系中的位置ContextBuilder 类 是 asc-devkit 为 Tiling 调测提供的核心工具位于context_ascendc命名空间下支持两类上下文的手动构造TilingContext用于单独验证 Tiling 函数Tiling 函数的入参正是gert::TilingContext*KernelContext用于验证 TilingParse 函数KernelRunContext 场景。框架在实际运行时会负责构造TilingContext并调用 Tiling 函数而在工程化算子开发中若需要单独进行 Tiling 调测就需要用ContextBuilder手动构建等价上下文。完整的构建链路见 ContextBuilder 简介 与 如何进行Tiling调测// 构造TilingContext auto tilingContextHolder context_ascendc::ContextBuilder() .SetOpNameType(..., ...); // 算子名/算子类型 .NodeIoNum(...); // 声明算子IR原型定义的输入输出个数本文主角 .IrInstanceNum(...); // 声明每种输入的实际实例化个数 .AddInputTd(...); // 逐个补充输入Tensor描述 .AddOutputTd(...); // 逐个补充输出Tensor描述 .AddAttr(...); // 补充算子属性 .BuildTilingContext(...); // 完成构建 gert::TilingContext* tilingContext tilingContextHolder-GetContextgert::TilingContext();NodeIoNum处于该链路的骨架声明环节它先确定算子的输入/输出规模后续的AddInputTd/AddOutputTd才有索引空间可填BuildTilingContext也据此分配内部 Tensor 占位。二、函数原型与参数说明2.1 函数原型ContextBuilder NodeIoNum(size_t inputNum, size_t outputNum)接口声明位于 context_builder.h处于ContextBuilder类的 OpInfo 区域与SetOpNameType、IrInstanceNum等接口并列。2.2 参数说明参数输入/输出说明inputNum输入算子 IR 原型定义中的输入个数outputNum输入算子 IR 原型定义中的输出个数注意这里的语义是**原型定义prototype**层面的计数它描述的是算子在 IR 层面有几路输入、几路输出而不是运行时实际张量个数。对于含动态输入同一路输入可能实例化多个 Tensor的算子二者会不一致——这正是必须配合IrInstanceNum的原因详见第四、五节。2.3 返回值返回当前 ContextBuilder 对象引用类型从而支持连续链式调用。所有ContextBuilder配置接口均遵循这一 Builder 模式约定例如auto builder ContextBuilder().NodeIoNum(5, 3); // 该算子有5个输入3个输出2.4 约束说明原文档核心约束必须配合 IrInstanceNum 一同使用。IrInstanceNum(std::vectoruint32_t instanceNum)基于算子的 IR 定义按照输入的 index 顺序声明每种输入在实例化时的实际个数。例如context_ascendc::ContextBuilder builder; (void)builder.NodeIoNum(5, 3) // 算子有5种输入3种输出 .IrInstanceNum({1, 1, 3, 1, 1}); // index为2的动态输入有3个实例此外AddInputTd 的约束说明也明确要求调用AddInputTd前需要先调用NodeIoNum与IrInstanceNum接口且输入的 index 需要基于算子 IR 定义、按照IrInstanceNum声明顺序来排布。也就是说NodeIoNum不仅是接口使用顺序上的第一环其声明的规模还直接决定AddInputTd的合法索引范围。三、从源码看实现一次调用背后发生了什么3.1 公共接口只做转发与防护ContextBuilder::NodeIoNum 的实现非常薄ContextBuilder ContextBuilder::NodeIoNum(size_t inputNum, size_t outputNum) { ASCENDC_ASSERT(impl_ ! nullptr, return *this, CXT_ASCENDC_LOGE(impl_ is nullptr!)); impl_-NodeIoNum(inputNum, outputNum); return *this; }先通过ASCENDC_ASSERT校验内部实现指针impl_有效无效时打日志并原样返回*this保持链式调用不中断再转发给 ContextBuilderImpl::NodeIoNumvoid ContextBuilderImpl::NodeIoNum(size_t inputNum, size_t outputNum) { ASCENDC_ASSERT(tilingCtxBuilder_ ! nullptr, return, CXT_ASCENDC_LOGE(tilingCtxBuilder_ is nullptr!)); tilingCtxBuilder_-IONum(inputNum, outputNum); inputNum_ inputNum; outputNum_ outputNum; }这里做了两件事把输入/输出个数写入底层构建器gert::OpTilingContextBuilder的IONum在ContextBuilderImpl内部缓存inputNum_与outputNum_成员见 context_builder_impl.h供后续构建流程使用。3.2 默认值与构建时序ContextBuilderImpl 的构造函数 中底层构建器初始化为占位的IONum(1, 1)tilingCtxBuilder_-OpName(default_name).OpType(default_type).IONum(1, 1); kernelCtxBuilder_-OpName(default_name).OpType(default_type).IONum(1, 1);从源码结构看如果不调用NodeIoNum算子会被默认按1 输入 1 输出处理——这与大多数算子的真实原型不符因此文档才会强调NodeIoNum必须与IrInstanceNum配套显式声明。3.3 关键细节inputNum_ 会被 IrInstanceNum 改写这是理解原型个数 vs 实例个数的关键。看 ContextBuilderImpl::IrInstanceNumvoid ContextBuilderImpl::IrInstanceNum(std::vectoruint32_t instanceNum) { ASCENDC_ASSERT(tilingCtxBuilder_ ! nullptr, return, CXT_ASCENDC_LOGE(tilingCtxBuilder_ is nullptr!)); tilingCtxBuilder_-IOInstanceNum(instanceNum, std::vectoruint32_t(outputNum_, 1)); uint32_t inputIstNum 0; for (const auto num : instanceNum) { inputIstNum num; } inputNum_ inputIstNum; // 用实例化总数覆盖原型个数 }注意两点它调用IOInstanceNum(instanceNum, std::vectoruint32_t(outputNum_, 1))——输出侧的实例数向量长度直接取自NodeIoNum声明的outputNum_每个输出默认 1 个实例。若未先调用NodeIoNum这里会用默认值 1输出侧实例结构就不对了它把inputNum_改写为instanceNum各元素之和即输入侧的实际张量总数。再看 BuildTilingContext 实现 中inputNum_/outputNum_的最终用途std::vectorstd::unique_ptruint8_t[] tensorValueVec(inputNum_); std::vectorstd::unique_ptruint8_t[] tensorValueVecOut(outputNum_); std::vectorgert::Tensor* tensorVec(inputNum_, nullptr); for (size_t i 0; i inputNum_; i) { auto iter dependTensorsData_.find(static_castint32_t(i)); if (iter ! dependTensorsData_.end()) { tensorValueVec[i] std::move(iter-second); tensorVec[i] reinterpret_castgert::Tensor*(tensorValueVec[i].get()); } }dependTensorsData_是按AddInputTd传入的 index 存张量的哈希表构建时按[0, inputNum_)逐位取出来挂到gert::OpTilingContextBuilder::InputTensors上。由此可以推断出三条实用结论动态输入场景下AddInputTd的 index 是实例展开后的连续索引而不是原型 index。以 AddInputTd 文档示例为例NodeIoNum(5, 1)IrInstanceNum({1, 1, 2, 1, 1})表示原型 index 2 有 2 个动态实例实例展开后需要AddInputTd(0..5)共 6 次调用原型 index 3、4 分别落在实例索引 4、5 上AddInputTd的 index 必须落在[0, inputNum_)内。index 越界的张量不会出现在最终tensorVec中查找不到对应条目上下文里的输入规模与声明不符Tiling 函数读到的形状/描述可能错位调用顺序敏感IrInstanceNum会覆盖inputNum_若先调IrInstanceNum再调NodeIoNuminputNum_会被还原回原型个数与实例总数不一致张量槽位分配就会出错。因此推荐的固定顺序是SetOpNameType → NodeIoNum → IrInstanceNum → AddInputTd/AddOutputTd/AddAttr → BuildTilingContext这也是 intro 文档 示例的顺序。3.4 构建失败的前置防护BuildTilingContext在构建前会检查errFlag_任一AddInputTd中 shape 非法、bin 文件读取失败、常量数据转换失败等都会置位该标志见 AddInputTd 各重载实现置位时直接打Build Context Error!日志并返回nullptr。所以调试时若holder为nullptr应优先回查NodeIoNum/IrInstanceNum声明与AddInputTd数据是否一致。四、实战在 Tiling 调测流程中使用 NodeIoNum如何进行Tiling调测 给出了完整的独立调测流程NodeIoNum是其中第二步构建 TilingContext的核心一环。该流程包括四步完成算子实现并通过算子包编译或算子动态库编译获取 Tiling 动态库liboptiling.so或libcust_opapi.so编写测试代码用ContextBuilder配置输入输出 Tensor 形状、数据类型、格式及平台信息构建TilingContext通过OpTilingRegistry的LoadTilingLibrary加载 Tiling 动态库、GetTilingFunc获取 Tiling 函数指针然后执行验证编译测试代码执行可执行文件。测试代码完整示例如下来自 tiling_debug 指南// test.cpp #include iostream #include exe_graph/runtime/storage_shape.h #include tiling/context/context_builder.h int main() { gert::StorageShape x_shape {{2, 32}, {2, 32}}; gert::StorageShape y_shape {{2, 32}, {2, 32}}; gert::StorageShape z_shape {{2, 32}, {2, 32}}; auto param gert::TilingData::CreateCap(4096); auto workspace_size_holder gert::ContinuousVector::Createsize_t(4096); auto ws_size reinterpret_castgert::ContinuousVector *(workspace_size_holder.get()); auto holder context_ascendc::ContextBuilder() .NodeIoNum(2, 1) // 2路输入、1路输出 .IrInstanceNum({1, 1}) .AddInputTd(0, ge::DT_FLOAT, ge::FORMAT_ND, ge::FORMAT_ND, x_shape) .AddInputTd(1, ge::DT_FLOAT, ge::FORMAT_ND, ge::FORMAT_ND, y_shape) .AddOutputTd(0, ge::DT_FLOAT, ge::FORMAT_ND, ge::FORMAT_ND, z_shape) .TilingData(param.get()) .Workspace(ws_size) .AddPlatformInfo(Ascendxxxyy) .BuildTilingContext(); auto tilingContext holder-GetContextgert::TilingContext(); context_ascendc::OpTilingRegistry tmpIns; bool flag tmpIns.LoadTilingLibrary(/your/path/to/so_path/liboptiling.so); if (flag false) { std::cout Failed to load tiling so std::endl; return -1; } context_ascendc::TilingFunc tilingFunc tmpIns.GetTilingFunc(AddCustom); // 入参为OpType if (tilingFunc ! nullptr) { ge::graphStatus ret tilingFunc(tilingContext); // 执行Tiling函数 if (ret ! ge::GRAPH_SUCCESS) { std::cout Exec tiling func failed. std::endl; return -1; } } else { std::cout Get tiling func failed. std::endl; return -1; } return 0; }配套编译命令${INSTALL_DIR}替换为 CANN 安装路径root 用户默认为/usr/local/Ascend/canng test.cpp -I${INSTALL_DIR}/include -L${INSTALL_DIR}/lib64 -Wl,-rpath,${INSTALL_DIR}/lib64 \ -ltiling_api -lc_sec -lgraph_base -lregister -lunified_dlog -lplatform -o test必须链接的动态库包括libtiling_api.so包含 ContextBuilder 类、OpTilingRegistry 类、libc_sec.so安全函数库、libgraph_base.so基础数据结构与接口、libregister.so业务函数注册、libunified_dlog.so日志库、libplatform.so平台信息库Tiling 函数使用硬件平台信息时依赖。OpTilingRegistry的加载与取函数逻辑实现于 OpTilingRegistry::LoadTilingLibrary / GetTilingFunc通过dlopen加载 so 并调用其中的TbeLoadSoAndSaveToRegistry完成 Tiling 函数注册再从OpImplSpaceRegistryV2中按 OpType 取出 Tiling 函数指针。五、单元测试中的使用形态仓库测试 tests/api/utils/tiling/test_tiling.cpp 覆盖了NodeIoNum在多种场景下的用法可作为对照参考1 输入 1 输出TestAddInputTdMallocFailedNodeIoNum(1, 1)IrInstanceNum({1})配合AddInputTd的 filePath 重载验证构建失败时返回nullptr6 输入 1 输出TestTilingContextBuildWithConstValueNodeIoNum(6, 1)IrInstanceNum({1, 1, 1, 1, 1, 1})依次AddInputTd(0..5)、AddOutputTd(0)并追加多种类型的AddAttr构建成功后用GetContextgert::TilingContext()取回上下文断言GetInputShape(1)、GetOutputShape(0)与传入的 shape 一致、GetInputDesc/GetOutputDesc的数据类型正确——这正是NodeIoNum声明规模正确后上下文数据可被完整回读的直接验证bin 文件输入TestTilingContextBuildWithBinFileNodeIoNum(6, 1)与NodeIoNum(4, 1)两组合验证非法文件路径空串、超长路径下构建返回nullptr。这些用例印证了第二节提到的使用约定NodeIoNum与IrInstanceNum先行声明规模AddInputTd/AddOutputTd的 index 严格落在声明范围内最后BuildTilingContext产出KernelRunContextHolder经GetContextgert::TilingContext()取出真正的 Tiling 上下文。六、小结与使用要点语义定位NodeIoNum(inputNum, outputNum)声明的是算子IR 原型定义中的输入/输出个数不是运行时张量总数动态输入场景的实例总数由IrInstanceNum决定最终输入张量槽位数为两者中后者实例之和。强制配套文档约束必须配合IrInstanceNum一同使用从源码看原因是IrInstanceNum依赖NodeIoNum写入的outputNum_构造输出实例向量且会覆写inputNum_供BuildTilingContext分配张量槽位调用顺序应为NodeIoNum在前、IrInstanceNum紧随其后之后才是AddInputTd/AddOutputTd/AddAttr。规模要一致AddInputTd的 index 数与总范围必须与实例展开后的输入规模一致越界或缺失都会导致上下文构建结果与算子真实输入不符构建失败holder 为nullptr时先检查errFlag_相关日志shape 非法、bin 读取失败、常量转换失败等。链式风格返回ContextBuilder所有配置接口可任意顺序链式书写在满足上述先后约束的前提下最终统一由BuildTilingContext收口。相关文档索引NodeIoNum、IrInstanceNum、SetOpNameType、AddInputTd、AddOutputTd、AddAttr、BuildTilingContext、ContextBuilder 完整 API 列表、如何进行Tiling调测。赞分享人工智能深度学习算子库CANNAscend【免费下载链接】asc-devkit本项目是CANN 推出的昇腾AI处理器专用的算子程序开发语言原生支持C和C标准规范主要由类库和语言扩展层构成提供多层级API满足多维场景算子开发诉求。项目地址https://gitcode.com/cann/asc-devkit点击查看免费下载相关推荐asc-devkit 中 ContextBuilder::IrInstanceNum 详解为 Tiling 调测声明算子输入实例数asc devkit 中 ContextBuilder::IrInstanceNum 详解为 Tiling 调测声明算子输入实例数 在 asc devkit人工智能深度学习算子库CANNAscendasc-devkit Tiling 调测实践ContextBuilder::AddInputTd 输入 Tensor 描述接口详解asc devkit Tiling 调测实践ContextBuilder::AddInputTd 输入 Tensor 描述接口详解 在算子 Tiling 函数人工智能深度学习算子库CANNAscendasc-devkit Tiling 上下文构建指南用 ContextBuilder::BuildTilingContext 离线验证算子 Tiling 函数asc devkit Tiling 上下文构建指南用 ContextBuilder::BuildTilingContext 离线验证算子 Tiling 函数人工智能深度学习算子库CANNAscend上一篇【亲测免费】 推荐项目WebSocketPP - 强大的C WebSocket库下一篇LKY OfficeTools: 提升办公效率的技术利器创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考