哈佛-CS249r-机器学习系统第二卷-五-

哈佛 CS249r：机器学习系统第二卷（五）

原文：Machine-Learning-Systems-Vol2

译者：飞龙

协议：CC BY-NC-SA 4.0

• 每用户的 KV 缓存：2000 + 500（平均响应）= 2,500 标记

• 总 KV 缓存：2,500 标记 × 1000 × 2 × 80 × 8192 × 2 = 6.6 TB

有前缀缓存：

• 共享前缀：2,000 标记（一次）

• 每用户唯一部分：500 标记

• 总计：(2000 × 1) + (500 × 1000) = 502,000

• 内存：502,000 × 2 × 80 × 8192 × 2 = 1.3 TB

结果：前缀缓存实现了 KV 缓存内存减少 79.9%，使得可同时服务的用户数量增加 5 倍。

系统洞察：当前缀命中率高时，前缀缓存效果显著，因为许多请求共享一个长前缀。表 10.18 对比了不同工作负载的命中率和内存节省，展示了该技术在何处提升服务容量以及何处无效。

| 工作负载 | 前缀命中率 | 内存节省 |

| :--- | :--- | :--- |

| 聊天机器人（相同系统提示） | 95%+ | 70-80% |

| 文档问答（相同文档） | 80-90% | 50-70% |

| 通用 API（多样化） | 20–40% | 10–30% |

表 10.18：按工作负载划分的前缀缓存效果：聊天机器人、文档问答和通用 API 工作负载的典型前缀命中率及由此产生的 KV 缓存内存节省，展示了前缀缓存何时有效及何时无效。

KV 缓存压缩与架构优化

上述容量技术能够容忍缓存；而压缩则进一步缩小其规模。此处的计算基于 64 KV 头多头注意力基线，以便分组查询注意力小节能够将头数减少作为单独的架构杠杆进行隔离。对于一个参数量为 70B、80 层、64 头、头维度 128、序列长度 4096 的 FP16 模型，KV 缓存的需求为：

KV 缓存 = 2 × 80 × 64 × 128 × 4096 × 2 ≈ 10.7 GB（FP16）

单个请求的 KV 缓存 alone 就占用了 H100 的 80 GB HBM 的相当大比例。对于 8 个并发请求的批次，KV 缓存将需要 85.9 GB，超过了单个 GPU 的容量。减少这一占用需要两种互补策略：量化和架构优化。

KV 缓存量化

通过降低精度来减小缓存值的尺寸，可直接节省内存。仅权重量化（GPTQ、AWQ）降低权重精度，同时保持激活在高精度。虽然对存储有效，但这并不会减小 KV 缓存。KV 缓存量化 明确针对激活，将缓存的键和值存储为 INT8、FP8，甚至 INT4。

将 KV 缓存压缩为 INT4 可将其减少至大约每请求 2.7 GB，即减少 4×。这一释放的内存直接转化为更大的批次和更高的服务吞吐量。KV 缓存值的分布与模型权重不同：KIVI 观察到键中的通道离群值，并采用按通道的键量化，而值缺乏相同的通道模式，因而采用按标记的量化。

分组查询注意力（GQA）

分组查询注意力（Ainslie et al. 2023），即在 第 9.4.3 节 中确立的共享 KV 头架构，是缩小缓存规模的第二个杠杆，与量化互补：量化通过减少每个缓存元素的字节数来缩小尺寸，而 GQA 则通过减少每层缓存的键值头数量来实现。其服务后果是头数的算术运算。对于我们之前的 70B 模型，从多头注意力（MHA）基线的 64 个 KV 头切换到具有 8 个 KV 头的 GQA，可使 KV 缓存减少 8×：

KV 缓存（GQA） = 2 × 80 × 8 × 128 × 4096 × 2 ≈ 1.3 GB（FP16）

在 1.3 GB 时，GQA 缓存相比 MHA 所需的 10.7 GB 要易管理得多。将 GQA 与 INT8 KV 缓存量化结合使用，可实现每请求亚吉字节级的缓存尺寸，通常能够在单个 GPU 上显著增大批处理规模。GQA 已成为推理优化型 LLM 的常见架构选择，因为它在许多部署中能以较小的质量影响显著降低 KV 缓存带宽和容量压力。

问题：量化对最大批次大小的影响

一个团队在 4× H100 GPU 上服务 70B 模型。FP16 权重占用 140 GB（每 GPU 35 GB）。FP16 KV 缓存每请求占用 10.7 GB。将权重量化为 INT4、KV 缓存量化为 INT8 会如何改变最大批次大小？

优化前（全 FP16）

• 权重：35 GB/GPU

• 可用于 KV 缓存：80 GB − 35 GB = 45 GB/GPU

• 每请求 KV 缓存：10.7 GB ÷ 4 ≈ 2.7 GB/GPU

• 最大批次大小：⌊ 45 GB ÷ 2.7 GB ⌋ ≈ 16 请求

优化后（INT4 权重，INT8 KV 缓存）

• 权重：35 GB × (4/16) = 8.75 GB/GPU (INT4)

• 可用于 KV 缓存：80 GB − 8.75 GB = 71.25 GB/GPU

• 每请求 KV 缓存 (INT8)：5.4 GB ÷ 4 ≈ 1.3 GB/GPU

• 最大批次大小：⌊ 71.25 GB ÷ 1.3 GB ⌋ ≈ 53 请求

系统洞察

精度工程从根本上改变了服务经济性，因为它支持更大的批次大小。更大的批次摊销了权重加载的固定成本，使操作从内存受限转向计算受限。

投机解码作为服务策略

第 9.6.1 节 确立了投机解码作为一种算法优化：一个小型草稿模型提议 K 个 token，目标模型在一次并行前向传播中验证它们，拒绝采样保证输出的 token 完全遵循目标模型的分布，因此该技术是无损的，且受草稿接受率 α[acc] 限制。服务问题则不同。投机在 SLA 压力下变成了一种资源准入策略：调度器必须决定何时启用它，其内存成本如何与 KV 缓存准入交互，以及它对端点所受 SLA 的影响。

解码是内存受限的；并行验证将工作移向脊线。

延迟收益是真实但有条件的，条件在于接受率。每轮发出的预期 token 数（包含修正 token）为 (1 - α[acc]^(K+1)) / (1 - α[acc])，随着接受率下降，该值趋近于 1。对于 K = 5 个草稿 token 和比目标模型快 20× 的草稿模型，这种敏感性很陡峭：

• 高接受率 (α[acc] = 0.9)：每轮预期 4.69 个 token，加速比 3.7×。

• 中接受率 (α[acc] = 0.7)：每轮预期 2.94 个 token，加速比 2.4×。

• 低接受率 (α[acc] = 0.5)：每轮预期 1.97 个 token，加速比 1.6×。

可预测文本可达 α[acc] > 0.9，而创造性推理或代码生成可能降至 0.5 以下；共享训练数据和架构的良好对齐模型对通常落在 0.6–0.8 之间。由于接受率是工作负载的属性而非硬件的属性，单一全局设置不适用于混合机群：在聊天端点上将单 token 时间减半的相同投机，可能会拖慢处于盈亏平衡接受率以下的代码生成端点。因此服务系统必须按端点决策，三个服务关注点主导该决策。

投机税与 KV 缓存准入

第一个关注点是内存。草稿模型不是免费状态：它需要自己的 GPU 分配用于权重，且每个使用投机的在途请求都会在目标模型之外预留一小部分额外的 KV 缓存给草稿模型。将 7B 草稿模型与 70B 目标模型配对，每个副本大约增加 14 GB 权重，加上每请求的草稿缓存。这项 投机税 直接与 第 10.4.1 节 中建立的 KV 缓存准入预算竞争：草稿模型持有的每一 GB，都是准入控制器无法分配给并发请求的 GB。因此投机缩小了节点可准入的最大批次大小，用聚合吞吐量换取单个请求的延迟。准入控制器与投机策略无法独立调优；启用投机会降低 KV 缓存墙已施加的并发上限。

SLA 下的延迟-吞吐张力

第二个关注点是端点受哪个服务级别目标约束。投机改善了每输出 token 时间，但通过降低并发上限，减少了副本可维持的每秒请求数。受严格首 token 时间或每 token 延迟 SLA 约束的端点（如交互式聊天）受益：投机税为关键的延迟目标买来了余量。受吞吐量 SLA 约束的端点（如批量文档处理或批量摘要）受损：投机花费批次容量去改善没人测量的延迟指标，丢失的并发直接威胁吞吐目标。因此决策是个 SLA 问题。调度器在延迟受限端点启用投机，在吞吐受限端点禁用它，在同时服务两者的共享副本上，必须按两者中更严格的预算核算草稿模型的常驻成本。

按端点调度

第三个关注点是这些决策是动态的，而非静态配置。接受率随流量组合漂移，且投机价值在高负载下崩塌：当副本已接近并发上限时，解码阶段更接近计算受限，投机的边际延迟收益缩减，而其内存税保持固定。生产调度器因此将投机视为一个由观测负载和接受率控制的运行时旋钮。它们在正常操作期间为延迟敏感端点启用它，在流量尖峰时禁用它以回收 KV 缓存页用于准入，并可能按端点切换草稿策略。

自投机解码 使用目标模型自身的早退作为草稿，消除了单独模型的内存税，代价是较低的接受率；Medusa (Cai et al. 2024) 向目标骨干添加轻量预测头；前瞻解码 使用 Jacobi 迭代完全避免草稿模型。每种变体在投机税的不同切片与接受率之间权衡，调度器根据哪个 SLA 受约束以及剩余多少 KV 缓存预算，按端点在其中选择。

分布式环境中的 KV 缓存

当对话被移动、再平衡或跨设备拆分时，其 KV 状态必须随之移动或逐 token 重建。第 10.5 节 阐述了跨设备分发模型的张量并行和流水线并行策略；每种策略对 KV 缓存管理有不同后果：

在张量并行下，KV 缓存随注意力头一起跨设备分片。每个设备存储其头子集的缓存。

8-way tensor parallelism:
Device 0: KV cache for heads 0-7
Device 1: KV cache for heads 8-15
...
Device 7: KV cache for heads 56-63

跨设备共享增加了一个约束：张量并行设备间的前缀缓存要求所有设备上缓存以相同方式分片。当前缀使用相同的张量并行配置处理时，这会自动满足。

KV 缓存迁移提出了进一步挑战。当路由器因故障或再平衡将对话移至不同副本时（路由键控于会话 ID 的哈希，即 第 10.6.6 节 中开发的一致性哈希有状态路由方案），KV 缓存必须迁移：

迁移选项

迁移选项

1. 重建：在新副本上重新运行预填充（长上下文 500 ms+）

2. 传输：通过网络发送 KV 缓存（100 MB，100 Gbps 时 = 8 ms）

3. 混合：小则传输，大则重建

决策阈值

if cache_size_bytes/network_bandwidth < prefill_time:
    transfer()
else:
    rebuild()

Llama-70B GQA 的性能背景

对于具有 4K 上下文的 Llama-70B GQA，每个序列的 KV 缓存总计约 1.3 GB，在 8 路张量并行下每个设备约 168 MB。在 100 Gbps（12.5 GB/s）下，传输一个分片大约需要 13 ms，而传输完整缓存大约需要 100 ms。两者通常都优于约 500 ms 的预填充重建，因此只要带宽可用，传输仍是更好的选择。

内存管理最佳实践

内存管理最佳实践

有效的 KV 缓存管理始于容量核算，而非淘汰策略。服务进程首先为权重、激活值、运行时开销和安全余量预留内存，然后将剩余的 HBM 视为活跃序列的托管池：

可用 GPU 内存 = 总内存 - 权重 - 激活值 - 开销
KV 池大小 = 0.9 * 可用内存  # 保留 10% 余量

最大并发序列数 = KV 池大小 / (平均序列长度 * 每 token 缓存)

该预算决定了在调度器必须在拒绝、抢占或换页之间做出选择之前，可以共存多少序列。当缓存已满时，LRU 淘汰移除访问最久的序列，基于大小的淘汰优先释放最长序列，基于优先级的淘汰保护付费层或延迟关键型请求。持续批处理随后将淘汰转化为调度决策：无法容纳的高优先级请求触发受害者选择，将受害者的 KV 缓存换出到 CPU 内存，为新请求分配 GPU 内存，若其服务级别目标仍允许延迟，则稍后恢复受害者。

生产系统根据表 10.19 中的三层层级管理 KV 缓存内存压力，随着活跃工作集超出每一层的容量，将数据从 GPU HBM 逐级换出到 CPU DRAM 和 NVMe SSD：

| 层级 | 容量 | 延迟 | 用例 |

|----------|----------|----------|----------|

| GPU HBM | 80 GB | 0 ms | 活跃序列 |

| CPU DRAM | 1 TB | 1–5 ms | 已换出序列 |

| NVMe SSD | 10 TB | 10–50 ms | 长期缓存 |

表 10.19：KV 缓存内存层级：生产推理服务器用于管理 KV 缓存内存压力的三个层级的容量、换入延迟和预期用例。

换页实现

观测性能

• 仅 GPU（无换页）：50 个并发序列

• GPU+CPU 换页：500 个并发序列（10 倍）

• 平均换页延迟：3 ms（非紧急请求可接受）

系统洞察：将 CPU DRAM 和 NVMe 视为 HBM 后的溢出层级，以毫秒级换页延迟为代价，将并发性提高了一个数量级，因此换页是非紧急流量的吞吐杠杆，但不能替代延迟关键路径上的 HBM 容量。

换页掩盖的错配仍然是结构性的：单个 GPU 必须同时处理计算密集型的提示词处理和带宽密集型的 token 生成。将这两个阶段分离到不同的硬件池上，可以完全消除这种错配。

解耦服务：拆分工作负载

解耦服务：拆分工作负载

LLM 推理包含两个具有不同计算特性的不同阶段，要求在同一请求内采用不同的批处理策略。图 10.11 展示了这种架构拆分如何将两个阶段分离到专用硬件池上，表 10.20 对比了它们的资源概况。

图 10.11：解耦服务架构：将计算受限的预填充阶段与带宽受限的解码阶段分离。请求进入预填充池进行提示词处理，生成的 KV 缓存被迁移到解码池进行 token 生成。这使得每个阶段都能在针对其特定瓶颈优化的硬件上运行，提高整体车队效率。

预填充与解码阶段

预填充与解码阶段是基于 Transformer 的 LLM 推理的两个不同计算模式。

1. 重要性：预填充阶段（处理提示词）是计算受限的（\(R_{peak}\)），具有高算术强度；而解码阶段（生成 token）是带宽受限的（BW），具有极低的算术强度。这种错配意味着单个请求的硬件效率（\(\eta_{hw}\)）在其生命周期中剧烈变化。

2. 区别：与单次推理（如 ImageNet）的资源瓶颈恒定不同，LLM 推理在每个请求中都在这两种模式之间切换，需要迭代级调度来维持利用率。

3. 常见误区：一个常见的误解是两个阶段应当被朴素地一起批处理。实际上，因为它们有相反的硬件要求，在没有分块预填充或类似技术的情况下将它们混在同一个批次中，可能导致解码 token 出现显著的排队延迟（\(L_{lat}\)）。

预填充阶段并行处理整个输入提示词。计算随提示词长度缩放，内存访问模式是计算受限的，具有高算术强度¹⁵⁶。

相比之下，解码阶段一次生成一个输出 token。每个 token 都需要加载整个模型权重，使得内存访问模式是带宽受限的，具有低算术强度。C.3.1 节 将这两个阶段置于屋顶线模型上：解码远低于公式 C.4 的屋脊点，吞吐量由 HBM 带宽而非峰值 FLOP/s 决定；而预填充的高算术强度（公式 C.2）将其推至屋脊之上进入计算受限区域。

| 阶段 | 计算 | 内存访问 | 瓶颈 | 最优批次 |

|----------|----------|--------------|----------|--------------|

| 预填充 | \(\mathcal{O}(\text{prompt length}²)\) | 激活值和注意力分块 | 计算 | 中等请求批次或大分块 |

| 解码 | \(\mathcal{O}(1)\) 稠密权重工作 + \(\mathcal{O}(\text{context length})\) 每 token 对 KV 缓存的注意力 | 权重和 KV 缓存读取 | 带宽 | 大量活跃 token 的连续批次 |

表 10.20：预填充与解码特性：两个阶段具有相反的优化要求。

因为解码是带宽受限的，缩小每 token 移动字节数的硬件直接攻击该阶段的约束瓶颈。

对窄格式的原生硬件支持是这种方法的当前体现。Blackwell (B200) 架构引入了原生 FP4 支持，使 4-bit 推理成为一等硬件目标，而非特定框架的变通方案。相对于 FP8，将权重和 KV 缓存字节减半，在不提高时钟频率的情况下提升了 token 吞吐量和并发序列容量，这在解耦部署中放宽了解码池的规模限制。该产品属于特定时间点，确切的每 token 成本收益取决于模型架构、内核成熟度、批次形状以及预填充与解码的时间占比，因此生产系统应通过特定工作负载基准测试验证 FP4，而非假设固定的乘数。

这种二分法带来了调度挑战：预填充操作长时间运行且计算密集，而解码操作短且带宽受限。将它们混在同一批次中可能导致干扰。即使解码步骤几乎没有暴露有用的计算，GPU 仍保持供电和分配状态，因此除非调度器用兼容的工作保持硬件忙碌，否则低利用率的解码流量可能主导能耗成本。

分块预填充¹⁵⁷ 通过将长提示词拆分为固定大小的块，并与解码操作交错执行，解决了这一问题：

\[\\text{Chunk latency} = \\frac{\\text{Chunk size}}{\\text{Prefill throughput}} \]

通过选择与解码迭代时间相匹配的块大小，预填充和解码可以共享 GPU 资源，而不会出现解码延迟尖峰。

预填充-解码解耦进一步分离了这一过程，将预填充和解码运行在独立的 GPU 池上。预填充池针对计算强度进行优化，使用高 TFLOP/s 的节点、中等请求批次或大 token 块，在不阻塞解码的前提下最大化吞吐量。解码池针对内存带宽进行优化，使用具有最大 HBM 容量的节点——即 4.3.2 节 中讨论的第 0 层存储资源——以处理数千个并发的自回归流。

独立扩展由此直接得出：预填充容量随输入量扩展，而解码容量随输出量扩展。关键在于，这种架构依赖于 第 3 章 中建立的高速、支持 RDMA 的网络结构。当预填充完成时，生成的 KV 缓存（通常为数兆字节数据）必须在 token 间延迟预算内（通常低于 10 毫秒）迁移到解码节点。InfiniBand 的低微秒级延迟和高剖分带宽是这种逻辑解耦的物理基础，这是一种开销置换，用通信带宽换取了专用的预填充和解码硬件。

分块预填充可以形式化为一种实用的调度算法，从而限制长提示词导致的解码停顿。

Sarathi-Serve 系统（Agrawal 等人，2024）实现了具有无停顿调度的分块预填充：

块大小确定：块的大小设定为使预填充工作能与解码迭代交错进行。例如，如果部署目标为 20 毫秒的调度时间片，且观测到的预填充吞吐量为 10,000 tokens/秒，则一个块大约处理 200 个 token。合适的块大小取决于工作负载和硬件。

交错调度：每次 GPU 迭代处理以下任务之一：

• 一个新请求的预填充块，或

• 所有活跃序列的一个解码步骤

该调度减少了长传入提示词导致的解码停顿。

KV 缓存交接：当一个预填充块完成时，调度器拥有足够的 KV 状态，可通过后续的解码工作继续处理该请求。在解耦的预填充/解码系统中，任何物理 KV 缓存传输都是独立的网络和放置预算，而非 Sarathi-Serve 本身提供的保证。

性能影响：

• 无分块时：长提示词会为其他活跃请求造成解码延迟尖峰。

• 有分块时：预填充工作被拆分为有界单元，因此解码迭代可在长提示词进入系统时继续推进。

系统洞察：分块预填充将一个长提示词从单个阻塞请求转变为可与解码流量共存的有界工作单元。

Adapter 状态与局部性

KV 缓存管理使单个 GPU 能安全地服务多个并发请求；多租户 Adapter 服务则要求同一服务进程管理另一种驻留状态。KV 缓存是逐 token 的注意力状态。LoRA Adapter 是逐租户的权重增量。两者都必须在解码步骤运行时刻可用，且若调度器忽略局部性，两者都可能抵消批处理收益。随着服务平台扩展至在单一基座模型上支持数千并发用户，个性化引入了新的内存瓶颈。低秩适配 存储一小组用户或任务特定的 Adapter 权重，在不复制完整模型的前提下修改共享基座模型。当 10,000 个用户各自拥有应用于同一个 140 GB 基座模型的唯一 LoRA Adapter 时，为每个用户复制基座权重在物理上是不可能的。取而代之的是，基座模型保持钉驻在 HBM 中，而用户特定的 Adapter 按需被带入快速的片上工作集。

这种多租户服务模式将根本性能约束从计算吞吐量转移到了 Adapter 局部性。当连续批处理调度器交错来自不同用户的请求时，Adapter 权重可能必须在每次生成步骤前反复从 HBM 移入 SRAM 或寄存器。其效果类似于操作系统上下文切换：加速器有工作要做，但必须先等待属于下一租户的状态。若 Adapter 交换延迟超过生成步骤的计算时间，GPU 计算核心将停转。因此，高效的多租户服务在可能时按活跃 Adapter 对请求进行批处理，并协调 Adapter 放置与 KV 缓存换页，使个性化不会抵消共享基座模型的收益。

当模型本身超出单 GPU 容量时，同一局部性问题会在更大规模上重现。对于 1750 亿参数的基座模型，甚至连权重都必须跨多设备分片，因此推理在成为调度问题之前，首先是一个分片问题。

推理的模型分片

一个 700 亿参数模型以 FP16 精度存储权重需要超过 140 GB VRAM，超过了单张 80 GB GPU 的容量。为服务该模型，我们必须将其架构切片并分布到多个协同工作、作为单一逻辑副本的 GPU 上。将分布式训练并行技术（具体为张量并行和流水线并行）改造用于低延迟推理，引入了一组独特的约束。

何时需要分片

推理模型分片由两个截然不同的需求驱动。表 10.21 列出了使分片成为必要的内存和延迟约束：

第一个驱动因素是内存容量。无法装入单 GPU 内存的模型必须分片，无论性能考量如何。对于参数量为 P、精度为 b 位的模型，权重内存由公式 10.6 计算：

\[\\text{Memory}\_{\\text{weights}} = P \\times \\frac{b}{8} \\text{ bytes} \\qquad(10.6) \]

一个 700 亿参数的 FP16（16 位）模型需要：

\[\\text{Memory} = 70 \\times 10⁹ \\times \\frac{16}{8} = 140 \\text{ GB} \]

结果超过了 H100 GPU 的 80 GB 容量，至少需要 2 路分片。

第二个驱动因素是延迟。即使模型装得下内存，分片也可通过并行化计算来降低延迟。公式 10.7 将潜在加速比形式化为并行化效率的函数：

\[T\_{\\text{parallel}} = \\frac{T\_{\\text{compute}}}{N} + T\_{\\text{comm}}(N) + T\_{\\text{sync}}(N) - T\_{\\text{overlap}} \\qquad(10.7) \]

其中 N 为分片组中的设备数量，Tcomm 为通信开销，Tsync 为同步开销，T[overlap] 为隐藏在有效计算后的通信时间。在常见的无重叠简化且额外同步可忽略的情况下，这简化为 T[compute]/N + Tcomm。仅当非重叠开销小于并行化节省的时间时，分片才能带来延迟收益。

| 分片触发条件 | 模型示例 | 最小分片度 | 策略 |

| --- | --- | --- | --- |

| 内存 (权重) | Llama-70B (140 GB) | 2 路 | 张量或流水线 |

| 内存 (KV 缓存) | GPT-4 (长上下文) | 4–8 路 | 张量 (用于缓存) |

| 内存 (Embedding) | DLRM (100 TB) | 1000+ 路 | Embedding 分片 |

| 延迟 | 任意大模型 | 视情况而定 | 张量并行 |

表 10.21：分片触发条件：不同约束导致不同的分片需求与策略。

张量并行

张量并行（Shoeybi 等人 2019）将单个层分布到多个设备上，实现层内并行计算。第 5 章中介绍的用于训练的列行分区方案在此同样适用：将第一个线性层按列分割、第二个线性层按行分割，每个 Transformer 块仅需一次 AllReduce 操作。对于 Transformer 模型，主要并行目标是注意力机制和前馈层，它们包含了绝大部分计算量。

多头注意力计算自然地按注意力头进行分区。对于拥有 N_heads 个注意力头、分布在张量并行度 t 设备上的模型，每个设备计算 N_heads/t 个头：

Attention_i = softmax(Q_i K_i^T / sqrt(d_k)) V_i for heads i in {1, ..., N_heads/t}

完成局部注意力计算后，一次 AllReduce 操作（详见第 6 章）跨设备聚合结果，引入的通信开销与激活大小除以互联带宽成正比。

前馈层（通常为带激活函数的两个线性变换）沿隐藏维度分区。第一个线性层按列分发，第二个按行分发。这种列行分区策略使得每个前馈块仅需一次 all-reduce。

张量并行推理的通信模式遵循每层两阶段同步。图 10.12 展示了这一流程：

图 10.12：用于推理的张量并行：通过分割张量操作将计算分布到各设备。注意力头跨 GPU 分区，需要 AllReduce 操作同步结果。前馈网络采用列行分割策略，每个块仅需一次 AllReduce 同步。这种方法降低了大模型的延迟，但引入的通信开销要求高带宽互联（如 NVLink）。

采用张量并行的推理时间遵循公式 10.8：

T_inference = T_compute / t + 2 × T_allreduce(A / t)  (10.8)

其中 T_compute 为顺序计算时间，t 为张量并行度，A 为被归约的激活大小。因子 2 代表每个 Transformer 层的两次 all-reduce 操作（注意力和前馈）。

以如下配置服务 Llama-70B 为例：(Touvron 等人 2023)

模型规格：

• 参数量：70B

• 隐藏维度：8,192

• 注意力头数：64

• 层数：80

每 GPU 显存（仅权重，FP16）：

Memory_70B = 70 × 10⁹ × 2 = 140 GB

最小分片：2 路（140 GB / 每张 H100 80 GB）

推荐分片：8 路以获得最优延迟

表 10.22 将 8× H100（NVLink 互联）上 8 路张量并行的单层成本分解为计算和 AllReduce 阶段，揭示了实际 6.9× 加速源于计算缩放减去少量通信税。

| 组件 | 顺序 (1 GPU) | 8 路 TP | 加速比 |

| --- | --- | --- | --- |

| 注意力计算 | 12 ms | 1.5 ms | 8× |

| AllReduce (注意力) | 0 ms | 0.3 ms | N/A |

| 前馈计算 | 18 ms | 2.25 ms | 8× |

| AllReduce (FF) | 0 ms | 0.3 ms | N/A |

| 单层总计 | 30 ms | 4.35 ms | 6.9× |

表 10.22：8 路张量并行单层分解：单个 Llama-70B Transformer 层的注意力、前馈和 AllReduce 阶段在顺序与 8 路张量并行下的耗时对比，将实现的 6.9× 加速分解为计算缩放与通信税。

层栈估算（同一 prefill 工作负载下的 80 层）：

• 顺序：完整 prefill 通道耗时 2,400 ms

• 8 路 TP：完整 prefill 通道耗时 348 ms

6.9× 加速（理论值为 8×）反映了通信开销。在 900 GB/s 带宽下，按原始带宽数学移动 8 MB 激活载荷仅需约 0.01 ms；此处所示的 0.3 ms 预算包含集合启动、同步、环形协议及框架开销。

首 Token 时间（1024 token 提示词）：

• Prefill 计算：8 路 TP 上约 348 ms（计算密集型，近线性缩放减去通信开销）

• 总 TTFT：含预处理和服务开销约 400 ms

系统洞察：张量并行以通信换取低延迟。它之所以适用于 Llama-70B，仅因互联保持了相对于分片节省计算量而言较小的集合税。

用于推理的流水线并行

流水线并行按顺序将层分布到各设备，每个设备处理一部分层。与张量并行不同，层内无同步，仅在流水线阶段间同步。

对于推理，流水线并行产生气泡的方式不同于训练。图 10.13 对比了单请求延迟（气泡主导）与流水线吞吐（气泡摊销）：

图 10.13：流水线并行气泡：对于单个推理请求（顶部），流水线并行无延迟优势，因请求必须依次遍历所有四个阶段。处理多个并发请求时（底部），流水线填满且吞吐随阶段数缩放。这使流水线并行适合高吞吐批处理，但不太适合延迟敏感的交互式服务。

对单个请求，流水线并行无延迟收益：请求必须按顺序遍历所有阶段。流水线填充时间等于顺序执行时间。

然而，流水线并行通过流水线多请求实现吞吐缩放：

时间 →
设备 0: [请求 1] [请求 2] [请求 3] [请求 4] ...
设备 1:        [请求 1] [请求 2] [请求 3] [请求 4] ...
设备 2:               [请求 1] [请求 2] [请求 3] [请求 4] ...
设备 3:                      [请求 1] [请求 2] [请求 3] [请求 4] ...

流水线填满后，吞吐量等于单阶段吞吐的 p 倍，p 为流水线阶段数。稳态延迟约等于单设备延迟（所有阶段耗时之和），但吞吐随并行度缩放。

流水线并行适用于推理的三种场景：

• 显存限制要求分片但延迟要求宽松

• 吞吐优于单请求延迟

• 设备间网络带宽受限（仅点对点通信）

表 10.23 总结了这两种分片策略的权衡：

| 方面 | 张量并行 | 流水线并行 |

| --- | --- | --- |

| 单请求延迟 | 降低约 t× | 无改善 |

| 吞吐量 | t× | p×（流水线时） |

| 通信模式 | AllReduce（带宽敏感） | 点对点（延迟敏感） |

| 显存效率 | 激活复制 | 激活传递 |

| 复杂度 | 较高（需自定义内核） | 较低（层级分区） |

表 10.23：流水线并行 vs 张量并行：每种策略在延迟、吞吐及实现复杂度上有不同权衡。

决策规则是：延迟优先，拓扑次之。当单请求延迟至关重要且有 NVLink 级带宽可用时，张量并行是正确的默认选择；流水线并行是宽松延迟工作负载的吞吐量工具，或仅用于只能负担得起点对点阶段通信的部署场景。

面向 MoE 模型的专家并行

混合专家模型，如 DeepSeek-V3 或 Mixtral，带来了密集模型之外独特的服务挑战。在 MoE Transformer 层中，前馈网络（FFN）被多个并行的“专家”子网络和一个轻量级路由器所取代，路由器为每个 token 选择一部分专家。

MoE 架构在保持每 token 计算量恒定的同时，实现了总参数量的扩展。然而，大规模服务此类模型需要专家并行（EP），即不同的专家托管在不同的 GPU 上。

MoE 经济学与容量规划

MoE 服务的经济性产生了一个悖论：总参数量决定了最小硬件数量（受限于显存），而激活参数量决定了每 token 的计算成本。这使得 MoE 模型在计算上高效，但在显存“租金”方面昂贵。

性能优势显著。在批大小为 1 的自回归解码过程中，主要成本是从 HBM 读取权重。一个 FP16 的密集 400B 模型每步读取 800 GB。尽管 DeepSeek-V3 拥有更多总参数，但每步仅读取 37B 激活参数（FP16 下约 74 GB），每 token 带宽降低了 10.8 倍。计算节省成比例：每 token FLOPs 减少 10.8 倍。

MoE 让所有专家常驻内存，但每个 token 仅激活少数专家。

权衡在于内存容量：即使任意时刻只有少部分专家处于激活状态，所有专家都必须驻留在内存中。DeepSeek-V3 完整模型 FP16 精度下需要约 1342 GB，必须分发到许多 GPU 上。

问题：某团队为聊天机器人应用部署 DeepSeek-V3（总参数 671B，每 token 激活 37B）。模型使用 FP8 权重（每参数 1 字节）。集群有 8-GPU 节点，每节点含 8× H100 GPU（每 GPU 80 GB HBM，每节点 640 GB）。需要多少节点？单 token 解码延迟是多少？

计算：

1. 显存：总权重显存 = 671 GB。单节点（640 GB）不足。2 个节点提供 1,280 GB，留有足够空间给 KV 缓存。

2. 延迟：每个解码步读取 37B 激活参数（37 GB）。分布在 16 个 GPU 上，每个读取约 2.3 GB。在 3.35 TB/s HBM 带宽下，t[读取]≈ 0.69 ms。AllToAll 路由增加约 0.3 ms。

3. 下限：预估解码延迟 ≈ 1.0 ms/token，即批大小 1 时 1,000 tokens/s。

系统洞察：MoE 让 671B 模型的每 token 带宽成本接近小得多的密集模型，但容量规划仍由必须常驻的全量参数集驱动。

专家并行与负载均衡

将 MoE 模型分发到 GPU 上引入了专家并行：每个 GPU 持有一部分专家，token 被路由到持有其指定专家的 GPU。在 MoE 层中，门控网络为每个 token 选择 k 个专家（共 E 个）：

输出 = ∑[i ∈ top-k] g[i] · Experti

专家并行将专家分发到各设备，每个设备托管 E/N 个专家，其中 N 是专家并行设备数。图 10.14 追踪了路由、分发和收集操作：

图 10.14：混合专家（MoE）路由：专家并行将“专家”分发到不同设备。对每个 token，门控机制选择 top-k 专家。AllToAll 通信步将 token 分发到托管其选定专家的设备（1）。专家并行处理 token（2）。第二个 AllToAll 步将结果收集回原始设备（3）。该模式实现了海量模型容量，但引入了 all-to-all 通信开销。

