AI推理服务的GPU资源调度：动态批处理与显存预算实战

我最早接触GPU资源调度，是因为某平台的推理服务在一次流量高峰里整段崩掉。几张显卡摆在那，跑了好几个模型，表面看风平浪静，结果活动流量一上来，请求全部堵在服务入口，超时雪崩一波带走。事后看监控，一张卡显存快撑爆，另外两张卡利用率不到三成。问题不在模型推理本身，而在整个服务缺少一个负责任地分配GPU资源的调度层。

AI模型推理的GPU资源调度，说白了就是回答三个问题：一批请求同时到了先让谁算？一个模型副本该放哪块卡上跑？卡不够的时候到底先扩谁？这三个问题听起来简单，真落地满身都是坑，而且每个坑都跟训练场景的经验对不上。

这篇文章把我在实际项目里踩过的坑和最终沉淀下来的方案完整写一遍。适合正在做推理服务部署、被显存碎片、请求排队、GPU利用率不均折磨的同学参考。无论你是打算自研一套轻量调度器，还是准备用社区方案改造，核心原理和排查套路是通用的。

1. 推理GPU调度的本质：为什么不能照搬训练调度

1.1 训练调度和推理调度是两个物种

很多人一开始接触GPU调度，脑子里想的都是训练集群的那套逻辑：任务来了排个队，等到有空卡就整卡分配，任务跑完再释放。这套逻辑在训练场景完全没问题，因为训练任务是长任务，一跑就是几十分钟甚至几小时，调度器只需要做一次决定，后面基本不用管。

但推理请求完全不一样。一个HTTP请求从进入到返回，预算就是一两秒，模型推理本身可能只占几百毫秒。如果也按训练那套"排队等空卡"来搞，请求早就超时了。更麻烦的是，推理请求占用的资源不是静态固定的——同一个模型的同一个副本，同时处理1个请求和处理16个请求，KV Cache占用的显存可以差出十几GB。训练任务的资源需求量是"分配时就锁死"，推理请求的资源需求量是"随着并发动态伸缩"。

用一个生活类比：训练调度像是包场订健身房，预约了就能独占一整块区域，练多久都行；推理调度像是餐厅翻台，每个客人只能占几分钟桌子，翻台率上不去，再大的店面也得排队排到街上去。

1.2 调度的三个核心维度

我后来把推理场景的GPU调度拆成了三个维度，每个维度解决的问题都不一样，用一套方案硬包所有问题是行不通的。

第一个维度是请求级调度。核心矛盾是：一批请求同时到达，是攒一批一起算，还是来一个算一个？攒批能提高吞吐，但攒太久会让单请求延迟飙升。这个维度管的是"先让谁算、怎么凑批"。

第二个维度是模型级调度。核心矛盾是：线上跑着好几个模型，每个模型要几个副本？副本是常驻还是动态扩缩？显存不够的时候哪个模型让位？这个维度管的是"模型副本的命和资源预算"。

第三个维度是实例级调度。核心矛盾是：集群里有几十张卡，每张卡空闲情况不一样，到底哪个模型副本落到哪张卡上？要不要考虑GPU拓扑、同模型副本之间的通信开销？这个维度管的是"卡位分配"。

三层调度加在一起，才算是一个完整的推理GPU资源调度方案。很多项目出问题，就是因为只做了第三层——有卡就塞，前两层完全没管。

1.3 调度器应该放在哪一层

架构上我不是很建议在推理引擎内部去改调度逻辑，那是推理框架该干的事，也就是像动态批处理、KV Cache管理这些。我们自己做调度器，应该站在引擎之上一个身位，管理的是"副本数量、请求路由、实例分配"这些更高一层的东西。

原因很简单：推理引擎迭代太快，你今天对着某个版本的源码把调度逻辑写死进去，下个版本可能就变了。调度器跟引擎解耦，引擎只负责"给我一个批处理窗口让我跑得够快"，调度器负责"给你多少并发、给你多少个副本、让你在哪些卡上跑"，这样两边都简单。

2. 请求级调度：动态批处理与显存预算

2.1 动态批处理才是吞吐的王道

