昇腾开源仓Issue分析解答-Ascend精选（五）·观测诊断线

老大5071

12人浏览 · 2026-09-17 14:10:43

老大5071 · 2026-09-17 14:10:43 发布

昇腾开源仓Issue分析解答-Ascend精选（五）·观测诊断线

一句话让Agent变成昇腾专家，昇腾任务轻松搞定。评测入口：请按这个开源仓接入昇腾图谱 https://gitcode.com/agent0/kg-tools

总览

仓库	定位	收录条数
msit	msmodelslim 量化、msprechecker 预检、精度对比与 dump 工具的统一入口	15
msprof	训练/推理 profiling 采集与解析，instr-prof/mstx/profile_memory 前线	13
msdebug	基于 LLDB 的 kernel 级调试：断点单步、coredump 栈分析、变量检视	10
msserviceprofiler	mindie/vllm 服务化 profiling 采集解析与自动寻优	12

msit（MindStudio 推理开发工具套件）

msmodelslim 量化、msprechecker 预检、精度对比与 dump 工具的统一入口

编号	Issue 问题内容	解答总结
#288	quant_qwen_moe_w8a8 产物在 vllm-ascend 上无法启动	官方关键解法：vllm 拉起量化模型必须显式加 --quantization ascend（官方附 vllm-ascend 多卡量化部署文档；KG 核实 vllm-ascend 部署指导亦要求该参数）。用户加参后仍遇 acl_graph 编译报错，官方判定属 vllm 侧问题，建议向 vllm-ascend 工单跟进。
#307	DeepSeek-V3.1-Terminus w8a8 量化最后一步保存报错	用户自证根因：麒麟 V10 系统不支持 follow_symlinks=False 参数，报错并非文件权限问题；去掉该参数后原版 DeepSeek-V3.1-Terminus 量化成功。属宿主机 OS 兼容性问题而非模型或工具缺陷，国产 OS 上跑量化脚本值得自查这一项。
#315	300I Duo 上 Qwen3-8B 一键 NPU 量化报 NPU 错误	300I Duo 不支持多卡跨卡量化。官方方案：export PYTORCH_NPU_ALLOC_CONF=expandable_segments:True 并用 ASCEND_RT_VISIBLE_DEVICES 指定单卡；维护者进一步建议双芯 0,1 切两芯跑，用户确认量化成功。transformers 固定 4.51.0，并确认权重目录含 config.json。
#331	310P 量化 Qwen2.5-7B w8a8 报 fake_quantize_save 参数错误	官方定位根因为 CANN 包版本过旧、与 msmodelslim 不配套：升级最新 CANN 后 source set_env.sh 重跑（8.2RC1 可用）。衍生知识：日志变量 ATB_LOG_TO_STDOUT/ATB_LOG_LEVEL 于 2025-12-31 弃用，改用 MINDIE_LOG_TO_STDOUT/MINDIE_LOG_LEVEL（KG 已核实收录）。
#339	离线环境装齐依赖后跑 msmodelslim install.sh 仍报缺 python 包	用户自证根因：离线环境缺 wheel 包，install.sh 构建安装时触发 setuptools 相关报错。解法：离线包清单额外补上 wheel（对比安装前后 pip list 差集），或按官方建议改用 pip install --no-deps 跳过依赖解析。官方另给排查三步：pip show setuptools 查来源、which python、echo $PYTHONPATH。
#351	msserviceprofiler 配 ACL_PROF_TASK_TIME 后 vllm 采集报错	根因：用 ASCEND_RT_VISIBLE_DEVICES 指定非 0 号卡时采集工具未适配，默认只采 0 卡导致 ProfCreateConfig 报错。官方解法：起容器时通过 --device 直接指定 NPU 而非环境变量；用户确认解决。环境：CANN 8.3RC1 + vllm-ascend 0.11.0rc1 + msserviceprofiler 1.2.2。
#353	910B3 64GB 上 DeepSeek-V3.2 fp8 转 w8a8 一键量化爆显存	DeepSeek-V3.2-Exp 一键量化 OOM。官方修复路径：先切 br_release_MindStudio_8.3.0_20261231 分支版本，随后 master 也已修复（PR#4756：修复 dpskv32 w8a8 最佳实践 yaml 及 iter smooth bug）。用户 2025-12-05 验证通过。
#361	310P NPU 方式量化 Qwen2.5-VL-7B 报错	官方口径：MindIE 310P 不支持部署量化权重，多模态模型更不在支持列表，需使用 800I A2 服务器量化并部署；模型支持情况以 MindIE 官方模型支持列表为准，列表未写即不支持。用户补测：310P3 跑大语言模型量化可行，多模态量化不行。
#375	Qwen3-8B-Reranker w8a8 量化后 vllm 加载报错，非量化版正常	官方咨询 vllm-ascend 团队后确认：vllm-ascend 尚未适配 Qwen3-Reranker-8B 量化权重的加载，非量化版可正常运行、量化版加 --quantization ascend 即失败，属上游适配缺口而非量化产物问题；建议向 vllm-ascend 仓提 issue 推动适配。
#379	安装后导入 llm_ptq 报 ModuleNotFoundError、torch_npu 导入失败	官方定位 python3.13 不被支持：换 3.10/3.11，或改用 V1 一键量化框架（msmodelslim quant 命令，参考 PR#4814 的 Qwen3-32B W8A8 yaml）。前置：CANN 大于 8.2RC1，先 source set_env.sh，且须在 msmodelslim 目录下执行 bash install.sh。
#393	精度对比开 --locat=True 后未生成 error_interval_info.txt	msit 8.2.0 精度工具开启定位开关后对比产物缺失，定位为累计误差执行过程缺陷；修复 PR#4976（修复累计误差执行过程中报错的问题）已于 2026-02-27 合入 master，升级 master 分支即可获得该修复。
#394	请求预检 HCCL_RDMA_PCIE_DIRECT_POST_NOSTRICT 的分页风险	提单者指出：openEuler/Ubuntu 默认 4KB 分页时该变量不生效；64KB 分页裸金属上 MindIE 配置它可能 OOM，不配又影响 HD 通信，可用 getconf PAGESIZE 检测。PR#4988 已为 msprechecker 新增该校验提示。KG 核实 HCCL 官方文档收录此变量、MindIE-LLM 部署脚本内置该配置；分页 OOM 细节以 CANN 文档为准。
#400	msprechecker 校验 rank_table 不支持 IPv6 地址格式	Atlas 800T A2 各平面需 IPv6 部署，rank_table 配 IPv6 IP 时 msprechecker 报错。PR#4989 简化 rank table 解析并为 HCCL 通信新增 IPv6 支持（2026-03-10 合入）；vllm 场景同类报错由 PR#4990 修复（同根因 issue #401），用户使用新版 rank_table 模板验证预检通过。
#406	vllm+vllm-ascend 下 msit llm dump 执行无报错但无数据	官方确认：msit dump 只支持 ATB 路径，vllm 框架不适用；且 msit 该能力已停止演进，功能迁移至 msprobe 工具，vllm 推理精度比对请参考 msprobe 的 vllm 功能介绍。KG 核实：MindSpeed-LLM 精度问题文档与 MindStudio 26.0.0 文档均以 msprobe 为当前精度调试工具。
#407	msprechecker 预检工具不适配最新开源 MindIE 框架	开源 MindIE（mindie_motor）路径与旧版不同导致预检不适配。PR#5011 重构 collector 并适配 MindIE/CANN 新版本路径改动（2026-03-27 合入）；官方同时给出 pd_disaggregation 单容器场景示例命令，可直接对 k8s 部署脚本中的 mindie_service 配置做预检。

