GLM-5.3 推理全链路（九）：混批——一条 8K 预填请求并进 32 条解码请求之后

前八篇的账本都默认了”纯批”

前八篇把 GLM-5.3 的一条请求拆成了入口、调度、解码层、prefill、PD 分离、MoE 通信、输出侧和一张总账（入口与解码层见 GLM-5.3 推理全链路（一），prefill 的分块见 （三））。每一篇的内部账本都成立，但它们共享一个不写在纸面上的前提：这一 step 里要么全是 prefill token，要么全是 decode token。纯 decode 时，每层读一遍 656 字节的 MLA KV，算一个头 192 维的稀疏注意力；纯 prefill 时，token 聚成一个大矩阵，走分块与上下文并行。两种形状各自的最优 kernel、最优并行方式、最优字节预算，都是从”批内同质”这个前提推出来的。

线上服务几乎没有这种同质批。一条 8K 的新请求到达时，32 条已经生成到一半的请求还在等下一个 token；调度器既不能为了新请求把 32 条全部挂起，也不能让新请求排到几十个 step 之后，否则 TTFT 会变成秒级。于是同一个 step 里，8K 个 prefill token 和 32 条 decode 行被塞进同一次前向。这个动作在 SGLang 里叫 mixed chunk，在 vLLM 里甚至没有专门的名字——V1 的调度器从一开始就只产出”每个请求这一步算几个 token”，同质只是它的一个特例。

混批不是一个调度开关那么简单。它把前八篇里所有”按批同质”算出来的数都改写了：注意力的形状变成两段，MoE 的 token 数变成两段之和，DP gather 的字节数按总行数走，CUDA Graph 的整图重放因为形状不匹配而退化成 piecewise 或 eager。这一篇打开这个被前八篇有意跳过的运行态，先把两个框架的实现讲清楚，再把混批一步的算子、KV 与通信重新记一遍。

混批有三种来源，不等价

“一个 step 里有两种 token”可以来自三个完全不同的机制，混在一起谈会得出错误结论。

第一种是分块预填与 decode 同批。一条长 prefill 被切成若干块，调度器在每块之间插入正在解码的请求。这时 prefill 段的 token 数由 chunked-prefill-size 决定，decode 段是每条请求一个（开了投机解码则是 k+1 个验证行）。两段共享一次前向，也共享这一层的权重读取。

第二种是投机解码的验证行。目标模型一次验证草稿模型给出的 k 个 token，再补一个 bonus 位置，于是每条 decode 请求在这一步贡献 k+1 行。它们全是”新 token”，但只有最后一行会被采样接受；前 k 行的 KV 是否保留，取决于验证结果。这仍然算同质批——因为所有请求都是 k+1 行——但它和”一条请求一行”的纯 decode 在形状上已经不同，前八篇里 192 行的算例就是这么来的。

第三种是PD 分离后 decode 实例的首步。prefill 实例把 KV 传过来，decode 实例的第一步要先把这批请求的上下文长度补齐到传输后的长度，再开始逐 token 解码。这一步在 SGLang 里可能被表示成一次 PREBUILT 或 EXTEND 前向，而不是普通 decode。

这一篇只讨论第一种：真正把”变长的 prefill 块”和”定长的 decode 行”放进同一个 batch。它是三种里唯一会让形状随请求长度连续变化的，也是唯一需要框架写专门合并逻辑的。

图源：Sarathi-Serve 论文图 7。图中 A、B 已处于 decode，C、D 后到达；最下方的调度把 C、D 的 prefill 切片后与 A、B 的 decode 同轮执行，使每轮工作量接近固定。混批要解决的就是这一行所示的状态：两类请求共享一次前向，但形状不同。

vLLM：调度器只记 token 数，不记批的类型

vLLM V1 的调度器没有 prefill 与 decode 两个队列。每个请求有一个 num_computed_tokens，调度器每轮为它分配 num_new_tokens，把所有请求的分配结果写进 SchedulerOutput.num_scheduled_tokens。一个请求这一步分到 8192 个 token，就是 prefill 块；分到 1 个，就是 decode；分到 k+1 个，就是投机验证。批的类型是这些数字的结果，不是输入。

