NVIDIA 集合通信库 (NCCL) 对于 AI 工作负载中的快速 GPU 到 GPU 通信至关重要，可使用各种优化和调优来提升性能。但是，随着平台的多样化，默认 NCCL 设置可能并不总是能提供最佳结果。本文讨论调优的重要性，以及用户如何使用自定义调优器插件增强性能。它还提供了一个成功重新调整的案例研究。
NCCL 调优概述
当 NCCL 收到要运行的运算时，它必须为以下变量选择正确的值：
- 用于驱动运营的 CTA 数量
- 协议
- 算法
- 数据块大小
为做出这些决策，我们会向其提供以下输入：
- 集合运算
- 消息大小
- Communicator 维度
ncclGroup中的并发运算数- 呈现的缓冲区是否已注册
- 拓扑和图形信息
NCCL 会查看这些输入，并通过内部成本模型和动态调度程序计算感知到的最佳输出。后续章节将提供有关此过程的更多详细信息。
然后，NCCL 将检查调优器插件是否已加载。如果插件已加载，它会为每个操作选择调整属性。此选择内置于计划中，并在提交集合运算之前分解为内核和代理运算。
NCCL 成本模型
NCCL 成本模型是默认调优决策的核心。该模型根据所用时间来评估集合操作的成本。成本模型的目的是选择正确的协议和算法。成本模型会考虑许多因素，包括 GPU、拓扑、网络和算法属性。NCCL 团队继续优化成本模型，为用户提供开箱即用的最佳调优。有关更多详细信息，请参阅 NCCL 文档。
动态调度程序
完成操作队列后，由单独的动态调度算法确定块大小 (缓冲) 和协作线程数组 ( CTA) 数量。需要更多 CTA 来驱动峰值带宽。对于较小的消息大小集合，较小的数据块和较少的 CTA 可以更好地实现更好的工作流和延迟。此外，当许多操作通过 NCCL Group Call 语义并行执行时，这些操作可能需要在更少的 CTA 上进行调度，以允许并行执行。
平台调优变体
NCCL 默认调优会始终尝试做出最佳决策，同时考虑系统和网络的差异。有时，由于网络交换机供应商、虚拟化、CPU 或 PCI 配置等各种因素，需要调整 NCCL 调优以实现最佳性能。当发生这种情况时，覆盖 NCCL 默认调优有助于优化性能。在这些情况下，推荐使用调优插件作为调优变通方法，具体详情请参阅下一节。
调优器插件
推荐使用调优器插件在任何平台上进行现场修复调优。它们提供了一种机制来覆盖成本模型通过插件模型做出的 NCCL 默认调优决策。它们已加载完毕，可面向任何最终用户透明地运行。它们可以灵活地跨任何维度或集合类型进行调整。
通常，集群管理员或平台提供商会维护调优器插件，并以配方形式提供给用户，以确保 NCCL 在其平台上选择最佳调优参数。Tuner 插件在应用中表现出色，因为它们对工作负载是透明的。调谐器插件具有最小接口 (自 NCCL 2.27 起) ，侧重于选择正确的协议和算法，并在必要时覆盖 CTA 计数。
加载调优器插件时，会向其提供 NCCL 维度、等级和上下文对象，以便识别多通信程序中的通信者。调谐器中的主要功能是 getCollInfo，此时操作成本会被覆盖。
getCollInfo 随 NCCL 成本模型预测一起作为提示，调优插件可能会始终选择保留这些默认值。这对于特定算法和协议不兼容或无法在当前拓扑上工作的情况非常重要。这些值将由成本模型设置为 -1.0。推荐使用调优器插件来修复工作负载调优问题。继续阅读以获取实际示例。
如何避免过度调整 NCCL
NCCL 默认 CTA 计数和缓冲区大小经过精心选择，可更大限度地提高端到端工作负载性能。增加这些值通常会带来更好的通信基准性能。但是，优化端到端工作负载不同于单独优化 NCCL。
NCCL 可以同时在多达 64 个 CTA 上运行通信运算 (截至 NCCL 2.27) 。虽然将 NCCL CTA 计数增加到默认值之上通常会提高操作的性能，但这可能会影响工作负载性能。干扰对芯片资源的影响以及 CTA 资源不足会对端到端性能造成严重影响。
NCCL 的设计理念是，只需足够的 CTA，即可在大消息大小下使可用传输的线速饱和，而不是增加。如之前的版本帖子中所述，用户缓冲区注册、集合网络或新的对称内存 API 也有助于使用更少的 CTA 来提高 NCCL 性能。
如果您非常熟悉工作负载配置和空闲 GPU 资源量，欢迎尝试增加 NCCL CTA 和缓冲区大小，看看是否有改进。
解决调优问题
务必要仔细考虑调整是否会给您的特定应用带来问题，以及手动校正是否利大于弊。这样做的好处取决于调整误差的程度，以及该误差对端到端工作负载时间的影响程度。对调优结果的任何选择性覆盖都会造成维护负担，并且可能会阻止未来 NCCL 调优的改进返回到您的工作负载。当这些优设已就绪时，NCCL 的任何默认选择都会被忽略。
如果您发现平台调优存在特定问题，请通过 NVIDIA/nccl GitHub 存储库报告。
调优优设选项
本节介绍可用于覆盖调优的选项。
调优器插件
如上一节所述，推荐使用调优器插件来覆盖调优。
环境变量
NCCL 广泛使用环境变量，允许用户对其进行配置。启用了特殊的环境变量来强制调整库。设置这些值时务必要小心。通常情况下，覆盖其中一个值将有助于解决特定性能问题，但复制并粘贴该变量将阻止 NCCL 再次使用其默认值。
如果您的工作负载配置中使用了这些变量，请定期重新检查是否仍应将其设置为对工作负载的更改、新的 NCCL 版本，或随着其他系统配置更新的推出而进行设置。
除了可维护性问题之外，这些变量是一个全局设置，将应用于进程中的所有 NCCL 通信器。NCCL 可以缓存它们的值 (在进程的生命周期内) ，因此将它们设置为一个值并在之后更改它们将不起作用。通常情况下，建议将这些数据用于基准测试，而非操作。
要覆盖算法和协议选择，请使用 NCCL_ALGO 和 NCCL_PROTO。您还可以尝试增加 NCCL_MIN_CTAS 或 NCCL_NCHANNELS_PER_NET_PEER，以尝试增加用于驱动运算的 CTA 数量。NCCL_BUFFSIZE 和 NCCL_P2P_CHUNKSIZE 也是指定给每个 CTA 的缓冲大小的关键调优参数。
ncclCommInitRankConfig
NCCL 允许用户覆盖每个通信器的配置。有关更多详细信息，请参阅 NCCL 文档。这允许进行 CTA 调优 (以及其他设置) ，但不支持协议或算法调优。只有当您可以访问应用程序的 NCCL 层代码库时，才会使用此选项，并且配置管理可能会导致与环境变量相同的问题。
确保良好的基础性能
确保正确设置 NCCL 和系统是实现良好性能的关键。如果底层系统无法执行，调整选择就无法发挥作用。请参阅 NCCL 文档的故障排除部分，了解常见问题。
案例研究：点固定默认调优
本节介绍如何使用 NCCL GitHub 库中提供的示例调优器插件，以解决示例场景中算法和协议选择错误的问题。
分析 S 曲线
图 1 所示的 NCCL S 曲线示例是报告的总线带宽或总体硬件带宽利用率与消息大小的对比图。
这是一条经过良好调优的清晰 S 曲线。假设此平台具有高达 200 GB/ 秒的硬件链路达到饱和，则显然已达到线速。对于非常小的消息大小，性能主要取决于延迟。随着消息大小的增加，带宽利用率也会增加，最终以硬件的线速趋于平稳。
图 2 将调优良好的 S 曲线与调优次优的 S 曲线进行比较。
您可以清楚地看到，将消息大小从 2 MB 增加到 4 MB 时，性能会下降。如果您在增加消息大小时看到性能下降，则表示调优时出现了错误过渡点的强烈信号。当在多个点 (从 4 MB 到 8 MB，从 128 MB 到 256 MB) 将消息大小增加一倍时，BusBW 也会处于稳定状态。假设基本硬件性能良好，这种情况永远不会发生。
此类数据是一个强烈信号，表明 NCCL 在某些消息大小下选择了错误的算法和协议。
要解决此问题，请先确认调优确实是问题所在，而非基础性能。建议使用相关调优环境变量对 NCCL 性能进行基准测试 (通常使用 NCCL 测试) ，并在有效值中扫描 NCCL_PROTO 和 tg_ 13。图 3 显示了 NCCL 调优如何影响网络性能。您可以看到不同算法和协议之间在性能方面的明显权衡。简单是带宽优化程度最高的协议，而 LL 是延迟优化程度最高的协议。LL128 位于中间。Ring 的峰值带宽利用率最高，但 Tree 是对数的，在中等消息大小下表现非常出色。
纵观这些曲线，您可以排除平台性能的根本原因。不同的调整参数组合看起来和预期一样。在这种情况下，可能的原因是 NCCL 调优错误。
为帮助找出问题，请在扫描图上绘制默认调优决策，如图 4 所示。
您可以清楚地看到默认调优选项在哪些地方出现问题，从大约 4 MB 开始，一直持续到大约 512 MB 的消息大小。理想情况下，对于每种消息大小，NCCL 都会选择性能最佳的协议和算法。
如何使用调优器插件修复调优问题
要修复这些调优，请使用调优插件。强制使用单个协议或算法不会解决任何问题，因为您需要在消息大小上进行各种选择。因此，调优插件是唯一的选择。
此示例使用 GitHub 上提供的参考开源示例调优器插件。示例调优器插件是选择性覆盖配置文件方法的参考实现。该插件从基于 CSV 的配置文件中读取调优配置，允许有针对性地覆盖给定的消息大小、比例或操作，而无需重新编译插件。
首先，获取原始调优数据，并将其转换为插件可用的格式。幸运的是，该插件随附了一个调用脚本的 make 命令，该脚本可将原始调优数据转换为插件正在寻找的 CSV 优设格式。输出显示了在配置文件中创建的自动范围。
make optimize-config CSV_FILE=my_raw_data.csv OUTPUT=my_new_tunings.conf METRIC=latency_us
Auto-ranging enabled: will create one bucket per unique size in data
Loaded 180 performance data points
Dimension 4 nodes, 32 ranks: 30 size ranges from 30 unique sizes:
Range 1: 0 - 12 bytes (6 data points, sizes: 8)
Range 2: 13 - 24 bytes (6 data points, sizes: 16)
Range 3: 25 - 48 bytes (6 data points, sizes: 32)
Range 4: 49 - 96 bytes (6 data points, sizes: 64)
Range 5: 97 - 192 bytes (6 data points, sizes: 128)
Range 6: 193 - 384 bytes (6 data points, sizes: 256)
Range 7: 385 - 768 bytes (6 data points, sizes: 512
...
Combined 30 ranges into 4 ranges (reduced by 26)
Optimal for allreduce [0-98304] nodes=4 ranks=32: tree/ll channels=-1 (latency_us=49.130)
Optimal for allreduce [98305-12582912] nodes=4 ranks=32: tree/ll128 channels=-1 (latency_us=101.400)
Optimal for allreduce [12582913-100663296] nodes=4 ranks=32: ring/ll128 channels=-1 (latency_us=634.800)
Optimal for allreduce [100663297-4294967296] nodes=4 ranks=32: ring/simple channels=-1 (latency_us=2967.600)
...
Creating new file: my_new_tunings.conf
Created my_new_tunings.conf with 30 optimized configurations
加载具有固定调优的插件
接下来，使用生成的优化 CSV 文件重新运行 NCCL。再次运行 all_reduce_perf 基准测试，加载 CSV 插件并启用 TUNING 调试子系统。您可以在输出中看到它已成功加载。
f1d6821f5ab3:1075:1081 [0] NCCL INFO TUNER/Plugin: Plugin name set by env to libnccl-tuner-example.so
f1d6821f5ab3:1075:1081 [0] NCCL INFO TUNER/Plugin: Using tuner plugin Example
f1d6821f5ab3:1075:1081 [0] NCCL INFO Initializing tuner for 4 nodes, 32 ranks
f1d6821f5ab3:1075:1081 [0] NCCL INFO TUNER/ExamplePlugin: Loaded config: allreduce [0-98304] tree/ll channels=-1 nodes=4 ranks=32 pipeOps=any regBuff=any
f1d6821f5ab3:1075:1081 [0] NCCL INFO TUNER/ExamplePlugin: Loaded config: allreduce [98305-12582912] tree/ll128 channels=-1 nodes=4 ranks=32 pipeOps=any regBuff=any
f1d6821f5ab3:1075:1081 [0] NCCL INFO TUNER/ExamplePlugin: Loaded config: allreduce [12582913-100663296] ring/ll128 channels=-1 nodes=32 ranks=8 pipeOps=any regBuff=any
f1d6821f5ab3:1075:1081 [0] NCCL INFO TUNER/ExamplePlugin: Loaded config: allreduce [100663297-4294967296] ring/simple channels=-1 nodes=32 ranks=8 pipeOps=any regBuff=any
f1d6821f5ab3:1075:1081 [0] NCCL INFO TUNER/ExamplePlugin: Loaded 4 tuning configurations from my_new_tunings.conf
最终结果
如图 5 所示，调优已被覆盖，现在效果良好。对于需要在不修改任何应用程序或库代码的情况下解锁的用户来说，这是一个好消息。
开始使用 NCCL 调优
NCCL 调优是在 AI 和 HPC 工作负载中更大限度地提高硬件性能以及跨消息大小和作业维度实现线速的重要方面。通过利用调优器插件，您可以克服默认调优的任何限制。正如本文中的案例研究所示，示例调优器插件可以用于解决可能出现的任何调优问题。
详细了解 NCCL，阅读 NCCL 文档，下载 NCCL 软件，并在 NVIDIA 开发者论坛上讨论此主题。有关更多信息，请查看以下相关文章：
- 借助 NVIDIA 集合通信库 2.22 实现显存效率、更快的初始化和成本估算
- 使用 NVIDIA 集合通信库 2.23 的新扩展算法和初始化
- 借助 NCCL 2.24 实现大规模网络可靠性和可观测性
- 借助 NVIDIA 集合通信库 2.26 提升性能和监控功能
- 借助 NCCL 2.27 实现快速推理和弹性训练
