昇腾开源仓Issue分析解答-CANN精选（一）

一句话让Agent变成昇腾专家，不必再找人问了。评测入口：请按这个开源仓接入昇腾图谱 https://gitcode.com/agent0/kg-tools

总览

仓库	定位	收录条数
asc-devkit	Ascend C 算子开发套件	14
pypto	PyPTO 算子工具链	13
ops-sparse	稀疏算子库	6
catlass	Catlass 高性能算子库	2
graph-autofusion	图自动融合	8
ge	图引擎	7

asc-devkit（Ascend C 算子开发套件）

Ascend C 语言、编译、调试与算子开发配套，算子开发者日常打交道最多的仓库

编号	Issue 问题内容	解答总结
#1357	9.0.0 下 LocalMemAllocatorHardware::UB 须带全命名空间编译	9.1.0/9.2.0 与官方示例同写法均可编译，9.0.0 却须补全为 LocalMemAllocatorAscendC::Hardware::UB。官方确认根因：头文件重复定义 Hardware 符号，非用法错误；4/30 发布的 9.0.0 已修复，升级 CANN 包即可、无需改代码。该接口用于 UB/L1 等硬件内存显式管理，用法参考 tensor_allocation 样例。
#1370	mix 算子 1:1 时 Fixpipe 从 L0C 直搬 UB 报 aicore error	KERNEL_TYPE_MIX_AIC_1_1 下 fixpipe L0C→UB 直出：mode4 同步 AIV/AIC 双报错，1:2 只搬 sub-0 正常。官方确认 1:1 硬件不支持 fixpipe 直搬 UB，属硬件约束而非软件 bug，资料已补约束（PR#5111）。KG Fixpipe 文档亦只定义 L0C→GM/L1 通路。规避：改 1:2 或经 GM/L1 中转。
#1389	CV 融合算子 Matmul 默认 MIX/CS 架构 scalar 空转占比近 90%	官方确认：CV 分离架构下 Matmul 默认 MIX 模式，AIV 为 client 经消息通信框架驱动 AIC 侧 MatmulService，约 +10% scalar 开销，cube 等 vector 时空转放大占比。纯矩阵场景开纯 Cube 模式跳过消息框架，scalar 开销降 22%；需 CV 协同参考 matmul_fused_manual 样例插核间同步；msopprof 定位。
#1434	InitGlobalMemory 大 size（9.8 亿元素）填充时 AI Core 超时	刷 -INF 入参 980591780 报 aicore timeout，注释即消失。官方：InitGlobalMemory 已废弃，改用 Fill，实测 9.8 亿元素无报错。KG Fill 样例补充：950 已删 L0A/L0B 初始化指令，A2/A3 可 Fill 直填 L0，950 需 Fill L1 后 LoadData 搬入。大容量初始化一律用 Fill。
#1448	VF 内 printf 格式字符串占 UB 静态区，挤占业务 UB 有溢出风险	printf 的 ubuf 字符串放静态内存、占 GetCoreMemSize 返回 248K UB 的头部，tiling 感知不到，按满额规划即可能越界，文档未提示。官方澄清 248K 已含静态区，但确认矛盾成立；长期方案（SE 需求）把字符串移 GM。过渡期调测构建可用 UB 更小，需单独调 tiling。VF printf 为 v9.1.0-beta.2 新增（PR#1605）。
#1451	310P3 跑 int8 矩阵乘示例报 VEC 目的块同址错误	参考新 SIMD C++ API 矩阵乘示例、half 改 int8 后在 310P3 报 507015 + destination blocks same address。官方：示例支持产品不含 310P，不能直接搬用——KG Fixpipe 文档同样明确 310P 不支持新 Fixpipe 接口。
#1467	算子只 EnQue 不 DeQue，第 5 个用例起整卡挂死	只进队不出队的算子部署后整卡挂起，杀进程重跑仍卡死。官方定性：硬件寄存器残留引起同步不匹配，不想 reboot 可等 18 分钟硬件自复位；服务侧用 aclrtSetOpExecuteTimeOut 设超时止损。根因是违反编程范式：EnQue/DeQue 必须配对（TPipe/TQue 指令队列机制），不配对属未定义行为且编译器不强制检查，8.5.0 建议先开 CPU 模式校验再上板。
#1471	Mask1 变体算子输出全零，疑似系统性失效	用户 DumpTensor 逐位核对后更正：Reciprocal/Exp_Mask1 执行正确——wrapper 生成的 mask 稀疏（仅 10/64 位置位），未置位元素按 Mask1 语义保持原值，全零是判定误判、非 CANN 缺陷。真问题仅 Cast_Mask1：根因同 #1470，CAST_NONE 的 float→int32 在 A3/910B 不支持、静默不执行。
#1477	expf 单点输出与 CPU 差 1ulp（末位 1bit 翻转）	input=-0.7415…：CPU 输出 0x3ef3ea86，NPU 输出 0x3ef3ea87，仅末位 1bit 差。官方结论：硬件指令精度误差为 1ulp，符合预期、非缺陷。跨平台数值对齐按"误差≤1ulp 即通过"设定容差即可，不必追求 bit 级一致；官方数学接口精度标准亦按 ulp 定义。确需 bit 级对齐 CPU 的只能 host 侧自行实现或换软仿路径。
#1484	BiSheng O2/O3 编译 simd_vf 内 0/1 次循环时段错误	O0/O1 通过、O2/O3 exit 139、-mllvm -vloop-unroll-disable 可过，定位为 HiIPUVectorLoopUnrollPass 处理运行时 0/1 次 trip count 尾块循环的编译器缺陷，已修复、随 CANN 包发布。升级前规避：触发循环加 #pragma clang loop unroll(disable)。
#1560	mix kernel AIV 侧 Cast<int32,float> 第 3 次迭代起输出全 NaN	int8 FlashAttention kernel，AIC 经 Fixpipe 写 int32 到 UB，AIV 在 WaitFlag 后 Cast，第 3 次迭代起全 NaN。官方定位：算子读写抢占导致崩溃，Cast 接口功能正常——需按 pipeline 同步语义修复跨核 UB 读写。用户按建议修复后解决。启示：跨核数据交换必须显式同步，勿凭"前两次正确"推断无竞态。
#1567	fp64→fp32 对 subnormal 数置零/截小，与 CPU/GPU 不一致	次正规区间 (0,1.18e-38) 输出 96.7% 清零、3.3% 截小，正规数 bit 级一致。官方确认：fp64→fp32 走软仿实现（硬件无此通路），软仿暂不支持 subnormal、此前文档未写明；将补约束说明，后续计划经编译选项支持。精度用例含极小值时需预清洗（clip 到正规区间）或容忍 FTZ 差异。同期 PR#5999 已更新数学函数 Subnormal 约束文档。
#1586	LoadData 兼容接口 transpose 分支部分 shape 精度 no pass	950PR 对比 legacy/transpose/v2 三模式，legacy 兼容模式在 deep 等 shape 失败。根因：转置分支源地址偏移算错且大偏移乘法溢出。修复：新增 srcFractalIndex 并 static_cast<uint64_t> 防溢出、源地址按 stride 逐块定位，PR 已合入、24/24 通过。新代码建议用增强指令 LoadData_2D_V2。
#1609	新算子仓配 8/1 前旧 asc-devkit 包在线编译报找不到 helpers.h	CI 新算子包依赖主线最新 tensor_api/c_api（含 utils/base/helpers.h），8/1 前旧 asc-devkit 包无此文件，版本不匹配致 include 失败。方案一：统一用最新 asc-devkit；方案二：特性分支用 PR#5511 补齐，配套 ops-tensor PR#337 同步 commitId。