先聊请求级调度里最关键的一件事——动态批处理。传统的静态批处理是等一批请求攒够了再统一推理，比如攒够8条就一起算，攒不够就干等。这个机制的问题很明显：低峰期请求稀稀拉拉，每条请求都要等好久才凑够一批，延迟直接爆炸。

动态批处理的思路完全不同。它不要求请求同时到来，而是让同一条推理序列在处理过程中动态地加入、退出批次。简单说，静态批处理是等满一车人才发车，动态批处理是公交车每站都停，新乘客随时上车，到站的随时下车，这样每个乘客的平均等待时间都大幅下降。

实际项目里，我们用的是"连续批处理"的思路，在每一个解码步都重新评估当前批次的组成。新来的请求如果显存预算允许，就立刻插入当前批次；已经生成完毕的序列马上退出，把位置让给后面的请求。这个机制对吞吐的提升非常直接——我见过某团队用同一个7B模型做压测，静态批处理并发打到20请求/秒的时候，动态批处理直接把吞吐干到3倍以上，同时P95延迟反而从4.8秒降到了790毫秒。

2.2 KV Cache：推理调度的隐形资源瓶颈

要理解动态批处理，就绕不开KV Cache。这是推理请求占显存的大头，也是调度系统里一个特别容易翻车的地方。

KV Cache的计算公式不复杂，按字节算大概是：

KV Cache Bytes = 2 × 层数 × hidden_size × batch_size × seq_len × dtype_bytes

这里的2代表K和V各一份。以7B模型为例，如果模型是32层、hidden_size是4096，批大小16、序列长度2048、FP16精度，那KV Cache占用的显存大概是：

2 × 32 × 4096 × 16 × 2048 × 2 ≈ 17.2GB

什么概念？7B模型FP16的权重本身才14GB，一个大批次请求的KV Cache就能比权重还占地方。这还没算中间激活和算子运行时开销。所以调度系统必须给每个模型副本设定一个"显存预算"，预算里权重占固定份额，KV Cache占动态份额。批处理可以动态伸缩，但不能无限涨，涨到预算上限就必须让新请求排队。

2.3 批处理窗口怎么定

动态批处理虽然比静态的好，但也不是说窗口越长越好。窗口时间越长，攒的请求越多，单次吞吐越高，但请求等待时间被拉长。这里需要算一笔账。

假设线上要求的P95延迟是1秒，单条请求平均解码耗时80毫秒，那么留给调度系统的整体时间预算大概就是920毫秒。这920毫秒里还要拆给排队、批处理窗口、调度开销、网络传输。经验上，批处理窗口最多只能占延迟预算的三分之一到四分之一。按这个算，100到200毫秒的窗口是一个在大多数场景下都比较稳的选择。超过200毫秒，单请求等待感会很明显，尤其对那种用户直接等待返回的同步接口，体感就是"卡了一下"。

一个实操技巧：批处理窗口不要用固定值，建议做成动态可调的配置，根据实时负载自动微调。高峰期窗口可以适当缩小，以延迟优先；低峰期窗口可以放大，以吞吐优先。后续我会专门讲为什么动态阈值这么重要。

2.4 批大小上限的估算方法

批大小上限不是拍脑袋定的，它由显存预算直接推出来。继续用刚才的7B模型举例。

假设单卡是80GB显存，分配权重14GB，预留8GB给运行时、算子、激活值，剩下的58GB全部可以用于KV Cache。前面已经算了单个序列（seq_len 2048）的KV开销是2048时约103MB——等一下，这里我重新算得更清楚一点：单个序列的KV Cache是 2 × 32 × 4096 × 1 × 2048 × 2 ≈ 1074MB。那58GB差不多能支撑54个并发序列。如果业务预期最大并发不会超过40，批大小上限就定40甚至再保守一点定32，留出余量。

这个估算方法适用于任何模型。先拿到模型结构和精度，算出权重和单序列KV开销，再减去运行时开销，就知道这块卡最多能接多少并发。调度系统在决定"要不要把新请求塞进当前批次"时，不是看当前批数有没有到固定上限，而是看当前已申请KV Cache加上新请求的预估KV开销，有没有超过显存预算。后者才是真正安全的判断方式。

