Internal Wiki

主题

Bootstrap 交换的元数据 ​

作业启动时，每个主机都会将自己的身份和端点发布给协调器，并接收组装好的机群视图。本页介绍这次交换中传输哪些元数据；rendezvous 机制本身（协调器选举、Coordinator<> 模板、收敛等待）记录在 Bootstrap Rendezvous 概览 中。

主机发布的内容 ​

每个 worker 调用 DiscoverTopologyAndAddressBindings(local_slice_id, TpuTopologyArgsProto args, local_host_id, num_slices) 并构造一个请求：

protobuf
message GetMultiSliceTopologyRequest {
  NetworkAddressMapping    address_mapping   = 1;  // THIS host's identity + endpoints
  tpu.TpuTopologyArgsProto tpu_topology_args = 2;  // THIS slice's shape
  int64                    incarnation_id    = 3;  // THIS process's generation
}
```text

`address_mapping` 携带该主机自己的身份和可达性信息：

```text
NetworkAddressMapping {
  slice_id  = local_slice_id,
  host_id   = local_host_id,
  addresses = [ HostNetworkAddress {
                 address, interface_name, numa_node,
                 host_name_for_debugging } per DCN NIC ]
}

因此，一个主机只发布四项事实：它的 (slice_id, host_id)、它的 DCN 端点、它的 slice 形状，以及它的 incarnation。不包含其他主机或芯片的信息。

关于字段位置的说明。 早期重构估计这是一个 5 字段请求，具有显式的顶层 slice_id / host_id / host_addresses / topology_args / incarnation_id。descriptor-pool 的真实情况是将 slice_id + host_id 放在address_mapping 内部，因此请求只剩三个字段。

协调器组装的内容 ​

协调器的 TopologyCoordinator 会为每个 (slice_id, host_id) 累积一个请求，并验证一个 slice 中的所有主机都报告等价的 tpu_topology_args。当所有 num_slices · hosts_per_slice 个注册都到达后，它会组装：

protobuf
message MultiSliceTopologyInfo {
  repeated SliceInfo             slice_info       = 1;  // every slice + shape
  repeated NetworkAddressMapping address_mappings = 2;  // every host's endpoints
  int64                          incarnation_id   = 3;
}
```text

这会将 slice 清单（字段 1）与完整端点表（字段 2）配对。协调器将其序列化为字节并返回：

```protobuf
message GetMultiSliceTopologyResponse {
  bytes serialized_topology_info = 1;   // serialized MultiSliceTopologyInfo
}

响应是单个不透明的 bytes blob，而不是结构化消息。这使响应在字节层面保持稳定（协调器会在序列化前对 slice 和端点列表排序，因此相同输入会产生相同字节），这是 re-key 检测器 所依赖的性质。

主机安装的内容 ​

收到响应后，每个 worker：

  1. 将 serialized_topology_info 解析回 MultiSliceTopologyInfo。
  2. 从 slice_info 重建自己的 MultiSliceTopologyAndLocation （通过 MultiSliceTopologyAndLocationProto 上的 FromProto），并写入自己的 local_slice_id / local_host_id。
  3. 将 address_mappings 转换为 EndpointAddresses，并把端点映射安装到 Communicator (flat_hash_map<tuple<int,int>, NetworkAddressMapping>).

到此时，稳态的 Send/Recv collective 就成为可能：每个主机都知道其他每个主机的 (slice_id, host_id)，以及可用于到达它的 DCN NIC。

数据流摘要 ​

text
发布（每主机）                    接收（整个机群）
──────────────────                ─────────────────────
(slice_id, host_id)        ──►    repeated SliceInfo         （所有 slice + 形状）
DCN 端点                  ──►    repeated NetworkAddressMapping （所有主机端点）
tpu_topology_args（形状）         incarnation_id
incarnation_id
```text

一个主机宣布单行信息；它接收整张表。

## bootstrap 时不交换的内容

- **芯片坐标。** ICI `ChipCoordinate` 空间留在 slice 内；只有 slice 的边界形状会被传输。参见
  [ICI 与 DCN](ici-vs-dcn.md).
- **DCNTopology reduction tree。** 该计划单独计算/配置，并传入 Communicator，而不是从主机收集。
- **每芯片物理句柄。** 芯片只会在
  [错误聚合器](barrier-error-usage.md) 的诊断输出中以物理方式命名
  (`chip_id`, `core_idx`, `physical_location`)，从不会出现在 bootstrap 清单中。