msprof（MindStudio 性能采集解析）

训练/推理 profiling 采集与解析，instr-prof/mstx/profile_memory 前线

编号	Issue 问题内容	解答总结
#19	缺最小可运行采集+解析示例，新手上手成本高	官方采纳建议：快速入门文档新增端到端样例，提供极简脚本、完整运行命令与预期输出，新手无需搭建复杂训练/推理工程即可体验完整性能采集+解析流程，2026-03-25确认已解决。
#37	ACLGraph场景kernel_details.csv算子名与aclnn接口名对不上	官方澄清命名机制：CSV中拿到的是kernelName（算子侧按类型+tiling key编译出的唯一名）；aclnn接口名对应opName（aclnn接口名+kernelName前半部分），profiling数据优先显示opName、次选kernelName。CANN8.5.0配套torch_npu 8.5.0已具备ACLGraph场景取算子shape的能力，建议版本配套使用。
#39	Qwen3-32B decode阶段Triton自定义算子shape采集为N/A	官方答复：kernel_details.csv中的shape信息依赖框架/算子侧上报。split_qkv_rmsnorm_rope_kernel_0等为用户自定义算子，其shape上报逻辑需用户自行处理，profiling工具侧不会代为推导补全。
#40	msprof报Running profiling failed，实际是任务跑在了CPU	官方定位：日志running_mode.cpp:153 File size is invalid（profiling_output_record size:-1）通常意味着msprof未在业务中感知到真实NPU进程——脚本初始化的模型未把任务下发到NPU。提问者为模型补上torch_npu下发逻辑后即可抓到timeline并复验通过。
#48	msserviceprofiler解析输出缺chrome_tracing.json	场景归属澄清：用户以pip装msserviceprofiler对vllm-ascend服务做采集解析，chrome_tracing.json输出件属msserviceprofiler组件，官方指引到Ascend/msserviceprofiler仓提单，不在msprof仓受理范围。服务化采集问题先分清组件归属。
#54	950上msprof -op单算子采集不到UB->GM内存搬运数据	官方归属澄清：msprof -op（msprof op单算子工具）相关问题应到Ascend/msopprof仓提单跟进，msprof仓只受理整网采集解析。同算子用msprof整网采集可见UB->GM数据，多人复现的单算子侧缺失需在msopprof继续排查（与博客7 ops-test-kit#149单算子耗时边界同类工具边界）。
#56	experimental_config开L2_CACHE=True却采不到L2 Cache数据	官方澄清开关适用面：experimental_config里的l2_cache开关仅用于910A及310P芯片，交付件为L2Cache.csv；A2/A3等后续演进芯片应改用aic_metrics中的L2Cache指标，数据呈现在kernel_details.csv/op_summary.csv中。开关无效先对照芯片型号。
#60	vllm离线推理混合流算子shape、dtype未采集到	官方对齐结论分两层：该次动态profiling没有采到capture_op_info数据，故无shape属符合预期，可能与CANN包和torch_npu包版本配套有关；后续另一份数据含capture_op_info但依然解析不出，经确认是偶现的数据结构内容异常导致解析报错。shape依赖capture_op_info数据在位。
#73	开启profile_memory有原始文件但未生成npu_module_mem.csv	根因：prof采集host侧数据时时间戳取syscnt还是monotonic取决于是否从驱动获取host freq；module_mem采集配置（res1字段）必须与时钟口径匹配，否则底软上报数据无法对齐。修复：调用PlatformHostFreqIsEnable，为true则配1通知上报syscnt，否则配0上报monotonic。
#82	ACLGraph多卡allreduce采集，timeline无通信大算子	定位为HCCL侧问题而非msprof解析问题：hccl仓已提修复PR（fix aclgraph aiv profiling bug）并合入，随B080 CANN包版本验证通过后关闭。遇ACLGraph场景通信算子缺失可先核对HCCL/CANN版本。
#95	mstx通信打点msg超156字节报错不支持落盘	根因：mstx接口单条msg上限156字节，超长即报错拒收。修复分两端：采集侧超长时自动拆分多条落盘（cann/runtime PR#3321）；解析侧将mark_id相同的多条数据按seg_idx顺序拼接还原完整msg后写入导出的tx数据（msprof PR#345）。
#112	开启mstx有概率丢数据，报Failed to save data for range end	根因：mstx_data_handler线程类start阶段先开线程再置start_=true，Run消费循环可能在start_尚未置true时判定非运行态直接退出；此后打点数据持续push进无人消费的buffer，写满后报错拒收。修复：调整为先置start_=true再启动线程，复验10次未再丢数据。
#130	A3上instr-profiling采集MTE workload，biu_group四项指标恒为0	官方联合底层硬软件在多个A2/A3环境复测的终版结论：A3环境采不到任何有效数据，A2仅device 0有数据；根因是底层软件侧功能设置差异，硬件侧确认现有数据不具备分析价值，且修复投入产出比低，暂不修复。使用instr-profiling的biu指标前建议先确认环境有效性。

