GLM-5.3 推理全链路（十九）：负载账本与慢 rank——路由把请求分给谁，谁就决定下一步的时钟

这一篇接在哪

前十八篇沿着一条 GLM-5.3 请求，把 GPU 上的 78 层、跨卡的四类集合通信、PD 分离的数据面与控制面、MTP 的三段前向，以及 CPU 侧的重叠调度都拆开看了一遍。那些账本有一个共同的前提：这条请求落在哪一个 rank 上，是给定的。第三篇算分块预填的预算，按「一个 prefill 实例」算；第六篇算 DeepEP 的 dispatch 字节，按「EP 组内每张卡收多少 token、按最慢的接收方计」，却没有问这批 token 是从哪几条请求来的；第十六篇算一条 decode step 的 kernel 数，按「batch 32、每卡 4 条请求」算。账本里没有出现的问题是：这 4 条请求为什么是这 4 条？如果同一时刻某张卡上堆了 12 条、另一张卡上只有 2 条，账本会变成什么样？

对 GLM-5.3 这种部署形态，这个问题不是边角料。SGLang 文档给出的 DPA + EP 推荐形态是 --tp 8 --attn-dp-size 8 --ep 8（GLM-5.3 还要在此基础上打开 DSA 与 MTP 的开关，第三篇列过完整命令）：注意力按请求分片到 8 个 DP rank，每个 rank 只算自己那几条请求的 DSA 与 MLA，各自维护自己的 KV Cache；但每层 MLP 之前要把 8 个 rank 的 hidden state 按全局 token 数拼起来（dp_gather），MoE 之后再按归约结果散回去（dp_reduce_scatter）。这两次集合通信的执行时间，按 8 个 rank 里最慢的那个 计时；而一个 rank 的快慢，直接取决于它手里有几条请求、这些请求的上下文有多长。于是「路由把请求给谁」这个发生在 CPU 上的决策，会通过每层两次的集合通信，变成 GPU 上一条所有 rank 都要等的时钟。

这一篇要回答的就是这一段：负载账本从哪里来、路由怎么据此分配请求、账本失真时会发生什么，以及当某张卡真的慢下来时，延迟怎样从一张卡扩散成全服务的尾延迟。前十八篇把「请求经过哪些算子、哪些通信」讲完了，这一篇补的是「这些算子和通信在哪个 rank 上发生，以及为什么是那个 rank」。

关于与第十八篇末尾预告的关系：那一篇写「下一篇将讨论进程间的那一段控制面」。逐条走完 tokenizer 进程、router、EngineCore 与前端之间请求路径的是第十篇与第十三篇；本篇不再重复消息怎么走，而是只看控制面里 与负载有关的那几条通知——负载快照、健康检查、调度统计，以及它们如何在时间上失真。

先把「慢 rank」这件事定义清楚

「慢」有三种完全不同的含义，混在一起谈会得出错误结论：

• 单点慢：某个 rank 的硬件或进程状态异常，比如某张卡降频、某条 NVLink 链路劣化、某个进程被其他任务抢了 CPU。这种慢是持续的、与请求无关的。
• 负载慢：所有 rank 的硬件一致，但请求分配不均。手里有 12 条请求的 rank，每步要读 12 条请求的 KV、算 12 条请求的注意力，自然比只有 2 条请求的 rank 慢。这种慢是瞬时的、与路由决策直接相关。
• 结构慢：慢来自并行策略本身。比如 EP 组内某个专家的 token 数远高于其他专家（专家热点），或者 MoE 的 dispatch 在某个接收方排队。这种慢与「哪张卡」关系不大，而与「这一批 token 的路由结果」有关。

三种慢在集合通信里的表现是一样的：所有 rank 等最慢的那个。但它们的解法完全不同——单点慢要换卡或隔离节点，负载慢要改路由与调度，结构慢要改并行布局或加冗余专家。负载账本只能解决第二种，而它恰好是最常见、也最容易被观测到的一种。

先给一个量级，而且要区分「总量」与「本地时间」。第十六篇算过 GLM-5.3 在 batch 32、8 卡 DP Attention + EP8 下一次 decode 的 GPU 侧时间约 30ms，其中 MoE 的权重读取约 19ms。这 19ms 是 gather 之后、所有 rank 都要读的全局权重总量——dp_gather 把 8 个 rank 的 hidden 拼成全局 batch，MoE 的权重读取量取决于全局 token 数而非某个 rank 的本地 token 数，所以 MoE 这一段的耗时对负载偏斜 不敏感：rank 之间怎么分，总 token 都是 32 行，权重都要读一遍。

真正对偏斜敏感的是 gather 之前的本地注意力。设正常时每卡 4 条请求、本地注意力 2ms；若某张卡堆到了 12 条，它的本地注意力按行数与 KV 读取量大约涨到 6ms，而其他 7 张卡只用了 1ms。此时 dp_gather 要等多 5ms，78 层累计约 390ms：一条 decode step 从 30ms 量级变成 400ms 量级。这个放大不是线性的百分之几十，而是「层数 × 每层等待」。反过来，如果偏斜发生在 token 层面（比如某卡多了一条 100K 上下文的请求），那么它对 MoE 的总量也有影响，但影响是加性的——全局多出 1 行 token，MoE 多读一行，而不是某张卡单独拖住所有人。

