2471 字
约 8 分钟
6
S23-J26 · 服务启动、扩缩容与部署比较

适用读者:要设计上线/扩容/迁移流程、要回答"为什么加机器也要等 40 秒"、要做部署方案评审的人。
前置:S23-J24、J25(PD 分离、专家放置)、J12(训练容量)。
覆盖旧文:A-4342 §9.6–§9.7(启动扩缩容与故障恢复 + 部署方案综合比较,390 点)→ 390 点。
扩展点:E-S23-094(启动积压:3.5 req/s × 10 s = 35 条,排空 43 / 63 s vs 60 s 期限)、E-S23-095(追赶式复制:净速率 25 − 0.172 = 24.8 GB/s → 1.66 s)、E-S23-096(9 秒软件准备把 4× 网络提速压成 17%)、E-S23-097(四种部署组合的比较维度与"同质量同资源"判据)。
上一篇:S23-J25 · AFD、专家放置与 KV 分布
下一篇:S23-J27 · 训练容量估算与状态分片。


1. 一句话结论

扩容不是"加卡就变快",是"加卡后要等积压消退"。 3.5 req/s 的流量、10 秒启动,就积压 35 条;服务率 4.55 的配置在第 43 秒排空,4.17 的在第 63 秒——而期限是 60 秒。差 0.38 req/s 就决定这次扩容算不算成功。

出处:AI Infra 教材 §9.6–§9.7(id 4342)。

积压 = 到达率 × 启动时长
排空时间 = 启动时长 + 积压 / (服务率 − 到达率)

2. 启动与预热(E-S23-094)

连续流量模型:3.5 req/s,启动 10 秒 → 积压 35 条。

配置 服务率 排空时刻(从启动算) 60 s 期限内
直接 PD 4.55 req/s 第 43 秒 ✅
理想分块共置 4.17 req/s 第 62 秒 ❌(差 2 秒)
不分块共置 3.02 req/s 持续积压 ❌
排空 = 10 + 35/(4.55−3.5) ≈ 43 s
       10 + 35/(4.17−3.5) ≈ 62 s
       3.02 < 3.5 → 永远追不上

判据:"服务率 − 到达率"决定一切。 服务率贴着到达率时,启动积压几乎排不空;差 33% 就能在 43 秒内清完。

2.1 预热阶段的三个坑

坑 现象 处理
缓存预取抢空间 多个请求同时登记预取,后面的被限流 限并发预取、按优先级
"没缓存反而更快" 无命中的请求直接 prefill,先到先跑 不要把预取当日志,要当队列
权重版本与硬件绑定 新版权重需新卡 路由器按版本分派,预留双版本资源

判据:命中缓存 ≠ 能立刻用缓存,还要先拿到预取空间。这解释了"为什么先到的请求反而更慢"。


3. 运行中迁移:追赶式复制(E-S23-095)

迁走一张 H20 上的 D worker:32 条请求、平均上下文 8,704 → KV 41.1 GB;decode 1,166 次/s × 144 KiB/次 = 0.172 GB/s 增长。

链路 复制速率 净追赶速率 追上用时 期间新增
200 Gbit/s 网卡 25 GB/s 25 − 0.172 = 24.8 1.65 s 0.28 GB
50 GbE 6.25 GB/s 6.08 6.76 s 1.16 GB
追上后仍需"最后交接点":同时确定状态版本与执行权,防止漏掉源端最后更新
复制速率降到状态增长速率 → 两条曲线平行,初始积压永不缩小

判据:迁移时间 ≈ 初始状态 / (复制带宽 − 状态增长速率)。 对 decode 这种慢增长负载,几乎全由初始状态决定;对高频写入的负载,增长率本身会成为瓶颈。


4. 重配置与并行度切换(E-S23-096)

Qwen3-8B 从 TP4 切到 TP8:网络传输 16.4 GB + 本地构建目标张量 4.7 GB。

场景 传输时间 + 9 s 软件准备 合计
50 GbE(6.25 GB/s) 2.63 s 9 s 11.6 s
200 Gbit/s(25 GB/s) 0.66 s 9 s 9.7 s
机内 NVLink(300 GB/s,单卡 4.7 GB) 15.7 ms 9 s 9.0 s
带宽 4× → 总时间只从 11.6 降到 9.7 s(−17%)
即使传输趋零,下限仍是 9 s

判据:软件准备(建通信组、捕获执行图、恢复接流)成了新的主项。 这不是换链路能解决的,只能"提前建组、预捕获图、把准备与传输重叠"。

代价:预存两套权重与执行图会挤占 KV 空间——迁移能力与并发能力要一起算。


5. 故障恢复:三种目标(§9.6.3)

目标 做法 风险
继续 decode 用已保存状态 + 已确定 token 续算 需精确知道"用户收到哪一段"
重做 prefill 按已确定 token 重算上下文 长上下文成本高(J21 的重计算)
重新采样 从头再随机一次 后缀可能不同(RL rollout 变了样本)