msdebug（MindStudio 算子调试器）

基于 LLDB 的 kernel 级调试：断点单步、coredump 栈分析、变量检视

编号	Issue 问题内容	解答总结
#7	文档未介绍LAUNCH_KERNEL_PATH如何找到实际加载的kernel侧.o文件	背景：一个大算子可编译出多个.o，开发者难知算子程序实际加载哪个。官方已在昇腾文档中心8.5版资料补充该介绍（atlasopdev_16_0146章节）；同时说明主线版本已无需手动配置LAUNCH_KERNEL_PATH导入调试信息，故仅更新历史版本资料。旧版本用户找.o可参考该文档。
#23	msdebug运行报错缺libform.so.5共享库	官方：构建环境问题——此前构建的liblldb.so产物不依赖libform.so.5，环境差异导致部分机器运行时缺该库；为鲁棒性将libform.so作为交付件随包发布，已修复。运行期缺ncurses系库（libform/libtinfo）时优先换用官方交付包而非手工补系统库。
#87	950上aclnn+cube场景coredump展示异常、调用栈不准、线程切换错	PR#161披露双根因：①多个error寄存器同时有值时代码逻辑未更新PC，导致栈不准——改为所有芯片类型统一取第一个error寄存器值修正PC；②thread info未处理好最后一个warp尾部thread的mask。06-15验证通过。core文件由ASCEND_DUMP_SCENE=aic_err_detail_dump触发生成，msdebug --core加载解析（KG用户指南核实）。
#90	构建msdebug要求cmake 3.20.2~3.31.10封顶，高版本cmake编译失败	官方整改PR#186/#182去除版本上限。根因：低版本cmake下的warning在高版本升级为error导致编译报错；修复这些告警后放开封顶，仅保留>=3.20.2下限，高版本cmake可正常构建。自构建msdebug遇cmake版本墙可升级到含此修复的版本。
#96	GM内存读取时var指令回显大段乱码字符串	官方：开源LLDB本身会把uint8_t按char来展示结果，因此__gm__ uint8_t*变量var打印出大量乱码样字符串；属LLDB类型展示行为而非内存读数错误，工具侧可选强行不展示。遇到此类乱码先确认是指针按字符串渲染，数值本身未损坏。
#99	950上pytorch场景调用算子，断点打不住	PR#181给出完整机制：断点同时匹配host与device侧（如动态库与kernel同名）时，原逻辑会取消host断点，但host侧运行后几乎不停、取消失败，而调试器管理的断点信息已删，host断点命中时被误判为SIGTRAP类型中断，算子断不到device侧。修复：算子运行后不再取消host断点，两侧断点并存。断点打不住时可检查是否host/device同名冲突。
#112	POD环境核切换后单步n卡住不动	官方定位为底层驱动问题（非工具逻辑bug），0726驱动侧已合入修复，08-11验证通过。用户侧启示：单步调试在核切换（ascend info core后切回）卡死时，先升级到含0726修复的驱动/CANN版本再排查msdebug本身；同类#100 simd+simt断点卡崩亦为调试驱动（ts侧）问题由驱动包修复。
#113	POD环境allgather算子单步调试，按n一次连跳多行	官方先判底层驱动问题修复中，08-04更正定性：是编译器优化所致，跳过的是变量定义代码行，属可接受优化而非工具bug；用户08-11验证通过。配合KG官方quickstart：上板调试须在kernel侧CMakeLists加-g -O0重编，若仍跳行多为优化语义（如变量定义行无实际指令），勿先怀疑调试器。
#114	shmem的simt_rma_ub2gm算子被msdebug拉起即报错，脱离工具单独运行正常	官方确认是工具缺陷：调试器劫持halMemAdvise做内存属性管理时处理不当，PR#220（0729合入）/PR#242（0825 sync合入）修复，08-06复测通过。同单另两现象非工具问题：udma_demo打不住断点实为断点设在host侧代码且算子根本不会运行到该处；moe_init_routing_story卡死系环境驱动过老。启示：拉起报错先分清工具缺陷与用法/环境问题。
#115	shmem combine_classic的coredump场景调用栈展示异常	官方定位：测试用例以while(1){}构造异常场景，编译器确认该写法导致kernel未定义行为（UB）；生成代码段仅0xc0大小（PC范围0x…d000-0x…d0c0），实际PC已跑到代码段外（0x…d11c），无法通过PC还原代码堆栈。属被测代码UB而非解析缺陷——coredump栈乱先审被测kernel是否含UB写法，调试器无法为跑飞PC还原栈。