3. 模型级调度：副本管理、显存预算与模型亲和性

3.1 显存预算到底怎么设计

模型级调度最先要解决的是"一个模型最多能用多少显存"。我在项目里最先踩的坑就是没做预算，结果一个模型实例在显存充足时疯狂接纳请求，等另一个高优模型需要扩容时发现没地方放了。

后来我们做了两层的显存预算。第一层是模型级别的固定预算，每个模型在部署时声明自己需要的显存额度，等于权重显存加上最大KV Cache缓冲，再加上一倍的中间激活余量。调度器在创建副本时校验，当前空闲显存不够就直接拒绝扩容，而不是让副本创建之后跑着跑着OOM。

第二层是请求级别的动态预算，前面已经说过，就是每个副本内部维持一个"当前KV Cache可分配上限"。这两个预算一个控制横向的副本数量，一个控制纵向的单副本并发深度，双保险。

3.2 副本扩缩容策略

推理副本的扩缩容我是强烈不建议直接看"GPU利用率"这一个指标去做的。原因很简单：GPU利用率高可能是好事（正在高效处理请求），也可能是坏事（请求堆积，计算能力已经打满但依然处理不过来）。更合理的扩缩容触发条件是"请求队列深度"。

队列深度超过某个阈值，说明已经有请求排队等待分配了，这时候才应该扩容。某团队当时的做法是：每个模型的独立队列深度如果超过50，持续30秒，就扩容一个副本；如果队列常年为空，GPU平均利用率低于20%，持续10分钟，就缩掉一个副本。这个策略比单纯按GPU利用率扩容要稳得多，最大好处是不会在请求量还没上来的时候就浪费卡。

具体的扩容策略用类似水平自动扩缩的配置来表达会清晰很多。比如下面这个外置指标扩缩容的伪配置：

metrics: - type: External external: metric: name: model_a_queue_depth target: type: AverageValue averageValue: 50 - type: External external: metric: name: model_a_gpu_avg_util target: type: AverageValue averageValue: 20

队列深度的Target值不是随便定的，它约等于"单个副本期望并发能力"乘以一个缓冲系数。如果单个副本能稳定支撑30并发，那队列深度阈值可以设在45到60之间——超过这个值说明一个副本已经吃不下新流量了，再排队下去延迟要超标。

3.3 模型副本的亲和性：别把通信开销不当回事

模型副本分配卡位的时候，很多人只看显存大小够不够，忽略了GPU之间的通信拓扑。尤其是模型大到单卡放不下，需要用张量并行拆分到两张卡甚至四张卡时，卡位选得好不好直接决定推理延迟。

如果两张卡之间走PCIe，而另一个方案是走NVLink或者同节点的高带宽互联，出来的推理延迟差距可能翻倍。我见过一个案例，某团队把4卡张量并行的模型副本跨节点拆了两份，结果每次前向计算都要走网络做集合通信，P95延迟从300毫秒涨到700多毫秒，排障排了一天才发现是卡位拓扑的问题。

所以调度器在给模型副本分配GPU时，必须优先满足亲和性约束：同一个模型副本的各张卡尽量在同一个节点、同一张NVLink互联域里。碎片化的GPU资源宁可保持空闲，也不要为了"把卡塞满"而跨拓扑部署大模型副本。

3.4 冷启动成本必须算进扩缩容决策里

很多人忽略的一点是，模型副本从启动到真正能接流量，中间有一段冷启动时间。常见的序列化格式加载7B模型的权重到显存，快则几十秒，慢则几分钟。如果扩缩容策略只看队列深度，等队列报警了才扩容，等副本真正拉起来，高峰期可能都快结束了，白白浪费了资源，而且还因为扩容太慢导致服务SLA受损。

所以调度系统要维护一张表，记录每个上线过的模型的冷启动耗时。某个模型副本的冷启动时间超过60秒的，扩缩容策略里就要加"提前扩容"的偏移量——队列深度还没到阈值但增长斜率很陡的时候，就提前触发扩容。最激进的方案是给核心高优模型常驻一个"热副本池"，请求量还没上来但副本已经加载完毕，随时候命。多消耗一点显存换冷启动延迟的消除，对线上高优服务来说是值得的。

