mx-smi dmon 日志攻略

MX-SMI dmon 日志阅读指南：以 MoE benchmark 监控日志为例

0. 这份日志是什么

本文总结如何阅读下面这类 mx-smi dmon 监控日志：

mx-smi dmon --show-temperature --show-board-power --show-usage --show-memory \
  -i 0 -l 1000 -c 120 \
  > artifacts/metrics/moe_mxsmi_dmon_manual.log 2>&1

这类日志的作用是：在 MoE benchmark 运行期间，以固定时间间隔记录 C500 GPU 的系统级状态，包括温度、板卡功耗、GPU 使用率、视频编解码单元使用率、显存使用率、系统内存相关使用率。

它适合回答：

这个 workload 是否真的跑到了 GPU 上？
GPU 在运行期间是否被压起来？
显存有没有明显申请和释放？
温度和功耗是否正常？
是否存在明显空闲、等待、初始化或结束阶段？

但它不能直接回答：

哪个 kernel 最慢？
TileLang 的 Step 1 / Step 2 各自耗时多少？
GEMM 是否 lower 到高效 MMA？
HBM 带宽是否打满？
shared memory 是否有 bank conflict？
host 侧同步、kernel launch、临时 buffer 分配各占多少？

这些更细的问题需要 mcTracer、mcProfiler、benchmark 内部计时、kernel timeline 或更细粒度 profiler 配合分析。

---

1. 命令逐项解释

原命令：

cd /data/c500-mxmaca-benchmark
source ./setup_env.sh
mx-smi dmon --show-temperature --show-board-power --show-usage --show-memory \
  -i 0 -l 1000 -c 120 \
  > artifacts/metrics/moe_mxsmi_dmon_manual.log 2>&1

1.1 进入工程目录

cd /data/c500-mxmaca-benchmark

进入 C500 / MXMACA benchmark 工程目录。

1.2 加载环境变量

source ./setup_env.sh

加载当前工程需要的 MXMACA 环境，例如 MACA_PATH、PATH、LD_LIBRARY_PATH、/opt/maca/bin、runtime library 路径等。

1.3 启动 dmon 监控

mx-smi dmon

dmon 可以理解成 device monitor，用于周期性打印 GPU 状态。

1.4 指定监控项

--show-temperature
--show-board-power
--show-usage
--show-memory

分别表示显示温度、板卡功耗、GPU/VPU 使用率、显存/内存使用情况。

1.5 指定设备

-i 0

只监控 GPU 0。

1.6 指定采样间隔

-l 1000

每 1000 ms 采样一次，也就是约每秒输出一行。

1.7 指定采样次数

-c 120

一共采样 120 次。配合 -l 1000，整体监控时长大约是 120 秒。

1.8 保存日志

> artifacts/metrics/moe_mxsmi_dmon_manual.log 2>&1

把标准输出和标准错误都写入同一个日志文件。

---

2. 日志表头怎么看

日志表头类似：

dev die hottemp drmossoctemp drmoscoretemp power gpu vpue vpud visvram vram xtt
idx idx C       C            C             W     %   %    %    %       %    %

字段	单位	含义	阅读重点
dev idx	-	GPU 设备编号	你的日志里全是 0，表示监控 GPU 0
die idx	-	die 编号	你的日志里全是 0
hottemp	℃	芯片热点温度	判断是否有明显热压力
drmossoctemp	℃	供电/DrMOS 相关温度	辅助看供电模块温度
drmoscoretemp	℃	DrMOS core 相关温度	辅助看供电模块温度
power	W	板卡功耗	判断 GPU 是否进入高负载状态
gpu	%	GPU 计算资源使用率	MoE 算子最核心观察列
vpue	%	视频编码器使用率	MoE 一般应为 0
vpud	%	视频解码器使用率	MoE 一般应为 0
visvram	%	可见显存使用率	通常和 vram 一起看
vram	%	板卡显存 / HBM 使用率	判断显存申请、保持、释放
xtt	%	系统内存相关使用率	判断是否使用系统内存方向资源

---

3. 单行日志怎么读

例如一行：

0   0   45      31           31            176   99  0    0    21      21   0

对应解释：