通信模式不同于张量并行：不是 all-reduce（向所有设备发送相同数据），专家并行使用 all-to-all（基于路由向不同设备发送不同数据）。这种 AllToAll 模式产生了一个关键系统挑战：负载均衡。如果路由器持续向某些专家发送更多 token 而非其他专家，那些专家的 GPU 会成为瓶颈，而其他 GPU 则闲置。三种机制解决负载不均：

• 辅助损失：训练损失中的额外项，通过奖励均匀的路由概率来惩罚专家利用不均。

• 容量因子：每个专家每批次接受的最大 token 数（通常为公平份额的 1.25×）。超出部分的 token 被丢弃或重新路由。

• 专家缓冲：当专家满载时，token 被缓冲并在后续迭代中处理，以延迟方差为代价平滑负载尖峰。

这些机制保持专家利用率足够均衡，使路由保持为吞吐优势，而非新的拖后腿来源。

路由失效模式

路由器行为直接影响系统性能和模型质量。专家崩溃是训练时的路由器失效，路由器收敛到一小部分专家，导致其他专家训练不足；服务中的模型表现得像一个拥有巨大内存占用的小型密集模型。路由不稳定是另一种训练时失效：分配震荡，阻止专家特化。服务阶段也引入运行时过载条件。分布偏移会使在正式文本上训练的路由器在服务口语聊天数据时，使特定“语法专家”过载，产生热点。Token 丢弃发生在容量受限的专家丢弃 token、跳过其计算、仅依赖残差连接时，降低输出质量。

这些失效模式源于基本的 MoE 服务权衡¹⁵⁸：计算根据输入动态路由到不同专家，因此路由模式成为系统工作负载，而不仅仅是模型内部选择。像 Mixtral（A. Q. Jiang 等 2024）这样的流行模型利用 MoE 以更低的推理成本实现高容量。

Mixtral-8x7B 每个 MoE 层使用 8 个专家，采用 top-2 路由：

模型特征：

• 总参数：46.7B（但每 token 仅激活 ~12.9B）

• 每层专家数：8

• 每 token 激活专家数：2 (top-k = 2)

• MoE 层：每个前馈层（每个 FFN 被一个 8 专家 MoE 块替换）

分片策略（4 路专家并行）：

• 专家 0-1 位于设备 0

• 专家 2-3 位于设备 1

• 专家 4-5 位于设备 2

• 专家 6-7 位于设备 3

机制：每 token 通信模式有四步：

1. 门控：确定使用哪 2 个专家 (~0.1 ms)

2. AllToAll 分发：将 token 发送到托管选定专家的设备 (~0.2 ms)

3. 专家计算：通过选定专家处理 token (~1 ms 每个，并行)

4. AllToAll 收集：收集结果返回 (~0.2 ms)

MoE 层总耗时：~1.5 ms（对比同等密集层 ~4 ms）

系统洞察：路由不均直接侵蚀八个专家间的 GPU 利用率和吞吐量；表 10.24 量化了退化程度。生产系统监控路由统计，并可能重新训练或微调门控以改善均衡。

| 路由分布 || GPU 利用率 || 吞吐影响 |

| --- | --- | --- |

| 完美均衡 || 100% || 基准 |

| --- | --- | --- |

| 中度不均衡 (20%) || 83% || -17% |

| 严重不均衡 (50%) || 67% || -33% |

表 10.24：MoE 路由负载均衡与吞吐量对比

随着路由不平衡在具有 4 路专家并行的 Mixtral-8x7B MoE 层的八个专家间增长，GPU 利用率和吞吐量受到的影响。

专家并行代表了模型分片复杂度的巅峰，要求模型架构、路由算法和物理互连拓扑之间进行紧密集成。下一节将探讨推荐系统如何对海量嵌入表使用类似的分片技术。

推荐系统的嵌入分片

推荐系统通常包含嵌入表，其规模远超稠密模型权重。Meta 的 DLRM 参考架构在嵌入表上使用模型并行来缓解内存限制，同时单独扩展稠密层（Naumov et al. 2019）。在生产规模下，这种嵌入密集型结构需要与张量并行或流水线并行截然不同的分片策略。

逐行分片按行（实体 ID）对嵌入表进行分区：

Shard[i] = {e[j] : hash(j) mod  N[shards] = i}

每个分片大约包含 N[entities]/N[shards] 个嵌入，其中 N[entities] 是实体总数，N[shards] 是分片数量。

逐列分片将每个嵌入向量跨设备分区：

e[j] = [e[j]^((0)), e[j]^((1)), ..., e[j]^((N[shards] − 1))]

每个设备存储每个嵌入的一个切片。混合分片结合了这两种方法：频繁访问的嵌入采用列分片以实现更快的访问，而长尾部分使用行分片。嵌入分片策略的选择取决于查找模式和通信开销。表 10.25 对比了逐行、逐列和混合方法：

| 分片策略 | 查找模式 | 通信 | 最适用场景 |

| --- | --- | --- | --- |

| 逐行 | 每次查找单设备 | AllToAll 收集 | 统一访问模式 |

| 逐列 | 每次查找全设备 | AllGather | 热门嵌入 |

| 混合 | 随嵌入而异 | 混合 | 生产推荐系统 |

表 10.25：嵌入分片策略

不同策略在查找局部性和负载均衡之间进行权衡。

权衡在于局部性与负载均衡之间。逐行分片将每个嵌入向量完整地保留在一台设备上，这使查找本地化，但需要 AllToAll 收集来聚合因实体 ID 而分散的向量；逐列分片以 AllGather 为代价，将每次查找并行化到所有设备；混合分片则折中处理，将热门嵌入按列分片复制，而将冷尾部按行分片。图 10.15 展示了这三种布局，其中逐行的“网络收集”即为 表 10.25 中提到的 AllToAll 集合操作。

图 10.15：嵌入分片策略

逐行分片根据实体 ID 将完整的嵌入向量放置在特定服务器上，查找时需要网络收集。逐列分片将每个向量拆分到所有服务器上，允许并行本地查找，随后进行 AllGather，这对流行的“热门”嵌入很高效。混合分片结合了这些方法，对热门项目使用列分片，对“冷门”长尾使用行分片，以平衡负载和内存。

所有三种分片策略均在生产环境中大规模运行。Meta 的推荐基础设施提供了一个具体示例，展示了逐行、逐列和混合方法如何结合以服务万亿级实体嵌入表。

对于 Archetype B 推荐工作负载，Meta 的基础设施展示了极端规模下的嵌入分片：

规模：

• 嵌入表：总计 100+ TB

• 唯一实体：10+ 万亿

• 嵌入维度：128–256

• 分片：1,000+ 台服务器

这些规模要点描述的是基础设施层面的总量，而非单个稠密驻留表，其中每个唯一实体都有一个 128–256 维的向量。一个包含 10 万亿实体、128 维的稠密 INT8 表至少需要 1,280 TB，而 100 TB 分摊到相同数量的实体上，平均每实体仅 10 字节。因此，生产系统依赖压缩、分层、冷存储和不均匀的实体覆盖，而非单一完全物化的稠密矩阵。

分片策略：

• 热门嵌入（按访问频率排名前 1%）：跨所有分片复制

• 温嵌入（随后的 10%）：采用 8 路并行进行列分片

• 冷门嵌入（剩余 89%）：采用一致性哈希进行行分片

每次推理请求大约需要 5,000 次嵌入查找。若无优化，这将需要 5,000 次网络往返。相反，系统应用了多项优化。批量累积收集 1 毫秒内的查找。查找去重移除跨请求的重复实体。分片感知批处理按目标分片对查找进行分组。并行调度同时将批量请求发送到所有分片。流式组装在响应到达时重构嵌入。

这些优化对往返次数、查找延迟和带宽产生的数量级效果见 表 10.26：

| 指标 | 无优化 | 有优化 |

| --- | --- | --- |

| 网络往返次数 | 5,000 | 1（批处理） |

| 查找延迟 | 50 ms | 2 ms |

| 网络带宽 | 10 Gbps | 40 Gbps（突发） |

表 10.26：Meta 嵌入分片查找性能

推荐查找路径在批处理加分片感知调度前后的网络往返、查找延迟和带宽测量，展示了这些优化的数量级效果。

灯塔经验在于，DLRM 规模的服务主要受制于稀疏嵌入的放置和查找协调，而非稠密加速器的 FLOP/s。

混合分片策略

生产系统通常结合多种分片策略，因为没有单一轴能满足每个推理约束。混合分片组合了内存容量、延迟和通信需求：一个轴可能保持权重驻留，另一个可能降低每 Token 延迟，第三个可能路由稀疏组件而不强制稠密层落在错误的设备上。三种反复出现的组合说明了这一模式：

张量并行和流水线并行在模型同时需要内存分布和降低延迟时结合：

8 个 GPU 组织为 2×4（流水线阶段 × 张量并行）：

第 0 阶段（第 1-40 层）：跨 GPU 0,1,2,3 进行 TP
第 1 阶段（第 41-80 层）：跨 GPU 4,5,6,7 进行 TP

该组合实现了 4 倍延迟降低（来自 TP），同时处理需要 8 路分片以满足内存需求的模型。

专家并行和张量并行为单个专家较大的 MoE 模型结合：

专家较大的 Mixtral：

- 专家并行：将 8 个专家分布在 8 个 GPU 组上
- 张量并行：每个专家跨 2 个 GPU 分布
- 总 GPU 数：16

嵌入并行和稠密并行服务于同时拥有大型嵌入和大型稠密组件的推荐模型：

DLRM 规模模型：

- 嵌入分片：跨 CPU 服务器的 1,000 个分片
- 稠密模型：跨 GPU 的 8 路张量并行
- 通信：嵌入收集至 GPU，处理后返回

混合分片通过在每个分片边界增加新的通信模式，换取适配性或延迟。下一个问题是通信税是否保持在延迟和吞吐量预算内。

通信开销分析

分片带来的实际加速关键取决于通信效率。每种分片策略都有特征性的通信模式，具有不同的带宽和延迟要求。

通信基元和互连

方程 10.9 量化了用于张量并行的 AllReduce 通信时间，其中所有设备的数据被合并，结果可在所有设备上获得。

\[T\_{\text{allreduce}} \approx 2(N-1)\alpha + \frac{2(N-1)}{N} \times \frac{M}{\beta} \qquad(10.9) \]

其中 N 是设备数量，M 是集合负载大小，α 是启动延迟，β 是互连带宽。因子 2 考虑了 reduce-scatter 和 all-gather 阶段。章节 D.2.1 推导了此环形 AllReduce 成本及其带宽最优的 2(N-1)/N 缩放，说明了随着张量并行度增长，每层通信开销保持有界的原因。

方程 10.10 表达了用于流水线并行的更简单的点对点通信，其中数据从一个设备流向下一个设备。

\[T\_{\text{p2p}}(n) = \alpha + \frac{n}{\beta} \qquad(10.10) \]

其中 n 是点对点负载大小，α 是网络延迟，n/β 是传输时间。方程 10.11 捕获了用于专家并行的更复杂的 AllToAll 通信，其中每个设备与其他每个设备交换不同的数据。

\[T\_{\text{alltoall}} = (N-1) \times \left(\alpha + \frac{M/N}{\beta}\right) \qquad(10.11) \]

两个方程清楚地说明了底层互连的可实现带宽 β 和延迟 α 决定了实际的分片性能。生产硬件在这两个轴上差异足够大，以至于互连的选择可以决定一个分片计划是否可行。

通信开销在很大程度上取决于互连技术。表 10.27 记录了每个候选互连的物理带宽、延迟和预期用途：

| 互连 | 带宽 | 延迟 | 使用场景 |

| --- | --- | --- | --- |

| NVLink (H100) | 900 GB/s | 500 ns | 节点内 TP |

| PCIe Gen5 | 64 GB/s | 1 μs | 节点内（无 NVLink） |

| InfiniBand HDR | 200 Gb/s (25 GB/s) | 7 μs | 节点间 |

| 以太网 100G | 100 Gb/s (12.5 GB/s) | 50 μs | 节点间（商用） |

表 10.27: 数据中心互连规格：NVLink、PCIe Gen5、InfiniBand HDR 和 100G 以太网的带宽、延迟和预期用途，确立了限制可实现分片加速的物理限制。

表 10.28 将这些带宽转换为 8 路张量并行层（每次 all-reduce 激活 8 MB；批次=1，隐藏层=8,192）的 AllReduce 时间，作为 30 ms transformer 层预算的一部分：

| 互连 | AllReduce 时间 | 30 ms 层的占比 |

| --- | --- | --- |

| NVLink | 0.03 ms | 0.10% |

| InfiniBand | 0.56 ms | 1.9% |

| 100G 以太网 | 1.12 ms | 3.7% |

表 10.28: 按互连划分的 AllReduce 成本：跨 NVLink、InfiniBand 和 100G 以太网的 8 MB 激活的 AllReduce 时间，每个作为 30 ms transformer 层预算的一部分，说明了为什么节点内 TP 需要 NVLink 级别的带宽。

工程边界是局部的：NVLink 使节点内的张量并行高效，InfiniBand 可以使精心选择的工作负载的跨节点张量并行变得可接受，而商用以太网通常对于延迟敏感的推理来说太慢。

NVLink 带宽¹⁵⁹ 在 GPU 世代之间发生了显著演变。

分片策略选择

分片策略的选择取决于模型架构和部署优先级。表 10.29 从四个关键因素评估每种方法：

| 因素 | 张量并行 | 流水线并行 | 专家并行 | 嵌入分片 |

| --- | --- | --- | --- | --- |

| 延迟优先 | 最佳 | 最差 | 中等 | N/A |

| 吞吐量优先 | 良好 | 最佳（流水线） | 良好 | 最佳 |

| 受互连限制 | 不适合 | 适合 | 中等 | 适合 |

| 实施工作量 | 高 | 低 | 中等 | 高 |

表 10.29: 分片策略选择指南：根据部署优先级和限制匹配策略。

策略选择从部署瓶颈开始。当延迟占主导且互连能够维持频繁的集体通信时，使用张量并行；当吞吐量比每请求延迟更重要时，使用流水线并行；当 MoE 路由定义模型结构时，使用专家并行；当大型稀疏表主导容量时，使用嵌入分片。

一旦我们构建了这些大规模分片的多 GPU 副本，就必须让数十个副本并行运行以处理全球流量。挑战从单个副本的内部机制转移到流量控制层，该层负责在整个机群中将数百万用户查询路由过去。

负载均衡和请求路由

如果十个模型副本正在积极处理流量，并且有新请求到达，要求对一个 5,000 词的文档进行摘要，将其发送到已经过载的副本将会为分配给该节点的每个用户触发巨大的延迟峰值。简单的轮询负载均衡在生成式机器学习中会灾难性失败。我们必须采用智能请求路由，以了解机群中每个副本的内部内存和队列状态。

原型 B（大规模 DLRM）是尾延迟的典型受害者（Dean 和 Barroso 2013）。处理 1000 万 QPS 意味着每秒会发生 1,000 次 1 在 10,000 的延迟峰值。对于原型 B（大规模 DLRM），复杂的负载均衡（例如将每个请求路由到两个采样副本中负载较低的那个）是强制性的，以抑制这些异常值；简单的轮询会导致队列堆积，导致第 99 百分位延迟陷入不可接受的缓慢。

负载均衡原则

两选一路由使随机放置的尾部失衡变平。

负载均衡服务于两个有时会冲突的主要目标：延迟最小化和利用率最大化。延迟最小化将请求路由到能够最快提供服务的副本，考虑当前队列深度和处理时间；利用率最大化将负载均匀分布，以避免既有空闲副本又有过载副本。这种紧张关系产生的原因是，延迟最优的路由可能会将负载集中在快速副本上，降低它们的性能，并使其他副本利用不足。

因此，评估因此需要四个信号，这些信号同时覆盖尾延迟和负载均衡：

• 最大队列长度：这决定了最坏情况下的延迟。

• 负载方差：这衡量工作分配的均匀程度。

• 利用率分散：这显示了一些副本是否空闲而其他副本是否饱和。

• 决策开销：这捕获了做出路由选择的成本。

仅优化这些信号中的一个的策略可能在总体上看起来健康，同时将不幸的请求送入尾部。

轮询和随机分配

最简单的负载均衡策略在分配请求时不考虑服务器状态。轮询将请求 1 发送给服务器 1，请求 2 发送给服务器 2，依此类推，仅当服务器同构且请求处理时间相同时，才能实现完美分布。随机分配为每个请求均匀随机地选择一台服务器；随着请求数量增加，它收敛到均匀的平均分布，但其方差高于轮询。这两种策略对于同构服务器而言是合理的基线，但生产环境服务很少满足这一假设。异构 GPU 代际、不同的内存配置、可变的请求大小、预热行为以及接近内存限制的副本，都使得服务器集群的状态变得至关重要。

在这些现实条件下，无感知策略表现不佳，因为不幸的分配会在尾部累积。随机分配下的最大队列长度遵循经典的“球入箱”结果（Mitzenmacher 2001），如公式 10.12 所示：

E[max queue] = Θ(log R / log log R)     (10.12)

其中 R 是服务器或副本的数量。在 R = 1,000 时计算该比率，得到 log R / log log R ≈ 6.9/1.9 ≈ 3.6，首项常数将其提升到最坏情况下队列中约 4–5 个请求。这看起来很小，但处于长队列中的不幸请求会经历显著更高的延迟。两个选择的幂提供了理论上的回应：多一次队列长度探测，就能将尾部行为从 𝒪(log R / log log R) 改变为 𝒪(log log R)。

两个选择的幂

负载均衡理论中的一个基础性结果（Mitzenmacher 2001）表明，在做出路由决策前仅查询两台随机服务器，相比随机分配，能提供指数级更好的负载分布。¹⁶⁰

该过程刻意设计得很小，但负载信号必须与服务工作负载相匹配。对于同构视觉集群，当前队列长度可能就足够了。对于 LLM 集群，活跃 token、预估剩余解码工作量和 KV 缓存压力能更好地近似副本已接受的工作量。算法 6 给出了一个典型的路由循环：探测两个副本，比较归一化工作量，并在不轮询整个集群的情况下进行路由。

算法 6 两个选择幂的请求路由

Require: 副本集合 𝒮；请求 r；容量权重 w[s]；每副本工作信号 W[s]（队列长度、活跃 token、预测工作量或 KV 缓存占用）

Ensure: 为 r 选定的副本

1. 从 𝒮 中采样两个候选副本 s[a]、s[b] —— 按容量加权

2. 查询 W[s[a]]、W[s[b]]；估算增量工作量 ĉ(r)（预期输出 token 或 KV 页）

3. u[s] ← (W[s] + ĉ(r)) / w[s]，对于 s ∈ {s[a], s[b]} —— 准入后负载

4. s* ← u[s] 较小的候选者 —— 平局时：缓存亲和性

5. 将 r 路由到 s*

6. 更新 s* 的本地准入状态

7. return s*

每个请求的两次探测和一次状态更新是 𝒪(1) 协调开销，而非全副本扫描，只有当负载信号反映真实工作量时，尾延迟收益才会显现：在 LLM 服务中，仅靠请求计数可能会将一个 10-token 的请求隐藏在一个 500-token 的请求之后，而活跃 token 和 KV 缓存信号则能暴露风险。公式 10.13 中的队列长度界形式化地说明了这一微小改变为何重要，将最大队列长度从 𝒪(log R / log log R) 降低到 𝒪(log log R)：

E[max queue][two choices] = Θ(log log R)   (10.13)

对于 1,000 台服务器，随机分配产生的最大队列约为 4–5 个请求，而两个选择将最大值降至约 2。这种改进是指数级的：1,000 台服务器下的两个选择，其均衡效果优于仅有 10 台服务器的随机分配。

对于接收独立请求的 R 台服务器，随机分配以高概率产生 𝒪(log R / log log R) 的最大队列长度，而将每个请求路由到两个随机采样队列中较短的那个，将最大队列长度降低到 𝒪(log log R)。

实际意义在于，近乎最优的负载均衡不需要轮询整个集群。两次探测避免了精确最少负载路由的 R 次探测成本，改进随系统规模增长，且方法足够简单，可在普通负载均衡器内实现。两个选择幂的变体出现在大规模系统中，因为它们无需全局轮询即可提供强尾部行为保证。

其机制直观：随机分配偶尔会通过路由到已繁忙的服务器而做出糟糕选择，这些错误会累积。有了两个选择，算法几乎从不做出最差选择，避免了产生长队列的尾部行为。数学上，当 m 台服务器的队列长度为 k 时，随机分配以与 m/R 成正比的概率使队列长度增长至 k + 1。有了两个选择，该概率降为 (m/R)²，从而在队列长度分布中产生超指数衰减。

加权与自适应负载均衡

当服务器容量不同时，朴素负载均衡会造成不平衡。混合的 A100 GPU 和低容量 T4 GPU 若接收相同的请求速率，会导致 T4 服务器过载，而 A100 容量闲置。加权轮询通过按服务器容量比例路由请求来校正平均分配速率：

Pr(route to server i) = w_i / Σ_j w_j

其中 w[i] 是服务器 i 的权重或容量。加权两个选择将同样的思路应用于尾部控制：按权重比例采样两台服务器，比较相对于容量的当前负载，并路由到相对负载较低者。加权路由示例使该策略在混合 GPU 硬件场景下变得具体。

场景：一个服务集群混合了两个 GPU 层级，必须在不过载较慢层级的前提下路由请求。

已知：

• 10 块 NVIDIA H100 GPU，每块 1000 QPS。

• 20 块 NVIDIA A100 GPU，每块 600 QPS。

• 总容量 22,000 QPS；目标流量 15,000 QPS。

在 15,000 QPS 的目标流量下，加权分配给每个 H100 4.5% 的权重，每个 A100 2.7% 的权重。每台服务器的预期负载变为 H100 681.8 QPS，A100 409.1 QPS，两种服务器类型的利用率均为 68.2%。

无加权时：均匀分发会给每台服务器发送 500 QPS，导致 H100 利用率仅 50% 而闲置，A100 利用率 83.3% 且延迟余量减少。

系统洞察：异构集群需要容量加权路由。当每个硬件层级服务速率不同时，相等的请求计数不代表相等的负载。

静态权重处理已知的容量差异，但生产副本也会随时间变化。自适应负载均衡根据观测到的性能动态调整权重：

For each server i:
    latency[i] = exponential_moving_average(observed_latency)
    weight[i] = 1 / latency[i]  # 反向延迟加权

反向延迟加权降低了路由到观测延迟升高的服务器的概率，无论原因是内存压力、热节流、请求组合还是后台工作消耗资源。

最少连接负载均衡

随机选择的替代方案是路由到活动连接最少或队列最短的服务器。least-connections 为每个服务器维护一个活动请求计数，将新请求路由到计数最小的服务器，分发时递增，完成时递减。对于 LLM 服务中常见的长时间运行请求，这种方法优于轮询，因为它考虑了仍在进行的工作，而不仅仅是历史分配顺序。

挑战在于在分布式系统中维护准确的连接计数。集中式计数器提供单一事实来源，但可能成为瓶颈。带有 gossip 协议的分布式计数器扩展性更好，但可能使用过时信息进行路由。sampled least-connections 结合了两个选择的思路，仅探测一部分服务器并选择最小值。

LLM 推理具有高度可变的请求持续时间，因为输出长度改变了服务时间。简短的 10-token 响应可能需要 500 ms，而 500-token 响应可能需要 25 秒，相差 50 倍。在 10 台服务器上以 100 QPS 轮询的情况下，无论服务器是否已在处理长响应，每台服务器每秒都会收到 10 个请求。接收多个长请求的服务器会落后，而其他服务器则处于空闲状态。least-connections 将新工作路由远离那些繁忙的服务器，因此完成短请求的副本会立即接收新工作，并根据实际剩余工作量进行负载均衡。

表 10.30 报告了生产环境 LLM 服务中各路由算法的观测改进情况：

| 算法 | P99 延迟 | 负载方差 |

| --- | --- | --- |

| 轮询 | 45s | 3.2 请求 |

| 最少连接 | 28s | 0.8 请求 |

| 两个选择 + 最少连接 | 26s | 0.5 请求 |

表 10.30：LLM 路由算法对比：在高度可变的 LLM 工作负载下，轮询、最少连接和最少连接加两个选择路由的观测 P99 延迟和负载方差，量化了路由选择如何重塑尾部延迟。

系统洞察：最少连接将 P99 降低了 38%；结合两个选择可提供额外改进，因为路由遵循当前工作量而非仅请求计数。

面向有状态路由的一致性哈希

许多推理工作负载维护受益于路由亲和性的状态。LLM 对话复用前几轮的 KV 缓存，推荐会话携带用户上下文和最近交互，流式推理可能依赖前几帧的模型状态。对于这些工作负载，将同一用户或会话路由到同一服务器，通过避免缓存未命中和状态重建来提高性能。

一致性哈希[¹⁶¹]（Karger et al. 1997）根据路由键（用户 ID、会话 ID）的哈希值将请求映射到服务器：

server(request) = arg min[s ∈ S[srv]] distance(hash(key), hash(s))

其中 S[srv] 是映射到环上的服务器集合，每个请求路由到顺时针方向最近的服务器。

重要特性包括确定性、最小干扰和平衡性。相同的键始终路由到同一服务器，添加或移除服务器平均仅重新映射 K/N[servers] 个键，虚拟节点均匀分布负载，防止单个物理服务器拥有不成比例的键范围。对于 LLM 服务，最直接的收益是将每个用户的请求保留在已持有其会话状态的服务器上。

场景：LLM 服务系统跨对话轮次维护用户特定的 KV 缓存状态。

无亲和性：

• 用户发送消息，路由到服务器 A，构建 KV 缓存

• 下一条消息随机路由到服务器 B

• KV 缓存从头重建，500 ms 惩罚

• 平均对话：10 轮，4.5 秒浪费在缓存重建上

有亲和性的一致性哈希：

• 用户 ID 哈希到服务器 A

• 该用户的所有消息路由到服务器 A

• KV 缓存跨轮次复用

• 仅在服务器变更或缓存驱逐时重建

虚拟节点实现：

每个物理服务器在哈希环上有 100 个虚拟节点，尽管服务器异构，仍确保均匀分布。

Hash ring positions:
Server A: [0.01, 0.03, 0.07, 0.12, ...]  (100 positions)
Server B: [0.02, 0.05, 0.09, 0.15, ...]  (100 positions)
...

Request for user "alice":
hash("alice") = 0.0834
Nearest server clockwise: Server A (at 0.09)

处理服务器故障：当服务器 A 故障时，其 100 个虚拟节点从环中移除，受影响的请求重新路由到顺时针方向的下一台服务器，因此仅约 1/N[servers] 的所有请求受影响。

系统洞察：有状态服务将负载均衡转化为缓存局部性问题。路由层必须在不使故障恢复破坏性的前提下保持亲和性。

当缓存状态是用户特定时，相同的有状态路由机制成为正确性边界。

背景：ChatGPT 通过 redis-py 客户端使用 Redis Cluster 缓存用户信息，以减少高容量服务系统中的数据库查找（OpenAI 2023）。

故障模式：在特定的 Asyncio 连接复用 bug 下，请求可能会接收与另一个活跃用户关联的缓存数据，因为连接被回收时带有意外的响应状态。

后果：2023 年 3 月 20 日，OpenAI 让 ChatGPT 离线修复该问题，并报告一些用户能看到另一用户的对话标题数据和有限的支付相关信息。

系统教训：有状态推理基础设施需要围绕缓存、连接池和路由键的隔离保证。缓存是服务正确性边界的一部分，而不仅仅是优化。

分片模型的请求路由

第 10.5 节中探讨的分片策略引入了路由复杂性：单个推理请求可能需要在多个设备上进行计算，需要协调。路由模式取决于分片策略。

在张量并行下，每个请求广播到分片组中的所有设备。每个设备处理其负责的每层部分，结果通过 AllReduce 同步。图 10.16 展示了这种扇出、计算和聚合模式。

图 10.16：张量并行请求路由：请求从负载均衡器广播到分片组中的所有设备。每个 GPU 计算其分配的注意力头分区，然后单次 AllReduce 同步结果并返回响应。互连带宽——而非模型大小——决定了延迟。

图 10.16 中可见的关键约束是每个请求都需要跨分片组中所有设备进行 AllReduce 同步，使互连带宽成为决定延迟的因素，而非模型大小。

在流水线并行下，每个请求按顺序遍历各阶段，每个阶段将激活值转发给下一阶段。图 10.17 说明了即使单请求延迟等于所有阶段时间之和，流水线多个请求如何实现吞吐量扩展。

图 10.17：流水线并行请求流：(a) 单个请求按顺序通过四个阶段——并行性无延迟收益。(b) 多个请求填满流水线：达到稳态后，吞吐量随流水线阶段数扩展，而单请求延迟保持近似恒定。

流水线并行延迟与吞吐量

从图 10.17 中得出的关键洞察是：流水线并行无法为单个请求带来延迟收益：一个请求仍需依次通过所有阶段。只有当多个并发请求填满流水线时，吞吐量才会随阶段数量成比例地达到稳态吞吐量。

专家并行路由与负载不平衡

在专家并行下，每个请求根据门控决策被分发到承载其选定专家的设备上。如图 10.18 所示，两步 AllToAll 通信包裹着专家计算。负载不平衡是关键挑战：当门控函数不成比例地将请求路由至某些专家时，通信开销便会成为瓶颈。

图 10.18：专家并行（MoE）请求流程：门控选择 top-k 专家；首个 AllToAll 将 Token 分发至承载这些专家的 GPU；专家并行计算；第二个 AllToAll 收集结果。下半部分对比了不平衡路由（单个专家成为瓶颈）与平衡路由（通过辅助损失实现均匀利用率）。

正如图 10.18 所示，两步 AllToAll 通信使专家并行对负载不平衡独特地敏感：如果门控函数将 Token 集中在少数专家上，这些设备就会成为瓶颈，而其他设备则闲置。

利用分片组进行水平扩展

当多个分片组提供水平扩展时，负载均衡器路由至分片组而非单个设备。图 10.19 展示了这种两级层级：标准负载均衡算法（轮询、两次选择、一致性哈希）在分片组层面运行，而每个组在内部独立处理自己的 AllReduce。

图 10.19：利用分片组进行水平扩展：负载均衡器将每个分片组视为单个逻辑推理服务器。在每个组内，8 张 GPU 通过张量并行协同工作。增加分片组可线性扩展吞吐量；增加每组 GPU 数可降低单请求延迟。

图 10.19 中的两级层级实现了关注点分离：负载均衡器使用标准算法将每个分片组视为单个逻辑服务器，而内部 AllReduce 协调保持在每个组内部局部进行。增加分片组可线性扩展吞吐量；增加每组 GPU 数可降低单请求延迟。

健康检查与故障转移

只有当健康信号与故障模式匹配时，负载均衡器才能绕过故障进行路由。对于 ML 服务，一个存活的进程可能仍不可用，因为权重未加载、GPU 内存池耗尽，或首个请求将触发漫长的预热。因此，生产系统按成本从低到高、真实度从低到高分层实施健康检查。

存活探针

存活探针验证服务器进程正在运行：

GET /health/live
响应：200 OK（进程存活）或超时（进程死亡）

就绪探针

就绪探针更进一步，验证服务器能够处理请求（模型已加载、GPU 已初始化）：

GET /health/ready
响应：200 OK（可服务）或 503（未就绪）

深度健康检查

深度健康检查通过运行测试请求来验证实际推理是否工作：

POST /health/inference
Body: {"prompt": "test"}
响应：带有效输出的 200 OK，或错误

深度健康检查是防御传统 Web 服务器不存在的故障模式——静默硬件退化——的首要防线。具有退化 HBM 模块的 GPU 可能仍对进程级探针做出响应，却因激活张量中的 NaN 传播或静默位翻转而产生损坏的输出。副本返回 HTTP 200 并通过所有存活和就绪探针，但生成的每个序列都是胡言乱语。深度健康检查通过将已知探针输入的张量输出与预期边界进行验证来捕获此问题——例如检查 logit 分布是否保持在合理的熵范围内，以及输出中是否出现 NaN 或 Inf 值。标准健康检查对 GPU 加速服务器虽必要但不充分，后者面临这些硬件特有的故障模式。

场景：通过常规健康检查的 GPU 推理服务器

场景：GPU 推理服务器可通过常规进程健康检查，却仍无法服务真实请求。

GPU 内存压力：服务器可能存活但无法为新请求分配内存。

模型预热：加载后的首次推理较慢。仅在预热完成后标记为就绪。

这三层探针在快速故障检测与 GPU 驻留探测成本之间各自取得平衡；表 10.31 规定了存活、就绪和深度健康探针的间隔、超时和失败阈值。这些频率形成了一个梯度：就绪探针运行最快，因为路由决策依赖于它们；存活探针运行较慢，因为它们仅捕获进程死亡；深度健康检查运行最稀疏，因为它们消耗 GPU 资源以验证模型输出。

| 检查类型 | 间隔 | 超时 | 失败阈值 |

| --- | --- | --- | --- |

| 存活 | 10s | 5s | 3 次失败 |

| 就绪 | 5s | 3s | 2 次失败 |

| 深度健康 | 30s | 10s | 1 次失败 |

表 10.31：GPU 推理健康检查频率：GPU 推理服务器的存活、就绪和深度健康探针间隔、超时和失败阈值，在快速故障检测与 GPU 驻留探针成本之间取得平衡。

系统经验教训：服务进程存活 ≠ 模型副本就绪。GPU 内存、预热状态和模型输出有效性必须纳入健康契约。

定量分析：负载均衡的影响

负载均衡算法的选择对系统性能有定量影响。假设一个拥有 100 台服务器、10,000 QPS 且请求大小可变（变异系数 CV = 0.5）的系统。表 10.32 量化了延迟与开销的权衡：

| 算法 | 最大队列 | P99 延迟 | CPU 开销 |

| --- | --- | --- | --- |

| 随机 | 4.2 个请求 | 45 ms | 极小 |

| 轮询 | 2.8 个请求 | 32 ms | 极小 |

