第 20 章 分布式部署

学习目标

• 掌握多副本、无状态/有状态服务的部署模式；
• 理解多区域、多集群、混合云、边缘协同的架构；
• 理解分布式推理（张量/流水/专家并行）的部署形态；
• 掌握服务网格与流量治理、故障隔离；
• 理解联邦推理、边缘-云协同、分层推理；
• 理解一致性、可用性、分区容忍与成本的权衡。

---

20.1 从单副本到多副本

第 16 章讲过扩缩容，这里讲部署拓扑。多副本（Replication） 是「水平扩展 + 高可用」的基础：同一模型服务跑多个副本，网关负载均衡分发。

无状态 vs 有状态是 LLM 服务的重要划分：

• 无状态服务：请求不依赖服务器本地状态——LLM 对话看起来「有状态」（多轮上下文），但上下文是随请求带来的（history 塞进请求），服务本身无状态，可以任意扩缩；
• 有状态服务：服务器保存会话/KV/缓存。LLM 里的「有状态」体现在前缀缓存与语义缓存（第 14、16 章）——缓存命中要路由到持有缓存的副本，这就把服务变「有状态」了。

%%{init: {"themeVariables": {"primaryTextColor": "#000000", "textColor": "#000000", "labelColor": "#000000", "nodeTextColor": "#000000", "labelTextColor": "#000000", "scaleLabelColor": "#000000"}}}%%
flowchart LR
    A[网关] --> B[副本1
模型+KV]
    A --> C[副本2
模型+KV]
    A --> D[副本3
模型+KV]
    B --> E[共享缓存层
Redis/分布式缓存]
    C --> E
    D --> E

一致性路由：靠「前缀 hash 路由」让相同会话/前缀的请求尽量落在同一副本，提高缓存命中——这是 LLM 分布式部署与 Web 服务的关键差别之一。

20.2 多区域、多集群、混合云、边缘协同

规模再往上，单集群不够：

拓扑	解决什么	代价
多集群（同区域）	故障域隔离、容量	流量调度复杂
多区域（跨地域）	就近延迟、灾难恢复	数据一致性、成本
混合云	弹性溢出（本地+公有云）	网络、治理异构
边缘协同	端边云分层（第 18 章）	分层路由复杂

%%{init: {"themeVariables": {"primaryTextColor": "#000000", "textColor": "#000000", "labelColor": "#000000", "nodeTextColor": "#000000", "labelTextColor": "#000000", "scaleLabelColor": "#000000"}}}%%
flowchart LR
    A[用户-华东] --> B[华东集群
主]
    C[用户-华北] --> D[华北集群]
    A -.故障.-> D
    B -.溢出.-> E[公有云弹性池]
    D -.溢出.-> E

LLM 多区域的特殊性：

• 模型是「重制品」：70B 权重 140GB，跨区域同步与加载是大数据搬运（镜像仓库 + 对象存储 CDN）；
• KV/缓存的区域隔离：缓存不跨区域（网络成本），但会话要在区域间迁移时要能重建上下文；
• 故障转移的代价：切区域 = 重新 Prefill（长上下文重算），TTFT 会跳变——多区域不是「免费的高可用」，是「花钱买可用性」。

20.3 分布式推理：张量、流水、专家并行

第 14 章是单机/单实例的推理优化，这里讲大模型放不下单卡时，推理怎么跨卡部署（第 10 章的并行策略在推理侧复用）：

并行	推理侧形态	关键点
张量并行（TP）	单请求跨卡算	机内 NVLink，低延迟；batch 小时通信占比高
流水并行（PP）	层切多卡	推理的 PP 有气泡，一般与 TP 组合
专家并行（EP）	MoE 跨卡路由	all-to-all 通信是瓶颈，跨机 EP 尤其

推理侧并行的取舍与训练不同：训练可以接受「慢一点但吞吐高」，推理要「低延迟」。所以推理的 TP 尽量机内（NVLink）、EP 尽量机内（all-to-all 贵）——跨机做推理并行要非常谨慎。

20.4 服务网格与流量治理、故障隔离

服务网格（Service Mesh）：把「服务间通信」从应用代码抽到独立数据面（sidecar）——熔断、重试、超时、流量切分、可观测性全部下沉到网格层（Istio 等）。LLM 服务网格的关注点：

• 流量治理：按模型版本、租户、请求类型分流（第 15 章路由 + 第 16 章金丝雀）；
• 故障隔离（Fault Isolation）：一个模型实例/集群故障不影响整体——熔断（快速失败）、降级（路由到备用模型）、隔离舱（某租户故障不拖累全平台）；
• 可观测性：全链路追踪（请求 → 网关 → 编排 → 引擎 → 检索）。