字段	值	解释
dev idx	0	GPU 0
die idx	0	die 0
hottemp	45℃	芯片热点温度 45℃
drmossoctemp	31℃	供电相关温度 31℃
drmoscoretemp	31℃	供电 core 温度 31℃
power	176W	板卡功耗 176W
gpu	99%	GPU 基本被打满
vpue	0%	没有使用视频编码器
vpud	0%	没有使用视频解码器
visvram	21%	可见显存使用率 21%
vram	21%	HBM 显存使用率 21%
xtt	0%	系统内存相关使用率 0%

这类行可以判断：

当前处于 MoE 主计算阶段，GPU 使用率接近 100%，功耗明显升高，显存已申请到峰值，视频编解码单元未参与。

---

4. 读日志的核心方法

阅读 mx-smi dmon 日志时，不要只看某一行，而要看趋势。推荐按下面几个阶段拆。

4.1 空闲基线阶段

典型特征：

gpu   = 0%
power = 55W ~ 60W 左右
vram  = 1% 左右

说明当前 GPU 基本没有计算任务。

4.2 初始化 / 数据准备阶段

典型特征：

gpu   = 0% 或很低
power = 60W ~ 90W
vram  = 从 1% 逐步升到 3%、5%、10%

说明程序在做准备工作，但还没有进入主计算。

可能包括：

• Python 解释器启动
• PyTorch / mcPyTorch 初始化
• MXMACA runtime 初始化
• TileLang JIT / 动态加载
• tensor 创建
• 输入数据准备
• golden 输出准备
• warmup 前准备
• 临时 buffer 分配

4.3 主计算阶段

典型特征：

gpu   = 95% ~ 99%
power = 明显升高，例如 160W ~ 176W
vram  = 稳定在峰值，例如 21%

这说明 workload 已经真正进入 GPU 主计算阶段。

4.4 中间空档阶段

典型特征：

gpu   = 0%
power = 降低
vram  = 仍然保持高位，例如 21%

这说明显存还没有释放，但 GPU 暂时没有计算。

可能原因：

• 两个 benchmark case 之间的间隔
• host 侧同步
• CPU 侧数据处理
• correctness check
• 日志打印
• 下一轮输入准备
• 等待 Python / runtime 调度
• kernel launch 之间的空隙

4.5 二次计算峰值

典型特征：

gpu   = 突然再次升高，例如 80% ~ 95%
power = 再次升高
vram  = 仍然保持高位

说明主计算之后又出现了一段短计算。

4.6 结束 / 释放阶段

典型特征：

gpu   = 0%
power = 回到空闲功耗
vram  = 从高位回到 1%

这说明 workload 结束，显存被释放，GPU 回到空闲状态。

---

5. 结合本次 MoE 日志的实际结论

两份日志：

• moe_mxsmi_dmon_manual.log
• moe_mxsmi_dmon_20260607T090804Z.log

它们形态高度一致。

5.1 第一份日志：moe_mxsmi_dmon_manual.log

项目	结果
采样点数	120
采样间隔	约 1 秒
总监控时长	约 120 秒
hottemp 最小值	37℃
hottemp 最大值	47℃
power 最小值	56W
power 最大值	176W
gpu 最大值	99%
vram 最大值	21%
vpue	全程 0%
vpud	全程 0%
xtt	全程 0%

阶段拆解：

近似时间	现象	判断
0–7s	gpu=0，power≈56W，vram=1%	空闲基线
8–33s	vram 从 3% 升到 10%，GPU 基本很低	初始化、显存申请、数据准备
34s	vram≈19%	主测试前大块显存申请
35–76s	gpu≈98%–99%，power≈168W–176W，vram≈21%	MoE 主计算阶段
77–82s	gpu=0，vram=21%	中间 host 侧空档或 case 间隔
83–88s	gpu≈84%–95%	第二段短计算
89–119s	gpu=0，vram=1%	计算结束，显存释放

核心结论：

这份日志证明 MoE benchmark 的主计算阶段确实运行在 C500 GPU 上，且主计算阶段 GPU 使用率稳定接近 100%。显存峰值为 21%，功耗峰值 176W，热点温度峰值 47℃，未观察到明显热压力。

5.2 第二份日志：moe_mxsmi_dmon_20260607T090804Z.log