预算的分配顺序决定了混批的形状。调度器先给 running 队列里的 decode 请求留出 token 预算，再用剩下的 input_budget 接纳 waiting 队列里的 prefill。相关代码在 vllm/v1/core/sched/scheduler.py：

1
num_new_tokens = min(num_new_tokens, token_budget, input_budget - draft_slots)

这一行把三件事同时压进一个整数：这一步还剩多少 token 预算（token_budget）、新请求还能吃多少输入预算（input_budget）、以及要给投机草稿留出的槽位（draft_slots）。decode 请求的 num_new_tokens 通常是 1 或 k+1，几乎不占预算；一条 8K 的 prefill 如果原样放进来，会一次吃掉整个 input_budget，把其他请求挤到下一步。

所以 vLLM 还有第二道闸：long_prefill_token_threshold。当一条请求本步被分配的 token 数超过这个阈值时，调度器把它截断：

1
if 0 < long_prefill_threshold < num_new_tokens:
2
    num_new_tokens = long_prefill_threshold

阈值默认是 0，即不启用；设为一个正值（例如 512 或 1024）后才生效。开启 adaptive_long_prefill_threshold 时，它还会把 input_budget // 可用请求数 作为下限，避免阈值小到让长请求每步只走几十个 token。它的作用不是限制 prefill 的总量，而是限制单条请求单步的占比：让一条长请求每步只贡献一个块，剩余预算留给其他 prefill 与 decode。这样做的代价是长请求要多走几个 step，收益是这一 step 的形状可控，decode 不会被一条 8K 请求拖成秒级停顿。

到了 worker 侧，这些 token 数被还原成三条索引：query_start_loc 给出每个请求在本步扁平 token 流里的起止位置，seq_lens 给出每个请求当前的上下文长度，logits_indices 给出哪些行需要采样。三者都不关心某一行来自 prefill 还是 decode。

图源：Inside vLLM: Anatomy of a High-Throughput LLM Inference System。图中三个不同长度的 prompt 被压成一条扁平 token 流，input_ids、positions 与 slot_mapping 按行对齐；第二轮 decode 只追加每个请求的新位置。混批只是让这条流里同时出现”多行”和”一行”的请求。

投机解码让这条流多出一个必须显式区分的字段。runner 在构造采样元数据时，对 chunked prefill 的请求填 -1：

1
num_decode_draft_tokens = np.full(num_reqs, -1, dtype=np.int32)
2
for req_id, draft_token_ids in scheduler_output.scheduled_spec_decode_tokens.items():
3
    ...
4
    if num_scheduled_tokens[req_idx] == draft_len + 1:
5
        num_decode_draft_tokens[req_idx] = draft_len

源码注释写得很直白：chunked prefill 用 -1 而不是 0 作为掩码，因为结构化输出（guided decoding）可能回滚投机 token。0 表示”这是一条 decode 请求，但本步没有草稿”；-1 表示”这不是 decode 请求，别按投机行处理”。混批里这两种情况会同时出现，一个整数掩码承担了区分职责。

混批与 CUDA Graph：形状不匹配，整图重放退出

纯 decode 能整图捕获，是因为形状只随 batch size 变化，用一组桶就能覆盖。混批把形状变成”prefill 块 token 数 + decode 行数”的二维组合，块 token 数又随请求长度连续变化，桶无法穷举。

vLLM 的判定写在一个静态方法里：

1
def _is_uniform_decode(self, max_num_scheduled_tokens, uniform_decode_query_len, num_tokens, num_reqs, force_uniform_decode=None):
2
    """Checks if it's a decode batch with same amount scheduled tokens
3
    across all requests."""
4
    return (
5
        (max_num_scheduled_tokens == uniform_decode_query_len)
6
        and (num_tokens == max_num_scheduled_tokens * num_reqs)
7
    ) if force_uniform_decode is None else force_uniform_decode

uniform_decode_query_len 是 1 + num_spec_tokens：没有投机解码时是 1，开了 5 个草稿时是 6。判定要求批内每个请求这一步都恰好分配这么多 token，且总 token 数正好等于”每请求 token 数 × 请求数”。混批里一条 8K prefill 加 32 条 6 行验证，两个条件都不满足，uniform_decode 为 False。

