大模型推理请求如何调度更公平？

简化版

公平不是所有请求获得完全相同 GPU 时间，而是在租户配额、优先级和 SLO 下，避免短请求被长请求阻塞，也避免低优先任务永久饥饿。LLM 请求长度未知且 KV 占用不同，仅用 FIFO 或最高优先级都不够。

实践中用连续批处理配合分层队列：先按租户和业务等级分配 Token/并发份额，再在队列内结合等待时间、预测剩余 Token、截止时间和 KV 成本排序。加入等待时间老化、最大连续服务量和最低保障份额，并用分租户 P99、慢化比与饥饿次数验证公平。

详细版

FIFO 简单但会产生队首阻塞；最短作业优先降低平均延迟，却可能饿死长请求；严格优先级保障核心业务，却可能让普通队列永远无法运行。因此通常采用分层策略，而非单一算法。

tenant quota / class reservation
            |
       weighted fair queue
            |
 deadline + aging + token-cost ordering
            |
 continuous batching / preemption

调度单位应从“请求个数”转为 Token 和 KV 资源。线上同时看全局吞吐与每租户 TTFT/TPOT P95/P99、分配份额偏差、最大等待、抢占恢复成本；全局平均变好但小租户尾延迟恶化，不算公平。

完整版教学

1. 公平首先是一份服务契约

公平取决于产品承诺：免费与付费租户可以有不同权重，实时聊天与离线生成可以有不同 SLO，但同一等级内不应因请求到达时机或长度而无限受损。

因此应先定义每类请求的权重、最低份额、最大并发和截止时间，再选择算法。没有契约，只说“公平调度”无法验收。

2. LLM 请求为何难以调度

请求到达时知道 Prompt 长度，却通常不知道会生成多少 Token；长上下文占用更多 KV，每个 Decode 步也可能更慢。一个请求可能持续数百轮迭代。

调度器既要决定谁进入系统，也要决定每轮哪些 Prefill 和 Decode 执行。资源需求动态增长，使传统固定时长任务假设不成立。

3. FIFO 的优点与局限

FIFO 按到达顺序服务，易解释且不主动插队。但队首若是超长 Prefill，后面的短请求也必须等待，形成 Head-of-Line Blocking。

queue: [20K prompt][100][80][120]
FIFO : short requests wait behind the 20K request

Chunked Prefill 能缓解独占，但 FIFO 本身仍无法表达租户权重和截止时间。

4. 最短作业优先的取舍

按预测 Token 或服务时间优先短请求，通常能降低平均完成时间和 TTFT。然而长请求如果不断被新短请求插队，会永久饥饿。

而且输出长度只能预测，低估会让任务进入后长期占用资源。应结合等待时间老化，并用实际消耗动态修正剩余成本。

5. 严格优先级为什么危险

严格优先级在高等级流量持续到达时，低等级队列得不到服务。它适合短时事故流量，不适合作为唯一长期策略。

更稳妥的是加权份额：高优等级获得更多资源，但低优等级保留最小份额；空闲时允许借用，拥塞时按契约收回。

6. 加权公平队列如何理解

可为租户 i 设置权重 wi，在持续拥塞时，使其长期服务 Token 份额近似：

share_i = wi / Σj(wj)

实际实现可用 Deficit Round Robin：每轮为队列增加额度，只有额度足以支付预计 Token 成本时才调度。未用额度可结转，使大请求最终有机会执行。

7. 为什么按 Token 计费更合理

按请求轮询会把 100 Token 与 20K Token 视作相同成本，长请求租户会获得更多资源。以输入 Token、输出 Token 或估算 GPU 时间记账，更接近真实消耗。

Prefill 和 Decode 的单位 Token 成本不同，还可分别设置权重。成本模型不必绝对准确，但要记录预测与实际差异并持续校准。

8. 等待时间老化怎样防饥饿

老化让请求等待越久，有效优先级越高：

effective_priority = base_priority + aging_rate × waiting_seconds