LLM 的故障模式特殊：不只「服务挂了」，还有「服务活着但质量崩了」（幻觉、越狱、成本失控）——第 23 章安全治理与第 21 章监控要把「质量故障」纳入熔断范畴。

20.5 联邦推理、边缘-云协同、分层推理

20.5.1 分层推理（Hierarchical Inference）

按请求难度分层路由到不同规模模型（第 15 章模型路由的规模化）：端侧小模型兜底简单请求 → 边侧中模型 → 云端大模型处理复杂请求。节省成本、控制延迟，是「端-边-云」协同的推理形态。

20.5.2 联邦推理（Federated Inference）

数据不出本地、推理也在本地做（或本地先做粗筛，敏感部分云端做）。与联邦学习（第 7 章）共享隐私动机：医疗、金融等数据不出域场景，模型可以共享但数据与推理结果不出域。挑战：端侧模型能力受限、更新要联邦分发。

20.5.3 边缘-云协同推理

把推理拆成「本地 + 远程」两步：端侧先做轻量理解（意图、去隐私），把需要大模型的部分（匿名化后）送云端——既保隐私、又保能力、又省带宽。

20.6 一致性、可用性、分区容忍与成本

CAP 定理在 LLM 服务里的变体：

• 一致性（Consistency）：多副本间行为一致（同 Prompt 同版本应同结果）——模型确定性（temperature=0）+ 版本一致（第 19 章）；
• 可用性（Availability）：服务持续可用——多副本、多区域、故障转移；
• 分区容忍（Partition Tolerance）：网络分区时系统仍工作——LLM 多区域的现实：分区时各区独立服务（牺牲「全局一致」换「本地可用」）；
• 成本（Cost）：这一切的约束——多副本、多区域、多集群都是「用钱买可用性」。

%%{init: {"themeVariables": {"primaryTextColor": "#000000", "textColor": "#000000", "labelColor": "#000000", "nodeTextColor": "#000000", "labelTextColor": "#000000", "scaleLabelColor": "#000000"}}}%%
flowchart TD
    A[高可用目标] --> B[多副本
成本+]
    A --> C[多区域
成本++]
    A --> D[故障隔离
复杂度+]
    B --> E{预算够吗?}
    C --> E
    D --> E
    E -->|否| F[降级方案
单区域+弹性池]

工程铁律：分布式部署的每一步都要回答「花了多少钱买到了多少可用性」——SLA 是预算的镜像（第 21 章错误预算）。不要为了「听起来高可用」而堆多区域。

---

本章要点回顾

1. LLM 服务「看起来有状态实则无状态」：上下文随请求走；缓存才是有状态，要一致性路由。
2. 多区域是「花钱买可用性」：重制品同步、缓存不跨域、故障切换要重 Prefill。
3. 推理侧并行（TP/PP/EP）尽量机内，跨机要谨慎（低延迟约束）。
4. 服务网格把熔断/重试/流量治理/可观测性下沉；质量故障（幻觉/成本）也要纳入熔断。
5. 分层推理（端-边-云按难度路由）、联邦推理（数据不出域）、边缘协同（本地粗筛云端精算）是三种分布式推理形态。
6. CAP 在 LLM 的体现：分区时各区独立服务，用「全局一致」换「本地可用」；一切可用性都是预算买来的。

习题

1. 你的对话服务要跨区域部署，用户可能切区续聊。设计会话上下文跨区迁移方案（提示：重建 vs 缓存迁移）。
2. 设计一个「端-边-云」分层推理架构：难度怎么判定？各层模型多大？成本与延迟如何权衡？
3. 为什么推理的 TP 尽量机内？用「batch 小时通信占比」分析 70B TP=8 跨机 vs 机内的差别。
4. 金融客户要求数据不出域，但想用你的 70B 旗舰模型。设计联邦推理/边缘协同方案。
5. 画出你的 LLM 服务的故障隔离策略：什么故障熔断、什么降级、什么隔离舱。

延伸阅读

• Istio / Linkerd 服务网格文档
• 各云厂商多区域部署白皮书
• NVIDIA TensorRT-LLM 多卡并行文档
• DeepSeek-V3 技术报告（MoE 推理与 EP 部署）
• AWS/GCP 的 Edge-Cloud 推理架构参考

下一章预告

第 7 篇「监控、运维与治理」：第 21 章监控体系（系统/服务/模型/业务四层指标）、第 22 章模型可观测性（漂移、异常、LLM 的 Prompt/Token/RAG/工具可观测性）、第 23 章可靠性安全与治理（SLO/错误预算、混沌工程、安全隐私合规）。