同样的 GPU，达标请求最多多接约五成：滑铁卢大学提出 ConfluxServe

做大语言模型推理服务，GPU 忙起来和用户等得起，往往是两回事。把更多请求塞进一个批次，可能提高资源利用率，也可能拖慢正在生成的回答；把不同阶段拆到不同 GPU，又容易让算力和带宽各有闲置。

滑铁卢大学的 ConfluxServe 尝试解决这个矛盾：让预填充和解码在同一批次中协作，同时保留各自适合的并行方式。在主实验中，相同 GPU 数量下，完整系统的有效吞吐达到最强增强调度基线的 1.26—1.52 倍，最高相当于每秒多承接约五成满足延迟要求的请求。

论文：ConfluxServe: Reconciling Resource Utilization and Parallelism Efficiency across Prefill and Decode in LLM Serving

作者：Wenhao Chen、Hong Zhang

单位：滑铁卢大学（University of Waterloo）

论文链接：https://arxiv.org/abs/2610.37810v1

背景：同一段回答，前后需要两种资源

一次推理请求通常分为两个阶段。预填充（Prefill）先处理整段输入，建立后续生成需要的 KV 缓存，决定用户要等多久才能看到第一个词元。解码（Decode）随后逐个生成词元，持续读取历史 KV 缓存，影响回答能否流畅输出。

两者的资源需求有明显差异。预填充一次处理大量输入，更容易受计算能力限制；解码每轮只生成少量新词元，却要反复读取权重和缓存，更容易受显存带宽及容量限制。把两者放在一起，本来存在互补空间。

但资源互补，并不意味着适合相同的并行方式。长提示词的预填充可以把序列分给多张 GPU，缩短首词元等待时间；同样的并行规模用在解码上，却可能增加跨卡通信，抵消收益。论文的动机实验中，Qwen3-14B 处理 64K 输入时，仅达到 2 秒首词元目标的理论下界就至少需要 4 张 H100；而一些批量为 16、上下文为 4K—16K 的解码负载，单卡已能做到每轮低于 25 毫秒。

已有设计各有取舍。将两个阶段分开执行，方便分别选择并行配置，却难以充分利用互补资源；将两者合批，可以摊薄权重读取成本，但常要求统一并行配置，让解码承担额外通信。

ConfluxServe 把这个选择细化到了 Transformer 内部：根据算子的特点决定合批和并行方式。

创新点：共享权重时合批，计算注意力时分流

这套机制叫 Conflux Parallelism，简称 XP。理解它的关键，是区分线性变换与注意力计算。

在 QKV 投影、输出投影、前馈网络等线性算子中，两阶段使用相同的模型权重。即使预填充的序列被切成多份，每份词元的特征维度仍然一致。因此，每个执行单元可以把自己拿到的预填充词元和解码词元拼起来，完成一次矩阵运算，共享权重读取开销。

到了注意力算子，执行路径才分开。预填充使用 Ulysses 序列并行，通过 All-to-All 通信在多个执行单元之间组织计算；解码保留在本地执行，减少不必要的跨单元通信。注意力结束后，两条路径重新汇合，继续合批执行后面的线性算子。

这样，同一批次里的两阶段可以拥有不同的序列并行规模。论文中的“本地解码”指一个逻辑执行单元：较大模型仍可能需要固定的张量并行组。例如 Qwen3-32B 的实验中，每个逻辑单元由两张 GPU 组成。

数据布局也要配合这条路径。预填充的 KV 缓存按注意力头分片，解码缓存保留在目标执行单元，避免每经过一个算子就重新搬运缓存。请求从预填充切换到解码时，才进行必要的转移；系统提前选好目标，并将逐层异步传输与最后一个预填充块的执行重叠。

注意力阶段的两条路径还可以重叠运行。系统用独立 CUDA 流配合 NVIDIA Green Context 划分计算资源，为解码保留足以维持高显存带宽的资源，再利用剩余资源运行预填充。共享线性算子则使用分段 CUDA Graph，减少运行时开销。

方法：每一轮都要算清，还能塞多少预填充

