4.2 多节点集群部署：跨机器扩展与那些躲不开的坑

4.2 多节点集群部署：跨机器扩展与那些躲不开的坑

当单节点 TP 开满、量化也用上、并发甜点已到，吞吐还是顶不住你的流量，或者模型权重单节点根本放不下——这时你才真正需要多节点。4.1 我们解决了「一台机器跑满」，这一节解决「多台机器协同」。跨节点带来的不是线性加成，而是一堆新约束：网络、负载均衡、容量规划。我会把这些坑一个个摆出来，并给出应对。

什么情况下才该上多节点

先泼盆冷水：多节点是复杂度的大跳跃，不是吞吐的免费倍增器。 在动它之前，确认单节点的潜力真的榨干了：

• TP 已开满（单节点卡数），EP 已用于 MoE 专家切分；
• gpu_memory_utilization 已到安全上限（约 0.9~0.95）；
• 量化已用（BF16→FP8/INT8），KV 预算已最大化；
• 并发甜点已找到，但吞吐仍不满足，或权重单节点放不下。

只有这四条都满足了，才引入 PP 跨节点扩容。否则，多节点大概率让你同时承担「跨节点通信损耗 + 调度复杂度 + 故障面扩大」，却换不来对等收益。

两种跨节点思路：扩容 vs 副本

多节点不是只有一种玩法，本质上有两条路线，目标不同：

1. 纵向扩容（scale-up 模型）：单个模型放不下，用 PP 把层切到多机，或继续加大 EP 把专家铺到更多卡。目的是「跑得下更大的模型 / 更高并发」。
2. 横向副本（scale-out 服务）：模型单节点放得下，但为了扛更多流量、提高可用，起多个完全相同的单节点实例，前面挂负载均衡。目的是「扛量 + 容错」。

绝大多数高并发服务场景，我更推荐横向副本而非纵向扩容：副本之间互不通信、没有跨节点 All-Reduce/All-to-All，延迟可控、扩容线性、挂一个不影响整体。纵向扩容（PP 跨机）只在「单节点硬放不下」时才是必选项，而且要接受尾延迟上升。

纵向扩容：PP 跨节点的真实代价

如果必须纵向扩（PP 跨机），记住第三章讲过的铁律：PP 靠点对点激活传递，通信频率低，所以吃得消跨节点；但 PP 有流水线气泡，直接拉高 P99。 落地时的几个判断：

• PP 的通信量小，节点间用普通 RDMA/以太也能跑，不强制 NVLink。这是它适合跨机的根本原因。
• 气泡随 PP Stage 数增加而放大。PP=2 的气泡尚可接受，PP=4 以上尾延迟会明显难看。所以纵向扩容尽量「刚好够切」，别为了显存无限堆 PP。
• TP 和 EP 仍然必须留在单节点 NVLink 域内。一旦把 TP8 跨节点拉成「逻辑 16 卡」，每层 All-Reduce 要走节点间网络，吞吐会断崖。

一个典型形态（参数名以实际版本为准）：单节点内 TP=8，跨两节点用 PP=2，MoE 专家在节点内做 EP。即「节点内 TP+EP 打底，跨节点 PP 兜底」。

横向副本：负载均衡与容量规划

横向副本看似简单（多起几个 4.1 的配置），但真正上线有三件事必须想清楚，否则就是「部署了等于没部署」：

第一，负载均衡策略。 多个实例前面挂一个 LB。最稳的是「最少连接」或带权重轮询；但 LLM 请求长短极度不均（有的 50 token 有的 8000 token），纯轮询会让某实例被长请求占满、短请求排队。我建议 LB 层能感知「在途 token 数」最好，退而求其次用最少连接。绝对不要用「随机」——高并发下随机会把长请求撞在一起。

第二，容量规划。 单实例稳态并发若约 256（见 4.1 甜点），要扛 2000 QPS 峰值，粗略需要 2000/256 ≈ 8 个实例的产能，再乘 1.3~1.5 冗余应对突发和故障。容量不是拍脑袋，是用 4.1 的压测拐点算出来的。

第三，KV 与状态的去留。 无状态实例最易扩：每个请求自带上下文，副本间不共享 KV。若你用了前缀缓存共享之类跨实例优化，那副本间就有状态耦合，扩容和故障切换会变复杂——这超出了基础部署范畴，按需评估。

跨节点绕不开的网络与故障

多节点把「网络」从背景项变成主角。几条实战经验：

• 先量节点间带宽再定并行。 节点间带宽通常只有节点内 NVLink 的几十分之一。如果你被迫把 TP/EP 跨节点，先量带宽，大概率会发现通信吃掉大部分并行收益——这时该回头用 PP 而非 TP 跨机。
• 健康检查与优雅下线。 副本模式下，LB 必须有真实健康检查（不是 TCP 通就行，要能探推理是否真的活着），且扩缩容要优雅排水，别在请求中途杀实例。
• 故障面是乘数的。 单节点挂了影响一片；多节点里一个节点网络抖动，可能让依赖它的 PP Stage 全链路卡住。纵向扩容尤其脆弱，所以能用副本就别用 PP 跨机当主力。

一个容量规划的小算例

把抽象讲成具体。假设业务峰值 3000 QPS，平均请求长度 1500 token（含输入+输出），单实例在甜点并发下实测吞吐 1600 tok/s、稳态并发 256。那么：

