大模型推理的请求调度算法——FCFS、连续批处理与优先级队列的多维对比一、背景与问题大模型推理服务的核心瓶颈不在单次推理的延迟而在并发请求的调度效率。当推理网关同时接收到数十个请求时如何组织这些请求的执行顺序直接决定了 GPU 利用率、TPOTTime Per Output Token和排队延迟三个核心指标。我们在部署 Llama-3 70B 模型的生产集群中发现同样的硬件配置8×A100vLLM 框架仅仅将调度策略从默认的 FCFS先来先服务切换为 Continuous Batching连续批处理就能将并发吞吐提升 2.3 倍P99 延迟降低 67%。本文将对比分析三种主流调度算法在生产场景中的表现差异。二、方案设计2.1 调度算法的核心矛盾推理请求调度的特殊之处在于不同请求的输入/输出长度差异极大从 50 Token 的问答到 4000 Token 的文档摘要且输出是逐步生成的自回归解码。这导致传统微服务领域的调度策略如轮询、最少连接不能直接套用。flowchart LR subgraph 请求到达 A1[请求A: 50 Token输入br/预计输出 200 Token] A2[请求B: 2000 Token输入br/预计输出 800 Token] A3[请求C: 200 Token输入br/预计输出 100 Token] end subgraph FCFS 策略 B1[A → B → Cbr/总耗时: A等待0B等待AC等待AB] end subgraph Continuous Batching 策略 B2[Batch[A]: A执行br/Batch[B]: A继续 B开始br/Batch[C]: A完成 C开始 B继续br/总耗时: 大幅减少] end subgraph 优先级队列策略 B3[短请求优先br/C → A → Bbr/平均等待降低] end A1 -- B1 A2 -- B1 A3 -- B1 A1 -- B2 A2 -- B2 A3 -- B2 A1 -- B3 A2 -- B3 A3 -- B32.2 三种算法的核心特征算法核心机制吞吐量平均延迟尾部延迟实现复杂度FCFS严格按到达顺序一个一个处理低高极高极低Continuous Batching动态组批完成一个立即插入下一个高中中中等优先级队列按优先级排序短请求优先中高低中低较高三、实战演示3.1 vLLM 中的调度参数配置 vLLM 推理引擎的调度配置示例。 调度策略通过 SchedulerConfig 控制max_num_seqs 决定最大并发批处理数。 from vllm import LLM, SamplingParams from vllm.config import SchedulerConfig import time import logging logging.basicConfig(levellogging.INFO) logger logging.getLogger(__name__) def create_inference_engine_with_scheduler( model_name: str, max_batch_size: int 256, max_num_seqs: int 64, policy: str fcfs # fcfs 或 priority ): 创建配置了特定调度策略的推理引擎。 关键参数说明 - max_num_seqs同时处理的序列数上限直接影响 Continuous Batching 的并发度 - max_num_batched_tokens单次迭代的最大 Token 数决定批处理效率 try: scheduler_config SchedulerConfig( max_num_batched_tokensmax_batch_size, max_num_seqsmax_num_seqs, policypolicy ) llm LLM( modelmodel_name, tensor_parallel_size8, gpu_memory_utilization0.9, scheduler_configscheduler_config ) logger.info( 推理引擎初始化完成: model%s, max_seqs%d, policy%s, model_name, max_num_seqs, policy ) return llm except Exception as e: logger.error(推理引擎初始化失败: %s, e) raise RuntimeError(f引擎创建异常: {e}) from e def benchmark_scheduler_performance(llm: LLM, prompts: list[str], output_len: int 256): 基准测试并发发送请求统计吞吐与延迟。 sampling_params SamplingParams( temperature0.0, max_tokensoutput_len ) start_time time.time() outputs llm.generate(prompts, sampling_params) elapsed time.time() - start_time total_tokens sum(len(o.outputs[0].token_ids) for o in outputs) throughput total_tokens / elapsed latencies [] for o in outputs: latencies.append(o.metrics.arrival_time) # 简化使用首 Token 时间 return { throughput_tokens_per_sec: throughput, avg_latency_ms: sum(latencies) / len(latencies) * 1000, p99_latency_ms: sorted(latencies)[int(len(latencies) * 0.99)] * 1000, elapsed_sec: elapsed }3.2 自定义优先级调度器vLLM 原生支持基于请求到达时间的优先级但在企业场景中我们需要根据业务优先级如付费用户优先、短请求优先进行调度。以下是一个自定义调度策略的实现思路/** * 自定义推理请求优先级调度器。 * * 设计原则短请求优先SJF近似 业务优先级权重 * 同时通过老化机制避免长请求被饿死。 */ public class InferenceRequestScheduler { /** * 计算请求的综合优先级分数。 * 分数越低优先级越高类似优先队列的默认排序。 * * param request 推理请求 * param waitingTimeMs 已等待时间毫秒 * return 优先级分数 */ public static double calculatePriority(InferenceRequest request, long waitingTimeMs) { try { // 期望 Token 数量的归一化值估计 int estimatedTokens request.getEstimatedOutputTokens(); double tokenFactor Math.log1p(estimatedTokens); // 对数平滑 // 业务优先级1-51为最高 int businessPriority request.getBusinessPriority(); double priorityFactor businessPriority * 2.0; // 老化因子每等待 1000ms优先级提升 1 分 double agingFactor waitingTimeMs / 1000.0; // 综合分数 Token因子 业务权重 - 老化补偿 double score tokenFactor priorityFactor - agingFactor; // 分数裁剪到 [0, ∞) return Math.max(0.0, score); } catch (Exception e) { throw new IllegalArgumentException( 优先级计算失败: e.getMessage(), e); } } /** * 从待处理队列中选择下一批请求。 * 使用贪心策略选择优先级最高的 N 个请求。 * * param backlog 待处理请求队列 * param maxBatchSize 每批最大请求数 * param maxTokens 每批最大 Token 数 * return 被选中的请求列表 */ public ListInferenceRequest selectBatch( PriorityQueueInferenceRequest backlog, int maxBatchSize, int maxTokens) { ListInferenceRequest batch new ArrayList(); int currentTokens 0; // 临时队列处理完后再放回未选中的请求 ListInferenceRequest temp new ArrayList(); while (!backlog.isEmpty() batch.size() maxBatchSize) { InferenceRequest req backlog.poll(); if (req null) { break; } int reqTokens req.getEstimatedOutputTokens(); // 检查 Token 预算 if (currentTokens reqTokens maxTokens) { temp.add(req); // 暂存待下批处理 continue; } batch.add(req); currentTokens reqTokens; } // 将未选中的请求放回队列 for (InferenceRequest req : temp) { backlog.offer(req); } return batch; } }四、深度解析4.1 Continuous Batching 的工程原理Continuous Batching 是 vLLM、TGIText Generation Inference等框架的核心创新。其关键洞察是自回归解码中每个请求的生成阶段长度不同。当某个请求完成生成后GPU 不应该空等其余请求——应立即插入一个新的请求继续批处理。实测数据Llama-3-70BH200 × 81024 并发策略吞吐 (Token/s)P50 延迟 (ms)P99 延迟 (ms)GPU 利用率FCFS3,24012,80045,20042%Continuous Batching7,4504,20014,80087%优先级队列短优先6,8903,10018,90081%连续批处理将 GPU 利用率从 42% 提升到 87%因为 KV Cache 的高效复用减少了 GPU 空闲周期。4.2 优先级队列的饥饿问题单纯按 Token 数排序会导致长请求被无限推迟。生产环境中必须引入老化机制。我们的方案是每等待 1000ms请求的优先级提升 1 个分值单位。经过测试在 QPS 200 的场景下最长请求的等待时间从无老化策略的理论无限长降低到 8.3 秒。4.3 动态批处理大小的自适应调整批处理大小并非越大越好。过大的批次会增加单次迭代延迟与短请求的 SLA 冲突。vLLM 0.6.0 引入了enable_chunked_prefill将长输入请求的 Prefill 阶段切分为多个 Chunk与正在生成的请求交错执行进一步优化了 GPU 计算单元的利用率。五、总结推理请求调度是从能用到好用的关键一步。三种策略的适用场景FCFS仅适用于原型验证和低并发场景生产环境不建议。Continuous Batching当前最优的通用策略吞吐和延迟折中最优适合大多数在线推理场景。优先级队列适合需要保证 SLA 的业务场景如付费用户优先但需配合老化机制避免饥饿。在架构设计上建议在推理网关层实现业务优先级的初步过滤将是否执行的决策前置到批处理之前与引擎层的 Continuous Batching 形成两级调度体系。这种组合在线上运行 6 个月后P99 延迟从 14.8 秒进一步降低到 9.2 秒同时 GPU 利用率稳定在 85% 以上。作者程序员鸭梨李然Java 架构师关注 AI 推理工程化与企业架构演进。欢迎留言交流你的调度优化经验。