这两者的区别决定了排障方向：本地注意力偏斜会通过 gather 变成全员等待，MoE 总量增加只是匀速变慢。下面所有关于「慢 rank」的讨论，默认都是前者。

部署拓扑：谁在给谁分请求

先把参与者摆清楚。GLM-5.3 的单机 8 卡部署下，一条请求在到达 GPU 之前要经过三个可能做「分配」决策的地方：

1. 前端 router（SGLang Router，或多 tokenizer 模式下的主进程）。若部署了多个 worker（多机、或多实例），router 决定这条请求去哪个 worker。router 能看到的是每个 worker 通过 HTTP 暴露的负载指标。
2. DataParallelController（DPC）。单机 8 卡、attn_dp_size=8 时，DPC 是一个独立进程，从 tokenizer 进程收请求，再按负载均衡策略把请求推给 8 个 DP rank 各自的 scheduler。
3. 每个 DP rank 的 scheduler。它决定这一步跑哪些请求、分多少 token 预算、要不要抢占（retract）。这一层不改变「请求属于哪个 rank」，但会改变「这个 rank 这一步有多忙」。

三层里，第二层是 GLM-5.3 特有的、也是本篇的重点：DP Attention 让「请求到 rank 的映射」变成了一个显式的、可配置的决策，而不是 TP 下那种「所有 rank 都算同一批请求」的隐式复制。官方文档对这一点的描述很直接：DPA 让每个 DP 副本「独立处理不同的 batch，可以处在不同的前向模式（prefill、decode 或 idle），并维护自己的 KV Cache」，这也正是它对 MLA 模型收益最大的原因——MLA 只有一个 KV 头，用 TP 切成 8 份时每张卡都存一份重复的 KV，切不出内存收益。

下图是第三篇与第六篇用过的 decode 拓扑，这里换个角度看：注意力区是「按请求切分」，MLP 区是「按专家切分」，两次集合通信把两块拼起来。

这张图里，dp_gather 和 dp_reduce_scatter 是两条横跨 8 个 rank 的粗箭头。它们的存在意味着：rank 之间的本地工作量差异，不会被流水线吸收，而是直接变成同步等待。TP 的 AllReduce 也是这样，但 TP 下每个 rank 算的是同一批 token 的不同头，负载天然一致；DP Attention 下每个 rank 算的是不同请求，负载天然不一致。这就是为什么 DP Attention 必须配一个负载均衡器，而 TP 不需要。

负载账本为什么能当锁的同步点：MLP 同步批次

在讲快照与路由之前，必须先把「每层都要对齐」这件事的代码落点看清楚。SGLang 每次要跑 MLP 的 step，都会先走一遍 prepare_mlp_sync_batch（scheduler_components/dp_attn.py），它构造一个 MLPSyncBatchInfo，把各 rank 这一步的「形状」用一个 11 列的整数张量打包，然后做一次 all-gather：

1
def _get_local_tensor(self, device, dtype=torch.int64) -> torch.Tensor:
2
    return torch.tensor(
3
        [
4
            self.num_tokens,
5
            self.num_tokens_for_logprob,
6
            int(self.can_run_decode_cuda_graph),
7
            int(self.is_extend_in_batch),
8
            int(self.local_can_run_tbo),
9
            self.local_forward_mode,
10
            int(self.can_run_prefill_cuda_graph),
11
            self.prefill_cuda_graph_max_prefix_len,
12
            int(self.can_run_draft_cuda_graph),
13
            int(self.is_health_check),
14
            self.attention_pairs,
15
        ],
16
        device=device,
17
        dtype=dtype,
18
    )

前两列是 token 数，第四列是「本批是否含 extend」，第五列是 TBO 可行性，最后两列是健康检查标记与因果注意力对数（attention_pairs）。all-gather 之后，每个 rank 拿到一个 [num_dp_ranks, 11] 的 CPU 张量，再由 tp0_info_cpu[:, k] 解出全局视图：

1
tp0_info_cpu = global_info_tensor.cpu()[:, 0, :]
2
self.tp0_info_cpu = tp0_info_cpu
3
self.global_num_tokens = tp0_info_cpu[:, 0].tolist()
4
self.can_run_decode_cuda_graph = bool(tp0_info_cpu[:, 2].min())
5
self.is_extend_in_batch = bool(tp0_info_cpu[:, 3].max())
6
...
7
self.global_attention_pairs = tp0_info_cpu[:, 10].tolist()
8
self.sync_wait_seconds = time.perf_counter() - sync_start

几处设计值得单独讲：