pypto（PyPTO 算子开发工具链）

Python 域算子开发范式，含 dump/调试/编译链路与内置性能模型

编号	Issue 问题内容	解答总结
#2939	dump 取址走旧路径，workspace 无效仍 memcpy，空地址拷贝致 core dump	PR#5380 对齐 AICore 实际取址：经 DynFuncData 解析，LOCAL 走 workspace+offset，否则 rawTensorAddr 加掩码；地址为 0 时跳过 dump 并告警，新增 #sche.dump.* 日志。评论仅附件日志，PR 按时间线与主题对应。排查可用 debug_aicore_error.py 收集故障信息。
#2947	stitchNumMax 与 unroll 次数取 max，小于 128 的配置被抬高，调小无效	PR#5434（官方指认）：非内存驱动模式下 stitchNumMax 直接用配置值，不再与 maxUnrollTimes 取 max；补齐 !4979 回退后 encode 侧遗漏（runtime 已按 root 计量而 encode 仍抬高）。配置 max_workspace_kb 的内存驱动行为不变，仍走 EffectiveStitchNumMax。
#3011	CreateDyn 对 dlsym 返回的函数指针未判空即调用，符号缺失时空函数指针调用崩溃	该路径经 Python 绑定 7 层可达，实际触发概率高。PR#5506：dlsym 返回 NULL 时 throw runtime_error，不再裸调；soPath 参数化便于测试，默认值保持原行为。官方当天回复已解决。
#3016	AllocDev 失败返回 nullptr，AllocZero 未判空直接 memset 崩溃	防御式修复：PR#5508 为测试工具补空指针检查，失败路径提前处理，不改变正常路径行为。与 #3021/#3011 同批静态扫描缺陷，官方均确认处理。此类 ST 工具缺陷平时难触发，但是 OOM 场景下的连环崩溃源。
#3021	解析外部 topo 文件的 fields 向量不校验长度，字段不足 13 个仍按下标访问，越界 UB	外部文件属不可信输入，必须校验。PR#5506 补防御式修复：ParseDynTopo 访问前校验 fields 数量；同 PR 一并修复 PvModelFactory dlsym 判空。官方当天回复已解决。静态扫描类缺陷均为防御式补齐，不改变正常路径行为。
#3042	build_ci 并发度只看 CPU 数不看内存上限，32GiB 容器 -j116 编译 OOM	PR#5721：job_num 改由 CPU 数与 cgroup 内存上限联合自动推导；同时补充 pip 编译内存/并行度要求文档。规避：高核低内存环境手动 -j8/-j16。cgroup oom_kill 偏高的环境应先核对内存上限再放开编译并发。
#3182	DRCO 下控制流 AICPU 与生产者并发且等待被空操作化，读旧数据致 MTE 越界	PR#5810：恢复 WaitAicoreStart 自旋等待；core0 InitDrcoEntry 置 syncFlag=1（aicore entry 流序在 producer 后即数据就绪）；退出清 0。#2227 修过非 DRCO 路径，此为遗漏场景。KG FAQ：『数据依赖边丢失』是 aicore error 常见根因，可用 debug_aicore_error.py 定位。
#3191	assemble 按完整 tile 而非 valid_shape 写回，尾块静默越界写	官方基于 0907 最新版复测不复现（原复现脚本未设 tile shape，与描述不符）。尾块场景应显式收窄 view 的 valid_shape 并控制 assemble 写入区。KG pypto-pro DSL 限制文档记录同族模式：静态 valid_shape 缺失时 fallback 按 tile 物理 shape 全量发出且无诊断，有效区必须显式管理。
#3192	子视图 reshape 不传播 valid_shape，静默变全量致 assemble 越界写	官方定性为接口语义：reshape 不推导输出 valid_shape，用户须自行计算显式传入（mhc_pre 案例传 [actual_bs,N,N] 即恢复）。PR#5966 文档补充该提示。KG 官方 API 文档中 valid_shape 本就是显式参数，支持 SymbolicScalar。
#3194	重复索引时多行写同一目标、结果取决于写入顺序，实现不检测不告警；文档漏 INT8 支持声明	PR#6027（Related #3194）：补 ScatterUpdate 校验并在文档添加 INT8 支持。同类 index_put_ 已文档化『重复索引行为未定义』。建议保证 index 唯一或接受非确定结果。KG 文档确认其为原地 2D/4D 更新语义，dtype 列表原不含 INT8。
#3195	unroll>1 时 RegisterCopy 拷贝路径选错，token[1…N-1] 静默损坏	官方核查：复现脚本报 CHECK_OP——assemble 要求 src/dst 同秩，x[idx,:] 经 view+reshape 成 1D 与 2D 目标不符，属用法问题，issue 关闭；RegisterCopy 未在本 issue 获确认修复。规避 unroll_list=[1] 关闭展开。KG 文档：展开因子排序去重且总含 1。
#3212	组检查只按 subgraphId 判内外，同 scope 组外端点被误拒，两组互锁融合失效	PR#5920（Closes #3212）：BoundaryTensorInfo 增加端点级 producer/consumerCvFuseIds；新增平行判定 IsInvalidMergedInnerTensorByCvFuseId：组外端点与组内 CvFuseId 集合相同则豁免（同 scope 终将同组），异 scope 仍拒，端点为 -1 则豁免失效，边界 tensor 不再走 DDR。
#3290	L1_reuse=4 时行块被切成 4 个 cube 子图，末子图依赖前三个，vec 子图推迟近串行	官方指认 PR#6065：新 IR 后 MergeViewAssemble 遇 View/Slice 旁路消费者即停止链合并，残留中间链影响内存通路选择；修复为无 token 函数恢复分支合并。另有 PR#6168（标题即 Fix issue3290 token partition）。最新主线验证 OK。