msserviceprofiler（MindStudio 服务化调优）

mindie/vllm 服务化 profiling 采集解析与自动寻优

编号	Issue 问题内容	解答总结
#11	vllm解析报TypeError Invalid value[list]，pandas 3.x不兼容	官方复现定位：pandas>3.x版本引发，降级2.x后消除；已修改软件依赖为pandas>=2.2,❤️.0（不排除后续按numpy配套再调）。与快速入门声明的pandas>=2.2一致。用户侧临时解法：pip装回2.x。
#12	文档kvcache.csv/batch.csv字段与mindie、vllm实际交付不一致	实测差异：kvcache.csv的domain字段mindie场景实际没有、rid字段vllm场景实际没有；batch.csv的dp_rank采集值为空、blocks_freed仅部分场景有。文档已按场景修正。启示：跨框架对照交付件先确认该场景字段集，勿按单一文档模板硬套字段含义。
#16	寻优遇服务崩溃/NPU OOM仅能30分钟超时等待，无主动感知	机制：插件化后统一流程仅靠推理端口health判断服务拉起，已崩溃进程无法及时识别，爆显存等场景白等N*30分钟。改进：各插件增加进程状态判断并留自定义扩展接口，监控框架运行OOM显存日志及时终止省时（先试PR#183未合，最终随PR#285功能反合2026-04-09合入）。#15（OOM跳过轮次）同因同修复。
#25	寻优vllm场景写死127.0.0.1，单栈ipv6环境执行失败	根因：ms_serviceparam_optimizer/optimizer/plugins/simulate.py硬编码127.0.0.1，环境仅启用ipv6时访问失败，寻优命令中断。规避：配置文件中将vllm的ip显式设为本机ipv4或ipv6地址均可拉起成功（用户已双验证）；官方后续版本补本机ipv6默认支持。
#30	解析交付件缺request.csv（主线必现，high优先级）	根因：此前合入的PR#173『增强detokenize事件处理』微重构引入bug，同时拖慢解析性能；官方回退该特性并补边际情况监测，PR#205修复request.csv导出，回归通过。启示：解析交付件突然缺失时，优先排查最近合入的解析模块重构改动。
#35	request.csv两行记录字段错位，token数/时延等列出现空值	根因：vllm 0.14.0起请求入队后http_rid新增hash后缀（如chatcmpl-xxx-9906dbe1），旧解析按rid关联失败，字段错位或为空。PR#233适配后修复回归通过；同PR亦解决#55交付件forward.csv缺失（A5）。启示：升级vllm后解析异常，先核对工具版本配套关系。
#37	mindie用ais_bench压测后request.csv的reply_token_size为空	官方定位：采集token步数设置过低，首个推理结果尚未返回采集即关闭，落盘数据无回复记录；步数调至5000后字段正常（reply_token_size即请求输出长度），资料补充说明中。压测采集时步数需按输出长度留足余量。
#39	配置acl_task_time后无算子执行时间，且日志无报错	根因：磁盘空间不足，算子原始数据（PROF开头目录）无法落盘，采集过程不报错，表象即『配置了却没算子数据』。文档亦提示算子采集数据量大，推荐集中采集3~5s防占用磁盘。排查顺序：先df -h查磁盘余量，再确认prof_dir下PROF原始文件是否存在。
#42	改开关并发请求后无任何采集日志回显，工具似未启用	两类根因：①mindie版本过低，该版本未集成msServiceProfiler，须升级MindIE；②vllm场景SERVICE_PROF_CONFIG_PATH等环境变量写错——文档明确变量须在服务进程启动前设置且不能拼错，否则采集不使能。判断标志：服务启动初期应打印[msservice_profiler]开头的日志。
#58	mindie镜像采集后解析报错：开关切换间无推理请求，空数据	根因：用户改enable=1见落盘后又改0，期间未发推理请求，数据缺请求记录致解析异常。新版对无请求数据给出明确报错ValueError: Profiling data is invalid；确认有推理请求时解析正常。要点：enable=1期间须实际发请求；enable由0改1时配置整体重载。
#62	first_token_latency仅54ms偏小，统计口径疑似有误	用户深析：该请求缺有效sendResponse事件记录，TTFT被锚定到BatchSchedule的end_time，54ms只反映『请求到达→入队被调度』等待，真TTFT约1149ms（排队54+执行1095）。官方建议用MindStudio Insight导入解析出的chrome_tracing.json按时间线核实TTFT。指标读数异常先查事件链完整性。
#82	解析后output目录无chrome_tracing.json，与文档交付件不符	官方两步：①拉起vllm前export SERVICE_PROF_CONFIG_PATH与PROFILING_SYMBOLS_PATH，拼错或启动后才设置都使能失败；②容器内工具非最新，按build_and_upgrade.sh源码重装后再采解析。chrome_tracing.json为Insight导入的trace交付件；与博客11 msprof#48同症状不同链路，互参。

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