• collective 用 min 还是 max 是有讲究的。 can_run_decode_cuda_graph 取 min（只要有一个 rank 不支持图捕获，整步都不用图，否则那个 rank 会以不同图形状参与同一批前向），is_extend_in_batch 取 max（只要有一个 rank 含 prefill，整步就是混合模式），can_run_prefill_cuda_graph 取 min，prefill_cuda_graph_max_prefix_len 取 max。这不是抄随手，而是「所有人必须走同一条代码路径」的强制约束：图捕获要求形状固定，混合模式要求所有 rank 都按 extend 的图跑。
• 这一列的 all-gather 发生在调度器线程上，默认走 CPU 侧通信（gloo 的 cpu_group）。 代码在选 group 时有分支：如果关闭重叠调度、或显式设置 SGLANG_NCCL_ALL_GATHER_IN_OVERLAP_SCHEDULER_SYNC_BATCH，就走设备组；否则走 tp_group.cpu_group。原因很实际：重叠模式下调度器要在 GPU 前向还在跑的时候发出下一批，如果这个 gather 也排在 forward stream 上，它就要等前向结束，重叠就白做了。
• sync_wait_seconds 被记录了下来，并且在 observe_dp_balance 里以直方图 sglang:dp_attention_sync_wait_seconds 暴露。注释写得很清楚：在 gloo 路径（重叠调度的默认）上，这个时间就是「等最慢 rank 到达 gather」的时间。这就是本篇最重要的观测指标——它把「负载偏斜变成了多少等待」直接量化了。

gather 之后还有一个连带决策：要不要给某个空闲 rank 造一个 idle batch。prepare_mlp_sync_batch_raw 里：

1
need_idle_batch = max(mlp_sync_info.global_num_tokens) > 0
2
batch_to_gather = local_batch
3
if need_idle_batch:
4
    if local_batch is None:
5
        batch_to_gather = local_batch = get_idle_batch()
6
    ...

含义是：只要别的 rank 这一步有活干，本 rank 就算没请求，也必须造一个 0-token 的 batch 参与 gather 与后续的集合通信，否则 DP 组会在通信点死锁。dp_attention_steps_total 里专门有 rank_state="idle" 这个标签来统计这种「只为锁步而跑」的步。对 GLM-5.3，这意味着 一条请求进入某个 rank 时，不仅占用了那个 rank 的时间，还让其余 7 个 rank 进入每一步都要同步的状态——第八篇把前七篇的算子与字节压进一条时间线，本篇补上的是那条时间线里「谁必须陪谁一起跑」的这一层。

还有一处与负载直接相关的联动：maybe_convert_decode_to_extend。当 gather 发现「某个 rank 本步有 extend」时，纯 decode 的 rank 会被改写成一个 extend 视图，好让整步复用 extend 的图；但它有一个前提——min(global_tokens) 不为 0 且有 rank 不支持 extend 图时就不转换。注释直白地写了理由：An idle rank makes the prefill runner reject replay for every rank。也就是说，只要有 rank 空闲，整步就从图捕获退回 eager。负载极度不均时（一条请求 + 七个空 rank），这不只是多等几毫秒，还会让所有 rank 失去 CUDA Graph 的收益。

负载账本的第一层：SGLang 的 LoadSnapshot

1
waiting_queues = [self.get_waiting_queue()]
2
pending_token_queues = [self.get_waiting_queue()]
3
if self.disaggregation_mode == DisaggregationMode.PREFILL:
4
    prefill_bootstrap_queue = self.get_disagg_prefill_bootstrap_queue().queue
5
    waiting_queues.append(prefill_bootstrap_queue)
6
    pending_token_queues.append(prefill_bootstrap_queue)
7
elif self.disaggregation_mode == DisaggregationMode.DECODE:
8
    decode_prealloc_queue = self.get_disagg_decode_prealloc_queue().queue
9
    decode_transfer_queue = self.get_disagg_decode_transfer_queue().queue
10
    decode_retracted_queue = self.get_disagg_decode_prealloc_queue().retracted_queue
11
    waiting_queues.append(decode_prealloc_queue)
12
    waiting_queues.append(decode_transfer_queue)
13
    waiting_queues.append(decode_retracted_queue)
14
    pending_token_queues = [decode_prealloc_queue, decode_retracted_queue]
15
    awaiting_kv_tokens = sum(
16
        req.seqlen
17
        for queue in (decode_prealloc_queue, decode_transfer_queue)
18
        for req in queue
19
    )

1
def read_all(self) -> list[LoadSnapshot]:
2
    if not self._attach():
3
        return []
4
    with file_lock(self.fd, fcntl.LOCK_SH):
5
        loads = []
6
        ...

1
def update_budget(self, loads):
2
    for load in loads:
3
        if load.timestamp == self.last_timestamp[load.dp_rank]:
4
            continue
5
        self.last_timestamp[load.dp_rank] = load.timestamp
6
        self.total_requests[load.dp_rank] = (
7
            load.num_running_reqs + load.num_waiting_reqs
8
        )
9
        self.total_tokens[load.dp_rank] = load.num_total_tokens

路由决策：预算、投机加一与 20ms 节流

