Anthropic 面试题：将模型权重分发到 GPU 集群

针对 Anthropic 模型权重分发题目的完整解答：下界、朴素拉取、树形广播、流水线分块、节点群（peer swarm）、无协调者恢复、校验，以及就绪门控路由。

由 The Forward Deployed 编辑团队审阅

本文属于 Anthropic 系统设计题库。该题目具有该轮面试的代表性。分析与解答为本站原创。

问题描述

该系统将一个大文件从一个源分发到多个目的地，校验每一份副本，将其加载到 GPU 上，并告知流量路由器哪些主机已就绪。模型训练和推理服务引擎本身不在讨论范围内。

澄清问题

• 带宽的单位是什么？ 千兆比特（Gigabit）和千兆字节（Gigabyte）相差 8 倍，这个错误会波及每一个答案。在做任何计算之前先确认。
• 链路是全双工的吗？ 一台主机能否同时以全速上传和下载，还是两者共享一个带宽预算？这会改变树形结构的计算。
• 文件有多大，有多少台主机？ 练习设定：400 GB、200 台主机，追问场景为 1,000 台主机。
• 网络拓扑是什么样的？ 是扁平网络，还是机架之间链路较慢的分层结构？
• 新版本发布的频率如何？ 每小时更新与每月更新相比，会改变设计方案。
• 应该假设怎样的故障率？ 练习设定：一次发布过程中 1% 到 5% 的主机发生故障。

分发为什么难

源只有一条链路。数百台主机各自需要完整文件。如果每份副本都来自源，源链路就要承载数百份完整副本，从而成为瓶颈。其他所有链路都闲置着。

其余链路是未被利用的容量。每一台已持有数据的主机都有一条闲置的上传链路。设计问题在于如何让所有这些链路同时工作，同时还要应对主机故障和部分链路较慢的情况。

因此，核心矛盾是协调与并行之间的权衡。越多主机并行共享越多分片，就越接近物理极限，但也需要更多协调：谁有什么、谁发给谁。

flowchart LR S[(Source<br/>one link)]:::store --> H1[Host 1]:::svc S --> H2[Host 2]:::svc S --> H3[Host ...]:::svc S --> H4[Host 200]:::svc H1 -. idle upload .-> X((unused)):::bad classDef svc fill:#f4f1e8,stroke:#315e55,color:#171717; classDef store fill:#fdf3dc,stroke:#c4492d,color:#171717; classDef bad fill:#fbe9e4,stroke:#c4492d,color:#171717;

核心思想。 分发受链路限制。源链路只有一条，而主机的上传链路有数百条。好的设计要让所有链路都保持忙碌。

关键概念

下界

在任何设计之前，先计算任何设计的最佳上限。每台主机必须通过自己的下载链路接收每一个字节。如果文件大小为 S 字节，链路速率为每秒 B 字节，那么任何主机都不可能在 S / B 之前完成。这就是目标。

存储转发与流水线

在存储转发模式下，主机先接收完整文件，再向外发送。在流水线模式下，主机每收到一个分片就立即转发。流水线把一整串“等完整文件”变成一串“等小分片”。

分块与清单

将文件切分成块，例如 64 MB。清单列出每个块及其哈希，并由源端签名。主机可以独立验证每个块、从任意对等节点获取块，并在崩溃后只补取缺失的块来恢复。

最稀有优先

在一个集群中，每台主机选择下一个要获取的块。获取持有者最少的块能让每个块迅速扩散，并避免出现只剩源端还持有的最后一块。

关键思想。 先计算下界。然后对文件分块，使主机能够流水线传输、验证，并从任何节点获取。

需求

在继续阅读之前。 列出需求。然后说出你绝不能违反的性质，以及决定设计的约束。

1.1 功能需求

• 将新的检查点从一个源分发到集群中的每台主机。
• 验证每台主机上的每一个字节。
• 在主机故障和慢速链路下无需运维人员干预即可存活。
• 将验证过的权重加载到 GPU 上，并按模型版本报告就绪状态。
• 只向已就绪所请求版本的主机发送流量。