| 两次选择 | 1.9 个请求 | 24 ms | 2 次探测/请求 |

| 最少连接 | 1.4 个请求 | 19 ms | 全局状态 |

| 两次选择 + 最少连接 | 1.2 个请求 | 17 ms | 2 次探测 + 状态 |

表 10.32：负载均衡算法对比：更复杂的算法以降低队列长度和延迟为代价，增加了开销。

表 10.32 展示了熟悉的服务权衡：随机和轮询路由将 CPU 开销保持在接近零，但留下更长的队列和更高的延迟方差；两次选择仅以每请求两次探测的代价，将 p99 延迟大致减半；当请求成本变化大时，最少连接进一步改进，但需要全局状态；将两次选择与最少连接结合，以最高的实现复杂度换取最短的队列。

对于许多服务系统，两次选择在性能提升与实现复杂度之间提供了有力的权衡。对于请求大小方差大的工作负载（LLM 服务、推荐排序），最少连接增加了价值。

熔断器与背压

当 GPU 推理服务器变慢时，继续向其路由更多请求可能将局部减速演变为全舰队故障。热节流是典型触发因素：一个正常 50 ms 服务请求的副本开始耗时 500 ms，请求在其后排队，客户端超时触发重试，这些重试又将负载推向邻近副本。负载均衡器需要一种方式，不再将该副本视为仅仅“缓慢”，而是将其视为“不可用”。

熔断器模式

熔断器模式¹⁶² （Nygard 2007）提供了这种控制。在闭合状态下，服务器接收正常流量。当错误率、超时率或延迟超过阈值时，熔断器打开，请求会快速失败或路由至其他地方，而不是在饱和队列后等待。经过恢复间隔后，熔断器变为半开状态：它允许少量探测请求通过，如果探测成功则闭合，如果失败则重新打开。重要的系统特性是有限的爆炸半径。故障副本会足够快地失去流量，使其队列无法将过载传播给集群的其余部分。

背压传播通过使过载在上游可见来补充熔断器。当队列深度超过阈值时，服务器返回诸如 503 Service Unavailable 之类的信号；负载均衡器将副本标记为降级，并向其路由更少的请求。如果所有副本都变为降级，系统会从路由控制转向准入控制，在边缘拒绝部分请求，而不是接受无法在延迟 SLO 内服务的工作。熔断器隔离不健康的副本；背压告诉系统的其余部分在重试放大故障之前减速。

在 KV 缓存压力下饱和的 LLM 集群拥有三个通用背压无法提供的泄压阀：

• 上下文驱逐：从 KV 缓存中驱逐较旧的对话轮次，以减小上下文窗口并释放内存。

• 推测性解码：禁用推测性解码，以回收其草稿模型占用的 GPU 内存。

• 回退路由：将新请求路由到较小的量化回退模型，直到主队列排空。

每种响应都以输出质量或延迟为代价换取持续可用性，从用户角度来看，这通常比直接拒绝更可取。系统设计师必须指定在每个压力层级可接受的降级模式，因为正确的权衡取决于应用——实时助手比起静默的质量下降，更能容忍上下文截断。

场景：慢速服务器（热节流）

考虑一个服务器变慢（热节流）的场景：

无熔断器

1. 服务器 A 变慢（处理时间从 50 ms 变为 500 ms）

2. 负载均衡器继续向服务器 A 路由请求

3. 请求在服务器 A 上排队，开始出现超时

4. 重试逻辑将失败的请求发送给其他服务器

5. 其他服务器因重试流量而过载

6. 系统全面故障

有熔断器

1. 服务器 A 变慢

2. 服务器 A 的错误率升至 50% 以上

3. 服务器 A 的熔断器打开

4. 所有请求路由至服务器 B、C、D

5. 系统以降低的容量运行但保持稳定

6. 30 秒后，熔断器允许探测请求，若成功则闭合

系统教训：对于 GPU 推理，标准阈值和恢复设置见表 10.33。熔断器通过阻止重试将一个慢速副本放大为系统范围的过载，从而保留部分容量。

表 10.33：GPU 推理的熔断器设置

| 参数 | 值 | 理由 |

| :--- | :--- | :--- |

| 错误阈值 | 50% | GPU OOM 故障很严重 |

| 延迟阈值 | 2× 基线 | 尽早检测节流 |

| 打开持续时间 | 30 秒 | 排队排空后再探测 |

| 半开请求数 | 5 个请求 | 全面重新开放前谨慎测试 |

错误和延迟阈值、打开持续时间以及半开探测次数的选择，旨在快速隔离单个节流 GPU，而不会过早地使健康节点失效。

高效路由假设我们的推理服务器拥有底层硬件。然而，在企业环境中，我们关键的生产模型往往运行在与实验模型和开发者端点完全相同的物理集群上。为了防止流氓开发者查询导致我们的旗舰服务崩溃，我们必须强制执行严格的多租户和资源隔离。

多租户与隔离

考虑一个关键的客户支持聊天机器人与一个实验性计算机视觉脚本运行在同一 GPU 服务器上。如果实验性工作负载意外垄断了 PCIe 总线或内存带宽，面向客户的聊天机器人就会开始超时，违反 SLA。多租户和隔离确保了共置工作负载在省钱的同时，不牺牲旗舰服务的可预测性。

多租户挑战

多租户通过成本效率、运维简易性和统计复用来节省成本。共享基础设施提高了资源利用率，减少了待管理的集群数量，并使聚合流量比任何单个租户的流量更具可预测性。

一个租户的突发流量可能会降低共享池中每个工作负载的性能。

同样的共享也造成了隔离问题和多租户权衡，表 10.34 对此进行了阐述：吵闹的邻居会导致一个租户的突发降低其他租户的性能，资源争用跨越 GPU 内存、网络带宽和 CPU 周期，安全边界必须保护租户数据，且当租户有不同要求时 SLO 复杂性会增加。

表 10.34：单租户与多租户权衡

| 方面 | 单租户 | 多租户 |

| :--- | :--- | :--- |

| 资源利用率 | 30–50% | 70-90% |

| 每请求成本 | 较高 | 较低 |

| SLO 保障 | 简单 | 复杂 |

| 隔离性 | 完全 | 需要工程实现 |

| 运维开销 | 较高（许多集群） | 较低（较少集群） |

多租户降低成本，但需要精心的隔离工程。

吵闹邻居问题

吵闹邻居问题发生在一个租户的工作负载降低了共享同一基础设施的其他租户的性能时。这种干扰同时在三个资源维度上表现出来。

GPU 内存争用最为严重：拥有意外长序列的租户可能会消耗不成比例的 KV 缓存池份额。设想三个租户共享一个 60 GB 的 KV 缓存池，各自分配 20 GB。当一个租户开始发出长上下文请求时，其分配可能膨胀至 45 GB，迫使驱逐发生，将其他租户的并发序列数从各 200 个减少到 75 个——批处理大小减少 62%，直接降低了它们的吞吐量。当一个租户流式传输许多大响应消耗可用的出口容量时，网络带宽饱和会加剧这种影响。租户间的 GPU 时间共享引入了上下文切换开销和不可预测的延迟方差。测量吵闹邻居影响需要同时捕捉所有三个干扰维度。

问题：在无保护的共享池中，一个租户的突发如何改变每个租户的延迟？

考虑一个在共享 H100 GPU 上为 10 个租户服务的推理平台：

基线（均匀负载）

• 每个租户：100 QPS，P99 延迟 10 ms

• GPU 利用率：70%

• 所有 SLO 均达标

租户 3 突发至 500 QPS（基线的 5 倍）。若无每租户配额，该突发会级联为共享池上所有十个租户的 SLO 违规（表 10.35）：

表 10.35：无隔离的吵闹邻居（无保护池）

| 租户 | QPS | P99 延迟 | SLO 状态 |

| :--- | :--- | :--- | :--- |

| 租户 1 | 100 | 25 ms | 违规 |

| 租户 2 | 100 | 28 ms | 违规 |

| 租户 3 | 500 | 45 ms | 违规 |

| 租户 4-10 | 各 100 | 22-30 ms | 违规 |

当一个租户突发时，所有租户均违反其延迟 SLO。

系统洞察：只有当服务系统同时实施隔离时，共享容量才能提高利用率。没有配额，有效 SLO 就会变成任何租户能产生的最差突发流量。

启用按租户配额可将影响限制在违规租户自身（表 10.36）：

| 租户 || QPS (实际) || P99 延迟 || SLO 状态 |

| --- | --- | --- | --- | --- |

| 租户 1 || 100 || 10 ms || 达标 |

| --- | --- | --- | --- | --- |

| 租户 2 || 100 || 10 ms || 达标 |

| --- | --- | --- | --- | --- |

| 租户 3 || 120 QPS (已限流) || 50 ms || 违规 (仅限该租户) |

| --- | --- | --- | --- | --- |

| 租户 4-10 || 各 100 || 10 ms || 达标 |

表 10.36：带按租户配额的吵闹邻居：在同一工作负载中启用按租户资源配额后的按租户 QPS、p99 延迟和 SLO 状态。

系统洞察：配额将平台级故障转变为局部准入控制决策：突发租户被限流，而受保护租户保持其延迟契约。

资源配额与公平共享

资源配额限制每个租户可消耗的资源，防止任何单一租户垄断共享资源。硬性配额将共享服务转变为准入控制：系统在准许每个请求前检查并发度、KV 缓存内存和请求速率。清单 10.1 使用这三道关卡，使租户可在稀缺资源边界被限流，而不是降低整个批次的性能。

清单 10.1：资源配额：对并发度、KV 缓存内存和请求速率实施按租户限制的准入控制。

不变量是在干扰发生前拒绝。任何会超出租户配额的请求永远不会进入调度器，从而防止受保护租户因另一租户的突发而承担更高的排队延迟或 KV 缓存压力。

带有公平共享的软性配额提供了更灵活的替代方案。每个租户都有一个名义令牌生成配额（例如 10,000 tokens/sec），但当集群利用率不足（50% 容量）时，租户可突发至其配额的 2 倍。当集群饱和（90% 容量）时，强制执行配额。这种方法在低流量期间最大化利用率，同时在资源争用期间保护租户。

当总需求超过容量时，最大-最小公平分配资源以最大化跨租户的最小分配。算法首先给每个租户分配相等份额，然后将需求低于其相等份额的租户的未用容量重新分配。原始请求数是此计算的不充分单位，因为正如 10.7 节 所确立的，相等的请求数不等于相等的负载——发出长上下文摘要请求的租户消耗的 KV 缓存和解码计算远多于发出短分类查询的租户。令牌生成速率 (tokens/sec) 作为合适的边界指标，同时捕捉吞吐量和内存压力。对于三个需求分别为 30,000、20,000 和 80,000 tokens/sec、竞争一个能提供 100,000 tokens/sec 的 GPU 池的租户，最大-最小公平产生的分配为 30,000、20,000 和 50,000——每个租户获得其需求或其公平份额中较小者，超额容量按比例重新分配。

优先级调度

当租户有不同的 SLO 要求时，优先级调度确保高优先级请求优先获得资源。表 10.37 显示抢占权和资源保证在三个类别中一起向下移动：关键流量既可抢占任何较低类别又保留容量，而尽力而为流量从不抢占且无保证，因此 SLO 层级直接映射到抢占阶梯上的一个位置。

| 类别 || 用例 || 抢占 || 资源保证 |

| --- | --- | --- | --- | --- |

| 关键 || 产生收入 || 可抢占较低类别 || 100% 预留 |

| --- | --- | --- | --- | --- |

| 标准 || 通用流量 || 可抢占尽力而为 || 加权份额 |

| 尽力而为 || 后台、批处理 || 不可抢占 || 无保证 |

表 10.37：优先级调度类别：多租户推理的三层优先级层级。关键流量获得 100% 预留容量且可抢占任何较低类别；标准流量按比例共享容量且可抢占尽力而为；尽力而为在剩余容量上运行且无保证。

调度器按优先级类别对传入请求排序，然后按同类别内的到达时间排序。当新的关键请求到达时，它会跳到队列中所有标准和尽力而为请求前面，确保产生收入的流量永远不必在后台批处理作业后面等待。

抢占将这一原则扩展到已在执行的请求。当关键请求到达且所有 GPU 插槽均被较低优先级工作占用时，调度器从最低优先级类别中选择一个受害者，将其 KV 缓存状态保存到 CPU 内存，并释放 GPU 插槽。关键请求完成后，被抢占的请求从其保存状态恢复，而不是从头重启。这种检查点-恢复机制使抢占对自回归生成变得实用，因为丢弃部分输出会浪费迄今生成的所有令牌。

舱壁模式

舱壁模式¹⁶³ (Nygard 2007) 物理隔离租户工作负载，防止故障跨租户传播。该模式以将洪水限制在隔离舱段的船舱壁命名。

最强形式的舱壁将整个副本专门分配给特定租户或租户组。图 10.20 演示了金牌级和标准级之间的部署级隔离：

图 10.20：舱壁隔离模式：为防止多租户系统中的级联故障，舱壁隔离资源。部署级舱壁（图示）为高优先级租户分配专用物理副本，确保完全隔离。请求级舱壁在共享进程内强制执行严格的并发限制。如同船舱壁，这些边界确保一个片段中的故障或资源耗尽不会拖垮整个平台。

部署级舱壁为高级租户提供完全隔离，确保其性能永不受其他工作负载影响。权衡是整体资源利用率降低，且管理专用基础设施的运营开销增加。

请求级舱壁通过限制共享进程内任何单个请求可消耗的资源，补充了这种物理隔离。限制输入长度（例如 8,000 令牌）、输出长度（2,000 令牌）和执行时间（30 秒），防止单个病态请求垄断 GPU 数分钟，而其他请求在其后排队。

故障隔离自然源于舱壁边界。当租户提交触发模型错误的畸形输入时，舱壁将故障限制在该租户的请求内；其他租户继续正常处理，而不是共享一个崩溃的推理工作进程。在多租户部署中，这些边界通常与服务层级对齐，每个层级具有不同的资源保证。

场景：一个典型的 LLM API 拥有企业版、专业版和免费服务层级。

设置

企业版运行在具有硬件隔离的专用 GPU 池上，拥有 99.9% 的可用性 SLO —— 其他租户的流量无法影响它。专业版共享一个 GPU 池，但通过资源配额获得该池 70% 的容量，并在出现争用时可以抢占免费版。免费版按最佳努力方式获得剩余的 30%，带有速率限制（例如 10 QPS）且无 SLO 保证。

系统经验教训：隔离舱将隔离成本集中在业务需求证明其合理性的地方，同时仍允许共享基础设施在高利用率下运行。

模型隔离

当多个模型在共享基础设施上运行时，隔离必须涵盖内存、计算和模型加载。内存隔离对 GPU 内存进行分区，使得一个模型的分配无法侵占另一个模型的内存。例如，在一张 80 GB 的 H100 上，为一个模型预留 40 GB，为第二个模型预留 30 GB，留下 10 GB 的共享池用于临时需求 —— 无论另一个模型的请求模式如何，每个模型的 KV 缓存增长都受到限制。

计算隔离解决了 GPU 时间片共享引入的延迟方差问题。MIG（多实例 GPU）¹⁶⁴ 通过在空间上将 GPU 分区为硬件隔离的实例，每个实例拥有专用的 SM、内存带宽和 L2 缓存，提供了最强的保证。时间片切分提供了一种开销较高的较软替代方案，而为每个模型专用整张 GPU 则以利用率换取完全隔离。

模型加载提出了一个更微妙的隔离挑战：加载新模型不应将正在运行的模型从 GPU 内存中驱逐。清单 10.2 将该策略实现为一种故障安全的内存检查：仅驱逐优先级较低、可驱逐的模型，并在剩余内存受保护时拒绝加载。

清单 10.2：模型加载隔离：防止模型驱逐违反租户隔离约束的优先级感知内存管理。

该拒绝路径即是隔离保证。它可能暂时降低利用率，但能防止控制平面的加载请求演变成非计划的模型驱逐或租户可见的故障。

多租户可观测性

有效的多租户需要对每个租户的资源消耗和性能具有可见性。关键指标跨越四个维度：请求量和延迟分布（P50、P95、P99）、GPU 内存和 KV 缓存利用率、限流和抢占事件计数，以及按错误类型细分的错误率。这些指标共同揭示每个租户是否正在获得其合同约定的服务质量。

三个告警阈值将这些指标转化为可执行的信号：

• SLO 违规：当租户的 P99 延迟连续五分钟超过其目标 10% 以上时触发告警。

• 配额耗尽：当使用量达到租户分配额度的 90% 时触发告警，在硬性限制导致请求被拒之前提供预警。

• 吵闹邻居检测：当租户消耗超过其公平份额两倍且持续五分钟时，识别出该租户，在干扰级联到其他租户之前进行标记。

回充和归因通过将资源消耗（GPU 秒数、KV 缓存 GB-小时、网络流出量）映射到各个租户以用于计费和容量规划，闭合了运营环路。没有按租户归因，组织就无法区分需要更多容量的租户和仅仅是低效的租户，从而无法做出明智的扩容决策。

适当的隔离允许我们将工作负载安全地打包到一组固定的服务器上。然而，互联网上的流量很少是固定的。为了在不烧钱的情况下应对病毒式产品发布或深度夜间低谷，我们隔离的推理服务必须通过智能自动扩缩容，跨全球数据中心动态增减。

自动扩缩容与全球基础设施

一条病毒式传播的社交媒体帖子在五分钟内将生成式 AI 应用的流量推高了 10 倍。如果基础设施团队依赖手动扩缩容或缓慢的基于 CPU 的指标来启动新的 GPU 实例，服务将在新副本甚至还没下载完模型权重之前就崩溃。ML 推理的自动扩缩容需要预测性的自定义指标策略来应对这些巨大的负载动态。

该响应包含四个耦合维度：如何增加容量、新副本需要多长时间才能变得有用、预测信号如何避免冷启动延迟，以及全球路由如何在容量或区域故障时转移流量。将自动扩缩容视为一个副本计数旋钮，忽略了模型加载、缓存预热、竞价实例容量和用户地理位置之间的相互作用。

扩缩容维度

推理系统可以沿三个维度进行扩缩容，每个维度具有独特的成本、延迟和速度特征。表 10.38 对比了这些方法。

一种常见的方法是水平扩缩容：增加或减少模型副本以调整聚合吞吐量。总容量按 容量 = 副本数 × 单副本吞吐量 线性扩展，但每个新副本都需要以分钟计的供应时间。

当副本数固定时，垂直扩缩容用更强大的 GPU 替换现有 GPU 以提高单副本吞吐量。成本效率为 吞吐量/GPU 成本，但垂直扩缩容需要重新部署，是最慢的扩缩容响应。

最快的响应来自批大小扩缩容，它调整系统同时处理的请求数量。增加批大小以更高的单请求延迟换取更大的吞吐量，且无供应延迟。这使得批大小成为流量高峰期间首先调整的旋钮，为水平扩缩容生效争取时间。这些扩缩容维度的权衡总结在表 10.38 中。

| 扩缩容类型 | 延迟 | 成本 | 速度 |

| --- | --- | --- | --- |

| 水平（增加副本） | 不变 | 线性 | 慢（分钟级） |

| 批大小 | 增加 | 不变 | 即时 |

| 垂直（更好的 GPU） | 不变 | 非线性 | 非常慢（需重新部署） |

表 10.38：扩缩容维度权衡：水平扩缩容保持单请求延迟不变但等待供应，批大小扩缩容通过以延迟换吞吐量即时响应，垂直扩缩容改变硬件包络但需要重新部署。

冷启动问题

冷启动延迟对无服务器推理构成重大挑战，因为模型加载往往主导了总启动时间。与几秒内即可启动的无状态 Web 服务不同，推理服务在服务流量前必须完成硬件供应、权重加载和运行时内核预热，如公式 10.14 所定义：

Tcold start = Tprovision + Tload + Twarmup (10.14)

供应阶段（Tprovision）获取一个 GPU 实例，耗时 30 秒到数分钟不等，取决于云提供商和 GPU 类型。¹⁶⁵ 仅此延迟就超过了无状态 Web 服务的总冷启动时间。

实例可用后，模型加载（Tload）将权重从存储传输到 GPU 内存。加载时间随模型规模扩展，且高度依赖存储层级，如表 10.39 所示：

| 模型规模 | 加载时间 (SSD) | 加载时间 (S3) |

| --- | --- | --- |

| 7B (14 GB) | 5s | 30s |

| 70B (140 GB) | 25s | 5min |

| 175B (350 GB) | 1min | 12min |

表 10.39：不同存储层级的模型加载时间：本地 SSD 以约 6 GB/s 的速度加载权重；远程对象存储 (S3) 在额外验证和运行时开销之前以约 0.5 GB/s 的速度加载。对于最大的模型，12 倍的差距影响最大：一个 175B 模型从 SSD 加载约需 1 分钟（350 GB，按 6 GB/s 计），而从 S3 加载则需 12 分钟，这主导了每次扩容都必须从对象存储拉取权重的任何服务部署的冷启动预算。

即使权重已驻留在 GPU 显存中，首次推理的运行速度也比稳态慢，因为即时 (JIT) 内核编译、CUDA 上下文初始化、内存池分配和缓存填充必须完成。此预热阶段 (T[warmup]) 通常需要 10–30 次虚拟推理，增加 5–30 秒的延迟。Llama-70B 的逐阶段时间线展示了这些延迟在实践中如何累积。

表 10.40 追踪了在 H100 上启动一个新的 Llama-70B 副本的各阶段及累计时长：

| 阶段 | 时长 | 累计时长 |

| --- | --- | --- |

| 云 API 请求 | 5s | 5s |

| GPU 实例预配 | 60s | 65s |

| 容器启动 | 10s | 75s |

| 模型下载 (S3) | 300s | 375s |

| 模型加载至 GPU | 25s | 400s |

| CUDA 预热 | 15s | 415s |

| 就绪探针通过 | 5s | 420s |

| 冷启动总计 | 7 分钟 | |

表 10.40：Llama-70B 副本的冷启动时间线 (H100)：在 H100 实例上启动一个全新的 Llama-70B 服务副本的各阶段及累计时长。

系统洞察：扩容决策必须提前数分钟预判需求。仅靠被动扩容无法应对突发流量峰值。

图 10.21 可视化了累计时间线：

图 10.21：冷启动剖析：启动一个新的 GPU 推理副本是一个耗时数分钟的多步骤过程。虽然容器启动很快，但预配专用实例和下载海量模型权重 (100 GB+) 主导了时间线。CUDA 上下文初始化和“预热”推理过程增加了进一步的延迟。大约 7 分钟的滞后使得纯粹的被动扩容在应对突发流量峰值时变得危险。

被动扩容

被动扩容在系统观测到压力后调整容量。它适用于渐进式的需求变化，但无法单独解决冷启动问题，因为信号到达时流量已已到达集群。

基于指标的扩容是一个带阈值的控制回路。清单 10.3 将目标运行点与扩容和缩容阈值分离，而冷却周期防止控制器在新副本影响指标之前撤销其上一个决策。

清单 10.3：基于指标的扩容：由利用率阈值驱动的自动扩容策略，带有冷却周期以防止震荡。

这些字段编码了响应性与稳定性的权衡。更严格的阈值反应更快，但在嘈杂的利用率下可能会震荡；更长的冷却期能抑制震荡，但在真实峰值发生后会让集群过载更久。

一种更灵敏的替代方案是基于队列深度而非利用率进行扩容，目标是每个副本的最大队列长度：

\[\\text{期望副本数} = \\left\\lceil \\frac{\\text{队列深度}}{\\text{队列目标}} \\times \\text{当前副本数} \\right\\rceil \]

当主要关注点是 SLO 合规而非利用率时，基于延迟的扩容会调整副本数以维持目标 P99 延迟：

\[\\text{期望副本数} = \\left\\lceil \\frac{\\text{P99}\_{\\text{观测值}}}{\\text{P99}\_{\\text{目标值}}} \\times \\text{当前副本数} \\right\\rceil \]

所有被动方法都有三个根本局限：

• 冷启动脆弱性：冷启动时间阻碍了对突发峰值的快速响应。

• 震荡风险：基于指标的触发器可能在扩容和缩容循环之间产生震荡。

• 过度预配要求：系统必须在冷启动窗口期间过度预配，以吸收新副本尚无法处理的负载。

这些限制在流量峰值期间表现得最为尖锐，此时副本必须在冷启动容量变得可用之前就已存在。

考虑流量从 1000 QPS 飙升至 3000 QPS 的场景：

当前状态：10 个副本，每个 100 QPS，利用率 70%

目标状态：30 个副本以应对 3000 QPS

无预热情况下：

• T=0：检测到峰值，触发扩容

• T=0 至 T=5 分钟：20 个新副本冷启动

• T=0 至 T=5 分钟：现有 10 个副本处理 3000 QPS（每个 300 QPS）

• 利用率：210%（过载）

• P99 延迟：500 ms+（违反 SLO）

有充足热备副本 (20 个) 情况下：

• T=0：检测到峰值，热备副本立即激活

• T=0：30 个副本处理 3000 QPS（每个 100 QPS）

• T=0 至 T=5 分钟：后台补充 20 个热备副本

• 利用率：70%（保留余量）

• P99 延迟：80 ms（满足 SLO）

热备副本将冷启动延迟转化为闲置容量成本：系统在峰值前支付额外副本的费用，以便用户在峰值期间无需为预配延迟买单。

在互联网级发布规模下，同一个冷启动窗口从容量规划的麻烦变成了基础设施生存问题。

背景：当 ChatGPT 在两个月内从零增长到 1 亿用户时，工程挑战从模型质量转移到了生存层面。

故障模式：服务面临前所未有的冷启动问题：在预配数千个 GPU 的同时，管理一个随着上下文长度和请求并发线性增长的 KV 缓存内存占用。早期的服务基础设施不得不迅速演进，转向优化的服务层、激进的批处理和量化，以及地理负载均衡，以便在请求洪流下保持单 token 延迟在可接受范围内。

系统教训：成功的模型发布可能引发基础设施故障模式。在服务规模下，需求增长、状态内存和预配延迟成为产品架构的一部分。

预测性扩容

预测性扩容在需求发生前预判需求，提前于流量变化启动扩容。最简单且最有效的方法是利用历史流量模式进行时间序列预测。清单 10.4 展示了一个结合每日季节性、每周季节性和趋势估计的简化预测函数。然而，对于生成式 LLM 服务，仅预测请求量是不够的：长上下文摘要请求的量级峰值比相同数量的短上下文聊天完成请求消耗 KV 缓存的速度快得多，因为每个长上下文请求在解码完成时可以在活跃 KV 缓存中持有数万个 token。因此，LLM 集群的精准预测性扩容必须在预测总量的同时预测请求类型的组合，即使请求数量不变，也要将向长上下文请求的转变视为一种内存受限的需求增长。

清单 10.4：预测性扩容：结合每日季节性、每周季节性和趋势估计的时间序列需求预测。

当需求有一个平台可信赖的外部时钟时，事件驱动扩容非常有用。清单 10.5 为产品发布或周期性批处理窗口预先调度容量，利用 ramp-up 字段隐藏冷启动，利用 duration 字段在事件结束后释放额外副本。

清单 10.5：事件驱动扩容：为产品发布和周期性流量峰值预配置容量的计划扩容规则。

此模式适用于发布、批量刷新和日历驱动的流量；它无法替代针对非计划需求的响应式控制，因为计划的好坏取决于事件模型的准确性。

在实践中，单靠预测或事件计划都不足够。生产系统将预测基线与响应式调整相结合，以同时应对预期模式和意外偏差：

目标副本数 = max(预测值, 响应值) + 缓冲量

每日模式使该规则的主动侧具体化。

表 10.41：聊天机器人服务的每日流量模式 展示了一个聊天机器人服务可预测的昼夜流量变化：

| 时间 (UTC) | 典型 QPS | 所需副本数 |

| --- | --- | --- |

| 00:00-06:00 | 500 | 5 |

| 06:00-09:00 | 1500 | 15 (扩容) |

| 09:00-17:00 | 3000 | 30 (峰值) |

| 17:00-20:00 | 2000 | 20 (缩容) |

| 20:00-00:00 | 1000 | 10 |

预测性自动扩缩容器将该需求曲线转换为 表 10.42 中的计划，其中每次扩容动作比其对应的流量上升期早约 30 分钟启动（05:30 为 06:00 的上升预热 10 个副本，08:30 为 09:00 的峰值再预热 15 个副本）。这种刻意的提前量正是响应式旋钮无法预见的冷启动延迟所能吸收的。

| 时间 | 动作 | 活跃副本数 | 启动中副本数 |

| --- | --- | --- | --- |

| 05:30 | 扩容 | 5 | +10 预热中 |

| 06:00 | 流量上升 | 15 | - |

| 08:30 | 扩容 | 15 | +15 预热中 |

| 09:00 | 峰值流量 | 30 | - |

| 17:00 | 缩容 | 20 | -10 终止中 |

| 20:00 | 缩容 | 10 | -10 终止中 |

| 00:00 | 缩容 | 5 | -5 终止中 |

表 10.42：预测性扩缩容计划：同一聊天机器人服务的分时间桶扩缩容动作、活跃副本数及冷启动预热中的副本数。

系统洞察：纯响应式自动扩缩容器必须在每次上升期过度配置（峰值约 45 个副本），因为它无法预判曲线。预测性扩缩容将机群规模调整至实际峰值（30 个副本），在不牺牲延迟余量的前提下，回收了约 33% 的 GPU 开支。

上述成本节省取决于在流量到达前对其进行预判。如 图 10.22 所示，主动预置避免了纯响应式系统在上升期间遭遇的 SLO 违规。

图 10.22：预测性扩缩容 vs 响应式扩缩容：响应式扩缩容（红线）在流量峰值发生后做出反应，导致因冷启动延迟而在扩容不足期间出现 SLO 违规。预测性扩缩容（蓝线）预判流量并在峰值到达前开始预置容量，确保性能一致。

预热池管理

维护一个预热副本池，通过在需求到达前购买空闲就绪状态，可缩短有效冷启动时间。预热池大小的计算起始于预期峰值和单副本吞吐量：

预热池大小 = (最大预期峰值 / 单副本吞吐量) × 余量因子

例如，如果最大预期峰值是正常水平的 2 倍且余量因子为 1.5，则机群需在峰值到达前准备好最小池容量的 3 倍：

预热池 = 2 × 1.5 = 3 × 最小池容量

维护预热副本的成本为 池大小 × GPU 成本/小时 × 空闲比例，这在响应速度和空闲容量开支之间形成了直接的权衡。分层预热池（见 表 10.43）通过在不同就绪级别维护副本（每个级别具有不同的激活延迟和成本）来解决这一权衡：

| 层级 | 状态 | 响应时间 | 成本 (相对) |

| --- | --- | --- | --- |

| 热 | GPU 已加载，运行中 | 即时 | 100% |

| 温 | GPU 已分配，模型已加载 | 30s | 60% |

| 冷 | GPU 未分配 | 5+ 分钟 | 0% |

表 10.43：分层预热池就绪级别：三个就绪层级在激活延迟与空闲容量成本间权衡。热副本以全额成本即时吸收突发；温副本在 30 秒内激活，成本为 60%；冷副本零成本但需 5 分钟以上上线。生产部署通常结合少量热池、较大温池和无限冷容量。

当流量峰值来袭时，扩缩序列会立即激活热副本，在 30 秒内提升温副本，仅当需求持续超出温池容量时才冷启动新实例。典型配置维护 2 个热副本用于即时突发吸收和 5 个温副本用于持续峰值，并可从云提供商获取无限冷容量。

扩缩响应时间分析

扩缩响应预算是控制环路的检测、决策、预置和预热延迟之和。公式 10.15 明确列出了这些阶段：

T[响应] = T[检测] + T[决策] + T[预置] + T[预热]   (10.15)

表 10.44 拆解了各项及其主要优化路径：

| 组件 | 时长 | 优化 |

| --- | --- | --- |

| 检测 | 10–60s | 降低指标采集间隔 |

| 决策 | 1–5s | 更快的自动扩缩容器 |

| 预置 | 30s–5min | 预热池 |

| 预热 | 5–30s | 预编译 |

表 10.44：扩缩响应时间组件：扩缩事件的四个阶段及其典型时长和主要优化杠杆。预置阶段在预算中占主导地位（高出一个数量级），这正是预热池成为延迟敏感型服务机群高杠杆优化手段的原因。

每个组件提供不同的优化机会。检测速度可通过以 1 秒而非 60 秒的间隔收集指标来提升，代价是信号更嘈杂和指标量更大。决策速度可通过为预测场景预计算扩缩计划来提升，这样触发器一触发，系统即执行预计算计划而非从头计算。预置速度通过预热池获得最显著提升，它完全消除了针对预期需求的预置阶段。预热速度通过预编译推理引擎（跳过 JIT 编译）提升，将最后阶段从 30 秒缩减至 5 秒以内。

抢占式实例与竞价实例

云提供商可能提供折扣 GPU 实例[¹⁶⁶]，这些实例可能在短时间通知后被回收，因此调度决策在于工作负载能否在不违反 SLO 的前提下完成排空、重路由或重算。表 10.45 列出了三类 GPU 实例及各自最适用的工作负载：

| 实例类型 | 折扣 | 中断通知 | 用例 |

| --- | --- | --- | --- |

| 按需 | 0% | 从不 | SLO 关键型 |

| 预留 | 30-60% | 从不 | 稳定基线 |

| 竞价/抢占式 | 60–90% | 30s–2min | 突发容量 |

表 10.45：按定价与可靠性分类的 GPU 实例类型：三类 GPU 实例在折扣与中断风险间权衡。按需实例为基准价格，无中断；预留实例以预先承诺换取中等折扣；竞价实例以抢占风险换取大幅节省。生产机群常运行预留 + 按需实例作为基线，并突发式使用竞价容量处理尽力型流量。