判据:先定"用户已经看到什么",再定恢复策略。 流式生成的"已确认前缀"是恢复的唯一锚点。


6. 四种部署组合的综合比较(E-S23-097)

方案 组成 优势 代价 适用
① 多卡实例 8 卡一个实例 容量、单请求延迟 伸缩粒度粗 大模型单实例
② 完整副本 每副本独立 吞吐线性、故障隔离 权重多份、KV 不共享 中小模型高并发
③ PD 分离 P 池 + D 池 阶段异构匹配、间隔稳定 交接 48 ms 级、整数划分损失 长输入 + 长输出
④ 专家分离(AFD) 注意力池 + 专家池 专家扩容独立 每层 All-to-All 大 MoE

6.1 "同质量、同资源"比较法(评审清单)

# 问题 不通过
1 两方案的 SLO 相同吗(TTFT / 间隔 / p99) 指标不同不能比
2 总卡数、总显存、总带宽相同吗 资源不同不能比
3 是否都算上交接与重配置开销 漏算会高估
4 故障域多大(一个副本挂影响多少请求) 越大越危险
5 扩容粒度(几张卡一跳)与启动时长 粒度粗 → 积压久
6 版本升级能否灰度、能否回滚 不能灰度 → 风险高
7 观测面:TTFT、间隔、KV 命中、队列长度 缺指标无法验收

7. 负载变化后的调整(§9.7.3)

变化 首选动作 不要做
到达率上升 20% 加 D 副本(若 D 是瓶颈) 无脑加 P
输入变长 分块 prefill + 扩 P 只加 D
输出变长 扩 D、开投机(低负载) 扩 P
长尾变差 查 KV 命中与队列、拆故障域 只看平均延迟

判据:先定位瓶颈池,再决定扩哪个池。 扩错池只会增加成本,不改善 SLO。


8. 可复算(实测)

$ cd /root/博客运营官/blog-v2 && python3 tools/s23_book_calc.py | tail -9
启动积压: 3.5 req/s × 10 s = 35 条
  排空: 4.55 → 43 s(期限 60 s)
  排空: 4.17 → 62 s(期限 60 s)
  排空: 3.02 → 永不排空(服务率 ≤ 到达率)
迁移(32 请求 × 8704 → 41.1 GB KV,增长 0.172 GB/s)
  25 GB/s: 净 24.83 → 1.66 s(新增 0.28 GB)
  6.25 GB/s: 净 6.08 → 6.76 s(新增 1.16 GB)
原地迁移 TP4→TP8(16.4 GB + 4.7 GB 本地)
  50 GbE 6.25 GB/s: 2.62 + 9 = 11.6 s
  200 Gbit/s 25 GB/s: 0.66 + 9 = 9.7 s
  NVLink 300 GB/s: 15.7 ms + 9 = 9.0 s

9. 前提与边界

结论 成立条件 不成立时
积压 = λ×启动时长 连续流量、固定启动时间 突发流量 → 峰值更高
排空公式 服务率 > 到达率 服务率 ≤ 到达率 → 永不排空
追赶复制 1.65 s 增长速率恒定、链路独占 链路共享/抖动 → 更久
迁移下限 9 s 软件准备串行 预建通信组 → 可降

10. 常见误区

误区 纠正
"加卡就会立刻变快" 先要排空启动积压(43 s 起)
"缓存命中就一定快" 还要抢到预取空间
"带宽翻倍迁移就快一倍" 9 s 软件准备把 4× 压成 17%
"故障后从上次 token 继续就行" 要先确认用户已收到哪一段
"扩 P 和扩 D 一样" 扩错池只涨成本

11. 自测

  1. 3.5 req/s、启动 10 s,积压多少?服务率 4.17 时排空用时?
  2. 41.1 GB 状态、增长 0.172 GB/s、复制 25 GB/s,追上要多久?
  3. TP4→TP8 迁移,传输 16.4 GB,50 GbE 与 200 Gbit/s 各多久?加 9 s 准备后差多少?
  4. 评审"同质量同资源比较"时,必须对齐哪几项?
答案
  1. 35 条;10 + 35/(4.17−3.5) ≈ 62 s。
  2. 41.1/(25−0.172) ≈ 1.66 s。
  3. 2.63 s vs 0.66 s;加 9 s 后 11.6 vs 9.7 s(只差 17%)。
  4. SLO、总资源、交接开销、故障域、扩容粒度、灰度回滚、观测指标。

12. 下一篇

S23-J27 · 训练容量估算与状态分片 —— 进入第 10 章:一次训练步要多少显存、参数/梯度/优化器状态怎么切,以及 ZeRO 三级的真实通信账。

S23-J26 · 服务启动、扩缩容与部署比较
https://www.clxhxhhr.top/posts/5553/
作者
clxstart
发布于
2024-12-31
许可协议
CC BY-NC-SA 4.0
评论
0 条
还没有评论,先写一条吧。