昇腾NPU运维故障排查实战：npu-smi诊断、训练卡死、通信异常处理

昇腾 NPU 的故障排查与 NVIDIA GPU 有较大差异：工具链不同（npu-smi vs nvidia-smi）、日志路径不同、通信协议不同（HCCS vs NVLink/NCCL）。本文总结生产环境中最常见的昇腾 NPU 故障场景及排查方法。

故障排查思路总览

昇腾故障分类：

1. 硬件层：
   - NPU 设备未识别、健康状态异常
   - 温度过高触发降频
   - HBM 显存错误（ECC）
   - HCCS 互联故障

2. 驱动/固件层：
   - 驱动未加载或版本不匹配
   - 固件升级后不兼容

3. CANN 层：
   - 算子未实现（fallback CPU）
   - 内核编译失败

4. 框架层（torch_npu）：
   - 版本不匹配
   - 算子错误、精度异常

5. 任务层：
   - 训练卡死（利用率为 0）
   - 多卡通信超时
   - 显存溢出（OOM）

一、npu-smi 深度使用

# === 基础信息查看 ===

# 查看所有 NPU 概览（类似 nvidia-smi 无参数）
npu-smi info

# 持续监控（每 2 秒刷新）
watch -n 2 npu-smi info

# 查看指定 NPU 的详细信息
npu-smi info -i 0 -t common      # AICore 利用率、显存、频率
npu-smi info -i 0 -t memory      # 显存详情
npu-smi info -i 0 -t temp        # 温度（各部件）
npu-smi info -i 0 -t power       # 功耗
npu-smi info -i 0 -t board       # 硬件信息（序列号、固件版本）
npu-smi info -i 0 -t ecc         # ECC 错误统计
npu-smi info -i 0 -t link-info   # HCCS 互联状态

# 查看运行中的进程
npu-smi info -t proc
# Chip ID  PID      Process Name                Memory(MB)
# 0        12345    python3                      45678

# 查看所有 NPU 的健康状态（自动化巡检用）
for i in $(seq 0 7); do
  status=$(npu-smi info -i $i -t board 2>/dev/null | grep "Health" | awk '{print $2}')
  echo "NPU $i: $status"
done

# 导出所有 NPU 状态到文件（发给华为支持时用）
npu-smi info -f /tmp/npu_status_$(date +%Y%m%d%H%M%S).txt

# === 关键指标阈值 ===
# 温度：正常 < 75°C，警告 75-85°C，危险 > 85°C（触发降频）
# AICore 利用率：训练时应 > 50%（低于 30% 需排查）
# 显存使用：不应超过 95%（留 5% buffer 防 OOM）
# 功耗：910B 单卡 < 350W，服务器总功耗需提前确认

二、训练任务卡死排查

最常见的故障之一：训练启动后利用率为 0，日志无报错，任务卡着不动。

# 步骤1：确认 AICore 利用率真的为 0
watch -n 1 'npu-smi info -i 0 -t common | grep AICore'
# AICore(%)    0   ← 训练中应该是 40-90%+

# 步骤2：查看进程是否存在
ps aux | grep python
npu-smi info -t proc
# 如果进程存在但利用率 0 → 任务卡在等待（数据加载？通信等待？）

# 步骤3：查看 Python 进程的栈（找到卡在哪里）
# 获取 PID
PID=$(npu-smi info -t proc | grep python | awk '{print $2}' | head -1)
# 打印 Python 栈信息
kill -SIGUSR1 $PID    # 发送信号让 Python 打印堆栈（如果程序支持）
# 或者使用 py-spy
pip install py-spy
py-spy dump --pid $PID

# 步骤4：检查是否卡在数据加载（DataLoader）
# 如果 py-spy 输出显示卡在 DataLoader 的 __iter__ → 数据 I/O 瓶颈
# 解决：增加 num_workers，或检查存储 I/O 性能

