2026/5/13 14:29:49
网站建设
项目流程
想做一个公司的网站去哪可以做,网站移动转换,汕头市企业网站建设哪家好,做推送封图的网站在高性能计算领域#xff0c;盲目运行模型无异于蒙眼狂奔。无论是排查 DeepSeek 的性能瓶颈#xff0c;还是保障生产环境的稳定性#xff0c;掌握 NPU 的实时状态是必修课。npu-smi 是昇腾系统自带的命令行工具#xff0c;对标 NVIDIA 的 nvidia-smi#xff0c;但其功能覆…在高性能计算领域盲目运行模型无异于蒙眼狂奔。无论是排查 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|关键指标解读HealthOK是唯一可接受的状态。出现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 简易看板WatchLinux 的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 -jJSON 格式输出CANN 7.0 支持并暴露 Metrics。importtimeimportjsonimportsubprocessfromprometheus_clientimportstart_http_server,Gauge# 定义核心指标NPU_TEMPGauge(npu_chip_temperature,NPU Temperature,[device_id])NPU_POWERGauge(npu_chip_power,NPU Power Consumption,[device_id])NPU_AICOREGauge(npu_aicore_utilization,NPU AICore Utilization,[device_id])NPU_MEM_USEDGauge(npu_memory_used_mb,NPU Memory Used,[device_id])NPU_MEM_TOTALGauge(npu_memory_total_mb,NPU Memory Total,[device_id])defcollect_metrics():try:# 获取 JSON 格式的详细信息需 CANN 版本支持否则需正则解析文本# 实际命令可能因版本差异需调整此处演示逻辑cmd[npu-smi,info,-j]# 注意部分旧版本不支持 -j需 fallback 到文本解析resultsubprocess.check_output(cmd,stderrsubprocess.STDOUT)datajson.loads(result)fordeviceindata[devices]:dev_idstr(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_infodevice[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(fError 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 中建议配置以下几个 PanelCluster Heatmap显示整个集群所有卡的 AICore 利用率热力图。一眼识别出哪台机器是“摸鱼”的。Throttling Alerts配置告警规则当npu_chip_temperature 70持续 1 分钟时发送钉钉/Slack 告警。Memory Leak Detection绘制显存使用率曲线。如果曲线呈现“只升不降”的阶梯状大概率是代码里有 Tensor 没释放。4. 总结数据驱动决策资源监控不是为了画漂亮的图表而是为了回答三个核心问题稳定性硬件健康吗有没有 ECC 错误或高温降频效率算力跑满了吗AICore 是不是在等待 IO容量还能塞下更大的 Batch Size 吗显存还有多少余量对于 DeepSeek 这样的大模型应用稳定性 性能。建议将npu-smi的健康检查集成到服务启动脚本Entrypoint中启动前自检不健康直接退出避免将流量引入故障节点。这才是生产环境的生存之道。