摘要推理服务上线后请求会排队、会互相抢算力、会在高峰期堆积。一个付费用户的关键请求可能被一大堆低价值批量任务挡在后面前端体验直接崩塌。这篇文章讲的正是这件事在有限算力上怎么让对的请求在对的时间被处理。涉及排队模型、优先级策略与多租户公平共享。2026 奇点智能技术大会11 月 20-21 日·北京万达文华酒店AI Infra 与推理优化专题会讨论服务调度与容量治理。▸ 核心结论调度型问题先看分优先级的延迟分布只看队列长度会漏掉批内等待▸ 关键权衡严格优先级会让低优饿死加权公平更好但要给单租户设上限防一家独大▸ 适合谁读推理服务 owner 与 SRE——高峰期谁先被服务是成本还是性能的取舍本文的结构 现象 一 请求为什么会排起来含隐藏的批内等待 | 模型 二 排队模型能给什么判断 | 手段 三~五 优先级插队 / 多租户公平 / 与批处理的张力 | 落地 六~八 常见坑、衔接大会、落地顺序 优先级策略要做成可热更新的配置别硬编码成要发版才能改一、请求为什么排起来推理服务通常维护一个待处理队列。请求到达后先入队再由调度器分配给空闲的计算槽位。当到达速率超过处理速率队列就开始增长延迟随之上升。和训练不同推理对延迟敏感且有峰谷。白天高峰队列能涨几倍深夜又几乎空转。如果调度不为这种波动做设计要么高峰时全员超时要么低谷时算力浪费。还有一种隐性排队发生在批处理内部即便请求已被接收也要等凑成一个批才开始计算这段等待常被忽略却是尾延迟的重要来源。只看队列长度会漏掉这部分必须连同批内等待一起度量才能看清用户真实感知的延迟。峰谷还带来一个调度难题低谷时实例空转浪费高峰时又不够。纯按峰值预留成本太高纯按均值又会超时。弹性伸缩配合队列才能在这两者之间找到动态平衡而不是静态地定一个容量。排队还要考虑优先级反转低优任务若持有一个高优任务需要的资源会造成高优被低优阻塞。这种反转在共享缓冲和锁竞争时常见调度要识别并打破不能只按请求本身的优先级排。二、排队模型的基本判断模型假设启示M/M/1单服务台随机到达利用率过七成延迟陡增M/M/c多服务台加槽位能摊薄但不改本质有优先级高优先服务低优可能饥饿最实用的结论是单台利用率一旦过七成延迟会非线性恶化。所以容量规划要留出余量而不是把算力压到满负荷。利用率过七成这个经验值依赖服务时间的分布。若请求时长差异极大即使平均利用率不高一个长请求也可能把后面一串短请求堵很久平均延迟看起来还行p99 却已经爆炸。所以长尾分布比平均更该被盯紧。M/M/c 模型还假设到达是随机的但真实流量常有突发和周期性比如整点批量任务。用纯随机模型估计会低估高峰延迟要叠加突发因子否则容量规划看着合理一到整点就崩。模型假设还要校验真实到达往往是非平稳的纯 M/M/c 会低估风险。用历史流量回放来测容量比套公式可靠能暴露公式看不到的突发和周期容量规划也更贴近真实。三、优先级怎么插队最朴素的做法是严格优先级高优请求一到就抢占或插到队首。问题是低优请求可能永远排不上出现饥饿。折中方案是加权公平给不同等级分配不同权重长期保证比例短期允许高优先走。插队还要考虑是否抢占。推理计算中抢占成本高通常不做计算级抢占而是在「下一个请求开始之前」决定顺序也就是调度级优先而非抢占级优先。严格优先级还有一种简单实现是双队列高优队列空了才轮到低优。它实现成本低但低优在高峰几乎拿不到资源适合低优本就可延迟的背景任务。若低优也有时效要求双队列就不合适得上加权公平。优先级还要和处理时间结合若高优请求本身极长插队会长时间霸占槽位反而让中优也变慢。可以按预估处理时间再做加权避免单条长请求独吞资源这是纯优先级之外的第二层公平。插队还要设最大等待时限高优也不能无限插队导致中优饿死。给每条请求一个年龄年龄越大优先级自动升高能在保证高优的同时给中低优一条兜底出路防止极端饥饿。三种调度方式对延迟的影响 先来先服务 (FIFO) [长][短][短][长][短] - 短请求要等长请求算完平均等待最差 ^ └─ 队头阻塞 严格优先级 高优队列空了才轮到低优 - 高优快但高峰期低优几乎拿不到资源 适合低优本来就可延迟的场景 加权公平 (WFQ) 老化机制 按权重分配长期份额短期允许高优先先走 给每条请求记年龄等太久自动提权重 - 防止个别请求被永久饿死 一个必须额外处理的细节 批处理会让一条慢请求拖住同批所有人 - 优先级不能只看单请求还要看它对同批其他请求的影响 - 快慢分开批或者把极小批留给高优通道牺牲一点吞吐换延迟 实用经验给低优保留最低带宽 否则高峰期低优完全不动等到低谷集中爆发反而造成二次拥塞四、多租户公平共享当多个业务共用一个推理集群一个租户的大批量会把其他租户的延迟全部拖高这就是邻居效应。加权公平队列是把集群算力按权重分给租户既保证大租户的服务等级又不饿死小租户。实现上通常分两层先按租户做公平调度再在租户内部按请求优先级排。两层都做才能既防邻居效应又保关键请求。加权公平还要防一点某租户突然放量按权重它的份额变大可能挤占其他租户。通常要给单租户设上限防止一家独大拖垮整体。上限值要按业务峰值和可接受的最差情况反推而不是拍脑袋。公平队列的实现还要注意头部阻塞一个租户的一条长请求排在前面会挡住后面所有请求。要结合短请求优先或年龄加权让等待久的请求逐渐获得更高优先级防止个别请求 starvation。公平共享还要可观测到租户粒度出问题时能定位是哪家租户在挤占而不是只看全局指标。租户级监控是治理的前提没有它配额调了也证明不了是否有效更谈不上追责。五、和批处理的张力连续批处理追求高吞吐会尽量把同批请求凑一起算。但优先级调度要求高优请求尽快开始不能一直等凑批。两者天然有张力。常见解法是给高优请求单独的快速通道牺牲一点批效率换延迟低优请求走攒批通道用延迟换吞吐。把两类流量分开调度逻辑会清晰很多。攒批通道里低优请求可以容忍更高延迟于是把批做得更大更密把吞吐推到接近硬件上限这部分算力几乎是白赚的。关键是不要把低优的延迟期望误设成高优否则攒批通道会把本该快的请求也拖慢。批处理还放大了尾延迟一条慢请求会拖住整个批的完成时间让同批快请求一起变慢。所以优先级不能只看单请求还要看它对同批其他请求的影响必要时把快慢请求分开批。批处理还可以和优先级分层高优走单请求或极小批保延迟低优走大批量保吞吐。两层 batch 大小不同调度逻辑要分开混在一起会两头的优势都丢变成既慢又费。六、常见坑坑一是把队列长度当健康度唯一指标。队列长不一定坏如果请求都是低优批量、高优都秒回那很健康。要看分优先级的延迟分布而不是总数。坑二是优先级设了却不设上限导致低优任务在高峰期完全不动等到低谷才爆发反而造成二次拥塞。要给低优保留最低带宽避免极端饥饿。坑三把不同延迟要求的流量混进同一条队列却不区分。结果长任务拖短任务、短任务又占着槽位不让长任务排整体效率双输。分层或分通道是基本动作混流是上线后才暴露的典型问题。坑四把队列长度当成容量规划的唯一输入。队列长可能是容量不足也可能是调度配置错误导致请求堆积两者解法完全不同。要先区分再扩否则盲目加机器只加成本不加效果。坑五把优先级做成硬编码改一次要发版。优先级策略应做成配置能热更新否则业务调整优先级时要走冗长发布流程响应慢半拍高峰期根本来不及。七、衔接大会专题11 月 20-21 日北京万达文华酒店奇点智能技术大会的 AI Infra 基础设施专题会讨论推理服务的调度与容量治理C 及系统软件技术大会的 AI 算力与推理优化专题从算子与运行时的层面给出实现细节。带着「我们高峰期的 p99 延迟是多少、谁在排队」去参会问题会很具体。调度是推理服务从能用到好用的分水岭。带着自己高峰期的延迟分布去听别人讲的公平队列和优先级才有参照也更容易判断哪些能直接用到自己的集群上。容量与调度的分享里最值得听的是别人如何度量分优先级延迟。带着自己的 p99 分布去对照能快速定位是排队还是计算的问题。推理调度分享里最该学的是别人如何把优先级、公平、批处理做成一套可热更新的体系。带着自己的调度痛点去听能对号入座找到可搬的方案。八、落地顺序先上基础 FIFO 队列并埋好分优先级延迟埋点看清现状。再加优先级通道隔离关键流量。最后做多租户加权公平。一步步来否则一上来就多层调度出问题很难定位是哪一层在作怪。补充所有调度改动都要配分优先级的监控。没有分优先级的数据改了调度也证明不了有效只会陷入「感觉快了」的口头判断和真实用户体验脱节。最后调度改动要做灰度先对一小部分流量生效观察分优先级延迟再全量。直接全量切一旦配置有误影响的是全部用户回滚成本很高。最后调度策略要配影子模式新策略先并行跑但不生效对比新旧延迟分布确认更优再切换。直接全量切一旦策略有误影响全部用户回滚也麻烦。补充问答问利用率到多少延迟会恶化答经验上单台利用率过七成延迟就非线性上升。所以容量规划要留余量而不是把算力压到满负荷否则高峰会全员超时。问优先级调度会饿死低优吗答严格优先级会。要用加权公平给不同等级分配权重长期保比例、短期允许高优先走并给低优保留最低带宽避免极端饥饿。问推理能抢占吗答计算级抢占成本高一般不这样做。多在下一个请求开始前决定顺序也就是调度级优先而非抢占级优先避免中途打断浪费已算的部分。问批处理和优先级冲突怎么办答高优走单独快速通道牺牲点批效率换延迟低优走攒批通道用延迟换吞吐。把两类流量分开调度逻辑会清晰很多。问只看队列长度够吗答不够。队列长可能是低优批量在排、高优都秒回那很健康。要看分优先级的延迟分布而不是总数。大会信息2026 奇点智能技术大会 C 及系统软件技术大会时间2026 年 11 月 20-21 日地点中国·北京万达文华酒店大会报名免费领取大会PPT资料立即报名锁定 Lukasz Kaiser Keynote 与 70 场演讲完整资料
