故障排查速查清单ttm-r3-npu常见报错NPU不可用/设备不匹配一次解决【免费下载链接】ttm-r3-npu项目地址: https://ai.gitcode.com/atlasleong/ttm-r3-nputtm-r3-npu 是 IBM TinyTimeMixer R3TTM-R3轻量级时序预测模型在华为昇腾 NPU 上的独立交付仓库模型快照、建模代码和推理入口都打包在一起拷贝到昇腾主机即可独立运行。对新手来说最容易在第一步就卡住的正是NPU 不可用和设备不匹配这两类 ttm-r3-npu 常见报错。本文按报错现象分节整理了一份故障排查速查清单从识别报错标记到逐条修复照着做就能一次解决。1. 先看懂运行时的 5 个关键输出标记运行python3 inference.py后程序会在终端打印一组机器契约标记它们是定位问题的第一手线索全部由 inference.py 在推理前后输出标记正常值含义INPUT_DEVICEnpu:0输入张量所在设备MODEL_DEVICEnpu:0模型参数所在设备OUTPUT_DEVICEnpu:0预测结果所在设备CPU_FALLBACKfalse是否回退到 CPUfalse 才正常EXIT_CODE0进程退出码记住一个口诀即可三个 DEVICE 都必须是 npu:0CPU_FALLBACK 必须为 false。任何一项不符合都会触发对应报错下面逐一拆解。上图是真实适配流程的日志记录可以看到CPU_FALLBACK: true、device mismatch、EXIT CODE: 1等典型的失败场景——这正是下面要解决的报错。2. 报错一NPU 不可用CPU_FALLBACKtrue典型现象终端输出CPU_FALLBACKtrue随后抛出RuntimeError: NPU backend is not available; CPU fallback is forbidden进程以非零码退出。原因当torch.npu.is_available()返回 False 时inference.py 会主动拒绝 CPU 回退——这是本仓库的硬性规则防止用 CPU 结果冒充 NPU 结果。✅ 最快的 4 步排查方法确认物理设备可见执行npu-smi info。如果提示命令找不到或没有列出芯片行如 910B4-1说明驱动或 CANN 未就绪。确认 CANN 环境已加载执行source /usr/local/Ascend/ascend-toolkit/set_env.sh后再运行很多NPU 不可用其实只是忘了加载环境变量。确认 torch_npu 版本匹配用pip show torch_npu检查本仓库实测锁定 torch 2.9.0 torch_npu 2.9.0 CANN 8.5.1版本错位会直接导致后端注册失败。确认 Python 环境一致安装依赖的 venv 必须与运行inference.py的是同一个避免装在一个环境、跑在另一个环境的乌龙。上图是npu-smi的正常输出参考所有芯片HealthOK、有进程占用内存说明物理设备就绪问题多半出在环境变量或 Python 环境上。3. 报错二设备不匹配device mismatch典型现象终端抛出RuntimeError: device mismatch: input... model... output...报错里会明确写出三个设备各自落在了哪里。原因程序在推理后会校验输入、模型、输出三者是否同时位于npu:0见 inference.py 中的设备一致性检查。只要有任何一个落在cpu上就判定为设备不匹配。✅ 最快的 3 步排查方法检查设备可见性环境变量执行echo $ASCEND_RT_VISIBLE_DEVICES以及其他ASCEND_*变量。入口脚本从不读取、删除或改写这些变量如果它们被外部限制逻辑设备npu:0可能不可见。确认代码显式指定了 npu:0程序使用DEVICE npu:0显式定位逻辑设备不要手工改成cuda或cpu也不要依赖默认设备。重启干净环境如有残留的 CUDA 相关设置或旧进程占用可先退出旧会话、重新开终端加载 CANN 环境再试。4. 报错三模型没有落到 npu:0 上典型现象RuntimeError: model did not land on npu:0 (got cpu)。原因模型加载后_ttm_common.py 中的load_model(devicenpu:0)负责把模型移动到 NPU。若这一步失败通常意味着 NPU 后端在加载阶段尚未生效。✅ 处理方法这种情况基本是报错二的前置版本——先把第 3 节的设备可见性检查做完再确认import torch_npu正常注册了 npu 后端然后重新运行即可。加载路径、模型快照均固定在 model/ 目录全程无需任何网络访问。5. 一切正常时的成功输出长这样排障完成后运行python3 inference.py应看到如下结果来自仓库真实 NPU 运行记录INPUT_DEVICEnpu:0 MODEL_DEVICEnpu:0 OUTPUT_DEVICEnpu:0 CPU_FALLBACKfalse OUTPUT_FINITEtrue FORECAST[-1.143884, -1.300210, ...] forecast_shape(1, 30, 1) INFER_MEDIAN_MS31.364211 EXIT_CODE0四个设备标记全部为npu:0、CPU_FALLBACKfalse、EXIT_CODE0说明模型已在昇腾 NPU 上完成推理输入形状(1, 512, 1)输出 30 步点预测(1, 30, 1)单次前向中位耗时约 31ms。6. 3 分钟速查清单现象先查什么最快修复CPU_FALLBACKtruenpu-smi infosource CANN 环境变量提示命令找不到which npu-smi安装/加载 CANN 8.5.1device mismatchecho $ASCEND_RT_VISIBLE_DEVICES清理设备可见性变量model did not land on npu:0pip show torch_npu对齐 torch/torch_npu 版本输出全为cpu检查 Python 环境用同一个 venv 运行结语ttm-r3-npu 的报错设计其实很友好——所有关键信息都印在终端里CPU_FALLBACK、三个*_DEVICE标记和明确的RuntimeError文案。遇到 NPU 不可用或设备不匹配时按上面的速查清单从npu-smi、CANN 环境变量、torch_npu 版本、Python 环境四项逐一核对绝大多数问题都能在 3 分钟内解决。更详细的交付说明、环境依赖与实测数据可查阅仓库内的 README.md 和 requirements.txt。【免费下载链接】ttm-r3-npu项目地址: https://ai.gitcode.com/atlasleong/ttm-r3-npu创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 故障排查速查清单：ttm-r3-npu常见报错（NPU不可用/设备不匹配）一次解决
故障排查速查清单ttm-r3-npu常见报错NPU不可用/设备不匹配一次解决【免费下载链接】ttm-r3-npu项目地址: https://ai.gitcode.com/atlasleong/ttm-r3-nputtm-r3-npu 是 IBM TinyTimeMixer R3TTM-R3轻量级时序预测模型在华为昇腾 NPU 上的独立交付仓库模型快照、建模代码和推理入口都打包在一起拷贝到昇腾主机即可独立运行。对新手来说最容易在第一步就卡住的正是NPU 不可用和设备不匹配这两类 ttm-r3-npu 常见报错。本文按报错现象分节整理了一份故障排查速查清单从识别报错标记到逐条修复照着做就能一次解决。1. 先看懂运行时的 5 个关键输出标记运行python3 inference.py后程序会在终端打印一组机器契约标记它们是定位问题的第一手线索全部由 inference.py 在推理前后输出标记正常值含义INPUT_DEVICEnpu:0输入张量所在设备MODEL_DEVICEnpu:0模型参数所在设备OUTPUT_DEVICEnpu:0预测结果所在设备CPU_FALLBACKfalse是否回退到 CPUfalse 才正常EXIT_CODE0进程退出码记住一个口诀即可三个 DEVICE 都必须是 npu:0CPU_FALLBACK 必须为 false。任何一项不符合都会触发对应报错下面逐一拆解。上图是真实适配流程的日志记录可以看到CPU_FALLBACK: true、device mismatch、EXIT CODE: 1等典型的失败场景——这正是下面要解决的报错。2. 报错一NPU 不可用CPU_FALLBACKtrue典型现象终端输出CPU_FALLBACKtrue随后抛出RuntimeError: NPU backend is not available; CPU fallback is forbidden进程以非零码退出。原因当torch.npu.is_available()返回 False 时inference.py 会主动拒绝 CPU 回退——这是本仓库的硬性规则防止用 CPU 结果冒充 NPU 结果。✅ 最快的 4 步排查方法确认物理设备可见执行npu-smi info。如果提示命令找不到或没有列出芯片行如 910B4-1说明驱动或 CANN 未就绪。确认 CANN 环境已加载执行source /usr/local/Ascend/ascend-toolkit/set_env.sh后再运行很多NPU 不可用其实只是忘了加载环境变量。确认 torch_npu 版本匹配用pip show torch_npu检查本仓库实测锁定 torch 2.9.0 torch_npu 2.9.0 CANN 8.5.1版本错位会直接导致后端注册失败。确认 Python 环境一致安装依赖的 venv 必须与运行inference.py的是同一个避免装在一个环境、跑在另一个环境的乌龙。上图是npu-smi的正常输出参考所有芯片HealthOK、有进程占用内存说明物理设备就绪问题多半出在环境变量或 Python 环境上。3. 报错二设备不匹配device mismatch典型现象终端抛出RuntimeError: device mismatch: input... model... output...报错里会明确写出三个设备各自落在了哪里。原因程序在推理后会校验输入、模型、输出三者是否同时位于npu:0见 inference.py 中的设备一致性检查。只要有任何一个落在cpu上就判定为设备不匹配。✅ 最快的 3 步排查方法检查设备可见性环境变量执行echo $ASCEND_RT_VISIBLE_DEVICES以及其他ASCEND_*变量。入口脚本从不读取、删除或改写这些变量如果它们被外部限制逻辑设备npu:0可能不可见。确认代码显式指定了 npu:0程序使用DEVICE npu:0显式定位逻辑设备不要手工改成cuda或cpu也不要依赖默认设备。重启干净环境如有残留的 CUDA 相关设置或旧进程占用可先退出旧会话、重新开终端加载 CANN 环境再试。4. 报错三模型没有落到 npu:0 上典型现象RuntimeError: model did not land on npu:0 (got cpu)。原因模型加载后_ttm_common.py 中的load_model(devicenpu:0)负责把模型移动到 NPU。若这一步失败通常意味着 NPU 后端在加载阶段尚未生效。✅ 处理方法这种情况基本是报错二的前置版本——先把第 3 节的设备可见性检查做完再确认import torch_npu正常注册了 npu 后端然后重新运行即可。加载路径、模型快照均固定在 model/ 目录全程无需任何网络访问。5. 一切正常时的成功输出长这样排障完成后运行python3 inference.py应看到如下结果来自仓库真实 NPU 运行记录INPUT_DEVICEnpu:0 MODEL_DEVICEnpu:0 OUTPUT_DEVICEnpu:0 CPU_FALLBACKfalse OUTPUT_FINITEtrue FORECAST[-1.143884, -1.300210, ...] forecast_shape(1, 30, 1) INFER_MEDIAN_MS31.364211 EXIT_CODE0四个设备标记全部为npu:0、CPU_FALLBACKfalse、EXIT_CODE0说明模型已在昇腾 NPU 上完成推理输入形状(1, 512, 1)输出 30 步点预测(1, 30, 1)单次前向中位耗时约 31ms。6. 3 分钟速查清单现象先查什么最快修复CPU_FALLBACKtruenpu-smi infosource CANN 环境变量提示命令找不到which npu-smi安装/加载 CANN 8.5.1device mismatchecho $ASCEND_RT_VISIBLE_DEVICES清理设备可见性变量model did not land on npu:0pip show torch_npu对齐 torch/torch_npu 版本输出全为cpu检查 Python 环境用同一个 venv 运行结语ttm-r3-npu 的报错设计其实很友好——所有关键信息都印在终端里CPU_FALLBACK、三个*_DEVICE标记和明确的RuntimeError文案。遇到 NPU 不可用或设备不匹配时按上面的速查清单从npu-smi、CANN 环境变量、torch_npu 版本、Python 环境四项逐一核对绝大多数问题都能在 3 分钟内解决。更详细的交付说明、环境依赖与实测数据可查阅仓库内的 README.md 和 requirements.txt。【免费下载链接】ttm-r3-npu项目地址: https://ai.gitcode.com/atlasleong/ttm-r3-npu创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考