1
class LoadBalanceMethod(Enum):
2
    ROUND_ROBIN = auto()
3
    FOLLOW_BOOTSTRAP_ROOM = auto()
4
    TOTAL_REQUESTS = auto()
5
    TOTAL_TOKENS = auto()

1
def dispatch(self, method: LoadBalanceMethod, estimated_tokens: int = 0):
2
    if method == LoadBalanceMethod.TOTAL_REQUESTS:
3
        target_rank = self.total_requests.index(min(self.total_requests))
4
    elif method == LoadBalanceMethod.TOTAL_TOKENS:
5
        target_rank = min(
6
            range(self.num_dp_ranks),
7
            key=lambda i: (self.total_tokens[i], self.total_requests[i]),
8
        )
9
    else:
10
        return None
11
    # Increment the load of that worker by one as a heuristic
12
    self.total_requests[target_rank] += 1
13
    self.total_tokens[target_rank] += estimated_tokens
14
    return target_rank

1
def refresh_load_budget(self):
2
    # Throttle to at most once per 20ms.  When a burst of requests
3
    # arrives, dispatching_with_trace() calls this before every
4
    # dispatch.  Each call reads the latest scheduler snapshot and
5
    # overwrites the speculative +1 increments that DPBudget.dispatch()
6
    # added for previously dispatched requests in this burst.  Without
7
    # throttling, the budget resets to the (stale) scheduler-reported
8
    # value on every request, causing the entire burst to land on a
9
    # single DP rank.  The 20ms interval lets the burst complete
10
    # using speculative counters, then refreshes from the real
11
    # scheduler load for the next batch.
12
    now = time.perf_counter()
13
    if now - self._last_refresh_time < 0.02:
14
        return
15
    self._last_refresh_time = now
16
    self.dp_budget.update_budget(self.load_snapshot_reader.read_all())

1
def dispatch_batch_generate(self, batch_req: BatchTokenizedGenerateReqInput):
2
    has_user_request = any(
3
        not is_health_check_generate_req(req) for req in batch_req
4
    )
5
    if has_user_request and self.refresh_load_budget_on_dispatch:
6
        self.refresh_load_budget()
7
    for req in batch_req:
8
        self.dispatching_with_trace(req, refresh_load_budget=False)

1
def get_num_waiting_uncached_tokens(self) -> int:
2
    ...
3
    for req in self.get_waiting_queue():
4
        if waiting_queue_prefix_matched:
5
            matched = req.num_matched_prefix_tokens
6
            uncached = max(0, req.seqlen - matched)
7
            ...
8
        else:
9
            # The historical hit rate already includes admitted storage hits.
10
            uncached = int(req.seqlen * cache_miss_rate)
11
        num_tokens += uncached

当账本失真：三种偏斜如何变成等待

偏斜三：专家热点与结构慢

MoE 的 dispatch 是另一条同步链。第六篇讲过 DeepEP 的两种模式与 combine 后的 reduce-scatter；从负载角度看，热点专家会让某个 rank 的 GEMM 变长，而 all-to-all 的完成时间取决于最慢的接收方。GLM-5.3 每个 token 激活 8 个专家、共 256 个专家、EP8 下每卡 32 个专家；如果某一批 token 大量路由到同一组专家，持有这些专家的 rank 就要算更多行，其他 rank 等它。DeepEP 的低延迟模式用固定容量与 masked 布局把这个差异「摊平」成固定形状的 GEMM——代价是算力浪费，收益是 时间可预测。第十六篇的 launch 账本里，decode 的 MoE 是约 19ms 的大头，正是因为这部分被设计成固定形状，才让每步时间稳定。

这张图与本文的关系是：masked 布局把「哪个专家收到多少 token」这个随路由变化的部分，变成了固定形状里的一段有效行，从而切断了「专家热点 → 形状变化 → 时间变化」这条链。但它切不断另一条链：每张卡本地 token 数不同 → 本地注意力时间不同 → gather 等待。前者靠布局设计，后者只能靠路由与调度。

结构慢无法靠路由解决。能做的只有三件事：换更细的专家切分（EP16/EP32，每卡专家更少、热点更分散）、加冗余专家（redundant experts，把热点专家复制到多张卡）、或者在 batch 组装时按专家负载做 token 重排。这三件都不在本篇的负载账本范围内，但要知道它们存在——否则会误以为「路由均衡了，慢 rank 就没了」。

另一套账本：vLLM 的 wave、请求计数与前端打分

vLLM 的 DP 与 SGLang 有一个结构性差异要先说清楚：vLLM 的 DP 只在 MoE 模型上走「锁步」路径。在 core.py 里，只有 data_parallel and model_config.is_moe 时才构造 DPEngineCoreProc；非 MoE 的 DP rank 会被 reconfigure_for_independent_dp_rank() 降级成互相独立的实例。GLM-5.3 是 MoE，所以它走锁步路径——这也意味着 GLM-5.3 的 vLLM 部署里，「某个 rank 慢」同样会让所有人等。