XP 解决了执行路径，ConfluxServe 还需要回答调度问题：哪个请求先进入、每张卡承担多少预填充，以及新请求的解码状态放在哪里。

每轮迭代，系统以所有正在解码的请求各推进一个词元为基础，估算满足词元间延迟目标时还能容纳多少预填充工作。离线测量得到的延迟模型负责估算不同混合批次的执行耗时。

预填充也不是平均分给每个执行单元。某个单元已有较重的解码负载，就少放一些预填充；较空闲的单元则多承担一些。系统通过这种“注水式”分配，尽量拉平合批后的负载，并搜索延迟预算允许的预填充量。

解码放置还要考虑未来的显存使用。KV 缓存占用较低时，系统倾向把新请求放到已有解码上下文总量较小的单元，平衡工作量；当所有单元的缓存利用率都超过阈值后，再转向更紧凑的放置方式，减少容量碎片。

对排队请求，调度器结合首词元截止时间判断哪些请求有希望按时完成，并优先安排较早到期的请求。暂未进入这组请求的任务，仍可在有余量时按短作业优先的方式补入执行。

这套调度并非零成本。论文报告，在测试的队列规模下，调度平均开销约为 0.36—1.04 毫秒，并通过异步调度与 GPU 执行重叠。

实验：多接的是满足延迟要求的请求

ConfluxServe 基于 vLLM 实现。实验使用带 NVLink 的 H100 SXM5 80GB GPU：Llama-3.1-8B 和 Qwen3-14B 各用 4 张，Qwen3-32B 用 8 张；同一模型下，各系统使用相同数量的 GPU。

比较对象包括分块预填充系统、预填充与解码分离的 DistServe、弹性并行的 LoongServe，以及通过空间资源划分运行两阶段的 MuxWise。实验使用生产请求轨迹中的输入输出长度与到达模式，在测试环境中回放并调整到达速率。

主要指标是有效吞吐（goodput）：在至少 95% 请求满足服务目标时，系统能够持续承接的最高请求到达速率。每个请求的所有输出词元，都必须满足相应的时间截止要求。Llama 的首词元与词元间延迟目标分别为 1 秒和 50 毫秒，两个 Qwen 模型分别为 2 秒和 100 毫秒。

论文分两步比较。第一步，各系统统一使用先到先服务调度，尽量隔离执行机制的影响。此时 ConfluxServe 的有效吞吐达到最强基线的 1.33—1.62 倍。

第二步，给基线也加入增强调度，再与完整 ConfluxServe 比较。主实验使用 Mooncake-Toolagent，结果如下：

开头“最多多接约五成”的结果，对应第二组比较中的 Qwen3-14B。它衡量的是服务质量约束下的承载能力，结果同时包含执行设计与调度策略的作用。

适用边界：长输入更能发挥互补优势

收益会随请求结构变化。在更偏预填充的 Mooncake-Synthetic 负载上，Qwen3-14B 的有效吞吐为 5.5 请求/秒，达到最强基线的 1.7 倍；在输入较短、输出较长的 QwenA 上，则为 15.6 请求/秒，约为最强基线的 1.1 倍。

长输入带来了更多可与解码共同安排的预填充计算，因而更有机会发挥资源互补。输入较短时，这部分空间缩小，收益也随之降低。这使它尤其值得承担长提示词请求、同时又要保持生成流畅度的推理服务团队关注。

目前的证据也有明确范围。评测覆盖三个模型配置和 H100 节点内互联环境，实际运行的是单个 XP 实例，没有检验全局路由的多实例扩展效果。系统还依赖离线延迟画像、缓存布局和底层执行支持。跨节点通信、其他硬件上的表现，以及长期部署的运维成本，仍需更多验证；论文没有给出总体费用或能耗的直接测量。

ConfluxServe 展示了一个具体的系统设计机会：共享权重的计算可以合批，通信敏感的计算可以分别组织，再用调度把两者协调起来。对推理服务而言，优化粒度深入到算子之后，同一批次就有机会同时兼顾资源利用率与不同阶段的执行效率。