文章核心观点 - 大模型大规模在线服务中，卡加得越多吞吐却涨得越慢，瓶颈不在算力而在跨组同步等待，即“谁来等谁”的问题 [1][2] - 香港科技大学周子杰团队与华为2012实验室理论部联合提出BalanceRoute，通过数学建模刻画同步等待，将短期负载预测转化为在线路由决策 [2] - 在96卡主实验中，采用实际预测器的BR-H相对最强基线，解码吞吐提升约15% [3] - 该工作已被NeurIPS 2026接收，并已部署于双方共建的MaaS推理服务系统MathBot-Pie [4] 请求数相同负载仍会不同 - 大模型生成回答分为预填充和解码两个阶段，预填充处理整段输入并保存KV缓存，解码逐个生成输出token，每步需读取此前输入和已生成内容对应的KV信息 [8] - 在预填充—解码分离系统中，两个阶段由不同计算资源承担，请求完成预填充后路由器为其选择解码工作单元，已有KV缓存随之传送，一个单元可由多张计算卡组成 [8] - 轮询等方法可依次把新请求分给各组，却没有区分每条请求需要处理多少KV信息，长上下文对应缓存更多，单步读取与计算负担可能更重，因此在同步约束下请求数相同较轻的组等待较重的组仍是常见问题 [8] - 负载还会随生成不断变化，每生成一个token请求就新增相应KV信息，下一步需处理的上下文随之变长，请求完成则退出后续解码计算，同时预填充侧还在送来新请求，某组可能连续多步变忙也可能因一条请求结束而突然减轻负担 [10] - 把运行中的请求转交给另一组需要搬运已积累的KV缓存，考虑这一开销论文采用分配后不迁移的设定，路由器必须在输出长度未知、负载不断变化时作出选择，请求随后留在该单元直到结束 [13] 数学建模把同步等待变成决策目标 - 从每一步的同步关系出发通过数学建模，把各单元与最重单元之间的负载差相加得到不均衡指标，设第k步中单元g负载为L_g(k)，最重单元负载为M(k)，一共有G个单元，单步不均衡可写作I(k)=Σ[M(k)-L_q(k)]，M(k)=max_q L_q(k) [15] - I(k)越大说明各单元之间算力分配越不齐，该指标刻画了同步等待对应的空闲，长期目标则是减少它在连续解码步骤中的累积 [16] - 四组负载为10、7、6、5时I(k)为12，给C增加4单位负载恰好填平它与最重单元的差距，I(k)降至8，若增加5则C变成新的最重单元，让其他三组各多等一份，I(k)为11 [16] - 该例子揭示分配的关键权衡：接入新请求能填补较轻单元的空闲，但若把它推成新的最重单元就会增加其他单元的等待，接下来需要把这种比较延伸到未来多个步骤 [18] 预测多远取决于路由真正需要什么信息 - 一次分配的影响会延续到后续解码，两组此刻一样忙，其中一组若有请求即将结束就可能很快释放负载，BalanceRoute的BR-H因此引入H步窗口估计各组近期的负载变化 [20] - 窗口并非越长越好，H太短可能看不到即将结束的请求，H太长即使现有请求的长度预测准确，尚未到达的新请求及后续分配也会改变负载，让更远处的状态难以确定 [20] - 预测目标具体化：对运行中的请求先估计它在窗口内结束的概率，再估计若在窗口内结束还需多少步，二者共同给出它在窗口内预计还会运行多久，若请求持续超过窗口就不必精确区分它在更远处还会生成多少内容 [20] - BR-H先估计各单元未来H步的负载，再比较接入候选请求后每一步能填补多少空闲又会带来多少额外等待，将收益与代价汇成评分并降低较远步骤的权重，为控制决策开销路由器结合可用槽位和预计余量挑选单元，再按评分选择请求或请求组合逐步完成分配 [22] - 每次接入后更新预计负载，下一轮再依据最新运行状态重新判断，预测、评分和分配由此形成持续更新的过程 [23] 从模型到真实系统中的毫秒级路由 - 团队在vLLM-Ascend之上实现了有状态代理，统一维护各工作单元的负载、空闲槽位和生成进度，预填充完成的请求先进入等待池让BR-H能结合全局状态比较候选请求的分配，解码端的流式反馈则持续更新生成进度 [25] - 这套设计通过现有接口接入无需修改推理引擎核心，系统复用预测、增量更新负载并将组合选择限制在小规模候选集合内以控制每轮调度开销 [25] - 主实验使用96张昇腾910C NPU运行DeepSeek-V3 671B（W8A8），其中包含8个解码工作单元，单轮调度耗时的中位数为1.20毫秒，99%分位为2.77毫秒，低于约60毫秒的单步解码时间预算 [28] - 在接近饱和的高负载条件下，团队回放企业生产请求记录和公开Azure-2024请求记录，与轮询、最短队列等四种常用路由策略比较，采用实际预测器的BR-H相对各数据集上吞吐最高的基线，解码吞吐分别提升15.4%和14.5%，输出token间隔的尾部延迟也同时降低，这些收益来自相同模型与NPU配置下的请求分配改进 [28] - BalanceRoute已部署于双方共建的MaaS推理服务系统MathBot-Pie，MathBot-Pie以cache感知调度为基础框架，通过Agent实现快速自动适配以及高性能算子和模型的自动构建与优化，综合推理框架、模型计算与底层算子的联合优化，致力于实现低时延与高性价比，而BalanceRoute正是其降低跨组同步等待、提升在线解码吞吐的关键所在 [30] 把运筹学写进推理系统 - 在请求不断到达、KV缓存随生成增长、请求结束又释放负载的过程中，跨组同步让这些变化相互牵连，很难直接判断一次分配对整体效率的影响，团队通过建模理清这些关系，提炼出反映同步等待的负载不均衡指标I(k)，把路由问题转化为一个有明确目标的优化问题 [32] - 沿着这个目标团队进一步分析负载随时间的变化并把预测重点放在近期哪些请求会结束上，形成短期预测与路由策略，并在真实系统中验证了收益 [33] - 这是香港科技大学周子杰团队探索OR for LLM serving（面向大模型服务的运筹学研究）的出发点：通过建模理解复杂系统并明确该优化什么以及需要哪些信息，再让这些认识指导实际决策 [33]