项目	结果
采样点数	96
采样间隔	约 1 秒
总监控时长	约 96 秒
hottemp 最小值	36℃
hottemp 最大值	48℃
power 最小值	55W
power 最大值	174W
gpu 最大值	99%
vram 最大值	21%
vpue	全程 0%
vpud	全程 0%
xtt	全程 0%

阶段拆解：

近似时间	现象	判断
0–6s	gpu=0，power≈55W，vram=1%	空闲基线
7–32s	vram 从 3% 升到 10%，GPU 很低	初始化、显存申请、数据准备
33s	vram≈19%	主测试前大块显存申请
34–75s	gpu≈98%–99%，power≈166W–174W，vram≈21%	MoE 主计算阶段
76–80s	gpu=0，vram=21%	中间空档
81–87s	gpu 再次升高	第二段短计算
88–95s	gpu=0，vram=1%	结束并释放显存

核心结论：

第二份日志与第一份日志相互验证：MoE 主计算阶段持续约 40 秒，GPU 使用率接近 100%，功耗稳定在高位，显存峰值约 21%，整体运行状态稳定。

---

6. 如何判断 GPU 是否真的被压起来

可以同时看三列：

gpu
power
vram

正常高负载特征：

gpu   接近 100%
power 明显高于空闲功耗
vram  稳定在较高位置

例如你的日志：

gpu   = 98% ~ 99%
power = 168W ~ 176W
vram  = 21%

这说明：

• GPU 计算资源处于 busy 状态
• 板卡功耗进入高负载区间
• 显存已申请到 workload 所需规模
• MoE benchmark 主体确实跑在 GPU 上

---

7. 如何看显存变化

7.1 vram=21 是 21%，不是 21GB

表头单位是 %：

visvram vram xtt
%       %    %

因此：

vram = 21

表示显存使用率 21%，不是 21GB。

如果 C500 是 64GB HBM，可以粗略估算：

64GB × 21% ≈ 13.4GB

但严谨统计应该用更精确的 memory used / total 指标，不应该只靠百分比估算。

7.2 显存保持高位但 GPU 为 0 说明什么

例如：

gpu  = 0%
vram = 21%

这通常说明：

• GPU 暂时没有计算
• 但程序仍持有 tensor / buffer
• 显存尚未释放
• 可能在做 host 侧处理、同步、日志输出、correctness check 或等待下一阶段

---

8. 这份日志适合放进报告的结论

可以在报告中这样写：

使用 mx-smi dmon 对 MoE benchmark 运行过程进行 1s 粒度系统监控，监控项包括温度、板卡功耗、GPU/VPU 使用率以及显存使用率。日志显示，运行初期 GPU 基本空闲，显存从 1% 逐步上升，对应运行时初始化、输入/输出 tensor 分配和 benchmark 准备阶段；随后显存进一步升至约 21%，GPU 使用率进入 98%–99% 的稳定平台，板卡功耗上升到约 168W–176W，说明 MoE 主计算阶段已充分调度到 C500 GPU 上执行。主计算结束后，GPU 使用率回落至 0%，显存仍短暂保持高位，随后释放回 1%。整个过程中 VPUE/VPUD 为 0，符合 MoE 非视频编解码 workload 的特征；xtt 为 0，说明主要使用板卡 HBM 资源。热点温度峰值约 47℃–48℃，未从该日志中观察到明显热压力。

---

9. 这份日志不能直接证明什么

mx-smi dmon 是系统级监控，不是 kernel profiler。

它不能直接证明：

• 每个 TileLang kernel 的耗时
• Step 1 / Step 2 的耗时占比
• GEMM 是否使用高效 MMA
• HBM 带宽是否达到瓶颈
• shared memory 是否存在 bank conflict
• register pressure 是否过高
• occupancy 是否合理
• kernel launch 开销有多大
• host-device 同步占比是多少
• 临时 buffer 分配是否拖慢端到端时间

所以报告中不要把 dmon 日志写成“kernel 级性能分析”。更准确的定位是：

系统级运行状态证明 + 粗粒度性能现象观察。

---

10. 一句话总结

这类 mx-smi dmon 日志的核心看法是：

先看 GPU、功耗、显存是否同步进入高位，确认 workload 是否真的跑在 GPU 上；再看显存申请和释放判断程序阶段；最后看温度、VPUE/VPUD、xtt 排除明显异常。但它只是系统级粗粒度监控，不能替代 kernel timeline 和 profiler。