后续的图模式分派拿到这个布尔值后，FULL 模式的整图重放就不再是候选。vLLM 在 FULL 模式下还要对 attention 段做 padding：pad_attn = cudagraph_mode == CUDAGraphMode.FULL，只有整图模式才把 token 数与请求数补齐到捕获形状。混批大概率走的是 piecewise 或 eager，pad_attn 为假，padding 逻辑直接跳过，真实形状原样执行。

代价是 launch 次数。前一 step 的纯 decode 可能整图重放 78 层，只有一次 launch；混批这一步要逐 kernel 发射，SGLang 在 prefill 上测过：整图重放相对 eager 快 1.93 倍，分段捕获快 1.70 倍。混批更接近后者：它介于纯 prefill 与纯 decode 之间，能吃到一部分分段捕获的收益，但拿不到整图的收益。

vLLM 还有一个额外的形状约束叫 micro-batching（ubatching，把一步切成两半重叠执行）。它不能随便切，因为前缀缓存命中可能让一条请求的 attention 读取另一条请求本步正在写入的块：

1
readers = np.flatnonzero(
2
    (query_lens > (self.reorder_batch_threshold or 1)) & (computed > 0)
3
)

注释解释得很清楚：整步执行时，所有 KV 写入发生在任何 attention 读取之前，命中成立；切成两半后，前半的 reader 会读到后半 writer 还没填完的块。混批里这类”本步写入 + 本步读取”的组合本来就多，所以 _allow_microbatching 在有 reader 时直接否决。也就是说，混批不仅失去整图，也常常失去 micro-batching。

图源：SGLang 官方博客 Advanced CUDA Graph Techniques in SGLang。整图捕获把动态 prefill 批次补齐到固定形状；混批把”prefill 块 + decode 行”叠加进来，形状空间变成二维，桶不再够用。

SGLang：把 decode 行改写成 1-token extend，再合并

SGLang 走的是另一条路：不造”混合批”这种新类型，而是把 decode 行改写成 extend 行，再和一个普通的 prefill batch 合并。合并之后，整个批就是一次 extend 前向，走 extend 的 kernel、extend 的 metadata、extend 的 CUDA Graph 分段。

开关在 scheduler 构造时确定：

1
self.is_mixed_chunk = (
2
    self.chunked_prefill_size is not None and get_schedule().enable_mixed_chunk
3
)

enable_mixed_chunk 是配置项，chunked_prefill_size 必须已设置。两者同时为真时，调度循环在一个 step 里先收 waiting 队列的 prefill，再检查 running 队列能否并进来。相关代码在 python/sglang/srt/managers/scheduler.py：

1
if (
2
    self.is_mixed_chunk
3
    and not running_batch.is_empty()
4
    and not (new_batch.return_logprob or running_batch.return_logprob)
5
    and new_batch.input_embeds is None
6
    and all(r.beam_group is None for r in running_batch.reqs)
7
):
8
    finishing_reqs = self._reqs_finishing_inflight(running_batch)
9
    running_batch.filter_batch(reqs_to_exclude=finishing_reqs)
10
    if not running_batch.is_empty() and running_batch.check_decode_mem():
11
        running_batch.prepare_for_decode()
12
        new_batch.mix_with_running(running_batch)
13
        new_batch.decoding_reqs = running_batch.reqs

这段条件列表本身就是一张边界说明。return_logprob 的请求被排除，是因为合并后 logprob 的起始位置需要按行重排，SGLang 还没有统一处理；input_embeds 不为空时，mix_with_running 会 cat input_ids 而不是 embeds，形状对不上；beam search 的束成员行也不能混进 extend 批。凡是越过这三条边界的请求，都退回到”这一 step 只跑 prefill，decode 下一步再说”。

check_decode_mem() 是第二道闸。这一步的 prefill 块先占了 KV 槽位，留给 decode 行的余量可能不够；不够时 running 队列原地不动，下一 step 单独解码。

注释写得很清楚：“这一步接纳的 prefill 可能没给 decode 行留出 KV 空间，它们就会在这一步缺席，到下一个 decode step 再解。“

1
def mix_with_running(self, running_batch: ScheduleBatch):
2
    self.forward_mode = ForwardMode.MIXED
