1. 背景

AI Infra 工程师的日常，本质上都在和分布式系统打交道。无论你在调训练集群、排障 Kubernetes、优化推理服务，还是设计存储架构，最终都会遇到同一类问题：

• 多台机器如何协同完成一件事？
• 当网络断了、节点挂了、消息丢了，系统还能不能继续工作？
• 多个副本之间的数据如何才能一致？

本章从这三个问题出发，解释为什么分布式系统是 AI 基础设施不可回避的底座。

1.1 为什么 AI 基础设施必然是分布式的

1.1.1 算力规模要求分布式

大模型训练需要数千甚至数万张 GPU。单台机器放不下一个模型，更放不下一个训练任务。

• GPT-4、Claude 4、Llama 4 级别的模型参数规模达到数百亿到数万亿；
• 一张 GPU 的显存只有几十到几百 GB；
• 训练数据需要 PB 级存储，必须分散在多个节点上。

因此，模型、数据、计算都必须被切分到多台机器上。

1.1.2 服务可用性要求分布式

在线推理服务不能靠单台机器支撑：

• 单点故障会导致服务中断；
• 单台 GPU 的吞吐有限，需要多副本并行；
• 用户请求来自全球，需要多区域部署。

分布式部署带来冗余，但也带来状态同步、路由、故障转移等复杂问题。

1.1.3 数据持久化要求分布式

AI 训练产生海量数据：

• checkpoint 文件大小从 GB 到 TB；
• 训练数据集通常是 PB 级；
• artifact、日志、指标需要长期保存。

这些数据必须被复制到多个节点、机架、可用区，以保证耐久性和可用性。

1.2 AI Infra 中的分布式问题

1.2.1 分布式训练协调

一次分布式训练 job 涉及数千个 worker：

• 如何发现彼此并组成通信组？
• 如何同步梯度（all-reduce）？
• 某个 worker 慢了怎么办（straggler）？
• 某个节点挂了，如何 checkpoint 回滚？

这些问题都属于分布式协调。

1.2.2 控制面一致性

Kubernetes 的 etcd、Ray 的 GCS、KubeRay 的 controller 都需要维护集群状态：

• 多个 controller 同时 watch 同一个资源，如何保证状态一致？
• leader 切换时如何不丢事件？
• 网络分区时如何避免脑裂？

这些问题都属于共识与复制。

1.2.3 推理服务多副本

一个 LLM 推理服务通常部署多个副本：

• 请求如何路由到不同副本？
• KV Cache 是否需要在副本间共享？
• 某个副本卡住或 OOM，如何快速摘除？

这些问题都属于分区容错与负载均衡。

1.2.4 存储一致性与耐久性

对象存储和并行文件系统需要在多个副本间保持一致：

• 写入一个对象后，多久能被其他节点读到？
• 某个副本损坏，如何恢复？
• 跨区域复制时，选择强一致还是最终一致？

这些问题都属于一致性模型与复制协议。

1.3 分布式系统的核心挑战

分布式系统之所以难，是因为它要面对一组单机系统不存在的根本问题：

挑战	含义	AI Infra 例子
网络分区	节点之间无法通信	训练集群中某个机架交换机故障
节点故障	机器宕机或进程崩溃	GPU 节点掉卡、kubelet 失联
消息延迟/丢失	消息可能迟到或丢失	RPC 超时、etcd watch 延迟
时钟不一致	不同机器时间不同步	日志排序、事件因果判断
部分失败	部分成功、部分失败	checkpoint 部分 shard 写入失败
不确定性	同样输入可能产生不同结果	网络抖动导致超时重试

1.4 一句话总结

AI 基础设施的规模、可用性和数据量决定了它必然是分布式的；而分布式系统的设计目标，就是在“不可靠的部件”之上构建“可靠的整体”。