跳转至

基于 MindStudio Insight 定位集群快慢卡问题

案例背景

在分布式训练或多卡推理场景中，集群整体性能通常受最慢的 Rank 影响。当部分 Rank 的计算、通信或 Host 侧下发节奏明显慢于其他 Rank 时，快卡会在同步点等待慢卡，表现为通信等待时间升高、Step 耗时变长、集群吞吐下降。

快慢卡问题的根因可能来自负载不均、通信链路异常、Host 侧下发瓶颈、并行策略配置不匹配或输入数据分布差异。单独查看某一张卡的 Timeline 往往只能看到局部现象，需要结合概览（Summary）、通信（Communication）和时间线（Timeline）逐层缩小范围。

本案例以“Summary 发现卡间性能差异 → Communication 定位等待/同步异常 → Timeline 对比快慢卡 → 判断慢卡负载偏高”为主线，介绍使用 MindStudio Insight 定位集群快慢卡问题的分析方法。

分析方法论

集群快慢卡问题建议按照“先看全局、再拆通信域、最后到 Timeline 定点验证”的顺序分析：

  1. 在概览界面定位异常 Rank：通过热力图、耗时占比和折叠视图快速发现计算、通信、调度或空闲时间明显异常的 Rank。
  2. 在概览、通信界面确认同步等待：查看通信耗时、等待或同步时间、传输时间占比，判断性能劣化是否与特定通信域或通信算子相关。
  3. 跳转到时间线界面对比快慢卡：选择同一 Step 内的快卡和慢卡，置顶关键泳道，对比计算、通信和空泡分布。
  4. 框选统计和下发追溯：对异常时间段执行框选统计，比较硬件任务数量、算子耗时和下发链路，定位是否存在负载不均或 Host 侧瓶颈。
  5. 结合模型逻辑验证根因：回到并行策略、数据划分、算子分布和业务代码，确认异常负载是否符合预期，以及是否可以规避。

数据准备

分析前需要导入集群场景性能数据。若数据目录中包含 cluster_analysis_output，MindStudio Insight 会读取其中的集群分析结果；若不包含该目录，工具会在导入时生成相应的集群分析结果。

进行分析前建议确认以下信息：

  • 性能数据覆盖了问题发生的 Step 或时间段。
  • 并行策略参数与模型实际训练或推理配置一致，例如 DP、TP、PP 等维度配置。
  • Rank 与物理节点、设备之间的映射关系明确，便于后续判断慢卡是否集中在某个节点或通信域。
  • 如果是大规模集群数据，优先使用折叠视图或精简数据进行全局定位，避免直接在全量数据中逐卡排查。

步骤一：在概览界面识别异常 Rank

导入集群数据后，先进入概览（Summary）界面观察集群整体性能。概览界面适合快速横向比较不同 Rank 的计算、通信和调度耗时。

图 1 概览界面

重点关注以下现象：

  • 某些 Rank 的 计算时间占比明显高于其他 Rank。
  • 某些 Rank 的 空闲时间或调度时间占比较高，说明可能存在 Host 侧下发瓶颈。
  • 某些通信域下的 平均通信时间波动较大，说明可能存在通信不同步。
  • 热力图中少数 Rank 的颜色明显偏离其他 Rank，说明该指标存在离群点。

当出现通信时间波动时，需要区分“慢卡”和“等待慢卡的快卡”：

  • 慢卡通常表现为计算或下发耗时偏高，自身通信时间占比不一定最高。
  • 快卡可能较早完成计算，但在集合通信同步点等待慢卡，因此等待或同步时间升高。

因此，不能仅凭通信算子总耗时最长就直接判断该 Rank 是根因 Rank，需要结合计算、空闲和等待时间一起分析。

步骤二：在概览、通信界面确认异常通信域

进入通信（Communication）界面后，围绕异常 Step 或异常 Rank 查看通信矩阵和通信耗时分析。