1
def _has_global_unfinished_reqs(self, local_unfinished: bool) -> bool:
2
    # Sync step 1 too: an idle pause needs one dummy batch, not a full interval.
3
    self.step_counter += 1
4
    if self.step_counter != 1 and self.step_counter % self.dp_sync_interval != 0:
5
        return True
6
    parallel_config = self.vllm_config.parallel_config
7
    has_unfinished, pause_consensus = parallel_config.sync_dp_state(
8
        self.dp_group,
9
        has_unfinished=local_unfinished,
10
        pending_pause=self.pending_pause,
11
    )
12
    ...

1
# [0] = 1 if this rank has unfinished work, else 0.
2
#       SUM > 0 ≡ logical OR across ranks → any rank has work.
3
# [1] = 1 if this rank has a pending pause request, else 0.
4
#       SUM == dp_size ≡ all ranks reached pause consensus.

请求计数：前端打分用的账本

vLLM 的负载账本有两层：scheduler.get_request_counts() 返回 (num_running, num_waiting)，_maybe_publish_request_counts() 在 GPU step 的前后各发布一次到协调器；协调器再把 (engine_req_counts_list, current_wave, engines_running) 广播给所有前端进程。前端（AsyncLLM 的 get_core_engine_for_request）据此为每条请求挑一个 engine。

协调器发版的节奏是：统计有变化时每 stats_update_interval_ms（默认 100ms）发一次，没变化时每 5 秒心跳一次；并且在锁步 DP 下，enable_wave_coordination 为真时至少等 50ms，以收集同一 step 所有 rank 的计数：

1
# Wait at least 50ms to ensure we've received all stats for
2
# the current step. Only applicable to lockstep (MoE) DP;
3
# non-lockstep engines have no synchronized step boundaries.
4
if self.enable_wave_coordination and last_step_counts is None:
5
    min_timeout = 50

前端打分本身是这套账本里最细致的一段：

1
current_counts = self.lb_engines
2
num_engines = len(current_counts)
3
min_score: float = sys.maxsize
4
eng_index = 0
5
for i in range(num_engines):
6
    idx = (self.eng_start_index + i) % num_engines
7
    waiting, running, kv_cache_usage = current_counts[idx]
8
    inflight = self.engine_inflight[self.core_engines[idx]]
9
    score: float = max(self.client_count * inflight, waiting + running)
10
    if waiting:
11
        # Waiting requests are penalized in proportion to KV cache
12
        # pressure: a queue on a KV-bound engine drains slowly, so
13
        # new requests should strongly prefer other engines. With
14
        # low KV usage the queue is transient (e.g. mid-burst) and
15
        # the penalty stays off, preserving exact round-robin.
16
        # Ramps from 0 at <=50% usage to 3x waiting at 100%.
17
        score += waiting * 6.0 * max(0.0, kv_cache_usage - 0.5)
18
    if score < min_score:
19
        min_score = score
20
        eng_index = idx

展开收起

这里有三处与 SGLang 的 DPBudget 对应、又处理得更细的地方：

• 本地 in-flight 计数：self.engine_inflight[engine] 是本前端进程自己派出去、还没回来的请求数。打分取 max(client_count * inflight, waiting + running)——取最大值而不是和，是为了让「本地精确的在飞数」在快照滞后时仍然起作用。一个突发里即使快照还是旧的，inflight 也会让分数立刻上涨，从而把突发摊到不同 engine。client_count 是前端进程数，用来把「本进程的在飞数」放大到全服务尺度。
• 按 KV 压力加权等待：waiting * 6.0 * max(0, kv_cache_usage - 0.5)。等待数在 KV 使用率低于 50% 时不计入，因为这种等待多半是突发中的瞬时排队，很快会消化；KV 使用率接近 100% 时，等待被放大到 3 倍（6 × 0.5），因为这样的队列排得很慢。这一项直接对应本文前面的「负载」定义：等待本身不慢，KV 快满的等待才慢。
• 平局时的轮转起点：eng_start_index 每次加一，扫描从不同的 engine 开始，避免「快照刚重置、所有 engine 看起来一样空」时所有请求都落到 0 号。

这张图解释了为什么 vLLM 的负载账本要经过一个协调器：前端不直接知道各 engine 的队列，协调器把计数汇总后以一播多（XPUB）的方式发给所有前端。多前端部署时，每个前端都拿同一份计数，再各自加上自己的 in-flight 计数——这正是上面打分公式里「快照 + 本地」两部分的来源。

运行中的再平衡：retract、抢占与「挪不走」的请求

路由只能决定请求落在哪个 rank；一旦落定，请求的 KV 页已经在那个 rank 的池子里了。要让它在运行中换 rank，代价是把 KV 页搬过去——对 GLM-5.3，一条 1M 上下文的请求就是 57GB 量级，搬一次比重新算一遍还贵。所以实际系统中，「运行中再平衡」几乎都不是搬家，而是以下三种：

观测：把「偏斜」与「单点慢」分开