4. 实例级调度：编排循环、分配算法与优先级约束

4.1 调度器的三个组件

一个轻量自研调度器通常会拆成三个组件：逻辑队列、调度循环、分配器。

逻辑队列是按模型维度分解的，每个模型一个独立队列，队列里存的是等待分配的推理请求。这样做的目的很明确：不能让一个热门模型的请求把其他模型的请求堵死。

调度循环是一个常驻循环线程，不停的扫描所有逻辑队列和当前的GPU资源视图。每隔几十毫秒做一次决策：哪些副本的批处理窗口该关闭了、哪些模型该扩容了、哪些请求该超时踢出了。

分配器是最下层的东西，负责把一个模型副本绑定到具体的GPU集合上。它读GPU资源视图，检查显存、拓扑、亲和性约束，然后执行绑定。绑定完成之后，副本才被标记为可调度。这个组件还负责在GPU空闲碎片位置回收副本，把不再使用的副本显存归还给资源池。

4.2 首次适应还是最佳适应

GPU分配算法上，推理场景我跟团队的结论是：默认选首次适应，附加一个"同模型聚簇"的条件。也就是分配卡位时，优先选第一组满足显存和亲和性约束的GPU，如果一组卡上已经有一部分空闲显存归同一个模型使用，优先填到这个模型的已有聚簇里。

最佳适应算法看起来很美好，每次找"最紧"的卡位，能把资源利用率抠得很细，但它的代价是碎片化。每次都塞进不同的卡，过一段时间GPU资源视图会被拆成几十个细碎空洞，后续大模型副本根本塞不进去，调度成功率反而下降。首次适应加上聚簇条件，就相当于一直在做资源的"隐式整理"，让同一个模型的副本尽量集中，减少碎片。

4.3 多级优先级的抢占机制

GPU调度不可能完全等优先级——优先级高的请求来了，如果所有资源都被占满，要不要把低优先级的请求踢下来？我的建议是：不要让低优先级请求"立刻被杀死"，而是给抢占设置一个退避的时间窗口。

具体做法是，每个请求带一个优先级标签，低优先级请求在进入推理队列之前，调度器会给它打一个"可以被抢占"的标记。当高优请求需要资源而当前副本的批处理窗口已满时，调度器等待当前低优请求的生成阶段结束。这个退出点可以是"当前一个batch的迭代完成"，而不是中途掐断。让一个正在生成token的请求突然中断，浪费的不只是这一次的计算，而是整个队列的连贯性。

抢占的前提是所有请求都能快速失败。如果请求被打上"可抢占"标记后，调度器迟迟不处理，低优先级的请求可能需要等非常久。所以调度器要保证一个全局的等待上限，比如低优请求排队超过5秒，无论如何都要给它分配一次资源，避免饥饿。

4.4 在线与离线资源池隔离

一台GPU机器上如果既跑在线推理服务，又跑离线批处理任务，两种负载必须通过资源池隔离开。离线任务的特点是"有多少卡就能吃多少卡"，一旦跟在线服务混池，离线任务启动时很容易把显存和算力全部打满，在线推理请求哪怕优先级再高也得排队。

我们在某平台踩过一次这个坑。后来把所有GPU节点按角色分成在线池和离线池，在线池里的卡只跑推理服务，离线池的卡跑批处理任务。两个池子之间可以动态调配，但调配必须通过调度器，而不是离线任务自己抢。Online池设置了一个最小保底卡数，任何时刻都不允许离线段把在线池吃到低于保底线。这个机制后来成了所有资源池设计的底线。

5. 队列、超时与优先级：让请求不至于堵死在系统里

5.1 每个模型独立队列是底线

调度器必须为每个模型维护独立的请求队列，而不是全局一个大队列。原因不复杂：不同模型的推理耗时差异非常大，一个小的对话模型可能20毫秒出一个token，一个大的生成模型可能要200毫秒。把这两种请求塞进同一个队列，队首的大模型请求会让后面所有小模型请求无限期等待，活生生制造"队头阻塞"。

