CANN 算子 Prompt 输出格式规范cann-bench direct-launch 四交付件 Markdown 代码块详解【免费下载链接】cann-recipes-train本项目针对LLM与多模态模型训练业务中的典型模型、加速算法提供基于CANN平台的优化样例项目地址: https://gitcode.com/cann/cann-recipes-train导读本文以 cann-recipes-train 仓库中llm_sft/qwen36_ascendc/prompt_generator目录下的输出格式规范文档为骨架系统讲解固定格式 Prompt 生成器CANNBench v1.5 的md-code-block-oneshot变体对模型输出的硬性约束输出必须且只需 4 段代码块kernel_src、launch_h_src、plugin_src、cmake_src且首行首字符必须是k。读完本文你将掌握该输出格式的完整语义、各交付件与仓库示例源码的对应关系、Prompt 的组装与校验机制以及如何据此编写可被机器稳定解析的算子生成结果。一、规范来源与定位该规范文件位于 llm_sft/qwen36_ascendc/prompt_generator/output_format_code_block_md.md是 generate_prompts.py 在渲染 Prompt 时注入的输出格式段落对应模板中的{{OUTPUT_FORMAT}}占位符。从仓库结构看该生成器是固定格式 Prompt 生成器的核心交付物面向让大模型编写自定义 AscendC 算子的场景给定算子规格desc.md、proto.yaml、cases.yaml、golden.py让模型输出可被 cann-bench direct-launch 模式直接编译与评测的代码。为了让下游自动解析器能稳定、无歧义地提取模型产物输出格式被收敛为固定 4 段 Markdown fenced code block不提供任何模板、格式或 one-shot 位置切换参数。二、输出格式规范原文规范文件的核心内容只有两条却决定了模型产物的机器可解析性输出只需 4 段代码块按固定顺序出现且每个代码块前必须带有固定的标签行kernel_src cpp ...launch_h_src...plugin_src...cmake_src...2. **第一行第一个非空字符必须是 k**来自 kernel_src即整段输出的最开头必须是 kernel_src 标签不允许有任何前置文本如问候语、解释性段落、思考过程等。 这两个约束共同保证了解析器只需扫描 kernel_src / launch_h_src / plugin_src / cmake_src 四个锚点标签即可按顺序切分出四段代码从而可靠地还原出一个算子所需的全部源码交付件。 ## 三、四个交付件的语义与源码对应 规范中的四个标签对应 cann-bench direct-launch 模式算子工程的四个必备文件。仓库内置的 one-shot 样例算子 sqrt 完整地展示了它们的真实形态位于 [examples/sqrt](https://link.gitcode.com/i/54f9372951e2c6a13ec1b0e8203c2fe6) text examples/sqrt/ ├── CMakeLists.txt ├── op_kernel/sqrt_kernel.cpp ├── op_kernel/sqrt_launch.h └── op_plugin/sqrt_plugin.cpp3.1 kernel_srcAscendC 内核实现对应样例的 op_kernel/sqrt_kernel.cpp。该文件包含模板化内核类如KernelSqrtT在Init()中通过SetGlobalBuffer绑定 GM 全局内存、按GetBlockIdx()切分 block、用TPipe::InitBuffer分配 VECIN/VECOUT 队列与 VECCALC 计算缓冲在Process()中完成CopyIn → Compute → CopyOut的流水循环并对尾块tail tile单独处理。宿主端 tiling 计算函数如calc_sqrt_tiling_params借助platform_ascendc::PlatformAscendCManager::GetInstance()-GetCoreNumAiv()获取 AI Core 数量计算(numBlocks, blockLength, tileSize)三元组tileSize 以元素个数非字节为单位。导出层extern C为每种 dtype 导出独立的launch_op_kernel_dtype入口内部以sqrt_kernelTnumBlocks, nullptr, stream方式启动内核。值得注意的实现细节来自源码非本规范半精度/bf16 输入会先Cast到 float32 计算再转回原 dtypebf16 回写时使用CAST_RINT舍入模式float16 使用CAST_NONE——这与样例 Prompt 中在 float32 下完成后转回 x 的 dtype的精度策略一致。3.2 launch_h_src启动声明头文件对应样例的 op_kernel/sqrt_launch.h。这是一个被 kernel 实现与 plugin 共同引用的声明层用#ifndef GM_ADDR / #define GM_ADDR void*兜底定义GM_ADDR类型声明 tiling 计算函数calc_op_tiling_params(int64_t totalLength)在extern C块中按 dtype 声明各launch_op_kernel_dtype启动函数。它构成了内核代码与上层插件之间的稳定 C ABI 契约。3.3 plugin_srcPyTorch 算子插件对应样例的 op_plugin/sqrt_plugin.cpp。该文件把内核接入 PyTorch 算子体系TORCH_LIBRARY_FRAGMENT(cann_bench, m)注册算子 schema如m.def(sqrt(Tensor x) - Tensor)实现 Meta 分发sqrt_meta返回torch::empty_like(x)与 NPU 分发sqrt_npuNPU 实现中通过c10_npu::getCurrentNPUStream()获取当前 stream调用 tiling 函数与对应 dtype 的 launch 入口并将调用包装进at_npu::native::OpCommand::RunOpApi(Sqrt, acl_call)。由此用户便可在 Python 侧以torch风格调用该算子见样例 desc 中的调用示例cann_bench.pows(x, 2.0)。3.4 cmake_src构建接入对应样例的 CMakeLists.txt。它定义源文件变量并调用构建框架提供的注册宏set(SQRT_KERNEL_SRCS ${CMAKE_CURRENT_SOURCE_DIR}/op_kernel/sqrt_kernel.cpp ) set(SQRT_PLUGIN_SRCS ${CMAKE_CURRENT_SOURCE_DIR}/op_plugin/sqrt_plugin.cpp ) register_direct_launch_op( ${SQRT_KERNEL_SRCS} op_kernel ${SQRT_PLUGIN_SRCS} op_kernel --npu-archdav-2201 )其中register_direct_launch_op是 cann-bench direct-launch 模式的注册宏依次接收内核源文件、内核构建目标目录、插件源文件、插件构建目标目录以及编译架构参数--npu-archdav-2201对应示例目标硬件 Ascend 910C。四、输出格式在 Prompt 中的组装位置该格式规范不是孤立文本而是固定格式 Prompt 三段式结构的一部分。以 main_assembly_v1.5.md 为总模板generate_prompts.py通过占位符替换完成组装算子规格段{{DESC_MD}}算子 API 描述含数学公式、参数表、精度要求与支持范围、{{PROTO_YAML}}算子原型、{{CASES_YAML}}测试用例、{{GOLDE_PY}}标准 golden 参考实现输出格式段即{{OUTPUT_FORMAT}}注入本文解析的输出格式规范one-shot 示例段即{{ONE_SHOT}}由 one_shot_code_block_md.md 渲染将样例算子sqrt的四份源码分别填入{{kernel_src}}、{{launch_h_src}}、{{plugin_src}}、{{cmake_src}}并显式声明仅作格式模板不是你要生成的算子看结构、勿抄语义。三段顺序由生成器强制保证算子规格在输出格式之前one-shot 示例在输出格式之后post-oneshot。这在单元测试中得到了验证self.assertLess(op_specification, output_format) self.assertLess(output_format, one_shot)一个完整的成品 Prompt 见 generated_prompt_example.md其尾部正是输出格式 sqrt one-shot的拼接形态可直接观察 4 段标签与代码块在真实 Prompt 中的排版。五、源码实现占位符注入与输出约束generate_prompts.py 中与输出格式直接相关的实现要点常量定义OUTPUT_FORMAT_FILE output_format_code_block_md.md、ONE_SHOT_TEMPLATE_FILE one_shot_code_block_md.md、TEMPLATE_FILE main_assembly_v1.5.md三个模板文件固定绑定不提供切换开关格式注入load_output_format()读取规范文件全文并rstrip(\n)后填入{{OUTPUT_FORMAT}}render_one_shot()按{{example_name}}等五个占位符逐一替换任务交付件声明TASK_DELIVERABLES **kernel**、**launch_h**、**plugin**、**cmake** 4 个交付件被注入任务概述与输出格式段互相呼应输入校验load_op_inputs()强制每个算子目录必须包含cases.yaml、desc.md、golden.py、proto.yaml四个文件缺一即报错REQUIRED_OP_FILESdesc 预处理strip_desc_standard_golden_code()会识别并移除desc.md内嵌的标准 Golden 代码章节按标题模式标准 golden 代码匹配避免与独立 golden 段重复同时保持其余章节编号连续渲染出口render_prompt()完成全部{{...}}占位符替换同时兼容GOLDE_PY与GOLDEN_PY两种拼写随后generate_prompts()为每个算子写出out-dir/op.md。脚本仅依赖 Python 3.10 标准库argparse/dataclasses/pathlib/re等运行时不会读取任何其他模板。六、生成命令与参数按生成器 README生成命令为python prompt_generator/generate_prompts.py \ --op-root path-to-op-root \ --ops sigmoid exp \ --out-dir generated_prompts关键参数参数说明默认值--op-root算子根目录脚本按op-root/op读取每个算子的输入必填--ops一个或多个算子目录名重复算子按首次出现顺序去重必填--out-dirPrompt 输出目录每个算子生成op.md必填--exampleone-shot 样例名sqrt--examples-root自定义样例根目录脚本同级examples/每个算子目录必须包含 4 个文件cases.yaml测试用例、desc.md算子 API 描述、golden.py标准 golden 实现、proto.yaml算子原型。每个样例目录则必须包含CMakeLists.txt、op_kernel/example_kernel.cpp、op_kernel/example_launch.h、op_plugin/example_plugin.cpp四个文件详见 README 中的目录结构约定。七、输出规范的机器校验逻辑输出格式能否被可靠解析取决于模型是否严格遵守 4 段约束。仓库测试test_generate_prompts.py虽然直接验证的是生成器而非模型输出但其断言恰好体现了可解析性的三个判据可作为校验模型输出的参考标准格式锚点存在Prompt 中必须包含输出只需 **4 段** 代码块的格式指令、kernel_src\n\ncpp的标签围栏组合顺序正确算子规格## 本任务算子规格等信息详述→ 输出格式## 输出格式→ 示例代码## 示例代码严格递增占位符全部替换最终 Prompt 中不得残留{{未替换模板标记。对照这三点可推得下游对模型产物的校验要点标签行必须以kernel_src开头且无前置文本首字符k四段标签按固定顺序出现每个标签后紧跟对应语言的代码围栏cpp×3、cmake×1代码块之间不得混入无关输出。任何一段缺失、顺序错乱或首行被思考过程/前言污染都会破坏自动解析。八、编写高质量模型输出的实操建议结合规范与示例源码可归纳出面向该输出格式的编写要点严格排版不写多余内容输出第一行第一个非空字符必须是k即kernel_src必须顶格或仅前导空白出现不要在代码块外添加总结、注释或分隔线。四段顺序固定kernel_src → launch_h_src → plugin_src → cmake_src其中前三个均为cpp围栏最后一个是cmake围栏。对照 one-shot 看结构sqrt样例已示范四交付件的标准骨架见 3.13.4生成新算子时应沿用该结构、替换算子语义与函数命名例如把sqrt_kernel换成目标算子的xxx_kernel把TORCH_LIBRARY_FRAGMENT中的 schema 换成目标算子原型。保持 ABI 契约一致launch_h_src中声明的每个launch_xxx_kernel_dtype必须在kernel_src中实现且签名完全一致GM_ADDR, GM_ADDR, int64_t, int64_t, int64_t, uint32_t, void*plugin 中的 dtype 分发分支必须与 launch 声明一一对应。遵守目标硬件约束样例的calc_*_tiling_params通过PlatformAscendCManager::GetCoreNumAiv()动态获取核数UB 队列与 fp32 转换缓冲的容量设计均需按 910Cdav-2201架构语义假定与 Prompt 中只使用在 Ascend 910C /ascend910_93上有效的 AscendC API的硬件说明保持一致。九、总结output_format_code_block_md.md虽然只有寥寥数行却是整个md-code-block-oneshotPrompt 体系中最关键的机器契约它把模型产物收敛为kernel_src、launch_h_src、plugin_src、cmake_src四段固定顺序的代码块配合首字符必须是k的首行约束使 cann-bench direct-launch 模式可以无歧义地提取算子源码并直接编译评测。理解这份规范是正确阅读仓库内 generated_prompt_example.md 成品 Prompt、复现或定制该生成器以及编写合规模型输出的基础。【免费下载链接】cann-recipes-train本项目针对LLM与多模态模型训练业务中的典型模型、加速算法提供基于CANN平台的优化样例项目地址: https://gitcode.com/cann/cann-recipes-train创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 CANN 算子 Prompt 输出格式规范：cann-bench direct-launch 四交付件 Markdown 代码块详解
CANN 算子 Prompt 输出格式规范cann-bench direct-launch 四交付件 Markdown 代码块详解【免费下载链接】cann-recipes-train本项目针对LLM与多模态模型训练业务中的典型模型、加速算法提供基于CANN平台的优化样例项目地址: https://gitcode.com/cann/cann-recipes-train导读本文以 cann-recipes-train 仓库中llm_sft/qwen36_ascendc/prompt_generator目录下的输出格式规范文档为骨架系统讲解固定格式 Prompt 生成器CANNBench v1.5 的md-code-block-oneshot变体对模型输出的硬性约束输出必须且只需 4 段代码块kernel_src、launch_h_src、plugin_src、cmake_src且首行首字符必须是k。读完本文你将掌握该输出格式的完整语义、各交付件与仓库示例源码的对应关系、Prompt 的组装与校验机制以及如何据此编写可被机器稳定解析的算子生成结果。一、规范来源与定位该规范文件位于 llm_sft/qwen36_ascendc/prompt_generator/output_format_code_block_md.md是 generate_prompts.py 在渲染 Prompt 时注入的输出格式段落对应模板中的{{OUTPUT_FORMAT}}占位符。从仓库结构看该生成器是固定格式 Prompt 生成器的核心交付物面向让大模型编写自定义 AscendC 算子的场景给定算子规格desc.md、proto.yaml、cases.yaml、golden.py让模型输出可被 cann-bench direct-launch 模式直接编译与评测的代码。为了让下游自动解析器能稳定、无歧义地提取模型产物输出格式被收敛为固定 4 段 Markdown fenced code block不提供任何模板、格式或 one-shot 位置切换参数。二、输出格式规范原文规范文件的核心内容只有两条却决定了模型产物的机器可解析性输出只需 4 段代码块按固定顺序出现且每个代码块前必须带有固定的标签行kernel_src cpp ...launch_h_src...plugin_src...cmake_src...2. **第一行第一个非空字符必须是 k**来自 kernel_src即整段输出的最开头必须是 kernel_src 标签不允许有任何前置文本如问候语、解释性段落、思考过程等。 这两个约束共同保证了解析器只需扫描 kernel_src / launch_h_src / plugin_src / cmake_src 四个锚点标签即可按顺序切分出四段代码从而可靠地还原出一个算子所需的全部源码交付件。 ## 三、四个交付件的语义与源码对应 规范中的四个标签对应 cann-bench direct-launch 模式算子工程的四个必备文件。仓库内置的 one-shot 样例算子 sqrt 完整地展示了它们的真实形态位于 [examples/sqrt](https://link.gitcode.com/i/54f9372951e2c6a13ec1b0e8203c2fe6) text examples/sqrt/ ├── CMakeLists.txt ├── op_kernel/sqrt_kernel.cpp ├── op_kernel/sqrt_launch.h └── op_plugin/sqrt_plugin.cpp3.1 kernel_srcAscendC 内核实现对应样例的 op_kernel/sqrt_kernel.cpp。该文件包含模板化内核类如KernelSqrtT在Init()中通过SetGlobalBuffer绑定 GM 全局内存、按GetBlockIdx()切分 block、用TPipe::InitBuffer分配 VECIN/VECOUT 队列与 VECCALC 计算缓冲在Process()中完成CopyIn → Compute → CopyOut的流水循环并对尾块tail tile单独处理。宿主端 tiling 计算函数如calc_sqrt_tiling_params借助platform_ascendc::PlatformAscendCManager::GetInstance()-GetCoreNumAiv()获取 AI Core 数量计算(numBlocks, blockLength, tileSize)三元组tileSize 以元素个数非字节为单位。导出层extern C为每种 dtype 导出独立的launch_op_kernel_dtype入口内部以sqrt_kernelTnumBlocks, nullptr, stream方式启动内核。值得注意的实现细节来自源码非本规范半精度/bf16 输入会先Cast到 float32 计算再转回原 dtypebf16 回写时使用CAST_RINT舍入模式float16 使用CAST_NONE——这与样例 Prompt 中在 float32 下完成后转回 x 的 dtype的精度策略一致。3.2 launch_h_src启动声明头文件对应样例的 op_kernel/sqrt_launch.h。这是一个被 kernel 实现与 plugin 共同引用的声明层用#ifndef GM_ADDR / #define GM_ADDR void*兜底定义GM_ADDR类型声明 tiling 计算函数calc_op_tiling_params(int64_t totalLength)在extern C块中按 dtype 声明各launch_op_kernel_dtype启动函数。它构成了内核代码与上层插件之间的稳定 C ABI 契约。3.3 plugin_srcPyTorch 算子插件对应样例的 op_plugin/sqrt_plugin.cpp。该文件把内核接入 PyTorch 算子体系TORCH_LIBRARY_FRAGMENT(cann_bench, m)注册算子 schema如m.def(sqrt(Tensor x) - Tensor)实现 Meta 分发sqrt_meta返回torch::empty_like(x)与 NPU 分发sqrt_npuNPU 实现中通过c10_npu::getCurrentNPUStream()获取当前 stream调用 tiling 函数与对应 dtype 的 launch 入口并将调用包装进at_npu::native::OpCommand::RunOpApi(Sqrt, acl_call)。由此用户便可在 Python 侧以torch风格调用该算子见样例 desc 中的调用示例cann_bench.pows(x, 2.0)。3.4 cmake_src构建接入对应样例的 CMakeLists.txt。它定义源文件变量并调用构建框架提供的注册宏set(SQRT_KERNEL_SRCS ${CMAKE_CURRENT_SOURCE_DIR}/op_kernel/sqrt_kernel.cpp ) set(SQRT_PLUGIN_SRCS ${CMAKE_CURRENT_SOURCE_DIR}/op_plugin/sqrt_plugin.cpp ) register_direct_launch_op( ${SQRT_KERNEL_SRCS} op_kernel ${SQRT_PLUGIN_SRCS} op_kernel --npu-archdav-2201 )其中register_direct_launch_op是 cann-bench direct-launch 模式的注册宏依次接收内核源文件、内核构建目标目录、插件源文件、插件构建目标目录以及编译架构参数--npu-archdav-2201对应示例目标硬件 Ascend 910C。四、输出格式在 Prompt 中的组装位置该格式规范不是孤立文本而是固定格式 Prompt 三段式结构的一部分。以 main_assembly_v1.5.md 为总模板generate_prompts.py通过占位符替换完成组装算子规格段{{DESC_MD}}算子 API 描述含数学公式、参数表、精度要求与支持范围、{{PROTO_YAML}}算子原型、{{CASES_YAML}}测试用例、{{GOLDE_PY}}标准 golden 参考实现输出格式段即{{OUTPUT_FORMAT}}注入本文解析的输出格式规范one-shot 示例段即{{ONE_SHOT}}由 one_shot_code_block_md.md 渲染将样例算子sqrt的四份源码分别填入{{kernel_src}}、{{launch_h_src}}、{{plugin_src}}、{{cmake_src}}并显式声明仅作格式模板不是你要生成的算子看结构、勿抄语义。三段顺序由生成器强制保证算子规格在输出格式之前one-shot 示例在输出格式之后post-oneshot。这在单元测试中得到了验证self.assertLess(op_specification, output_format) self.assertLess(output_format, one_shot)一个完整的成品 Prompt 见 generated_prompt_example.md其尾部正是输出格式 sqrt one-shot的拼接形态可直接观察 4 段标签与代码块在真实 Prompt 中的排版。五、源码实现占位符注入与输出约束generate_prompts.py 中与输出格式直接相关的实现要点常量定义OUTPUT_FORMAT_FILE output_format_code_block_md.md、ONE_SHOT_TEMPLATE_FILE one_shot_code_block_md.md、TEMPLATE_FILE main_assembly_v1.5.md三个模板文件固定绑定不提供切换开关格式注入load_output_format()读取规范文件全文并rstrip(\n)后填入{{OUTPUT_FORMAT}}render_one_shot()按{{example_name}}等五个占位符逐一替换任务交付件声明TASK_DELIVERABLES **kernel**、**launch_h**、**plugin**、**cmake** 4 个交付件被注入任务概述与输出格式段互相呼应输入校验load_op_inputs()强制每个算子目录必须包含cases.yaml、desc.md、golden.py、proto.yaml四个文件缺一即报错REQUIRED_OP_FILESdesc 预处理strip_desc_standard_golden_code()会识别并移除desc.md内嵌的标准 Golden 代码章节按标题模式标准 golden 代码匹配避免与独立 golden 段重复同时保持其余章节编号连续渲染出口render_prompt()完成全部{{...}}占位符替换同时兼容GOLDE_PY与GOLDEN_PY两种拼写随后generate_prompts()为每个算子写出out-dir/op.md。脚本仅依赖 Python 3.10 标准库argparse/dataclasses/pathlib/re等运行时不会读取任何其他模板。六、生成命令与参数按生成器 README生成命令为python prompt_generator/generate_prompts.py \ --op-root path-to-op-root \ --ops sigmoid exp \ --out-dir generated_prompts关键参数参数说明默认值--op-root算子根目录脚本按op-root/op读取每个算子的输入必填--ops一个或多个算子目录名重复算子按首次出现顺序去重必填--out-dirPrompt 输出目录每个算子生成op.md必填--exampleone-shot 样例名sqrt--examples-root自定义样例根目录脚本同级examples/每个算子目录必须包含 4 个文件cases.yaml测试用例、desc.md算子 API 描述、golden.py标准 golden 实现、proto.yaml算子原型。每个样例目录则必须包含CMakeLists.txt、op_kernel/example_kernel.cpp、op_kernel/example_launch.h、op_plugin/example_plugin.cpp四个文件详见 README 中的目录结构约定。七、输出规范的机器校验逻辑输出格式能否被可靠解析取决于模型是否严格遵守 4 段约束。仓库测试test_generate_prompts.py虽然直接验证的是生成器而非模型输出但其断言恰好体现了可解析性的三个判据可作为校验模型输出的参考标准格式锚点存在Prompt 中必须包含输出只需 **4 段** 代码块的格式指令、kernel_src\n\ncpp的标签围栏组合顺序正确算子规格## 本任务算子规格等信息详述→ 输出格式## 输出格式→ 示例代码## 示例代码严格递增占位符全部替换最终 Prompt 中不得残留{{未替换模板标记。对照这三点可推得下游对模型产物的校验要点标签行必须以kernel_src开头且无前置文本首字符k四段标签按固定顺序出现每个标签后紧跟对应语言的代码围栏cpp×3、cmake×1代码块之间不得混入无关输出。任何一段缺失、顺序错乱或首行被思考过程/前言污染都会破坏自动解析。八、编写高质量模型输出的实操建议结合规范与示例源码可归纳出面向该输出格式的编写要点严格排版不写多余内容输出第一行第一个非空字符必须是k即kernel_src必须顶格或仅前导空白出现不要在代码块外添加总结、注释或分隔线。四段顺序固定kernel_src → launch_h_src → plugin_src → cmake_src其中前三个均为cpp围栏最后一个是cmake围栏。对照 one-shot 看结构sqrt样例已示范四交付件的标准骨架见 3.13.4生成新算子时应沿用该结构、替换算子语义与函数命名例如把sqrt_kernel换成目标算子的xxx_kernel把TORCH_LIBRARY_FRAGMENT中的 schema 换成目标算子原型。保持 ABI 契约一致launch_h_src中声明的每个launch_xxx_kernel_dtype必须在kernel_src中实现且签名完全一致GM_ADDR, GM_ADDR, int64_t, int64_t, int64_t, uint32_t, void*plugin 中的 dtype 分发分支必须与 launch 声明一一对应。遵守目标硬件约束样例的calc_*_tiling_params通过PlatformAscendCManager::GetCoreNumAiv()动态获取核数UB 队列与 fp32 转换缓冲的容量设计均需按 910Cdav-2201架构语义假定与 Prompt 中只使用在 Ascend 910C /ascend910_93上有效的 AscendC API的硬件说明保持一致。九、总结output_format_code_block_md.md虽然只有寥寥数行却是整个md-code-block-oneshotPrompt 体系中最关键的机器契约它把模型产物收敛为kernel_src、launch_h_src、plugin_src、cmake_src四段固定顺序的代码块配合首字符必须是k的首行约束使 cann-bench direct-launch 模式可以无歧义地提取算子源码并直接编译评测。理解这份规范是正确阅读仓库内 generated_prompt_example.md 成品 Prompt、复现或定制该生成器以及编写合规模型输出的基础。【免费下载链接】cann-recipes-train本项目针对LLM与多模态模型训练业务中的典型模型、加速算法提供基于CANN平台的优化样例项目地址: https://gitcode.com/cann/cann-recipes-train创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考