1.2 非功能需求

• 速度。 完成时间接近下界。
• 正确性。 任何主机都绝不提供损坏或错误版本的权重。
• 韧性。 5% 的主机故障率只会略微拖慢发布，绝不会使其停止。
• 可观测性。 运维人员可以查看每台主机的进度，并在几秒内找到卡住的主机。

1.3 约束与性质

正确性是性质。 提供损坏权重的主机会悄悄产生错误答案，这比发布缓慢更糟糕。链路带宽是约束。 每个设计都以它能让所有链路保持繁忙的程度来衡量。

关键思想。 绝不提供坏权重。设计要让每条链路都保持繁忙。

粗略估算

练习：一个 400 GB 的检查点，200 台主机，每台主机和源端都有 10 Gbps 全双工链路。10 Gbps 即 1.25 GB/s。

2.1 下界

400 GB / 1.25 GB/s = 320 秒，略超过五分钟。任何设计都无法超越这个下界。

2.2 朴素拉取

每台主机都从源端下载。源端必须发送 200 × 400 GB = 80 TB。按 1.25 GB/s 计算，需要 64,000 秒，接近 18 小时。

2.3 二叉树，存储转发

源主机将完整文件发送给两台主机。这两台主机各自再发送给两台，以此类推。一台主机同时向两个子节点发送，因此每个子节点获得一半的上行带宽，每一层耗时 2 × 320 = 640 秒。七层可覆盖 2 + 4 + ... + 128 = 254 台主机，足以覆盖 200 台。总计：7 × 640 = 4,480 秒，约 75 分钟。

2.4 流水线分块

按 64 MB 分块，文件共有 400 GB / 64 MB = 6,250 个块。一个块通过一条链路需要 64 MB / 1.25 GB/s ≈ 0.05 秒。在深度为 d 的流水线链中，最后一台主机约在 320 秒加上 d × 0.05 秒时完成。即使深度达到 200，也只增加 10 秒。该设计已接近理论上限，误差仅几个百分点。

2.5 在 1,000 台主机的场景

理论上限不变：320 秒。朴素的拉取方式增长到 90 小时。二叉树需要 9 或 10 层，约 100 分钟。流水线集群仍保持在 320 秒左右，因为每台新主机在带来需求的同时也带来了上传能力。这就是点对点架构的扩展性论据。

核心思想。 320 秒是理论上限，18 小时是朴素方案，75 分钟是树形方案，而流水线集群在任何集群规模下都能在数秒内逼近理论上限。

API 设计

系统分为控制平面和数据平面。

3.1 控制平面

POST /v1/rollouts
  {model_version, manifest_ref, target_hosts: selector, max_concurrent_loads}
  -> {rollout_id}
GET  /v1/rollouts/:id
  -> {hosts_total, hosts_downloading, hosts_verified, hosts_ready,
      hosts_failed, bytes_total, bytes_done, stuck_hosts[]}
POST /v1/rollouts/:id/pause | resume | abort

3.2 节点间的数据平面

GET  /chunks/:model_version/bitmap        -> bitmap of chunks this host holds
GET  /chunks/:model_version/:chunk_index  -> chunk bytes (range requests allowed)
POST /peers/gossip                        {host_id, model_version, bitmap_digest, peers_seen[]}

3.3 就绪状态

GET /health/ready?model_version=v42
  -> 200 only if weights for v42 are fully verified, loaded on GPUs,
     and a smoke-test prompt returned a sane answer

核心思想。 运维人员与发布流程交互。主机之间以分块方式通信。路由器与就绪检查交互，以验证正确的版本已加载。

数据模型

manifest (signed by the source)
  model_version, total_size, chunk_size,
  chunks: [{index, sha256, size}], signature

host state (local disk + memory)
  model_version, bitmap[6250], chunk files on NVMe,
  in_flight: {chunk_index -> peer, started_at},
  peer_stats: {peer_id -> throughput, failures, last_seen}

