当前位置: 首页 > news >正文

CANN算子规范生成器使用场景

应用场景

【免费下载链接】cannbot-skillsCANNBot 是面向 CANN 开发的用于提升开发效率的系列智能体,本仓库为其提供可复用的 Skills 模块。项目地址: https://gitcode.com/cann/cannbot-skills

本文描述从 REQUIREMENTS.md 出发的完整操作步骤, 包括 spec 生成(场景二)和 spec 独立评审(场景五)。


场景二:从 REQUIREMENTS.md 生成 spec.yaml

强制规则

ID规则
S1必须使用scripts/generate_spec.py生成骨架,禁止手写 spec.yaml
S2生成完成后必须跑scripts/validate_spec.py spec.yaml9-stage 校验全 PASS(stage 9 SKIP 视为通过)
S3(建议)scripts/compute_spec_hash.py工具链尚未交付,v1 不要求锁 spec_hash;待工具与 schema 字段就绪后启用
S4字段值必须与 REQUIREMENTS.md 一致——dtype / shape 约束 / 平台限制 / 容差由 REQUIREMENTS 推导,不允许凭空添加
S5numerical_stability.techniques.anti_pattern_id 引用必须在registries/anti_pattern_registry.yaml中已注册(如未来 schema 加 enum)
S6必须填op.platform_constraints.supported_chips(来自 REQUIREMENTS §2 运行环境;与 chip_registry.yaml 对齐)
S7(建议)interface_binding.arg_order/aclnn/ge_ir字段尚未纳入schemas/op-spec.json(顶层additionalProperties: false),v1 不填;待 schema 扩展后启用
S8(建议)performance_budget同上,schema 未定义,v1 不填
S9(建议)performance_baseline同上,schema 未定义,v1 不填

执行步骤

Step 1: 读取 REQUIREMENTS.md,提取以下字段映射到 spec.yaml:

REQUIREMENTS.md 字段spec.yaml 字段
算子类别op.category
算子范式(多选)op.paradigms
范式间组合方式(横向组合 / 纵向融合)op.paradigm_groups+--paradigm-groups参数(见下方说明)
算子接口描述中的非张量参数声明attributes[]+--axis-source参数(见下方说明)
数据排布格式支持(NCHW/NHWC/NCDHW 等)math_semantics.format_variants[]+--format-variants参数
输入张量列表 + dtypeinputs[].name / dtype_set / shape.symbolic
输出张量 + dtype 推导规则outputs[].dtype_rule / shape_rule
数学公式math_semantics.formula
参考实现 / oraclemath_semantics.reference_oracle
数值稳定性技术numerical_stability.techniques
精度容差numerical_tolerance.per_dtype
边界 caseboundary_conditions[]/extreme_inputs[]
§2 运行环境(芯片号)op.platform_constraints.supported_chips
§2 运行环境(DAV 宏 / CANN 版本)REQUIREMENTS.md继续承载;schema 未定义时不要写入 spec
§5 ACLNN API 接口(参数列表 / 顺序)v1 暂缓interface_binding.*尚未纳入 schema
§6 GE IR 定义(IR 算子名 / 动态 shape)v1 暂缓interface_binding.ge_ir.*尚未纳入 schema
§8 资源约束(workspace 上限 / 对齐)v1 暂缓performance_budget尚未纳入 schema
§7 性能指标(利用率 / 带宽 / 延迟)v1 暂缓performance_baseline尚未纳入 schema

attribute / axis_source 选择规则

查看 REQUIREMENTS.md 中的算子接口描述(可能以 REG_OP 宏、ACLNN API 参数表、GE IR 表格或自然语言描述等形式出现),判断归约轴是如何指定的:

接口特征--axis-source说明
归约轴作为非张量参数声明(如 REG_OP 的.ATTR(dim, ...)、ACLNN 参数表中的 int64/list 类型参数、GE IR 表格的 ATTR 行)attribute(默认)归约轴作为 attribute 传入
归约轴作为整型 tensor 输入声明(如 REG_OP 的.INPUT(axes, ...)、ACLNN 参数表中的 aclTensor 类型参数)input_tensor归约轴作为 tensor input
无归约轴参数,归约轴固定(如 reduce 特定维度)fixed归约轴硬编码在算子内部
无归约轴参数,reduce 所有轴(输出为标量)implicit_all隐式归约所有轴,无需显式指定

注意:当 REQUIREMENTS.md 的算子接口描述中无归约轴相关参数时,必须根据算子语义选择fixedimplicit_all,不能使用默认的attribute(否则会注入不存在的dim/keep_dimsattribute)。

paradigm_groups 选择规则

当算子有多个范式且不同属性值触发不同计算模式时,需要声明范式间组合方式:

判断条件--paradigm-groups说明
属性值切换导致计算模式根本性变化(如 reduction=none→逐元素 vs reduction=sum/mean→归约;mode=training vs mode=inference)combination横向组合:多范式择一,由属性值决定激活哪个。每个 paradigm 独立一条 combination 组
多范式串联执行(如先 Elementwise 再 Reduction 再 Elementwise,所有范式始终参与)fusion纵向融合:所有范式按序执行
仅 1 个范式,或所有属性值走同一范式不传(默认)无需声明组合关系

关键判断:检查 REQUIREMENTS.md 中是否存在"模式切换"属性——某个属性值使算子退化为完全不同的计算模式(如reduction=none使 Reduce 算子退化为逐元素、training=False跳过 dropout)。若存在,必须选combination并在 spec 中补 Elementwise 范式。

Step 2: 调用生成器(非交互式,CI 友好):

python3 ops/ops-spec-gen/scripts/generate_spec.py \ --op-name {operator_name} \ --category {category} \ --paradigms {Paradigm1},{Paradigm2},... \ --paradigm-groups {combination|fusion} \ --inputs "{name1}:{dtype1},{dtype2};{name2}:{dtype1},..." \ --outputs {name} \ --axis-source {attribute|input_tensor|fixed|implicit_all} \ --description "{REQUIREMENTS 中的一句描述}" \ --output-dir operators/{operator_name}/docs

--paradigm-groups仅当有 ≥ 2 个范式且存在模式切换时使用。combination模式下 Elementwise 不会被自动过滤。生成后需手填每组switch(属性名)和when(属性值)。

--axis-source仅对 Reduction 类算子有效。默认值为attribute,需根据上方规则表对照 REQUIREMENTS.md 算子原型选择正确值。

注:交互式向导用法见 SKILL.md §3.1。