• 单实例每秒能消化的请求数 ≈ 1600 / 1500 ≈ 1.07 请求/s（注意这里用 token 吞吐折算请求数，取决于平均长度）。
• 需要实例数 ≈ 3000 QPS / 1.07 ≈ 2800... 这里暴露一个常见误算：QPS 是请求数，token 吞吐是 token 数，二者要用平均请求 token 数换算。若平均每个请求 1500 token，3000 QPS 即 4.5M tok/s 的需求，远超单实例 1600 tok/s——这说明「3000 QPS 且每请求 1500 token」需要约 4.5M/1600 ≈ 2810 实例，显然不可能，真实业务里要么平均长度没这么高，要么需要更小上下文+更短输出。

这个算例的用意不是给数字，而是提醒你：容量规划必须在同一个量纲（token/s）下对齐需求和产能，别把 QPS 和 tok/s 直接相除。我见过的最多翻车就在这里——以为 8 个实例能扛，结果量纲错配，上线即雪崩。

纵向扩容的替代思路：请求分类路由

除了 PP 跨机，还有一种常被忽视的纵向思路值得提一句：当模型权重单节点放不下，但你又不想引入 PP 的气泡，可以考虑把不同负载路由到不同规格的部署。例如把「长上下文、慢推理」的请求路由到显存更大的少数大实例，把「短平快」请求路由到密集的小实例。这本质上是用 LB 层的请求分类，替代了模型内部的复杂切分。它的代价是路由逻辑变复杂，但避开了 PP 跨机的尾延迟陷阱。是否采用，取决于你的流量是否天然可分类。

横向副本的灰度与回滚

多副本上线不能「一把梭」。我建议的节奏是：新配置先以单副本灰度接 5%~10% 流量，盯住 TTFT/P99 和错误率，确认无回归再逐步放量；同时保留旧副本可随时切回。LLM 服务的回归往往隐蔽（不是直接报错，而是长尾变慢、质量略降），所以灰度期要足够长、指标要足够细，别只看均值。

多节点下的可观测性基线

节点多了，单看某个实例的监控会盲人摸象。起码要有一层聚合视图：

• 全局 QPS 与错误率：LB 层或网关聚合，第一时间发现整体劣化。
• 各实例负载分布：看 LB 是否真的把请求铺匀，有没有某实例长期高载（说明路由策略或实例规格不均）。
• 跨节点通信指标（纵向扩容时）：PP Stage 间激活传递的延迟、是否有节点成为瓶颈。

没有这层聚合，多节点出问题你会花数倍时间定位——而高并发故障的每一分钟都是真金白银。

成本视角：多节点不是免费的

最后泼一盆现实的冷水：多节点最容易被忽略的代价是钱。横向副本意味着成倍的计算资源常驻，纵向扩容意味着跨机通信和更长尾延迟换来的产能。落地前请算一笔账：你要扛的流量，值不值得为此常驻 N 台机器？很多时候，「把上下文砍一半」「把输出限个长度」「非实时请求走异步队列」这类产品侧改动，比加机器便宜得多，也稳得多。部署者的成熟，往往体现在「先问能不能少花，再问怎么多花」上。

多节点部署的判断清单

给你一份落地前的自查清单，逐条过完再动手：

1. 单节点潜力是否真正榨干（TP满、量化、并发甜点已定）？
2. 是「放不下」（→纵向 PP/EP）还是「扛不住量」（→横向副本）？
3. 若横向副本：LB 策略、容量余量、健康检查是否齐备？
4. 若纵向扩容：PP Stage 数是否克制在气泡可接受范围？TP/EP 是否仍留在节点内？
5. 节点间带宽是否实测，足以支撑所选并行方式？
6. 容量规划是否在同一量纲（tok/s）下对齐需求与产能？
7. 副本上线是否有灰度与回滚机制？是否有聚合可观测视图？

一句话带走：多节点是单节点潜力的延伸而非替代——先用副本扛量、保可用，只有权重硬放不下才上 PP 跨机，并且永远把 TP/EP 留在节点内 NVLink 域、把跨机通信留给 PP 和 LB。至此，从单节点到集群的完整实战范式就齐了，第五章我们做个收束与展望。

4.2 收尾：多节点的核心判断

多节点这一节，最该刻进脑子的是「先副本、后纵向」这六个字。副本用资源换线性可扩和容错，几乎无通信代价；纵向扩容（PP 跨机）是放不下时的无奈之举，要拿尾延迟去换。至于容量规划，永远记住那个量纲陷阱：需求用 tok/s，产能也用 tok/s，别拿 QPS 去除以 tok/s。把这三件事想透，你已经能撑起绝大多数生产级 DeepSeek V4 部署了。

顺带一句：当你真正在多节点上跑起 DeepSeek V4，会发现监控、告警、容量三者是绑定的——监控告诉你现在怎样，告警告诉你何时该扩，容量规划告诉你扩多少。这三者缺一，多节点就只是「看起来很美」的摆设。所以本章反复强调的 LB、健康检查、聚合视图、灰度回滚，从来不是可选项，而是多节点能稳定活下来的底线。

还有一点容易被忽略：多节点部署的「可观测性」和「可回滚」不是锦上添花，是上线前提。没有聚合监控，你会在故障里盲人摸象；没有灰度回滚，一次坏配置就能把整片服务拖垮。把这两样在动手第一天就建好，比事后救火划算一万倍。这也是我从几次线上事故里用真金白银换来的教训——部署的成熟度，往往不取决于你把模型跑得多快，而取决于出事时你能多快看清、多快恢复。