独立队列的另一个好处是每个队列的深度、等待时长都能单独监控。某个模型的队列如果长期积压，说明要么这个模型副本不够，要么这个模型的推理性能出了问题。每个队列独立，才能准确定位问题出在谁身上。

5.2 超时控制：快速失败比无限等待更优雅

推理服务最怕的一个状态就是"所有请求都堵在队列里，谁也别想好"。这种情况通常是上游流量突增，下游推理能力已经打满，队列越积越长，新请求排队时间越来越久，最终所有请求一起超时。

为了避免这个状态，队列里的每个请求从进入调度器开始就记一个"截止时间"，到期还没分配到计算资源就直接返回超时错误。这个设计跟"无限等待"的思路相反，但它能保证系统的整体行为可控——最坏情况下就是一部分请求被快速拒绝，而不会是所有请求全部卡死。对用户来说，快速失败永远比转圈等半天然后失败要体面，因为用户还有机会立刻重试，而不是白白消耗耐心。

5.3 重试的退避策略

客户端收到超时之后通常会重试，如果成千上万个客户端同时重试，会形成重试风暴。调度器层面要限制同一请求的重试次数，服务端要记录每个请求的唯一标识，同一个标识的重试请求不会重复进入队列两次。合理的重试策略是指数退避：第一次重试等100毫秒，第二次等200毫秒，第三次等400毫秒。这个策略在高峰期非常有用，它能自然地摊开重试请求的到达时间，而不是让所有重试再次汇聚成尖峰。

5.4 在线服务的混合流量控制

还有一个容易被忽略的场景：同一个模型可能同时承担在线实时请求和近线批量任务。比如某平台同时用同一个生成模型服务用户点击产生的实时请求和老数据集的离线处理任务。离线任务的特点是数量大、容忍延迟高、可以分片处理。

这种场景下不要让离线任务跟在线请求走同一个调度通道。离线任务应该被打包成独立的批量任务，调度器只在"在线队列空闲超过一定时间"时才放行离线任务，在线流量上来时立刻暂停离线任务，把计算资源让给在线请求。这个"空闲时兜底跑、繁忙时立刻让路"的策略，能让GPU的利用率在低峰期也不至于完全浪费，高峰期又能保证核心SLA。

6. 观测体系与自动扩缩容：先看清再动手

6.1 调度系统必须看的六个指标

调度器本身不产生业务价值，它只是让GPU资源用得更合理。但如果观测体系做不好，调度器就是一台"黑盒分配机"——卡位分配完之后你不知道发生了什么，也没法把问题定位到具体的决策上。

至少盯住这六个指标：模型副本数、每个副本当前的批处理并发数、每个模型的请求队列深度、队列里请求的最长等待时间、GPU显存分配率、GPU平均利用率。前三个指标是调度器的"工作负荷"，后两个是GPU资源的"水位"。

最有用的一组关联是"队列深度"和"GPU利用率"一起看。如果队列很深、GPU利用率很高，说明计算资源确实吃满了，要扩容。如果队列很深但GPU利用率很低，那大概率是批处理策略太保守或者调度循环有阻塞，不是缺卡，先查调度器自身的瓶颈。这两个指标能帮你把"缺算力"和"调度畸形"快速分离开。

6.2 自动扩缩容的滞后性怎么破

前面提到过冷启动滞后，这里再展开说。自动扩缩容普遍存在滞后性：请求量先涨，队列深度后涨，扩缩容策略再反应过来，副本启动还要几十秒。这一整套信号链路走完，高峰可能已经过去了。在推理场景，这个滞后性最直观的体现就是"扩容永远慢半拍"。

破解办法之一是做基于趋势预测的扩容。调度器不仅看当前的队列深度，还看队列深度的变化斜率。如果斜率连续几个采样周期都是陡增，说明流量在快速上涨，这时候不等阈值触发就提前扩容。另一个办法是为每个模型保存一份历史的流量画像，很多平台的流量是有明显的周期性的，比如每天早上10点和下午3点是高峰。基于周期性的预扩容虽然听着不够"智能"，但在成本控制上非常有效——提前把副本拉起来，高峰结束后再缩掉，这比晚扩容扛高峰稳定得多。