Spot 实例终止处理是一场与供应商警告时间窗口的赛跑。清单 10.6 对关闭路径进行了排序，使新工作首先停止、在途工作在剩余时间内耗尽、可恢复状态得以持久化，且负载均衡器在实例消失前停止发送流量。

清单 10.6：Spot 实例终止处理：优雅关闭序列，耗尽在途请求，持久化 KV 缓存状态，并从负载均衡器注销。

顺序至关重要，因为这些步骤不可互换。过早注销会浪费有用的算力，但在关机后保存状态会丢失 KV 缓存；处理程序通过先耗尽、仅在副本无法安全接受工作后再路由离开来保持可用性。

感知 Spot 的架构按 SLO 类别将流量拆分到按需实例和 Spot 实例副本上，如图 10.23 所示。SLO 关键请求始终路由到按需算力，而尽力而为请求吸收 Spot 实例的成本节省和中断风险。

图 10.23：感知 Spot 的流量分发：负载均衡器将 70% 的流量路由到按需副本（保证可用性），30% 路由到 Spot 副本（节省成本，抢占风险）。SLO 关键请求始终使用按需实例；尽力而为请求容忍驱逐时的偶尔重试。在代表性折扣场景中，混合机群相比 100% 按需实例实现了约 18–27% 的成本降低。

图 10.23 中的拆分架构在代表性折扣场景下相比全按需机群实现了约 18–27% 的成本降低，同时仅对尽力而为流量承担抢占风险，并将 SLO 关键请求保留在有保障的算力上。

全球推理基础设施

当距离、故障域或数据驻留约束超出单个区域的掩盖能力时，全球服务变得必要。东京的用户期望低延迟响应，无论模型在哪里训练或公司总部在哪里；工程选择在于：是复制算力、缓存重复工作，还是集中模型并支付网络惩罚。架构模式仅在与该选择挂钩时才有用。

为什么多区域很重要

单区域部署造成了三个根本限制。最直接的是由到远端用户的网络往返时间（RTT）强加的延迟下限，如表 10.46 量化所示：

| 用户位置 || RTT 到 US-East || RTT 到本地区域 |

| --- | --- | --- | --- |

| 纽约 || 10 ms || 10 ms |

| 伦敦 || 75 ms || 10 ms |

| 东京 || 150 ms || 10 ms |

| 悉尼 || 200 ms || 10 ms |

表 10.46：按用户位置划分的网络 RTT：单一 US-East 部署给欧洲、亚洲和澳大利亚用户强加了 75 到 200 ms 的 RTT——比本地区域的下限高出一个数量级。对于每个请求进行多次模型调用的交互式工作负载，此延迟下限会迅速累积，促使任何全球分布的用户群采用多区域部署。

对于交互式应用（聊天机器人、自动补全），这些延迟会跨每个请求的多次模型调用累积。除了延迟，单区域部署还造成了单点故障：云区域中断虽罕见，但会同时影响所有用户。监管约束增加了第三个维度，因为数据驻留要求（《通用数据保护条例》(GDPR) 和数据主权法律）可能要求在特定地理边界内处理用户数据。由此产生的模式形成了一架决策梯：区域副本部署成本最高，但将 RTT 和区域故障隔离降至最低；边缘缓存仅在查询重复时付出运维复杂度；跨区域分片是因算力短缺而采取的最后手段，因为区域间延迟会淹没每阶段的计算时间。

模式 1：带区域副本的全球负载均衡

每个区域运行具有相同模型的独立推理副本。全球负载均衡器根据测量的往返延迟将每个用户路由到最近的区域，如图 10.24 所示。共享模型注册表在推出期间跨区域同步权重。

图 10.24：多区域推理：全球负载均衡：全球负载均衡器基于延迟将请求路由到三个独立的区域部署（US-East、EU-West、Asia-Pacific）。每个区域独立运行；共享模型注册表同步权重。区域故障时，LB 重新路由到下一个最近的健康区域。

如图 10.24 所示，独立区域副本将远端用户的 RTT 从 150–200 ms 降低到 10 ms 以下，而共享模型注册表确保跨部署的一致性。模型同步是首要架构关注点：更新必须传播到所有区域。基于推送的同步让中央注册表推送到每个区域，简单但会产生可能的不一致窗口；基于拉取的同步让区域轮询更新，以更高的推出延迟换取更强的一致性；混合同步结合推送通知与拉取验证。版本一致性是第二个关注点。推出期间，不同区域可能短暂服务不同版本。对大多数应用可接受，但要求严格一致性的应用需要在请求路由中进行版本固定。

模式 2：带中央推理的边缘缓存

对于过大而无法全球复制的模型，在边缘缓存响应可消除重复查询的冗余推理。图 10.25 显示了两条路径：缓存命中从最近边缘节点在 10 ms 内返回；缓存未命中遍历完整后端并在返回时填充缓存。

图 10.25：边缘缓存：缓存命中与缓存未命中路径：缓存命中从 CDN 边缘节点立即返回（<10 ms）。缓存未命中流经中央推理并在返回时填充缓存。命中率决定有效成本节省；开放式生成工作负载重复性低，受益于此模式甚微。

图 10.25 中的两条路径凸显了数量级的延迟差异：缓存命中在 10 ms 内返回，而缓存未命中承担完整的后端往返。有效性取决于自动补全、FAQ 聊天机器人、开放式聊天和代码生成等工作负载的请求重复性，表 10.47 量化了这一点：

| 工作负载 || 缓存命中率 || 适用性 |

| --- | --- | --- | --- |

| 自动补全 || 60–80% || 极佳 |

| FAQ 聊天机器人 || 40-60% || 良好 |

| 开放式聊天 || 5-15% || 差 |

| 代码生成 || 20–40% || 中等 |

表 10.47：按工作负载划分的边缘缓存命中率：缓存有效性几乎完全取决于请求重复性。自动补全和 FAQ 工作负载具有高前缀重叠，受益显著；开放式聊天输入近乎唯一，几乎不受益。命中率范围决定了边缘缓存是否值得为给定工作负载付出运维复杂度。

语义缓存¹⁶⁷（基于嵌入相似性而非精确匹配的缓存）可提高开放式工作负载的命中率。

模式 3：跨区域模型分片

跨区域模型分片与量化优化

跨区域模型分片

跨区域模型分片是最后手段的容量策略，而非常规的延迟优化。对于最大规模的模型，流水线并行理论上可以跨区域：路由器将早期层分配给一个区域，后期层分配给另一个区域。这种模式极少实用，因为区域间网络延迟（75–150 ms）主导了每阶段的计算时间（1–5 ms），导致跨区域流水线并行比同地部署慢 10–100 倍。仅当没有单个区域拥有足够的 GPU 容量容纳完整模型时才适用。

由于跨区域分片在稳态路径上代价极高，大多数生产设计保持推理同地部署，并使用其他区域实现弹性。因此，跨区域问题从“将一个请求拆分到多个区域”转变为“当区域故障时，流量能多快迁移”。

跨区域故障转移

当某个区域不可用时，流量必须重新路由到健康区域。Listing 10.7 展示了主动-主动故障转移路由逻辑，在超时或不可用后回退到下一个健康区域。

Listing 10.7: Active-Active Failover：全局路由，在超时或不可用时回退到第二近的健康区域。

有状态的 LLM 服务使故障转移比普通 HTTP 路由更难，因为接收区域必须同时吸收流量和丢失的会话状态。会话亲和性丢失意味着对话中的用户会丢失 KV 缓存状态，因此回退区域必须从对话历史中重新生成上下文。接收区域还会看到突发的容量尖峰，需要预先预留的冗余，通常为稳态之上的 30–50%，或者在故障转移期间接受降级的延迟。当故障区域恢复时，渐进式恢复会缓慢地将流量切回，以避免震荡。

全球模型部署

跨区域部署模型更新需要仔细协调。分阶段发布从对单个区域进行金丝雀部署开始（通常为 1% 的流量），监控 1–4 小时，然后逐步扩展到其他区域。每个扩展点都是一个关卡：如果错误率超过 0.1% 或 P99 延迟超过目标，发布将暂停。回滚将受影响的区域切回之前的模型版本，同时保留新版本用于调试。关键不变量是：在前一个区域展示出足够监控窗口内的健康指标之前，任何区域都不会进入新版本。

全球部署健康要求在每个区域和全局层面监控四个指标，如 Table 10.48 所示：

| Metric | Per-Region | Global |

| --- | --- | --- |

| Error rate | < 0.1% | < 0.1% |

| P99 latency | < target | < 2× single-region |

| Throughput | Stable | Stable |

| Model quality | Within bounds | Consistent across regions |

Table 10.48: Global Deployment Health Metrics：分阶段发布期间在每个区域和全局粒度监控的四个指标。每个区域的阈值捕获局部回归；全局阈值捕获跨区域效应（例如 P99 膨胀超过单区域目标的 2 倍），这是任何单区域检查都无法发现的。

跨区域成本优化

GPU 定价因区域而异。Table 10.49 显示了代表性的 H100 价格，以便部署能在成本和延迟要求之间取得平衡：

| Region | H100 Spot Price | On-Demand | Latency to US Users |

| --- | --- | --- | --- |

| US-East | $2.50/hr | $4.00/hr | 10–50 ms |

| US-West | $2.30/hr | $3.80/hr | 30–70 ms |

| EU-West | $2.80/hr | $4.20/hr | 75–100 ms |

Table 10.49: H100 Pricing and Latency by Region：代表性的 H100 抢占式和按需价格，以及到美国用户的 RTT。区域间 20% 的价差与延迟差异相比较小，因此成本感知路由通常仅将对延迟容忍的工作负载（批量推理、后台处理）发送到最便宜的区域，同时保持交互式流量本地化。

成本感知路由将对延迟容忍的工作负载（批量推理、后台处理）导向最便宜的可用区域，如 Listing 10.8 所示。

Listing 10.8: Cost-Aware Routing：基于优先级的路由，将低优先级的批量请求发送到最便宜的区域，同时保持交互式流量本地化。

基于时间段的路由可以在为交互式流量维持 SLO 的同时，将批量工作负载的成本降低 20–40%。

激进地扩展全球基础设施非常有效，但也极其昂贵。为了进一步压低部署成本曲线，我们必须再次向内看模型本身，通过权重量化改变其基本数学表示，使其运行得更快、更便宜。

服务推理的权重量化

INT4 将双 GPU 模型变为单 GPU 候选。

服务推理的权重量化是一个瓶颈选择决策：将权重从 16 位浮点数降低到 8 位或 4 位整数，可以将一个需要两张 A100 GPU 的 140 GB FP16 语言模型变为适合单张 GPU 的 35 GB INT4 表示。权衡是以少量精度损失换取内存带宽和容量需求 4 倍的减少。

在服务系统中，量化不仅仅是模型压缩技术；它改变了绑定资源。训练后量化 (PTQ) 可以在不重新训练的情况下压缩已部署模型，而量化感知训练 (QAT) 则投入训练精力以在较低精度下保持精度。系统问题在于：低精度表示放松了哪个约束——GPU 显存容量、解码时的 HBM 带宽、加速器指令支持，还是每服务 Token 的成本。精度基础见 Section 9.4 和 Section 9.4.2。

量化降低了模型权重和激活值的数值精度，使内存占用减少 2–4 倍，同时提高了解码吞吐量，解码是 memory-bandwidth limited（受内存带宽限制）而非 compute limited（受计算限制）。服务决策在于缩减哪个量：用于适配的常驻权重、每解码步骤移动的字节数（带宽）、用于预填充吞吐量的激活值，还是目标硬件支持的精度路径。大规模服务还带来了独特挑战：模型必须在无训练数据访问的情况下训练后量化，质量必须在多样化输入中保持，硬件部署目标从数据中心 GPU 到边缘加速器各不相同。因此，生产推理需要一个决策模型，而非方法清单。Table 10.50 中的决策模型将方法选择与实际绑定系统的服务约束联系起来。

| Binding serving constraint | Representation change | Method family | Risk to test before rollout |

| --- | --- | --- | --- |

| Model does not fit in memory | Quantize weights only | GPTQ, AWQ | Calibration mismatch and quality regression |

| Decode is bandwidth-bound | Reduce bytes read per token | W4A16 weight-only paths | Kernel support and KV-cache headroom |

| Prefill is compute-bound | Quantize weights and activations | SmoothQuant W8A8 | Activation outliers and INT8 hardware path |

| Outliers block low precision | Change the coordinate basis before quantization | Rotation-based methods | Transform overhead and limited runtime path |

表 10.50：服务量化决策模型

量化方法仅当它们放宽了实际约束服务系统的资源时才有用。方法族源于瓶颈：适配、带宽、预填充算力或异常值鲁棒性。

LLM 专属量化挑战

大语言模型带来了与视觉或推荐模型截然不同的独特量化挑战。异常激活问题的发生是因为某些注意力头产生的激活幅度比典型值大几个数量级。朴素量化会裁剪这些异常值，导致显著的质量下降。

考虑一个大语言模型层，其中大多数激活值适中，但特定通道产生大得多的异常值（Xiao et al. 2023）。使用范围为 [-127, 127] 的对称 INT8 量化不存在完美的缩放因子选择：宽范围保留异常值但将典型值压缩进过少的区间，而窄范围保留典型值的分辨率却裁剪异常值并引入巨大误差。

异常值分布解释了以下专业方法的差异：每一种都保护服务契约的不同部分。

GPTQ：逐层权重量化

当部署需要训练后进行 4 位压缩且能承担校准数据时，GPTQ（Frantar et al. 2023）是仅量化权重的选择。其服务价值在于模型体积变小，无需完整的重新训练运行。风险在于舍入一个权重会以一种后续权重必须吸收的方式改变层输出。GPTQ 通过使用校准激活来估计哪些权重误差最重要[¹⁶⁸]，然后在舍入每一列时补偿剩余的未量化权重来应对该风险。

GPTQ 逐层处理模型，按列量化每个权重矩阵[¹⁶⁹]，并补偿仍未量化的列，使层输出的漂移尽可能小。服务后果是分两部分的部署时成本：一次针对 128–256 个具有代表性样本的校准遍历（必须匹配生产流量），以及一个逐层的二阶更新，使量化成为分钟到小时级的离线工作，而非一次性转换。两者均在部署前一次性支付，因此不影响服务延迟，但在推出前必须测试的失效模式是：校准集错误地代表了部署的流量组合。

表 10.51 总结了 GPTQ 在不同 Llama 模型规模上的性能：

| 模型 | 位宽 | 困惑度增加 | 内存减少 | 量化时间 |

| --- | --- | --- | --- | --- |

| Llama-7B | 4 | +0.3 | 4× | 15 分钟 |

| Llama-13B | 4 | +0.2 | 4× | 30 分钟 |

| Llama-70B | 4 | +0.15 | 4× | 3 小时 |

表 10.51：不同规模 Llama 上的 GPTQ 性能：随着模型规模扩大，量化质量保持得相当稳定：尽管目标均为 4 位，70B 模型的困惑度损失反而比 7B 模型小。内存减少均为 4×。量化时间随模型规模近线性扩展，主要由逐层二阶更新主导。

GPTQ 的优势包括无需重新训练即可快速量化、4 位权重质量损失极小以及广泛的硬件兼容性。其局限性包括需要校准数据、对校准集选择敏感，以及无法利用跨层信息的逐层处理。

AWQ：激活感知权重量化

AWQ（Lin et al. 2024）从激活侧切入同一个仅量化权重的服务目标。一次校准遍历测量每通道激活幅度，馈送幅度最大的那些高幅度通道的权重在量化前被放大（匹配的缩放因子折叠进下一层），从而让这些显著权重保留分辨率，而其余权重被激进地量化。其相对于 GPTQ 的服务优势在于，保护显著通道避免了逐列误差反馈遍历，因此校准更轻量且无需任何参考输出即可无数据进行；需测试的风险是显著通道缩放必须融合进部署图而无需单独的运行时算子，否则内存收益会被额外的内核抵消。

表 10.52 总结了 AWQ 与 GPTQ 在误差补偿、校准成本、质量、速度和硬件兼容性方面的对比。

| 方面 | GPTQ | AWQ |

| --- | --- | --- |

| 误差补偿 | 调整剩余权重 | 缩放显著通道 |

| 校准数据 | 128–256 样本 | 128 样本 |

| 质量 (4-bit) | 很好 | 优秀 |

| 速度 | 较快 | 稍慢 |

| 硬件兼容性 | 广泛 | 广泛 |

表 10.52：AWQ 对比 GPTQ：AWQ 缩放显著通道而非补偿残差误差，在校准速度略慢的情况下实现了更高的 4 位质量，并在硬件兼容性上与 GPTQ 持平。

在此处的代表性设置中，AWQ 在相同位宽下可比 GPTQ 实现低 0.5-1 个百分点的困惑度退化，使其成为质量预算紧张时的合理选择。

SmoothQuant：迁移量化难度

SmoothQuant（Xiao et al. 2023）是 W8A8 部署的服务路径，适用于激活量化至关重要、特别是算力受限的预填充阶段。激活携带不可预测的异常值，会击败 INT8；权重则不会。SmoothQuant 将激活除以逐通道缩放因子，并将相应权重乘以相同缩放因子，这是一个代数恒等变换，在保持层输出不变的同时，将难以量化的范围从激活移至更宽容的权重中。其服务后果是缩放因子折叠进现有权重和一个廉价的激活除法中，因此平滑后的模型以近乎零的运行时开销在标准 INT8 路径上运行；需测试的风险是迁移仅转移了异常值而非消除它们，因此激活极值与生产环境不同的校准集仍可能导致裁剪。

在 W8A8 部署方案中，SmoothQuant 实现了权重和激活均量化为 INT8。表 10.53 展示了 W8A8 与 FP16 基线及仅权重量化的对比：

| 配置 | 内存 | 预填充加速 | 解码加速 | 质量 |

| --- | --- | --- | --- | --- |

| FP16 (基线) | 1× | 1× | 1× | 基线 |

| W8A16 (仅权重) | 2× | 1.3× | 1.8× | <0.5% 损失 |

| W8A8 (SmoothQuant) | 2× | 1.8–2× | 1.3–1.5× | <1% 损失 |

表 10.53：W8A8 SmoothQuant 对比仅权重量化：W8A8 将权重和激活均量化为 INT8，内存节省翻倍并释放了算力受限的预填充加速，但其解码加速低于 W8A16，因为解码受内存带宽限制，而 W8A8 更小的权重已被更简单的仅权重方案捕获。

关键区别在于 W8A8 为算力受限的预填充（大批量处理初始提示词）提供近 2× 加速，但为内存受限的解码（逐个生成 Token）仅提供 1.3–1.5× 加速。LLM 服务通常以解码为主，因此 W8A8 的实际吞吐提升往往是 1.3–1.7×，而非 INT8 Tensor Core 理论 2× 算力吞吐。

基于旋转的量化

传统量化 vs. 基于旋转的方法

传统量化方法（GPTQ、AWQ、SmoothQuant）通过补偿或迁移来处理异常值。基于旋转的量化（Ashkboos et al. 2024）是当激活异常值阻碍更低精度时的激进路径：它在数学上转换权重和激活空间，彻底消除异常值。

关键的认识在于异常值是坐标基表示的副产物。旋转到不同的基会将极端值均匀分布，使所有数值都更适合量化。

QuaRot（带旋转的量化）

QuaRot 使用正交的 Hadamard 变换¹⁷⁰ 对权重和激活空间进行旋转，使任何单个异常值均匀分布到所有维度上，从而得到一个没有主导值的分布，统一低位宽量化能够捕获。由于旋转是正交的，层的输出保持不变，且该变换无需校准数据，这正是 QuaRot 能在补偿和迁移方法止步于更高精度时实现 W4A4 的原因。其代价是其他方法不需要的运行时开销：旋转在每一次前向传播中内联执行，约增加 3% 的开销。因此在推理前的测试是，W4A4 在内存和带宽上的收益是否足以抵消目标硬件上这笔固定的“税”。

与 SmoothQuant 的比较

Table 10.54 对比了 QuaRot 基于旋转的方法与 SmoothQuant 的迁移方法。两者的权衡在于校准成本和运行时开销：SmoothQuant 在校准后没有运行时开销但止步于 W8A8，而 QuaRot 通过支付内联旋转成本达到 W4A4。

| 方面 | SmoothQuant | QuaRot |

| --- | --- | --- |

| 校准数据 | 需要 | 不需要（免数据） |

| 最低精度 | W8A8 | W4A4 |

| 运行时开销 | ~0% | ~3%（Hadamard 变换） |

| 异常值处理 | 迁移 | 消除 |

Table 10.54: QuaRot vs. SmoothQuant：SmoothQuant 将异常值从激活迁移到权重，运行时无额外开销但需要校准数据且止步于 W8A8。QuaRot 通过 Hadamard 旋转消除异常值，免校准、实现 W4A4，并承担约 3% 的运行时内联变换成本。

Perplexity 对比

Table 10.55 对比了不同量化方法和精度在 LLaMA-2-70B 上的困惑度：

| 方法 | 精度 | LLaMA-2-70B 困惑度 | 相对基线 |

| --- | --- | --- | --- |

| FP16 | W16A16 | 3.12 | 基线 |

| SmoothQuant | W8A8 | 3.18 | +0.06 |

| GPTQ | W4A16 | 3.24 | +0.12 |

| QuaRot | W4A4 | 3.31 | +0.19 |

Table 10.55: LLaMA-2-70B 的量化困惑度：四种量化方法在 70B 模型上的困惑度下降情况。QuaRot 的 W4A4 与 FP16 基线相差不到 0.2，同时实现约 4 倍的张量内存缩减，证明基于旋转的方法使 4 位激活量化在生产推理中可行。

QuaRot 实现了 4 位权重和 4 位激活，质量可与仅 4 位权重的 GPTQ 相竞争，使量化权重和激活相较于 FP16 可实现约 4 倍的内存缩减。SpinQuant 通过在短暂微调阶段学习最优旋转矩阵进一步提升质量，但会增加训练算力成本。旋转方法因此扩展了低精度的适用范围，但是否值得取决于部署硬件对目标精度的支持情况。

硬件‑部署协同设计

量化方法只有在部署硬件加速所选精度时才有价值。不同加速器支持的格式如 BF16、INT8、INT4 各有不同的性能倍数。

NVIDIA Tensor Core 精度支持

Table 10.56 汇总了 NVIDIA Ampere 与 Hopper 上 Tensor Core 对不同精度的支持：

| 格式 | Ampere (A100) | Hopper (H100) | 相对 FP16 的加速 |

| --- | --- | --- | --- |

| FP16 | 支持 | 支持 | 1x |

| BF16 | 支持 | 支持 | 1x |

| INT8 | 支持 | 支持 | 2x |

| FP8 (E4M3) | 不支持 | 支持 | 2x |

| INT4 | 需软件/CUTLASS 或框架实现 | 需软件/框架实现（H100）；原生 FP4 为 Blackwell 特性 | 取决于工作负载 |

Table 10.56: Tensor Core 精度支持与加速：NVIDIA Ampere 与 Hopper Tensor Core 的原生精度支持情况。INT8 与 FP8 的 2 倍加速反映了这些原生路径的吞吐量翻倍；INT4 在 Ampere 与 Hopper 上仍依赖框架实现，而原生 FP4 首次出现在 Blackwell。

内存带宽与解码吞吐

内存带宽主导自回归 LLM 的解码吞吐，因为每个 token 都需要读取整个模型：

Decode throughput ∝ Memory bandwidth / Model size in bytes

在理想的内存受限情形下，将 FP16 权重压缩到 4 位可将权重流量降低 4 倍，但实际解码吞吐还受到 kernel 支持、反量化开销、KV‑cache 精度、批次形状以及 HBM 带宽是否真正成为瓶颈等因素影响。4 位推理的价值在于能够提升模型驻留或批次容量，实际吞吐提升需在目标服务工作负载上验证。

部署配置

Table 10.57 表明配置取决于两点：目标硬件支持的精度路径以及部署目标是内存驻留还是吞吐。内存受限的消费级 GPU 采用 W4A16，INT8 加速器采用 W8A8 以获取 Tensor Core 吞吐，而 H100 系列则走原生 FP8。

| 量化方案 | 最适用场景 | 框架支持 |

| --- | --- | --- |

| W4A16 (GPTQ/AWQ) | 消费级 GPU、内存受限 | vLLM、TensorRT-LLM、llama.cpp |

| W8A8 (SmoothQuant) | INT8 加速器、高吞吐 | TensorRT-LLM、ONNX Runtime |

| FP8 | H100/H200 部署 | TensorRT-LLM |

| W4A4 | 研究、极端压缩 | 支持有限 |

Table 10.57: 量化部署配置：从量化方案到部署目标及对应框架的映射。W4A16 常用于消费级和内存受限场景；W8A8 解锁 INT8 Tensor Core 吞吐；FP8 为 H100/H200 系列的原生低精度路径；W4A4 为激进压缩目标，框架支持相对较少。

量化服务的运行时契约

生产服务框架至关重要，因为只有运行时保持理论节省，量化权重才能真正降低成本。该契约是框架无关的：服务堆栈必须加载量化产物而不进行静默反量化，选择执行预期低精度路径的 kernel，围绕更小的权重占用规划 KV‑cache 内存，并提供足够的遥测以检测质量或延迟回归。Table 10.58 列出了这些职责以及在运行时未满足时如何悄然泄漏理论收益，正因如此四项共同构成了框架在量化成为生产服务胜利前必须满足的最低契约。

| 运行时职责 | 关键原因 |

| --- | --- |

| 保持量化产物 | 静默反量化会恢复 FP16 的内存和带宽成本。 |

| 选择兼容的低精度 kernel | 不受支持的算子会回退到更慢或更高精度的执行。 |

| 围绕权重和 KV‑cache 规划内存 | 只有释放的内存被用于增加批次容量时，容量提升才有意义。 |

Table 10.58: 量化服务运行时契约：服务框架必须满足的四项职责，以在生产环境中实现量化节省。

| 同时验证质量与延迟 || 满足延迟但未达任务质量要求的低比特路径不属于服务收益。 |

表 10.58：量化服务运行时契约：尽管特定框架的 API 各异，但每条生产路径都必须保留表达形式、选择受支持的内核、规划内存，并在部署的流量组合下验证质量。

量化模型结合 PagedAttention 以实现最大内存效率：

\[ \text{最大批次} = \frac{\text{GPU 显存} - \text{量化权重}}{\text{每序列 KV 缓存}} \]

具有 4-bit 权重的 70B 模型约需 35 GB，在 80 GB A100 上留出 45 GB 给 KV 缓存。若 MHA 基线下 FP16 KV 缓存每 1K-token 序列约占 2.6 GB，则在其他运行时开销之前可支持约 17 个并发 1K-token 序列。若采用 FP16 权重，同一 70B 模型根本无法装入单张 A100，因此权重仅量化同时改变了可行性和批次容量。

量化选择指南

最终选择将方法与约束瓶颈相匹配。当量化开销占主导时，延迟敏感型路径应优选 FP16 或 BF16；而吞吐导向型路径更可能从量化中获益。硬件支持缩小了可行选择范围：H100 和 H200 部署可考虑 FP8，因为硬件提供原生支持且质量损失极小；A100 和 A10G 部署通常根据工作负载在 W8A8 和 W4A16 间抉择；消费级 GPU 常被迫选择 W4A16 仅为装下模型。质量预算随后设定了精度下限。若可接受 0.5% 以内劣化，AWQ 4-bit 是合理目标；若可接受 1% 以内劣化，GPTQ 4-bit 或 SmoothQuant W8A8 可能可行；若零劣化为要求，FP16 或 BF16 仍是最稳妥之选。约束资源做最终区分：计算受限的 prefill 倾向 W8A8，因其可提供 2× 加速；内存受限的 decode 倾向 W4A16，因其可提供 4× 有效带宽提升。

表 10.59 展示了量化如何重塑每百万 token 服务成本：

| 配置 || 每百万 token 成本（估算） |

| --- | --- | --- |

| 8× A100 上 FP16 || $2.40 |

| 4× A100 上 AWQ 4-bit || $1.20 |

| 2× A100 上 AWQ 4-bit || $0.60 |

表 10.59：量化对服务成本的影响：三种配置下每百万 token 估算成本。通过 4-bit 量化将 GPU 数量减半，成本减半；再减半则使每百万 token 成本降至 FP16 基线的四分之一。成本节省几乎完全源于 GPU 数量减少，而非单 GPU 吞吐提升。

量化可在保持可接受质量的前提下将服务成本降低 2–4×，使其成为高性价比 LLM 部署的重要杠杆。

这些服务优化涵盖连续批处理、PagedAttention、全局负载均衡与极致量化。后续案例研究将展示全球规模生产系统如何组合这些技术以满足特定成本与延迟目标。

案例研究

生产规模服务系统迫使本章技术面对真实负载方差、延迟预算与运维约束。各案例受制于不同约束：嵌入规模、变长生成、级联成本或多模态时效性。示例展示了系统如何结合批处理、分片、缓存、路由与量化以达成特定成本与延迟目标。前文开发的 Orca 与 vLLM 机制提供了 LLM 服务原语；以下案例将视野拓展至推荐服务、全局请求路由、排序级联与多模态时效性。

Meta 推荐服务

Meta 的推荐基础设施受制于嵌入规模而非稠密前向计算。它为 Facebook、Instagram、WhatsApp 和 Messenger 的信息流、广告与内容排序提供预测，是全球最大的生产推理部署之一。

规模数据说明了为何嵌入局部性主导设计：

• 请求量：每日数十亿次

• 延迟目标：P99 < 10 ms

• 模型多样性：数百个模型变体

• 特征基数：数万亿唯一实体

服务栈将稀疏查找与稠密排序分离：

用户请求 → 特征收集 → 嵌入查找 → 模型推理 → 响应
                    │                     │                  │
                    ▼                     ▼                  ▼
             特征存储        嵌入服务器      GPU 推理
             (CPU, DRAM)    (CPU + SSD, 1000s)   (GPU, 100s)

在 Meta 架构中，约束设计的瓶颈是嵌入规模：表总量超 100 TB，需 1,000+ 分片。Meta 采用混合分片策略：

• 热嵌入（Top 1%）：跨所有推理服务器内存复制

• 温嵌入（次 10%）：列分片，8 路并行

• 冷嵌入（其余 89%）：行分片 + 一致性哈希，SSD 支持

混合分片通过批处理与局部性优化，将嵌入查找延迟从 50 ms（朴素实现）降至 2 ms。

Meta 不批处理整个请求，而是在特征层面批处理。每次推理请求触发 5,000+ 次嵌入查找，但这些查找在 1 ms 窗口内跨请求批处理。这在嵌入服务器上实现了 90%+ 内存带宽利用率。

由此产生的 GPU-CPU 混合架构在 GPU 上运行稠密模型计算（排序塔），而在拥有大内存与 SSD 存储的 CPU 服务器上运行稀疏嵌入查找。表 10.60 将各组件置于其瓶颈匹配的硬件上：内存受限的稀疏查找落在 SSD 支持的 CPU 服务器上，低算术强度的特征处理留在 CPU，仅计算稠密的排序前向传递使用 GPU。

| 组件 || 硬件 || 延迟 || 吞吐 |

| --- | --- | --- | --- |

| 嵌入查找 || CPU + SSD || 2 ms || 50M lookups/s |

| 特征处理 || CPU || 1 ms || 10M ops/s |

| 稠密排序 || GPU || 1.5 ms || 100K infs/s |

表 10.60：Meta DLRM 混合 CPU/GPU 架构：Meta 推荐服务栈的硬件-负载映射。CPU + SSD 处理带宽受限的稀疏路径；CPU 处理低算术强度的特征处理；GPU 处理计算稠密的排序前向传递。三个延迟预算求和约 5 ms，远在典型推荐 SLO 之内。

服务启示在于：推荐延迟常由嵌入查找而非稠密模型推理主导。特征并行批处理与混合 CPU-GPU 架构将硬件与负载的稀疏半与稠密半相匹配，这与 GPT 式 API 服务（请求方差与自回归状态占主导）形成对比。

OpenAI API 基础设施

OpenAI 式 API 基础设施受制于请求方差：短提示、长上下文请求与不同模型规模共享容量，而用户期望可预测的 TTFT。该基础设施为大规模开发者与应用工作负载服务 GPT 级模型，同时跨多样工作负载维持服务质量。

规模数据说明了为何连续批处理与准入控制占主导：

• 请求量：每小时数百万次

• 延迟目标：首 token 时间 (TTFT) < 2s，吞吐随模型变化

• 模型规模：数十亿至数千亿参数

• 上下文长度：高达 128K tokens

服务栈分离了路由、调度、缓存管理与分片组：

API 网关 → 限流 → 请求路由 → 模型集群 → 响应流式传输

│

▼

┌─────────────┐

│ 模型池 │

│ ┌─────────┐ │

│ │ Large │ │

│ │ 8×H100 │ │

│ └─────────┘ │

│ ┌─────────┐ │

│ │ Smaller │ │

│ │ 4×A100 │ │

│ └─────────┘ │

└─────────────┘

主要的设计决策是防止长提示阻塞其他所有人的解码服务。

Orca 风格的长上下文服务设计采用连续批处理，尽管输出长度各异，仍能维持高 GPU 利用率。分块预填充通过将长提示分块处理并与正在进行的生成交织，从而限制了解码延迟。表 10.61 对比了三种方法：

| 批处理策略 | GPU 利用率 | 128K 提示行为 |

| --- | --- | --- |

| 静态批处理 | 45% | 30s TTFT；解码被阻塞 |

| 连续批处理 | 75% | 30s TTFT；解码仍被预填充阻塞 |

| 连续 + 分块 | 85% | 30s TTFT；解码停顿限制在 ~3s 内 |