rollout (control plane DB)
  rollout_id, model_version, status, created_at
rollout_host
  rollout_id, host_id, state: pending|downloading|verified|loading|ready|failed,
  bytes_done, last_progress_at, error

位图很小：6,250 位不到 1 KB，因此主机可以频繁共享它。

高层设计

5.1 每台主机从源主机拉取

flowchart LR S[(Source)]:::store --> H1[Host 1]:::svc S --> H2[Host 2]:::svc S --> H3[Host 200]:::svc classDef svc fill:#f4f1e8,stroke:#315e55,color:#171717; classDef store fill:#fdf3dc,stroke:#c4492d,color:#171717;

这种方式很简单，但需要 18 小时，因为源链路要承载每一份副本。

5.2 修复方案 1：主机以树形结构相互转发

每台拥有文件的主机将其发送给另外两台。

flowchart TB S[(Source)]:::store --> A[Host A]:::new S --> B[Host B]:::new A --> C[Host C]:::new A --> D[Host D]:::new B --> E[Host E]:::new B --> F[Host F]:::new classDef store fill:#fdf3dc,stroke:#c4492d,color:#171717; classDef new fill:#ffffff,stroke:#c4492d,stroke-width:2px,stroke-dasharray:5 3,color:#171717;

这样源主机只需发送两份副本，副本数量每层翻倍。但每台主机必须等待完整文件后才能转发，而叶子主机（约占集群的一半）完全不参与上传。耗时 75 分钟。

5.3 修复方案 2：分块并流水线化

将文件拆分为多个块，每块一到就立即转发。主机在接收第 2 块的同时，就开始向子节点发送第 1 块。

sequenceDiagram participant S as Source participant A as Host A participant C as Host C S->>A: chunk 1 S->>A: chunk 2 A->>C: chunk 1 S->>A: chunk 3 A->>C: chunk 2 Note over S,C: 每条链路同时都在忙碌

树形结构中每层的整文件等待时间缩短为一个分片时间。但树很脆弱：如果主机 A 宕机，它的整个子树都会停滞。而且叶子节点仍然从不上传。

5.4 修复 3：一个 swarm（集群）

抛弃固定的树。每台主机从任何拥有缺失分片的对等节点获取该分片，并向任何请求的对等节点提供它持有的分片。主机优先获取最稀有的分片，并同时从不同的对等节点保持多个下载进行中。

flowchart LR S[(Source)]:::store --> H1[Host]:::svc S --> H2[Host]:::svc H1 <--> H2 H1 <--> H3[Host]:::svc H2 <--> H4[Host]:::svc H3 <--> H4 H3 <--> H5[Host]:::svc H4 <--> H5 classDef svc fill:#f4f1e8,stroke:#315e55,color:#171717; classDef store fill:#fdf3dc,stroke:#c4492d,color:#171717;

每台主机都上传，包括最后加入的，因此上传容量随集群增长。没有单台主机故障会让任何人停滞，因为每个分片都有多个来源。

5.5 修复 4：验证、加载与就绪

只有当分片的哈希与签名的清单匹配时，它才算有效。当所有分片都验证通过后，主机将权重加载到其 GPU 上，运行一个冒烟测试提示，并针对该确切版本报告就绪。路由器只将某个版本的流量发送到报告对该版本就绪的主机。

5.6 组合后的设计

sequenceDiagram
  autonumber
  participant Op as Operator
  participant CP as Control plane
  participant H as Host
  participant P as Peers
  participant R as Router
  Op->>CP: start rollout v42
  CP->>H: manifest ref + seed peer list
  H->>H: verify manifest signature
  loop until all chunks held
    H->>P: exchange bitmaps (gossip)
    H->>P: fetch rarest missing chunks
    H->>H: verify each chunk hash
    H-->>P: serve held chunks to others
  end
  H->>H: load weights to GPUs, smoke test
  H->>CP: ready v42
  CP->>R: host ready for v42
  R->>H: route v42 traffic