建议按以下顺序分析：

  1. 概览页面查看全网链路展示，确认是否存在慢链路或慢节点。
  2. 点击通信域连线，观察计算/通信概览中的传输时间、等待或同步时间占比。
  3. 右键通信域连线，进入特定通信域的通信耗时分析。
  4. 对比同一通信域内不同 Rank 的通信时间。

图 2 按通信域拆解后的计算/通信概览

图 3 通信耗时分析

若某个通信域中大部分 Rank 的等待或同步时间升高，而少数 Rank 的计算或下发耗时偏高，通常说明该通信域内存在快慢卡问题。此时可以从通信界面跳转到时间线界面，定位异常通信算子所在的具体时间范围。

步骤三：在时间线界面对比快卡和慢卡

在 Timeline 中选择同一 Step 的快卡和慢卡进行对比。建议将以下泳道置顶，便于横向观察：

  • Overlap Analysis 泳道：观察计算与通信任务是否充分重叠。
  • Communication 泳道：观察通信算子、Notify Wait 等同步等待事件。
  • Ascend Hardware 相关泳道：观察硬件任务数量和执行时长。
  • Host 侧 API 或下发相关泳道：观察算子下发节奏，是否存在明显空泡。

图 4 置顶对比慢卡与快卡的 Overlap Analysis 泳道

对比时重点观察：

  • 慢卡是否存在更多计算算子或更长的计算任务。
  • 快卡是否在通信同步点出现长时间等待。
  • 慢卡的 Host 侧下发是否出现明显间隙，导致 Device 侧空泡。
  • 同一时间段内，不同 Rank 的硬件任务数量是否存在明显差异。

如果慢卡在异常 Step 中承载了更多计算算子，或某些算子执行时间显著长于其他 Rank，则优先怀疑负载不均。如果各 Rank 计算负载接近，但某些 Rank 的下发间隙更大，则优先排查 Host Bound 或调度问题。

步骤四：框选统计定位负载差异

在 Timeline 中对异常时间段执行框选统计，分别统计快卡和慢卡的硬件任务数量、算子耗时和通信等待时间。

图 5 框选统计

典型判断方式如下：

  • 负载不均：慢卡算子数量更多，或关键计算算子耗时显著更长；快卡主要表现为等待同步。
  • Host 侧下发瓶颈：慢卡 Device 侧存在空泡，Host 侧 API 或下发链路之间存在明显间隔。
  • 通信链路异常：计算负载接近，但特定 Rank 或通信域的传输时间明显更长。
  • 并行策略不匹配：异常 Rank 分布与 DP、TP、PP 等并行域划分相关，且异常集中在某一通信域或某类并行组内。

如果工具支持 async_npu 下发连线，可以进一步从硬件任务追溯到对应的 Python API，确认异常任务来自哪段模型代码或数据处理逻辑。

分析结论示例

在本案例中，概览界面显示某些 Rank 的计算耗时和空闲时间占比高于其他 Rank；通信界面显示对应通信域存在较高等待或同步时间；Timeline 对比后发现慢卡在异常 Step 内承载了更多计算算子，快卡则在集合通信同步点等待。

因此，该问题属于典型快慢卡问题，直接原因是卡间负载不均，慢卡计算完成时间晚于其他 Rank，导致集群整体 Step 时间被慢卡拉长。

优化建议

针对负载不均导致的快慢卡问题，可从以下方向优化：

  • 检查数据划分逻辑，避免某些 Rank 长期处理更大 batch、更长序列或更复杂样本。
  • 检查模型并行策略，确认 DP、TP、PP 等配置与实际训练或推理任务一致。
  • 对负载明显偏高的算子，和模型开发人员确认是否存在条件分支、动态 shape、冗余计算或不均衡专家路由。
  • 若异常集中在 Host 侧下发，参考 Host Bound 问题定位方法继续分析 CPU 调度和算子下发链路。
  • 若异常集中在通信链路，继续在通信界面分析具体通信域、通信算子和链路传输效率。

优化后建议重新采集相同场景下的 Profiling 数据，对比优化前后的 Summary、Communication 和 Timeline，确认慢卡计算耗时下降、等待或同步时间缩短，且各 Rank 的 Step 节奏趋于一致。

参考信息