表 10.61：批处理策略对比：三种批处理方法及其带来的 GPU 利用率和 128K 提示行为。静态批处理让最长请求导致整个批次空闲；连续批处理将利用率提升至 75%，但解码仍会在长预填充后停顿；分块预填充将预填充分块与解码交织，在达到 85% 利用率的同时，将解码停顿限制在几秒内。

大型 GPT 类模型通常需要 8 路或更高的张量并行度，以满足显存容量和延迟要求：

• 每大模型分片组 8× H100

• NVLink 用于节点内通信

• 一致性哈希实现会话亲和性（KV cache reuse）

OpenAI 在多个层级实施限流，以防止“吵闹邻居”问题：

• 每 API Key 请求速率限制

• 每 API Key 每分钟 Token 限制

• 组织级容量配额

• 全局模型容量限制

高峰期需求期间，OpenAI 根据队列深度在模型间转移容量：

if large_model_queue_depth > threshold:
    # 将部分较小模型容量迁移至大模型
    reallocate_cluster_capacity(from="smaller-model", to="large-model", fraction=0.2)

服务启示在于：LLM API 由方差控制管辖——连续批处理、前缀缓存和多级限流，防止长提示、重复对话上下文和流量尖峰将某一用户的请求转化为所有人的延迟。搜索排序面临同一问题的不同形态：许多更廉价的模型必须在一个严格的截止时间内协同工作。

Google 搜索排序

Google 搜索受限于级联成本：每个查询在一个端到端延迟预算内协调许多较小模型，而非服务单一大模型。该集成结合了用于查询理解、文档相关性和结果排序的专用模型。

规模数据说明了为何级联是强制性的：

• 请求量：每日数十亿次搜索

• 延迟目标：<200 ms 端到端

• 模型数量：每查询数十个模型

• 结果处理：每查询数千个文档

为在评估数千文档的同时满足该延迟预算，系统采用排序级联（图 10.26），通过日益昂贵的模型逐步缩小候选集。

图 10.26：排序级联架构：为优化延迟和成本，搜索和推荐系统使用日益复杂的模型级联。早期阶段（检索）使用快速、廉价的启发式方法将数百万候选过滤至数千。后期阶段仅在最有希望的候选上使用昂贵、高精度的模型。

核心设计决策是渐进式细化：Google 使用排序级联，而非在所有候选上运行单一昂贵模型。表 10.62 展示了级联所做的权衡：每个阶段在更小的候选集上花费更大的延迟预算，因此昂贵的 L3 集成之所以负担得起，仅因为 L0 到 L2 已将候选削减了四个数量级。

| 阶段 | 模型复杂度 | 候选数 | 延迟预算 |

| --- | --- | --- | --- |

| L0 (检索) | 嵌入查找 | 1,000,000 → 10,000 | 10 ms |

| L1 (首遍) | 线性模型 | 10,000 → 1,000 | 20 ms |

| L2 (二遍) | 小型 Transformer | 1,000 → 100 | 50 ms |

| L3 (最终排序) | 大型集成 | 100 → 10 | 100 ms |

表 10.62：Google 排序级联：四阶段级联将百万候选过滤至十个，同时按深度成比例分配计算。各阶段在更少候选上使用更昂贵模型，使总成本由廉价的早期阶段主导，而非昂贵的最终集成。

与在所有候选上运行 L3 相比，级联减少了最终 L3 评估 10,000 倍。在此简化的请求预算模型下，L3 阶段每候选耗时 1 ms。若对完整的百万候选集应用 L3，将消耗约 1000 s 的模型算力，而级联预算总和仅 180 ms。由此带来的模型算力降低约为 5,600 倍。

鉴于紧张的延迟预算，Google 对模型集成采用推测执行。此处推测是指在截止时间前并行启动候选排序工作，而非用于 LLM 解码的草稿 Token 验证：

# 而非顺序执行：
#   q1 = model1(query)
#   q2 = model2(query)
#   q3 = model3(query, q1, q2)

# 推测并行：
async_q1 = async model1(query)
async_q2 = async model2(query)
async_q3 = async model3(query, predicted_q1, predicted_q2)

# 若实际结果及时到达则使用，否则使用推测结果

搜索排序部署可在针对 Transformer 推理优化的张量处理单元 (TPU)¹⁷¹ 上运行排序模型。TPU Pod 提供：

• 用于高效 AllReduce 的二维网格拓扑

• 用于注意力操作的高内存带宽

• 用于服务效率的定制量化

每个子请求携带截止时间，工作进程按截止时间临近度优先处理：

工作队列：[Doc1: 剩余 50 ms] [Doc2: 剩余 30 ms] [Doc3: 剩余 80 ms]
                                          ↑ 优先处理

若将错过截止时间：
  返回缓存/默认结果而非超时

服务启示在于：排序级联通过仅在不断缩小的候选集上使用昂贵模型来降低成本，而截止时间传播和优先级调度将集成控制在严格的延迟预算内。当工作负载与加速器匹配时，定制硬件可提升可预测性，但下一个案例增加了仅靠硬件无法解决的新鲜度约束。

TikTok 多模态推荐

TikTok 推荐系统受限于严格排序 SLO 下的新鲜度：视频理解昂贵，新内容持续到达，用户建模保持在线。它将视频理解（视觉）与用户建模（推荐）相结合，用于个性化内容排序，造成了一种多模态推理挑战，不同模型类型必须协同工作。

规模数据说明了为何在线/离线分离很重要：

• 请求量：每秒数百万次视频排序

• 延迟目标：<50 ms P99

• 内容量：每日数百万新视频

• 模态：视频、音频、文本、用户信号

服务栈分离了内容路径和用户路径：

用户请求 → 用户嵌入 → 候选视频 → 视频理解 → 排序

│ │ │

▼ ▼ ▼

用户塔 视频缓存 视觉模型

(Transformer) (预计算) (按需)

TikTok 的架构通过带缓存的双塔架构，将用户理解（在线）与内容理解（离线）分离开来¹⁷²。表 10.63 对比了在线塔和离线塔的更新节奏：

| 塔 | 更新频率 | 延迟 | 算力 |

| --- | --- | --- | --- |

| 用户塔 | 实时 | 5 ms | GPU（在线） |

| 视频塔 | 每小时 | N/A | GPU（批处理） |

表 10.63：TikTok 双塔更新节奏：用户塔和视频塔以不同的节奏运行：用户特征秒秒变化，必须在线运行推理；视频特征变化慢得多，以每小时批次预计算。这种非对称调度是将视觉推理从几乎所有请求的关键路径中移除的设计。

视频嵌入被预计算并缓存，消除了大多数请求关键路径上的视觉推理。仅新视频（上传一小时内）需要在线视觉推理。

与 Meta 一样，TikTok 使用 CPU 进行嵌入操作，使用 GPU 进行稠密模型计算：

用户特征 → CPU 预处理 (1 ms)
         → 嵌入查找 (2 ms, CPU+DRAM)
         → 稠密排序 (10 ms, GPU)
         → 响应格式化 (1 ms)

新视频内容按不同优先级处理，如表 10.64 所示：

| 优先级 | SLA | 用例 |

| --- | --- | --- |

| 关键 | 5 分钟 | 拥有大量粉丝的创作者 |

| 标准 | 30 分钟 | 普通上传 |

| 后台 | 2 小时 | 批量/导入内容 |

表 10.64：TikTok 视频摄入优先级层级：视频摄入的三层 SLA。高粉丝数创作者获得五分钟 SLA，以最大化其受众的内容新鲜度；标准上传获得 30 分钟；批量导入获得两小时的缓冲期，以便系统在空闲时段吸收它们。

该优先级方案确保热门创作者的内容快速触达推荐，同时管理计算成本。

TikTok 通过后期融合结合多种理解模态，即在排序末端附近融合独立计算的模态嵌入或分数，而非在所有原始模态上运行单一联合模型：

视频嵌入 (512d) ─┐
音频嵌入 (256d) ─┼─ 拼接 → 融合 MLP → 最终嵌入 (256d)
文本嵌入 (256d)  ─┘

后期融合允许独立更新每个模态的模型，而无需重新训练整个系统。

服务端的启示是，新鲜度要求将在线和离线工作分离。双塔架构使得激进缓存成为可能，因为物品嵌入可以异步刷新，而基于优先级的处理将最新鲜的计算资源用在用户影响最大的地方。

横向观察

跨越这些案例，通用模式是专业化而非通用服务栈。系统将嵌入与检索、排序与生成分离，使用混合 CPU-GPU 架构以匹配硬件与工作负载特性，在接受陈旧性的前提下进行多级缓存，逐步细化候选集以避免在不可能的项目上进行昂贵工作，并传播截止时间，使质量/延迟权衡在压力下保持显性。表 10.65 标识了每个系统的主要技术和关键创新。这四个系统截然不同，正是因为各自专门针对自己的工作负载；这种专业化是共享的模式，而非矛盾。

| 系统 | 主要技术 | 关键创新 |

| --- | --- | --- |

| Meta | 嵌入分片 | 特征并行批处理 |

| OpenAI | 连续批处理 | 分块预填充 |

| Google | 排级联 | 推测执行 |

| TikTok | 双塔缓存 | 多模态融合 |

表 10.65：案例研究总结：每个系统都在匹配其工作负载特性的核心技术上进行创新。

案例研究揭示了大规模服务 ML 所需的深度定制工程。试图复制这些架构的工程师往往会成为不适用于 GPU 绑定工作负载的常规智慧的受害者，这引出了该领域最常见的谬误和陷阱。

谬误与陷阱

一个 DevOps 团队将其标准 Web 服务器负载均衡规则应用于新的 GPU 推理节点集群，结果尾部延迟爆炸，因为他们忽略了自回归 Token 生成的极端方差。大规模推理打破了传统微服务的规则，为从标准 Web 开发转型到机器学习系统的工程师制造了危险的谬误。

谬误：大规模推理等同于 LLM 服务。

这种由以 LLM 为中心的论述强化的误解，导致过度关注 LLM 特定技术，而忽视了更广泛的推理领域。在大型消费平台上，推荐系统可能构成 AI 推理周期或容量压力的大头，视觉、语言、欺诈、广告及其他模型构成其余部分（Gupta 等人 2020；Hazelwood 等人 2018）。一个只理解连续批处理和 KV 缓存管理的从业者，无法应对主导高吞吐推荐推理的特征并行批处理和嵌入分片。技术选择必须匹配实际工作负载。

陷阱：将训练基础设施用于生产服务。

训练和服务有不同的需求。训练优化的是数小时或数天的聚合吞吐量；服务优化的是严格 SLO 下的单请求延迟。训练容忍数千的批大小；服务通常需要个位数的批大小。训练接受基于检查点的恢复；服务要求无用户影响的优雅故障转移。将训练集群部署用于服务的团队，往往会发现不可接受的延迟方差、糟糕的资源利用率以及难以满足 SLO。具有适当批处理、负载均衡和自动扩缩容的专用服务基础设施至关重要。

谬误：连续批处理解决了全部 LLM 服务问题。

连续批处理极大地提高了 LLM 服务的 GPU 利用率，但它只解决了问题的一个维度。对于长上下文，预填充仍是瓶颈，因为无论后续解码迭代如何批处理，二次注意力计算都无法避免。正如第 10.4 节所述，限制批大小的往往是 KV 缓存内存而非计算。分片模型组件间的网络带宽可能主导大模型的延迟。连续批处理是高效 LLM 服务的必要非充分条件。

陷阱：按平均吞吐量规划机群规模。

重要误区与陷阱

排队论表明，为平均负载配置资源的系统会在流量峰值期间违反 SLO。当平均利用率达到 80% 时，仅 25% 的流量激增就会将利用率推高至 100% 以上，导致队列无限制增长。正如 Section 10.8 所述，冷启动问题加剧了这一点：等到新产能可用时（对于 GPU 实例可能需要数分钟），SLO 违规已经发生。容量规划必须考虑峰值负载加上冗余余量，而非平均负载。

Fallacy：Load balancing does not matter much for inference

简单的负载均衡策略（如轮询）看似足够，直到进行定量分析。正如 Section 10.6 所示，随机分配在 R 台服务器上产生的最大队列长度为 𝒪(log R / log log R)。Power-of-two-choices 将其降低至 𝒪(log log R)，这是指数级的改进。对于拥有 1000 台服务器的集群，这将最大队列从约 4-5 个请求降低至约 2 个请求。在决定 SLO 合规性的尾部延迟上，这种差异非常显著。负载均衡算法的选择对系统性能有一阶影响。

Pitfall：Ignoring the serving tax

分布式推理引入了单机服务中不存在的开销：网络往返、序列化、负载均衡器决策以及分片模型的协调。这种“服务税”往往消耗 10%–30% 的延迟预算。一个团队可能在单张 GPU 上实现了 70 ms 的模型推理延迟，却惊讶地发现生产环境中的端到端延迟因这些开销达到了 100 ms。延迟预算必须显式地考虑分布式开销，而不仅仅是计算时间。

Fallacy：More GPU memory always means larger batch size and higher throughput

更大的 GPU 显存仅对吞吐量受容量限制的模型才能启用更大批次。LLM 解码的约束瓶颈是内存带宽，而非容量：一旦 HBM 带宽饱和，增加显存并不会提升每秒 Token 数。瓶颈层级揭示了这一错误。

虽然更大的 GPU 显存允许适合内存的模型使用更大批次，但瓶颈往往在显存耗尽前就已发生转移。内存带宽限制带宽受限操作（LLM 解码）的吞吐量。计算限制计算受限操作（Prefill、视觉推理）的吞吐量。在搭载 80 GB 显存的 H100 上运行带宽受限的解码工作负载，最终会在 HBM3 带宽（3.35 TB/s）饱和时达到平台期；仅增加显存一旦达到该点便无法提升 Token 吞吐量。理解工作负载是计算受限、内存带宽受限还是容量受限，能指导合理的资源分配。

Pitfall：Neglecting multi-tenancy isolation until production

在开发和预发布环境中，单租户部署效果良好。在生产环境中，吵闹邻居会导致突发的、不可预测的性能下降，难以诊断和解决。某租户流量暴增至正常水平的 5 倍，会降低共享基础设施上所有其他租户的延迟。正如 Section 10.7 所强调的，资源配额、优先级调度和舱壁隔离必须从一开始就设计进系统，而非在生产事故后才补救。

规避这些陷阱，能使服务基础设施在面对流量波动时保持弹性，在固定 SLO 下维持成本效益，并在各租户间提供一致的响应性。

Summary

大规模推理是将训练好的模型和分布式基础设施转化为低延迟全球预测的服务层。吞吐量、尾部延迟、内存驻留和租户隔离在此成为用户可见的系统行为。

服务层级将优化问题从请求级的批处理和缓存，组织到副本级的 GPU 显存管理、服务级的负载均衡，再到平台级的多租户。从训练到推理的转变改变了核心指标：聚合吞吐量仍然重要，但 P99 延迟决定了服务是否好用，以及下游系统能否依赖它。

不同模型架构需要不同的批处理策略。视觉模型受益于静态或动态批处理，因为输入形状可预测。推荐系统对稀疏特征进行批处理和分片，因为 Embedding 查找占主导。LLM 需要连续批处理和 KV Cache 管理，因为每个活跃请求都携带私有序列状态。张量并行和专家并行等模型分片技术，仅当 Chapter 6 中讨论的网络结构能维持同步开销时，才能为超大模型降低延迟。

理解大规模推理至关重要，因为在生产环境中，服务成本而非训练成本可能主导机器学习的总体经济账。一个超大模型可能需要数千万美元和数月时间来训练，但这笔投资只需摊销一次。而在其运营生命周期内为数百万用户提供服务，当请求量大且模型服役数年时，服务支出可能以数量级超过原始训练支出。这种不对称性意味着，本章讨论的每一项优化——从连续批处理到 PagedAttention 再到 Power-of-two-choices 负载均衡——都能直接转化为随模型部署周期复合增长的持续成本节约。

内化 Prefill/Decode 拆分、理解为何浪费的 KV Cache 显存会扼杀吞吐量、并能推理批处理策略与尾部延迟的交互作用的工程师，能在固定 SLO 下使服务在经济上可行。选择连续批处理而非静态批处理可在输出长度多变时提高利用率；实施 PagedAttention 可回收因 KV Cache 碎片化而损失的显存；在工作负载组合合理时将 Prefill 与 Decode 解耦，可通过独立硬件池降低单 Token 成本。综上，本章呈现的技术代表了能经济扩展的推理基础设施与服务账单增长快于有效需求的基础设施之间的差异。

• 服务成本永远复利：训练一次性付费，但推理 OpEx 随每个请求累积；对于高流量生产系统，其在模型生命周期内可主导总成本 100 倍以上。毫秒、内存碎片和利用率点是财务杠杆，而非局部优化。

• 尾部延迟支配架构：推理系统在 P99 SLO 约束下优化，因此批处理、分片、缓存和自动扩缩容必须在不消耗用户可见截止时间的前提下提高利用率。聚合吞吐量是必要但不充分的，因为一个慢请求可能击垮下游服务。

• Decode 将内存转化为容量：LLM Prefill 受计算限制，而自回归 Decode 逐 Token 重读权重并扩展私有 KV 状态。连续批处理、PagedAttention、前缀复用和 KV 压缩之所以重要，是因为它们将稀缺的 HBM 带宽和显存转化为可接纳的请求。

• 模型类别设定基元：视觉模型受益于可预测的静态或动态批处理，推荐系统受益于特征并行 Embedding 分片，LLM 受益于迭代级调度。车队调度器必须匹配工作负载形状，而非套用统一的批大小规则。

• 分布式总要付账单：张量并行、专家路由、全局负载均衡、多租户和故障转移，都通过增加通信和协调来换取容量或隔离。仅当该税收被显式纳入延迟、成本和可靠性预算内时，生产级服务才能行之有效。

决定推理系统成本的通常是服务 OpEx（运营支出），而非一次性的训练账单。前沿模型的训练运行仅需支付一次，而只要模型仍在生产环境中，服务就需为每个请求付费；因此，微小的利用率提升便能抵消巨大的训练开销。难点在于物理层面：自回归生成一次只产生一个 token，且每个解码步骤都要从内存中重读模型权重，因此限制吞吐率的往往是带宽而非算力。本章介绍的技术旨在该约束下提高利用率，而在服务规模下，每一节省的毫秒、内存页或空闲加速器时隙，都会在完整的请求流中累积收益。

此处构建的大规模推理架构基石——连续批处理、PagedAttention、模型分片与负载均衡——均假设使用数据中心级硬件：H100 GPU、NVLink 互联、TB 级 HBM。然而，许多应用要求推理更贴近用户：在智能手机、IoT 设备或本地网关上运行，那里的功耗预算以毫瓦计，内存以兆字节计，且连接间歇性中断。第 11 章将探讨当智能下沉到边缘、所有数据中心假设被颠覆时，服务原则将如何变化。

此处用于确保测验能在章节开始前正确插入。

• 与一次性训练效率相比，全生命周期服务经济性应如何重塑架构？

• 连续批处理与 KV 缓存策略如何在保持 p99 延迟的同时利用性能工程工具？

• 服务应在何时选择分片、解耦、量化或更小的模型，而非增加副本？

• 路由如何兼顾请求长度变异、状态亲和性与嘈杂邻居干扰？

边缘智能

目的

为何智能必须适应其运行环境，而非冻结在遥远的训练中？

在数据中心训练的模型，部署到用户设备时，会遭遇一个从未见过的世界。用户的词汇与训练数据不同。本地条件（光照、声学、使用模式）偏离了塑造模型参数的分布。随着用户行为演变而模型保持静态，这种鸿沟会随时间拉大。设备端学习之所以存在，是因为中心化训练无法预见每一种语境、为每位用户个性化，或适应持续的变化。它也存在于数据并不总能流动这一事实：隐私约束、带宽限制和延迟要求可能禁止将原始观测发送至远程服务器。放弃设备端学习，意味着接受部署模型逐渐过时、个性化需要牺牲隐私、断网运行意味着智能降级。设备端学习通过将学习过程带到数据所在之处、适应最关键之处，拒绝了这些妥协。边缘智能将适应转化为 C³ 问题：算力下沉至设备，通信从原始观测压缩为选择性更新，协调必须在数据中心从未见过的功耗与内存预算下运行。

• 通过分析数据流、隐私属性与运营权衡，对比中心化云训练、设备端学习与联邦学习

• 量化边缘设备训练相较于纯推理部署在内存、算力与能耗上的开销

• 通过对比内存占用、表达能力与收敛性，针对特定设备能力选择模型适配策略

• 应用数据高效技术（小样本学习、经验回放、对比学习），在不发生灾难性遗忘的前提下，从有限本地数据中学习

• 设计联邦学习系统，在管理异构数据、通信效率与慢节点的同时，聚合隐私保护更新

• 解释设备端学习所需的运营控制：设备感知部署、分布式验证、隐私保护监控、以及跨异构种群的回滚

边缘学习范式

设想一个语音助手，在云数据中心用数百万通用音频样本训练而成。部署后，它难以理解用户浓重的地方口音或特定的家庭词汇。若模型无法在设备本地自适应，便会永久冻结，且随着本地用法偏离训练分布而变得愈发无用。边缘智能将推理、适应与协作置于观测数据的设备上或附近，使模型能在功耗、内存、隐私与连接约束下响应本地语境。边缘学习范式将机器学习从中心化工厂模式转向去中心化、持续适应的网络。

数据中心 ML 系统假设环境可控：算力资源充沛、网络连接可靠、系统行为可预测。中心化推理是该假设最典型的体现，而边缘打破了它。

智能手机学习预测用户文本输入、智能家居设备适应家庭作息、自动驾驶汽车基于本地路况更新感知模型，这些场景无不表明传统中心化训练方法力有不逮。智能手机遇到的语言模式因人而异，全球训练数据未必覆盖。智能家居设备须适应季节变化与家庭动态，这些在不同家庭间差异巨大。自动驾驶汽车面对的本地路况、天气模式与交通行为，可能与其原始训练环境截然不同。

这些场景要求设备端学习，即模型在运行设备上直接训练与适应。¹⁷³ 其后果是根本性的转变：机器学习从中心化训练转向跨数百万异构设备的分布式学习，每个设备皆在独特约束与本地条件下运行。在舰队技术栈中，分布式学习将物理层推至热力学极限。

局部适配只能发生在已跨越推理门槛的硬件上，因为梯度更新的成本严格高于其赖以构建的前向传播。专用加速器设定了这条门槛：它们决定边缘设备是否拥有足够的延迟与能量裕度运行智能负载，从而决定任何本地训练是否可能。

在通用移动 CPU 与专用神经网络处理单元（NPU）上运行模型的差距，最好理解为“硅红利”而非边际加速。已发布的 NPU 性能随硅代际与负载而异，但以 MobileNet 级分类器为例，其代表性数据支撑了本章论点：专用 NPU 运行前向传播的速度比同模型在移动 CPU 上快约 20 倍，能效高约 60 倍。此处 CPU 基线按 MobileNetV2 低利用率（每次推理 1.711 ms）计算；NPU 数据为该类加速器的示意性目标，非实测剖面。

本地学习：架构张力与系统设计

对于系统设计而言，重要的是这些比率所代表的差异种类。专用硬件使模型变得可行，而不仅仅是更快：如此幅度的能量收益是在几分钟内耗尽电池的工作负载与能够在后台持续运行的工作负载之间的区别。在边缘设备上，CPU 用于协调，NPU 用于生存。当未达到 NPU 目标时回退到 CPU 不仅会带来性能损耗；它通常会通过快速电池耗尽和热限制导致应用不可用。

向本地学习的过渡在机器学习系统设计中引入了根本性的张力。虽然基于云的架构利用丰富的计算资源和受控的运行环境，但边缘设备必须在极其有限的资源范围内运行。内存以兆字节而非千兆字节来衡量；功率预算以毫瓦而非瓦来衡量；网络连接可能是间歇性的或完全不可用。当本地模型在安全关键循环中运行时，这些约束就成为生命安全工程问题。

这些约束贯穿于原型 C（联邦 MobileNet）（第 1.6.1.3 节），其中自治性要求在严格的资源限制下在设备上进行学习。原型 C 代表了这一光谱的极端端。在毫瓦级功率预算下运行，它无法承担将原始数据传输到云端的能量成本。因此，数据局部性是由功率墙施加的物理必要条件，而不仅仅是一个隐私特性。量化训练、稀疏更新和联邦协调是使原型 C 能够存在的生存策略。

在极端资源限制下实现有效学习所需的架构张力，需要将推断阶段的压缩技术与算法技术、设计模式和系统原则相结合。这一挑战超越了传统训练算法的优化：它要求重新思考整个机器学习管道，以适应传统计算假设失效的部署环境。

本地学习

本地学习 是指在不需要服务器连接的情况下，直接在已部署的硬件上对机器学习模型进行本地训练或适应。

1. 重要性

它能够实现超个性化，并在严格的资源限制下实现自主运行。在铁律之下，本地学习必须最小化每次更新所消耗的总能量，因为每一步梯度都依赖于有限的电池功率，并且与其他系统任务竞争可用的计算吞吐量（R[peak]）。

2. 区别

与仅执行固定模型的边缘推理不同，本地学习涉及局部优化循环（前向传播和反向传播），这需要显著更多的内存和计算资源。

3. 常见误区

一个常见的误解是认为本地学习需要从头开始训练。实际上，它几乎总是本地适应：即微调预训练基础模型的一小部分参数，以适应本地环境的特定数据分布。

其影响超越了技术优化，延伸到机器学习生命周期的每一个阶段。模型从可预测的版本模式转向持续的分歧和适应轨迹。性能评估从集中监控仪表板转向对异构用户群体的分布式评估。隐私保护成为核心架构需求，塑造系统设计决策，而不仅仅是事后合规问题。

动机与优势

机器学习系统传统上依赖于集中式训练管道。模型是在大型、精心策划的数据集和基于云的基础设施上开发和优化的（Dean et al. 2012）。训练完成后，这些模型会被部署到客户端设备用于推理，从而在训练和部署阶段之间形成明确的分离。虽然这种架构分离在许多用例中表现良好，但在应用中，当本地数据是动态的、私有的或高度个性化时，它会带来显著的限制。

本地学习通过使系统能够在设备上直接进行训练或适应，而无需依赖持续的云连接，来挑战这一既定模式。这一转变反映了应用需求和用户期望的变化，这些需求和期望要求具备响应性、个性化和保护隐私的¹⁷⁴ 机器学习系统。

本地学习在遇到计算瓶颈之前就先遇到了内存瓶颈。

考虑智能手机键盘根据用户独特的词汇和输入模式进行适应的场景。为了实现个性化预测，系统必须在本地观察到的文本输入上对紧凑型语言模型执行梯度更新。即使是最小的语言模型，一次梯度更新也需要 50 MB–100 MB 的内存用于激活和优化器状态。智能手机操作系统通常只为键盘等后台应用留出 200 MB–300 MB 的内存，具体预算因操作系统、设备代际和前台工作负载而异。这种刀刃般的余量凸显了本地学习的核心工程挑战：一次训练步骤可能消耗可用内存的 25%。系统必须在如此严苛的约束下实现有意义的个性化，以至于传统的训练方法在架构上变得不可行。这种量化现实推动了对专门技术的需求，使得在极端资源限制下成为可能。

有四个关键考虑因素促使从集中式转向去中心化学习（T. Li et al. 2020）：个性化、延迟和可用性、隐私以及基础设施效率。个性化是最具说服力的动机，因为部署的模型经常遇到与其训练环境不同的使用模式和数据分布。局部适应使模型能够根据用户特定的数据优化行为，捕捉语言偏好、生理基线、传感器特性或环境条件。这一能力在用户变异性高的应用中至关重要，因为单一的全局模型无法有效服务于所有用户。

延迟和可用性限制提供了对局部学习的额外证明。在边缘计算场景中，对集中式基础设施的连接可能不可靠、延迟或被故意限制以保存带宽或降低能源消耗。本地学习即使在完全离线或对延迟敏感的情况下也能实现模型的自主改进，在这种背景下，往返云端的更新在架构上是不可行的。

隐私考虑提供了第三个充分动机。许多应用涉及敏感或受监管的数据，包括生物测量、键入输入、位置轨迹或健康信息。本地学习可以通过在设备上保留原始数据并限制向中心化系统的传输来降低隐私暴露。这可以简化合规工程，但它本身并不能确保符合诸如《通用数据保护条例》（GDPR）¹⁷⁵、《健康保险流通与责任法案》（HIPAA）¹⁷⁶（美国卫生与公众服务部 2026）或特定地区的数据主权法律。

基础设施效率为分布式学习方法提供了经济动机。中心化训练管道需要大量的后端基础设施，以从潜在的数百万台设备中收集、存储和处理用户数据。通过将学习转移到边缘端，系统可以降低通信成本，并将训练工作负载分布在部署舰队中，缓解了中心化资源的压力，同时提高了可扩展性。

替代方案与决策标准

设备端学习需要大量的工程投入，这并不总是合理的。更简单的替代方案往往能以更低的运营开销实现相当的效果，过早采用会在没有相应价值的情况下引入复杂性。

表 11.1 对比了三种替代方案，它们通常无需本地训练的复杂性即可满足个性化和适配需求。

| 替代方案 | 机制 | 适用场景 |

| --- | --- | --- |

| 基于特征的个性化 | 在本地存储用户偏好、交互历史和行为特征，然后将这些特征输入静态模型，而不是调整模型权重。 | 新闻推荐系统可在本地存储主题偏好和阅读模式，然后将这些特征与中心化的内容模型相结合。 |

| 带隐私控制的云端微调 | 在隐私保护技术（如差分隐私、联邦分析、安全聚合 (Bonawitz et al. 2017) 或这些控制的组合）下，于非高峰时段批量处理用户数据，实现中心化适配。 | 这种方法通常比资源受限的设备端更新能实现更高的准确性，同时为许多应用维持可接受的隐私属性。 |

| 用户专属查找表 | 通过维护一个用于频繁访问的本地模式的轻量级表，将全局模型与个性化检索机制相结合。 | 需要个性化收益，且计算和存储开销极小。 |

表 11.1：设备端学习的替代方案：更简单的个性化机制无需本地梯度更新即可满足许多适配需求，因此设备端学习应保留用于隐私、延迟、连接性或可衡量的质量要求排除这些选项的场景。

在云端微调一行中，差分隐私¹⁷⁷ 是一种在添加噪声（这可能需要更多轮次或更多数据）的同时限制信息泄露的机制。

实施设备端学习的决策应由排除这些更简单替代方案的可量化需求驱动。法律上禁止云端处理的真实数据隐私约束、阻止可靠连接的真实网络限制、排除云端往返的量化延迟预算，或证明运营复杂性合理的可证明性能提升，均代表了采用设备端学习的正当理由。

对于具有关键时序要求的应用，网络往返时间使得基于云端的替代方案在架构上变得不可行。33 毫秒以下的相机处理、500 毫秒以下的语音响应、20 毫秒以下的 AR/VR 运动到光子延迟，或 10 毫秒以下的安全关键控制，均面临通常在 50 到 200 毫秒范围内的网络往返时间。在这些场景下，无论复杂性如何考量，设备端学习都成为必要。团队在投入设备端学习所需的巨大工程投资之前，应彻底评估更简单的解决方案。

知识迁移作为适配基础

这些动机建立在知识迁移的更广泛概念之上，即预训练模型将有用的表示迁移到新任务或新领域。这一基本原理使设备端学习既可行又有效，仅凭极少的本地资源即可实现复杂的适配。图 11.1 说明了知识迁移如何在紧密相关的任务之间发生，例如玩不同的棋类游戏或乐器，或跨越共享结构的领域（如从骑自行车到驾驶滑板车）。在设备端学习中，云端预训练的模型仅使用本地数据和有限的更新即可高效适应新环境，即使新任务在输入模态或目标上有所不同，也能实现快速适配，无需从头重新学习。

图 11.1：知识迁移：预训练模型通过利用现有表示加速新任务的学习，如在相关棋类游戏或乐器间迁移技能所示。这种迁移延伸至骑自行车和驾驶滑板车等跨领域场景，共享的底层结构使得仅凭有限的新数据即可实现高效适配。

这一由迁移学习和适配所实现的概念转变，使得现实世界的设备端应用成为可能。无论是为个人打字偏好适配语言模型、调整手势识别以适应个人运动模式，还是在变化的环境中重新校准传感器模型，设备端学习都使系统能够随时间保持响应性、高效性和用户一致性。

现实应用领域

设备端学习的动机在消费技术、医疗保健、工业系统和嵌入式应用中具体体现，每个领域都呈现出个性化、延迟、隐私和基础设施效率变得至关重要的场景。移动输入预测是设备端学习的一个有据可查的例子。在智能手机键盘等系统中，预测文本和自动纠错功能从持续的本地适配中获益显著。用户打字模式高度个性化且动态演变，使得中心化的静态模型不足以提供高质量的用户体验。设备端学习允许语言模型直接在设备上微调其预测，在保持数据本地性的同时实现个性化。例如，Google 的 Gboard¹⁷⁸ 采用联邦学习¹⁷⁹（每台设备共享模型更新，从不共享底层数据）来改进跨大量用户群体的共享模型，同时将原始数据保留在各自设备本地 (Hard et al. 2018)。

图 11.2 演示了不同预测策略如何实现实时本地适配。下一词预测基于先前文本建议可能的延续，而智能撰写利用即时重评分提供动态补全。这些技术展示了本地推理机制的复杂性。

图 11.2：设备端预测策略：Gboard 采用下一词预测和带即时重评分的智能撰写，在本地适配用户打字模式，增强个性化并保护隐私。这些技术展示了机器学习模型如何在不向中心服务器传输数据的情况下实时优化预测，从而实现高效且私密的移动输入体验。

可穿戴与健康监测设备

可穿戴和健康监测设备呈现出同样引人注目的用例，但面临额外的监管约束。这些系统依赖加速度计、心率传感器和皮电活动监测器的实时数据来跟踪用户健康与体能。个体间的生理基线差异巨大，造成了静态模型无法有效解决的个性化挑战。设备端学习允许模型随时间适应这些个体基线，在满足数据本地化监管要求的同时，大幅提升活动识别、压力检测和睡眠分期的准确性。