关键思想。 从物理规律出发，用转发消除源瓶颈，用分片消除整文件等待，用 swarm 消除脆弱的树，并以验证后的就绪状态来控制流量。

深入探讨

6.1 有协调器还是无协调器

在继续阅读之前。 你的 swarm 使用一个中央追踪器来分配分片并跟踪进度。面试官把它移除了。主机如何发现对等节点、检测失效节点，并恢复它们未完成的分片？

中央追踪器很容易解释。它知道每台主机的位图，为每台主机分配对等节点和分片列表，并在某台主机失去响应时重新分配工作。但它也是单点故障和扩展热点。

没有它，主机通过 gossip（流言协议）通信。大约每隔一秒，每台主机向几个随机对等节点发送一条小消息：它的位图摘要以及它最近听说过的对等节点。信息在集群中传播所需的轮数随主机数量的对数增长。每台主机构建一个关于谁持有哪些分片的本地视图。

故障检测来自同样的消息。如果一个对等节点错过了几轮 gossip 并且不再响应分片请求，邻居会将它标记为死亡。主机从该死亡节点获取的任何分片都会回到其缺失集合中，并从其他人那里获取。对于没有其他人持有的任何分片，源服务器仍作为后备可达。

区分答案的关键：协调

弱：需要协调器才能工作

无法说明追踪器失效后集群如何继续运作。

GoodGossip 用于成员关系和位图

通过 gossip 解释节点发现和故障检测，并以源站作为兜底。

Strong 同时权衡两者并给出收敛上界

保留一个可选的追踪器以提升速度和可观测性，在其失效时回退到 gossip，并解释为什么 gossip 能以对数轮数传播状态。

6.2 慢节点与终局阶段

在继续阅读之前。 199 台主机在 330 秒内完成。一台主机却花了 20 分钟。为什么？如何修复？

常见原因有两个。该主机从慢节点拉取数据，例如网卡性能退化的节点，并因此等待。或者它是最后还需要几个稀有分块的节点，而这些分块只存在于负载过重的节点上。

修复方法：

• 跟踪每个节点的吞吐量。 剔除传输速度远低于中位数的节点，并在重试前进行指数退避。
• 同时保持多个在途请求。 这样慢节点只会延迟一个请求，其余请求继续进行。
• 终局模式。 当一台主机只剩少量分块时，它同时向多个节点请求每个剩余分块，并在第一份副本到达时取消重复请求。少量浪费换来可预期的完成时间。

6.3 机架与拓扑

数据中心通常在机架内部有高速链路，而机架之间是较慢的共享链路。如果随机选择节点，大部分分块流量会跨机架传输，使这些链路过载。

让节点选择具备拓扑感知。优先选择同一机架内的节点。让每个机架中少量主机从其他机架拉取每个分块，然后在机架内部传播。这样跨机架流量大约每个机架只承载一份副本，而不是每台主机一份。

flowchart LR
  subgraph R1["Rack 1"]
    A1[Host]:::svc <--> A2[Host]:::svc
    A2 <--> A3[Host]:::svc
  end
  subgraph R2["Rack 2"]
    B1[Host]:::svc <--> B2[Host]:::svc
    B2 <--> B3[Host]:::svc
  end
  A1 <-->|one cross-rack flow per chunk| B1
  classDef svc fill:#f4f1e8,stroke:#315e55,color:#171717;

6.4 校验与坏数据

源站对清单进行签名。每台主机在信任任何分块哈希之前都会先校验签名。每个分块在到达时都会计算哈希，不匹配则丢弃该分块并从其他节点重新拉取。发送多个坏分块的节点会被隔离：其他主机停止从它拉取数据，控制平面将其标记为待修复，因为坏磁盘或内存故障通常是原因所在。

校验还能防范最严重的运维失误：一台主机加载了两个版本的混合内容。每个分块在其路径中携带模型版本，而清单哈希将它们绑定在一起。

6.5 就绪门控路由