排障时最常犯的错误是把负载偏斜当成硬件故障，或者反过来。下面这组指标按「从粗到细」的顺序排，前两项在任何部署里都有，后两项只有 SGLang 的 DP Attention 提供：

• 每 rank 的 num_running_reqs 与 num_total_tokens 的比值。若各 rank 条数相近但 token 差很多，是长度偏斜；若 token 相近但条数差很多，是条数偏斜（短请求堆积）；若条数与 token 都差很多，是路由与突发叠在一起。
• 每 rank 的 gen_throughput 与 cache_hit_rate。单点慢的 rank 吞吐会持续低于其他 rank，且与请求数无关；负载慢的 rank 吞吐会随请求数波动。命中率异常低的那张卡，往往不是慢，而是「没享受到前缀缓存」——它的 token 数看着一样，prefill 却更贵。
• queues 里的 retracted 与 paused。retract 次数集中出现在某个 rank，说明该 rank 的 KV 长期不足，往往是长请求堆积的结果，而不是硬件问题。
• sglang:dp_attention_token_imbalance_ratio。每步统计「最忙 rank 的 token 数 / 平均 token 数」，1.0 是完全均衡，等于 num_dp_ranks 意味着只有一个 rank 有活干。这个直方图由 0 号 rank 的 scheduler 上报，是判断负载偏斜最直接的数。
• sglang:dp_attention_tokens_total{kind="imbalance"} 与 sglang:dp_attention_pairs_total{kind="imbalance"}。前者是「本 rank 比最忙 rank 少跑的 token 数」，后者是「少算的因果注意力对数」。token 数衡量的是 MoE 与投影的容量浪费（在 SUM_LEN padding 下是等待，在 MAX_LEN padding 下是填零算的废行）；注意力对数衡量的才是真正会变成同步等待的部分。
• sglang:dp_attention_sync_wait_seconds。每次 MLP 同步 gather 的墙钟耗时，在 gloo 路径上它就是「等最慢 rank」的时间。把它与一次前向的时间比，就是重叠调度第十八篇里「重叠是否生效」判断的同一类问题：如果 gather 等待占了 step 的很大比例，那么不管重叠开没开，GPU 都在空等。
• sglang:dp_attention_steps_total{rank_state="idle"}。空闲 rank 为锁步而跑的步数占比。这个比例高，说明整体负载很轻或者极度不均；两种情况下，一个 rank 上的新请求都会让整组进入同步。

这几项里，imbalance_ratio 与 sync_wait_seconds 是互补的：前者说「账面上偏了多少」，后者说「偏了多少变成了时间」。有时候前者很高、后者很低——那是 token 偏斜但注意力对数接近（比如偏斜在很短的请求上）；反过来，前者不高但后者很高，才是最难查的情况：token 数看起来均衡，但有一张卡的前向就是慢，这通常指向单点慢（降频、链路劣化、进程被抢 CPU），或者该卡的投机接受长度异常（它每步要多跑 MTP 的验证前向，却没有体现在 token 数上）。

还有一项需要单独测：集合通信的等待分布。sync_wait_seconds 只覆盖调度器侧的 MLP 元数据 gather；GPU 侧的 dp_gather/dp_reduce_scatter 与 DeepEP 的 all-to-all 的等待，要看 Nsight Systems 的时间线。做法是把 8 个 rank 的时间线并排：如果某个 rank 的注意力 kernel 早早结束、在 gather 前空等，等待时长就是它被其他 rank 拖住的时间；反过来，如果所有 rank 都早早结束却在通信上花很久，那是通信本身慢（链路或拥塞），不是负载。

一个可算的场景：三张卡的账

把上面的机制落到一个具体配置上，看一次 decode step 中「偏斜」如何逐层放大。设定：8 卡 DP Attention + EP8，batch 32、各卡 4 条；其中 3 条是 8K 上下文、1 条是 200K 上下文，且这 4 条全部落在 rank 0 上（其余 rank 各 4 条 8K 的），这是 TOTAL_REQUESTS 策略在「请求数相同、token 数完全不同」时可能造出的偏斜。

用第三篇的 MLA 口径：decode 每 token 每层的 KV 读取是 $576 \times 78$ 字节，其中 512 是 KV 潜向量、64 是 RoPE 部分。注意力对数按「每条请求一行 query 读它的全部历史」算：

• 8K 请求：$8192$ 对；
• 200K 请求：$204800$ 对。

rank 0 的注意力总对数：$3 \times 8192 + 204800 = 229376$；其他 rank：$4 \times 8192 = 32768$。比例约 7:1。KV 读取量同理：rank 0 约 $229376 \times 576 \times 78 \approx 10.3$ GB（若 DSA 层只读 Top-K，则这个数要按稀疏率打折，但 rank 之间的比例不变），其他 rank 约 $1.47$ GB。

这里先不讨论具体毫秒数——HBM 带宽、kernel 效率、DSA 稀疏率都会改变它——只讨论结构：