语音交互技术

语音交互技术是另一个具有独特声学挑战的重要应用领域。智能音箱和耳机等设备中的唤醒词检测和语音界面，必须在嘈杂或动态变化的声学环境中快速准确地识别语音指令。

这些系统面临严格的延迟要求。语音界面必须保持 500 ms 以内的端到端响应时间以维持自然对话流畅度，唤醒词检测要求亚 100 ms 响应时间以避免用户挫败感。本地训练允许模型适应用户独特的声纹和变化的环境背景，在满足这些苛刻性能约束的同时减少误报和漏检。这种适应在远场音频设置中尤为宝贵，因为麦克风配置和房间声学特性在不同部署中差异巨大。

工业物联网与远程监控系统

除了消费级应用，工业物联网和远程监控系统展示了设备端学习在资源受限环境中的价值。在农业传感、管道监测或环境监控等应用中，与中心化基础设施的连接可能受限、昂贵或完全不可用。设备端学习使这些系统能够在无需持续与云端通信的情况下检测异常、调整阈值或适应季节性趋势。这种能力对于维持边缘部署传感器网络的自主性和可靠性至关重要，因为系统停机或漏检可能造成重大的经济或安全后果。

嵌入式计算机视觉系统

最苛刻的应用出现在嵌入式计算机视觉系统中，包括机器人、AR/VR 和智能摄像头。这些系统将复杂的视觉处理与 Section 11.1.2 确立的最严格延迟预算相结合：30 FPS 摄像头的 33 ms 帧预算、防止 AR/VR 眩晕的亚 20 ms 运动到光子预算，以及安全关键控制的亚 10 ms 界限。这些系统还在与原始训练条件截然不同的新环境或快速变化环境中运行。设备端适应允许模型在满足这些关键延迟预算的同时重新校准至新的光照条件、物体外观或运动模式，这些预算从根本上驱动了设备端与云端处理之间的架构决策。

共同模式与设计需求

每个领域都揭示了一个共同模式。部署环境引入了无法在中心化训练期间预见的变化和特定上下文需求。这些应用展示了动机驱动因素如何表现为具体的工程约束。移动键盘面临存储用户特定模式的内存限制。可穿戴设备遇到限制训练频率的能量预算。语音界面必须满足排除云端协调的亚 100 ms 延迟要求。工业物联网系统在网络受限环境中运行，要求自主适应。这一模式阐明了塑造所有后续技术决策的基本设计需求。学习必须在显著资源约束下高效、私密且可靠地执行。Section 11.2 系统分析这些约束，Section 11.3 展示在紧凑资源包络内适应模型的技术，Section 11.5 建立跨设备群体隐私保护协调的协议。

架构权衡：中心化与去中心化训练

这些应用的多样性揭示了设备端学习与传统 ML 架构的根本差异，这种差异超越了部署选择，延伸为对训练生命周期的完全重新构想。许多机器学习系统遵循中心化学习范式：模型在数据中心使用来自多源的大规模精选数据集进行训练，以静态形式部署到客户端设备进行推理而不再进一步修改，并通过使用现场发回的新收集或标注数据进行离线重新训练来定期接收更新。这种中心化模型提供了经过验证的优势，包括高性能计算基础设施、对多样化数据分布的访问，以及稳健的调试和验证流水线，但它也依赖于边缘部署常违反的假设：可靠的数据传输、对数据托管的信任，以及能够跨设备队列管理全球更新的基础设施。

设备端学习颠倒了这些假设。每个设备维护自己的模型副本，并使用中心化基础设施无法访问的数据在本地进行适应。训练在由设备使用模式、电池电量和热状态驱动的变化资源条件下异步发生。原始数据保留在设备上，减少了隐私风险但增加了协调复杂性。硬件能力、运行时环境和使用模式在设备间差异巨大，使学习过程具有异构性且难以标准化。

去中心化引入了一类新的系统挑战。设备可能运行不同模型版本，导致部署队列中的行为不一致。缺乏中心测量性能的枢纽点，使评估和验证变得更加复杂 (McMahan et al. 2017)。模型更新必须谨慎管理以防止退化，没有中心化测试基础设施，安全保证更难执行。

管理数千个异构边缘设备超出了典型分布式系统的复杂性。设备异构性不仅限于硬件差异，还包括不同的操作系统版本、安全补丁、网络配置和电源管理策略。大规模联邦系统必须容忍未通过资格检查、迟到或在训练轮次中退出的客户端 (Bonawitz et al. 2019)。其他设备可能已断开连接数周或数月，造成持久的协调挑战。

当断开连接的设备重新连接时，它们需要状态协调以避免版本冲突。更新验证变得至关重要，因为设备可能静默地无法应用更新，或在运行过时模型时报告成功。稳健系统实施多阶段验证。加密签名确认更新完整性，功能测试验证模型行为，遥测确认部署成功。回滚策略必须处理部分部署，即某些设备接收更新而其他设备保持在先前版本。在故障恢复期间保持系统一致性需要复杂的编排，这借鉴了分布式系统原则，同时引入了边缘特有的复杂性。

尽管面临这些挑战，去中心化实现了无需中心化监管的深度个性化，支持在断网或带宽受限的环境中学习，并降低了模型更新的运营成本。核心问题是如何跨设备协调学习，这个问题分为三个运行阶段：集中式训练、本地适应和联邦协调。

传统的集中式范式始于聚合数据的云端训练，随后将静态模型部署到客户端设备。当数据收集可行、网络连接可靠且单一全局模型能有效服务所有用户时，这种方法效果很好。然而，当数据变得个性化、隐私敏感或在连接受限的环境中收集时，这种方法就会失效。

部署后，随着每个设备遇到其独特的数据分布，本地差异开始显现。设备收集的数据反映了个体用户模式、环境条件和使用上下文。这些数据通常是非独立同分布（non-i.i.d.¹⁸¹）且带有噪声的，需要本地模型适应来维持性能。这一转变标志着从全局泛化到本地专用化的转变。

最后阶段引入了联邦协调，设备通过聚合模型更新而非原始数据共享来定期同步其本地适应。这在保持本地个性化优势的同时，实现了保护隐私的全局细化。

图 11.3 追踪了从集中式训练经过本地适应到联邦协调的演变过程。每个阶段都增加了协调复杂性，同时实现了纯集中式部署中不可能的能力。

图 11.3：从仅本地到中心化云到联邦学习：分布式学习的演变分为三个阶段：（A）仅本地，单个设备在无外部通信的情况下使用自身数据训练；（B）中心化云，多个设备将原始数据发送至云服务器进行聚合（简单但有隐私风险）；（C）联邦学习，设备仅与联邦平均（FedAvg）聚合服务器共享模型更新（Δθ），大规模保护隐私。每个阶段都在协调成本与隐私和协作收益之间进行权衡。

去中心化、持续学习重写了系统设计的规则。我们不再在拥有近乎无限电力的恒温数据中心运行；必须直面边缘设备严峻的物理和算法限制。

设计约束

在智能手机上微调神经网络是一场热力学博弈。典型的 GPU 训练集群消耗兆瓦级功率，而智能手机必须在 10 W 的热预算内执行反向传播，既不能烫伤用户的手，也不能在五分钟内耗尽电池。这些严苛约束迫使我们从根本上重新设计学习算法，使其在计算、内存和数据方面高效至极。

参数、操作和数据上的约束是乘积而非加法相互作用的，创造了一个比纯推理部署更具挑战性的约束优化问题。最重要的转变在于压缩的目的：量化缩减每个权重的字节数，剪枝移除不必要的参数，知识蒸馏将行为迁移到更小的架构中，而设备端学习将这些工具从可选优化转变为基线可行性要求。此处建立的压缩基线是后续章节构建的基础，而非重新推导。

设备端学习在推理的同等效率约束下运行，但具有特定于训练的放大效应，使优化变得更加苛刻。推理仅需通过网络的单次前向传播，而训练需要前向传播、反向传播中的梯度计算和权重更新，当包含激活值、梯度和优化器状态时，内存需求增加 4–12 倍，计算成本增加 2–3 倍。这些放大效应正是压缩基线在边缘端不可商量的原因：没有它，在设备约束内训练将不可能实现。

塑造设备端学习实现的根本工程挑战直接源于这些动机。在设备上启用学习需要完全重新思考关于机器学习系统在何处及如何运行的传统假设。在中心化环境中，模型在拥有大量计算基础设施、大型精选数据集以及充裕内存和能源预算的条件下训练。而在边缘端，这些假设均不成立，创造了一个根本不同的设计空间。

这些约束定义了一个可行区域，而非核对清单。模型压缩决定了算法能改变多少。稀疏、非均匀数据决定了每次本地更新能提取多少信号。有限算力决定了训练何时能运行。这些维度间的相互作用决定了后续在适应、数据效率和联邦协调技术间的选择。

量化边缘设备上的训练开销

除了压缩基线，训练以特定于本地适应的方式放大内存占用、内存带宽和硬件利用率压力，这些压力是复合而非相加的。表 11.2 量化了计算操作如何增长 2–3 倍、能耗如何膨胀 10–50 倍，而图 11.4 显示了该更宽范围内具有代表性的 9 倍 Adam 风格内存预算。

| 约束维度 | 推理 | 训练放大 | 对设计的影响 |

| :--- | :--- | :--- | :--- |

| 内存占用 | 模型权重 + 单个激活图 | 权重 + 完整激活缓存 + 梯度 + 优化器状态 | 增加 4–12 倍；迫使采用激进压缩 |

| 计算操作 | 仅前向传播 | 前向 + 反向 + 权重更新 | 增加 2–3 倍；限制模型复杂度 |

| 内存带宽 | 顺序权重读取 | 梯度的双向数据流 | 增加 5–10 倍；产生瓶颈 |

| 每样本能耗 | 单次推理操作 | 含收敛的多次梯度步骤 | 增加 10–50 倍；需机会主义调度 |

| 数据需求 | 预收集、精选数据集 | 稀疏、嘈杂、流式本地数据 | 必须采用样本高效方法 |

| 硬件利用率 | 为前向传播优化 | 反向传播的不同访问模式 | 推理加速器可能无助于训练 |

表 11.2：训练放大推理约束：设备端学习在推理的同等效率约束下运行，但具有特定于训练的放大效应，使优化变得更加苛刻。本表量化了从运行预训练模型过渡到本地适应时每个约束维度如何增强。放大系数假设为标准反向传播，未使用梯度检查点等优化。

如图 11.4 所示，具有代表性的 Adam 风格训练预算在各模型规模下可达 9 倍内存占用增长；更宽的 4–12 倍范围取决于优化器选择、批大小、激活检查点和更新层数。

图 11.4：训练内存放大器

跨模型规模（100 万至 1 亿参数）的推理与训练内存需求对比。此说明性配置存储权重、梯度、优化器状态和激活值，产生具有代表性的 9 倍内存占用增加。

峰值内存使用

训练期间的内存消耗并非静态。它动态波动，在反向传播期间达到最大值，此时激活值、梯度和优化器状态必须共存。该峰值内存使用量决定了模型能否在设备上训练。对于配备 8 GB RAM 的智能手机上的 1000 万参数模型，40 MB 的 FP32 权重在反向传播期间可能飙升至 200 MB 以上，因为激活值、梯度和优化器状态会累积——直接与操作系统和前台应用争夺设备有限的内存。梯度检查点等技术通过在前向传播期间丢弃中间激活值，并在反向传播期间按需重新计算它们来缓解此问题（Chen et al. 2016）。这种方法以额外计算换取较低的峰值内存；具体节省量取决于哪些激活值被检查点化以及设备能容忍多少重新计算。

这些放大效应解释了为何标准优化技术若不经修改直接应用于训练工作负载便会失效。每个约束类别都塑造着设备端学习系统的设计，要求采用在推理导向方法基础上构建并加以扩展的方法。

验证您对训练如何放大边缘约束的理解：

图 11.5 展示了完整训练管线如何将离线预训练与资源受限物联网设备上的在线自适应学习相结合。系统首先使用通用数据进行元训练。部署期间，设备特定的约束（如数据可用性、算力和内存）通过对要更新的层和通道进行排序和选择来塑造适应策略。这种选择性微调允许在有限的资源包络内实现高效的设备端学习。

模型约束

机器学习模型的结构和大小直接决定了设备端训练是否可行。云部署模型可跨越数十亿参数，并依赖多 GB 级内存预算；面向设备端学习的模型必须符合内存、存储和计算复杂度的严格约束。这些约束在训练期间进一步收紧，因为梯度计算、参数更新和优化器状态管理都需要除推理之外的额外资源。

跨设备谱系，这些约束的规模变得具体化。MobileNetV2 常用于移动视觉任务，其标准配置约需 14 MB 存储空间。虽然对于拥有数 GB 可用 RAM 的智能手机而言可行，但这远超 Arduino Nano 33 BLE Sense 等微控制器的 256 KB SRAM 和 1 MB 闪存存储¹⁸²。在这类严重受限平台上，甚至单个卷积层在训练期间可能因中间特征图和梯度存储而超出可用 RAM。

训练过程本身会显著扩大有效内存占用。标准反向传播在前向传播期间缓存每层的激活值，随后在反向传播的梯度计算中复用它们。约束放大分析表明，与纯推理部署相比，这种激活值缓存使内存需求成倍增加。一个看似普通的处理 64 × 64 图像的 10 层卷积模型可能需要 1 到 2 MB，远超大多数嵌入式系统的 SRAM 容量。

模型复杂度还直接影响运行时能耗和热限制。在智能手表或电池供电的可穿戴设备上，持续的模型训练会迅速耗尽能量储备，或触发热节流导致性能下降。即使满足内存约束，在这些设备上使用浮点运算训练完整模型在能耗方面通常也是不可行的。MLPerf Tiny 等超轻量级基准为严重受限设备提供了小型量化推理目标（Banbury et al. 2021）。设备端适应技术随后通过冻结大部分参数、减少激活存储或选择稀疏更新集来降低训练成本（Cai, Gan, Zhu, et al. 2020；Kwon et al. 2024）。

电池和热约束的实际影响不仅限于限制训练时长。移动设备必须在训练机会与用户体验之间谨慎平衡。激进的设备端训练会导致设备明显发热和电池快速耗尽，引发用户不满和潜在的应用卸载。智能手机 ML 工作负载通常在 2–3 W 的持续处理包络内运行以防止热不适，尽管在热节流生效前可短时爆发至 5–10 W。即使训练适度的模型也容易超出这些可持续功耗限制。这种现实要求智能调度策略：在热散发条件改善的充电时段进行训练，尽可能使用低功耗核心进行梯度计算，并实施热感知占空比循环，在温度超阈值时暂停训练。某些系统甚至利用设备使用模式，仅在设备空闲且连接电源的夜间充电时段安排密集适应。

这些约束要求模型架构从一开始就为设备端学习而设计。大型 Transformer 和深度卷积网络若不进行分区、量化或卸载，根本不适合设备端适应。MobileNets¹⁸³、SqueezeNet（Iandola et al. 2016）和 EfficientNet（Tan and Le 2019）等专用轻量级架构通过深度可分离卷积¹⁸⁴、瓶颈 / Fire 模块和复合模型缩放等机制解决资源受限推理问题。量化和选择性更新则是架构之上的独立部署和适应选择。

模块化是关键设计属性。MobileNets（Howard et al. 2017）和 MobileNetV2（Sandler et al. 2018）可配置不同的宽度乘数和分辨率设置，以平衡性能和资源使用。宽度乘数 α[width] = 1.0 的完整 MobileNetV2 约有 350 万参数（FP32 下 14 MB）。当 α[width] = 0.5 时，完整 1000 类模型约有 200 万参数（7.9 MB），而仅带小型任务专用头部的特征提取器部署可小至 69 万参数（2.8 MB），适配 4 MB 模型预算。

数据约束

模型架构与数据约束

模型架构决定了设备端学习的内存和计算基线，但数据的可用性和质量引入了同样根本的限制，这些限制塑造了学习过程的方方面面。设备端 ML 系统可用的数据与云端训练所用的大规模精选数据集截然不同。在边缘端，数据是本地采集、时间上稀疏的，且往往是非结构化或无标签的。由此产生的在数据量、质量和统计分布方面的挑战，直接影响着设备端学习的可靠性和泛化能力。

数据量

数据量受到存储限制和用户交互零星性质的双重严重制约。智能健身追踪器可能仅在体育活动期间采集运动数据，每天产生相对较少的标注样本。如果用户锻炼 30 分钟，可能只有几百个数据点可用于训练，而有效的监督学习通常需要数千或数百万个样本。这种稀缺性迫使算法从 data-rich（数据丰富型）转向 data-efficient（数据高效型）。

非独立同分布数据分布

设备端数据也经常是非独立同分布的（non-IID，Zhao et al. 2018），这给云端系统很少遇到的统计学挑战带来了困难。部署在各家庭中的语音助手会遇到口音、语言、说话风格和指令模式的巨大差异。智能手机键盘适应个体的打字模式、自动更正偏好和多语言使用习惯，这些在用户间差异巨大。这种异质性使得模型收敛和更新机制的设计复杂化，后者必须在跨设备泛化的同时保持个性化。

标签稀缺

标签稀缺加剧了分布问题。大多数边缘采集的数据默认是无标签的，要求系统从弱监督或隐式监督信号中学习。智能手机相机全天可能拍摄数千张图片，但只有少数与有意义的用户操作（标记、收藏或分享）相关联，这些操作可作为隐式标签。在许多应用中，包括传感器数据中的异常检测和手势识别适配，显式标签可能完全不可用，若没有弱监督或无监督适配的替代方法，传统监督学习便行不通。

数据质量

数据质量引入了进一步的挑战。环境传感器或汽车 ECU 等嵌入式系统会经历传感器校准波动、环境干扰或机械磨损，导致输入信号随时间推移而损坏或漂移。如果没有集中式验证系统来检测和过滤这些错误，它们会无声地降低学习性能。

隐私与安全

隐私和安全顾虑施加了最严格的约束，往往使数据共享在架构上变得 impossible（不可能），而不仅仅是 undesirable（不可取）。敏感信息（如健康数据、个人通信或行为模式）必须根据法律和道德要求防止未经授权的访问。因此，设备端学习必须依赖那些能在从未暴露敏感信息的情况下实现本地适配的技术，从根本上重塑了学习系统的设计和验证方式。

算力约束

边缘硬件景观为机器学习提供了计算底层，范围涵盖从最受限端的 STM32F4 和 ESP32 等微控制器，到中端拥有专用 AI 加速器（Apple Neural Engine、Qualcomm Hexagon、Google Tensor）的移动级处理器，再到高端高性能边缘设备。虽然这些设备提供不同水平的推理能力（计算吞吐量、内存带宽和执行预训练模型时的能效），但训练工作负载表现出根本不同的计算特性，从而重塑了硬件利用模式。

设备端学习必须在与云端训练基础设施相差数百倍或数千倍原始算力的计算包络内运行。关键差异在于：反向传播因梯度计算和激活缓存，需要比推理高得多的内存带宽；权重更新产生写密集型访问模式，这不同于推理的只读操作；优化器状态管理需要额外的内存分配。完全足以胜任 inference（推理）的硬件，在执行 adaptation（适配/训练）时可能完全不堪重负，即使仅更新一小部分参数。

在最受限端，STM32F4¹⁸⁵ 或 ESP32¹⁸⁶ 等微控制器仅提供几百 KB 的 SRAM 和有限的算力与功耗预算（Warden and Situnayake 2020）。尽管这些系列包含单精度浮点支持，实际 ML 部署通常依赖量化或定点内核以求效率。CMSIS-NN 等库（Lai et al. 2018）为 Arm Cortex-M 处理器提供了优化的神经网络内核，通过定点运算和单指令多数据流（SIMD）优化实现了 4.6 倍的运行时提升。这些严苛限制排除了传统深度学习库，要求模型专为量化运算和最小运行时内存分配而设计。即使是简单模型，也需要量化感知训练¹⁸⁷和选择性参数更新，才能在不超出内存或功耗预算的情况下执行训练循环。

实际影响非常显著：STM32F4 微控制器虽能运行一个拥有几百个参数的简单线性回归模型，但训练即使是一个小型卷积神经网络也会立即耗尽其内存容量。在这些严重受限的环境中，神经网络更新通常局限于随机梯度下降（SGD）¹⁸⁸ 等简单算法，而非神经网络适配可能使用 k-means 聚类来更新质心或用于传感器异常检测的阈值。两者均可用整数运算和最小内存开销实现，代表了与数据中心机器学习实践的根本背离。

向上迈进至移动级硬件，计算层级有所改善，但仍在严苛约束下运行。包括 Qualcomm Snapdragon、Apple Neural Engine¹⁸⁹ 和 Google Tensor SoC¹⁹⁰ 在内的平台，比微控制器提供强得多的算力，通常配备专用 AI 加速器并针对 8 位或混合精度¹⁹¹ 矩阵运算提供优化支持。这些加速器提供专用矩阵乘法单元、片上内存层级和电源管理功能，专为神经网络推理设计，对本地训练工作负载的支持程度不一。虽然这些平台能支持更复杂的训练流程，包括针对紧凑模型的完整反向传播，但它们仍远未达到中心化数据中心可用的计算吞吐量和内存带宽。例如，在智能手机上训练轻量级 Transformer¹⁹² 在技术上可行，但必须在时间和能耗上严格限制，以免降低用户体验，这凸显了学习能力与实际部署约束之间持续存在的张力。

发布的基准测试结果

来自 MLPerf Tiny 和官方供应商数据的发布基准测试结果使这些硬件层级变得具体明确。图 11.6 绘制了代表性设备的推理延迟与每次推理能耗的关系，揭示了三个由约 100× 能耗差异分隔的明显集群。专用神经处理器（如 Syntiant Core 2 和 STM32N6 NPU）可在 5 ms 以下、30 至 160 微焦耳 能耗下实现关键词检测，而边缘 GPU（如 Jetson AGX Orin）则能在 15 毫焦耳 能耗下提供亚毫秒级延迟。层级间的 100× 能耗鸿沟决定了哪些设备可靠电池供电运行数月而非数小时，从根本上塑造了设备端学习的可行设计空间。

图 11.6：边缘推理全景图：来自 MLPerf Tiny 和官方基准测试的已发布推理延迟和能耗测量揭示了三个由约 100× 能耗差异分隔的截然不同的硬件层级。专用神经处理器（Syntiant、STM32N6）可在 5 ms 以下、30-160 微焦耳 能耗下实现关键词检测，而边缘 GPU（Jetson Orin）则能在 15 mJ 能耗下提供亚毫秒级延迟。

这些计算限制在实时或电池供电系统中变得尤为严峻，第 11.1.2 节 中确立的延迟预算变成了硬性架构约束：它们决定了设备端适应是否根本可行，还是基于云端的替代方案在架构上成为必要。更严苛的约束是适应过程不能独占设备。在基于智能手机的语音识别器中，设备端适应必须与主要推理工作负载无缝共存，且不干扰响应延迟或系统响应性。同样，在可穿戴医疗监测仪中，训练必须在精心管理的时间窗口（通常在低活动期或充电期间）机会性地进行，以保护电池寿命并避免热管理问题。

除了原始计算能力外，这些硬件约束的架构含义还延伸至基本的系统设计选择。训练操作表现出与推理工作负载截然不同的内存访问模式：由于梯度计算和激活缓存，反向传播需要 3–5× 更高的内存带宽，造成了纯计算指标无法捕捉的瓶颈。边缘加速器设计通过专用硬件特性解决这些挑战。自适应精度数据通路允许在前向传播的 INT4 和梯度计算的 FP16 之间动态切换，在功率预算内优化精度和效率。稀疏计算单元通过跳过零梯度加速选择性参数更新，这对高效的仅偏置和结构化低秩更新（第 11.3.2.2 节）至关重要。近存计算架构通过在紧邻权重存储处直接执行梯度更新来降低数据移动成本，解决内存带宽瓶颈。然而，许多边缘加速器仍从根本上针对推理工作负载进行优化，这为专门处理本地适应独特需求的设备端训练加速器创造了软硬件协同设计机会。

移动端内存墙

虽然移动 NPU 提供了令人印象深刻的 TOPS，但 第 2.3 节 所探讨的“内存墙”成为边缘设备上大规模模型难以逾越的障碍。限制训练更新的同一带宽墙，在移动语言模型解码中最容易看清：如果权重和 KV 状态无法足够快地流经内存，任何标称的 TOPS 数值都无法挽救该工作负载。近期分析凸显了自回归解码如何将 LLM 推理压力转向内存和互联，而非峰值算术吞吐量（Ma and Patterson 2026）。量化差距十分显著：H100 上的数据中心 HBM3 提供 3,350 GB/s，而 A17 Pro 或 Snapdragon 8 Gen 3 等旗舰移动系统的 LPDDR5X 带宽仅在 64–100 GB/s 左右。

数据中心 HBM 的带宽比移动端内存高出约 34 倍。

30–50× 的带宽差距意味着，即使模型能放入移动端 RAM，其生成 token 的速度也比数据中心 GPU 慢 30–50×。因此，设备端大语言模型（LLM）服务需要激进的量化（INT4 甚至 INT2）作为带宽生存策略，而不仅仅是容量优化。将模型尺寸缩小 8× 实际上增加了相对带宽，使移动硬件上交互式生成速度成为可能。

带宽差距之所以成为瓶颈，是因为每个生成的 token 都要将模型权重从内存流式传输到计算单元，所以只要权重超出片上缓存（这在移动级芯片上的十亿参数模型中是常态），铁律中的数据项（D[vol]/BW）就会主导计算项。这也是量化缩减 D[vol] 而非每 token 算术量的原因。

实际推论如下：在为 Transformer 解码对边缘加速器选项排序时，衡量指标是芯片能向其片上封装内存持续提供的 GB/s，而非其规格表上的峰值 TOPS。两者在移动级芯片上可能相差数个数量级。

边缘硬件集成挑战

除了模型、数据和计算的个别约束外，设备端学习系统还必须驾驭移动计算的底层物理特性：功耗散发、热极限和能量预算。这些物理约束是决定设备端学习算法整个可行空间的根本设计驱动因素。

能量与热约束分析

能量和热管理代表了设备端学习系统设计中最具挑战性的方面，因为它们直接影响用户体验和设备寿命。移动设备在严格的功率预算下运行，这从根本上决定了可行的模型复杂度和训练调度。

问题：一个团队正在为智能手机上的个性化语音助手设计一个后台微调任务。该训练任务消耗 4.5 W，需 30 分钟 完成。如果手机配备 15 Wh 电池，这次“不可见”的更新将消耗用户多少电量？

数学计算：

1. 总能量：4.5 W × 0.5 h = 2.25 Wh。

2. 电池影响：2.25 Wh / 15 Wh = 15%。

系统洞察：为后台任务消耗用户 15% 的电量严重违反了移动用户体验原则——这相当于损失一小时的屏幕使用时间。这就是为什么设备端训练通常限制为机会性调度：仅在设备插电、连接 Wi-Fi 且热稳定时运行。为边缘设计意味着像尊重模型精度预算一样严格尊重用户的能量预算。

此电池计算是更广泛能量约束的设备端学习本地版本：训练必须适应用户的能量预算，而不仅仅是模型的精度目标。因此，生产设计必须在调度时核算能量，对比本地计算与通信成本，并在用户设备无法吸收更新时推迟学习。

设备内存跨度约 15,000 倍，从手机到微控制器。

内存层级优化

内存层级约束

补充热力和功耗挑战的同时，内存层级约束造成了另一个塑造设备端学习系统设计的根本瓶颈。约束放大分析表明，这些限制同时影响静态模型存储和训练期间的动态内存需求，往往将系统推向其实际极限之外。

设备内存层级跨越几个数量级，覆盖不同设备类别，每种类别都为设备端学习带来独特的约束。旗舰手机提供约 8 GB 总系统内存，但扣除操作系统需求和后台进程后，仅有部分可用于应用工作负载。预算级 Android 设备运行在约 4 GB 总系统内存下，操作系统开销消耗大量资源后，仅剩约 1 GB–2 GB 可用于 ML 工作负载。IoT 嵌入式系统提供 64 MB–1 GB 总内存，必须在系统任务和应用数据间共享，给任何学习算法造成严峻约束。微控制器仅提供 256 KB–2 MB SRAM，要求极致优化和谨慎的内存管理，从根本上限制了可在此类平台适应的模型复杂度。

训练期间的内存膨胀造成了特别严峻的挑战，往往决定了系统的可行性。标准反向传播要求在前向传播期间缓存每层的中间激活值，随后在反向传播的梯度计算中复用，产生巨大的内存开销。一个在推理时轻松适配内存的 MobileNetV2 规模模型，一旦包含激活值、梯度和优化器状态，即可超出可用内存预算，若无激进优化则无法训练。量化、剪枝和蒸馏各自可减小模型体积或更新成本（Jacob et al. 2018; Han et al. 2015; Hinton et al. 2015），但其收益因工作负载而异且不会自动组合。这些技术必须联合验证，以实现实际部署所需的压缩。

因此，缓存优化成为在受限内存池中实现可接受性能的关键。现代移动 SoC 具备复杂内存层级：L1 缓存（32–64 KB）、L2 缓存（1–8 MB）和系统内存（4–16 GB），层级间存在 10–100× 延迟差异，当工作集超出缓存容量时会造成严重的性能断崖。超出缓存容量的训练工作负载因内存带宽瓶颈面临剧烈的性能下降，训练速度可能降低数个数量级。成功的设备端学习系统必须精心设计数据访问模式以最大化缓存命中率，通常需要专用内存布局将相关参数分组以利用空间局部性、精心设计适应缓存约束的微批次大小、以及精细的梯度累积策略以最小化昂贵的内存总线流量。

内存带宽限制在训练期间变得尤为严峻。推理工作负载主要顺序读取模型权重，而训练需要双向数据流进行梯度计算和权重更新。这种增加的内存流量可饱和内存子系统，造成瓶颈，无论计算能力如何都限制训练吞吐量。先进实现采用诸如梯度检查点¹⁹⁴ 以计算换内存（Chen et al. 2016）及混合精度训练等技术，在保持数值稳定性的同时降低带宽需求。

移动 AI 加速器优化

加速器的选择不在于峰值 TOPS 的比较，而在于硬件能持续支持哪种训练原语。固定精度推理引擎偏向推理密集型适应，可编程向量单元使紧凑反向传播更可行，紧密的框架集成降低了联邦协调开销。这些加速器间的架构差异塑造了设备端训练算法的设计空间。

旗舰级移动加速器应被视为不同的适应包络，而非峰值 TOPS 排名。旗舰级移动 NPU 提供数十 TOPS 的峰值性能，此处 35 TOPS 作为通用高端参考点，而非单一具名芯片。Apple 的 Neural Engine 主要针对 CoreML 推理模式优化，训练支持有限，适合推理密集型适应技术。Qualcomm 的 Snapdragon 8 Gen 3 中的 Hexagon DSP 达到 45 TOPS，具备灵活精度支持和可编程向量单元，支持混合精度训练工作流，可根据训练阶段和内存约束动态调整精度。Google 的 Pixel 8 中的 Tensor TPU 专门针对 TensorFlow Lite 操作优化，具备强劲的 INT8 性能并与联邦学习框架紧密集成，反映了对分布式学习场景的软件栈关注。能效差距解释了为何专用神经处理单元至关重要：NPU 实现 1–5 TOPS/瓦特，而通用 CPU 仅 0.1–0.2 TOPS/瓦特，呈现 5–50× 的能效优势，这决定了设备端训练的可行与不可行。

每种加速器暗示不同的学习范式。Apple 的 Neural Engine 擅长固定精度推理，但对动态精度梯度计算支持有限，更适合推理密集型适应技术如小样本学习。可编程 DSP 通过向量单元和混合精度算术提供更大的训练灵活性，当软件栈暴露所需算子时，可在紧凑模型上实现反向传播。移动 TPU 级加速器与框架运行时和联邦学习工具紧密集成，降低了本地训练和更新协调的系统开销。

这些厂商特定的包络继承了第 11.2.4 节讨论的相同训练专用访问模式和硬件特性：写密集型梯度流、自适应精度数据通路、稀疏更新单元和近存计算，这些特性将支持训练的加速器与仅支持推理的加速器区分开来。对设计的启示是，此处的架构选择非峰值吞吐量之选；它影响从模型量化策略、梯度计算方法到联邦通信协议和热管理策略的方方面面。

全息资源管理策略

上述约束分析揭示了定义设备端学习设计空间的三大挑战类别，每类驱动一个对应的解决方案支柱。资源放大（训练使内存需求增加 4–12×，计算成本增加 2–3×，能耗成比例增加）要求采用模型适应方法，在保持学习能力的同时减小参数更新范围。信息稀缺（包括有限的本地数据集、非 IID 分布、数据共享隐私限制和最少监督）驱动数据效率方案，从极少样本中提取最大学习信号。协调挑战（如设备异构性、间歇性连接、分布式验证复杂性和可扩展性需求）激励联邦协调机制，实现跨设备群体的隐私保护协作。

面向设备端学习的约束-解决方案映射

表 11.3 揭示了这种设备端学习约束-解决方案映射如何创建了一个系统化的工程框架：模型适应 通过选择性参数更新解决内存和计算限制，数据效率 从稀缺的私有样本中最大化学习效果，而 联邦协调 实现了隐私保护的协作。与其将这些视为独立的技术，稳健的系统会编排这三种方法，创建能够在边缘约束内有效运行的连贯自适应系统。

| 约束类别 | 关键挑战 | 解决方案方法 |

| --- | --- | --- |

| 资源放大 | • 训练工作负载（内存 4–12×）
• 内存限制
• 功耗约束 | 模型适应
• 参数高效更新
• 选择性层微调
• 低秩适应 |