1. 量化工具链的第一因还是配套：CANN/python/OS 三层各有一坑。
CANN 过旧与 msmodelslim 不配套报 fake_quantize 参数错，升级后 source set_env.sh 重跑；日志变量 ATB_LOG_TO_STDOUT 已弃用改 MINDIE_LOG_TO_STDOUT（msit#331）；python3.13 不支持，换 3.10/3.11 或改用 V1 一键量化框架（msit#379）；离线环境缺 wheel 包致 install.sh 构建报错，补 wheel 或 pip install --no-deps（msit#339）；麒麟 V10 不支持 follow_symlinks=False，DeepSeek-V3.1 量化保存报错去掉该参数即过（msit#307）；DeepSeek-V3.2 爆显存先切 8.3.0 分支再取 master 修复 PR#4756（msit#353）。部署侧：vllm 拉起量化模型必须显式 --quantization ascend（msit#288）；Reranker 量化权重加载失败是 vllm-ascend 上游适配缺口非产物问题（msit#375）。硬件边界：300I Duo 不支持跨卡量化，单卡+expandable_segments 或双芯各跑（msit#315）；310P 不支持多模态量化部署，以 MindIE 模型支持列表为准（msit#361）。

2. msprechecker 预检四连修：分页/IPv6/新框架路径全覆盖。
HCCL_RDMA_PCIE_DIRECT_POST_NOSTRI CT 在 4KB 分页不生效、64KB 裸金属配错可能 OOM，getconf PAGESIZE 先测，PR#4988 已把该校验加进预检（msit#394）；rank_table IPv6 地址报错由 PR#4989/4990 修复（vllm 场景同根因 #401 一并覆盖）（msit#400）；开源 MindIE（mindie_motor）路径变化致预检不适配，PR#5011 重构 collector 并给出 pd_disaggregation 预检示例（msit#407）；精度工具 --locat=True 缺 error_interval 产物是累计误差执行缺陷，PR#4976 已合入（msit#393）。

