对多切片环境进行性能分析
Cloud TPU 多切片环境由多个通过数据中心网络 (DCN) 通信的 TPU Pod 切片组成。您可以使用 DCN 集合统计信息工具查看有关多切片环境使用 DCN 网络的效果的信息。具体来说，借助 DCN Collective Stats 工具，您可以：
- 根据收集的数据查看和了解切片之间的网络性能
- 识别性能瓶颈
- 优化模型的性能
DCN 总体统计信息工具中的所有指标都是基于每个 TPU 生成的。
术语
DCN 集合统计信息工具会显示一些指标，这些指标描述了多切片环境中 TPU 切片之间发生的通信。当 TPU 运行时启动切片间通信时，会使用一系列操作：
send- 中断主机以启动直接内存访问 (DMA)，并为主机提供填充的缓冲区以开始数据传输。
send-done- 向主机发送数据转移已完成的信号。
recv- 提供空缓冲区，供主机填充传输的数据。
recv-done- 指示主机已收到数据。
集合在发生 send 操作时启动，在发生匹配的 recv-done 操作时完成。
Slack 时间
用于衡量集合发送和接收数据的时间。不包括 send、send-done、recv 或 recv-done 操作。以下面的时间轴为例：
在此示例中，Slack 时间的计算方式如下：
Slack 时间 = t1 + t2 + t3
增加宽松时间可降低 TPU 停止集体的可能性。您可以通过选择其他分片方法来增加空闲时间。
摊位时长
总体在发送、发送完成、接收和接收完成操作中花费的平均时长。请注意，这不包括传输数据所花的时间。以下面的时间轴为例：
在本示例中，停滞时长的计算方式为：
展示时长 = 发送 + 发送 - 发送 + 接收 + 接收
观察时长
send 和 recv-done 操作之间的时间，包括发送和接收数据的时间。以下面的时间轴为例：
观察持续时间的计算公式如下：
观察到的时长 = t1 + t1 + tsend-done + t2 + trecv + t3 + trecv-done
出现次数
在分析期间启动和完成集合的次数。集合在发生 send 操作时启动，在发生匹配的 recv-end 操作时完成。send 操作及其匹配的 recv-done 操作必须在配置文件持续时间内发生，才能纳入到此指标中。
汇总总摊位数
某个集合在分析期间使 TPU 停止的总时长。聚合总停顿的计算公式如下：
汇总总停滞次数 = 失速时长 * 出现次数
传输的数据大小
在分析期间，通过网络传输的数据量。
所需带宽
在提供的 Slack 中传输数据所需的带宽。您可以使用此指标查看在配置文件运行期间竞争网络带宽的集体数量。所需带宽的计算公式如下：
所需带宽 = 数据传输大小 / 空闲时间
工具状态
下表显示了 DCN Collective Stats 工具中显示的每个指标所需的 TensorFlow 或 TPU 运行时版本。
| DCN Collective Stats | 支持的 TPU 运行时版本 TensorFlow |
|---|---|
| Slack 时间 | TensorFlow 2.15.0、TensorBoard 2.15.1 和 tensorboard-plugin-profile 2.15.0 |
| 摊位时长 | TensorFlow 2.15.0、TensorBoard 2.15.1 和 tensorboard-plugin-profile 2.15.0 |
| 观察时长 | TensorFlow 2.15.0、TensorBoard 2.15.1 和 tensorboard-plugin-profile 2.15.0 |
| 出现次数 | TensorFlow 2.15.0、TensorBoard 2.15.1 和 tensorboard-plugin-profile 2.15.0 |
| 汇总总摊位数 | tf-nightly、tb-nightly、tbp-nightly |
| 传输的数据大小 | tf-nightly、tb-nightly、tbp-nightly |
| 所需带宽 | tf-nightly、tb-nightly、tbp-nightly |
如何分析 DCN Collective Stats 工具
- 运行 TensorBoard 服务器并转到性能剖析 (Profile) 标签页。
- 在 DCN 总体统计信息工具中，按 Aggregated Total Stall 降序排列。
- 确定汇总总摊位数最高的 DCN 集合名称。如果此集合的汇总停滞时长与其他集合相比明显较长，则可能表示 DCN 集合中存在瓶颈。
- 将 DCN 所需的带宽乘以核心数。每个 v4 TPU 主机有 8 个核心，因此一个集合所需的带宽是显示值的 8 倍。如果所需的带宽超过 TPU 的最大网络带宽，这可能意味着网络拥塞。如需减少所需的带宽，请尝试更改使用的分片机制。如需详细了解分片机制，请参阅 Cloud TPU 多切片概览。
- 生成 HLO 转储，以确定是否存在任何编译器问题。最好为集合扇出
send和recv-done操作，以便调度更多重叠的 HLO 操作。重叠更多的 HLO 操作可缩短 TPU 停顿时间。 - 在跟踪查看器中检查具有最大汇总总停顿的 DCN 集合的
recv-done操作时长。如果传输的时长较长，则可能存在带宽瓶颈，因为为了获取数据，网络通常会阻止recv-done操作。 - 如果与 Slack 时间相比，
recv-done操作的时长不太长，则可能表示硬件存在问题。