| 信息稀缺 | • 有限的本地数据集
• 非 IID 分布
• 隐私限制 | 数据效率
• 少样本学习
• 元学习
• 迁移学习 |

| 协调挑战 | • 设备异构性
• 间歇性连接
• 分布式验证复杂性
• 可扩展性要求 | 联邦协调
• 联邦平均与异步聚合
• 安全聚合与差分隐私
• 客户端选择与慢节点处理 |

表 11.3：约束-解决方案映射：设备端学习中的三大基本约束类别各自通过直接必要性驱动相应的解决方案方法。

每个解决方案支柱都扩展了压缩和分布式系统工具，以解决特定的约束类别。单一支柱本身是不够的，但它们的集成创建了能够在边缘部署环境的严苛约束内实现有意义适应的系统。

模型适应

在只有 500 MB 总系统内存的智能手表上对十亿参数模型进行个性化，如果不放弃更新完整模型的目标，那是不可能的。答案是我们不更新整个模型。我们冻结网络的绝大多数部分，仅训练一小组经过战略性放置的新参数。这就是资源高效模型适应的精髓。

问题：一个团队将一个 1000 万参数的视觉模型部署到支持 10 种不同“用户上下文”（家庭、办公室、汽车等）的智能手机上。如果一个完全微调的模型需要 40 MB，那么使用残差适配器代替能节省多少存储空间？

数学计算：

1. 完全微调：10 个上下文 × 40 MB = 400 MB。

2. 适配器方法：(1 × 40 MB 主干) + (10 × 200 KB 适配器) ≈ 42 MB。

3. 存储节省：400 MB / 42 MB ≈ 9.5 倍设备总存储减少。

4. 每上下文效率：40 MB / 0.2 MB = 200 倍。

系统洞察：个性化是一个存储密度问题。在闪存有限的设备上，存储同一个 40 MB 模型的 10 个版本会迅速消耗 400 MB。将模型分片为冻结的主干和动态适配器，将新用户上下文的边际成本降低了 200 倍。在边缘设备群中，模块化是在不耗尽物理硬件的前提下扩展智能的唯一途径。

适配器使得按用户个性化比完整模型副本廉价得多。

工程挑战的核心在于驾驭一个基本的权衡空间：适应表达能力与资源消耗。在一端，更新所有参数提供了最大灵活性，但超出了边缘设备的能力；在另一端，零适应保留了资源，却无法捕捉用户特定模式。有效的设备端学习系统必须在中间地带运行，基于三个关键工程标准选择适应策略：

• 资源包络 决定哪些适应方法是可行的。拥有 1 MB RAM 的微型可穿戴设备需要与拥有 8 GB 内存的智能手机截然不同的策略。

• 用户特定变化 决定系统需要多少适应复杂度。简单的偏好学习可能只需要偏置更新，而复杂的域迁移则要求更复杂的方法。

• 系统集成 决定适应技术能否融入现有的推理管线、联邦协调协议，以及用于模型部署和生命周期管理的运营监控系统。

适应技术的选择遵循相同的逻辑，从轻量级方法（第 11.3.1 节）开始，逐步过渡到表达能力更强但资源消耗更大的方法（第 11.3.3 节）。每种技术都代表了工程权衡空间中的不同点。

在 第 11.2 节 确立的压缩基线之上，模型适应增加了第二步：完整的模型重新训练在边缘端既不必要也不可行，因此系统战略性地使用预训练表示，仅调整捕捉局部变化所需的最小参数子集：保留全局有效的部分，适应局部重要的部分。这三个标准将适应转化为设备匹配决策。权重冻结通过仅更新偏置项或最后几层来适应严峻的内存限制。当设备能承担更多表达能力但无法进行完全微调时，结构化更新使用低秩和残差适应。稀疏更新将稀缺的训练算力保留给具有最高适应价值的参数。

权重冻结

设备端学习最直接的方法是冻结模型的大部分参数，仅调整极小的子集。仅偏置适应 将所有权重固定，仅更新偏置项（线性层或卷积层之后应用的标量偏移）。该约束将可训练参数减少 100–1000 倍，简化了反向传播期间的内存管理，并在训练数据稀疏或嘈杂时有助于缓解过拟合。

考虑一个标准神经网络层：y = Wx + b，其中 W ∈ ℝ^(m×n) 是权重矩阵，b ∈ ℝ^(m) 是偏置向量，x ∈ ℝ^(n) 是输入。在完全训练中，会为 W 和 b 计算梯度。在仅偏置适应中，我们约束：

\[ \frac{\partial \mathcal{L}}{\partial W} = 0, \quad \frac{\partial \mathcal{L}}{\partial b} \neq 0 \]

使得仅偏置通过梯度下降更新：

\[ b \leftarrow b - \eta \frac{\partial \mathcal{L}}{\partial b} \]

这减少了存储的梯度和优化器状态，使得训练能在内存受限条件下进行。在缺乏浮点运算单元的嵌入式设备上，这种减少使设备端学习成为可能。清单 11.1 明确了该约束：所有卷积和全连接权重保持冻结，而仅偏置项适应本地数据。

# 清单 11.1：仅偏置适应
# 冻结除偏置外的模型参数，以减少内存使用并允许设备端学习。
# 伪代码示例：
for param in model.parameters():
    param.requires_grad = False  # 冻结所有权重
for bias in model.biases():
    bias.requires_grad = True    # 仅解冻偏置

清单 11.1：仅偏置适应：冻结除偏置外的模型参数，以减少内存使用并允许设备端学习。

这种模式确保只有偏置项参与反向传播和优化器更新，在保持适应能力的同时简化了训练过程。当将预训练模型适应用户特定或设备本地数据（其中核心表示仍然相关但需要校准）时，这非常有价值。

TinyTL: 高效设备端适配

这种方法的实际有效性由 TinyTL (Cai, Gan, Zhu, et al. 2020) 得以证明，这是一个专门设计用于在微控制器和其他严重内存受限平台上实现深度神经网络高效适配的框架。与其在训练期间更新所有网络参数（在如此受限的设备上是不可能的），TinyTL 策略性地同时冻结卷积权重和批量归一化统计量，仅训练偏置项，在某些情况下还包括轻量级残差组件。这种架构约束在反向传播期间的内存需求上产生了深远的转变，因为最大的内存消费者（中间激活值）不再需要为冻结层的梯度计算而存储。

图 11.7 通过对比标准训练与 TinyTL 方法，直观展示了这种架构影响。常规反向传播需要存储所有层的激活值，而 TinyTL 冻结主干权重和批量归一化统计量，仅训练最终分类器和轻量级偏置模块。这消除了为冻结层存储激活值的需求，使得在前述严重内存限制下进行适配成为可能。

图 11.7：TinyTL 内存优化：对比传统微调（上）与 TinyTL 方法（下）。传统方法要求在反向传播期间存储所有层的激活值。TinyTL 冻结主干权重并仅训练偏置项，显著降低了设备端适配的内存需求。

仅当冻结的主干网络对于下游任务仍保持足够的表达能力时，内存减少才有用。偏置项允许对模型行为进行细微但有意义的调整，特别适用于个性化任务。当领域偏移更为显著时，TinyTL 可以选择性地引入小型残差适配器以提高表达能力，同时保持系统严格的内存和能耗配置。

这些设计选择使 TinyTL 能将训练内存用量降低 10×。例如，使用 TinyTL 适配 MobileNetV2 模型可将更新参数量从超过 3 million 降至少于 50,000 个¹⁹⁵。结合量化技术，这使得仅拥有几百 KB 内存的设备也能进行本地适配，从而在受限环境中真正实现了设备端学习。

结构化参数更新

虽然权重冻结提供了计算效率和明确的内存边界，但它通过将适配限制在一小部分参数子集上，严重限制了模型的表达能力。当仅更新偏置不足以捕捉复杂的领域偏移或用户特定模式时，残差和低秩技术在权重冻结的极致效率与无限制微调的完全表达性之间提供了一个折中方案。这些方法不是修改现有参数，而是通过添加小型可训练组件（如残差适配模块 (Houlsby et al. 2019) 或低秩参数化 (Hu et al. 2021)）来扩展冻结模型。网络主体保持固定，仅优化新增组件，因此模型能在不放弃使设备端适配成为可能的内存和计算边界的情况下响应新数据。

基于适配器的适配

一种常见实现涉及在预训练模型的现有层之间插入残差适配器，即小型残差瓶颈层。考虑层间传递的隐藏表示 h。残差适配器引入变换：h' = h + A(h)，其中 A(·) 是可训练函数，通常由两个线性层和一个非线性激活组成：A(h) = W₂ σ(W₁h)，W₁ ∈ ℝ^(r×d)，W₂ ∈ ℝ^(d×r)，且 r ≪ d。这种瓶颈设计确保每层仅引入少量参数。

适配器作为冻结主干网络之上的可学习扰动发挥作用。因为它们体积小且稀疏应用，增加的内存开销可忽略不计，却能让模型根据新输入调整其预测。

低秩技术

另一种高效策略是将权重更新本身约束为低秩结构。不更新完整矩阵 W，而是将更新近似为：ΔW ≈ U V^⊤，其中 U ∈ ℝ^(m×r)，V ∈ ℝ^(n×r)，且 r ≪ min(m, n)。这将可训练参数量从 m×n 降至 r(m + n)。

这种分解背后的数学直觉关联到基础线性代数原理：任何矩阵都可通过奇异值分解表示为一组秩一矩阵之和。将更新约束为低秩（通常 r = 4 到 16）在减少参数的同时捕捉了一组受限的变化模式。以典型维度 768 × 768 的 Transformer 层为例，全量微调需更新 589,824 个参数。采用秩 4 分解，仅更新 768 × 4 × 2 = 6,144 个参数，实现 99 percent 的减少。能否保留大部分适配质量取决于任务、秩和基础模型；低秩适配 报告称，低秩适配器可在多个 Transformer 适配基准上达到或接近全量微调效果 (Hu et al. 2021)。

适配期间，新权重计算为：W_adapted = W_frozen + U V^⊤

该公式常用于 LoRA¹⁹⁶，最初为 Transformer 模型开发 (Hu et al. 2021) 但广泛适用于各类架构。从系统工程视角看，LoRA 使可训练适配器成为可独立于冻结基础模型进行存储、传输、调度和回滚的工件。

设想这样一个移动部署场景：一个拥有 7B 参数的语言模型，其 FP16 权重占用 14 GB，这还未计入全量微调所需的额外梯度、优化器状态和激活值。除非基础模型被激进地量化、分区或卸载，否则这在总内存约 8 GB 的智能手机上是不可能的。在秩 16 下，LoRA 可将可训练适配器参数降至数十或数百 MB，仅当冻结基础模单独处理时，本地适配才变得可行。

LoRA 的效率在间歇性连接场景下变得至关重要。全模型更新通过蜂窝网络需下载 14 GB 并承担相应流量费用，而适配器更新仅 50 MB。在良好移动链路上，小型适配器更新可在一分钟内同步；较大适配器更新通常需 LTE 或 Wi-Fi 实现亚分钟级协调，在 3G 网络下可能需数分钟。这仍比数小时的全模型传输切实可行得多。

分层设备部署可根据设备能力使用不同适配器配置。旗舰手机采用更宽瓶颈以获更高表达力，中端设备用中等瓶颈平衡性能，入门设备用窄瓶颈以维持在约 2 GB 内存限制内。这些残差适配器模块可在边缘设备上高效实现，特别是当下投影和上投影矩阵较小且支持定点表示时。清单 11.2 将这种低秩适配器模式实现为残差瓶颈，展示了紧凑的下/上投影如何在不更新冻结主干的情况下增加可训练容量。

场景：大规模移动键盘系统是联邦学习和设备端学习的典型部署模式。

机制：键盘可以在不上传原始按键的情况下，调整下一个单词预测，但前提是训练受到严格限制：它仅在设备闲置、充电、连接 Wi-Fi 的时间窗口运行，并传输压缩后的更新而非文本。大规模部署可以将安全聚合与隐私核算或噪声添加相结合，使服务器仅学习群体级别的更新统计信息，而非个人的输入历史。

系统层面的启示：只有当训练计划、通信负载和隐私边界被协同设计时，设备端学习才切实可行。模型更新是一种系统协议，而不仅仅是一个本地优化步骤。

回到适配器机制，代码清单 11.2 展示了使内存节省具体化的残差瓶颈：冻结的主干网络保持不变，仅训练下投影和上投影权重。

代码清单 11.2：残差瓶颈适配器：该代码实现了一个包含下投影和上投影层的紧凑适配器模块，在减少可训练参数量的同时，实现了边缘设备上高效的模型适配。

该适配器向冻结层添加了一个小型残差变换。当插入更大的模型中时，仅训练适配器参数。

边缘个性化

适配器为边缘智能实现了高效的多租户架构，其中单个冻结主干网络支持多个个性化上下文。设想一个部署在拥有 8 GB 内存智能手机上的 1000 万参数视觉模型。完全微调将要求为每个个性化上下文（家庭、办公室、户外）存储一份独立的 40 MB 模型权重副本，迅速耗尽设备存储。秩为 64 的适配器每个上下文仅引入约 50,000 个参数（约 200 KB）——存储量减少了 200 倍。这种效率使设备能够存储数十个共享同一冻结主干网络的专用适配器，并根据用户的位置或活动动态切换它们。

这种适配器切换模式将智能手机从静态推理引擎转变为上下文感知学习系统。当用户进入弱光环境时，系统可以将合适的适配器加载到视觉流水线中，而无需替换整个主干网络。这种模块化自然地延伸至联邦学习：在上述 1000 万参数的示例中，传输一个 200 KB 的适配器远比在带宽受限的蜂窝连接上传输 40 MB 的全模型更新便宜得多。残差适配器研究表明，小型可训练模块可以跨多个视觉域适配共享视觉主干网络（Rebuffi 等人，2017），使其成为在个性化质量和系统资源之间取得平衡的有用设计点。冻结主干网络有助于保留通用视觉表征，而适配器为用户或上下文特定的更新提供了一个有界空间，且不会使整个模型面临灾难性遗忘的风险——即新更新覆盖旧知识时，先前学到的通用行为丢失（在本章后文的第 11.4.2 节中形式化阐述）。

在智能手机相机流水线中，环境光照、用户偏好和镜头畸变因用户而异。共享模型可以被冻结，并通过少量残差模块按设备微调，从而在不破坏基础模型稳定性的前提下实现轻量级个性化。在语音系统中，适配器模块在无需重新训练完整声学模型的情况下，降低了个性化语音识别的词错误率。它们还允许轻松回滚或在用户特定版本间切换——这是一项关键的操作能力，因为本地适配偶尔会降低而非提升性能。

性能与资源权衡

选择正确的适配策略需要对资源-表达性光谱进行定量分析。对于 1000 万参数模型，权衡是具体的。仅偏置更新效率最高，仅需 50 KB 可训练参数，计算开销可忽略不计，但难以适应结构性域迁移，如传感器几何变化或新物体类别。另一极端，完全微调提供最大表达性，但需要 40 MB 或更多的梯度和优化器状态，使其难以在典型移动设备上进行后台训练。低秩技术 (LoRA) 和残差适配器占据了战略中间地带：秩为 16 的 LoRA 配置需要约 2 MB 可训练内存，而标准残差适配器需约 5 MB。

在 LoRA 和残差适配器之间做决定，往往取决于推理延迟约束。LoRA 矩阵在推理期间可在数学上合并进冻结主干权重中（W_final = W_frozen + U * V^⊤），导致零额外推理延迟。这使得 LoRA 成为延迟关键路径（如实时视频处理）的理想选择，因为每一毫秒都至关重要。相反，残差适配器保持为独立模块（y = f(x) + Adapter(x)），由于通过适配器层的额外前向传递，增加了 1%–3% 的推理延迟。然而，这种分离实现了前文所述的热插拔能力：切换适配器仅需加载少量适配器权重，而非重新计算合并矩阵。

实施这些适配技术需要系统级支持动态计算图，并能选择性地注入可训练参数。并非所有部署环境或推理引擎都原生支持此类功能。TensorFlow Lite 和 Open Neural Network Exchange (ONNX) Runtime Mobile 支持适配器风格架构，但微控制器上的自定义推理栈可能需要手动实现适配器前向传递。

系统架构师应应用设备分级框架来做此决策。在旗舰手机（一级）上，配备专用神经网络引擎和 8 GB 以上内存，残差适配器在模块化和速度之间提供了良好平衡，支持上下文感知切换且延迟影响极小。在中端设备（二级）上，拥有 4–8 GB 内存，LoRA 很有吸引力，因为权重合并完全消除了运行时开销。对于超受限的物联网端点（三级），内存不足 1 GB，仅偏置更新可能是唯一可行的选择。这种分级方法确保适配机制与硬件的物理现实相匹配，在防止热节流的同时，在每个能力层级提供有意义的个性化。

验证您对高效设备端适配的理解：

稀疏更新

稀疏更新处于模型适配层级的最高表达性端。系统不是预先添加新参数或选择固定子集，而是动态识别哪些现有参数为特定任务或用户提供最大的适配收益。这在保留完全微调大部分灵活性的同时，将更新占用空间控制在足以支持边缘部署的范围内。

稀疏更新决策不仅在于更新更少参数。即使模型适配技术将学习限制在一个小子集上，训练仍然资源密集。稀疏更新通过仅选择任务相关参数解决了剩余成本问题，在保留有意义个性化的同时减少内存和计算。

关键洞察在于：各层对本地性能提升的贡献并不相等。如果系统能识别出具有最高适配价值的最小子集，就能将稀缺的训练算力花在最能改变模型行为的地方。

稀疏更新设计

神经网络参数定义

设神经网络由跨越 N[L] 层的参数 θ = {θ[1], θ[2], …, θ[N[L]]} 定义。

在标准微调中，我们计算所有参数的梯度并执行更新：

θ_i ← θ_i - η ∂L/∂θ_i,  for i = 1, …, N_L

在任务自适应稀疏更新中，我们选择一个小子集 S ⊂ {1, …, N[L]}，使得仅更新 S 中的参数：

