PyPTO 算子设计 API 约束全解析dtype、广播与数值精度的硬边界pypto-op-design 实战指南【免费下载链接】pypto-gymPyPTO-Gym 是基于 PyPTO 编程框架构建的算子与模型样例仓库项目地址: https://gitcode.com/cann/pypto-gymPyPTO 编程框架面向 NPU 算子与模型开发其算子设计阶段的每一步都受 API 层的类型、形状与精度约束制约。本文以 CANN / pypto-gym 仓库中 cannbot-skills/ops/pypto-op-design/constraints/api.md 记录的 6 条 API 约束C-API-01 至 C-API-06为骨架结合仓库内真实算子实现与 kernel 参考样例系统讲解sum、matmul、amax、exp等核心 API 的 dtype 配对、FP32 累加策略与广播 shape 规则。读完本文你将能够在算子设计阶段一次性规避“编译失败”“调用不支持”“舍入误差累积”等典型 API 层问题并把每条约束以稳定 ID 的方式写入 DESIGN.md。一、约束体系的组织方式稳定 ID、不复制规则在阅读具体 API 约束之前先理解这套约束文件的组织约定。constraints/README.md 明确说明约束描述 PyPTO 设计和实现必须遵守的边界设计文档引用稳定 ID不复制规则。规则按主题分布在api.md、tiling.md、loop.md、symbolic.md、dataflow.md五个文件中每条约束采用统一的 YAML 结构- id: C-AREA-01 level: must | must_not | should rule: 规则本身 when: 适用条件可选 source: 事实来源可选 consequence: 违反后的结果其中level字段是优先级语义的核心must硬性要求违反将导致编译/调用失败或结果错误属于设计红线must_not明确禁止的行为api.md 未直接出现但属于该枚举的合法取值should建议性要求违反不会立即报错但会带来精度、性能或稳定性隐患应在设计中显式记录取舍。在 pypto-op-design 工作流 中设计者在“计算图与 API 映射”阶段沿 golden 的数据依赖逐步分析为每个关键中间张量推导 shape 和 dtype 后再匹配 PyPTO API并对照本约束文件与目标版本文档检查类型转换、广播和归约记录转换位置及原因覆盖全部输出。这意味着api.md不是孤立的规则清单而是设计文档生成过程中必须逐条核对的检查表。二、dtype 约束逐 API 的硬性红线C-API-01 ~ C-API-042.1 sum按目标版本与设备文档选 dtype必要时显式转 FP32- id: C-API-01 level: must rule: sum 的输入 dtype 按目标版本和设备文档选择需要提高累加精度时显式转换为 FP32。 source: PyPTO docs/zh/api/tensor_api/operation/pypto-sum.md consequence: 不支持的类型会调用失败低精度累加可能引入误差。sum属于归约类 API其支持的输入 dtype 随 PyPTO 目标版本与设备昇腾 NPU 型号而不同不能想当然认为“和 torch 一样支持所有 dtype”。设计时须以目标版本文档即source指向的pypto-sum.md为准核对支持矩阵当累加对象本身是低精度FP16/BF16且对精度敏感时应先cast到 FP32 再归约而不是依赖 API 内部的隐式行为。仓库中的 kernel 参考样例与实现均遵循这一模式。在 attention.md 的 attention kernel 中softmax 分母的计算显式使用 FP32 中间量x pypto.cast(scores, pypto.DT_FP32) e pypto.exp(pypto.sub(x, pypto.amax(x, -1, True))) attn pypto.cast(pypto.div(e, pypto.sum(e, -1, True), pypto.PrecisionType.INTRINSIC), pypto_dtype)softmax.md 的注释更直接点明设计原则“中间 FP32非 FP32 输入首尾各一次cast”即输入先pypto.cast(a_s, pypto.DT_FP32)归约完成后在输出端再cast回原 dtype。而归约计数类场景同样先把 mask 转成 FP32 再求和例如 all.md 与 any.md 中的sum_val pypto.sum(mask_fp32, dim-1, keepdimTrue)从实现侧看mla_prolog_quant_v4_impl.py 等源码在构造累加缓冲时统一使用torch.float32与“精度敏感归约优先 FP32”的设计约束保持一致的工程实践。2.2 matmuldtype 配对必须满足目标 API转换位置要写进计算图- id: C-API-02 level: must rule: matmul 的两侧输入满足目标 API 的 dtype 配对要求转换位置在计算图中明确。 source: PyPTO docs/zh/api/tensor_api/operation/pypto-matmul.md consequence: 不支持的 dtype 配对会编译失败。matmul走 Cube 硬件单元其左右输入通常要求一致的 dtype如两侧均为 FP16/BF16或均为 FP32不支持的配对会直接导致编译失败而非运行期报错。因此约束要求两侧输入必须先满足配对要求且任何cast转换的位置必须在计算图中明确标注——即转换是作为独立节点存在而不是隐含在调用内部这样后续模块划分、接口文件生成和精度回溯时都能看到类型在哪一步发生变化。attention.md 展示了典型用法QK 与 PV 两次 matmul 都显式传入输出 dtype 参数且保证两侧输入同型scores pypto.matmul(q_s, k_s, pypto_dtype, b_transTrue) # ... r pypto.matmul(attn, v_s, pypto_dtype)值得注意的是该示例注释还提示了动态 shape 与 matmul 的兼容性问题matmul/归约类计算 API 在编译期需要 concrete shape不接受含 DYNAMIC 维度的 tensor见 pypto-api-explore/SKILL.md 中记录的has invalid shape value: -1报错。因此含动态轴且用到 matmul 的算子必须采用 loop 切 tile 策略把动态轴放在循环上属于设计风险评估的一部分。2.3 amax只用文档支持的 dtype低精度输入单独评估误差- id: C-API-03 level: must rule: amax 的输入使用其 API 文档支持的 dtype并单独评估低精度输入的误差。 source: PyPTO docs/zh/api/tensor_api/operation/pypto-amax.md consequence: 调用失败或误差超出要求。amax常用于 online softmax / flash attention 中的 running-max 计算。它同样有 dtype 支持边界设计时须核对pypto-amax.md同时低精度输入下amax的返回值本身就可能携带误差例如 FP16 表示范围与舍入导致的极值偏移进而影响后续exp的输入范围与 softmax 分母因此要求“单独评估低精度输入的误差”而不是把精度风险默认归零。在 attention.md 中pypto.amax(x, -1, True)的输入x正是刚被cast到 FP32 的 scores恰好满足“低精度输入先升精度再 amax”的推荐路径。2.4 exp仅支持 FP16 / BF16 / FP32整数输入直接不可用- id: C-API-04 level: must rule: exp 的输入使用 FP16、BF16 或 FP32。 source: PyPTO docs/zh/api/tensor_api/operation/pypto-exp.md consequence: 整数输入不受支持。exp是逐元素超越函数dtype 支持面明确收窄为三种浮点类型。这是最容易被忽视的一条在 softmax / GELU 类算子中若把整数索引或整数 mask 直接送入exp会因整数输入不受支持而调用失败。正确的做法是先cast为 FP32或目标浮点 dtype再计算。同时exp与sub、div、cast等逐元素 API 组合成 softmax 计算链时FP32 中间态也能规避 FP16 在极端输入下 exp 溢出或下溢的问题与 C-API-05 的精度策略互相印证。三、精度策略FP32 累加与转换位置一致C-API-05- id: C-API-05 level: should rule: 精度敏感的归约和跨循环累加优先使用 FP32转换位置保持与参考计算的数值要求一致。 consequence: 舍入误差可能随迭代积累。这是 api.md 中唯一一条should级约束但它恰恰是大模型算子attention、norm、量化 prolog 等数值精度的关键所在。理由很直接低精度累加在单次运算内误差有限但跨循环跨 batch、跨序列块、跨 tile累加时舍入误差会随迭代次数线性甚至超线性积累最终超出容差。约束同时强调“转换位置保持与参考计算的数值要求一致”——即升/降精度的位置必须与 golden 参考计算的数值语义对齐不能为了图省事在错误的位置转换。仓库源码对该策略的执行非常彻底。例如 softmax.md 中x pypto.cast(a_s, pypto.DT_FP32) # 入口一次 cast 到 FP32 e pypto.exp(pypto.sub(x, pypto.amax(x, -1, True))) r pypto.div(e, pypto.sum(e, -1, True), pypto.PrecisionType.INTRINSIC) pypto.assemble(pypto.cast(r, pypto_dtype), ...) # 出口一次 cast 回原 dtype归约链sub → exp → sum → div全程 FP32只在边界做两次 cast。实现侧的 BSA 前反向算子bsa_fwd_impl.py、bsa_bwd_impl.py同样用torch.float32显式构造 hint 与累加缓冲。此外to.md 展示了转换 API 本身的标准写法r pypto.cast(a_s, dst_dtype)转换作为独立逐元素操作嵌入计算图轴整块处理便于在设计中定位每一次 dtype 变化。四、广播约束按具体二元 API 的 shape 规则处理C-API-06- id: C-API-06 level: must rule: 广播按具体二元 API 的 shape 规则处理不支持的多轴组合先显式扩展或变形。 consequence: 输入 shape 不兼容。PyPTO 的二元 APIadd、sub、mul、div、gt、lt等的广播语义并不一定与 torch 的隐式广播完全等价不同 API 对多轴组合的容忍度不同。约束给出的处理策略是先按具体 API 文档的 shape 规则确认是否支持目标组合对不支持的多轴广播组合不要指望 API 自动扩展而是先用view/expand等操作显式扩展或变形到兼容 shape再进入计算。回到 attention.md 的 scale 广播示例scale_t pypto.full(scores_shape, scale, pypto_dtype) # 显式构造 [1, S, S] 形状 scores pypto.mul(scores, scale_t)这里没有依赖标量隐式广播而是用pypto.full显式构造与scores形状对齐的张量后做逐元素乘法——这正是“多轴组合先显式扩展”约束在实战中的直接体现。同理pypto.amax(x, -1, True)与pypto.sum(e, -1, True)都显式传入keepdimTrue保证归约结果形状可与原张量在广播链中正确对齐。五、约束如何嵌入算子设计流程从 API 映射到 DESIGN.mdapi.md的价值最终体现在 pypto-op-design 工作流 的执行过程中。流程要求在“计算图与 API 映射”步骤对照本约束文件检查类型转换、广播和归约并记录转换位置及原因覆盖全部输出随后在“设计检查结果”阶段复核 API 限制是否全部落实。这意味着实践中的标准动作是沿 golden 数据依赖为每个中间张量推导 shape 与 dtype逐节点匹配 PyPTO API并按 C-API-01~04 核对 dtype 支持面sum/matmul/amax/exp 各有硬边界对精度敏感路径按 C-API-05 安排 FP32 中间态与转换位置按 C-API-06 处理广播 shape 组合在 DESIGN.md 中以C-API-0x稳定 ID 引用结论不复制规则原文把 dtype 变化点同步进伪代码与模块接口用validate_artifacts.py做结构检查后交接给 develop 阶段。同时应记住约束中的source指向 PyPTO 官方 API 文档如pypto-sum.md、pypto-matmul.md文档与代码不一致时须注明版本并确认实际支持情况候选参数不代表已验证可用改变 dtype 或 shape 后需重新检查受影响的形状、资源和精度。这与仓库中 pypto-api-explore 的职责按准确 API 名核对签名、设备支持、默认值与使用限制形成互补设计阶段先用 docs-search 核文档再以api.md的稳定 ID 收敛结论是保证“可实现、可验证”设计的完整闭环。六、速查六条 API 约束一览ID级别核心规则主要后果仓库佐证C-API-01mustsum输入 dtype 按目标版本/设备文档选择需提精度时显式转 FP32不支持类型调用失败、低精度累加误差softmax.md、all.mdC-API-02mustmatmul两侧输入满足 dtype 配对转换位置在计算图中明确不支持的 dtype 配对编译失败attention.mdC-API-03mustamax使用文档支持 dtype低精度输入单独评估误差调用失败或误差超限attention.mdC-API-04mustexp仅支持 FP16 / BF16 / FP32整数输入不受支持softmax.mdC-API-05should精度敏感归约/跨循环累加优先 FP32转换位置对齐参考计算舍入误差随迭代积累mla_prolog_quant_v4_impl.py、bsa_fwd_impl.pyC-API-06must广播按具体二元 API 的 shape 规则处理不支持的组合先显式扩展/变形输入 shape 不兼容attention.md 中pypto.full显式构造 scale这六条约束共同构成了 PyPTO 算子设计阶段“API 可用性”的完整检查面dtypeC-API-01~04决定能不能编译、精度C-API-05决定准不准、广播C-API-06决定 shape 合不合法。在开始新的算子设计时建议直接以本表为模板把每条约束的核对结论与依据写入 DESIGN.md从而把 API 层的风险在进入代码实现之前全部显性化。【免费下载链接】pypto-gymPyPTO-Gym 是基于 PyPTO 编程框架构建的算子与模型样例仓库项目地址: https://gitcode.com/cann/pypto-gym创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 PyPTO 算子设计 API 约束全解析：dtype、广播与数值精度的硬边界（pypto-op-design 实战指南）
PyPTO 算子设计 API 约束全解析dtype、广播与数值精度的硬边界pypto-op-design 实战指南【免费下载链接】pypto-gymPyPTO-Gym 是基于 PyPTO 编程框架构建的算子与模型样例仓库项目地址: https://gitcode.com/cann/pypto-gymPyPTO 编程框架面向 NPU 算子与模型开发其算子设计阶段的每一步都受 API 层的类型、形状与精度约束制约。本文以 CANN / pypto-gym 仓库中 cannbot-skills/ops/pypto-op-design/constraints/api.md 记录的 6 条 API 约束C-API-01 至 C-API-06为骨架结合仓库内真实算子实现与 kernel 参考样例系统讲解sum、matmul、amax、exp等核心 API 的 dtype 配对、FP32 累加策略与广播 shape 规则。读完本文你将能够在算子设计阶段一次性规避“编译失败”“调用不支持”“舍入误差累积”等典型 API 层问题并把每条约束以稳定 ID 的方式写入 DESIGN.md。一、约束体系的组织方式稳定 ID、不复制规则在阅读具体 API 约束之前先理解这套约束文件的组织约定。constraints/README.md 明确说明约束描述 PyPTO 设计和实现必须遵守的边界设计文档引用稳定 ID不复制规则。规则按主题分布在api.md、tiling.md、loop.md、symbolic.md、dataflow.md五个文件中每条约束采用统一的 YAML 结构- id: C-AREA-01 level: must | must_not | should rule: 规则本身 when: 适用条件可选 source: 事实来源可选 consequence: 违反后的结果其中level字段是优先级语义的核心must硬性要求违反将导致编译/调用失败或结果错误属于设计红线must_not明确禁止的行为api.md 未直接出现但属于该枚举的合法取值should建议性要求违反不会立即报错但会带来精度、性能或稳定性隐患应在设计中显式记录取舍。在 pypto-op-design 工作流 中设计者在“计算图与 API 映射”阶段沿 golden 的数据依赖逐步分析为每个关键中间张量推导 shape 和 dtype 后再匹配 PyPTO API并对照本约束文件与目标版本文档检查类型转换、广播和归约记录转换位置及原因覆盖全部输出。这意味着api.md不是孤立的规则清单而是设计文档生成过程中必须逐条核对的检查表。二、dtype 约束逐 API 的硬性红线C-API-01 ~ C-API-042.1 sum按目标版本与设备文档选 dtype必要时显式转 FP32- id: C-API-01 level: must rule: sum 的输入 dtype 按目标版本和设备文档选择需要提高累加精度时显式转换为 FP32。 source: PyPTO docs/zh/api/tensor_api/operation/pypto-sum.md consequence: 不支持的类型会调用失败低精度累加可能引入误差。sum属于归约类 API其支持的输入 dtype 随 PyPTO 目标版本与设备昇腾 NPU 型号而不同不能想当然认为“和 torch 一样支持所有 dtype”。设计时须以目标版本文档即source指向的pypto-sum.md为准核对支持矩阵当累加对象本身是低精度FP16/BF16且对精度敏感时应先cast到 FP32 再归约而不是依赖 API 内部的隐式行为。仓库中的 kernel 参考样例与实现均遵循这一模式。在 attention.md 的 attention kernel 中softmax 分母的计算显式使用 FP32 中间量x pypto.cast(scores, pypto.DT_FP32) e pypto.exp(pypto.sub(x, pypto.amax(x, -1, True))) attn pypto.cast(pypto.div(e, pypto.sum(e, -1, True), pypto.PrecisionType.INTRINSIC), pypto_dtype)softmax.md 的注释更直接点明设计原则“中间 FP32非 FP32 输入首尾各一次cast”即输入先pypto.cast(a_s, pypto.DT_FP32)归约完成后在输出端再cast回原 dtype。而归约计数类场景同样先把 mask 转成 FP32 再求和例如 all.md 与 any.md 中的sum_val pypto.sum(mask_fp32, dim-1, keepdimTrue)从实现侧看mla_prolog_quant_v4_impl.py 等源码在构造累加缓冲时统一使用torch.float32与“精度敏感归约优先 FP32”的设计约束保持一致的工程实践。2.2 matmuldtype 配对必须满足目标 API转换位置要写进计算图- id: C-API-02 level: must rule: matmul 的两侧输入满足目标 API 的 dtype 配对要求转换位置在计算图中明确。 source: PyPTO docs/zh/api/tensor_api/operation/pypto-matmul.md consequence: 不支持的 dtype 配对会编译失败。matmul走 Cube 硬件单元其左右输入通常要求一致的 dtype如两侧均为 FP16/BF16或均为 FP32不支持的配对会直接导致编译失败而非运行期报错。因此约束要求两侧输入必须先满足配对要求且任何cast转换的位置必须在计算图中明确标注——即转换是作为独立节点存在而不是隐含在调用内部这样后续模块划分、接口文件生成和精度回溯时都能看到类型在哪一步发生变化。attention.md 展示了典型用法QK 与 PV 两次 matmul 都显式传入输出 dtype 参数且保证两侧输入同型scores pypto.matmul(q_s, k_s, pypto_dtype, b_transTrue) # ... r pypto.matmul(attn, v_s, pypto_dtype)值得注意的是该示例注释还提示了动态 shape 与 matmul 的兼容性问题matmul/归约类计算 API 在编译期需要 concrete shape不接受含 DYNAMIC 维度的 tensor见 pypto-api-explore/SKILL.md 中记录的has invalid shape value: -1报错。因此含动态轴且用到 matmul 的算子必须采用 loop 切 tile 策略把动态轴放在循环上属于设计风险评估的一部分。2.3 amax只用文档支持的 dtype低精度输入单独评估误差- id: C-API-03 level: must rule: amax 的输入使用其 API 文档支持的 dtype并单独评估低精度输入的误差。 source: PyPTO docs/zh/api/tensor_api/operation/pypto-amax.md consequence: 调用失败或误差超出要求。amax常用于 online softmax / flash attention 中的 running-max 计算。它同样有 dtype 支持边界设计时须核对pypto-amax.md同时低精度输入下amax的返回值本身就可能携带误差例如 FP16 表示范围与舍入导致的极值偏移进而影响后续exp的输入范围与 softmax 分母因此要求“单独评估低精度输入的误差”而不是把精度风险默认归零。在 attention.md 中pypto.amax(x, -1, True)的输入x正是刚被cast到 FP32 的 scores恰好满足“低精度输入先升精度再 amax”的推荐路径。2.4 exp仅支持 FP16 / BF16 / FP32整数输入直接不可用- id: C-API-04 level: must rule: exp 的输入使用 FP16、BF16 或 FP32。 source: PyPTO docs/zh/api/tensor_api/operation/pypto-exp.md consequence: 整数输入不受支持。exp是逐元素超越函数dtype 支持面明确收窄为三种浮点类型。这是最容易被忽视的一条在 softmax / GELU 类算子中若把整数索引或整数 mask 直接送入exp会因整数输入不受支持而调用失败。正确的做法是先cast为 FP32或目标浮点 dtype再计算。同时exp与sub、div、cast等逐元素 API 组合成 softmax 计算链时FP32 中间态也能规避 FP16 在极端输入下 exp 溢出或下溢的问题与 C-API-05 的精度策略互相印证。三、精度策略FP32 累加与转换位置一致C-API-05- id: C-API-05 level: should rule: 精度敏感的归约和跨循环累加优先使用 FP32转换位置保持与参考计算的数值要求一致。 consequence: 舍入误差可能随迭代积累。这是 api.md 中唯一一条should级约束但它恰恰是大模型算子attention、norm、量化 prolog 等数值精度的关键所在。理由很直接低精度累加在单次运算内误差有限但跨循环跨 batch、跨序列块、跨 tile累加时舍入误差会随迭代次数线性甚至超线性积累最终超出容差。约束同时强调“转换位置保持与参考计算的数值要求一致”——即升/降精度的位置必须与 golden 参考计算的数值语义对齐不能为了图省事在错误的位置转换。仓库源码对该策略的执行非常彻底。例如 softmax.md 中x pypto.cast(a_s, pypto.DT_FP32) # 入口一次 cast 到 FP32 e pypto.exp(pypto.sub(x, pypto.amax(x, -1, True))) r pypto.div(e, pypto.sum(e, -1, True), pypto.PrecisionType.INTRINSIC) pypto.assemble(pypto.cast(r, pypto_dtype), ...) # 出口一次 cast 回原 dtype归约链sub → exp → sum → div全程 FP32只在边界做两次 cast。实现侧的 BSA 前反向算子bsa_fwd_impl.py、bsa_bwd_impl.py同样用torch.float32显式构造 hint 与累加缓冲。此外to.md 展示了转换 API 本身的标准写法r pypto.cast(a_s, dst_dtype)转换作为独立逐元素操作嵌入计算图轴整块处理便于在设计中定位每一次 dtype 变化。四、广播约束按具体二元 API 的 shape 规则处理C-API-06- id: C-API-06 level: must rule: 广播按具体二元 API 的 shape 规则处理不支持的多轴组合先显式扩展或变形。 consequence: 输入 shape 不兼容。PyPTO 的二元 APIadd、sub、mul、div、gt、lt等的广播语义并不一定与 torch 的隐式广播完全等价不同 API 对多轴组合的容忍度不同。约束给出的处理策略是先按具体 API 文档的 shape 规则确认是否支持目标组合对不支持的多轴广播组合不要指望 API 自动扩展而是先用view/expand等操作显式扩展或变形到兼容 shape再进入计算。回到 attention.md 的 scale 广播示例scale_t pypto.full(scores_shape, scale, pypto_dtype) # 显式构造 [1, S, S] 形状 scores pypto.mul(scores, scale_t)这里没有依赖标量隐式广播而是用pypto.full显式构造与scores形状对齐的张量后做逐元素乘法——这正是“多轴组合先显式扩展”约束在实战中的直接体现。同理pypto.amax(x, -1, True)与pypto.sum(e, -1, True)都显式传入keepdimTrue保证归约结果形状可与原张量在广播链中正确对齐。五、约束如何嵌入算子设计流程从 API 映射到 DESIGN.mdapi.md的价值最终体现在 pypto-op-design 工作流 的执行过程中。流程要求在“计算图与 API 映射”步骤对照本约束文件检查类型转换、广播和归约并记录转换位置及原因覆盖全部输出随后在“设计检查结果”阶段复核 API 限制是否全部落实。这意味着实践中的标准动作是沿 golden 数据依赖为每个中间张量推导 shape 与 dtype逐节点匹配 PyPTO API并按 C-API-01~04 核对 dtype 支持面sum/matmul/amax/exp 各有硬边界对精度敏感路径按 C-API-05 安排 FP32 中间态与转换位置按 C-API-06 处理广播 shape 组合在 DESIGN.md 中以C-API-0x稳定 ID 引用结论不复制规则原文把 dtype 变化点同步进伪代码与模块接口用validate_artifacts.py做结构检查后交接给 develop 阶段。同时应记住约束中的source指向 PyPTO 官方 API 文档如pypto-sum.md、pypto-matmul.md文档与代码不一致时须注明版本并确认实际支持情况候选参数不代表已验证可用改变 dtype 或 shape 后需重新检查受影响的形状、资源和精度。这与仓库中 pypto-api-explore 的职责按准确 API 名核对签名、设备支持、默认值与使用限制形成互补设计阶段先用 docs-search 核文档再以api.md的稳定 ID 收敛结论是保证“可实现、可验证”设计的完整闭环。六、速查六条 API 约束一览ID级别核心规则主要后果仓库佐证C-API-01mustsum输入 dtype 按目标版本/设备文档选择需提精度时显式转 FP32不支持类型调用失败、低精度累加误差softmax.md、all.mdC-API-02mustmatmul两侧输入满足 dtype 配对转换位置在计算图中明确不支持的 dtype 配对编译失败attention.mdC-API-03mustamax使用文档支持 dtype低精度输入单独评估误差调用失败或误差超限attention.mdC-API-04mustexp仅支持 FP16 / BF16 / FP32整数输入不受支持softmax.mdC-API-05should精度敏感归约/跨循环累加优先 FP32转换位置对齐参考计算舍入误差随迭代积累mla_prolog_quant_v4_impl.py、bsa_fwd_impl.pyC-API-06must广播按具体二元 API 的 shape 规则处理不支持的组合先显式扩展/变形输入 shape 不兼容attention.md 中pypto.full显式构造 scale这六条约束共同构成了 PyPTO 算子设计阶段“API 可用性”的完整检查面dtypeC-API-01~04决定能不能编译、精度C-API-05决定准不准、广播C-API-06决定 shape 合不合法。在开始新的算子设计时建议直接以本表为模板把每条约束的核对结论与依据写入 DESIGN.md从而把 API 层的风险在进入代码实现之前全部显性化。【免费下载链接】pypto-gymPyPTO-Gym 是基于 PyPTO 编程框架构建的算子与模型样例仓库项目地址: https://gitcode.com/cann/pypto-gym创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考