3
    running_bs = running_batch.batch_size()
4

5
    if self.spec_algorithm.is_none():
6
        running_prefix_lens = [s - 1 for s in running_batch.seq_lens_cpu.tolist()]
7
    else:
8
        running_prefix_lens = [r.seqlen - 1 for r in running_batch.reqs]
9
    for req, prefix_len in zip(running_batch.reqs, running_prefix_lens, strict=True):
10
        req.refresh_fill_ids()
11
        req.extend_end = prefix_len + 1

1
self.prefix_lens = self.prefix_lens + running_prefix_lens
2
self.extend_lens = self.extend_lens + [1] * running_bs
3
self.extend_num_tokens = self.extend_num_tokens + running_bs

1
out_cache_loc = torch.cat([self.out_cache_loc, running_out_cache_loc])

1
tail_base = torch.tensor([r.seqlen - 1 for r in running_batch.reqs], dtype=torch.int64, device=self.seq_lens.device)
2
running_out_cache_loc = self.req_to_token_pool.req_to_token[
3
    running_batch.req_pool_indices.long(), tail_base,
4
].to(self.out_cache_loc.dtype)

1
def is_extend(self, include_draft_extend_v2: bool = False):
2
    return (
3
        self == ForwardMode.EXTEND
4
        or self == ForwardMode.MIXED
5
        or (include_draft_extend_v2 and self == ForwardMode.DRAFT_EXTEND_V2)
6
        or self == ForwardMode.TARGET_VERIFY
7
        or self == ForwardMode.SPLIT_PREFILL
8
        or self == ForwardMode.DLLM_EXTEND
9
    )

一个混批 step 的形状账

先选一个具体形状，后面所有数字都从它来。假设：

• 32 条 decode 请求正在运行，上下文都是 128K，开了 MTP、每步验证 6 个 token（k=5，加一个 bonus），于是 decode 段是 $32 \times 6 = 192$ 行；
• 一条新请求带 8192 token 的 prompt，前缀缓存命中 0，这一步被切成一个 8192 token 的块；
• 部署沿用第一篇的吞吐配方：单机 8 卡 H200，--tp 8 --ep-size 8 --attn-dp-size 8，FP8 权重与 FP8 KV；
• 记 $P = 8192$ 为 prefill 段行数，$D = 192$ 为 decode 段行数，总行数 $N = 8384$。

1
self.extend_logprob_start_lens = (self.extend_logprob_start_lens + [0] * running_bs)

混批一步的账，和纯 decode 一步的账

把上面的数字放到同一张表里：

表格里最能说明问题的是 MoE 通信。纯 decode 一步的 MoE 通信是几十 MB 量级，混批一步是百 GB 量级。这不是”混批变慢了”，而是混批把一步的 prefill 计算并了进来——同样的 8K prefill 如果单独跑一步，通信量也是一样的。混批改变的是”这一步的延迟由谁承担”，而不是”这一步要搬多少字节”。

由此可以得出几个判断：

第一，混批的收益在 decode 侧。8K prefill 如果单独占一个 step，32 条 decode 请求在这一 step 全部停摆，TBT 出现一个长尾；并入之后，它们在这一步照常出 token。Sarathi-Serve 论文正是用这个论证提出 chunked prefill：在 A100 上跑 Yi-34B 服务 arXiv 摘要轨迹时，vLLM 风格的完整 prefill 会让生成流出现持续数秒的停顿。

第二，混批的代价在 prefill 侧。prefill 块的 MoE 通信与 KV 写入被 decode 行”分摊”了少量行，但整体形状从”纯 prefill 的大矩阵”变成”带 192 行尾巴的大矩阵”，Tensor Core 的有效利用率略降。8K 的块里混入 192 行 1-token 的尾巴，对稠密 GEMM 影响可以忽略；对稀疏注意力则要把两段分开算，多一次 kernel 发射。

第三，混批把两套最优形状拉向均值。纯 prefill 适合大块与大通信，纯 decode 适合小块与低延迟；混批既不纯大也不纯小。这也是后来分块预填与 PD 分离同时存在的原因：分块预填让”混批”的形状可控，PD 分离则干脆把两段放到不同实例上，彻底避开混批的均值化。