ops-sparse（稀疏算子库）

SpMV/SpMM/SpGEMM 等稀疏算子实现与性能验收

编号	Issue 问题内容	解答总结
#76	SpMV kernel 7处GlobalTensor单元素访问GM低效；QUICKSTART路径失配	问题B文档路径已修（PR#151后续统一修正QUICKSTART并补环境章节）。问题A：维护者实测把rowPtr读取改DataCopyPad批量搬运收益不明显——仅2个标量、gather地址难保证32B对齐、反多占UB，大shape甚至略降。KG最佳实践亦将GM单元素读写列入生产黑名单（逐次触发GM↔UB搬运），但替换需评估数据量、对齐与局部性，非机械套用。
#163	aclsparseSpMM P-01实测180μs仅0.48×A100，验收口径与优化方向存疑	官方确认验收口径=单次torch.sparse.addmm内全部NPU kernel之和的中位数；上库版本此前按整体平均性能比验收（超1.0达标），宽N低nnz case仍有未过，需补行nnz分布、tile切分、活跃核数、访存指标定位。提问者按#166口径用真Cora复测：35.033μs vs A100 87.040μs=2.485×，早期180μs系合成数据口径偏差。
#166	性能验收表P-01/02/03缺canonical CSR fixture，A100基线无法复现	官方确认：P-01=PyG Planetoid(Cora)；P-02=ogbn-arxiv原始有向图；P-03=ogbn-products保持OGB Loader双向边。CSR规则：不加self-loop、不额外对称化、同坐标coalesce、行内列升序、I32 base0；附件性能JSON与三case无一一对应，公开材料难复现基线。提问者按真Cora复测35.033μs=2.485×A100。
#169	950PR(arch35)下build.sh --soc=ascend950编译spmm连续三类报错	官方分类核验：仅问题①（test/spmm CMake找不到spmm_test.cpp）为master真实缺陷，主线已修复，同步后编译通过；问题②spgemm_common.h缺失、③kernel类型属性推导失败均出自提问者本地开发分支（master无sparse/spGEMM目录）。教训：报工程缺陷先对齐master，分支问题走咨询PR并附个人分支链接。环境CANN 9.1.0/bisheng。
#189	spmm/arch22 M/K/N无上限校验，static_cast静默截断致内核维度错误	根因：arch22把rows/cols直接static_cast为uint32_t，无上限校验，超大shape静默截断写入tiling致内核维度错误；arch35的ValidateSpmmInputs已有rows≤INT32_MAX校验，两代防护不一致。PR#161为arch22 SpMM补M/K/N/nnz上限校验，官方09-03确认已修复。host代码应参照同仓最新架构校验清单。
#190	spmv/arch22 host放行FLOAT计算类型的未实例化dtype组合，错配写坏输出	根因：SPMV_EXTERN仅实例化7种dtype组合，host校验只约束INT32分支，FLOAT计算类型放行未实例化组合（如val=I32/out=I32），分发器按float写int32缓冲，类型混淆损坏数据。PR#161为arch22 SpMV补全dtype组合白名单；同PR还修复描述符double-free等#181-190系列缺陷。官方09-03确认已修复。

