CANN PyPTO-Gym A5 平台约束发现指南：从设备检测到容量定案的证据门禁

CANN PyPTO-Gym A5 平台约束发现指南从设备检测到容量定案的证据门禁【免费下载链接】pypto-gymPyPTO-Gym 是基于 PyPTO 编程框架构建的算子与模型样例仓库项目地址: https://gitcode.com/cann/pypto-gym本篇指南围绕 PyPTO-Gym 仓库中面向 A5dav-3510 / Ascend 950 系列的算子开发约束页 constraints/arch-a5.md 展开系统讲解在 A5 目标上开发 PyPTO-Pro 算子时必须遵守的「平台门禁」流程如何确认目标架构、从安装的 CANN/PyPTO 树中解析唯一权威的平台配置文件、在设计阶段按需提取容量常量以及为何「携带 key 而非 value」是防止数值失真的关键纪律。读完本文你将掌握一套可复现的 A5 平台证据获取流程并理解一个真实的容量争议UB 248 KB 还是 256 KB是如何被平台文件一锤定音的。适用范围什么情况下才启用这份约束该页面的适用条件非常明确当运行时或构建配置显式选择 A5 目标或工作流默认目标为 A5 时才加载本页一旦运行时或构建识别出 A2/A3 目标应立即停止套用本页约束。这与知识库的路由规则一致——在 constraints/README.md 的约束索引中arch-a5.md被定位为 A5-only platform discovery and evidence gate并明确要求 Do not load a platform-specific page until the target architecture is confirmed在目标架构确认前不要加载平台专属页面。更关键的是数值使用边界任何数值限制UB 容量、L0/L1 尺寸、核数等都必须以目标设备上的实测证据为准。如果无法确认架构或匹配的源文件宁可拒绝给出数值fail closed也不能凭记忆代入 A5 的值。这条纪律在 ROUTER.md 中被再次强调架构未确认前不要加载arch-a5.md未确认确切设备和来源前不要使用其中的数值限制。平台门禁Platform gate四步证据流程页面定义了一个强制性的四步门禁流程用于在任何设计工作开始前锁定平台事实检测目标架构使用 get_npu_arch.py 或构建配置确认目标。该脚本通过libascend_hal.so的halGetChipInfo查询芯片型号再到 CANN toolkit 的platform_config目录读取NpuArch字段找不到该字段时回退到内置映射表Ascend950 → 3510。输出格式为dav-3510--raw输出原始数字3510。记录设备证据记录设备型号、SKU、CANN 版本、PyPTO 版本以及解析出的pypto_pro.__file__路径。选择匹配的平台文件从安装树中选出与「确切安装版本 SKU」匹配的平台.ini文件。提取所需常量并引用只提取当前设计需要的常量并在EXPLORE_REPORT.md/DESIGN.md中引用文件与键名key。其中第 1、2 步的自动化支撑可以在环境检测技能的 env_preflight.py 中找到完整实现它分四层检测——[1] 设备层npu-smi 主后端 torch_npu 回退后端因 A5 环境的 npu-smi 常是残缺 stub、[2] 架构层复用get_npu_arch.py返回dav-*架构串、[3] 运行时层torch / torch_npu /pypto_pro.language/pl.jit可导入性、[4] CANN 层ASCEND_HOME_PATH/ toolkit / 版本 / OPP。输出的PREFLIGHT_JSON中npu_arch字段即第 1 步所需的架构证据。get_npu_arch.py的 CANN home 解析优先级也值得了解ASCEND_TOOLKIT_HOME→ASCEND_HOME→ 从ASCEND_OPP_PATH剥掉/opp推导 →ASCEND_HOME_PATH→ASCEND_CANN_HOME并支持ascend-toolkit/{version}、latest软链接与cann-{version}三种布局确保解析到「实际被使用」的 toolkit。主要来源路径Primary source paths数值只从这里来页面明确列出在已记录版本的已安装 PyPTO/CANN 树下解析的权威文件路径相对已安装树用途framework/src/platform/parser/simulation_platform/platform_config/950DT_957x.iniA5 基础平台配置UB/L0/L1/BT 容量、核数等匹配的950DT_958x.ini、950PR_957x.ini或950PR_958x.ini与检测到的 SKU 精确匹配的变体framework/src/platform/parser/platforminfo.ini平台基础信息python/pypto_pro/runtime/compile_config.py编译目标与编译配置python/pypto_pro/runtime/platform.py运行时平台信息如启动宽度 / core 数这些文件用于获取核数、内存预算、数据类型/分形fractal设置、路径与编译目标。本 KB 刻意不复制这些文件的数值——因为一旦把数值写进 KB 页面约束就会与已安装版本脱钩detach这正是页面顶部禁令要防止的实践。从源码结构可以推断get_npu_arch.py读取的正是platform_config/{soc_version}.ini中[version]段的NpuArch字段与上表第一类文件处于同一目录二者在工具链中天然配套。设计检查Design checks把约束变成可执行动作在拿到平台证据后页面给出五条设计期检查全部以「从检测目标推导」为原则逐 tile 推导字节大小从 shape 和 dtype 计算每个活跃 tile 的字节数按空间分组求和对 Vec、Mat、Left、Right、Acc 分别求和同时分配的字节再与检测目标的对应上限比较读 dtype 相关的收缩几何从匹配的平台文件读取收缩分形设置不要假设所有 dtype 共用一个 K 分形读启动宽度从运行时平台信息读取而不是硬编码某个 SKU 的核数——这一点在 a5-roofline-and-levers.md 中有直接印证四个 A5 ini 共享NpuArch3510与cube_freq1650以及相同的 L2/UB/L1/L0 尺寸但核数不同且ddr_rate相差超过两倍且platform.py只报告DAV_3510加核数只能收窄到两个 SKU因此必须记录实际读取了哪个 ini变更后重跑正确性任何 dtype、layout、buffering 或 tile-size 改动后都要重新验证正确性。UB 容量争议的定案248 KB 胜出且方法比数字更重要这是该页面最具教学价值的部分。A5 的 UB 容量曾经有两个流传值248 KB来自已安装教程tile_based_python_programming/multi_core_partitioning_and_Tiling.md一次作为限制陈述、一次出现在 FP16/FP32 预算示例内256 KB / 216 KB含 SIMT来自同硅片另一套 DSL 的设备档案。结论由平台文件一锤定音950PR_957x.ini携带ub_size253952即 248 KB 整950DT_957x、950PR_958x、950DT_958x三个文件同样如此。教程与平台配置一致256 KB 并不描述该 SKU 上工具链实际编译所依据的预算。但页面强调「如何定案」比数字本身更重要有两件事值得记住教训一搜索位置错误会得出「无来源」的错误结论此前一次调查声称「没有源码能定案 UB 数值」是因为它 grep 了python/pypto_pro——Python 包里本来就没有 UB 常量。预算住在平台.ini里而那正是本页主来源列表上方表格早已点名的位置。这正是 investigation-discipline.md §11 的第一条要求——where was looked, and for which names查了哪里、查了哪些名字——在真实问题上翻车的案例而修复只花了一次find。该节还给出了「声称能力缺失」前的五步证据清单API 面搜索查了哪里、查了哪些名字、已装签名证据、最近的可组合原语及失败原因、最小探针、生成代码或板端证据。注意其中两个陷阱find/Glob 默认不跟随符号链接$PYPTO_DEVKIT_DIR/pro_ops是软链接不加-L会返回零文件文档中的 dtype/能力表格不是白名单。教训二携带 key而不是携带 value设计在规划期应解析 SKU 平台文件里的ub_size而把「248」写进文档只是一个脱离产生它的版本的数字——这正是页面顶部禁止的实践。同理同一文件还定案了相邻的一整行容量l0_a_size、l0_b_size、l0_c_size、l1_size、bt_size、cube_core_cnt、vector_core_cnt、ubblock_size——其中ubblock_size是 32 字节的 UB 量子KB 各处的对齐规则如 vec-alignment-and-rotation.md 中Cols * sizeof(T) % 32 0的静态断言规则反复独立地收敛到它。页面建议从平台文件读取这些值而不要从任何页面包括本页读取。对 sibling DSL 设备表的检验结论逐行对照950PR_957x.ini后sibling DSL 的设备表在 L0A/L0B各 64 KB、L0C256 KB、L1512 KB、BT4 KB、28/56 核划分以及 A2/A3 的 192 KB UB 上都是正确的只有 A5 UB 一行错了——而恰好这一行是被引用最多的。因此它可作为交叉检验但复用任何一行前都必须对照平台文件验证。性能边界平台值是 roofline 输入不是实测性能页面最后提醒平台配置值只是 roofline 计算的输入而非 kernel 的实测性能瓶颈判定必须用目标 profiler。相关流程见平台门禁约束下的 A5 roofline workflow。该文档与arch-a5.md共享同一套证据门禁与主来源路径并给出可直接从 ini 复算的推导公式cube FLOP/s M*N*K (from [DtypeMKN]) * 2 * cube_core_cnt * cube_freq HBM B/s cube_core_cnt * [AICoreMemoryRates]ddr_rate * cube_freq vector_core_cnt * [VectorCoreMemoryRates]ddr_rate * vec_freq estimate max(bytes / HBM, MACs*2 / cube FLOP/s)这里再次强调「Pick the SKU deliberately」四个 A5 ini 核数与ddr_rate不同用错一个 roofline 就错一倍950DT与950PR在相同核数下也不可互换。在 KB 工作流中的位置target-gated 约束从 topology-map.json 的路由机制看arch-a5.md属于target-gated 约束路由收集流程的第 3 步是「Add the target-gated constraint selected by the explicit target or workflow default」即由显式目标或工作流默认值决定是否加入required_constraints。约束是正确性义务obligations一旦适用就永不截断——这与 CONTRACT.md 中 required_constraints「All applicable constraints; never truncated」的规则一致。规划者Planner在 Stage 1 前写入KB_SELECTION.json架构师Architect将其转化为设计不变量验证者Verifier独立核对只有验证者 PASS 才允许阶段完成。把这份约束页放进整个 A5 知识图景中看它与 pypto-pro-dsl-limitations-a5.md在 Ascend950PR、CANN 9.2.0 上实测的 DSL 限制集按「是否静默出错」排序互补前者锁定「平台能给你什么」后者记录「这套 DSL 在这块平台上有什么坑」二者共用同一条纪律——以目标环境的实测证据为准。小结一份可复用的 A5 证据检查清单用 get_npu_arch.py 确认目标为dav-3510A5非 A5 立即停止记录设备型号、SKU、CANN/PyPTO 版本与pypto_pro.__file__在已安装树中定位精确匹配的950xx_95xx.ini从其中读取ub_size、l0_a/b/c_size、l1_size、bt_size、cube_core_cnt、vector_core_cnt、ubblock_size在设计文档中引用「文件 key」不转抄数值变更 dtype / layout / buffering / tile-size 后重跑正确性性能结论一律以 profiler 实测为准。【免费下载链接】pypto-gymPyPTO-Gym 是基于 PyPTO 编程框架构建的算子与模型样例仓库项目地址: https://gitcode.com/cann/pypto-gym创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考