三种边界：什么不能混、什么时候该分开

混批不是”越混越好”。从两个框架的实现看，有三条边界必须守住。

边界三：形状与图的连续性

混批会让 CUDA Graph 从整图退回分段。这在 decode 侧的代价是每 step 多几毫秒的 launch 开销；在延迟敏感的场景里，这几毫秒足以让 P99 的 TBT 越过 SLA。

所以线上常见的做法是按负载切换：低负载、请求短的时候关掉混批，让 decode 走整图；高负载、长请求多的时候打开混批，用吞吐换一点延迟。SGLang 的 enable_mixed_chunk 是静态配置，vLLM 的 long_prefill_token_threshold 是静态配置——两个框架都把这个权衡交给了部署者，而不是自动决策。

图源：Sarathi-Serve 论文中的流水并行空泡示意图。论文给出的例子是：4K token prefill 约需 1150ms，而 batch size 32 的纯 decode 迭代约需 200ms；若二者在流水并行的不同微批中交错，阶段间可产生约 950ms 的空泡。混批的目的是让这两类工作在时间上重叠，而不是让它们各自占满整轮。

与 PD 分离的关系：混批的退路

第四篇讲过 GLM-5.3 的 PD 分离：prefill 实例把 57GB 的 KV 与索引器缓存传给 decode 实例。PD 分离从根本上让混批不再必要——prefill 与 decode 在不同实例上跑，各自有同质的批，各自用最优 kernel。

但 PD 不是免费的。57GB 的传输本身就是一项开销，PD 分离还需要两套实例、两套调度、两套 KV 池。对于中小规模部署，PD 分离的收益可能抵不过它的复杂度，这时混批是更实际的选择。

两者的另一个关系是互补而非替代。PD 分离之后，decode 实例依然会遇到”首步的 EXTEND 前向”（第三种混批来源），prefill 实例依然会遇到”长请求的多个块”。混批逻辑在这些位置仍然被调用，只是不再用于把两类生产请求并在一起。

真实的大规模部署里，常见的是组合：PD 分离承载主要流量，同一实例内的混批处理”实例内剩余的长尾请求”，分块预填控制 prefill 实例的形状。三者在不同层上解决同一个问题——让变长的 prefill 不阻塞定长的 decode。

形状之外：调度器内部还有哪些计数会错位

上面几节都是从”前向形状”看混批。但混批对调度器自己的账本同样有影响，而且这些影响在第 0 层之前就已经发生。

一个真实的首步：8K 请求到达时发生了什么

前面几节都是”稳态混批”的账，即 decode 已经跑了一段时间、新请求在中间到达。更极端的情况是新请求就是第一条：decode 队列是空的，但 is_mixed_chunk 仍然为真，调度器第一步只跑纯 prefill。混批的价值要等 decode 队列起来之后才出现。

以第三篇的 SGLang 配置为例：--chunked-prefill-size 32768、--attn-dp-size 8、--speculative-num-steps 5。一条 1M 的请求到来时，第一步会按 32K 切块；32 个块跑完，第一条 token 才产出。如果在此期间有新的短请求到达，它们会排在 1M 请求的块与块之间，而不会与 1M 的块混批——因为 PrefillAdder 在长请求的块之间会优先给短请求一个小块，后者单独跑或与 decode 混批。

所以混批在真实服务里的作用，更多是”承载长尾”而不是”承载主力”。主力流量走 PD 分离或独立实例；长尾请求、短请求、缓存命中请求，在同一个实例里被混批与 decode 一起处理，保持 GPU 不空闲。

把混批放回五框架的横向坐标

第五篇之后的几篇横向对比过前缀缓存、进程边界、CUDA Graph 在五个框架里的做法。混批在这里同样有一个横向坐标。

TensorRT-LLM 的 in-flight batching 与 vLLM 的连续批处理同源，但 TRT-LLM 在编译期就固定了 KV 最大长度与 max batch，混批的形状空间由引擎 profile 决定。“Paged KV 与 in-flight batching”的组合在 TRT-LLM 里是通过多个 profile 覆盖的，形状超出 profile 就退回 eager。这与 SGLang 的”extend 分段 + 分段图”是同一思路的不同落地。