catlass（Catlass 算子库）

面向 MoE/Attention 场景的高性能模板库

编号	Issue 问题内容	解答总结
#369	MoE下expert token数悬殊，grouped slice M是否致AICore负载不均	官方：kernel按序循环每个group，按L1:M/L1:N切块并修正尾行尾列block，Swizzle排布后把block0…block_tail依次分给各逻辑核，并把block_tail的下一核更新为下一group的startCoreIdx——组间连续接力，expert token再多也只是多占若干block，不会核间空闲，无需动态迁移。catlass 65号FP8样例即该调度参考。
#487	950PR编译81 rain_attn样例报simd_vf函数必须为free或static函数	根因：bisheng对__simd_vf__（cce_simd_vf）函数强约束——必须为自由函数或static成员函数；rain_fusion_attention epilogue的ComputeScaleAndMax等为非静态成员，CANN 9.2.0.beta1/950PR下编译报错。修复：为vf函数加static（PR#1193）；样例后迁experimental（PR#1239）。

graph-autofusion（图自动融合）

自动图融合优化 pass，融合正确性与性能的守门人

编号	Issue 问题内容	解答总结
#78	多轴slice-concat融合时Load尾轴对齐与Concat输出32B对齐口径不一致，精度出错	根因：多轴slice时Load做尾轴对齐，而Concat输出未对齐到32B，两侧对齐假设不一致导致读数错位。修复修改V2对齐策略：非尾轴concat场景若Concat输入已对齐，Concat改用默认对齐策略，保证融合边界两侧一致。官方确认修改已合入。避坑：融合后精度异常可先关闭该融合pass对比定位对齐类根因。
#88	删除Concat输入端reverse Cast前未检查消费者数，多消费者时dtype断裂	cast_optimization_pass.cpp的DoOptimize无条件删除reverse Cast；Cast还有其他消费者时被全部重连到其输入节点，dtype不连续（abs期望FP32却接FP16）。修复：单消费者保持删除；多消费者仅断开Concat连接、直连dtype匹配的源并保留Cast。避坑：优化pass删节点前必须检查出度。
#119	split不均等拆分成多轴后各输出共用一个load，无法拆分子图致精度问题	split走进case3场景转load时，各输出轴大小不同却连在同一load上，无法拆分到子图，引发精度错误。Ascend910D白泽用例tc_af_SPBC_0356可复现。修复PR#876已合入，调整该场景拆图与调度逻辑，使不等分多轴输出正确进入子图。
#239	pre_pos初始化为0兼具未找到语义，前置stride全0时误把首轴当有效前置轴	BroadcastRegApiCall生成BroadcastExtend参数时，pre_pos用于记录前置非零vectorized stride轴，初始化为0；前置各轴stride全为0时找不到前置轴也不更新，索引0的首轴被误当有效前置轴，尾轴尺寸错误引用首轴信息，可能导致生成代码错误。修复：以明确无效值表示未找到，此时直接按当前轴算尾轴；保留已找到时的合并逻辑并补UT/ST。
#241	A5盘古92B开SuperKernel输出乱码，HiF8量化、不加scope时精度异常	官方排查：8/22定位到A5上Tile算子与SK功能相互影响；9/11确认为算子间同步不匹配，模型替换问题算子后精度恢复。规避：关闭SuperKernel，或按层加scope缩小融合范围（用户实测每层加scope后正常）。KG文档印证：SuperKernel为二进制层融合，可aclskScopeBegin/End标定范围，None标记排除算子且优先级最高。
#242	动态创建的Scalar因api_type无效未被识别，误入Concat轴替换触发断言、编译失败	动态Scalar未补全API类型（kAPITypeInvalid）致IsBuffer()为false，被纳入复制集合后进入ReplaceAxis()，在axis=[5]中查Concat轴0/6触发断言、编译失败。修复：CloneNonConcatNodes轴替换排除Scalar与IsDataInput()节点，仅普通Compute节点参与，保留断言不掩盖异常。
#282	Reduce source reuse仅看输入出度，未识别上游Broadcast共轴语义冲突致精度错	Broadcast->Reduce链中，B轴与R轴为同一vectorized_axis且Broadcast扩展、Reduce归约时，复用Reduce输入source会改写Broadcast仍依赖的数据，输出精度错误。修复：在单出度判断上遍历Reduce上游数据链，比较Broadcast输入输出轴与stride，存在同轴冲突即禁止复用；元数据计算与codegen复用同一判断，避免两侧策略不一致。
#305	多上游分支任一分支命中BR共轴风险即禁用整个Reduce输入复用，误伤性能	这是#282修复判定过宽的后续：多分支Reduce图中只要任一上游路径存在Reduce轴上的Broadcast，整个节点输入复用即被关闭，正常分支也被迫拆分搬运、性能退化。修复：递归检查每条上游路径，仅当所有分支都存在Broadcast on Reduce Axis风险才禁用；普通传递/Gather分支保留复用。

