96卡实测吞吐只涨15%，大模型推理卡在"谁等谁"

卡加得越来越多，吞吐却涨得越来越慢。这个现象在大模型在线服务里反复出现，原因往往不在算力本身。

香港科技大学周子杰团队与华为2012实验室理论部联合提出BalanceRoute，专门处理大模型推理中的数据并行负载均衡瓶颈。在论文的96卡主实验中，采用实际预测器的BR-H相对所比较的最强基线，解码吞吐提升约15%。这项工作已被NeurIPS 2026接收，并已部署于双方共建的MaaS推理服务系统MathBot-Pie。

论文标题为《Tackling the Data-Parallel Load Balancing Bottleneck in LLM Serving: Practical Online Routing at Scale》。

问题的根源在于同步等待。在DeepSeek等MoE模型的一类部署中，多组计算卡并行处理大量请求，每组既处理各自的请求，又要通过跨组通信共同完成每一步解码。解码是齐步走：只要最忙的一组没算完，其他组算得再快也只能等。这种等待会随token生成反复发生，每一步都等一点，累积下来，部署规模扩大的收益便被悄悄吃掉了。

瓶颈并不卡在算力那里，而是卡在"谁来等谁"上。

请求数相同，负载仍会不同

大模型生成回答通常分为预填充和解码两个阶段。预填充先处理整段输入，把后续生成需要复用的中间结果保存为KV缓存；解码再逐个生成输出token。每生成一步，都需要读取此前输入和已生成内容对应的KV信息。

在预填充—解码分离系统中，这两个阶段由不同的计算资源承担。请求完成预填充后，路由器为它选择一个解码工作单元，已有的KV缓存也随之传送过去。一个单元可由多张计算卡组成。

轮询等方法可以依次把新请求分给各组，却没有区分每条请求需要处理多少KV信息。同样处理两个请求，长上下文对应的缓存更多，单步读取与计算的负担也可能更重。因此在同步约束下，请求数相同，较轻的组等待较重的组仍是常见的问题。

负载还会随生成不断变化。每生成一个token，请求就会新增相应的KV信息，下一步需要处理的上下文也随之变长，请求完成则退出后续解码计算。与此同时，预填充侧还在送来新请求。某组可能连续多步变忙，也可能因一条请求结束而突然减轻负担。

把运行中的请求转交给另一组，需要搬运已经积累的KV缓存。考虑这一开销，论文采用分配后不迁移的设定：路由器必须在输出长度未知、负载不断变化时作出选择，请求随后留在该单元直到结束。

把同步等待变成决策目标

从每一步的同步关系出发，通过数学建模，把各单元与最重单元之间的负载差相加，得到不均衡指标。这个量越大，说明各个单元之间的算力分配越不齐。这个指标刻画了同步等待对应的空闲，长期目标则是减少它在连续解码步骤中的累积。

一个例子揭示了分配的关键权衡：四组负载为10、7、6、5，给较轻的一组增加4单位负载，恰好填平它与最重单元的差距，不均衡指标下降；若增加5，它就变成新的最重单元，让其他三组各多等一份，指标反而回升。接入新请求能填补较轻单元的空闲，但若把它推成新的最重单元，就会增加其他单元的等待。

一次分配的影响会延续到后续解码。两组此刻一样忙，其中一组若有请求即将结束，就可能很快释放负载。BalanceRoute的BR-H因此引入H步窗口，估计各组近期的负载变化。

窗口并非越长越好。H太短，可能看不到即将结束的请求；H太长，即使现有请求的长度预测准确，尚未到达的新请求及后续分配也会改变负载，让更远处的状态难以确定。

预测目标也随之具体化：对运行中的请求，先估计它在窗口内结束的概率，再估计"若在窗口内结束，还需多少步"。二者共同给出它在窗口内预计还会运行多久。若请求持续超过窗口，就不必精确区分它在更远处还会生成多少内容。

这些预测最终要变成具体的分配。BR-H先估计各单元未来H步的负载，再比较接入候选请求后，每一步能填补多少空闲、又会带来多少额外等待，将收益与代价汇成评分，并降低较远步骤的权重。为控制决策开销，路由器结合可用槽位和预计余量挑选单元，再按评分选择请求或请求组合，逐步完成分配。每次接入后更新预计负载，下一轮再依据最新运行状态重新判断。

毫秒级路由与真实系统验证

模型要带来收益，路由决策需要跟上解码节奏。团队在vLLM-Ascend之上实现了有状态代理，统一维护各工作单元的负载、空闲槽位和生成进度。预填充完成的请求先进入等待池，让BR-H能结合全局状态比较候选请求的分配；解码端的流式反馈则持续更新生成进度。这套设计通过现有接口接入，无需修改推理引擎核心。

主实验使用96张昇腾910C NPU，运行DeepSeek-V3 671B（W8A8），其中包含8个解码工作单元。在该部署中，单轮调度耗时的中位数为1.20毫秒，99%分位为2.77毫秒，低于约60毫秒的单步解码时间预算。

在接近饱和的高负载条件下，团队回放企业生产请求记录和公开Azure-2024请求记录，与轮询、最短队列等四种常用路由策略比较。采用实际预测器的BR-H，相对各数据集上吞吐最高的基线，解码吞吐分别提升15.4%和14.5%，输出token间隔的尾部延迟也同时降低。这些收益来自相同模型与NPU配置下的请求分配改进。

在系统应用方面，BalanceRoute已部署于双方共建的MaaS推理服务系统MathBot-Pie。MathBot-Pie以cache感知调度为基础框架，通过Agent实现快速自动适配，以及高性能算子和模型的自动构建与优化，综合推理框架、模型计算与底层算子的联合优化，致力于实现低时延与高性价比；而BalanceRoute正是其降低跨组同步等待、提升在线解码吞吐的关键所在。

在请求不断到达、KV缓存随生成增长、请求结束又释放负载的过程中，跨组同步让这些变化相互牵连，很难直接判断一次分配对整体效率的影响。团队通过建模理清这些关系，提炼出反映同步等待的负载不均衡指标，把路由问题转化为一个有明确目标的优化问题。沿着这个目标，团队进一步分析负载随时间的变化并把预测重点放在近期哪些请求会结束上，形成短期预测与路由策略，并在真实系统中验证了收益。