θ_i ← { θ_i - η ∂L/∂θ_i,  if i ∈ S
      { θ_i,              otherwise

子集选择的贡献分析

挑战在于在内存和计算约束下选择最优子集 S。一种原则性策略是贡献分析，一种估算每层对下游性能提升贡献程度的经验方法。例如，可以通过独立更新每层来测量其边际收益：

1. 冻结整个模型。

2. 解冻一个候选层。

3. 简短微调并评估验证集准确率的提升。

4. 按单位成本的性能收益对层进行排序（例如，每 KB 可训练内存的收益）。

这种逐层剖析产生一个排序，据此可在内存预算约束下构建 S。

TinyTrain：运行时自适应稀疏更新

一个具体例子是 TinyTrain，这是一种旨在实现设备端快速适应的方法 (Kwon et al. 2024)。TinyTrain 将离线准备与任务自适应稀疏更新方法相结合，该方法利用用户数据、内存限制和计算限制动态选择要更新的层或通道。在运行时，系统仅更新选定的子集，而非将整个网络视为可训练。

在实现中，选择性层更新将排序转化为 requires_grad 决策或等效的图掩码。Listing 11.3 将此模式扩展到基于剖析驱动的层选择，演示了硬件剖析如何根据贡献分数和内存约束确定要更新的层。

Listing 11.3：选择性层更新

此技术允许微调预训练模型的特定层，同时保持其他层冻结，从而优化计算资源以实现有针对性的改进。来源：PyTorch 文档。

TinyTrain 使运行时动机具体化。考虑这样一个场景：用户佩戴增强现实头显执行实时目标识别。随着光照和环境变化，系统必须适应以保持准确性，但训练必须在短暂的空闲期或充电期间进行。TinyTrain 通过任务自适应稀疏更新解决了这一约束：部署过程选择一个符合设备内存和计算预算的小更新集。当目标任务和设备配置文件与该方法的假设相匹配时，这种方法能使适应过程保持快速、节能且内存感知。

任务自适应稀疏更新仍引入了系统级权衡。即使贡献分析发生在预训练或初始剖析阶段，其计算成本也不可忽视，因此部署流水线必须为其预算。稳定性也需关注：如果选中更新的参数太少，模型可能对目标分布欠拟合，因此团队需要在部署前对选定子集设定验证阈值。选择策略还必须考虑硬件特定的执行成本，因为某些参数虽显示高贡献分数，但在特定架构上更新成本高昂。尽管存在这些权衡，任务自适应稀疏更新仍提供了一种实用机制，可将适应扩展至从微控制器到移动设备的各种部署场景 (Diao et al. 2023)。

适应策略对比

每种适应策略在表达性、资源效率和实现复杂性之间提供了独特的平衡。

• 仅偏置适应 是最轻量级的方法，仅更新各层的标量偏移量，同时冻结所有其他参数。这降低了内存需求和计算负担，使其适用于内存和能量预算紧张的设备。然而，其有限的表达性意味着它最适合预训练模型已捕获大部分相关任务特征、仅需微小局部校准的应用。

• 残差适应 通常通过适配器模块实现，将少量可训练参数引入神经网络的冻结主干网络中。这比仅偏置更新提供了更大的灵活性，同时仍保持对适应成本的控制。由于主干网络保持固定，训练可在受限条件下高效且安全地进行。该方法支持跨任务和用户的模块化个性化，使其成为需要中等适应能力的移动场景的优选方案。

• 任务自适应稀疏更新 通过基于对下游性能的贡献选择性更新层或参数子集，为特定任务微调提供了最大的潜力。虽然该方法允许表达性的局部适应，但它需要一种层选择机制（通过剖析、贡献分析或元训练），这引入了额外的复杂性。尽管如此，当谨慎部署时，它允许在准确性和效率之间进行动态权衡，特别是在经历大域偏移或不断变化的输入条件的系统中。

表 11.4 从可训练参数、内存开销、表达性、用例适用性和系统要求等维度对比了适应策略的权衡，揭示了最优选择如何取决于应用领域、可用硬件、延迟约束和预期分布偏移。

| 技术 | 可训练参数 | 内存开销 | 表达性 | 用例适用性 | 系统要求 |

| --- | --- | --- | --- | --- | --- |

| 仅偏置更新 | 仅偏置项 | 极小 | 低 | 简单个性化；低方差 | 极限内存/计算约束 |

| 残差适配器 | 适配器模块 | 中等 | 中等到高 | 移动端用户特定调优 | 支持运行时的移动级 SoC |

| 稀疏层更新 | 选择性参数子集 | 可变 | 高 (任务自适应) | 实时适应；域偏移 | 需剖析或元训练 |

表 11.4：适应策略权衡：表条目通过量化三种模型适应方法——仅偏置更新、残差适配器和稀疏层更新——对可训练参数、内存开销、表达性、不同用例的适用性及系统要求的影响，来刻画它们的特征。这些特征揭示了在动态环境中部署机器学习系统时，模型灵活性、计算成本和性能之间固有的权衡。

虽然冻结权重并训练适配器解决了内存瓶颈，但留下了一个统计问题。我们创建了一种高效的学习机制，但边缘设备很少拥有数千个标注样本来妥善训练即使是这些小型适配器。我们现在必须解决设备端学习的第二大支柱：数据效率。

数据效率

用户每天可能只纠正智能手机键盘自动更正三次。我们无法要求他们输入 10,000 个标注句子来训练语言模型。边缘端的数据效率意味着从稀疏、嘈杂且未经筛选的隐式用户反馈涓涓细流中激进地学习，最大化从每次交互中提取的信号。

System Engineering Challenge: Data Collection Cost vs. Adaptation Quality Trade-off

The systems engineering challenge centers on a critical trade-off: data collection cost versus adaptation quality. Edge devices face severe data acquisition constraints that reshape the design of learning systems in ways not encountered in centralized training. Understanding and addressing these constraints requires systematically analyzing four interrelated engineering dimensions:

• Acquisition cost encompasses user friction, energy consumption, storage overhead, and privacy risk. A voice assistant learning from audio samples must balance improvement potential against battery drain and user comfort with continuous recording.

• Collection depth determines whether the system spends limited capacity on broad coverage or detailed examples. A mobile keyboard can collect many shallow typing patterns or fewer detailed interaction sequences, each strategy implying different learning approaches.

• Learning urgency dictates whether the system must adapt immediately from few examples (as in emergency response scenarios) or can accumulate evidence over time (as in user preference learning).

• Lifecycle integration determines whether data efficiency techniques fit with model adaptation methods in Section 11.3, federated coordination in Section 11.5, and operational monitoring for model deployment and lifecycle management.

These engineering constraints create a systematic trade-off space where different data efficiency methods serve different combinations of constraints. Successful on-device learning systems often do not select a single technique but combine multiple methods, each addressing a specific aspect of the data scarcity challenge.

Strategy selection depends on which scarcity binds first. Few-shot learning suits cases where limited labeled or weakly-labeled examples must drive personalization. Streaming updates suit settings where useful data arrives incrementally and cannot be batched ahead of time. Experience replay trades memory to stabilize ongoing updates by reusing scarce examples. Data compression reduces the storage cost of these histories, keeping replay and lightweight training feasible within edge memory budgets.

Few-Shot Learning and Data Streams

Together, these techniques turn data scarcity into an allocation problem: spend labeling, memory, compute, and privacy budgets where they yield the most reliable local signal. In traditional ML workflows, effective training typically requires large labeled datasets, carefully curated and preprocessed to ensure sufficient diversity and balance. In contrast, on-device learning often begins with only a handful of local examples, passively collected through user interaction or environmental sensing, and rarely labeled in a supervised fashion. These constraints motivate two complementary adaptation strategies: few-shot learning, where models generalize from a small static set of examples, and streaming adaptation, where models update continuously as data arrives.

When a device observes a small number of labeled or weakly-labeled instances targeting a new task or user condition, Few-shot adaptation is particularly relevant (Wang et al. 2020). In these settings, performing full fine-tuning over all model parameters is typically infeasible and leads to overfitting. Instead, methods such as bias-only updates, adapter modules, or prototype-based classification are employed to exploit limited data while minimizing memorization capacity. Let \(\mathcal{S} = \{(x_i, y_i)\}_{i=1}^K\) denote the \(K\)-shot labeled example dataset collected on-device. The model update is only feasible when three constraints remain bounded:

• Gradient work remains small: \(K_{\text{steps}} \ll 100\).

• The update state remains compact: \(\|\theta_{\text{updated}}\| \ll \|\theta\|\).

• Prior task knowledge is preserved, avoiding catastrophic forgetting.

Keyword spotting (KWS) systems are a common target for data-efficient on-device adaptation; Speech Commands provides a standard dataset for training and evaluating limited-vocabulary KWS models under on-device constraints (Warden 2018). These models are used to detect fixed phrases with low latency and high reliability, including phrases such as "Hey Siri"[¹⁹⁷] or "OK Google". A typical KWS model consists of a pre-trained acoustic encoder (e.g., a small convolutional or recurrent network mapping input audio to an embedding space) and a lightweight classifier. In commercial systems, the encoder is trained centrally on thousands of hours of labeled speech across languages and speakers. However, supporting custom wake words (e.g., "Hey Jarvis") or adapting to underrepresented accents and dialects often cannot be achieved through centralized training due to data scarcity and privacy concerns.

Few-shot adaptation addresses this by leveraging a small number of example utterances collected directly on-device to fine-tune only the output classifier or a small subset of parameters, including bias terms. For example, a user may provide 5-10 recordings of a custom wake word. These samples are then used to update the model locally, while the main encoder remains frozen to preserve generalization and reduce memory overhead. This enables personalization without requiring additional labeled data or transmitting private audio to the cloud.

The approach is computationally efficient and aligns with privacy-preserving design principles. Because only the output layer is updated, typically involving a single gradient step or prototype computation, the total memory footprint and runtime compute are compatible with mobile-class devices and even microcontrollers.

Beyond static few-shot learning, many on-device scenarios benefit from streaming adaptation, where models must learn incrementally as new data arrives (Hayes et al. 2020). Streaming adaptation generalizes this idea to a continuous, asynchronous setting where data arrives incrementally over time. Let \(\{x_t\}_{t=1}^\infty\) denote the observation stream. In the streaming setting, the model must update itself after observing each new input, typically without access to prior data, and under bounded memory and compute. Computable losses may come from implicit feedback, pseudo-labels, self-supervised objectives, reconstruction error, or task-specific proxies rather than explicit human labels. The model update generalizes to: \(\theta_{t+1} = \theta_t - \eta_t \nabla \mathcal{L}(x_t; \theta_t)\), where \(\eta_t\) is the learning rate at time \(t\). This form of adaptation is sensitive to noise and drift in the input distribution, so it is often combined with mechanisms such as learning rate decay, meta-learned initializations, or update gating for stability.

Practical deployments of these strategies extend beyond KWS. In wearable health devices, models classifying physical activity may start from a generic classifier and adapt to a user's specific motion patterns using only a few labeled activity segments. In smart assistants, user voice profiles are continuously refined through ongoing voice input, even without explicit supervision. Here, local feedback—including corrections, repetitions, or downstream task success—serves as an implicit signal to guide learning.

Few-shot and streaming adaptation lay the groundwork for more advanced memory and replay strategies that address the stability challenges of sustained on-device learning.

Experience Replay

Catastrophic Forgetting is a phenomenon where neural networks rapidly lose performance on previously learned tasks when trained sequentially on new tasks or data distributions, because gradient updates optimizing for new objectives overwrite weight configurations that supported old tasks.

1. 意义：若无显式缓解措施，在新域上微调已部署的分类器会大幅降低其在先前任务上的准确率，即使新域与旧域紧密相关（Kirkpatrick et al. 2017）。这是设备端学习和联邦学习的核心失效模式：每个在本地适应用户近期数据的设备，都有抹除集中式训练所赋予的通用能力的风险，且这种损耗在推理遇到“近期上下文之外”的输入前是不可见的。

2. 区别：遗忘不同于过拟合（单一固定任务上的泛化失败）和分布偏移（训练与推理数据在部署时的不匹配）；它是由更新流的序列结构本身导致的训练时现象；模型容量足够，但其权重无法在不干扰旧目标编码的情况下编码新目标。

3. 常见陷阱：一个常见的误解是，小规模的经验回放缓冲区就足以提供保护。对 100 到 1,000 个存储样本的朴素回放，可能在留出验证集上掩盖短视野的遗忘，却仍会降低稀有类别或长尾分布的性能，因为缓冲区的采样分布对尾部呈欠代表性。生产部署需要与容量成比例的缓冲区、优先级回放，或权重正则化方法（如弹性权重巩固，见第 11.7.2 节）。

学习新任务侵蚀了旧任务的准确率。

经验回放通过维护一个包含过往学习情节中代表性样本的缓冲区，解决了持续学习场景下的灾难性遗忘问题。该技术最初为强化学习开发（Mnih et al. 2015），在设备端学习中被证明至关重要，因为序列数据流可能导致模型过拟合于近期样本。在此，经验回放解决了即时的稳定性需求；而生物启发的终身学习（第 11.7.2 节）则通过局部可塑性和巩固机制解决同一稳定性问题。

与依赖大规模数据集和大量算力的服务端回放策略不同，设备端回放必须在极受限的容量下运行，通常仅有数十或数百个样本，且必须避免干扰用户体验（Rolnick et al. 2019）。缓冲区可能仅存储压缩特征或蒸馏摘要，更新必须在机会性时刻进行（例如空闲周期或充电时）。这些系统级约束重塑了嵌入式 ML 中回放的实现与评估方式。

设 ℳ 表示一个保留固定大小训练样本子集的记忆缓冲区。在时间步 t，模型接收新数据点 (x[t], y[t]) 并将其追加至 ℳ。基于回放的更新随后从 ℳ 中采样一个批次 {(x[i], y[i])}[i=1]^(k) 并应用梯度步骤：

θ_{t+1} = θ_t - η ∇_θ [ (1/k) Σ_{i=1}^{k} L(x_i, y_i; θ_t) ]

其中 θ[t] 为模型参数，η 为学习率，L 为损失函数。随着时间的推移，该回放机制允许模型在融合新信息的同时强化先验知识。

一个切实可行的设备端实现可能使用环形缓冲区存储少量压缩特征向量，而非完整输入样本。清单 11.4 实现了这种极简回放缓冲区设计，演示了循环存储机制如何在平衡历史知识保留与新信息融合的同时，实现高效内存管理。

清单 11.4：回放缓冲区：实现了一种用于受限环境高效内存管理的循环存储机制。这种方法使模型能高效保留并采样近期数据点，平衡利用历史信息与融合新见解的需求。

该实现维护一个固定容量的循环缓冲区，存储压缩表示（如最后一层嵌入）及关联标签。此类缓冲区适用于在不违背内存或能量预算的前提下，回放适配更新。

在 TinyML 应用¹⁹⁸中，经验回放已应用于手势识别等问题，设备必须在每天仅观测到少量事件的情况下持续改进预测。设备不直接在流数据上训练，而是存储近期手势的代表性特征向量，并定期用其微调分类边界。同样，在设备端关键词唤醒中，回放过往语句可在无需将音频数据传出设备的情况下提升唤醒词检测准确率。

虽然经验回放提升了数据稀疏或非平稳环境下的稳定性，但也引入了若干权衡。存储原始输入可能违反隐私约束或超出存储预算，尤其是在视觉和音频应用中。回放特征向量虽减少内存占用，但可能限制上游层梯度的丰富度。为嵌入式设备长期存储而频繁写入持久化闪存，还可能引发磨损均衡担忧。这些约束要求在持续部署场景中，仔细协同设计内存使用策略、回放频率及特征选择策略。

数据压缩

在许多设备端学习场景中，原始训练数据可能过大、噪声多或冗余，难以有效存储和处理。这促使采用压缩数据表示，将原始输入转换为低维嵌入或紧凑编码，在最小化内存和计算成本的同时保留显著信息。

压缩表示服务于两个互补目标：减小存储数据的占用空间，使设备能在严峻的内存预算下维持更长的历史或回放缓冲区（Hayes et al. 2020）；并通过将原始输入投影到更结构化的特征空间（常通过预训练或元学习获得，在其中仅需极少监督即可高效适配）来简化学习任务。

一种常见方法是使用预训练特征提取器编码数据点并丢弃原始高维输入。例如，图像 x[i] 可通过 CNN 生成嵌入向量 z[i] = f(x[i])，其中 f(·) 为固定特征编码器。该嵌入以紧凑表示（通常 64 至 512 维）捕捉视觉结构（如形状、纹理或空间布局），适合轻量级下游适配。

数学上，可使用轻量级解码器或投影头在压缩样本 (z[i], y[i]) 上进行训练。设 θ 为该解码器模型的可训练参数，通常为一个将压缩表示映射到输出预测的小型神经网络。每呈现一个样本，即使用梯度下降更新模型参数：θ[t + 1] = θ[t] - η∇[θ]L(g(z[i]; θ), y[i]) 六个要素定义了此更新规则：

• z[i] 为第 i 个输入的压缩表示，

• y[i] 为对应的标签或监督信号，

• g(z[i]; θ) 为解码器的预测，

• L 为度量预测误差的损失函数，

• η 为学习率，及

∇θ 表示相对于参数 θ 的梯度。

这种公式阐明了仅需训练一个拥有参数集 θ 的紧凑解码器模型，即使在内存和算力受限的情况下，也使学习过程变得可行。

当重放存储而非模型算力成为瓶颈约束时，高级方法会超越固定编码器的范畴。它们学习离散或稀疏字典：即反复出现的传感器轨迹模式的基，这些基比原始重放样本存储得更紧凑。传感器轨迹数据集可分解为 X ≈ Φ[dict]C，其中 Φ[dict] 是基模式字典，C 是分块稀疏系数矩阵，指示每个样本中哪些模式处于激活状态。通过仅更新少量字典原子或系数，模型能以极小的重放缓冲区开销实现适应。

压缩表示在隐私敏感场景中大有裨益，因为它们允许在编码后丢弃或混淆原始数据。压缩充当隐式正则化器，平滑学习过程，并在仅有少量训练样本可用时缓解过拟合。

在实践中，这些策略已应用于关键词检测等领域，原始音频信号首先被转换为梅尔频率倒谱系数（MFCCs）¹⁹⁹，这是语音功率谱的一种紧凑、有损表示。这些 MFCC 向量作为下游模型的压缩输入，仅使用几千字节内存即可实现本地适应。

数据效率策略对比

小样本学习、经验重放和压缩数据表示各自针对数据稀缺或流式传输时设备端适应的不同侧面。其有效性取决于系统级因素：内存容量、数据可用性、任务结构和隐私需求。

当有一小组但信息丰富的标注样本可用时，特别是在需要个性化或快速任务特定调优时，小样本适应表现出色。它将算力和数据需求降至最低，但其有效性取决于预训练表示的质量及初始模型与本地任务的契合度。

经验重放通过缓解遗忘和提高稳定性来应对持续适应，尤其是在非平稳环境中。它允许重用过去的数据，但需要内存存储样本和算力周期进行周期性更新。重放缓冲区还可能引发隐私或寿命担忧，特别是在存储有限或闪存写入周期受限的设备上。

压缩数据表示通过将原始数据转换为紧凑特征空间来减小学习占用。这种方法支持更长时间的经验保留和高效微调，尤其是在仅有轻量级头部可训练时。压缩可能引入信息损失，且如果固定编码器与部署条件不够契合，可能无法捕捉任务相关的变异性。表 11.5 总结了每种技术在数据需求、内存开销和用例适用性方面的设备端学习权衡。

| 技术 | 数据需求 | 内存/算力开销 | 用例契合度 |

| --- | --- | --- | --- |

| 小样本适应 | 小型标注集（K 射击） | 低 | 个性化、快速设备端微调 |

| 经验重放 | 流式数据 | 中等（缓冲区与更新） | 非平稳数据、漂移下的稳定性 |

| 压缩表示 | 无标签或编码数据 | 低到中等 | 内存受限设备；隐私敏感场景 |

表 11.5：设备端学习权衡：技术选择取决于约束边缘的瓶颈：小样本适应将标注数据需求降至最低，重放以内存为代价提高漂移下的稳定性，压缩表示在原始数据过大或过于敏感而无法保留时延长保留期。

在实践中，这些方法并非互斥。许多现实系统会结合它们以实现鲁棒、高效的适应。例如，关键词检测系统可能使用压缩音频特征（如 MFCCs），从小型支持集微调少量参数，并维护过去嵌入的重放缓冲区以实现持续改进。

高效的适应和数据策略使单台设备能从其用户处学习。然而，数百万台孤立设备各自为政地学习，浪费了共享其本地化洞见的巨大机会。在不损害用户隐私的前提下聚合这种去中心化智能，需要联邦学习的数学原理。

联邦学习：算法

假设一家医院想利用患者记录训练 AI 以预测并发症，但严格的隐私法规使得将原始患者数据移至中心服务器成为非法。这就是跨孤岛联邦学习：少数可靠机构在不集中数据的情况下协作。挑战在于让多家医院协同训练全局模型，且永不共享其原始数据。联邦学习通过将计算移至数据端、将模型广播至边缘、仅聚合由此产生的模型更新来解决此问题。

考虑部署在 1000 万家庭的语音助手。这就是跨设备联邦学习：大量不可靠、间歇性连接的设备在本地条件允许时贡献微小更新。每台设备针对其用户的声音、口音和词汇进行本地适应。设备 A 学会 "data" 读作 /ˈdeɪtə/，设备 B 学会 /ˈdætə/。设备 C（科技家庭）频繁遇到罕见短语 "machine learning"，而设备 D（非科技家庭）从未见过。经过六个月的孤立本地适应后，出现四种失效模式：

• 每台设备在单一用户模式上表现出色，但难以泛化至更广范围。

• 罕见词汇在某些设备上被学会，在另一些设备上被遗忘。

• 局部偏差在无更广泛群体校正的情况下累积。

• 一台设备发现的宝贵洞见无法惠及其他设备。

孤立的单设备学习虽利于本地个性化，但设备孤立运行时面临根本局限。每台设备仅观测完整数据分布的窄窄一隅，限制了泛化能力。设备能力差异巨大，造成群体间学习不平衡。一台设备学到的宝贵洞见无法惠及他人，降低了整体系统智能。缺乏协调下，模型可能因局部偏差随时间发散或退化。

联邦学习通过隐私保护协作解决这些协作约束：设备在不共享原始数据的前提下贡献集体智能。该方法将数据局部性从限制转化为隐私特性，使系统能从人口规模数据中学习，同时保障个体信息安全。该承诺仅在系统将梯度和参与元数据视为敏感输出时才成立，因为这些信号仍可能泄露本地用户信息。

联邦学习 是一种去中心化训练范式，分布式设备利用本地数据协同训练共享模型，仅交换模型更新（梯度或权重）。

1. 意义：它将数据局部性约束转化为隐私特性。在铁律中，联邦学习受限于广域带宽（BW）和车队的极端异构性，其中设备专属效率（η[hw]）和可用性可能相差数量级。

2. 区别：与将数据移至算力的中心化训练不同，联邦学习将算力移至数据端，确保原始信息永不离开设备。

常见误区

一个常见的误解是认为联邦学习“天生具有隐私性”。实际上，模型更新本身可能通过梯度反演攻击泄露信息，因此需要额外的保护措施，如差分隐私或安全聚合。

其运营收益并非抽象概念：对于相机个性化工作负载，传输紧凑的模型更新而非原始观测数据，可以将带宽预算缩减数量级。

联邦学习传输的是更新而非原始数据，从而降低网络负载。

问题

某团队正在设计一个联邦相机个性化系统，该系统每周从 200 MB 的压缩用户图像中学习。系统应将原始图像上传至云端进行训练，还是使用联邦学习发送模型更新？

数学分析

带宽效率是原始数据量与模型更新大小的比率。

1. 原始数据上传：200 MB/周。

2. 联邦更新：一个压缩的模型更新（500 万参数）仅为 2.5 MB。

3. 带宽缩减：200 MB / 2.5 MB = 80× 节省。

系统洞察

联邦学习是一种 network multiplier（网络乘数）。对于流量套餐有限的用户，上传 200 MB 原始数据既昂贵又缓慢。上传 2.5 MB 更新几乎不留痕迹。将计算迁移至数据端，可将网络负载降低 80×，即使在带宽受限的环境中也能实现持续学习。在机器学习舰队中，这就是系统如何在不耗尽网络预算或侵犯用户隐私的前提下，扩展至大规模用户群体。

图 11.3 中介绍的三阶段演进（仅本地、中心化云端、联邦）如今归位为联邦学习的定义地位。图 11.8 重述了该对比，并带有算法章节所需的侧重点：离线学习集中训练并部署静态模型；设备端学习在隔离中本地适配，不在用户间共享洞见；而联邦学习通过全局协调更新、同时保持原始数据本地化，弥合了二者鸿沟，因此它受益于分布式模型改进，又无需中心化产生这些数据的来源。

图 11.8： 联邦学习通过协调分布式设备上的本地训练，在数据隐私与集体模型改进之间取得平衡，这不同于离线学习的中心化方法或设备端学习的隔离适配。每种范式处理数据位置和模型更新策略的方式不同，揭示了个性化、数据安全与全局知识共享之间的权衡。

保护隐私的协同学习

跨 Gboard 键盘个性化、可穿戴健康监测和语音接口等应用领域，紧凑的设备端更新仅解决了数据移动侧的问题。联邦学习 (FL) 增加了协调层：它跨设备群体训练共享模型，而无需将原始数据传输到中心服务器 (McMahan 等人，2017)。与需要在单一位置汇聚所有训练数据的传统中心化训练管线不同，联邦学习分发了训练过程本身。每台参与设备基于其本地数据计算更新，并通过聚合协议（通常由中心服务器协调）为全局模型做出贡献。

这种转变与移动、边缘和嵌入式系统紧密契合，因为它在保持数据局部性的同时仍能改进共享模型。然而，隐私和个性化收益仅在系统同时通过专用协议和协调机制处理客户端变异性、通信效率和非独立同分布 (non-i.i.d.) 数据分布²⁰⁰ 时才是真实的。

三大领域定义了设备端场景下的联邦学习：管辖设备间协调的核心学习协议、调度与通信效率策略，以及个性化方法。隐私机制（如安全聚合和差分隐私）包裹这些领域而非取代它们：它们决定服务器能从更新中推断什么，以及训练循环必须吸收多少噪声。

学习协议

使大规模分布式协调切实可行的协议，必须同时解决三大工程挑战：确保本地训练尽管面临非 IID 数据分布仍能产出兼容的更新，在带宽受限下高效聚合这些更新，以及协调具有异构可用性模式的设备间的时序。

本地训练

本地训练是隐私保护成为系统边界的节点。单个设备从私有数据计算模型更新，但每一个本地选择都影响聚合结果的有效性：设备从哪个基础模型开始、采样哪些本地样本、执行多少优化、发回什么更新。因此，将该循环呈现为有序协议而非抽象定义更为实用：

1. 模型初始化：每台设备初始化其本地模型参数，通常通过从服务器下载最新的全局模型。

2. 本地数据采样：设备采样其本地数据的一个子集用于训练。该数据可能是非 IID 的，即可能不会在设备间均匀分布。

3. 本地训练：设备在其本地数据上执行若干训练迭代，基于计算出的梯度更新模型参数。

4. 模型更新：本地训练后，设备计算模型更新（如更新后与初始参数的差值）并准备发送给服务器。

5. 通信：设备将模型更新传输至服务器，通常使用安全通信信道以保护用户隐私。

6. 模型聚合：服务器聚合来自多台设备的更新以生成新的全局模型，随后分发回参与设备。

该过程迭代重复，设备定期下载最新全局模型并执行本地训练。更新频率因系统约束、设备可用性和通信成本而异。

联邦聚合协议

联邦学习中的中心协调机制，允许拥有小规模本地数据集的设备协同训练共享模型。客户端设备执行本地训练并将模型更新传输至中心服务器，后者将其聚合为优化后的全局模型，并重新分发以供下一训练轮次。该循环过程将学习与中心化数据收集解耦，适用于用户数据私有、带宽受限且设备参与零星的环境。

该过程最广泛使用的基线是联邦平均 (FedAvg)²⁰¹，它已成为联邦学习的典范算法 (McMahan 等人，2017)。在 FedAvg 中，每台设备使用随机梯度下降 (SGD) 在其私有数据上训练模型的本地副本。

形式上，令 𝒟[k] 表示客户端 k 上的本地数据集，令 θ[k]^(t) 为第 t 轮客户端 k 上的模型参数。每个客户端在其本地数据上执行 E 个 epoch 的 SGD，产生更新 θ[k]^(t+1)。中心服务器随后按如下方式聚合这些更新：

\[ \theta^{t+1} = \sum_{k=1}^{C} \frac{n_k}{n} \theta_k^{t+1} \]

其中 n[k] = |𝒟[k]| 是设备 k 上的样本数量，n = ∑[k] n[k] 是所有参与客户端的总样本数，C 是当前轮次中活跃设备的数量。

直隶客户端缓解

在数百万异构设备的集群中，等待每个选定的客户端报告其更新是不切实际的。网络延迟、电池耗尽或后台进程争用可能导致某些设备（“直隶客户端”）耗时比平均值长 10 倍。在轮次语义层面，后果是直接的：上述加权聚合无法进行，直到收到足够的更新，因此轮次持续时间由服务器仍在等待的最慢设备决定。针对这一问题的调度答案——过度选择，是一种客户端调度策略，将在 第 11.6.1 节 中与客户端调度的其余部分一起讨论。

这种周期性协调协议构成了联邦学习的基础。图 11.9 将联邦平均协议分解为四个阶段：客户端选择（通过过度选择处理直隶客户端）、在私有数据上的本地训练、参数上传（可选压缩）以及产生更新后全局模型的加权聚合。

图 11.9：联邦平均协议：联邦学习的四阶段周期。(1) 服务器向参与客户端广播全局模型。(2) 客户端在私有数据上进行本地训练。(3) 客户端上传模型更新（梯度或权重）。(4) 服务器聚合更新生成改进的全局模型。

这一基本结构引入了许多设计选择和权衡。本地 epoch 数 E 影响计算与通信之间的平衡：较大的 E 减少通信频率，但如果本地数据分布差异过大，则有发散风险。参与客户端的选择影响收敛稳定性和公平性。在实际部署中，并非所有设备随时可用，且硬件能力可能差异巨大，这要求鲁棒的参与调度和容错能力。

联邦学习收敛分析

联邦学习是否收敛以及以多快速度达到可接受精度，是系统设计的关键问题。与集中式训练中收敛主要取决于学习率和批次大小不同，联邦学习收敛取决于通信轮次、本地计算、客户端参与和数据异构性之间的相互作用。这些因素决定了联邦部署将在数小时、数天内达到目标精度，还是永远无法达到。附录 C.3.4 节 阐述了弱扩展论证，即增加更多参与设备使总工作量增长快于其缩减墙钟时间，这设定了边际收益递减的界限，限制了客户端参与对加速收敛的作用。

收敛率基础

一个有用的系统抽象是将参与客户端数、本地 epoch 数和通信轮次的乘积视为联邦计算的有效量。McMahan 等人（2017）从客户端参与、本地小批量/epoch 工作和重复通信轮次的角度定义了 FedAvg。对于本章的系统模型，一个理想的 IID 缩放启发式将最优性差距总结为：

\[ \mathbb{E}[F(\theta^R) - F(\theta^\star)] \leq \mathcal{O}\left(\frac{1}{\sqrt{CER}}\right) \]

其中 F 是全局目标，θ^(R) 是 R 轮后的模型，θ^⋆ 是该目标的参考最优值，期望是在客户端采样和随机本地训练上的，C 是每轮参与的客户端数量，E 是每个客户端执行的本地 epoch 数，R 是通信轮次总数。根据此启发式，收敛随总计算量的平方根改进：增加客户端、本地 epoch 或轮次均带来边际收益递减。要将最优性差距减半，系统必须将总计算量增加四倍。

乘积 C*E*R 代表总客户端-epoch 数，即联邦计算的基本单位。假设数据分布相同，一个拥有 10 个客户端、每个执行 5 个本地 epoch、共 100 轮的系统（C*E*R = 5000）获得的收敛效果，类似于拥有 50 个客户端、每个执行 2 个 epoch、共 50 轮的系统（C*E*R = 5000）。这种等价性实现了灵活的资源分配：带宽受限的部署可通过更多本地计算来补偿，而计算受限的设备可依赖更频繁的通信。

非 IID 数据的影响

联邦缩放启发式假设客户端间数据为 IID，这一假设在实践中很少成立。调查和实证研究将非 IID 数据确定为联邦学习收敛的核心挑战，并用局部差异性、土方距离或权重发散等指标量化它（T. Li et al. 2020; Zhao et al. 2018）。为了推理这种系统效应，令 β_het 表示一个抽象的异构性惩罚，它随着局部客户端目标偏离全局目标而增长：

\[ \mathbb{E}[F(\theta^R) - F(\theta^\star)] \leq \mathcal{O}\left(\frac{1 + \beta_{\text{het}}}{\sqrt{CER}} + \frac{\beta_{\text{het}}² E²}{R}\right) \]

此处，β_het 是本章系统模型中表示客户端漂移的一种紧凑方式，而非所有分析共享的通用度量。当数据接近 IID 时，β_het 接近零，界限趋向标准的 O(1/√(CER)) 速率。当数据高度异构时，较大的 β_het 值显著减缓收敛。

第二项 \frac{\beta_{\text{het}}² E²}{R} 揭示了一个关键交互：更多的本地 epoch E 会放大异构性惩罚。每增加一步本地训练，在聚合前局部模型就进一步偏离全局最优，这些偏差在异构客户端间会累积。这创造了一个取决于数据分布特征的通信-计算权衡。

实践中量化异构性

现实世界的联邦部署表现出的 β_het 值因应用领域而异。说同一种语言的用户间的键盘预测通常显示 β_het ≈ 0.3-0.8，因为词汇和打字模式虽异但共享通用语言结构。跨语言键盘预测增加到 β_het ≈ 1.5-3.0，这是由于字符分布和词模式根本不同。具有多样化患者群体的健康监测可达 β_het ≈ 2.0-5.0，因为不同年龄组、健康水平和医疗状况下的生理基线差异巨大。

一个拥有 100 个客户端的生产联邦部署使轮次-复杂度权衡具体化：总体 100 个客户端，每轮选择 C = 10 个客户端，每轮 E = 5 个本地 epoch，目标最优性差距 ϵ = 0.01，以及两个场景对比：IID 数据（β_het = 0）与中度非 IID 数据（β_het = 1.5）。

IID 情况（β_het = 0）：使用收敛界限 ϵ ≤ σ/√(CER)，其中 σ 捕捉梯度方差（通常归一化目标下 σ ≈ 1），我们求解所需轮次：

\[ R_{\text{IID}} \geq \frac{\sigma²}{C \cdot E \cdot \epsilon²} = \frac{1}{10 \cdot 5 \cdot 0.0001} = 200 \text{ rounds} \]

每轮 10 个客户端和 5 个本地轮次，这代表 200 × 10 × 5 = 10,000 个总客户端-轮次的计算量。

非 IID 情况（\(\beta_{\text{het}} = 1.5\)）：异质性惩罚要求同时满足界限的两项。当 \(E = 5\) 时，方差项要求 1,250 轮，而异质性项占主导地位：

\[ \frac{\beta_{\text{het}}² E²}{R} \leq \epsilon \implies R \geq \frac{\beta_{\text{het}}² E²}{\epsilon} = \frac{2.25 \times 25}{0.01} = 5,625 \text{ rounds} \]

与 IID 情况相比，这代表通信轮数大约增加了 28.1 倍。非 IID 场景需要 5,625 × 10 × 5 = 281,250 个客户端-轮次，展示了数据异质性如何主导收敛成本。

对 \(E\) 的二次依赖表明当异质性高时应减少本地计算。将 \(E = 5\) 改为 \(E = 2\)，异质性项收缩至 900 轮，而方差项增长至 3,125 轮，因此方差项现在占主导地位：

\[ R \geq \max\left(\frac{(1+\beta_{\text{het}})²}{C \cdot E \cdot \epsilon²}, \frac{\beta_{\text{het}}² E²}{\epsilon}\right) = \max\left(\frac{2.5²}{10 \cdot 2 \cdot 0.0001}, \frac{2.25 \times 4}{0.01}\right) = \max(3,125, 900) = 3,125 \text{ rounds} \]

这以每单位本地计算 2.5 倍的通信成本为代价，将总轮数减少了 1.80 倍。总客户端-轮次变为 3,125 × 10 × 2 = 62,500，比 \(E = 5\) 的非 IID 情况减少了 4.5 倍。这说明了为什么基于估计的数据异质性进行自适应本地轮次选择能显著提高联邦学习效率。

通信-计算权衡

本地轮次与通信轮次之间的相互作用产生了一个基本的设计权衡，可视化见图 11.10。更多本地轮次降低通信频率（计算拉力）但增加客户端漂移（统计惩罚），而更少本地轮次在更高的通信成本下维持更紧密的同步。

图 11.10：通信-计算权衡：对于 IID 数据，增加本地轮次始终减少总通信量，惩罚极小。对于非 IID 数据，客户端漂移导致在最佳点（通常 \(E \in [2, 5]\)）之外收敛性能下降，使得激进的本地计算适得其反。系统设计师必须估算数据异质性以选择合适的工作点。

最佳工作点取决于部署特定因素。通信成本（带宽、能耗）倾向于更大的 \(E\)，而异质性下的收敛速度倾向于更小的 \(E\)。实际系统通常采用自适应策略，从较小的 \(E\) 开始，随着模型接近收敛和客户端漂移减小而增加 \(E\)。

联邦学习何时有效

联邦学习只有在多个部署条件有利时才能实现实际收敛，这是联邦学习系统综述和开放问题中强调的主题（Kairouz 和 McMahan 2021）：

• 异质性必须保持在有界范围内，使客户端漂移不会主导训练时间。当群体高度异质时，将客户端聚类为更同质的组或使用个性化可能比单一全局模型更可取。

• 客户端参与度必须足以提供稳定的聚合更新。极低的参与度会使梯度估计充满噪声并加剧选择偏差。

• 每个参与客户端需要足够的本地数据进行有意义的更新计算。极小的本地批次可能贡献高方差更新，破坏训练稳定性。

当这些条件被违反时，替代方法变得必要。严重异质性建议采用带有区域聚合的分层联邦学习或无全局聚合的完全个性化模型。极低参与率表明需要不需要同步轮次的异步协议。本地数据极少的客户端受益于少样本适应技术而非基于梯度的训练。

这些数学聚合协议证明了去中心化学习在理论上是可能的。在实验室里让联邦平均算法跑通十个可靠节点是小菜一碟；但在一千万部频繁掉线的智能手机上执行则是另一个工程问题。鲁棒的联邦系统必须从一开始就假设客户端不可靠，将算法转化为编排、调度和故障处理机制。

联邦学习：大规模系统

在教科书算法中，所有 100 台边缘设备完美计算更新并精确同时汇报给服务器。现实中，跨越一百万部智能手机的联邦学习轮次必须应对设备过热、断网、进入省电模式或关机。大规模构建联邦系统，意味着设计一个能容忍异步掉线和极端落后者作为标准运行条件的编排器。

客户端调度

联邦学习基于这样一个假设运行：客户端（持有本地数据的设备）定期可用于参与训练轮次。在真实系统中，客户端可用性是间歇性且可变的。设备可能关机、断电、无网络接入，或因其他原因在任何给定时间无法参与。因此，客户端调度在分布式学习的有效性和效率中起核心作用。

基础层面上，联邦机器学习系统定义参与资格标准。设备必须满足最低要求，如接入电源、连接 Wi-Fi 和处于空闲状态，以避免干扰用户体验或耗尽电池资源。这些标准决定了总体人口中哪个子集被视为任一给定训练轮次的“可用”设备。

除了这些操作过滤器，设备在硬件能力、数据可用性和网络条件上也存在差异。一些智能手机包含许多与当前任务相关的近期样本，而其他设备则拥有过时或无关数据。网络带宽和上传速度可能因地理位置和运营商基础设施而差异巨大。因此，随机选择客户端可能导致底层数据分布覆盖不足和模型收敛不稳定。

可用性驱动的选择引入了参与偏差。条件有利的客户端更有可能反复参与。这些有利条件包括频繁充电、高端硬件和稳定连接。同时，其他客户端系统性地被低估代表。这会使结果模型偏向特权人群的行为和偏好，引发公平性和泛化性担忧。

参与偏差的严重性在检查真实部署统计数据时变得明显。联邦学习部署研究表明，最活跃的 10% 设备可能贡献超过 50% 的训练轮次，而底部 50% 的设备可能从未参与。这形成了一个反馈循环：模型更强地针对拥有高端设备和稳定连接的用户进行优化，可能降低最需要适配的资源受限用户的性能。键盘预测模型可能偏向于拥有旗舰手机且夜间充电用户的打字模式，遗漏了使用预算设备或充电模式不规律用户的重要语言变体。

系统调度与客户端选择

为了应对这些挑战，系统必须在调度效率与客户端多样性之间取得平衡。关键方法包括使用分层或配额采样，确保不同群体的客户端都能代表性地参与。一些系统实施“公平预算”，追踪累计参与度，并在代表性不足的设备可用时主动优先调度。其他系统则采用重要性采样技术，根据预估的总体统计数据而非原始参与率来重新加权贡献。例如，基于异步缓冲区的技术允许参与客户端独立贡献模型更新，无需在每轮进行同步协调。该模型已扩展为融合陈旧感知和公平机制，防止过度活跃的客户端主导训练过程。

这些公平机制与自适应客户端选择策略相辅相成。联邦机器学习系统可优先选择数据类型代表性不足的客户端，针对采样频率较低的地理区域或人口统计特征，并利用历史参与数据强制执行公平约束。预测建模可预判客户端后续的可用性或成功率，从而提升训练吞吐量。

聚合与轮次同步

选中的客户端在其私有数据上执行一个或多个本地训练步骤，并将模型更新传输至中央服务器。这些更新被聚合以形成新的全局模型。通常采用加权聚合，即在平均前按各客户端训练时使用的本地样本数对其贡献进行缩放。这确保了拥有更具代表性或更大数据集的客户端对全局模型施加成比例的影响。

调度还必须限制一轮等待最慢参与者的时间。正如第 11.5.2.3 节所述，掉队者耗时可能是中位数设备的 10 倍，且在收到足够更新前，该轮无法进行聚合。

过度选择：在前 K 个更新到达时关闭轮次。

为防止全局模型更新停滞，生产级联邦学习系统采用过度选择。服务器选择的候选池大小 K_candidates 大于目标更新数 K_target（通常 K_candidates ≈ 1.3 × K_target）。服务器聚合前 K_target 个响应者的更新并丢弃其余。这种方法将轮次时长限制在 K_target 个最快设备的速度，而非绝对最慢设备，从而显著加快收敛的墙钟时间。

这些调度决策直接影响收敛速率、模型泛化能力、能耗及整体用户体验。不良调度会导致过多掉队者、对狭窄客户端片段过拟合或计算资源浪费。因此，客户端调度是联邦学习系统设计的核心组件，既需要算法洞察，也需要基础设施级的协调。

设计场景：千万级移动设备联邦学习系统

你正在为 1000 万台移动设备构建联邦学习系统。数据高度非独立同分布（用户拥有独特、聚簇的输入模式），网络环境受限（1-10 Mbps）。在为该场景选择优化方案前，请对本地瓶颈进行分类，并指出主导各决策的系统约束。

考虑三个设计决策：

1. 聚合：针对非 IID 人群，在标准 FedAvg、减少本地轮数、或个性化/聚类之间选择，并论证该选择如何控制客户端漂移。

2. 隐私：判断部署是否需要正式的差分隐私噪声，还是安全聚合和数据最小化已足以应对所述威胁模型；定性解释预期的收敛时间代价。

3. 通信：在受限带宽下，在梯度量化（如 8-bit）与结构化稀疏性之间选择，并论证带宽/精度权衡。

带宽感知的更新压缩

更新压缩首先是瓶颈诊断，而后才是技术选择：若每轮传输完整模型权重或梯度，移动端带宽和电量预算将在优化器生效前决定收敛。设计决策在于：哪些信息可被量化、稀疏化或保留在本地，同时保留足够的梯度保真度使 FedAvg 收敛。

压缩决策分为三个杠杆，各自作用于通信瓶颈的不同部分：模型压缩减少每次更新的比特数，选择性共享减少传输的参数，架构分区将私有状态保留在本地。如图 11.12 所示，模型压缩方法旨在通过量化、稀疏化或子采样减小传输更新的大小。客户端不再发送全精度梯度，而是传输 8-bit 量化更新，或仅传输幅度最大的前 k 个梯度元素。

选择性更新共享通过仅传输模型参数或更新的子集进一步降低通信量。在逐层选择性共享中，客户端仅更新特定层（通常为最终分类器或适配器模块），而冻结骨干网络的大部分。这既降低了上传开销，也减轻了共享表示对非代表性客户端数据过拟合的风险。

分离模型与架构分区将模型划分为共享的全局组件和私有的本地组件。客户端独立训练和维护私有模块，仅与服务器同步共享部分。这以最小的通信和隐私泄露实现了用户级个性化。

所有这些方法均在 FedAvg 聚合协议（第 11.5.2.2 节）框架内运行：压缩改变的是每个客户端传输的内容，而非服务器聚合更新的方式。虽然图 11.11 展示了本地计算与网络带宽的基本权衡，但其他通信高效更新引入了自身的权衡。压缩可能降低梯度保真度，选择性更新可能限制模型容量，分离架构可能增加协调复杂度。因此，有效的联邦学习需要在带宽约束、隐私顾虑和收敛动态之间审慎平衡，这种平衡高度依赖于客户端群体的能力和变异性。附录 D.5 节通过实例量化了压缩盈亏平衡阈值，计算给定压缩率节省的带宽何时超过因梯度保真度下降导致的精度损失。

图 11.11：联邦学习中的通信-计算权衡

随着网络带宽降低（从快到慢），最优本地轮数右移，以通过更多计算摊销高昂的通信成本。然而，过度的本地计算最终会因模型漂移（需要更多全局轮次收敛）而增加总耗时。

一旦系统确定本地计算量，更新压缩便决定了每轮必须传输的数据量。

图 11.12：梯度压缩技术：(a) 标准更新传输全精度数值。(b) 量化将数值映射到低精度桶（例如 FP32 到 INT8），从而降低带宽占用。(c) 稀疏化仅传输最显著的梯度，利用了许多更新接近于零这一特性。

联邦个性化

虽然压缩和通信策略提升了可扩展性，但它们并未解决全局联邦学习范式的一个重要局限性：无法捕捉用户特有的差异。在实际部署中，设备往往观测到截然不同且异构的数据分布。当“一刀切”的全局模型统一应用于多样化用户时，可能会表现不佳。这激发了对个性化联邦学习的需求，即在不损害全局协调优势的前提下，将本地模型适配至用户特定数据。

设 θ[k] 表示客户端 k 上的模型参数，θ[global] 表示聚合后的全局模型。对于 K 个客户端，传统 FL 寻求最小化一个全局目标：

\min_\theta \sum_{k=1}^K w_k \mathcal{L}_k(\theta)

其中 ℒk 是客户端 k 上的本地损失，w[k] 是加权因子（例如与本地数据集大小成比例）。然而，这种公式假设单一模型 θ 能很好地服务于所有用户。在实践中，不同客户端的本地损失地形 ℒ[k] 往往存在显著差异，反映了非独立同分布数据分布和多变的任务需求。

个性化修改了这一目标，允许每个客户端维护自己的适配参数 θ[k]，并针对全局模型和本地数据进行优化：

\min_{\theta_1, \ldots, \theta_K} \sum_{k=1}^K \left( \mathcal{L}_k(\theta_k) + \lambda_{\text{reg}} \cdot \mathcal{R}(\theta_k, \theta_{\text{global}}) \right)

此处，ℛ 是一个正则化项，惩罚对全局模型的偏离，λ[reg] 控制该惩罚的强度。这种公式允许本地模型按需偏离，同时仍能从全局协调中受益。

现实世界的用例阐释了该方法的重要性。试想一个可穿戴健康监测器，它追踪生理信号以对身体活动进行分类。虽然全局模型在人群中可能表现尚可，但个体用户展现出独特的运动模式、步态特征或传感器佩戴位置。对最终分类层或低秩适配器进行个性化微调可提升准确性，特别是针对罕见或用户特有的类别。

针对计算开销、隐私和适配速度之间的权衡，已涌现出多种个性化策略。一种广泛使用的方法是本地微调，即每个客户端下载最新的全局模型，并利用其私有数据执行少量梯度步骤。虽然该方法简单且保护隐私，但当全局模型与客户端数据分布错位严重，或本地数据集极其有限时，可能产生次优结果。

另一种有效技术涉及个性化层，即将模型划分为共享主干和轻量级的客户端专用头（通常是最终分类层）（Arivazhagan et al. 2019）。仅在设备上更新头部，从而降低内存占用和训练时间。当客户端间的主要差异在于输出类别或决策边界时，该方法尤为适用。

聚类联邦学习提供了一种替代方案，根据客户端数据或性能特征的相似性将其分组，并为每个簇训练单独的模型。该策略可提升同质子人群内的准确性，但引入了额外的系统复杂性，且可能需要交换元数据以确定组成员资格。

最后，元学习方法（如模型无关元学习 MAML²⁰⁵）旨在产生一个全局模型初始化，仅需少量本地更新即可快速适配新任务（Finn et al. 2017）。当客户端数据有限或处于频繁分布漂移的环境中时，该技术特别有用。