ge（图引擎）

计算图编译与执行核心，ATC 编译报错多半在这里定位

编号	Issue 问题内容	解答总结
#431	GE初始化与去初始化分落不同线程，aclrtSetDevice线程绑定语义致GetDevice失败	TF 1.x的session.run用线程池执行，GEInitialize与GEFinalize可能落在不同线程；aclrtSetDevice创建的默认Context绑定线程，Finalize线程未SetDevice，其依赖aclrtGetDevice的环节（HCCL Finalize等）报107002 rtGet device fail。已由hcom修复（cann/hcomm#2928）。
#441	动态shape JIT在线编译下稀疏算子每次推理重新编译，咨询缓存容量与老化配置	官方仅反问使用场景后关闭。KG官方文档：ATC编译缓存以–op_compiler_cache_mode=enable开启；容量与老化在op_cache.ini配置：max_op_cache_size（默认500MB）限空间，remain_cache_size_ratio（默认50%）删旧保留比例；op_debug_level非0忽略缓存。
#445	310P3动态shape PaddleNLP编译报未知ATC错误码1343266818并崩溃	官方要求提供ATC完整命令与编译日志后转移关闭，无最终结论。KG FAQ排查：atc加–log=debug --dump=1查/var/log/ascend_seclog/atc.log；动态shape用–dynamic_batch_size/–dynamic_image_size明确范围；核对soc_version与CANN版本。Unknown错误码必须靠详细日志定位。
#490	用户称CANN默认为每模型保留三图内存致3-4倍膨胀；官方实测澄清为误解	官方澄清：aclgrphBuildModel推理路径不会自动生成/保留var_init/var_update图，三图仅由权重更新API显式调用产生；OM大小不等于NPU内存，加载另分配IO与workspace。GE实测YOLOv13：三图bundle与单图HBM差仅5-6MB，仅传infer_graph省97MB磁盘但HBM不变。纯推理用aclgrphBuildModel即可。
#504	BertBase跨版本迁移CANN9.0编译失败，根因是版本信息库缺Adds算子致选引擎失败	plog显示Can not find engine of op type Adds（1343242282），最终CompileGraph failed ret 1343225857。提问者自答：CANN版本问题，所装版本信息库中没有Adds算子，换含该算子的版本解决。避坑：跨芯片/跨CANN版本迁移先核对目标版本算子支持清单；engine_place.cc的SelectEngine报错是定位入口。
#510	aclDataBuffer声明4字节而OM按INT64需8字节，GE越界读取残留数据当输入	真实ATC->OM->aclmdlExecute路径复现：OM中index为DT_INT64[1]需8B，运行时仅声明4B，GE仍按OM读8B，把length外高4字节device残留当输入，SequenceAt报index out of range；对照组清零污染内存后无异常。官方：属以模型为准的合理现象，设计合理性仍在分析。规避：buffer长度须与OM声明dtype匹配。
#518	CANN9.2头文件链引入废弃ge_error_codes.h，pragma告警大量打屏干扰构建定位	ge_error_codes.h已废弃（2027-06后移除），continuous_vector.h、tiling_context.h等仍间接包含且暂不能改，算子仓编译各包含点都触发含error字样告警。官方：整改有一年兼容期；组件可在target_compile_options加-Wno-deprecated-declarations规避，兼容期内向graph/error_codes.h迁移。

