尧图网页设计 
vLLM 请求调度全解一条 Prompt 从排队到出字的 5 个关卡【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllmvLLM 请求调度决定了哪个请求先上 GPU 显存、显存不够时谁被请出去是 LLM 推理服务里的指挥台。读完这篇你能说清一个请求的完整旅程显存告急、响应变慢时也知道该拧哪个旋钮。从一次 API 调用说起假设你部署了一个 vLLM 服务往/v1/chat/completions甩了条请求。接下来几百毫秒里你的 prompt 其实要闯 5 个关卡进等待队列请求落到 waiting 队列。默认按到达顺序排队启用优先级策略后则按 (优先级, 到达时间) 入堆抢显存块KV 缓存按块管理默认每块 16 个 token调度器每步都为请求分配它需要的块预填充整段 prompt 一次算完或者按 token 预算切成若干块分批算逐 token 解码每个调度步给这个请求生成一个新 token直到撞上max_tokens或结束符收尾释放块归还块池请求从运行队列里摘掉调度逻辑就住在引擎核心进程里下图能帮你把位置对上——vLLM 请求调度相关的 Scheduler 就挂在 EngineCore 这一步先记个印象v1 调度器里没有预填充阶段/解码阶段的分区概念每个请求只有已算了多少 token和一共要算多少 token两个数每步尽量让前者追上后者。就这一套机制同时覆盖了分块预填充、前缀缓存、投机解码。排队规则——谁先跑、谁后跑假设你一口气甩进来 10 个请求。谁先跑vLLM 给了两种排队策略由policy参数控制fcfs默认就是先来后到队列是个双端队列头部先进来的人先出队priority堆排序priority值越小越先跑对和直觉可能相反同优先级再比到达时间你可能会发现光靠这两种策略还不够长请求和短请求混排时还得靠分块预填充来救场。几种典型组合的效果场景调度行为效果10 个请求都同等重要默认 fcfs按到达顺序出队公平直观但队首一条长预填充会堵住后面 9 个其中 2 个是高优先级policyprioritypriority 值小的先跑高优先级插队低优先级的等待时间变长1 个长请求 9 个短请求长请求被切成多块短请求在块间隙插入长请求不再独占一个完整 prefill 步至于连续批处理一句话就能说清老请求每跑完一个 token新请求立刻插进当前批次不用等整批跑完。这也是为什么 vLLM 的实际吞吐比静态批处理高出一截——GPU 的空档期被压缩到了几乎看不见的程度。显存坐不下了分块、挪座、抢座把 GPU 显存想成一桌有限的座位KV 缓存就是坐上去的人。座位按块发满了就得挪座、抢座。座位怎么分块大小和水印KV 缓存被切成固定大小的块block_size默认 16。KV 缓存块大小怎么调记住权衡就行块越小显存利用越精细但管理开销和块表越大块越大最后一块可能浪费到 15 个 token 的座位。多数场景默认值就够用显存极度紧张时才考虑动它。另一个容易忽略的旋钮是watermark默认 0.0即不留余量。它的用法很具体只在新请求或被抢占的请求想进运行队列时生效要求新请求需要的块 预留的余量块都得有空闲才放行。已经坐在座位上的运行中请求不受它管。满了怎么挪交换去 CPU 是上一代的做法在 V0 时代显存不够可以把请求的 KV 缓存 swap 到 CPU 内存继续等位。但翻一下现在的 v1 调度器代码你会发现这条路被拆了——当前的抢占就是释放块、回等待队列重算没有 swap 这个中间态。如果你需要把 KV 挪到别的机器或远端存储那走的是 KVConnectorKV offloading、P/D 分离这套独立的扩展机制不是调度器内置动作。挪座的代价一句话被重算的请求它已经 prefill 过的那几千个 token 的 KV 全得从头算长上下文下这不是小数目。实在没座怎么抢preempt 怎么选人当新请求分配块失败时调度器会挑一个牺牲者踢出去fcfs 下选运行队列里最后进来的那个priority 下选 (优先级, 到达时间) 最大的那个——也就是最不该优先伺候的。两种思路的对比帮你把概念捋直swap 是 V0 的选项V1 默认走 recompute思路保留了什么代价适用场景SWAPV0 传统做法KV 缓存挪到 CPU 内存占 CPU 内存 来回搬运时间长上下文、CPU 内存宽裕RECOMPUTEV1 现行做法什么都不留prefill 算力从头再花一遍上下文不算太长、抢占预期不频繁vLLM 显存不够怎么办答案就在这三层先分块复用、再留 watermark 余量、最后才 preempt 重算。平时把水位控制好抢座动作根本轮不到出场。两个典型场景的应对长文本别一锅炖分块预填充怎么配场景 A用户甩来一篇 8000 token 的长文让你总结。如果 prefill 一锅炖这 8 千 token 会占满好几个调度步的预算其他请求的解码全得干等。实际跑起来之后你会发现enable_chunked_prefill默认就是开着的长文按每步剩余 token 预算切片每步只算其中一块默认上限就是max_num_batched_tokens2048块与块之间穿插着别的请求的解码谁也不卡谁。你可以这样调max_num_batched_tokens从默认 2048 提到 4096~8192长文 prefill 的总步数直接减半long_prefill_token_threshold默认为 0不限制设成 2048~4096 可以给长请求单独限流防止单条长文一步吞掉大半预算长文本多到离谱时顺手看一眼max_num_seqs默认 128别让一批里塞满长请求秒杀流量200 个请求突然涌入场景 B秒杀开始了200 个请求 3 秒内涌进来。这时候队列是你的第一道防线运行队列装不下max_num_seqs个多出来的老实排队再配上watermark留出余量块能避免刚放进一个请求就得马上抢座的抖动代码注释管这个叫 thrashing。如果还想在门口设闸max_num_queued_reqs可以限制在途请求总数超了直接回 HTTP 503 让客户重试到别的实例——这是最粗暴也最有效的容量阀。你可以这样调watermark设 0.01~0.05预留 1%~5% 的空闲块抢占频率肉眼可见地降下来max_num_queued_reqs按DP 实例数 × max_num_seqs 期望排队深度估一个值给队列封顶有 VIP 请求时切policypriority让付费用户的请求有资格插队上手前先看这几个旋钮参数管什么默认值什么时候该动它max_num_batched_tokens每步调度的 token 总预算2048长 prefill 太慢、或想给 prefill 更多份额max_num_seqs运行队列并发请求上限128并发上不去想换吞吐block_size每个 KV 块的 token 数16显存碎片化明显时watermark放行新请求时预留的空闲块比例0.0抢占/重算日志刷得太频繁policy排队规则 fcfs / priorityfcfs出现有优先级的请求long_prefill_token_threshold长请求单步 token 上限0不限长请求长期霸占预算max_num_queued_reqs在途请求上限超了回 503不限想让队列别把服务拖死三条踩坑提醒block_size不是越小越好设太大会让每个请求的最后一块白白占掉显存座位watermark只是新请求入门时的刹车不会把运行中的人踢下去别指望它治运行队列太挤priority是数值越小越先跑把 0 留给最重要的请求别按数值大重要去配想再往深处走直接打开vllm/v1/core/sched/scheduler.py从schedule()方法读起——先调度 running 队列、再消化 waiting 队列的完整逻辑都在里面排队策略的两种实现则在vllm/v1/core/sched/request_queue.py。对照着上面这张图走一遍源码vLLM 请求调度的家底你就算摸清了个别默认值可能随版本调整以实际版本为准。【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 vLLM 请求调度全解：一条 Prompt 从排队到出字的 5 个关卡
vLLM 请求调度全解一条 Prompt 从排队到出字的 5 个关卡【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllmvLLM 请求调度决定了哪个请求先上 GPU 显存、显存不够时谁被请出去是 LLM 推理服务里的指挥台。读完这篇你能说清一个请求的完整旅程显存告急、响应变慢时也知道该拧哪个旋钮。从一次 API 调用说起假设你部署了一个 vLLM 服务往/v1/chat/completions甩了条请求。接下来几百毫秒里你的 prompt 其实要闯 5 个关卡进等待队列请求落到 waiting 队列。默认按到达顺序排队启用优先级策略后则按 (优先级, 到达时间) 入堆抢显存块KV 缓存按块管理默认每块 16 个 token调度器每步都为请求分配它需要的块预填充整段 prompt 一次算完或者按 token 预算切成若干块分批算逐 token 解码每个调度步给这个请求生成一个新 token直到撞上max_tokens或结束符收尾释放块归还块池请求从运行队列里摘掉调度逻辑就住在引擎核心进程里下图能帮你把位置对上——vLLM 请求调度相关的 Scheduler 就挂在 EngineCore 这一步先记个印象v1 调度器里没有预填充阶段/解码阶段的分区概念每个请求只有已算了多少 token和一共要算多少 token两个数每步尽量让前者追上后者。就这一套机制同时覆盖了分块预填充、前缀缓存、投机解码。排队规则——谁先跑、谁后跑假设你一口气甩进来 10 个请求。谁先跑vLLM 给了两种排队策略由policy参数控制fcfs默认就是先来后到队列是个双端队列头部先进来的人先出队priority堆排序priority值越小越先跑对和直觉可能相反同优先级再比到达时间你可能会发现光靠这两种策略还不够长请求和短请求混排时还得靠分块预填充来救场。几种典型组合的效果场景调度行为效果10 个请求都同等重要默认 fcfs按到达顺序出队公平直观但队首一条长预填充会堵住后面 9 个其中 2 个是高优先级policyprioritypriority 值小的先跑高优先级插队低优先级的等待时间变长1 个长请求 9 个短请求长请求被切成多块短请求在块间隙插入长请求不再独占一个完整 prefill 步至于连续批处理一句话就能说清老请求每跑完一个 token新请求立刻插进当前批次不用等整批跑完。这也是为什么 vLLM 的实际吞吐比静态批处理高出一截——GPU 的空档期被压缩到了几乎看不见的程度。显存坐不下了分块、挪座、抢座把 GPU 显存想成一桌有限的座位KV 缓存就是坐上去的人。座位按块发满了就得挪座、抢座。座位怎么分块大小和水印KV 缓存被切成固定大小的块block_size默认 16。KV 缓存块大小怎么调记住权衡就行块越小显存利用越精细但管理开销和块表越大块越大最后一块可能浪费到 15 个 token 的座位。多数场景默认值就够用显存极度紧张时才考虑动它。另一个容易忽略的旋钮是watermark默认 0.0即不留余量。它的用法很具体只在新请求或被抢占的请求想进运行队列时生效要求新请求需要的块 预留的余量块都得有空闲才放行。已经坐在座位上的运行中请求不受它管。满了怎么挪交换去 CPU 是上一代的做法在 V0 时代显存不够可以把请求的 KV 缓存 swap 到 CPU 内存继续等位。但翻一下现在的 v1 调度器代码你会发现这条路被拆了——当前的抢占就是释放块、回等待队列重算没有 swap 这个中间态。如果你需要把 KV 挪到别的机器或远端存储那走的是 KVConnectorKV offloading、P/D 分离这套独立的扩展机制不是调度器内置动作。挪座的代价一句话被重算的请求它已经 prefill 过的那几千个 token 的 KV 全得从头算长上下文下这不是小数目。实在没座怎么抢preempt 怎么选人当新请求分配块失败时调度器会挑一个牺牲者踢出去fcfs 下选运行队列里最后进来的那个priority 下选 (优先级, 到达时间) 最大的那个——也就是最不该优先伺候的。两种思路的对比帮你把概念捋直swap 是 V0 的选项V1 默认走 recompute思路保留了什么代价适用场景SWAPV0 传统做法KV 缓存挪到 CPU 内存占 CPU 内存 来回搬运时间长上下文、CPU 内存宽裕RECOMPUTEV1 现行做法什么都不留prefill 算力从头再花一遍上下文不算太长、抢占预期不频繁vLLM 显存不够怎么办答案就在这三层先分块复用、再留 watermark 余量、最后才 preempt 重算。平时把水位控制好抢座动作根本轮不到出场。两个典型场景的应对长文本别一锅炖分块预填充怎么配场景 A用户甩来一篇 8000 token 的长文让你总结。如果 prefill 一锅炖这 8 千 token 会占满好几个调度步的预算其他请求的解码全得干等。实际跑起来之后你会发现enable_chunked_prefill默认就是开着的长文按每步剩余 token 预算切片每步只算其中一块默认上限就是max_num_batched_tokens2048块与块之间穿插着别的请求的解码谁也不卡谁。你可以这样调max_num_batched_tokens从默认 2048 提到 4096~8192长文 prefill 的总步数直接减半long_prefill_token_threshold默认为 0不限制设成 2048~4096 可以给长请求单独限流防止单条长文一步吞掉大半预算长文本多到离谱时顺手看一眼max_num_seqs默认 128别让一批里塞满长请求秒杀流量200 个请求突然涌入场景 B秒杀开始了200 个请求 3 秒内涌进来。这时候队列是你的第一道防线运行队列装不下max_num_seqs个多出来的老实排队再配上watermark留出余量块能避免刚放进一个请求就得马上抢座的抖动代码注释管这个叫 thrashing。如果还想在门口设闸max_num_queued_reqs可以限制在途请求总数超了直接回 HTTP 503 让客户重试到别的实例——这是最粗暴也最有效的容量阀。你可以这样调watermark设 0.01~0.05预留 1%~5% 的空闲块抢占频率肉眼可见地降下来max_num_queued_reqs按DP 实例数 × max_num_seqs 期望排队深度估一个值给队列封顶有 VIP 请求时切policypriority让付费用户的请求有资格插队上手前先看这几个旋钮参数管什么默认值什么时候该动它max_num_batched_tokens每步调度的 token 总预算2048长 prefill 太慢、或想给 prefill 更多份额max_num_seqs运行队列并发请求上限128并发上不去想换吞吐block_size每个 KV 块的 token 数16显存碎片化明显时watermark放行新请求时预留的空闲块比例0.0抢占/重算日志刷得太频繁policy排队规则 fcfs / priorityfcfs出现有优先级的请求long_prefill_token_threshold长请求单步 token 上限0不限长请求长期霸占预算max_num_queued_reqs在途请求上限超了回 503不限想让队列别把服务拖死三条踩坑提醒block_size不是越小越好设太大会让每个请求的最后一块白白占掉显存座位watermark只是新请求入门时的刹车不会把运行中的人踢下去别指望它治运行队列太挤priority是数值越小越先跑把 0 留给最重要的请求别按数值大重要去配想再往深处走直接打开vllm/v1/core/sched/scheduler.py从schedule()方法读起——先调度 running 队列、再消化 waiting 队列的完整逻辑都在里面排队策略的两种实现则在vllm/v1/core/sched/request_queue.py。对照着上面这张图走一遍源码vLLM 请求调度的家底你就算摸清了个别默认值可能随版本调整以实际版本为准。【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考