推理框架的调度器是怎么工作的？

你在腾讯元宝里给 AI 发一句话，几秒后回答出现，中间发生了什么？请求并没有直接「飞」到显卡上，而是先到一位隐形管家手里：排队、分批、安排上卡、回收结果，全程由它指挥。这位管家就是推理框架里的调度器。

调度器站在什么位置

它夹在入口和计算资源之间：前面接收源源不断的请求，后面管理有限的显存和计算单元。资源永远比请求少，谁先谁后、怎么拼批、满了怎么办，都要有人拍板，调度器就是那个拍板的角色。它的水平直接决定服务的吞吐和延迟，同样的机器，调度策略不同，表现能差出一大截。

一个请求的完整旅程

以 Kimi 风格的长对话请求为例走一遍流程：请求到达，先在队列登记；调度器判断当前批次还有没有空位、显存够不够接纳；条件满足就分配进批，随批上卡计算；生成过程中如果显存吃紧，它还要决定保谁、缓谁；算完交付结果、释放占位，流程到此走完一轮。每个环节进出什么、消耗什么，调度器都记着账，这也是它敢做取舍的依据。

排队规则并非先来后到那么简单：短请求和长请求混在一起时，有的策略让短请求插队，先把快活干完腾地方；有的按会话分组，保证同一位用户的多次请求顺序稳定。取舍标准只有一个：整体体验和资源效率的平衡。

排队与抢占的规则

资源紧张时调度器要「动刀」：轻则让新请求在队列里多等，重则暂停进行中的任务，把资源让给更急的活。抢占不是随便做的——被打断的请求要保存现场，恢复时接着算，这套机制和批处理的进退出入衔接紧密，细节见批处理；多卡场景下任务落到哪张卡，还要配合模型切分的布局来安排。

不同策略的差异

策略没有标准答案：有的追求吞吐，批次往大凑，适合离线场景；有的追求延迟稳定，宁可少装也要快回，适合交互服务；还有的按优先级分层，重要用户优先级更高。策略好不好，最终看两个数字：延迟分布和利用率，读法见GPU 利用率。底层计算快慢还受算子效率影响，两件事配合优化，参考算子融合。

新手理解调度器有个容易犯的错：把它想成单纯的「排队机」。实际上它同时管着三本账：请求账——谁在等、等了多久、优先级多少；资源账——每张卡的显存余量、正在跑的批次、还能塞多少；策略账——当前该偏向吞吐还是延迟。三本账每隔很短的时间就要对一遍，随时调整，这套高频小步的决策节奏，也是它区别于简单先来后到队列的地方。

调度器速查表

• 角色：请求与算力之间的总管事
• 日常动作：排队、凑批、分配、抢占、回收
• 核心取舍：吞吐与延迟之间找平衡
• 评估方式：看延迟分布与资源利用率

带走一句：调度器决定「谁先上桌」，它排得聪明，同样的机器就能多招待一倍客人。

评估调度器改动的效果要留足观察期：调度策略的影响往往在高峰时段才显现，低峰期怎么测都差不多。改动上线后至少覆盖一个完整高峰周期，再对比同期分位数延迟和排队长度，别拿凌晨两点的数据给高峰策略打分。

聊聊调度器的常见疑问

• 为什么高峰期回答明显变慢？：队列变长、批次变满，等待与计算时间一起上涨，调度策略会尽量托底但物理极限挡不住。
• 调度器能保证先到先答吗？：多数策略不做严格保证，短任务插队、优先级分层都会改变次序。
• 换调度策略要改代码吗？：主流推理框架把策略做成可配置项，改配置就能切换，观察一段时间再固化。