组合解读：这 50 条里的共性规律

单条 issue 是案例，放在一起看就是规律。按「下次遇到先查什么」归纳成七组：

1. 「不是 bug，是硬件契约」——精度/报错先查产品支持表。
#1370（Fixpipe 1:1 直搬 UB 不支持）、#1451（310P3 不在示例支持列表）、#1477（expf 差 1ulp 属硬件指令预期）、#1567（fp64→fp32 subnormal 置零）四条根因都是硬件行为而非代码缺陷。遇到「输出不对/报 aicore error」，第一步查该接口在你所用芯片上的支持表与精度标准，别急着改 kernel。

2. 版本耦合是高频坑。
#1609（新算子仓配旧 devkit 包编译失败）、#169（950PR/arch35 编译链差异）、#504（CANN9.0 版本信息库缺算子）三条都指向同一件事：换板卡、升 CANN、动工具链版本后，先对齐「仓 × 包 × 芯片」三者的版本矩阵再排代码问题。

3. 图融合是精度重灾区。
graph-autofusion 收录的 8 条里 6 条是融合后精度错误（#78、#88、#119、#282 等），叠加 #241（SuperKernel 精度异常）与 asc-devkit 的 LoadData transpose（#1586）。开融合/图优化后精度必做回归；出问题时用关闭融合二分定位是最快路径。