# 步骤5：检查是否卡在集合通信（多卡训练）
# 查看通信相关日志
tail -f /var/log/mindx-dl/*.log | grep -E "timeout|HCCL|error"

三、HCCS 集合通信异常

多卡训练时，卡间通信使用昇腾专有的 HCCS（Huawei Collective Communication System，类似 NCCL）。

# 检查 HCCS 链路状态
npu-smi info -i 0 -t link-info
# Link Status:
#   HCCS Link 0: UP   ← 正常
#   HCCS Link 1: DOWN ← 链路故障！

# 检查卡间 P2P 连通性
python3 << 'EOF'
import torch
import torch_npu

num_npus = torch.npu.device_count()
print(f"NPU 数量: {num_npus}")

# 测试所有卡对之间的 P2P 传输
for src in range(num_npus):
    for dst in range(num_npus):
        if src != dst:
            try:
                x = torch.randn(1000, 1000).to(f"npu:{src}")
                y = x.to(f"npu:{dst}")
                print(f"NPU {src} → NPU {dst}: OK")
            except Exception as e:
                print(f"NPU {src} → NPU {dst}: FAIL - {e}")
EOF

# 查看 HCCL 通信日志
find /var/log -name "hccl*" -newer /var/log/lastlog 2>/dev/null | head -10
cat /var/log/mindx-dl/hccl_*.log 2>/dev/null | tail -50

# 典型 HCCS 通信超时报错：
# [ERROR] HCCL: HcclCommInitRootInfo failed, error code: 0x03
# 原因：通常是某张卡故障或 HCCS 线缆问题
# 排查：逐步减少卡数（从 8 卡 → 4 卡 → 2 卡 → 1 卡）定位故障卡

# 隔离故障卡（环境变量方式）
export ASCEND_VISIBLE_DEVICES=0,1,2,3,5,6,7  # 排除 NPU 4

四、显存溢出（OOM）处理

# 昇腾 OOM 报错特征
# RuntimeError: NPU out of memory. Tried to allocate XXX MiB
# 或者：
# EI9999: Inner Error, error info: ASCEND_OOM

# 查看显存使用详情
npu-smi info -i 0 -t memory
# HBM Usage(MiB): 61440 / 65536   ← 已用 / 总量

# 释放未使用的显存
python3 -c "
import torch
import torch_npu
torch.npu.empty_cache()
print('显存缓存已清理')
"

# 找到 OOM 前的状态（昇腾的显存快照）
# 在代码中添加显存跟踪
import torch_npu
torch.npu.memory._record_memory_history()
# 触发 OOM 后：
torch.npu.memory._dump_snapshot('npu_memory_snapshot.pkl')

# 显存优化技巧（昇腾特有）
import torch
import torch_npu

# 1. 减少显存碎片
torch.npu.set_per_process_memory_fraction(0.85)  # 最多用 85%

# 2. 梯度检查点（减少激活内存）
from torch.utils.checkpoint import checkpoint

# 3. 昇腾特有：关闭 ATB 算子的显存预分配
import os
os.environ['PYTORCH_NPU_ALLOC_CONF'] = 'max_split_size_mb:128'

五、NPU 设备故障隔离

# 场景：NPU 3 出现 ECC 错误，需要隔离
npu-smi info -i 3 -t ecc
# ECC Error Count:
#   Single Bit Error: 0
#   Double Bit Error: 5   ← 双 bit 错误，硬件故障！

# 步骤1：将该节点从 K8s 移除（驱逐 Pod）
kubectl drain gpu-node-01 --ignore-daemonsets --delete-emptydir-data

# 步骤2：标记节点不可调度
kubectl cordon gpu-node-01

# 步骤3：通过环境变量屏蔽故障 NPU（容器层面）
# 让其他 NPU 继续工作
export ASCEND_VISIBLE_DEVICES=0,1,2,4,5,6,7   # 排除 NPU 3

# 步骤4：通知华为支持，提供诊断信息
# 收集诊断包
npu-smi info -f /tmp/npu_diag.txt
journalctl -u containerd --since "1 hour ago" > /tmp/containerd.log
dmesg | grep -i "ascend\|npu\|error" > /tmp/dmesg.log
tar -czf npu_support_$(hostname)_$(date +%Y%m%d).tar.gz \
    /tmp/npu_diag.txt /tmp/containerd.log /tmp/dmesg.log \
    /var/log/mindx-dl/

# 步骤5：NPU 修复后解除隔离
kubectl uncordon gpu-node-01

六、日志收集体系

# 昇腾相关日志路径总览
/var/log/mindx-dl/           # MindX DL 主日志目录
  ├── devicePlugin/          # Device Plugin 日志
  ├── hccl/                  # 集合通信日志
  └── ascenddk/              # 底层 SDK 日志

/var/log/npu/                # 驱动日志
/proc/driver/npu/            # NPU 驱动 proc 信息

# 关键日志过滤
grep -rE "ERROR|FATAL|OOM" /var/log/mindx-dl/ | tail -50

# 实时追踪训练日志
tail -f /var/log/mindx-dl/hccl/*.log | grep -v DEBUG

# 自动化健康检查脚本
cat << 'EOF' > /usr/local/bin/npu-health-check.sh
#!/bin/bash
echo "=== NPU Health Check $(date) ==="
for i in $(seq 0 7); do
  if npu-smi info -i $i &>/dev/null; then
    STATUS=$(npu-smi info -i $i -t board 2>/dev/null | grep -oP 'Health\s+\K\w+')
    TEMP=$(npu-smi info -i $i -t temp 2>/dev/null | grep "Die" | awk '{print $NF}')
    AICORE=$(npu-smi info -i $i -t common 2>/dev/null | grep "AICore" | awk '{print $2}')
    echo "NPU $i: Health=$STATUS Temp=${TEMP}°C AICore=${AICORE}%"
  fi
done
echo "=== End Check ==="
EOF
chmod +x /usr/local/bin/npu-health-check.sh

# 加入 cron，每 5 分钟检查一次
echo "*/5 * * * * root /usr/local/bin/npu-health-check.sh >> /var/log/npu-health.log 2>&1" > /etc/cron.d/npu-health

小结

昇腾 NPU 运维的故障排查核心工具是 npu-smi，重点关注三个维度：AICore 利用率（训练中应 > 50%，否则找卡点）、健康状态（非 OK 立即隔离）、ECC 错误计数（双 bit 错误 = 硬件故障，必须更换）。多卡训练的 HCCS 通信问题最难排查，方法是逐步二分减少卡数来定位故障卡。生产环境建议建立 NPU 健康检查定时任务 + Prometheus 告警双保险，确保 NPU 异常能在 5 分钟内被发现，而不是等训练任务挂掉后才知道。