6.3 容量规划的估算方法

容量规划这件事其实可以在调度系统上线前就做。最简单的思路是：先用压测工具把单个副本的极限吞吐测清楚，然后根据业务的峰值QPS配置副本数下限。

比如业务峰值QPS是200，单副本压测能扛80，那至少需要3个副本。再考虑扩容滞后和流量瞬间尖峰，建议按1.5倍冗余预留，也就是配置5个副本。这5个副本就是调度器的常驻水位。在此基础上，队列深度触发的是"临时扩"，这5个副本是"保底扛尖峰"的底气。

没有人能在流量到来之前精确预测它，但压测加冗余能让调度器在流量突变时有足够的缓冲时间去计算和扩容。没有保底副本的调度器就像没有安全气囊的车，方向盘再精准也没用。

7. 常见问题与排查技巧实录

7.1 典型问题速查表

7.2 一个真实的排查过程

某次线上模型服务出现了一个很怪的现象：GPU利用率看起来只有30%多，显存占用却到了85%，而且请求延迟在持续上升。一开始团队所有人都在猜是不是模型反向推理变慢了，查了模型日志发现单次推理耗时没有明显变化。

后来把请求的等待阶段拆开看，发现大部分延迟是排队等待造成的。但GPU利用率不高说明推理引擎本身没有满负荷运转，为什么还在排队？再往深查，队列里全是等"批处理窗口关闭"的请求——因为动态批处理的窗口设成了500毫秒，请求到达后在batch里空等窗口关闭，单次推理只有80毫秒，但每个请求都等了大几百毫秒才被送进推理引擎。

调整办法很简单，把批处理窗口从500毫秒压到150毫秒，同时开启"队列积压超过N条立即关闭窗口"的策略。调整之后，P95延迟从2.1秒降到700毫秒，GPU利用率从30%涨到了70%。这个案例说明，性能问题有时候根本不是计算能力的问题，而是调度策略里一个参数跟业务流量特性不匹配。

7.3 三个值得记住的经验

第一个经验：调度器上线前先把"决策日志"留好。每一条请求进入哪个队列、分配到了哪个副本、批处理窗口关了没有，全部记录下来。没有日志，任何线上事故排查都会变成猜谜游戏。有日志，所有调度行为都是可回放、可审计的。

第二个经验：所有调度参数默认走配置中心，不要写死在代码里。阈值这个东西，没有谁能一次性定准。队列深度阈值、批处理窗口、缩容冷却时间、抢占时间窗口，这些都要能线上动态调整。写死在代码里的调度参数意味着每次调优都要发一次版本，没人愿意为了改一个数字走一遍发布流程。

第三个经验：先做"半自动"调度。调度器如果一开始就全自动扩缩容，线上出现事故时没人敢说清楚是哪一步自动决策出了问题。稳妥的路径是先让调度器生成"建议"——比如提示当前队列深度超标建议扩容，由人工确认后执行。跑上两三个流量周期，确认建议全部合理，再把人工确认环节去掉。这比一步到位全自动上线要可靠得多。

结尾

调度系统上线半年多，我最大的体会是：GPU资源调度不是一个一次性的架构工程，它是一个持续调参的过程。流量模型在变，模型服务在变，GPU硬件的规格也在变，今天调好的参数下个月可能就过时了。可观测性、动态配置、快速回滚这三件事的重要性，远超调度算法本身的高深程度。

最后再分享一个小技巧：做调度器的时候，把每个模型的"资源画像"都记录下来——权重大小、单序列KV Cache开销、压测单副本吞吐、冷启动耗时、延迟预算。这些数据平时看不出多大价值，但每次新模型上线、新流量预估、新GPU采购，都需要拿这套画像去推算。有了画像，调度器的所有决策都是基于数据而不是拍脑袋。

调度器做得再好，也只是让有限的GPU资源发挥出最大的价值。真正想清楚业务要什么，延迟预算卡在哪，成本红线在哪里，调度器才有方向。这大概是这个领域里最容易被忽略、也最重要的一句话。