4. 静默错误最危险——输出要加断言。
pypto 的 valid_shape 三连（#3191、#3192、#3195）、scatter_update 非确定性结果（#3194）、ops-sparse 的 static_cast 静默截断（#189）共同点是不报错、结果悄悄错。这类问题的通用防御：kernel 输出与 CPU 参考逐元素比对加容差断言，而不是只看跑没跑通。

5. 同步与并发语义。
#3182（DRCO 控制流缺同步读旧数据）、#431（初始化跨线程 + 设备绑定语义）、#1467（只 EnQue 不 DeQue 整卡挂死）——多线程/多流/队列场景的问题往往不报在出错的位置，按「谁生产、谁消费、谁同步」梳理数据流比看报错栈更有效。

6. 静态分析报告不是走过场。
pypto 一口气修了三处空指针/越界（#3011、#3016、#3021），ops-sparse 补了 host 侧参数校验（#189、#190）。外部输入（文件、dlsym、用户参数）在使用前判空/判范围，是这些修复的共同姿势，值得抄进自己的算子工程。

7. 性能问题先对齐口径。
#490 里官方用实测数据澄清了「CANN 默认保留三图内存导致 3-4 倍膨胀」的流传误解（实测差距仅 5-6MB）；#163 的 A100 对齐争议最终落在「验收口径是哪些 kernel、取什么统计量」；#1389 提醒 CV 融合场景 Matmul 默认 MIX 架构里 scalar 空转占比可达 90%。性能优化前先统一测量口径与架构选型，否则优化的是噪声。

排错指引（从这批 issue 提炼）

症状	第一优先动作	本篇相关案例
aicore error / MTE 越界	查接口在目标芯片的支持表与使用约束；核对同步点	#1370、#3182、#1451
精度 no pass（含 NaN/全零）	关闭融合/图优化二分；单算子 vs 整网分离；查 dtype 支持矩阵	#1560、#1586、#241、autofusion 系列
编译报错（找不到头文件/符号）	对齐仓-包-芯片版本矩阵；查头文件废弃兼容期	#1609、#518、#1357
结果静默错误	输出加逐元素容差断言；检查 valid_shape/索引语义	#3191、#3192、#3194
性能不达预期	明确口径（kernel 范围/统计量）；核对架构选型（MIX vs 纯 Cube）	#163、#1389、#3290
整卡挂死/超时	检查队列 EnQue/DeQue 配对；大 size 填充换 Fill	#1467、#1434

涉及具体 API 语义与硬件约束的核对，用了昇腾知识图谱（ascend.wiki）的官方文档节点；各条解答中 KG 核实过的部分不再单独标注，评论与 PR 均无依据的信息一律未收录。接入昇腾知识图谱 https://gitcode.com/agent0/kg-tools