PyTorch TorchElastic Rendezvous 完整指南：分布式任务会合机制、Backend 注册与动态集群编排
【免费下载链接】pytorchTensors and Dynamic neural networks in Python with strong GPU acceleration项目地址: https://gitcode.com/GitHub_Trending/py/pytorch
Rendezvous（会合）是 PyTorch TorchElastic（torch.distributed.elastic）在启动与弹性伸缩分布式训练任务时使用的核心机制，它将"分布式同步屏障"与"节点发现"合二为一。本文以 rendezvous.md 官方 API 文档为骨架，逐层拆解其Registry → Handler → Backend抽象体系、DynamicRendezvousHandler的动态会合算法、四种可用实现（static/c10d/etcd-v2/ 旧版etcd）以及配套的EtcdStore与EtcdServer，并结合 torch/distributed/elastic/rendezvous 目录下的真实实现源码给出可落地的配置与使用方式。
读完本文，你将能够：理解 torchrun 在--rdzv-*参数背后实际做的工作；掌握RendezvousParameters、RendezvousHandler等关键类的字段与方法语义；知道如何注册并使用c10d、etcd等会合后端；并能通过EtcdServer快速搭建本地（单节点多 worker）的 etcd 会合环境进行验证。
什么是 Rendezvous：同步屏障 + 节点发现
在 torch/distributed/elastic/rendezvous/__init__.py 的模块文档中，对 rendezvous 给出了精确定义：它把分布式同步原语和**节点发现（peer discovery）**结合在一起，用于让一个训练任务（job）的参与节点（nodes）汇聚起来，使所有节点对"参与者名单与各自角色"达成一致，并对"训练何时可以开始/恢复"做出统一决策。
具体而言，TorchElastic rendezvous 提供以下关键能力：
- Barrier（屏障）：节点调用
next_rendezvous()后阻塞，直到至少min_nodes个（同一 job 的）节点加入屏障，会合才算完成——这意味着屏障不是固定大小的。达到min后还有一段额外等待时间（last_call），避免"过快完成"而把几乎同时到达的节点拒之门外；若收集满max个节点则立即完成；同时存在一个总超时（join timeout，默认 600 秒），若始终凑不齐min个节点则失败，该失败被设计为不可重试，用于在资源管理器异常时释放部分已分配的任务资源。 - Exclusivity（排他性）：同一 job 在同一时刻只允许存在一个 worker 组。迟到的节点不会与已在训练的节点并行组成第二个独立组，而是进入 wait-list 等待，直到当前会合被销毁（关闭）。
- Consistency（一致性）：会合完成后，所有成员对成员名单与角色（整数 rank，介于 0 与 world size 之间）达成一致。注意 rank不是稳定的——同一节点在下一轮 re-rendezvous 中可能被分到不同 rank。
- Fault-tolerance（容错）：若某进程在"加入会合"到"会合完成"之间崩溃（或断网），剩余的健全节点会自动触发 re-rendezvous。若节点在会合完成后才失败，则由 TorchElastic 的
train_loop处理并同样触发 re-rendezvous。 - Shared key-value store（共享键值存储）：会合完成后会创建一个实现
torch.distributed.StoreAPI 的共享键值存储并返回给成员，用于交换初始化 job 控制面与数据面所需的信息（例如MASTER_ADDR/MASTER_PORT）。 - Waiting workers 与 rendezvous closing：handler 额外提供两项不属于会合过程本身的功能——查询有多少迟到节点在等待下一轮会合（
num_nodes_waiting()），以及把会合标记为 closed 以通知所有节点不要参加下一轮会合（set_closed()）。
关于弹性（min_nodes < max_nodes）场景下的迟到节点处理，torch/distributed/elastic/__init__.py 补充说明：若会合已达max_nodes，新节点不会立刻进入 wait list（因为没有必要拆毁一个已满员的会合），而是等到自身超时（默认 600 秒）并周期性检查参与者数量；一旦参与者降到max_nodes以下，新节点才加入 wait list；否则超时退出。因此在实际生产使用中，join_timeout与弹性缩容节奏需要相互匹配。
状态迁移：从 Joinable 到 Final 的两个阶段
官方文档在 etcd_rdzv_diagram.png 中绘制了 rendezvous 的状态迁移示意（该图主要描述 etcd 等后端上会合状态的流转，其逻辑与 dynamic_rendezvous.py 中_RendezvousState及其操作符执行器的设计一一对应）：
整个会合可以理解为两个阶段：
- Join（加入）阶段：后端上记录了一份"参与者"名单。每个新节点到达后尝试把自己的描述符（地址、pid 等，对应源码中的
_NodeDesc）追加进名单，每追加一个参与者版本号递增（对应图中/rdzv/version_counter的原子递增）。当参与者数量达到min_nodes时进入确认前的"可会合（joinable）"状态。 - Confirm（确认）阶段：一旦达到
max_nodes，或触发last_call超时，会合被"冻结（frozen）"并最终完成（final）。此时会合产生的这份只读快照——参与者的完整名单——被广播给所有参与者，节点据此推导出自己的 rank 与 world size。
这套状态机在源码中的体现是：_RendezvousStateHolder（负责在本地与后端之间同步、缓存会合状态）、_RendezvousOpExecutor（负责以"先读后端状态、在本地计算新状态、再条件写回"的方式原子地执行动作）以及_RendezvousExitOp/_RendezvousJoinOp/_RendezvousCloseOp/_RendezvousKeepAliveOp四类动作。这类动作把节点区分为participants（本轮参与者）、wait_list（迟到等待者）、redundancy_list（冗余节点）三类集合。
顶层 API 体系速览
rendezvous.md 采用 Sphinxautodoc组织文档，正文实际由四个命名空间组成，全部位于 rendezvous 包（torch.distributed.elastic.rendezvous）下，顶层入口通过 __init__.py 统一导出。
在torch.distributed.elastic.rendezvous包被 import 时，模块末尾会自动执行两件事：调用_register_default_handlers()注册内置后端，以及调用_register_out_of_tree_handlers()从 Pythonentry_points(group="torchrun.handlers")中加载外部注册的 handler（加载失败只告警，不影响启动）：
# torch/distributed/elastic/rendezvous/registry.py def _register_default_handlers() -> None: handler_registry.register("etcd", _create_etcd_handler) # 旧版 etcd handler handler_registry.register("etcd-v2", _create_etcd_v2_handler) # DynamicRendezvousHandler + EtcdRendezvousBackend handler_registry.register("c10d", _create_c10d_handler) # DynamicRendezvousHandler + C10dRendezvousBackend handler_registry.register("static", _create_static_handler) # StaticTCPRendezvous（wrapper around TCPStore）因此通过 torchrun 或在代码中调用时，合法的后端名是etcd、etcd-v2、c10d、static（以及任何外部插件注册的名字）。
Registry：参数对象、注册表与工厂函数
文档的 "Registry" 一节覆盖三个概念：RendezvousParameters、RendezvousHandlerRegistry 与 get_rendezvous_handler。
RendezvousParameters：构造 Handler 的参数容器
RendezvousParameters是面向对象地承载"要创建哪种会合"的纯数据类。其构造参数如下：
| 参数 | 类型 | 含义 |
|---|---|---|
backend | str | 后端名（非空字符串），如c10d/etcd/etcd-v2/static |
endpoint | str | 会合端点，通常形如<hostname>[:<port>] |
run_id | str | 会合 id，唯一标识一次分布式应用（通常映射为 job id），用于让节点加入正确的应用 |
min_nodes | int | 允许进入会合的最少节点数（必须 ≥ 1） |
max_nodes | int | 允许进入会合的最大节点数（必须 ≥min_nodes） |
local_addr | Optional[str] | 本机节点地址，缺省时由 handler 基于 FQDN/主机名解析 |
**kwargs | — | 传给特定后端的附加配置，统一放入config字典 |
构造时若backend为空、min_nodes < 1或max_nodes < min_nodes，均抛出ValueError。附加配置通过get(key, default)、get_as_bool(key, default)、get_as_int(key, default)三个读取方法访问——其中get_as_bool接受bool、0/1整数以及"true"/"t"/"yes"/"y"/"1"等字符串形式，非法布尔值会抛错。后端各自的扩展参数（如join_timeout、keep_alive_interval、store_type、read_timeout、is_host等）都通过这些 getter 从config中取出。
RendezvousHandlerRegistry：后端注册表
RendezvousHandlerRegistry维护一张backend 名 → creator 回调的字典：
register(backend, creator)：注册后端。同名后端再次注册时，若回调与已注册的不同会抛出ValueError（防止重复注册冲突）。create_handler(params)：根据params.backend查找 creator 并实例化 handler，随后做一致性检查——若handler.get_backend() != params.backend会抛出RuntimeError；后端不存在则提示Did you forget to call register(...)。
模块级的全局单例是torch.distributed.elastic.rendezvous.rendezvous_handler_registry，torchrun 启动脚本正是通过它来实例化会合 handler。
get_rendezvous_handler：默认工厂函数
get_rendezvous_handler(params: RendezvousParameters) -> RendezvousHandler是对全局注册表create_handler的一层薄封装，是绝大多数用户获取 handler 的入口。注册自定义后端（例如对接自研调度系统）的完整姿势如下：
from torch.distributed.elastic.rendezvous import rendezvous_handler_registry from torch.distributed.elastic.rendezvous.api import RendezvousParameters from torch.distributed.elastic.rendezvous.registry import get_rendezvous_handler def create_my_rdzv(params: RendezvousParameters): return MyCustomRdzv(params) # 实现 RendezvousHandler 接口 rendezvous_handler_registry.register("my_rdzv_backend_name", create_my_rdzv) params = RendezvousParameters( backend="my_rdzv_backend_name", endpoint="host:port", run_id="job-123", min_nodes=1, max_nodes=4, ) handler = get_rendezvous_handler(params)Handler：RendezvousHandler 接口与返回信息
RendezvousHandler：一切会合的抽象基类
RendezvousHandler 是主会合接口，所有实现（StaticTCPRendezvous、DynamicRendezvousHandler、EtcdRendezvousHandler）都实现它。抽象方法语义如下：
| 方法 | 说明 |
|---|---|
get_backend() | 返回会合后端的名称（用于与请求的后端做一致性校验） |
next_rendezvous() | 主入口。阻塞直至会合完成且本进程被纳入 worker 组，或超时，或会合被标记关闭；返回RendezvousInfo。可能抛RendezvousClosedError/RendezvousConnectionError/RendezvousStateError/RendezvousTimeoutError |
is_closed() | 判断会合是否已被关闭。语义是"最终一致传播"，不能用于同步：只要有一个节点决定任务结束并关闭会合，其他节点很快也会观察到 |
set_closed() | 把会合标记为关闭 |
num_nodes_waiting() | 返回迟到到达屏障、因而未进入当前 worker 组的节点数。调用方应周期性检查，若有新节点等待则通过再次next_rendezvous()（re-rendezvous）将其纳入 |
get_run_id() | 返回会合的 run id |
shutdown() | 释放会合打开的所有资源，返回是否成功 |
此外还有一个可选属性use_agent_store（默认False）：当为True时表示next_rendezvous()返回的 store 可以与用户应用共享，且在整个应用生命周期内可用；handler 会通过RendezvousStoreInfo暴露 store 细节，应用按惯例使用MASTER_ADDR/MASTER_PORT环境变量来发现 store。
文档注释明确建议：普通分布式 PyTorch 用户通常不需要自己实现RendezvousHandler——基于 C10d Store 的实现已内置且被推荐（见下文 c10d Backend 一节）。
RendezvousInfo 与 RendezvousStoreInfo：返回给调用方的数据类
文档 "Dataclasses" 一节覆盖两个数据类：
RendezvousInfo：一次会合的结果对象，含只读属性
store（控制面使用的共享 Store）、rank（组内编号）、world_size（全局组大小）、bootstrap_store_info（可用于引导训练通信的 store 信息，类型为RendezvousStoreInfo或None）。RendezvousStoreInfo：封装引导训练器分布式通信所需的地址信息，含
master_addr: str与master_port: int两字段。其静态工厂方法build(rank, store, local_addr, server_port=None)的行为（实现见 api.py#L71-L106）值得展开：当rank == 0时，取local_addr（缺省则socket.getfqdn()解析）并通过get_free_port()分配空闲端口，然后把这两个值以键MASTER_ADDR/MASTER_PORT（类常量MASTER_ADDR_KEY/MASTER_PORT_KEY）写入共享 store；随后所有 rank 从 store 中读回并构造统一的RendezvousStoreInfo。若使用者已有现成的 TCPStore server（共享场景），可显式传server_port以复用，否则会走"自动找空闲端口"的路径。典型用法——把 rendezvous 输出转换为进程内
MASTER_ADDR/MASTER_PORT环境变量：info = handler.next_rendezvous() os.environ["MASTER_ADDR"] = info.bootstrap_store_info.master_addr os.environ["MASTER_PORT"] = str(info.bootstrap_store_info.master_port) dist.init_process_group("nccl", rank=info.rank, world_size=info.world_size)
Exceptions：异常层级
文档 "Exceptions" 一节列出的异常全部定义在 api.py，以RendezvousError（基类，直接继承Exception）为根：
| 异常 | 语义 |
|---|---|
RendezvousClosedError | 会合已被关闭时抛出 |
RendezvousTimeoutError | 会合未在期限内完成时抛出 |
RendezvousConnectionError | 到会合后端的连接失败时抛出 |
RendezvousStateError | 会合状态损坏时抛出（例如 C10d 后端中 base64 状态解码失败） |
RendezvousGracefulExitError | 节点未被纳入本轮会合而"优雅退出"时抛出。注意：该异常仅用于退出调用栈，并不意味着失败 |
这五类异常会被next_rendezvous()、is_closed()等方法在错误路径上抛出，被 agent（见 server/api.py）捕获以驱动 worker 重启或任务终止。
Implementations：可用的具体实现
Dynamic Rendezvous：统一动态会合实现
文档明确指出，新代码应优先使用DynamicRendezvousHandler——一个后端无关的类型：它实现了上文全部会合语义（barrier、exclusivity、consistency、fault-tolerance、共享 KV store、wait list 管理），但把"状态存放在哪里"抽象成 RendezvousBackend 接口。用户要么自研 backend，要么使用 PyTorch 自带的两种：C10dRendezvousBackend（基于 C10d Store，默认TCPStore，无第三方依赖）与EtcdRendezvousBackend（动态 handler + etcd 后端，功能上等价于旧版EtcdRendezvousHandler）。
模块级工厂create_handler(store, backend, params)负责把RendezvousParameters中形如*_timeout的后端参数解析进 RendezvousTimeout，再从params.config读取keep_alive_interval与keep_alive_max_attempt，最后调用DynamicRendezvousHandler.from_backend(...)（实现见 dynamic_rendezvous.py#L1391-L1458）。
超时与心跳配置（RendezvousTimeout / 参数表）
RendezvousTimeout持有四类超时，构造函数全部可省略（省略即用默认值，且传入非正timedelta会抛ValueError），其默认值定义于 dynamic_rendezvous.py#L143-L148：
| 超时 | 语义 | 默认值 |
|---|---|---|
join | 会合预期完成的总时间；min个节点始终凑不齐则会合失败（不可重试） | 600 秒 |
last_call | 达到最小节点数后、正式完成会合前的额外等待（避免漏掉同时到达的节点） | 30 秒 |
close | 调用set_closed()或shutdown()后，会合预期被关闭的时间 | 30 秒 |
heartbeat | 一次 keep-alive 心跳预期完成的时间 | 5 秒 |
create_handler的 docstring 同时给出了从RendezvousParameters传入时的参数名（秒为单位）：join_timeout、last_call_timeout、close_timeout、heartbeat；此外还接受keep_alive_interval（节点发送心跳保活的间隔，默认 5 秒）与keep_alive_max_attempt（连续失败多少次后认为节点死亡，默认 3 次）。这些配置在 torchrun 中可通过--rdzv-conf以key=value逗号分隔形式传入，例如：
torchrun \ --rdzv-backend=c10d \ --rdzv-endpoint=localhost:29500 \ --rdzv-id=my-job \ --rdzv-conf='join_timeout=900,last_call_timeout=60,keep_alive_interval=10' \ --nnodes=2 --nproc-per-node=4 \ train.py心跳保活机制与 store 封装
DynamicRendezvousHandler内部以_PeriodicTimer周期发送心跳：节点加入后会合后启动名为RendezvousKeepAliveTimer_<local_id>的定时器（dynamic_rendezvous.py#L1348-L1357），每次_keep_alive()在持锁状态下把当前节点重新写入后端的 participants/keep-alive 记录，并清理超过keep_alive_max_attempt的死亡节点——这正是容错性中"会合中途崩溃会被剔除并触发 re-rendezvous"的落地方式。
next_rendezvous()内部工作流（dynamic_rendezvous.py#L1148-L1236）大致为：先停掉上一轮心跳 → 若当前轮次为 0 则做 0~0.3 秒随机延迟（打散节点到达后端的时间，降低后端瞬时负载）→ 依次执行 exit op（把本节点从上一轮名单中摘除）与 join op（按上文状态机加入本轮）→ 启动心跳 → 从状态中推导rank, world_size→ 取得 store。返回给用户的 store 会用dist.PrefixStore以torch.rendezvous.<run_id>.<round>为前缀封装（_wrap_store），从而保证不同 round 之间的键空间天然隔离。
C10d Backend：默认推荐、无第三方依赖
C10dRendezvousBackend 使用 C10d Store（默认TCPStore，也支持FileStore）作为会合状态的后端，是c10d这一后端名的实现。它最大的优势正如 __init__.py 所述：不需要 etcd 等第三方依赖即可建立会合。它与动态 handler 组合，就是 PyTorch 2.x 起 torchrun 默认推荐的多节点启动方案。
create_backend(params)根据参数创建后端与 store，其配置参数表（见 c10d_rendezvous_backend.py#L211-L244）：
| 参数 | 默认值 | 说明 |
|---|---|---|
store_type | "tcp" | C10d store 类型，目前仅支持"tcp"（TCPStore）与"file"（FileStore）；源码注释说明其他 store 类型尚不具备所需功能（如compare_set） |
read_timeout | 60 秒 | store 操作的读超时；仅对TCPStore有意义（FileStore不接受超时参数） |
is_host | None | 本进程是否作为 C10d store 的 host。缺省时根据本机 hostname/IP 与端点做启发式匹配（_matches_machine_hostname）；仅在 CNAME 端点或端点与 FQDN 不一致等无法自动判定的场景才需要显式设置 |
C10dRendezvousBackend把会合状态序列化后 base64 存入 store 中torch.rendezvous.<run_id>键下，并以一个内置哨兵值（_NULL_SENTINEL）绕过"Store.get 会阻塞直到键存在"的问题（c10d_rendezvous_backend.py#L52-L66）：初始化时先把空串通过compare_set换成哨兵，读到哨兵即视为"无状态"。set_state依赖 Store 的原子compare_set实现"带 fencing token 的条件写"（token 不匹配则不更新并返回现状）；由于compare_set不直接告知是否成功，源码用"本地位与远端逐字节比较"来判断写入成败。
在 torchrun 中使用c10d后端时，endpoint即 TCPStore 所在地址。torchrun 的 docstring（torch/distributed/run.py#L95-L121）给出了典型用法：单机多 worker 时用--rdzv-backend=c10d --rdzv-endpoint=localhost:0（端口 0 表示自动选择空闲端口），多节点时指定 host 节点的地址与端口，并把相同的--rdzv-id传给所有节点。
Etcd Backend（etcd-v2）：动态 handler 的 etcd 实现
etcd-v2后端 =DynamicRendezvousHandler+ EtcdRendezvousBackend，由_create_etcd_v2_handler组装（registry.py#L35-L40）。注册表中将其与c10d并列推荐，若环境里已具备 etcd 集群、或需要把会合状态保存在运行期之外的服务端上，可使用它。
Etcd Rendezvous（Legacy）：etcd后端与淘汰警告
etcd（不带-v2）注册的是旧版 EtcdRendezvousHandler。rendezvous.md 用一个醒目的 warning 提醒：
DynamicRendezvousHandler已取代EtcdRendezvousHandler，推荐大多数用户使用后者；EtcdRendezvousHandler处于维护模式，未来将被弃用。
旧版 handler 使用 URL 字符串配置，其基本格式为：
etcd://<etcd_address>:<port>/<job_id>?min_workers=<min>&max_workers=<max> # 例如 etcd://localhost:2379/1234?min_workers=1&max_workers=3从源码可见，旧版EtcdRendezvous内部依赖一组 etcd TTL 常量与EtcdRendezvousRetryableFailure/EtcdRendezvousRetryImmediately两个内部异常来驱动重试（etcd_rendezvous.py#L54-L88）：例如 worker 保活键 TTL 为 10 秒、run_id 目录的清理 TTL 为 7200 秒（仅用于清理持久化 etcd 中旧任务数据，不影响正确性）。新项目应改用etcd-v2/c10d。
EtcdStore：以 etcd 为后端时返回的 C10d Store
当使用 etcd 作为会合后端时，next_rendezvous()返回的共享键值存储是 EtcdStore ——它实现了torch.distributed.StoreAPI（即 C10d Store），但在底层把set/get/add/compare_set等操作翻译成对 etcd 键值 API 的调用。也就是说，使用 etcd 后端时训练进程拿到的仍是一个标准的dist.Store，可以直接传给dist.init_process_group，无需区分实现差异。EtcdStore会以torch.rendezvous.<run_id>.<round>之类的键空间前缀隔离不同会合轮次的数据。
EtcdServer：免手工部署的本地 etcd
EtcdServer 是一个便捷类，在子进程中启动/停止一个本地单机 etcd server（官方注释说明测试基于 etcd v3.4.3），适用于测试或单节点（多 worker）部署——此时手工在旁边起一个 etcd 较为繁琐。
它的 etcd 二进制查找顺序是：TORCHELASTIC_ETCD_BINARY_PATH环境变量 →<本文件目录>/bin/etcd→PATH中的etcd。用法：
from torch.distributed.elastic.rendezvous.etcd_server import EtcdServer server = EtcdServer() # 可选参数 data_dir 指定数据目录，缺省自动创建临时目录 server.start() # 在随机空闲端口上启动 etcd 子进程 client = server.get_client() # 获得 etcd client server.stop() # 停止子进程（同时有注册的退出清理回调兜底）重要警告：文档明确提示 EtcdServer 只适合测试/本地场景——对生产与多节点部署，请认真部署高可用的 etcd 集群，因为 etcd 是本类分布式任务的单点故障（single point of failure）。此外，包内 import 若找不到第三方etcd库会回退到_etcd_stub（见 _etcd_stub.py），说明以 etcd 为后端时该 Python 库仅用于客户端通信，而会合状态本身由服务端承载。
从配置到运行：这些参数在 torchrun 中如何体现
torchrun（入口见 torch/distributed/run.py）是消费上述抽象的最常见入口。其命令行参数--rdzv-backend、--rdzv-endpoint、--rdzv-id、--rdzv-conf（同义词--rdzv_backend/--rdzv_endpoint/--rdzv_id/--rdzv_conf）最终会被映射为RendezvousParameters并调用get_rendezvous_handler（run.py#L898-L1000 附近会依据--rdzv-conf解析出扩展配置）。其中：
--rdzv-backend=static时使用--master-addr/--master-port/--node-rank直接定位 TCPStore（见 static_tcp_rendezvous.py）；StaticTCPRendezvous本质上是 TCPStore 的薄封装——由rank 0的 agent 监听，store 以PrefixStore(run_id, store)隔离命名空间，其余方法（is_closed、set_closed、num_nodes_waiting）为空实现，因此它不提供弹性能力，适合排他式调度器下规模固定的任务。--rdzv-backend=c10d/etcd-v2则走完整动态会合，支持弹性扩容与 re-rendezvous。
完整示例：c10d 动态会合（推荐，无第三方依赖）
# 在每台参与训练的节点上执行（各节点共用相同 rdzv-id）： torchrun \ --rdzv-backend=c10d \ --rdzv-endpoint=192.168.1.10:29500 \ --rdzv-id=exp-001 \ --nnodes=2 \ --nproc-per-node=8 \ --max-restarts=3 \ train.py --config=/etc/train/exp-001.yaml192.168.1.10:29500即会合 TCPStore 的宿主地址；动态会合不要求各节点用相同的--rdzv-endpoint表达自身 rank，只要都指向同一个 store 即可自动发现彼此并协商出全局rank。
完整示例：etcd-v2 动态会合 + EtcdServer
# 测试/本地场景：用 EtcdServer 起一个 etcd，再以其为后端建立会合 import torch.distributed as dist from torch.distributed.elastic.rendezvous import rendezvous_handler_registry from torch.distributed.elastic.rendezvous.etcd_server import EtcdServer from torch.distributed.elastic.rendezvous.registry import get_rendezvous_handler from torch.distributed.elastic.rendezvous.api import RendezvousParameters server = EtcdServer() server.start() client = server.get_client() host, port = client.host, client.port params = RendezvousParameters( backend="etcd-v2", endpoint=f"{host}:{port}", run_id="job-0001", min_nodes=2, max_nodes=4, # 可选扩展参数：join_timeout=600, last_call_timeout=30, keep_alive_interval=5 等 ) handler = get_rendezvous_handler(params) try: info = handler.next_rendezvous() dist.init_process_group( "gloo", store=info.store, rank=info.rank, world_size=info.world_size, ) # ... 训练逻辑 ... finally: handler.shutdown() server.stop()小结：如何选择合适的后端
从 registry.py 与各实现的源码可以归纳出以下选型建议：
- 新任务首选
c10d：DynamicRendezvousHandler+C10dRendezvousBackend，无第三方依赖、支持弹性、单机多 worker 与多节点均适用（--rdzv-endpoint=localhost:0即可在单机场景自动找端口）。 - 已有 etcd 基础设施 / 需要服务端持久化会合状态：选
etcd-v2（DynamicRendezvousHandler+EtcdRendezvousBackend）。 - 规模固定、不需要弹性的任务：可用
static后端（torchrun 通过--master-addr/--master-port走StaticTCPRendezvous），但不具备迟到节点扩容能力。 etcd（旧版）：仅用于兼容存量任务，处于维护模式，官方建议迁移到etcd-v2。- 无论哪种后端，任务侧拿到的都是统一的
RendezvousInfo（store/rank/world_size/bootstrap_store_info）与标准dist.Store；自定义后端则通过rendezvous_handler_registry.register(...)接入全局注册表。
如需进一步阅读，可继续查看 TorchElastic 快速上手、自定义扩展指南、torchrun 启动器说明 以及 Kubernetes 上的部署指南，它们与本文共同构成 TorchElastic 从会合到完整训练任务编排的全链路参考。
【免费下载链接】pytorchTensors and Dynamic neural networks in Python with strong GPU acceleration项目地址: https://gitcode.com/GitHub_Trending/py/pytorch
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