在继续阅读之前。 发布进行到一半。一个针对 v42 的请求到达。路由器如何避开那些已有文件但尚未加载的主机，或仍在服务 v41 的主机？

就绪状态是按版本维护的，由主机在验证完所有分块、将权重加载到 GPU 并通过冒烟测试后上报。路由器维护一个从模型版本到就绪主机的映射，并只路由到该集合。仍在加载中的主机既不出现在 v42 集合中，一旦卸载 v41，也不再出现在 v41 集合中。

滚动发布应保持容量。在部分主机上加载新版本，其余主机继续运行旧版本，随着主机就绪逐步转移流量，然后继续推进。绝不能从主机上卸载旧版本的数量超过剩余主机所能承接的量。

6.6 可观测性

运维人员需要一个屏幕：按状态分类的主机、已完成的字节数、预计完成时间，以及卡住的主机列表。当一台主机的字节数在设定时间内（例如 30 秒）没有变化时，即视为卡住。对于每台卡住的主机，显示其对等节点及其吞吐量，这通常能在几秒内指向原因。要区分一台慢的主机和一台因磁盘已满或 GPU 故障而等待的主机，因为两者的修复方法不同。

6.7 分块大小

在继续阅读之前。 为什么是 64 MB？1 MB 的分块会出什么问题？4 GB 的分块又会出什么问题？

分块大小是在流水线延迟与开销之间做权衡。

小分块缩短流水线：一个分块快速跨越一跳，数据因此更早到达集群的远端。但每个分块都有固定成本：一次请求、一次哈希校验、位图记账以及 gossip 字节。使用 1 MB 分块时，一个 400 GB 的文件有 40 万个分块。位图增长到每台主机 50 KB，gossip 携带更多数据，每次请求的开销开始侵蚀带宽。

大分块降低开销，但拉长流水线，且在失败时浪费更多。一个 4 GB 的分块在 1.25 GB/s 下每跳需要 3.2 秒；在 20 跳的深度上，这会增加约一分钟。一个在分块中途宕机的对等节点最多会浪费 4 GB 的传输。而一个只有 100 个分块的文件，rarest-first 策略可用的块太少，难以扩散。

折中之下，16 到 256 MB 是常见范围。在 64 MB 时，每跳时间为 0.05 秒，位图不足 1 KB，一次丢失的传输最多浪费 64 MB。要说明这个数字来自上述权衡，并且你会通过在测试集群上测量完成时间来调优它。

6.8 集群时间线实例

为集群给出具体数字，以展示它确实逼近理论上限。

• t = 0 秒。 200 台主机收到签名的清单和对等节点种子列表。所有位图为空。源开始以 rarest-first 方式向不同主机发送不同分块，因此没有两台主机以相同的分块开始。
• t = 0 到 10 秒。 源推送约 12.5 GB，约 195 个分块，每个分块发送给一台主机。现在每个分块都在源之外的一个位置存在。
• t = 10 到 30 秒。 主机交换位图并相互获取数据。早期分块的副本数量大约每个分块时间翻一倍。现在每台主机都以接近全速下载，同时从多个对等节点获取，并上传自己持有的分块。
• 稳态。 每台主机以约 1.25 GB/s 下载并以大致相同的速率上传，因为它收到的每个分块都被其他主机需要。源继续以全速注入新分块。
• t ≈ 320 秒。 源已将每个分块至少发送一次。大多数主机已持有几乎整个文件。
• t ≈ 320 到 340 秒。 终局阶段：主机同时从多个对等节点获取最后几个分块。最慢的主机完成下载。

总时间在 320 秒下界的大约 5% 以内，而途中 5% 的主机失败影响不大，因为到那时每个分块已有许多持有者。

变体

7.1 共享的上传和下载带宽预算

如果上传和下载共享同一条链路预算，全速上传的主机就无法全速下载。下界随之改变：集群的总链路容量必须承载大约每台主机一次下载，再加上为其提供数据的上传。集群仍然占优，但完成时间大约是全双工情况的两倍。先陈述新的下界，再给出新的设计。

7.2 频繁更新