3. 采集侧机制答疑：先问「数据有没有」，再问「口径对不对」。
Running profiling failed 常见真相是任务根本没下发到 NPU——running_mode.cpp 的 File size is invalid 即无真实 NPU 进程，补 torch_npu 下发逻辑即可（prof#40）；kernel_details.csv 的名字是 kernelName（类型+tiling key 唯一名），aclnn 接口名对应 opName，CANN8.5 配套 torch_npu 8.5 已支持 ACLGraph 取 shape（prof#37）；自定义 Triton 算子 shape 为 N/A 是上报逻辑归用户自理（prof#39），vllm 混合流无 shape 则依赖 capture_op_info 数据在位（prof#60）；experimental_config 的 l2_cache 开关仅 910A/310P 适用，A2/A3 改看 aic_metrics 的 L2Cache（prof#56）；A3 instr-profiling 的 biu 指标官方终版结论：现有数据不具备分析价值、修复投入产出比低，暂不修复——用前先确认环境有效性（prof#130）。

4. 跨仓修复链：工具仓的 bug 常修在别处。
npu_module_mem.csv 缺失根因是 host 侧时钟口径（syscnt/monotonic 取决于驱动 host freq），修复落在 cann/runtime PR#2872/2874（prof#73）；mstx 概率丢数据是 handler 线程先启动后置 start_ 的竞态，PR#3932 改为先置位再启线程（prof#112）；mstx 单条 msg 上限 156 字节，采集侧自动拆分（runtime PR#3321）+ 解析侧按 mark_id/seg_idx 拼接（msprof PR#345）双端修（prof#95）；ACLGraph 多卡 allreduce 无通信大算子是 HCCL 侧 aclgraph aiv bug，hcomm PR#2738 修复（prof#82）；msdebug 核切换卡死同理是底层驱动问题，0726 驱动已修（dbg#112）——排工具 bug 前先看驱动/CANN/通信库版本。