Step 3: 手填 TODO 字段(生成器只给骨架,详见 SKILL.md §3.4):

  • math_semantics.formula— numpy 可 eval 的表达式
  • math_semantics.reference_oracle— 单 callable api,或填 absent=true + governance 签字
  • dtype_policy.supported_combinations— 显式枚举 (input dtypes) → output dtypes
  • numerical_tolerance.per_dtype— 覆盖输出 dtype(默认值见registries/tolerance_defaults.yaml
  • op.platform_constraints.supported_chips— 来自 REQUIREMENTS §2,与registries/chip_registry.yaml对齐
  • op.paradigm_groups[].switch/when— 当使用--paradigm-groups combination时,需手填每组的switch(属性名)和when(属性值),将属性值映射到对应的范式子集
  • v1 暂缓interface_binding/performance_budget/performance_baseline尚未纳入 schema(顶层additionalProperties: false),不要写入;待 schema 扩展后启用

Step 4: 跑 9-stage 校验

python3 ops/ops-spec-gen/scripts/validate_spec.py operators/{operator_name}/docs/spec.yaml

预期 stage 1-8 全 PASS。stage 9 在测试机未装 torch 时走 SKIP(不算失败)。任一 FAIL 必须修复后重跑,禁止跳过。校验详情见 SKILL.md §4。

Step 5: 锁 spec_hash(建议):compute_spec_hash.py工具链 v1 未交付;不要求执行,待工具就绪后再纳入流程。

完成标志

  • spec.yaml 已生成并通过 9-stage 校验
  • 字段与 REQUIREMENTS.md 内容一致(dtype / shape / 平台 / 容差均可追溯到需求)

场景五:spec 独立评审(14 条 SPEC-* 条款评审)

在 CP1.5 用户人工 review 前,先做 14 条 SPEC-* 条款级评审——逐项对照 spec ↔ REQUIREMENTS 中机器可判的项。把明显错误(dtype 漏一个、芯片不匹配、attribute 凭空注入、错误码缺漏、性能字段没填) 先拦下,避免拿一份"机器自洽但语义错"的 spec 去骚扰用户。

前置条件

  • 已存在operators/{operator_name}/docs/spec.yaml(9-stage 全 PASS)
  • 已存在operators/{operator_name}/docs/REQUIREMENTS.md

14 条 SPEC-* 条款

条款 ID检查项数据来源对照
SPEC-CHIP-1spec.op.platform_constraints.supported_chips ⊆ REQUIREMENTS §2 目标芯片字符串集合包含关系
SPEC-DAV-1v1 暂缓— DAV 宏由 REQUIREMENTS / DESIGN 承载,dav_macros尚未纳入 schema
SPEC-DTYPE-1spec.dtype_policy.supported_combinations 输入 dtype 集 = REQUIREMENTS §4 支持类型集集合相等
SPEC-DTYPE-2spec.inputs[].dtype_set 覆盖 REQUIREMENTS §4 数据类型集合包含
SPEC-IO-1spec.inputs/outputs 数量 + name 与 REQUIREMENTS §5 ACLNN 参数列表对齐长度 + 名字集合
SPEC-ATTR-1spec.attributes[].name 集合 ⊆ REQUIREMENTS 算子接口描述中声明的非张量参数集合(接口描述中无归约轴等 attribute 类参数时 spec.attributes 应为空)集合包含
SPEC-ARG-1v1 暂缓interface_binding.arg_order尚未纳入 schema,待扩展后启用
SPEC-ERROR-1spec.op.error_codes ⊇ REQUIREMENTS §8 错误码集合集合包含
SPEC-PERF-1v1 暂缓performance_baseline尚未纳入 schema,待扩展后启用
SPEC-RES-1v1 暂缓performance_budget尚未纳入 schema,待扩展后启用
SPEC-FORMULA-1spec.math_semantics.formula 至少引用所有 input name字符串包含
SPEC-PARADIGM-1spec.op.paradigms 与 category 隐含范式 + REQUIREMENTS 暗示的修饰范式对齐集合差
SPEC-LIFECYCLE-1spec.op.lifecycle 与 REQUIREMENTS 描述匹配(experimental vs stable)字符串匹配
SPEC-INTERFACE-1v1 暂缓interface_binding.*尚未纳入 schema,待扩展后启用

执行步骤

  1. 逐条对照 spec ↔ REQUIREMENTS:按 14 条条款表逐项评审,每条输出 ✓/⚠/❌ + 证据(spec 字段值与 REQUIREMENTS 来源的对照)
  2. 生成必看清单:列出 agent 独立评审无法判但必须由人 review 的项(见下文)
  3. 状态判定:任一 ❌ → 状态=❌失败;全 ✓ 或 ⚠ → 状态=✅通过(⚠ 提示用户但不阻塞)
  4. 输出 SPEC_REVIEW.md:按下文报告格式模板输出

注意:本场景只读、只评审、只输出报告;不得修改 spec.yaml。修复由场景二(spec-generation)执行。

必看清单(用户对照摘要必含)

agent 独立评审无法判但必须由人 review 的项:

强制规则:以下每一项必须出现在评审报告的"必看清单"中。即使判断为 ✓ 也必须输出并附简要证据,不允许省略。

必看项为什么 agent 判不了
公式数学意图"y = (x - mean) / sqrt(var + eps)" 写得对但用户真想要的可能是 RMSNorm 不是 LayerNorm
tolerance 数值合理性1e-3 还是 5e-3?需要算子领域知识 + 上下游精度标准
boundary case 业务覆盖业务上 K 维 > 4096 是否常见?需领域知识
composition 拆分合理性FusedComposite 算子的 primitives 拆分是否符合预期融合方式
reference_oracle 选择选 torch.matmul 还是 torch.linalg.matmul?两者数值差异在边界 case 可能很大
范式选择正确性spec.op.paradigms 列出的范式是否完整覆盖了算子的所有计算路径?典型陷阱:reduction=none 时算子退化为 Elementwise,但 spec 只声明了 Reduction + FusedComposite,漏掉了 Elementwise。agent 只能校验"声明的范式是否与 category 对齐",无法判断"是否漏了一条独立的计算路径"
范式组合方式(paradigm_groups)多个范式之间的关系是横向组合(combination,按属性值择一激活)还是纵向融合(fusion,串联执行)?agent 只能做结构校验(switch/when 格式),无法判断组合方式是否符合算子实际的分发逻辑。典型陷阱:存在模式切换属性但未声明 paradigm_groups,导致下游 design 无法生成分区 TilingKey

报告格式(精确模板,供主 Agent 机读判定)

**状态**: ✅通过 / ❌失败 **spec.yaml 路径**: operators/{op}/docs/spec.yaml **REQUIREMENTS.md 路径**: operators/{op}/docs/REQUIREMENTS.md ## 14 条 SPEC-* 条款评审 | 条款 ID | 状态 | spec 字段值 | REQUIREMENTS 来源 | 证据 / 备注 | |---------|------|-------------|------------------|------------| | SPEC-CHIP-1 | ✓ | [Ascend910B, Ascend910D] | §2 Atlas A2/A3 训练系列 | 字段值与需求对齐 | | SPEC-DAV-1 | ⚠ | v1 暂缓 | §2 编译宏 | DAV 宏尚未纳入 spec schema,由 REQUIREMENTS / DESIGN 承载 | | SPEC-DTYPE-1 | ⚠ | {fp16, bf16} | §4 fp16/bf16/fp32 | spec 漏 fp32;用户确认是否真要去掉 fp32? | | ... | ... | ... | ... | ... | ## 必看清单(CP1.5 人工 review 用) ⚠ **公式数学意图**:spec.formula="y = np.exp(x) / np.exp(x).sum(axis=dim)" ⚠ 注意:未做 max-shift 数值稳定。REQUIREMENTS §4 公式同未提;但 NumericalStable 范式已声明。 → 人工确认:是否真不做 max-shift? ⚠ **tolerance 数值合理性**:fp16 用 1.0e-3,bf16 用 4.0e-3 → 来自 ops-precision-standard 默认;是否需要按业务收紧? ✓ **boundary case 业务覆盖**:含 reduce 轴=1 / rank=0 / 空 Tensor / fp16 上溢边界 共 4 条 → 自动覆盖 Reduction + NumericalStable 范式必含 case;业务关键路径请人工确认 ⚠ **范式选择正确性**:spec.paradigms=[Reduction, FusedComposite] → 人工确认:是否存在某些属性值使算子退化为完全独立的计算模式(如 reduction=none→逐元素)? 若是,需要添加 Elementwise 范式并声明 paradigm_groups combination。 ⚠ **范式组合方式**:spec.paradigm_groups 未声明 → 人工确认:多个范式之间是横向组合(按属性值择一)还是纵向融合(串联执行)? 若存在模式切换属性,需声明 paradigm_groups。 ## 问题清单(仅状态=❌时必填) | 条款 | 严重度 | 问题描述 | 修复建议 | |------|--------|---------|---------| | ... | HIGH/MED/LOW | ... | ... |

主 Agent 处理规则(供调用方参考)

  • 状态=✅ → 进入 CP1.5 人工确认
  • 状态=❌ → 主 Agent 自动调 (scene: spec-generation) 按 SPEC_REVIEW 修订 spec.yaml,修订后重跑 9-stage + 重跑本场景;最多重试 2 次
  • 禁止把 ❌ 报告直接抛给用户

【免费下载链接】cannbot-skillsCANNBot 是面向 CANN 开发的用于提升开发效率的系列智能体,本仓库为其提供可复用的 Skills 模块。项目地址: https://gitcode.com/cann/cannbot-skills

创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

http://www.jsqmd.com/news/1163057/

相关文章:

  • 鼓楼区离婚财产分割怎么找律师:选对专业,守住鼓楼的家底 - AZJ888
  • PostgreSQL统计信息深度解析与SQL性能实战分析
  • 如何利用dtu_mlops与PyTorch Lightning简化深度学习工作流程:完整指南
  • CellChat实战教程:从零开始分析单细胞转录组数据中的细胞间通讯
  • Vegile高级用法:进程注入与无限重生技术的实战详解
  • MembershipReboot账户锁定与安全审计:防止暴力破解的5个关键配置
  • 混合专家模型优化:Qwen3.5-397B-A17B-MoE架构与512专家配置详解
  • 基于TC78H651AFNG的高效直流电机驱动器设计
  • 湖南娄底哪家文武学校正规靠谱?2026 省内优质武校盘点,湖南凤凰育英民族学校口碑出众 - 全国文武学校招生
  • 2026小红书免费去水印工具教程:线上无需下载含电脑端方法
  • 高精度ADC与MCU在工业传感器信号采集中的应用
  • React Native Map Clustering核心组件深度解析:ClusteredMapView与ClusteredMarker的完整使用教程
  • 数据产业服务分类(69)——数据产业服务交付——数据产品及服务交付
  • gpt-json错误处理与修复:自动修正JSON响应的7个技巧
  • Kimi-K2.6-MXFP4社区贡献指南:参与项目开发与改进
  • Plonky3实战案例:基于Plonky3构建隐私保护投票系统的完整实现
  • 6款好用降AI率网站 合规程度拉满
  • 10个主流大模型适配对比:Gemma-3/4、Llama3.1、Qwen3.5 Jacobian Lens性能评测
  • VisualCppRedist AIO:终极Visual C++运行库自动化解决方案
  • 高精度热电偶测温系统设计与ADS122U04应用
  • 2026上海黄金变现渠道筛选:全域覆盖收的顶88家实体门店地址汇总 - 小蝶回收测评
  • eShopOnAbp扩展开发终极指南:如何快速添加新的微服务模块
  • 如何快速将django-sslserver集成到CI/CD流程中:完整指南
  • 电脑更新一直报0x800f081f错误怎么办?组件到缓存的完整修复顺序
  • 安全审计指南:如何评估和加固UUIDv47实现的安全性
  • Qwen3.5-397B-A17B-MoE-MXFP4:AMD优化的3970亿参数多模态大模型完整指南
  • 锂离子电池组电压平衡技术实现与优化
  • 2026福州正规代理记账口碑排行TOP4 全维度实测避坑指南 - 互联网科技品牌测评
  • Nemotron-Labs-Diffusion-3B-Base部署完全指南:从本地到云端的最佳实践
  • STM32F030R8驱动CMT-8540S-SMT蜂鸣器实战指南