RAS¶

自 NCCL 2.24 起，可靠性、可用性和可维护性 (RAS) 子系统可用于在执行期间查询 NCCL 作业的健康状况。这可以帮助诊断和调试崩溃和挂起。RAS 是一种低开销的基础架构，NCCL 用户和开发人员可以在应用程序运行时使用。它提供了正在运行的应用程序状态的全局视图，并可以帮助检测异常值，例如无响应的进程。有了这些信息，用户可以通过其他技术（例如交互式调试、系统日志分析等）缩小对可疑根本原因的范围。

操作原理¶

RAS 内置于 NCCL 中，并在 NCCL 初始化期间启动。它由一组线程（每个进程一个）组成，这些线程相互建立连接，形成一个网络，RAS 线程然后使用该网络交换信息并监视彼此的健康状况。在典型配置中，RAS 网络流量（在 NCCL 在初始化期间使用的引导/带外网络接口之上使用普通 TCP/IP 套接字）不应与主要的 NCCL 流量（使用 RDMA 网络）竞争。RAS 是轻量级的，不应干扰主要的 NCCL 作业；因此，默认情况下启用它（但请参阅 NCCL_RAS_ENABLE）。

RAS 线程相互通信有关作业配置的任何更改；他们还交换定期的保持活动消息。如果 NCCL 进程崩溃或挂起，则在其他 NCCL 进程上运行的 RAS 线程会通过与该进程的 RAS 网络连接关闭或变得无响应来了解它。

RAS 查询¶

RAS 线程还在 localhost，端口 28028 上侦听客户端连接（可以使用 NCCL_RAS_ADDR 更改这些默认值）。ncclras 二进制客户端可用于连接到该套接字并查询 RAS 子系统以获取当前的作业状态，然后将其打印到标准输出。客户端接受 -h 和 -p 参数来指定主机名和端口，-v 在出现问题时生成更详细的输出，以及 -t 来指定不同的超时时间（默认 5 秒；0 禁用超时）。

由于客户端通信协议是完全基于文本的，因此可以使用 telnet 或 netcat 等标准网络工具来代替 ncclras 二进制文件。相关命令包括 STATUS、VERBOSE STATUS（等效于 ncclras 客户端的 -v 参数）和 TIMEOUT <seconds>（等效于 -t）；例如，echo verbose status | nc localhost 28028。

无论如何提交查询，接收 RAS 线程都会发回作业摘要信息以及有关所有 NCCL 通信器的摘要信息；后者是从所有作业进程收集的，因此，对于遇到问题的作业或特别大的作业，响应可能需要几秒钟才能生成。如果遇到任何问题，则会提供其他信息。

示例输出¶

本节包含 RAS 状态输出的摘录。请注意，预计可用信息的具体格式和范围会不断发展；提供的摘录仅用于说明目的。

这是一个来自正常进行中的作业的示例输出

Job summary
===========

  Nodes  Processes         GPUs  Processes     GPUs
(total)   per node  per process    (total)  (total)
      4          8            1         32       32

我们有一个由 32 个 GPU（每个进程 1 个 GPU）组成的作业在 4 个节点上运行。

Communicators... (0.00s)
=============

Group     Comms     Nodes     Ranks     Ranks     Ranks    Status  Errors
    #  in group  per comm  per node  per comm  in group
    0         8         4         1         4        32   RUNNING      OK

GPU 被分成 8 个通信器，每个节点 1 个 GPU。RAS 尝试通过将具有相同大小和其他重要属性的对象组合在一起来使摘要输出尽可能简短。

对于在 RAS 查询期间正在积极通信的作业，有时可以观察到以下输出

Group     Comms     Nodes     Ranks     Ranks     Ranks    Status  Errors
    #  in group  per comm  per node  per comm  in group
    0         1         4         8        32        32   RUNNING  MISMATCH

输出表明不同通信器 rank 提供的信息存在不一致。其他信息打印在下方（在本例中，它在 Warnings 部分，表明潜在的较低严重性）

Warnings
========

#0-0 (27a079b828ff1a75) MISMATCH
  Communicator ranks have different collective operation counts
  26 ranks have launched up to operation 6650
  6 ranks have launched up to operation 6649
  Rank 0 -- GPU 0 managed by process 483072 on node 172.16.64.210
  Rank 2 -- GPU 2 managed by process 483074 on node 172.16.64.210
  Rank 3 -- GPU 3 managed by process 483075 on node 172.16.64.210
  Rank 4 -- GPU 4 managed by process 483076 on node 172.16.64.210
  Rank 5 -- GPU 5 managed by process 483077 on node 172.16.64.210
  Rank 7 -- GPU 7 managed by process 483079 on node 172.16.64.210