llama.cpp 的批处理以”batch 内每个序列的 slot”组织，混批逻辑体现在 llama_batch 的 n_tokens 与每序列的 seq_id 上。它的混批更接近”把两段放进同一个 n_tokens”，没有统一的 extend 型 kernel，所以 decode 与 prefill 各自调用自己的 kernel，形状切换在 C 层做。

DeepInfer 的 SGLang 衍生路径在本篇的场景里与 SGLang 一致：enable_mixed_chunk 决定是否把 decode 行改写成 extend 行。差别在于它的调度器把 prefill 与 decode 的预算分成两层记账，混批的准入判断发生在第二层，而不像 SGLang 那样在 PrefillAdder 之后。

对 GLM-5.3 的部署者来说，这个横向坐标的意义是：混批的收益与代价在五个框架里量级一致，差异在”形状切换的粒度”。SGLang/vLLM 粒度细，混批能覆盖到很窄的形状；TRT-LLM 粒度粗，混批被 profile 边界限制；llama.cpp 粒度最粗，混批的吞吐收益最高，延迟稳定性最差。

逐算子清单：从第 0 层到第 79 层

把混批一步的每个阶段按执行顺序列出来，标清”两段共用”还是”两段分派”，这张表就是第八篇总账在混批状态下的展开。

这张表里，“共用”的算子占绝大多数。这也解释了为什么混批的实现成本主要在调度器与 metadata，而不在模型层：模型层的绝大多数算子天然按行工作，只有注意力与索引器需要知道”这一行属于哪一段”。

真正的分派点是两个：稀疏注意力与索引器。这两个恰好也是 GLM-5.3 推理开销最大的两处——前者决定 KV 读取，后者决定二次方项。混批把两个开销最大的算子拆成两套形状，剩下的算子合并，这是它能在工程上成立的原因。

怎么在线上看出混批正在发生

混批不是一个直接暴露的指标。SGLang 的 /metrics 里没有 mixed_batch 计数器，vLLM 也没有；要看出来，得从几条间接指标的组合推断。

第一条是 prefill 与 decode 的 token 数同时非零。 SGLang 的调度日志会打印每一步的 #new-token 与 #cached-token，vLLM 的 SchedulerOutput.num_scheduled_tokens 可以从 debug 日志或 profiler 里读到。如果某一步既有大于 chunked-prefill-size 量级的 token 分配，又有若干请求分到 1 或 k+1，混批就在发生。

第二条是 TPOT 的周期性尖峰。 纯 decode 的 TPOT 分布很窄，P50 与 P99 相差不到 2 倍；混批会在每次 prefill 块并入时出现一个尖峰，尖峰的高度近似等于”prefill 块的 MoE 通信时间 / decode 一步的时间”。32 条请求、8K 块、单机 NVLink 的场景里，这个尖峰通常是 5 到 10 倍。如果 P99 的尖峰周期与 prefill 块的到达周期一致，基本可以确认。

第三条是 GPU 利用率的锯齿。 纯 decode 的 SM 利用率低而稳定（显存带宽受限）；混批在 prefill 块那一步把 SM 拉满，下一步又回到低利用率。Nsight Systems 的 timeline 上会看到”一宽一窄”交替的 kernel 序列，宽的正是 prefill 段。

第四条是 CUDA Graph 的重放计数。 vLLM 的 cudagraph_metrics 会记录 FULL 与 PIECEWISE 的重放次数。混批 step 的 FULL 计数不增加、PIECEWISE 增加，这就是形状退回的直接证据。SGLang 的 --enable-metrics 里有类似的分段图统计。

排障时最有用的是把这四条放在同一张时间轴上：如果 TPOT 尖峰、SM 锯齿、PIECEWISE 重放三者同相位，而 token 分配里又同时有两段，那么尖峰的原因就是混批，而不是 PD 传输或专家负载不均。

反过来，如果 TPOT 尖峰出现但 token 分配里只有 decode，问题在别处——可能是专家路由的热点、前缀缓存的失效、或者 PD 的 KV 传输。混批只是众多”周期性强干扰”里的一种，不能看到尖峰就归因于它。

混批对前缀缓存命中的改写

