8. 企业生产实践
分布式系统理论最终要落地到 AI 生产集群。本章把前面章节的抽象概念，映射到训练、推理、存储、编排四个真实场景中。
8.1 分布式训练中的集合通信
8.1.1 数据并行 vs 模型并行 vs 流水线并行
| 并行方式 | 切分对象 | 通信模式 | 适用场景 |
|---|---|---|---|
| 数据并行 | 数据 batch | all-reduce 梯度 | 模型可放入单卡显存 |
| 模型并行 / 张量并行 | 模型层内参数 | all-gather / reduce-scatter | 单卡放不下整个层 |
| 流水线并行 | 模型层间 | point-to-point | 超大模型，层间流水线 |
| 专家并行（MoE） | 专家路由 | all-to-all | Mixture-of-Experts 模型 |
8.1.2 通信拓扑与算法
- Ring all-reduce：把梯度拆成 N 份，沿环传递，通信量与节点数无关；
- Tree all-reduce：层次化聚合，降低延迟；
- Hierarchical all-reduce：跨机用 RDMA/NCCL，机内用 NVLink；
- Reduce-scatter + all-gather：常用于张量并行。
8.1.3 容错与弹性
生产训练常遇到的故障：
- GPU 掉卡、Xid 错误；
- NCCL 超时；
- 节点 OOM；
- 网络抖动导致 straggler。
应对：
- Checkpoint 频率：平衡 IO 开销与恢复时间；
- 弹性训练：PyTorch Elastic、Kubernetes Volcano、Ray Train；
- Health check：NCCL watchdog、GPU 温度/ECC 监控；
- 重试与隔离：失败节点暂时隔离，任务迁移到其他节点。
8.2 推理服务的多副本一致性
8.2.1 状态共享问题
多副本 LLM 推理面临：
- 是否共享 KV Cache？
- 如何保持模型版本一致？
- 长连接断开后如何恢复上下文？
常见方案：
| 方案 | 一致性 | 复杂度 | 适用 |
|---|---|---|---|
| 每个副本独立 KV Cache | 最终一致（请求固定副本） | 低 | 无状态负载均衡 |
| 分布式 KV Cache（如 vLLM 的 TP/PP） | 强一致 | 高 | 大模型单实例内并行 |
| 外部缓存（Redis） | 最终一致 | 中 | 会话状态、前缀缓存 |
8.2.2 路由与故障转移
- Round-robin：简单，但可能把长请求集中到同一副本；
- Least loaded：根据当前请求数或 token 生成速度路由；
- Session sticky：同一用户固定到同一副本，便于缓存命中；
- Circuit breaker：副本异常时快速摘除，防止拖垮整体。
8.3 Kubernetes 控制面调优
etcd 是 K8s 的“单一事实来源”，它的健康决定整个集群健康。
8.3.1 etcd 部署建议
- 节点数：3（容忍 1 故障）或 5（容忍 2 故障）；
- 跨可用区部署，避免 AZ 级故障；
- 使用 SSD，WAL 与数据目录分离；
- 限制单个 key/value 大小，避免大对象拖垮 Raft；
- 定期 defrag 与 snapshot。
8.3.2 apiserver 与 controller
- apiserver 是无状态的，可水平扩展；
- controller 用 leader election，同一时间只有一个 active；
- watch 机制让各组件实时感知状态变化；
- 大规模集群要调大
--max-requests-inflight和--max-mutating-requests-inflight。
8.4 对象存储与多 AZ 复制
AI 训练数据、checkpoint、模型 artifact 通常存放在对象存储。
8.4.1 一致性级别选择
| 场景 | 推荐一致性 | 原因 |
|---|---|---|
| checkpoint 元数据 | 强一致 | 恢复时必须读到最新索引 |
| 训练数据只读副本 | 最终一致 | 数据不变，复制延迟可接受 |
| 模型版本注册 | 强一致 | 避免读取到未完成的 artifact |
| 推理日志/指标 | 最终一致 | 可容忍秒级延迟 |
8.4.2 跨区域复制
- 主动-被动：主区域写，其他区域异步复制，故障时手动切换；
- 主动-主动：多区域同时写，需要冲突解决；
- 近线复制：热数据就近读取，冷数据归档到低成本存储。
8.5 故障域与爆炸半径
8.5.1 分层故障域
text
GPU → 节点 → 机柜 → 机架 → 可用区 → 区域关键设计原则：
- 控制面副本跨 AZ；
- 训练 job 的 worker 尽量分散到不同机架；
- 存储副本跨 AZ，重要数据跨区域；
- 单点服务（如 scheduler）要有热备或 leader election。
8.5.2 爆炸半径控制
- Namespace / 租户隔离：一个租户的异常不影响其他租户；
- 资源配额与限流：防止单个 job 占满网络或存储带宽；
- 熔断与降级：推理服务某副本卡顿时，快速熔断并返回降级结果；
- 混沌工程：定期注入故障，验证系统韧性。
8.6 一句话总结
生产级 AI 基础设施的分布式系统实践，核心是把“共识、复制、分区、超时”落到实处：训练用 all-reduce 和 checkpoint 保证进度，推理用多副本和路由保证可用，K8s 用 etcd/Raft 保证状态一致，存储用多 AZ 复制保证耐久，最终目标是在任何故障域下控制爆炸半径。