通信器使用 #<x>-<y> 标识符引用，其中 <x> 是摘要输出中的组号，<y> 是组内的通信器编号，两者都从 0 开始（在本例中，只有一个（32-GPU）通信器，因此，毫不奇怪，标识符是 #0-0）。标识符后跟一个通信器哈希，这是一个可以在 NCCL 的常规调试输出中找到的值，以及 rank 信息。RAS 将具有相同相关属性的 rank 分组在一起（在本例中是已发出的集合操作的计数）。如果组构成异常值，则 RAS 会打印有关每个组成员的其他信息。默认情况下，如果组大小最多占总数的 25% 且组的成员不超过 10 个，则会执行此操作；启用详细输出会将此限制放宽到总数的 50% 以下，并取消组大小限制。

上面的特定情况不应引起关注，只要计数在重复查询中增加即可。NCCL 集合操作经过速度优化，可以轻松超越 RAS 集合查询，特别是如果集合操作的大小相当小。应用程序也可能表现出工作负载不平衡，某些 rank 通常比其他 rank 更晚到达集合操作 - 需要特定工作负载的经验来确定什么是正常的，什么是不正常的。但是，如果输出在后续 RAS 查询中没有变化，则可能表明通信器由于某种原因“卡住”了，这可能需要进行调查。

在通信器初始化或拆卸期间有时也会观察到类似的效果

Group     Comms     Nodes     Ranks     Ranks     Ranks    Status  Errors
    #  in group  per comm  per node  per comm  in group
    0         1         4       1-2        32        32  FINALIZE  MISMATCH
    1         7         4         1         4        28   RUNNING      OK
    2         1         4         1         4         4      INIT      OK

[...]

#0-0 (9e17999afaa87dbb) MISMATCH
  Communicator ranks have different status
  26 ranks have status UNKNOWN
  4 ranks have status RUNNING
  Rank 0 -- GPU 0 managed by process 507285 on node 172.16.64.210
  Rank 8 -- GPU 0 managed by process 1598388 on node 172.16.64.212
  Rank 16 -- GPU 0 managed by process 3500071 on node 172.16.64.213
  Rank 24 -- GPU 0 managed by process 2405067 on node 172.16.64.222
  2 ranks have status FINALIZE
  Rank 4 -- GPU 4 managed by process 507289 on node 172.16.64.210
  Rank 20 -- GPU 4 managed by process 3500075 on node 172.16.64.213

上面的快照描述了一个过渡情况，因为初始的 32-GPU 通信器正在被八个 4-GPU 通信器取代（其中一个仍在初始化，因此它与已经初始化的七个（组 #1）分开列出（组 #2））。32-GPU 通信器 (#0-0) 正在被拆卸，其中两个 rank 正在 ncclCommFinalize 中，四个 rank 尚未调用 ncclCommFinalize，其余 26 个 rank “未知” - 这意味着当 RAS 收集数据时，他们没有提供有关该通信器的任何信息，仅仅是因为他们对 ncclCommFinalize 的调用已经完成，因此实际上他们不再是该通信器的成员。同样，只要在重复查询时情况得到解决，就可以忽略它。

这是一个在人为地创建一个作业进程问题后的调用摘录

Communicators... (2.05s)
=============

Group     Comms     Nodes     Ranks     Ranks     Ranks    Status  Errors
    #  in group  per comm  per node  per comm  in group
    0         1         4       7-8        32        32   RUNNING  INCOMPLETE

Errors
======

INCOMPLETE
  Missing communicator data from 1 job process
  Process 3487984 on node 172.16.64.213 managing GPU 5

#0-0 (cf264af53edbe986) INCOMPLETE
  Missing communicator data from 1 rank
  The missing rank: 21

Warnings
========

TIMEOUT
  Encountered 2 communication timeouts while gathering communicator data

在这种情况下，摘要需要几秒钟才能生成，因为 RAS 等待来自遇到问题的进程的数据（该进程无响应 - 它已停止 - 但 RAS 尚不知道）。重复查询应该快得多，因为一旦 RAS 确定进程无响应，它就会重新配置 RAS 网络以绕过它。

RAS 将尝试重新建立与无响应进程的通信；如果它在 60 秒内无法做到这一点，它将声明该进程已死（永久地）

Errors
======

DEAD
  1 job process is considered dead (unreachable via the RAS network)
  Process 3487984 on node 172.16.64.213 managing GPU 5

#0-0 (cf264af53edbe986) INCOMPLETE
  Missing communicator data from 1 rank
  The missing rank: 21

RAS 将简单地停止尝试通过 RAS 网络与此类进程进行通信，让用户来确定是否需要采取任何其他操作。