资源监控体系：利用npu-smi实现硬件状态实时可视化

在高性能计算领域，盲目运行模型无异于蒙眼狂奔。无论是排查 DeepSeek 的性能瓶颈，还是保障生产环境的稳定性，掌握 NPU 的实时状态是必修课。npu-smi是昇腾系统自带的命令行工具，对标 NVIDIA 的nvidia-smi，但其功能覆盖了从芯片状态、显存带宽到互联拓扑的全维度监控。

本篇不谈虚的，直接拆解如何利用npu-smi及其周边工具，建立一套可视化的硬件监控体系。

1. 命令行实战：从入门到精通

1.1 全局概览：读懂 Dashboard

最常用的命令是npu-smi info。它展示了当前服务器上所有 NPU 的核心指标。

$ npu-smi info +------------------------------------------------------------------------------------------------+|NPU Name Health Power(W)Temp(C)Hugepages-Usage(page)||Chip Device Bus-Id AICore(%)Memory-Usage(MB)|+================================================================================================+|0910B OK300.5450/0||000000:C110032768/65536|+================================================================================================+

关键指标解读：

Health：OK是唯一可接受的状态。出现Warning或Error（如 ECC 错误、温度过高）时，推理服务通常会不可预测地崩溃。
Power(W)：910B 单卡满载功耗约 350W-400W。如果你的 DeepSeek-67B 推理时功耗只有 100W，说明计算单元在空转，瓶颈卡在了数据搬运或 CPU 调度上。
AICore(%)：核心算力利用率。
- 理想状态：Prefill 阶段瞬间飙升至 90%-100%，Decode 阶段维持在 60%-80%。
- 异常状态：长期维持在 10%-20%。这通常意味着 Python 层的 Overhead 太大，或者 Kernel Launch 速度太慢，NPU 大部分时间在“等米下锅”。
Memory-Usage：显存占用量。注意，这里显示的是申请量（Reserved），而非实际使用量（Allocated）。PyTorch 的缓存分配机制会让这个数值通常较高。

1.2 进阶诊断：查带宽、查频率、查拓扑

静态信息不够用，我们需要深入肌理。npu-smi info -t <type>参数是解剖 NPU 的手术刀。

场景一：模型推理慢，怀疑显存带宽瓶颈
DeepSeek 的 Decode 阶段是典型的 Memory-Bound。查看显存带宽利用率：

# 查询设备 0 的显存统计信息npu-smi info -t memory -i0

重点关注HBM Read/Write Bandwidth。如果带宽利用率长期打满（接近 1.2TB/s），说明算力再强也没用，必须上量化（W8A8）或优化 KV Cache。

场景二：多卡并行训练/推理卡顿
8 卡部署 DeepSeek-67B 时，卡间通信（HCCS）是生命线。

# 查询网络健康状态npu-smi info -t network -i0

检查Link Status是否全为UP。任何一个 Link Down 都会导致集合通信（AllReduce）超时。

场景三：怀疑过热降频
如果机房散热不佳，NPU 温度超过阈值（通常 75℃+）会触发热保护降频。

# 查询功率和频率信息npu-smi info -t pm -i0

对比当前的AI Core Frequency和额定频率。如果频率大幅跳水，请立即检查风扇转速和散热风道。

2. 实时监控模式：捕捉瞬态异常

npu-smi默认只是快照。要观察推理过程中的脉冲波动，需要高频采样。

2.1 简易看板：Watch

Linux 的watch命令是穷人的仪表盘。

# 每 0.5 秒刷新一次，高亮变化部分watch-n0.5-d npu-smi info

技巧：在压测 DeepSeek 时，盯着 AICore 利用率。

锯齿状波动：正常。对应 Token 生成的计算脉冲。
长直线：异常。说明程序卡死（Hang）或在进行极慢的 CPU 处理（如 Tokenizer 慢、磁盘 IO 慢）。

2.2 抓取 ECC 错误

硬件故障往往是静默的。如果你发现模型输出乱码或 Loss 不收敛，检查一下是否有不可纠正的 ECC 错误。

npu-smi info -t error -i0

关注Double Bit Error计数。如果不为 0，这块卡可能物理损坏了，建议尽快下线报修。

3. 生产级监控方案：Prometheus + Grafana

在几十上百张卡的集群中，靠 SSH 盯着命令行是不现实的。我们需要将 NPU 状态接入标准的云原生监控体系。

3.1 架构设计

Data Source:npu-smi（底层数据源）。
Collector:ascend_exporter（运行在每台服务器上的 Daemon）。
Storage: Prometheus（时序数据库）。
UI: Grafana（可视化面板）。

3.2 编写轻量级 Exporter

虽然华为提供了官方的 exporter，但为了轻量化部署，我们可以写一个 Python 脚本，解析npu-smi info -j（JSON 格式输出，CANN 7.0+ 支持）并暴露 Metrics。

importtimeimportjsonimportsubprocessfromprometheus_clientimportstart_http_server,Gauge# 定义核心指标NPU_TEMP=Gauge('npu_chip_temperature','NPU Temperature',['device_id'])NPU_POWER=Gauge('npu_chip_power','NPU Power Consumption',['device_id'])NPU_AICORE=Gauge('npu_aicore_utilization','NPU AICore Utilization',['device_id'])NPU_MEM_USED=Gauge('npu_memory_used_mb','NPU Memory Used',['device_id'])NPU_MEM_TOTAL=Gauge('npu_memory_total_mb','NPU Memory Total',['device_id'])defcollect_metrics():try:# 获取 JSON 格式的详细信息（需 CANN 版本支持，否则需正则解析文本）# 实际命令可能因版本差异需调整，此处演示逻辑cmd=["npu-smi","info","-j"]# 注意：部分旧版本不支持 -j，需 fallback 到文本解析result=subprocess.check_output(cmd,stderr=subprocess.STDOUT)data=json.loads(result)fordeviceindata['devices']:dev_id=str(device['id'])# 提取指标NPU_TEMP.labels(dev_id).set(device['temperature'])NPU_POWER.labels(dev_id).set(device['power'])NPU_AICORE.labels(dev_id).set(device['aicore_utilization'])# 显存单位转换mem_info=device['memory']NPU_MEM_USED.labels(dev_id).set(mem_info['memory_usage'])NPU_MEM_TOTAL.labels(dev_id).set(mem_info['total_memory'])exceptExceptionase:print(f"Error collecting metrics:{e}")if__name__=='__main__':# 启动 HTTP 服务，端口 9100start_http_server(9100)print("NPU Exporter running on :9100")whileTrue:collect_metrics()time.sleep(5)# 5秒采集一次，避免对 NPU 造成查询压力

3.3 Grafana 面板配置建议

在 Grafana 中，建议配置以下几个 Panel：

Cluster Heatmap：显示整个集群所有卡的 AICore 利用率热力图。一眼识别出哪台机器是“摸鱼”的。
Throttling Alerts：配置告警规则，当npu_chip_temperature > 70持续 1 分钟时，发送钉钉/Slack 告警。
Memory Leak Detection：绘制显存使用率曲线。如果曲线呈现“只升不降”的阶梯状，大概率是代码里有 Tensor 没释放。