如果每隔几小时就发布一个新版本，而大部分权重变化很小，则只发送哈希发生变化的分块。主机保留上一版本的分块并获取差异部分。通过在版本正式发布流量之前就开始传输来进行预热。

7.3 太字节级检查点

在几个太字节的规模下，本地磁盘空间和加载时间与带宽一样成为限制因素。在服务引擎支持的情况下，将分块直接流入 GPU 显存，并将加载分片到多块 GPU 上并行进行。

7.4 集群规模扩大十倍

在 2,000 台主机的情况下，下界仍是 320 秒，集群也仍接近该下界，因为每台新主机都会增加上传容量。变化的是协调。Gossip 仍以对数轮数收敛，只是比 200 台主机时多几轮。跨机架和跨楼宇的链路成为瓶颈，因此感知拓扑的对等节点选择变得至关重要。控制平面的发布视图显示百分比和卡住主机的列表，因为没人会去读 2,000 行数据。路由器按就绪主机的百分比分步切换流量，而不是等待全部就绪。

可迁移的模式

权重分发是带对等放大的广播：一个源，多个接收者，而接收者会成为发送者。同样的形态适用于容器镜像分发、训练数据集准备、游戏补丁以及跨机群的软件更新。这个方法可以迁移：计算下界，找出闲置容量，分块以流水线化，并验证一切。

回顾：30 秒答案

• 先算下界。 文件大小除以链路速度：这里是 320 秒。
• 朴素拉取需要 18 小时；树形分发需要 75 分钟。 原因是源链路和整文件等待。
• 分块、流水线、集群化。 每台主机都上传，优先处理最稀有的分块，同时连接多个对等节点。
• 在没有协调者的情况下存活。 Gossip 位图和存活检测；源作为后备。
• 验证并设门。 签名的清单、逐分块哈希，以及只将流量路由到已为该版本就绪的主机。

测验

+为什么要在设计之前先计算下界？

它为每种设计提供了一个衡量标准。在这里，任何主机都不可能在文件大小除以链路速度（即 320 秒）之前完成。75 分钟的设计显然远非最优，而 330 秒的设计则明显接近极限。

+为什么存储转发树很慢？

每台主机必须先接收完整文件才能转发，因此每一层都会增加一次完整的文件传输时间，而共享的上传链路会使时间翻倍。作为叶子节点的主机（占集群的一半）则完全不进行上传。

+分块如何接近这个下限？

主机在收到每个数据块后立即转发，因此每条链路都在同时工作。流水线在单文件传输时间之上，每跳只增加一个数据块的传输时间，仅为几分之一秒。

+为什么优先获取最稀有的数据块？

这样可以让每个数据块迅速扩散到多台主机上，从而避免在最后阶段出现某个数据块只掌握在源节点或少数负载过重的节点手中的情况。

+路由器在将 v42 流量发送到某台主机之前，必须满足什么条件？

每个数据块都已对照签名清单完成校验，权重已加载到 GPU 上，冒烟测试已通过，并且该主机已明确报告已为 v42 准备就绪。

+非常小的数据块会带来什么问题？

每个数据块的开销会增长：更多的请求、更多的哈希校验、更大的位图，以及更多的 gossip 流量。到某个程度时，这些开销会占用相当大比例的带宽。

+为什么随着集群规模扩大，集群仍能保持接近下限？

每台新主机在带来需求的同时也增加了上传容量。总传输容量随主机数量增长，因此每台主机的传输时间始终接近文件大小除以链路速度。

资料来源与延伸阅读

• BitTorrent 协议规范（BEP 3） 描述了分片、哈希和节点交换。
• Incentives Build Robustness in BitTorrent 解释了最稀有优先的分片选择策略和终局行为。
• Dragonfly 是一个开源的点对点分发系统，用于大型集群中的容器镜像和模型文件。
• 使用就绪状态的路由器设计于 LLM inference API with GPU batching。Deployment 涵盖了就绪门控和回滚。

NextOne-to-One Chat System