前缀缓存与混批在调度器里是相邻的两步：请求进入 waiting 队列时先算前缀命中长度，再进入 PrefillAdder 决定本步分多少 token。混批打开后，这一步的命中判断要处理一个额外情况——前缀的块里有一部分是本步正在被别的请求写入的。

第八篇的”前缀缓存命中如何改写账本”一节只讨论了命中之后的读取，没有讨论命中与写入同批的情形。混批把两者放在同一个 step 里：一条请求的前缀命中可能在另一条请求本步正在计算的块上，这在纯 decode 的批里不会出现（decode 只追加单 token，不产生新块），在纯 prefill 的批里也只发生在”同批的两个请求共享前缀”时。

vLLM 的 _allow_microbatching 注释正好描述这个情形：“一条请求可能在一个前缀缓存命中上被接纳，而它命中的块正是同批另一条请求此刻正在计算的。“整步执行时，写入先于读取，命中成立；切成两半后，前半的 reader 会读到后半 writer 还没写完的块。

SGLang 在 mix_with_running 里没有对应的显式检查，但它通过两个设计天然避开了问题：其一，decode 行只写 1 个槽位，不产生新块，不会让其他请求的命中指向半成品；其二，prefill 请求之间的共享前缀在 PrefillAdder 阶段已经按顺序处理，先算的请求先写块，后算的请求读到的都是完整块。

对账本的影响是：混批一步的”有效缓存字节”不是两段命中字节之和，而是”命中且已完整写入”的部分。一条请求的前缀命中了 4K，其中 1K 是本批另一条请求本步才写入的，那么对这 1K 的读取要等写入完成；这部分等待在纯 decode 的账本里不存在，在混批里是一次与块大小成正比的块内同步。

前九篇的账，到这里才完整

前八篇把 GLM-5.3 的一条请求拆开，每一篇都在”纯批”的假设下算账。这一篇补上了那个假设不成立时的账：混批让形状变成两段，让算子分派变成”一算子两形状”，让 CUDA Graph 从整图退回分段，让 MoE 通信从每 step 几十 MB 跳到上百 GB——但这些字节全都来自同一步的 prefill 计算，混批改变的是”谁来承担这一步的延迟”，而不是”这一步要搬多少字节”。

把这个结论放回总账（第八篇）里，一条请求的生命周期就有三本账：

• 纯 decode 一步：几十 MB 通信、每层几百 MB 的 KV 读取、整图重放，瓶颈在显存带宽；
• 纯 prefill 一步：百 GB 级 MoE 通信、二次方项索引器、分块与上下文并行，瓶颈在 Tensor Core 与 NVLink；
• 混批一步：两段之和，形状拉向均值，瓶颈由两段的 token 比例决定。

调度器的真正职责，不是选择”prefill 还是 decode”，而是决定”这一 step 的两段比例”。比例偏向 decode，TBT 稳定、TTFT 变慢；比例偏向 prefill，TTFT 变快、TBT 出现长尾。分块预填、混批、PD 分离，都是在这条比例轴上做选择的不同工具。

参考资料

1. Sarathi-Serve: Stall-Free Batching for Efficient Large Language Model Serving（arXiv:2403.02310）
2. DeepSeek-V3.2: Pushing the Frontier of Open Large Language Models（DSA 与稀疏 MLA 结构，arXiv:2512.02556）
3. vLLM 源码：v1/core/sched/scheduler.py（num_scheduled_tokens、long_prefill_token_threshold）
4. vLLM 源码：v1/worker/gpu_model_runner.py（_is_uniform_decode、chunked prefill 的 draft 掩码、micro-batching 约束）
5. SGLang 源码：managers/scheduler.py（is_mixed_chunk 与混批接纳条件）
6. SGLang 源码：managers/schedule_batch.py（mix_with_running、check_decode_mem）
7. SGLang 源码：model_executor/forward_batch_info.py（ForwardMode.MIXED 与 extend 判定）
8. Inside vLLM: Anatomy of a High-Throughput LLM Inference System
9. SGLang 官方博客：Advanced CUDA Graph Techniques in SGLang
10. DeepEP：MoE dispatch/combine 通信库
11. FlashMLA：MLA 解码内核
12. vLLM GLM-5.3 部署配方（TP8、FP8 KV、MTP 与 DSA 后端参考）