1. rank 0 的本地注意力时间远大于其他 rank，这是「偏斜」的源头。
2. MoE 的全局权重读取取决于全局 32 行，与偏斜无关；所以 MoE 这一段是匀速的。
3. dp_gather 的等待出现在 rank 0 追到其他 rank 的那一段；每层都要等一次，78 层累加。
4. 如果这一步同时有 rank 需要 prefill，is_extend_in_batch 取 max，所有 rank 都走 extend 视图；rank 0 若还有 chunked prefill，等待会更大。

第 1 步里那个「约 7:1」就是 dp_attention_pairs_total{kind="imbalance"} 会记录的量：每个非 rank 0 的 rank 每步会累计 $\max(229376) - 32768 = 196608$ 个「少算的对数」。如果按 78 层累计，每步约 1500 万对——这不是一个可以直接换算成毫秒的数，但它与 sync_wait_seconds 的直方图放在一起，就能判断「偏斜的主要来源是长上下文还是条数堆积」。

这个场景也解释了为什么 TOTAL_TOKENS 比 TOTAL_REQUESTS 更适合 GLM-5.3：在 TOTAL_REQUESTS 下，rank 0 的 4 条与别人的 4 条在请求数上完全相同，路由不会做任何调整；在 TOTAL_TOKENS 下，rank 0 的 $229K$ 总 token 会立刻让它成为「最忙」，后续请求会绕开它。但要注意，TOTAL_TOKENS 用的是 num_total_tokens，它含 KV 已用与待处理 token，对 decode 中的请求就是上下文长度——正是这个数。

反过来，如果路由选择 TOTAL_TOKENS，那么一条 200K 请求进入之后，该 rank 的 num_total_tokens 立刻增加 20 万，其他 7 个 rank 在剩余时间里都会被绕开。这又引出另一个问题：路由只按「现在」的负载做决定，不按「未来多久」。一条 200K 请求要跑很久，它落在一个 rank 上，就会把那个 rank 长期标成「最忙」；如果同期有很多短请求，它们会全部涌向其他 7 个 rank，导致其他 rank 反而更忙——负载均衡变成了「惩罚长请求所在卡」。这是 TOTAL_TOKENS 策略的结构性缺陷，也解释了为什么有些部署会把这个值按请求的未命中 token（而不是总 token）来算，或者干脆按「剩余 decode 步数」加权。

工程上的几条结论

把上面的机制收拢成可操作的判断：

1. 负载均衡的目标不是「每卡请求数相等」，也不是「每卡 token 数相等」，而是「每卡这一步的墙钟时间相等」。 在 DP Attention 下，后者才是集合通信等待的依据。条数均衡只在请求长度同质时近似等价；token 均衡在长度异质时接近，但会被前缀命中率与 DSA 稀疏率扭曲。
2. 账本永远滞后，滞后要被显式补偿。 SGLang 用投机加一 + 20ms 节流，vLLM 用本地 in-flight 下界 + 100ms 广播；两者都把「快照」与「本地状态」组合成最终决策。别指望「把快照频率调高」就能解决——频率一高，投机计数就被覆盖，突发会全部落到同一个 rank，这正是 20ms 节流注释里写的那条坑。
3. 长请求要隔离。 一条 1M 请求的 prefill 会让整个 DP 组的 decode 变慢，这不是调度器能解决的，只能靠分池（长上下文实例与短请求实例分开）或 PD 分离把 prefill 挪走。对 GLM-5.3 的 1M 上下文，这一条几乎是必选项。
4. 前缀命中率要进路由。 如果部署里共享前缀很多（系统提示、工具定义、RAG 的同一份文档），estimated_tokens 会系统性高估，路由会绕开实际上很空的 rank。把命中率或未命中 token 作为路由特征，是这类部署最值得做的一项改造；SGLang 的快照里已经有 num_waiting_uncached_tokens，只是 DPC 还没用它。
5. 结构慢与负载慢要分开处理。 前者靠并行布局（EP 细粒度、冗余专家），后者靠路由与调度；把两者混为一谈，会在错误的方向上调参。
6. 同步的范围要按部署形态算。 SGLang 是每步一次元数据 gather + 每层两次设备侧集合通信；vLLM MoE DP 是每 16 步一次 finish-sync。前者把等待分散到每一步，后者把等待聚集到 wave 边界；排障时先确认自己看的是哪一种时钟。
7. 单点慢只能从「与负载无关的持续差异」里找。 每 rank 的吞吐、每 rank 的 kernel 时长、降频日志，这几样与请求数解耦；负载慢的指标则一定与请求分布相关。把两者混看，会得出「加卡」或「改路由」这类并不对症的结论。

把三层账本放在一条时间线上

一条请求从进入到被调度，负载信息在三个地方各有一份，而且三份的定义不同：

三层里只有第三层是实时的，也只有第三层知道「未命中 token」与「KV 页够不够」。前两层都是它的有损投影。理解这一点，很多现象就解释得通：为什么 /v1/loads 显示的 num_running_reqs 与 DPC 实际用的预算对不上（刷新间隔不同）；为什么 router 看到两个 worker 负载相同，实际 TPOT 差一倍（一个 worker 的长请求占比高，另一个短请求多，条数相同但 token 不同）；为什么 DPC 刚派完一批请求，/v1/loads 里那个 rank 还是空的（快照还没发布）。