5. 组件归属路由：提对仓，问题才有人接。
msprof -op 单算子问题归 msopprof 仓，msprof 只受理整网采集（prof#54）；chrome_tracing.json 服务化输出归 msserviceprofiler（prof#48）；msit llm dump 只支持 ATB 路径且已停止演进，vllm 精度比对迁移至 msprobe（msit#406）；采集工具默认只采 0 卡，指定非 0 卡要用容器 --device 而非 ASCEND_RT_VISIBLE_DEVICES（msit#351）；快速入门现已补端到端极简样例，新手可零工程体验采集+解析（prof#19）。

6. msdebug 调试器三课：断点、栈、显示各有陷阱。
断点打不住——host/device 同名断点冲突时原逻辑取消 host 断点失败、命中被误判 SIGTRAP，PR#181 改两侧断点并存（dbg#99）；工具劫持 halMemAdvise 不当致 shmem 算子拉起即报错，PR#220/242 修复（dbg#114）。栈不可信——多 error 寄存器未取第一个修正 PC+末 warp 尾部 mask 缺陷，PR#161 修复（dbg#87）；被测 kernel 含 while(1){} 等 UB 写法时 PC 跑出代码段，调试器无法还原栈，先审被测代码（dbg#115）。显示疑云——单步连跳多行多为编译器优化跳过变量定义行，上板调试先 -g -O0 重编（dbg#113）；GM 变量乱码是 LLDB 把 uint8_t* 按 char* 渲染，数值未损坏（dbg#96）。工程侧：libform.so 已纳入交付件（dbg#23）；LAUNCH_KERNEL_PATH 找 .o 有专章文档、主线已免手动配置（dbg#7）；cmake 3.31.10 封顶已随 PR#186 解除（dbg#90）。