老化率太低不能解除饥饿，太高会快速抹平业务等级。可同时设置最大等待时间，超过后强制获得一次服务或转移到保留容量。

9. 截止时间调度何时适用

有明确 Deadline 的 API 可使用 Earliest Deadline First，并在调度前预测能否按时完成。已经不可能满足的请求应快速失败，而不是消耗资源后仍超时。

Deadline 也必须可信，不能由客户端随意伪造。相同 Deadline 下再结合权重与成本，避免大量昂贵任务同时进入。

10. Prefill 与 Decode 如何协调

长 Prefill 会阻塞正在流式输出的 Decode，使 TPOT 抖动；只服务 Decode 又可能让新请求长期拿不到首 Token。Chunked Prefill 将长输入分块，与 Decode 轮次交错。

调度偏向	收益	风险
Prefill 优先	新请求更快开始	现有流式输出卡顿
Decode 优先	TPOT 更稳定	TTFT 和队列增长
分块混合	两者可配额平衡	调度与块大小更复杂

应分别为 Prefill Token 与 Decode Token 设每轮预算。

11. 抢占如何控制代价

高优任务到达时，可暂停低优序列。若 KV 保留，抢占不释放显存；若 Swap 或丢弃重算，则有传输或 Prefill 恢复成本。

只有高优请求收益大于抢占成本时才应抢占，并限制单请求最大抢占次数。频繁来回切换会产生 Thrashing，使所有请求都变慢。

12. 多租户隔离与借用

每租户设置并发、Token 速率和 KV 配额，避免单租户占满资源。保留份额暂时空闲时可借给其他租户，提高利用率；原租户流量恢复时逐步收回。

借用不能破坏正在执行请求的基本承诺。可优先不再接收借用方新请求，而不是立刻终止大量活跃请求。

13. 公平性怎样量化

除吞吐与延迟外，至少按租户和任务类别报告资源份额、最大等待、Deadline 违约和抢占次数。可用 Slowdown 衡量相对伤害：

slowdown = shared_system_completion_time / isolated_completion_time

若某类请求 Slowdown 长期远高于其他类别，说明它在共享系统中受到不成比例的影响。也可用 Jain 公平指数观察份额分配，但不能代替 SLO。

14. 如何压测和上线

构造短长请求混合、大小租户混合、持续高优流量和突发 Prefill 四类场景。验证低优请求最终能完成，高优 SLO 达标，且抢占成本没有抵消调度收益。

灰度时同时比较全局指标和分组指标，设置最大等待、租户 P99、饥饿事件与份额偏差阈值。调度配置需版本化并能快速回滚。

公平调度不是让所有请求一样快，而是让资源分配符合明确契约，并且任何合法队列都不会无限等待。

15. 常见误区与追问

误区：FIFO 天然最公平。 它按到达顺序公平，却会造成长任务队首阻塞。
误区：短请求优先对所有人最好。 它改善平均值，但可能饿死长请求。
误区：高优先级应该无限抢占。 频繁抢占会增加恢复成本并伤害低优保障。
误区：按请求数分配就是公平。 不同请求的 Token 和 KV 成本差异很大。
误区：只看全局 P99 就能判断公平。 应按租户、等级和长度分桶观察。
追问：如何保证长请求最终完成？ 使用额度结转、等待老化与最大等待保障。
追问：空闲份额能否借用？ 可以，但要能在拥塞时按契约收回且不引发抢占震荡。

16. 加强记忆

先定契约：权重、最低份额、SLO 和截止时间。
再记局限：FIFO 阻塞，短作业饥饿，严格优先级压死低层。
再记计量：按 Token、KV 或 GPU 时间，而非只按请求数。
再记修正：等待老化和额度结转保证最终服务。
再记阶段：Prefill 与 Decode 分别设预算。
再记隔离：租户配额可借用，但要安全收回。
最后记验收：分组 P99、最大等待、Slowdown 和饥饿次数。

简化版

详细版