第四层不在这个表里，但它是最终决定结果的那一层：MLP 同步的元数据 gather 与设备侧集合通信。它不采样、不投影，只忠实地把「最慢 rank 的到达时间」变成「所有 rank 的出发时间」。

小结

这一篇把镜头从「一条请求经过什么」移到了「这条请求为什么在这个 rank 上」。GLM-5.3 的 DP Attention 让这个问题第一次变得重要：每个 rank 算不同的请求，而每层两次集合通信要求它们同时到达。于是负载账本的每一次失真——快照滞后、投机计数的长度估计、前缀命中的缺席——都会通过 78 层乘以两次通信的放大，变成全服务的尾延迟。

几处机制值得记住：

• SGLang 的 DPC 用 LoadSnapshot + DPBudget 做请求级路由，用「投机加一 + 20ms 节流」补偿快照滞后；快照的 timestamp 相同就跳过，是防止把已派发负载抹掉的关键细节。
• vLLM 的 MoE DP 用 wave（默认 16 步）做完成同步，空闲 rank 跑 dummy batch 维持锁步；前端按 max(client_count * inflight, waiting + running) + KV 压力加权 打分选 engine。
• 两套账本都只解决「路由时」的均衡；运行中的再平衡靠 retract/preemption，真正的「搬家」只有 PD 分离。
• 偏斜真正变成等待的地方，是 MLPSyncBatchInfo 的每步元数据 gather 与每层的 dp_gather/dp_reduce_scatter；sglang:dp_attention_sync_wait_seconds 是这段等待的直接观测。
• 偏斜的代价不是线性的：本地注意力多 4 倍，step 时间可能多 10 倍，因为等待按层累加；而 MoE 的全局权重读取对偏斜不敏感，这是两种「慢」必须分开看的原因。

前十八篇解释了 GPU 上算了什么、跨卡搬了多少字节；这一篇解释了这些计算与通信为什么落在那些卡上，以及当分配不均时，等待如何沿着同步结构扩散。到这里，一条 GLM-5.3 请求从进入服务到离开服务的路径，连同它所在的部署形态与它所在的那个 rank，才算完整。

参考资料

1. SGLang 源码：python/sglang/srt/managers/data_parallel_controller.py（DPBudget、LoadBalanceMethod 与 20ms 刷新节流）
2. SGLang 源码：python/sglang/srt/managers/load_snapshot.py（LoadSnapshot、ShmLoadSnapshotReader 与 ZmqShmLoadSnapshotReader）
3. SGLang 源码：python/sglang/srt/managers/scheduler_components/load_inquirer.py（get_loads 与未命中 token 估计）
4. SGLang 源码：python/sglang/srt/managers/scheduler_components/load_publisher.py（LoadStat 的 ZMQ PUB 发布）
5. SGLang 源码：python/sglang/srt/managers/scheduler_components/dp_attn.py（MLPSyncBatchInfo、prepare_mlp_sync_batch 与 idle batch）
6. SGLang 源码：python/sglang/srt/observability/metrics_collector.py（DPBalanceStats 与 dp_attention_sync_wait_seconds）
7. SGLang 文档：DP Attention（DPA + EP 架构与启动参数）
8. vLLM 源码：vllm/v1/engine/core.py（DPEngineCoreProc、wave 与 dummy batch）
9. vLLM 源码：vllm/v1/engine/core_client.py（get_core_engine_for_request 的前端打分）
10. vLLM 源码：vllm/v1/engine/coordinator.py（DPCoordinator 的计数汇总与广播节奏）
11. vLLM 源码：vllm/config/parallel.py（dp_sync_interval 默认 16 步）
12. vLLM 文档：Data Parallel Deployment（内置与外部负载均衡）
13. DeepSeek-V3.2: Pushing the Frontier of Open Large Language Models（DSA 与 MLA 结构，arXiv:2512.02556）
14. SGLang: Efficient Execution of Structured Language Model Programs（RadixAttention 与前缀共享，arXiv:2312.07104）
15. Efficient Memory Management for Large Language Model Serving with PagedAttention（arXiv:2309.06180）
16. 站内：GLM-5.3 推理全链路（一）：一个请求在 SGLang 里经过哪些算子、哪些通信
17. 站内：GLM-5.3 推理全链路（四）：PD 分离——57GB KV 与索引器缓存如何跨节点交接
18. 站内：GLM-5.3 推理全链路（六）：token 跨卡的那一段——MoE dispatch/combine 的模式、缓冲与重叠
19. 站内：GLM-5.3 推理全链路（十六）：一条 decode step 的 kernel 账本——78 层里到底发了多少次 launch
20. 站内：GLM-5.3 推理全链路（十八）：重叠调度——GPU 前向还在跑时，调度器在 CPU 上做什么