昇腾FAQ-A06-行业应用MindX相关
昇腾高频问答FAQ-A06-行业应用MindX相关-2507
备注:我们让大模型读了昇腾全年工单,整理了1000条经验包,贴出来供大家参考、少走弯路,但仍可能会有轻微幻觉,或由于产品版本更新、时效性等原因已不完全适用,建议按需搜索+交叉验证,有疑问之处欢迎来查询案例库或提单,咱们边唠嗑边修BUG。转载随意,如反馈修订请移步原文。
FAQ(001):如何解决Ascend-dmi P2P测试失败?
安装好驱动固件后进行P2P带宽测试时报错 [p2p_calculator.cpp GetElapsedTime:238] Invalid param time.
,错误代码为 ret = 2
。
原因分析:
可能是CANN版本与Toolbox之间存在兼容性问题。
解决办法
请检查并确保使用的 CANN 包的发布时间早于或等于 Toolbox 的版本。如果仍然存在问题,请尝试升级您的驱动和固件到最新匹配的版本。
FAQ(002):如何正确配置Atlas 800T A2服务器上的NPU标签?
用户在使用 Atlas 800T A2 上进行 NPU 资源分配时,发现指定 device 的方式未能生效。
原因分分析:
Atlas 800T A2设备上可能未正确配置 accelerator-type
标签导致调度器无法识别可用NPU资源。
解决办法:
-
确保节点标签描述准确:
accelerator-type=module-910xxxx
-
通过命令行
kubectl describe pg -n vcjob
查看 podGroup 的详细信息以确认配置是否正确。
FAQ(003):MindIE Server使用中出现请求超时且无返回。
原因分析:发送请求的速率超过了服务所能处理的速度,导致任务积压和响应延迟。
解决办法
- 如果您是通过 MindIE Benchmark 发起请求,请适当减少并发数(–Concurrency 参数)以匹配服务器的实际负载能力;
- 若使用脚本调用MindIE Server,则可考虑增加超时时间限制。
FAQ(004):在Atlas设备上运行多个视频流解码任务时报错,数据出现混乱。
原因分析
多线程/进程处理中可能存在资源竞争或配置不当导致的错误操作。
解决办法
请参考官方文档中的示例项目进行调整和优化。可访问此链接获取帮助:https://gitee.com/ascend/mindsdk-referenceapps/blob/master/VisionSDK/PutTextForMultiVideos/README.md
FAQ(005):在使用 PyTorch 框架训练模型时,环境变量指定的 NPU 设备 ID 不生效。
原因分析
NPU设备资源分配依赖于容器调度器(如Kubernetes)和相关插件配置。若未正确设置或插件不兼容,则可能无法实现预期效果。
FAQ(006):使用 Ascend Deployer 安装时遇到编码错误 UnicodeDecodeError
。
原因分析
操作系统默认字符集与Ascend Deployer使用的 UTF-8 不匹配,导致读取子进程输出失败。
FAQ(007):在Ubuntu系统中使用pip3安装Ascend Deployer时提示找不到6.0.RC3版本。
原因分析
该版本尚未正式发布到pypi默认源或清华镜像站上。
FAQ(008) :如何确保NPU资源分配符合预期?
在Kubernetes中,通过环境变量指定的device id未能正确反映实际使用的NPU卡。
解决办法:
- 确保使用正确的标签和调度策略;
- 参考相关文档或联系技术支持以获取更详细的指导。
FAQ(009) :在Kubernetes中,Pod频繁重启。
用户按照示例配置后 Pod 频繁重启。
原因分析
容器中的任务执行完毕导致容器退出,需要使用 sleep 或其他方式保持运行状态以供观察和调试。
FAQ(010) :安装Ascend-mindxdl-faultdiag时提示找不到依赖包ply>=3.11。
解决办法:
确保Python的环境支持该版本。如果仍然无法解决,可以使用 Ascend Deployer 安装故障诊断组件以绕过此限制。
FAQ(011) :Ascend-docker-runtime安装失败或找不到相关文档?
原因分析
用户可能需要查阅官方提供的指南来获取ascend docker runtime的下载和部署信息。
解决办法:
- 手动安装请参考: https://www.hiascend.com/document/detail/zh/mindx-dl/600/clusterscheduling/clusterschedulingsd/clusterscheduledsd/mxdlug_017.html
- 使用工具安装,请查看:https://www.hiascend.com/document/detail/zh/mindx-dl/600/clusterscheduling/clusterschedulingig/clusterschedulingig/dlug_installation_017.html
FAQ(012):如何确保MindCluster版本与驱动兼容?
用户在尝试将 MindCluster v6.0 配合 NPU 驱动24.x使用时报错,提示固件和驱动的兼容性问题。
解决办法
请参照华为提供的兼容性文档选择合适的组件组合。
FAQ(013):Atlas设备上的NPU资源监控失败。
原因分析:
当时版本的 npu-exporter 不支持该型号设备的 vnpu 资源监控。
解决办法
联系华为技术团队提交需求,以获得对vnpu监控的支持。
FAQ(014):使用Ascend Deployer下载软件时遇到编码错误。
原因分析:
可能是由于Python处理子进程输出的字符集与实际不一致导致。
解决办法
尝试跳过 download_util.check_base()
方法前进行网络环境检查。
FAQ(015):Ascend-dmi命令执行失败,提示“FLOP test timeout”。
原因分析:
使用的固件版本7.7与驱动25.0.rc1可能存在不兼容。
解决办法
尝试升级MCU(微控制器单元)并更新CANN包至8.1.RC1以上。
FAQ(016):如何解决Minikube环境中通过npu-smi info
无法检测到昇腾NPU设备?
原因分析
在Kubernetes(k8s)场景下部署Ascend Docker运行时和Device Plugin后,若未正确配置容器内的库路径环境变量,可能导致工具无法识别NPU硬件。
解决办法:
-
在任务容器中执行以下命令设置
LD_LIBRARY_PATH
export LD_LIBRARY_PATH=/usr/local/Ascend/driver/lib64:/usr/local/Ascend/driver/lib64/common:/usr/local/Ascend/driver/lib64/driver
-
之后运行
npu-smi info
检查NPU状态。 -
若仍有问题,请提供详细报错信息以便进一步排查。
FAQ(017):如何解决部署MindCluster时出现的UnexpectedAdmissionError错误?
原因分析
Node节点磁盘空间已满,导致Kubernetes无法正常创建Pod。该现象通常发生在同一主机上有大量异常状态POD堆积的情况下。
解决办法:
-
登录对应node节点清理文件系统中的冗余日志或数据;
-
使用命令批量删除故障pod:
kubectl get pods -A | grep 'UnexpectedAdmissionError' | awk '{print("kubectl delete pod",$2,"-n",$3)}'
FAQ(018):如何配置vNPU动态资源调度以支持更多并发容器?
原因分析
当前使用的vnpu切片方式限制了单个容器的内存上限,导致无法满足多任务并行需求。
解决办法:
- 使用MindCluster提供的
device-plugin-310P-volcano-v6.0.rc2
版本; - 根据文档配置动态算力分配策略(参考链接:https://www.hiascend.com/document/detail/zh/mindx-dl…)。
FAQ(019):如何解决NPU容器化部署时出现的权限问题?
原因分析
挂载昇腾设备到Docker或K8s Pod中,由于用户ID和组ID不匹配导致访问失败。
解决办法:
-
修改物理机上HwHiAiUser用户的UID/GID为
1000:1000
-
或在Pod YAML配置文件的容器描述部分添加:
securityContext:runAsUser: 1000fsGroup: 1000
-
杀掉所有非法挂载NPU设备的Docker进程。
FAQ(020):如何优化Volcano调度器配置以避免部署卡顿?
原因分析:
旧版volcanoc配置文件未启用clusterd组件或参数设置不匹配。
解决办法:
- 安装
clusterd
服务; - 或在configmap中将useClusterInfoManager设为false。
FAQ(021):如何确认Ascend Device Plugin与NPU驱动版本是否兼容?
原因分析
Device-plugin版本和实际使用的昇腾硬件/软件环境不匹配,导致无法获取设备信息。
解决办法:
- 确保device-plugin、docker运行时及driver组件的版本一致;
- 检查
ascend-k8sdeviceplugin-310P-aarch64.tar
是否与NPU硬件型号匹配。
FAQ(022):如何配置Kubernetes以确保POD删除时及时释放NPU资源?
原因分析
当fault-scheduling设置为force模式下,terminationGracePeriodSeconds参数可能不生效。
解决办法:
- 参照官方文档建议将
grace-over-time
设得比terminationGracePeriodSeconds大; - 在volcano调度器配置文件中检查并调整相关字段。
FAQ(023):如何区分Pod级与进程级别重调度机制?
原因分析
用户对两种级别的故障恢复策略理解不清,导致部署失败。
解决办法:
- Pod级重调度是将整个POD迁移;
- 进程级仅重启受影响的容器进程(不删除Pod)。
FAQ(024):如何正确挂载ConfigMap到指定路径?
原因分析
在创建任务时未正确配置reset-config
Configmap,导致恢复机制失败。
解决办法:
确保YAML文件中包含如下字段,并将该ConfigMap挂载至容器的/user/restore/reset/config
目录下:
volumes:- name: reset-configconfigMap:name: your-reset-config-namecontainers:volumeMounts:...
FAQ(025):如何排查npu-smi在容器内无法识别设备的问题?
原因分析
镜像与昇腾硬件型号不匹配,或挂载方式错误。
解决办法:
参考官方文档,选用与NPU型号对应的镜像版本,并确保正确挂载虚拟NPU ID为100
。
FAQ(026):如何解决Ubuntu系统下用户权限导致的任务失败?
原因分析
HwHiAiUser的UID/GID与默认值不一致,影响任务提交。
解决办法:
- 修改该用户的uid和gid为
1000:1000
- 或者在容器中使用root权限运行。
FAQ(027):如何配置Kubernetes以支持NPU资源调度?
原因分析
未正确安装Ascend Docker Runtime或Device Plugin。
解决办法:
- 安装
ascend-docker-runtime_5.0.RC2.2_linux-aarch64.run
- 部署device-plugin-310x.x.x组件
FAQ(028):如何处理ResNet模型在多卡训练时的yaml配置问题?
原因分析
示例YAML文件未适配新版本特性。
解决办法:
参考v6.0.RC1文档中的resnet50 YAML模板,调整为支持集群模式。
FAQ(029):如何避免Kubernetes Pod状态异常导致的NPU资源不释放?
原因分析
Pod处于CrashLoopBackOff状态时未能自动清理残留进程。
解决办法:
- 检查容器运行环境下的cgroup设置是否与Docker一致;
- 确保使用
ascend-pytorch:24.x.RCx-A3-xx.xx...
镜像版本。
FAQ(030):如何在Kubernetes中跨节点调度NPU资源?
当使用三个NPU设备的服务器时,希望一个Pod能同时访问所有设备的48个核心。
原因分析
Kubernetes Pod机制限制了其只能绑定到单一物理节点上的计算单元。即使集群中有多个可用的Ascend NPU卡资源,在没有特殊调度策略的情况下也无法实现跨机架资源共享或负载均衡分配给不同Pod使用同一硬件的不同部分(如整卡切分)。
解决办法
- 调整标签匹配规则:将
ring-controller.atlas: ascend-910xxx
作为节点选择器参数。 - 启用多实例部署模式:
- 创建多个副本时需设置合适的亲和性策略;
- 通过Volume共享机制保证各Pod间数据一致性。
FAQ(031):MindCluster恢复策略之间是否存在优先级关系?
四个选项retry、recover、dump和exit是否按照特定顺序执行?
原因分析
不同级别的故障处理机制存在逻辑依赖,但并非硬性规定先后次序。例如UCE(用户空间错误)会触发在线恢复流程。
解决办法
- 配置文件中指定策略组合:按需启用任意数量的选项。
- 理解执行顺序原则:
- 在线恢复失败后才会尝试重调度;
- dump操作完成后仍可能继续进行exit处理(除非特别设置
dump-only=true
)。
FAQ(032):MindCluster组件是否会被集成到TaskD中?
Elastic、MindIO ACP等子模块是否会统一纳入主控程序?
原因分析
各工具包功能定位差异较大,部分会重构整合而其他则保持独立状态。例如elastic将被合并进taskd以简化架构。
解决办法
- 确认当前版本文档:查看官方发布说明了解哪些组件已被废弃。
- 关注未来更新计划: 通过gitee下载页面跟踪最新release信息,如npu-exporter升级至7.0.RC1可解决部分兼容性问题。
FAQ(033):Kubernetes无法识别NPU卡导致任务挂起
部署mindxdl组件时遇到NPU核心分配异常。
原因分析
驱动版本与minxdl配置参数不匹配,动态切分场景下缺少必要标签定义。官方提供的device-plugin-volcano-yaml文件未正确设置presetVirtualDevice=false
解决办法
- 验证节点打标情况:检查是否包含加速器类型为module-910xxx的标记。
- 修改dp启动参数: 在volcano-system命名空间下的scheduler configmap中添加
-p reset=true -log-level=info
以启用调试日志。
FAQ(034):多任务环境中hccl.json文件相互覆盖影响调度
在Ascend Operator组件下多个训练POD生成相同名称的配置文件时产生冲突。
原因分析
容器内RankTable根目录路径必须与宿主机保持一致,否则会读取错误位置。实际测试表明此过程并非完全自动化完成而是需要手动指定挂载点。
解决办法
- 统一命名空间:确保所有任务POD的volumes指向相同的物理存储地址。
- 避免全局变量污染: 为每个训练Pod分配独立子目录,如
/user/mindx-dl/ranktable/taskid
FAQ(035):故障恢复后检查点保存失败导致无法继续执行
当启用进程级快速恢复特性时仍可能发生数据丢失。
原因分析
部分故障类型不支持ckpt自动拉起,例如硬件损坏需先修复设备才能重启任务。此外dump策略仅作为exit前的附加选项存在。
解决办法
- 查看框架日志:MindSpore或PyTorch训练记录中会包含详细的错误代码。
- 设置强制退出标志: 在yaml文件里添加
process-recover-enable=off
禁用自动恢复,便于排查根本原因。
FAQ(036):如何获取NPU卡的vGPU指标采集信息
使用Prometheus监控时遇到npu-exporter在进程占用设备时报错。
原因分析
6.0版本组件仅支持200I DK硬件架构,无法识别虚拟化后的NPU核心。需要等待7.x升级以兼容新式显卡切分技术。
解决办法
- ** 确认固件/驱动匹配:** 检查系统是否已安装适配containerd 1.6+的专用DK。
- ** 监控策略调整:** 对于非整机部署场景,建议使用
kubectl describe pod npu-exporter-xxx | grep -i configmap:device-plugin
FAQ(037):如何为NPU卡配置正确的加速器类型参数
在创建POD时遇到accelerator-type=module-xxxb-8无法识别的问题。
原因分析
文档未明确列出所有支持的型号,且不同硬件需要特定的标签组合。例如nodeSelector应包含accelerator-type=module-910xxx
解决办法
访问官方指南页面:
https://www.hiascend.com/document/detail/zh/mindcluster/600/clustersched/usage/schedulingug/mxdlug_scheduling_013.html
并参考其中的"accelerator-type=module-{xxx}b-8"格式填写参数。
FAQ(038):Atlas 300V解码视频时出现"SetDevice failed, ret = 507033"错误
原因分析:
当使用Atlas 300V进行多路视频流的FFmpeg解码操作时,系统限制了同时运行的最大进程数为64个。当尝试启动超过这个数量的任务时,会遇到无法设置设备的问题。
解决办法:
- 确保使用的服务器类型支持DDR(如800T A2、800I A2或200T A2 Box);
- 检查并确认npu-exporter是否正常工作:在NPU上执行
wget {npu-exporter-pod-id}:8082/metrics
获取指标信息,若异常则检查其Pod状态及日志。 - 如果是设备DDR不支持,则此限制为硬件特性而非错误;
FAQ(039):NPU利用率的采集方式
原因分析:
NPU利用率是通过定期调用驱动提供的DCMI接口获取的数据。
解决办法:
- 为确保正确收集数据,应检查并配置npu-exporter服务;
- 在容器中挂载必要的工具如
/usr/local/bin/npu-smi
以便进行NPU信息查询。
FAQ(040):Ascend DMI命令不可执行
原因分析:
ascend-dmi可能未安装或环境变量设置不正确。
解决办法:
- 安装Toolbox软件包;
- 设置正确的路径和环境变量,确保ascend-dmi可被调用。
FAQ(041):NPU利用率指标查询失败
原因分析:
npu-exporter日志中出现大量错误信息可能表明配置或挂载问题。
解决办法:
- 检查npu-exporter的YAML文件是否正确地定义了所需的卷和路径;
- 确保所有必要的系统目录(如
/usr/local/Ascend/driver
,/var/run/docker
, 以及日志存储位置)已挂载到容器中。
FAQ(042):NPU利用率低
原因分析:
NPU的D2H和H2D性能差异可能由硬件架构限制导致。
解决办法:
- 对于Atlas 300I Duo卡,主芯片与从芯片之间的数据传输依赖HCCS链路;
- 考虑BIOS设置调整以优化HCCS带宽。
FAQ(043):单张Ascend NPU是否能被多个容器挂载
原因分析:
单个NPU设备在同一时间只能由一个进程控制。
解决办法:
- 只允许单一镜像或应用使用该硬件资源;
- 若需多任务处理,应考虑部署额外的计算实例。
FAQ(044):MxBase内存申请失败
原因分析:
MxVision接口可能要求特定条件下的内存分配。
解决办法:
- 使用
MEMORY_HOST_MALLOC
或MEMORY_HOST_NEW
来确保兼容性; - 确保在调用任何涉及NPU的函数前,已经正确初始化了上下文。
FAQ(045):如何优化仿射变换性能
原因分析:
小尺寸图像处理时CPU可能比NPU更快。
解决办法:
- 使用推荐的标准图片大小(如640x480)以利用硬件加速;
- 确认MxVision是否使用了定制版OpenCV库进行优化。
FAQ(046):如何解决在容器中运行npu-smi info
命令时出现错误码-8005的问题?
用户通过Ascend Docker Runtime启动容器后,执行npu-smi info
显示错误信息"DrvMngGetConsoleLogLevel failed. (g_conLogLevel=3)“和"dcmi module initialize failed. ret is -8005”
原因分析:
- 容器内缺少必要的运行时环境配置
- 或者Ascend Docker Runtime安装后未正确完成初始化
解决办法:
-
在启动容器之后,执行以下命令进行后续操作:
mkdir /dev/shm/dmp mkdir /home/HwHiAiUser/hdc_ppc nohup /var/dmp_daemon -I -M -U 8087 >&/dev/null &
-
确保环境变量ASCEND_VISIBLE_DEVICES设置正确。如果问题依旧存在,检查容器内是否已安装Ascend Docker Runtime所需的依赖项。
FAQ(047):使用MindCluster时如何处理npu-smi: command not found
错误?
原因分析:
- 安装的镜像中缺少npu-smi命令行工具
解决办法:
- 使用包含完整环境配置的基础镜像,例如官方提供的ascend-infer或兼容版本。
- 确保在容器内正确安装了Ascend Docker Runtime,并且该运行时包含了所有必要的二进制文件和库。
FAQ(048):如何处理使用MindCluster的动态虚拟化特性启动Pod时报错MountVolume.SetUp failed for volume "vnpucfg"
?
部署ascend-device-plugin后,执行kubectl命令创建资源失败
原因分析:
- 缺少必要的配置文件/etc/vnpu.cfg导致挂载操作异常。
解决办法:
-
在宿主机上手动创建该文件:
touch /etc/vnpu.cfg
-
确保Ascend驱动版本与NPU HDK(Host Development Kit)兼容,以避免因不匹配而导致的错误。
FAQ(049):如何配置非root用户访问容器中的NPUs?
在使用Atlas 300v Pro设备时发现只有root启动容器才能正常检测到虚拟化后的NPU信息。
原因分析:
- 容器运行环境下的UID和GID与Ascend驱动安装时不一致
- 没有正确设置ASCEND_VISIBLE_DEVICES变量或权限问题
解决办法:
-
使用非root用户时,确保在容器启动命令中包含
--privileged=true
参数。 -
在宿主机上使用如下方式重新安装Ascend Docker Runtime:
./Ascend-docker-runtime_6.0.RC3_linux-aarch64.run --install --install-type=A200IA2 --install-for-all
-
验证容器内用户与NPU设备文件的uid/gid是否匹配。
FAQ(050):如何解决镜像中缺少npu-smi
命令的问题?
运行train_start.sh脚本时提示’npu-smi’未找到
原因分析:
- 镜像是基于Ascend Toolkit构建,没有包含必要的工具链或环境配置。
解决办法:
- 确保使用的镜像中包含了npu-smi命令。
- 检查并确认是否在容器内正确设置了ASCEND_VISIBLE_DEVICES和ASCEND_ALLOW_LINK=True等必要环境变量。
FAQ(051):MindSDK的安装提示权限错误(如FileUtils.cpp:495)?
执行APP_ERROR ret = MxInit();
时出现日志文件写入失败,显示关于用户ID和组ID不一致的日志信息。
原因分析:
- 安装CANN、驱动等组件的账户与运行应用的非root用户的权限设置冲突
解决办法:
- 以相同的普通用户身份安装所有Ascend相关软件包。
- 参照官方文档确认并统一安装和使用时的操作用户。
FAQ(052):如何在Kubernetes中配置容器化部署?
按照指南准备YAML文件后,Pod启动失败
原因分析:
- YAML中的command字段指向了不存在的脚本或路径错误
- 镜像内部环境未正确设置以支持训练任务执行
解决办法:
- 请检查并确认镜像
mindspore-modelzoo:23.0.0
是否确实包含所需运行的shell文件(如test_model.sh)。 - 确保在容器中,所有必要的环境变量和路径都已正确设置。
FAQ(053):MindSDK安装时提示"owner id diff"问题?
原因分析:
- 安装CANN或相关工具包使用的是root权限而运行程序的用户不是相同的
解决办法:
- 以非root(如HwHiAiUser)身份重新安装所有Ascend相关的组件。
- 确保运行时环境变量配置正确,并且该用户的UID和GID与设备文件一致。
FAQ(054):使用Containerd作为容器运行器是否支持MindCluster的集群调度?
用户询问Kubernetes中能否用containerd代替docker
原因分析:
- 当前版本可能存在兼容性限制或配置错误
解决办法:
- 确认当前使用的MindX DL版本,查阅官方文档确认其对Containerd的支持情况。
- 联系技术支持获取最新补丁或等待新版本发布。
FAQ(055):如何确保非root用户可以在容器中使用Ascend设备?
以普通账户启动的容器无法访问NPU资源
原因分析:
- 安装Ascend Docker Runtime时未指定–install-for-all参数
- 用户权限不足,导致对/dev/vdavinci等文件没有读取和写入权限
解决办法:
- 重新安装Ascend Docker运行环境,并添加
--intall-for-all
选项。 - 检查容器内用户与设备文件的uid/gid是否一致。若不匹配,考虑修改或调整用户的ID以确保一致性。
FAQ(056):使用非root账户进行日志采集时遇到权限问题?
原因分析:
- 日志目录/home对当前运行脚本的用户具有写保护
解决办法:
- 修改日志存储路径为该普通用户有访问权限的位置。
- 调整相关安全策略,确保非root账户可以执行日志采集任务。
FAQ(057):在华为云ModelArts Notebook上安装MindSDK时遇到限制?
无法使用root权限进行Ascend SDK的部署
原因分析:
- 安装用户与CANN环境配置不一致
- 环境变量未正确设置影响了组件识别和访问
解决办法:
- 以非root但具有相应权限的身份安装SDK,确保该账户拥有对所有Ascend相关文件的读写执行权。
- 设置合适的环境变量,并参考官方文档中的用户指南。
FAQ(058):如何解决Kubernetes中Ascend Job无法调度的问题?
当使用MindCluster部署多个任务时,即使有足够资源且配置相同的情况下仍然出现部分Pod处于Pending状态。具体表现为“pod group is not ready, 1 Pending”。
原因分析:
可能是由于NPU设备插件(device-plugin)或Volcano调度器未能正确识别和分配NPUCORE资源导致的。
解决办法:
- 确保使用正确的版本组合,如ascend-for-volcano与v1.7.1及以上的volcano版本兼容。
- 检查并确认NPU设备插件是否正常运行,并查看相关日志(/var/log/mindx-dl/devicePlugin/devicePlugin.log)以获取更多信息。
FAQ(059):如何解决Ascend Docker Runtime安装后Docker容器无法启动的问题?
在Ubuntu 22.04系统上安装ascend docker runtime后,执行docker-compose up -d
命令时出现错误提示“unable to retrieve OCI runtime error”。
原因分析:
可能是由于Ascend Docker运行环境配置不正确或与现有Docker服务冲突导致。
解决办法:
-
安装完成后尝试卸载并重新安装ascend docker runtime。
systemctl daemon-reload && systemctl restart docker
-
如果问题仍然存在,检查
/var/run/docker/containerd/daemon/io.containerd.runtime.v2.task/moby/<container_id>/log.json
是否存在及权限设置。
FAQ(060):如何确保NPU Exporter在Kubernetes集群中正常运行?
当使用npu-exporter采集指标时,遇到错误提示无法解析ASCEND_VISIBLE_DEVICES的值为Ascend910xxx,并且容器启动后退出报错。
原因分析:
使用的npu-exporter版本较低(v5.0.0),不支持新的设备标识格式如“Ascend910xxx”。
解决办法:
升级至6.x或更高版本的npu-exporter,以确保兼容性。检查日志文件确认是否有其他初始化失败信息。
FAQ(061):如何查看NPU卡上的AICore数量?
用户想要知道如何查询Ascend NPU设备上可用的AI Core(aicore)的数量。
原因分析:
需要通过特定命令获取硬件详细信息,而不是直接在Kubernetes中看到这些细节。
解决办法:
执行以下命令来查看NPU卡上的AICore数量:
npu-smi info -t info-vdss -c <card_index>
其中<card_index>
是您要查询的特定NPU设备索引号,例如0或1。
FAQ(062):如何解决Ascend Docker运行时无法找到日志文件的问题?
安装ascend-docker-runtime后执行docker命令时报错“unable to retrieve OCI runtime error (open /var/run/docker/containerd/daemon/io.containerd.runtime.v2.task/moby/61644cb93a9f0d26534… no such file or directory)”。
原因分析:
Ascend Docker运行时与Docker服务配置可能存在不兼容,或安装过程中未正确设置。
解决办法:
-
尝试卸载ascend-docker-runtime并使用默认的docker runtime。
sudo ./Ascend-docker-runtime_5.0.0_linux-x86_64.run --uninstall
-
确认执行了
systemctl daemon-reload && systemctl restart docker
FAQ(063):如何解决NPU Exporter无法初始化的问题?
npu-exporter容器启动时报错,提示deviceManager init failed和get chip info失败。
原因分析:
可能是DCMI(Device Communication Management Interface)接口调用异常导致设备管理器未能正确初始化。检查相关服务日志有助于定位具体错误源。
解决办法:
-
查看
/var/log/nputools_LOG_INFO.log
和/var/log/nputools_LOG_ERR.log
cat /var/log/npu-tools_LOG_INFO.log | grep -i error
FAQ(064):如何确保vNPU资源在Kubernetes中被正确识别?
ascend-device-plugin插件故障导致vnpu资源丢失。
原因分析:
当使用静态切分方式创建或销毁VNPU后,device-plugin可能未能及时更新其设备列表。需要手动重启以使其感知到新添加的vNPU。
解决办法:
每次更改vNPU配置(如新增、删除)之后都应重新启动ascend-device-plugin服务。
systemctl restart ascend-device-plugin
FAQ(065):如何在Atlas设备上使用FFmpeg进行视频流处理?
开发者询问如何利用Ascend加速卡通过ffmpeg将RTSP流推送到SRS服务器。
原因分析:
需要确保NPU的编解码功能已正确配置,并且使用的SDK版本与CANN工具包兼容以支持硬编码操作。
解决办法:
- 确保使用了正确的MindX SDK(如mxVision 6.0)和配套的CANN Toolkit。
- 检查环境变量是否设置,包括
LD_LIBRARY_PATH
等关键路径配置。
FAQ(066):如何确认NPU卡当前资源利用率?
用户需要查看Ascend NPU设备上的解码器(Decoder)和编码器(encoder)的使用率以评估性能瓶颈或负载情况。
原因分析:
缺乏对特定工具的理解,或者未正确配置监控系统。
解决办法:
-
使用
npu-smi
命令行接口查询NPU利用率。npu-smi info -t utilization
FAQ(067):如何确认使用的Ascend设备信息?
用户发现某些Prometheus指标缺少node节点信息,导致难以跟踪具体硬件使用情况。
原因分析:
当前npu-exporter版本可能未包含Node级别的元数据收集功能。
解决办法:
-
使用6.0.RC1或更高版本的npu exporter。
npu-smi info -t metrics
FAQ(068):如何正确配置Kubernetes以调度NPU资源?
在Atlas设备上,即使多个任务需要不同NPUs且有足够的空闲卡时仍无法启动新Pod。
原因分析:
可能由于节点标签、affinity设置或device-plugin未更新所致。
解决办法:
-
确保nodeSelector和资源请求正确。
resources:requests:huawei.com/npu-core: "2"
FAQ(069):如何确认Ascend设备是否支持FP16推理?
用户询问mxVision版本是否能进行半精度(FP16)计算以加速模型运行。
原因分析:
需要查阅官方文档了解特定SDK和工具包对数据类型的兼容性。
解决办法:
-
访问华为昇腾技术社区或相关产品的详细规格页面,确认所使用的mxVision版本是否支持FP16推理。
# 示例命令(可能需根据实际情况调整) npu-smi info -t supported-data-types
FAQ(070):如何解决/etc/os-release软链接错误问题?
安装Ascend Docker运行时工具包时报错“/etc/os-release is invalid”。
原因分析:
系统文件结构不符合预期,导致脚本检测失败。
解决办法:
-
检查
/etc/os-release
是否为有效的符号链接或实际存在的配置文件。ls -l /etc/os-release
FAQ(071):如何获取NPU卡的详细信息?
用户想确认Ascend NPU上的AICore数量,用于资源规划和负载均衡。
原因分析:
需要使用正确的工具来查询硬件详情。
解决办法:
-
使用
npu-smi info -t aicore -c <card_index>
命令获取信息。npu-smi info -t utilization
FAQ(072):如何在Kubernetes中使用NPU设备?
用户部署多个任务时,即使有空闲的NPUs也无法调度。
原因分析:
可能涉及节点亲和性设置或PodAffinity/Anti-affinity配置不当。
解决办法:
-
确保YAML文件中正确指定了NPU资源请求。
resources:requests:huawei.com/npu-core: "2"
FAQ(073):如何处理Kubernetes中Ascend Job无法调度的问题?
原因分析:
在部署多个Ascend任务(如Pod)到同一个节点上,即使资源充足的情况下也可能因为某些配置或环境问题导致部分 Pod 处于Pending状态。
解决办法:
-
确保使用正确的版本组合:
ascend-for-volcano
需要与volcano v1.7.1+
版本搭配。-
检查Pod的YAML配置文件中资源请求是否正确,例如:
resources:requests:huawei.com/npu-core: "2"
-
-
查看节点和Pod的日志信息以获取更多线索。关键日志路径为
/var/log/mindx-dl/volcano-scheduler.log
和/var/log/mindx-dl/devicePlugin/devicePlugin.log
kubectl describe node <node_name> kubectl logs -f npu-exporter-pod-name
FAQ(074):安装Ascend Docker运行时后,Docker容器启动失败
原因分析:
可能是由于操作系统配置不正确或与Ascend Docker运行时不兼容。
解决办法:
-
确保
/etc/os-release
是一个有效的文件而非软链接。ls -l /etc/os-release
-
卸载当前安装的ascend-docker-runtime并重新尝试默认Docker runtime:
sudo ./Ascend-docker-runtime_6.0.RC2_linux-x86_64.run --uninstallsystemctl daemon-reload && systemctl restart docker
FAQ(075):如何确认NPU卡上的AICore数量
原因分析:
需要通过命令行工具查询NPU设备的详细信息。
解决办法:
-
使用
npu-smi info -t aicore
命令查看Ascend NPU上可用的AI Core(aicore)数目。npu-smi info -t utilization
FAQ(076):如何确保NPU Exporter在Kubernetes中正常运行?
原因分析:
npu-exporter版本较低,不支持新的设备标识格式。
解决办法:
-
升级到6.0.RC1或更高版本。
npu-smi info -t metrics
FAQ(077):如何在Atlas 200I上使用FFmpeg进行视频流处理?
原因分析:
需要确保Ascend加速卡的编解码功能正确启用,并且使用的SDK版本支持所需的功能。
解决办法:
-
确保安装了兼容的CANN Toolkit和MindX SDK。
npu-smi info -t supported-codecs
FAQ(078):如何检查Ascend Docker运行时是否正确配置?
原因分析:
Docker日志显示ascend-docker-runtime启动失败,可能是环境路径或权限问题。
解决办法:
-
检查
/var/run/docker/containerd/daemon/io.containerd.runtime.v2.task/moby/<container_id>/log.json
-
确认Ascend Docker运行时是否与当前Docker版本兼容。
systemctl status docker
-
FAQ(079):如何解决NPU Exporter无法初始化的问题?
原因分析:
DCMI接口调用失败,可能是硬件或驱动问题。
解决办法:
-
检查日志文件
/var/log/npu-tools_LOG_INFO.log
和/var/log/nputoolss_LOG_ERR.log
-
确认NPU设备是否被正确识别。
npu-smi info
-
FAQ(080):如何监控Atlas服务器上的Ascend NPU资源使用情况?
原因分析:
当前版本的npu-exporter可能未包含Node级别信息。
解决办法:
-
使用6.0.RC1+版本。
npu-smi info -t node-info
FAQ(081):如何确保Ascend设备插件正确报告vNPU资源?
原因分析:
静态切分后未重启ascend-device-plugin或有配置错误。
解决办法:
-
每次修改了VNPU的划分之后,都需要重新启动device-plugin。
systemctl restart ascend-device-plugin
FAQ(082):如何获取Ascend NPU上的编解码利用率信息?
原因分析:
需要特定工具或命令来查看硬件使用情况。
解决办法:
-
使用
npu-smi info -t utilization
npu-smi info
FAQ(083):如何处理NPU Exporter日志中的错误?
原因分析:
可能是deviceManager初始化失败,需要检查DCMI接口是否正常工作。
解决办法:
-
检查相关服务状态和依赖项。
journalctl -u npu-exporter.service
FAQ(084):如何配置Kubernetes以避免Ascend任务调度问题?
原因分析:
可能涉及节点选择器、亲和性设置或device-plugin未正确识别设备。
解决办法:
-
在YAML中添加合适的nodeSelector标签。
nodeSelector:npu.compatible: "true"
FAQ(085):如何确认Ascend软件是否支持FP16推理?
原因分析:
需要查阅官方文档以确定SDK的兼容性。
解决办法:
-
访问华为昇腾技术社区,查找对应mxVision版本的支持特性。
npu-smi info -t supported-dtypes
FAQ(086):如何排查Ascend Docker运行时安装问题?
原因分析:
可能是由于系统文件路径错误或权限不足。
解决办法:
-
检查
/etc/os-release
ls /var/run/docker/containerd/daemon/io.containerd.runtime.v2.task/moby
FAQ(087):如何获取K8s中Ascend设备的详细信息?
原因分析:
需要利用npu-smi命令行工具查询。
解决办法:
-
使用
npu-smi info -t utilization
来检查使用率。npu-smi info
FAQ(088):如何获取或创建适用于Atlas 300I Pro推理卡的日志采集工具(npu-exporter)的Grafana面板配置文件?
原因分析
用户在使用npu-exporter
监控昇腾NPU设备时发现,官方文档未提供直接可用的 Grafana 面板模板。当前版本中并未内置 Atlas 300I Pro 推理卡对应的 Dashboard 模板。
解决办法:
-
可以参考官网提供的示例面板地址:
https://grafana.com/grafana/dashboards/20592-ascend-npu-exporter/
FAQ(089):如何正确设置GST_PLUGIN_PATH
环境变量,避免出现“File in GST_PLUGIN_PATH is invalid”的错误?
原因分析
在Atlas 200i DK A2设备上运行视频处理应用时,用户未正确配置GStreamer插件路径导致的初始化失败。
解决办法:
-
检查
/usr/local/Ascend/mxVision/opensource/lib/gstreamer-1.0:/usr/local/Ascend/mxVision/lib/plugins
目录下是否包含可执行文件。 -
确保环境变量已正确设置,可以采用以下方式之一:
-
永久方法:在当前用户的
.bashrc
或系统级的shell配置中添加并生效source /usr/local/Ascend/mxVision/set_env.sh # 或者对应的set_env路径
-
临时设置:
export GST_PLUGIN_PATH=/usr/local/Ascend/mxVision/lib/plugins:/usr/local/Ascend/mxvision/opensource/lib/gstreamer-1.0
-
FAQ(090):Atlas 300I Pro推理卡是否支持使用AiPhysicalAttackAndDetecting
示例?
原因分析
当前提供的样例模型是为 Ascend 310B 设备编译的,其格式不兼容 Atlas 300I Pro 推理卡。
解决办法:
- 当前示例中的 ONNX 模型未提供适配版本。
- 若有原始ONNX文件,则需自行转换以适应目标硬件平台(如Atlas 300I Pro)的架构特性,例如通过使用ATC工具进行模型转换,并确保与昇腾AI处理器兼容。
FAQ(091):如何选择合适的MindX DL版本用于生产环境?
原因分析
用户对于不同应用场景下推荐使用的MindX深度学习框架版本存在疑问,在多个可用版本中难以抉择,担心不稳定性或缺少长期维护支持的问题。
解决办法:
-
建议使用最新发布的稳定版(如当前为6.0.RC2),以确保获得最新的功能和安全性更新。
mindx install -v=latest
FAQ(092):如何确定Atlas服务器上的昇腾AI芯片型号?
原因分析
用户在裸金属主机上执行npu-smi info
命令后得到的NPU名称(如910xxx)无法直接对应官方文档中的产品标签。
解决办法:
- 按照如下步骤确认:
- 查看设备信息,通常通过
lspci
或厂商提供的硬件检测工具。 - 对比昇腾官网的产品列表及对应的AI芯片型号命名规则,以匹配相应标签。
- 查看设备信息,通常通过
FAQ(093):在Atlas 300V上进行500万张人脸特征库的精确检索时,如何提高QPS性能?
原因分析
使用AscendIndexFlat
算法可能无法满足高并发需求;而近似搜索(如IVFSQ)可以提升效率。
解决办法:
-
推荐采用近似最近邻方法进行初步筛选。
-
示例代码:
// 使用近似索引初始化并检索 Top-K 结果,然后再使用精确匹配算法获取最接近的结果.AscendIndexIVFSQ index; IndexFlat index_flat;// 创建近似索引... // 查询TopK个候选结果// 对于每个TopK中的项目进行AscendIndexFlat的详细比较
-
FAQ(094):vNPU相关性能指标为何采集不到?
原因分析
当前版本仅支持特定型号设备(如Atlas 200I SoC A1核心板)。
解决办法:
- 确认所用硬件是否为 Atlas 推理系列产品。
- 如果使用的是其他类型的昇腾卡,考虑升级到兼容的vNPU指标采集方案或联系官方获取支持。
FAQ(095):如何通过npu-exporter
上报多个错误码?
原因分析
Prometheus监控系统中对于多错误代码的支持存在限制。
解决办法:
-
当有超过一个错误发生时,将依次命名为
npu_chip_info_error_code_1
, …,npu_chip_info_error_code_n
。-
示例格式:
# HELP npu_chip_info_error_code the First npu error code # TYPE npu_chip_info_error_code gauge npu_chip_info_error_code{...} <十进制错误码># HELP npu_chip_info_error_code_1 ...
-
FAQ(096):Ascend-DMI工具显示的算力结果与实际计算不一致?
原因分析
硬件特性(如AI Core数量、频率)和算法实现效率差异,可能导致理论值与实测性能存在偏差。
解决办法:
- 根据文档提供的公式重新验证:
- Cube单元:16×16×16次操作/周期 × 频率
- Vector单元:16×16次操作/周期 × 高频数
FAQ(097):如何在Atlas300I Pro上运行Vision SDK中的视频解码功能?
原因分析
底层硬件限制导致某些特定分辨率的处理失败。
解决办法:
- 解析报错信息,确认是否与图像尺寸有关。
- 尝试调整输入图片大小至符合16倍数(如从1920x1087改为1920x1080)以避免因解码器限制而出现的异常。
FAQ(098):安装MindX SDK后在Python环境中import mind.sdk
时报错?
原因分析:
环境变量未正确配置,或者安装过程中某些依赖项缺失。
解决办法:
- 检查是否已按照文档执行了环境变量设置命令(如
. /mxVision/set_env.sh
); - 验证Python环境中是否存在多个版本的MindX SDK导致冲突。
FAQ(099):安装Ascend-cann-toolbox后找不到hccn_tool?
原因分析:
hccn_tool可能未随CANN工具包一起安装,或文档指引不明确。
解决办法:
- 查阅相关指南确认是否包含此工具;
- 如果确实缺失,则需要单独下载对应版本的HCCL库。
FAQ(100):编译项目时提示找不到某些FFmpeg动态链接库文件?
原因分析:
自定义编译的FFmpeg版本与系统中预装组件存在不兼容。
解决办法:
- 在构建过程中确保所有相关的.so文件都被正确地包含在内;
- 使用
find / | grep libswresample
等命令查找缺失库的位置,并将其路径添加至环境变量或编译时的链接目录。
FAQ(101):C++项目中导入MxBase.h失败,提示找不到opencv_modules.hpp?
原因分析:
缺少必要的OpenCV头文件包含。
解决办法:
- 在CMakeLists.txt里添加
include_directories(${MX_SDK_HOME}/opensource/include/opencv4)
; - 确保链接了正确的动态库,如需可手动指定路径。
FAQ(102):使用Atlas300I DUO设备进行分布式训练时缺少hccn_tool?
原因分析:
hccn_tool可能未包含在当前安装的CANN工具包中。
解决办法:
- 查看官方文档了解获取方式;
- 可能需要单独下载HCCL相关组件。
FAQ(103):在使用mxVision SDK时遇到Segmentation fault (core dumped)错误?
原因分析:
当前版本的SDK不支持特定硬件型号。
解决办法:
- 核对使用的MX Vision与CANN版本是否匹配;
- 参考官方文档确认所用接口在目标设备上的可用性。
FAQ(104):使用ROS2节点整合mxVision SDK时遇到Torch文件缺失?
原因分析:
环境变量配置不完整,或安装存在问题。
解决办法:
- 检查环境是否正确设置;
- 根据官方文档重新审视并确保所有依赖已满足。
FAQ(105):安装MindX SDK时提示缺少GCC导致失败?
原因分析:
系统中未安装或配置好编译工具链。
解决办法:
- 即使使用Python,也需要确保底层依赖的C/C++构建环境;
- 按照用户指南完成所有必需的基础软件包。
FAQ(106):在cmakelists.txt中添加链接目录后仍然报错?
原因分析:
动态库路径未被正确识别。
解决办法:
- 使用
find_library()
查找缺失的.so文件; - 明确指定所有依赖项,而不仅仅是通过link_directories。
FAQ(107):如何使用WarpAffine对Device侧MxBase::Image进行人脸校正?
原因分析:
MxTools中的某些函数仅适用于特定数据类型。
解决办法:
- 将图像先转换为Tensor格式;
- 参考提供的示例代码或官方文档实现功能。
FAQ(108):在使用FFmpeg插件时遇到链接错误?
原因分析:
使用了与SDK不兼容的第三方库版本。
解决办法:
- 确保所有依赖项都来自mxVision环境;
- 若需自定义编译,确保其版本和接口符合要求。
FAQ(109):当使用import mind.sdk
时提示模块不存在?
原因分析:
Python环境中缺少必要的Python包。
解决办法:
- 确认安装了所有必需的依赖;
- 检查环境变量是否正确配置。
FAQ(110):如何确认MxTools中的函数签名?
原因分析:
函数名在动态库中找不到,可能是链接时遗漏。
解决办法:
- 在CMakeLists.txt文件内显式指定所需符号;
- 提供详细错误截图以便进一步排查。
FAQ(111):当使用WarpAffineHiper
处理人脸数据时遇到问题?
原因分析:
操作对象类型不匹配。
解决办法:
- 使用ConvertToTensor方法将图像转为适当格式;
- 对于更底层的实现,可参考ACL文档进行调整。
FAQ(112):mxVersion-6.0 RC3遇到“av_buffersink_get_h@LIBAVFILTER_7”未定义引用?
原因分析:
自编译FFmpeg与mxVision自带组件存在版本不兼容。
解决办法:
- 确认使用的opencv4.7和ffmpeg是否为官方推荐组合;
- 如果需要自建,确保所有依赖项都正确链接。
FAQ(113):在Atlas设备上长时间运行FFmpeg编码时出现灰屏或花屏现象。
原因分析
Ascend-FFmpeg的h264_ascend_enc组件存在内存管理缺陷,导致长期使用后无法正确释放/分配设备资源。错误日志中提示[h264_ascend_enc] Ascend memory D2H failed, ret is 507899.
。
解决办法
-
修改Ascend-FFmpeg源码注释以下代码:
// 注释掉ascend_enc.c文件中第705行的hi_mpi_dvpp_free调用
-
执行重新编译和安装操作以应用修改。
FAQ(114):MxBase模型加载失败,提示“failed to get output dims or the it exceeds the upper limit”或类似错误信息。
原因分析:
ATC转换时未指定--input_shape
参数导致生成的OM文件与实际输入不匹配。
解决办法:
-
使用 ATC 工具进行模型转换时,务必明确提供
--input_shape="image:batch_size,channels,height,width"
参数。 -
确保SOC版本型号(如Ascend310xx)和ATC工具链兼容性。例如:
atc --model=./clip.onnx \--framework=5 \--output=./clip.om \--soc_version=$SocVersion \--input_shape="image:1,3,224,224"
FAQ(115):使用AscendStream进行推理时,返回的输出为空但错误码为APP_ERR_OK。
原因分析
调用异步接口 Infer(std::vector<>, AscendStream)
未正确初始化output tensor对象导致空结果。
解决办法:
-
参考官方示例代码中的
Yolov7PostProcess.cpp
文件,手动构造输出Tensor。 -
使用如下方式创建:
std::vector<MxBase::Tensor> output_tensors; for (int i = 0; i < num_outputs; ++i) {MxBase::TensorDesc desc(output_shapes[i], data_type, format);output_tensors.push_back(MxBase::Tensor(desc)); }
FAQ(116):MxVision SDK中如何实现Device-to-Device的图像拷贝?
原因分析:
SDK未提供直接接口,需使用底层ACL API操作。
解决办法:
-
使用
aclrtMemcpy
函数进行设备间数据复制。aclError ret = aclrtMemcpy(destination_device_ptr, size,source_device_ptr, size,ACL_MEMCPY_DEVICE_TO_HOST);
-
确保源和目的内存区域均已被正确分配。
FAQ(117):使用Netron查看OM模型时报错“File does not contain a model model definition”。
原因分析:
可能是ATC转换过程中生成的.om文件损坏或格式不兼容当前工具。
解决办法:
- 确保使用的ATC版本和硬件平台匹配。
- 使用
--output_format=om
参数并检查输出路径是否正确。 - 通过https://github.com/lutzroeder/netron 提交反馈,确认OM文件格式问题。
FAQ(118):MindX DL与MindCluster有什么区别?在什么场景下使用?
原因分析:
两者为不同名称的同一产品。部署时需关注根分区大小影响Kubernetes调度器行为(如kubelet清理机制)。
解决办法:
- Mindx DL和Mind Cluster是同一个产品的两个命名阶段,无实质差异。
- 部署建议将根目录空间预留充足以避免因存储不足导致的镜像清理问题。
FAQ(119):昇腾MindCluster是否同时支持硬件虚拟化和软件虚拟化?
原因分析:
当前仅存在硬件虚拟化方式,不存在软件虚拟化的实现。反馈中提及"软件*静态/动态""可能与实际架构描述不符,请确认参考资料来源是否为昇腾官方资料。
解决办法:
(1)在任务调度层面:
- 硬件虚拟化通过物理资源划分进行隔离管理
- 软件虚拟化的概念未被实现,当前系统不支持该方式
(2)关于推理产品设置修改的说明:
当前昇腾AI处理器仅采用硬件虚拟化技术作为标准配置方案。
补充说明:
根据MindCluster特性中的集群调度功能描述可知,NPU资源管理主要通过物理层面划分来实施。用户在部署时需注意参考资料版本是否为最新官方文档,并以实际支持的硬件*静态/动态两种组合方式为准进行规划。