7. 服务化采集的「静默失败」家族：九个症状、一类本质——使能链路没走通。
先看启动日志有无 [msservice_profiler] 前缀：没有则 mindie 版本未集成或 SERVICE_PROF_CONFIG_PATH 拼错/未在启动前设置（mssp#42）；配置 acl_task_time 无数据且无报错，先 df -h——磁盘满会静默丢 PROF 原始文件（mssp#39）；enable=1 期间必须实际发请求，空数据新版明确报 ValueError（mssp#58）；reply_token_size 为空是采集步数过低，调至 5000（mssp#37）；chrome_tracing.json 缺失走两步法：环境变量前置+容器内源码重装（mssp#82）。解析侧：pandas 3.x 不兼容依赖已锁 >=2.2,❤️.0（mssp#11）；vllm 0.14.0 rid 加 hash 后缀致字段错位，PR#233 适配（mssp#35）；request.csv 缺失是 PR#173 重构引入回归，PR#205 回退修复——交付件突变先查最近合入的重构（mssp#30）；kvcache/batch.csv 字段集随 mindie/vllm 场景不同，勿按单一模板硬套（mssp#12）；TTFT 仅 54ms 是缺 sendResponse 事件被锚定到 BatchSchedule end_time，用 Insight 导入 trace 按时间线核实（mssp#62）。寻优侧：服务崩溃只等 30 分钟超时已改进程状态感知，PR#285（mssp#16）；simulate.py 写死 127.0.0.1 在单栈 ipv6 失败，配置文件显式指定本机 ip（mssp#25）。

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

症状	第一优先动作	本篇相关案例
量化报参数/导入错误	核三层配套：CANN 版本、python 3.10/3.11、OS 特性；source set_env.sh	msit#331、#379、#339、#307
量化产物部署失败	vllm 加 --quantization ascend；核上游适配列表	msit#288、#375、#361
profiling failed / 无数据	确认任务真下发 NPU；看磁盘余量与 PROF 原始文件	prof#40、mssp#39
指标/字段口径存疑	分清 opName/kernelName、整卡/vNPU、场景字段集	prof#37、#56、mssp#12
工具 bug 疑似	先核驱动/CANN/hcomm 版本，跨仓修复链常见	prof#73、#82、dbg#112
断点打不住/栈乱	查 host/device 同名冲突；审被测 kernel UB；-g -O0 重编	dbg#99、#115、#113
服务化采集静默失败	启动日志 [msservice_profiler] 标志；环境变量前置；enable 期间发请求	mssp#42、#58、#82
解析交付件突变	查最近合入的重构 PR；核 vllm/pandas 版本配套	mssp#30、#35、#11

涉及具体 API 语义与硬件约束的核对，用了昇腾知识图谱（ascend.wiki）的官方文档节点；各条解答中 KG 核实过的部分不再单独标注，评论与 PR 均无依据的信息一律未收录。51 条高质量候选按每篇 ≤50 硬约束保留 50，另 1 条（msprof#81 SIMT timeline 仅排期信息、无落地修复）未收录。接入昇腾知识图谱 https://gitcode.com/agent0/kg-tools

系列下一篇：Ascend 精选（六）—— RecSDK / msagent / DrivingSDK / MindIE-SD 等应用与推理 SDK 线，或 mindspore 组织新篇，欢迎留言点仓。