01 · 单请求很快，为什么上线后还是慢
在线服务同时收到长短不同的请求。设备每秒能做的工作有限，KV容量也有限；一个大Prefill可能占据较长执行时间，很多长Decode又会持续占用缓存。如果到达速度长期超过服务能力，队列会增长，优化单个kernel也未必解决排队。
本篇把M021连续批处理、M022分块Prefill和M015前缀路由放进完整服务生命周期。目标可能是吞吐、TTFT、ITL、完成时限或不同租户的服务份额，它们不能只用“每秒输出token最多”一个指标代替。
依据：vLLM · Scheduler预算与调度策略配置 ↗ · NVIDIA Dynamo · KV与负载感知副本路由 ↗
02 · 五个问题，分别由谁来决定
| 环节 | 决定什么 | 对应方法 |
|---|---|---|
| 准入 | 现在接收、排队、拒绝或延后多少工作 | 请求/token/KV/租户预算，超载反馈。 |
| 副本路由 | 把已选择模型的请求送到哪个可用实例 | 负载与KV复用；模型选择另见M044。 |
| 排队与轮次调度 | 谁先得到执行机会，本轮多少Prefill/Decode | 优先级、公平、连续批处理、分块。 |
| 运行状态管理 | 内存不足时暂停谁、怎样恢复 | KV分页/卸载/重算，状态与成本配套。 |
| 结束与取消 | 何时停止后续工作、何时释放存储 | 结果返回、取消传播、完成事件与回收。 |
请求到达 → 检查身份/模型就绪/准入预算
→ 选择兼容副本 → 进入有界队列
→ 按轮次预算选请求与token → 准备KV → 执行
→ 返回已完成输出 → 更新请求状态
→ 继续 / 结束 / 取消 → 按完成依赖回收准入用的预测工作量、当前KV占用和本轮query token预算是不同对象。一个Decode请求本轮只输入一个token，但可能读取几千位置的KV；仅限制请求数或query token数不足以描述全部成本。
03 · 有界队列和容量预算，比无限接收更可控
可以同时限制活动请求、待处理输入token、输出预算、KV块、队列长度及每租户份额。准入预测输出长度可能不准，应明确保守预留、动态增长、回收与不足时的策略。上下文或预算超硬上限时，应该给出明确状态，不能静默截断。
自设KV池16块：活动A占6块、B占5块，可用5块；新C当前需要7块，不能立即驻留。如果B取消且所有读者完成后释放5块，可用10块，C才能放入。若B的执行或复制仍在读，就不能提前释放。
一个轮次预算8个query token：两个Decode各1个，剩余6个可给Prefill块。这是token账本，不是这轮一定耗时8个单位；Attention历史、shape和设备利用率仍影响时间。
04 · 谁先完成：用三个排队作业看优先级
自设只有一个执行资源，A需8 ms、B/C各2 ms，三者在0 ms都已排队，B/C优先级高；不抢占、不合批。FCFS按A→B→C，等待为0/8/10 ms；优先级按B→C→A，等待为0/2/4 ms。全部完成仍需12 ms。
先照顾短任务，谁的等待改变了？
A为普通任务，B/C优先级高且各2 ms；三者在0 ms均已排队，一个执行资源、无抢占/合批。表中为作业完成时间，不是LLM的TTFT；未计KV和轮次成本。这说明优先级可改善一类请求的等待，但把A推迟了，并未减少总工作量。若A已经执行，非抢占优先级也不能让B马上越过A。真实LLM可按轮次让出机会，轮次大小、重算和迁移又有成本。
持续高优先级到达可能使普通请求饥饿。可用aging、份额或加权公平等策略，但要定义按请求、token、估计时间还是实际资源计费；长请求与短请求的公平标准可能不同。
05 · 命中缓存最多的副本，不一定最快
副本选择应先排除模型/适配器版本不兼容、未就绪或正在排空的worker，再考虑排队、活动负载、可用KV和前缀重叠。所有请求都集中到同一个热门前缀副本，可能把省掉的Prefill变成更多排队。
自设A可省20 ms的Prefill但预计排队50 ms，B没有前缀但排队5 ms；其他部分相同，选择A的净优势已被45 ms额外等待抵消。缓存事件和负载测量也可能滞后，所以预测不是保证。
Dynamo的router提供根据可复用KV与预测活动负载选择worker的实现入口，具体路由模式、后端事件和参数要按版本核对。
06 · 抢占、取消、背压：都要对接状态生命周期
| 动作 | 主要目的 | 需要保留的合同 |
|---|---|---|
| 暂停/抢占 | 给其他请求或内存释放机会 | 暂停进度、KV是否保留/卸载/重算、恢复时正确前缀。 |
| 取消 | 停止已无需求的后续工作 | 传播到调度器与worker；已提交执行可能仍需等待完成。 |
| 背压/拒绝 | 防止上游继续制造超量工作 | 显式返回状态；重试退避和预算，防止重试风暴。 |
| 超时 | 限制等待或完整请求时限 | 超时不是正常完成；客户端离开不自动等于设备已停止。 |
vLLM文档说明KV不足时可以抢占并在恢复时重算，这可能恶化端到端延迟。把抢占次数降低到零，也不一定最好：若因此拒绝很多请求或留大量资源空闲，需一并比较。
cancel(request)
标记终止，不再安排新轮次
若还在队列：移除并归还尚未使用的预算
若已有执行/复制/通信读者：等待对应完成依赖
归还不再共享使用的KV/缓冲和配额
拒绝迟到输出或旧代次回调
# 取消状态与资源可复用状态不是同一瞬间。07 · 弹性扩缩容要计加载、预热与排空
长期负载增加时可增加副本；短时尖峰可能在新副本加载和预热前就结束。扩容应看队列、请求长度与服务目标，不能只看GPU利用率：等待网络、KV不足和小批次都会让利用率指标难解释。
新副本真正就绪后才接收请求；缩容先停止新路由，等活动任务结束或按合同迁移/终止，再回收实例。前缀缓存、适配器和活动KV未必能无成本搬走。设置观察窗口、冷却时间和容量上下界可减小反复扩缩。
Dynamo Planner是针对服务目标和负载配置资源的官方入口；本页讲控制思路，不复制一个对所有硬件/负载都合适的阈值。
依据：NVIDIA Dynamo · Planner负载与服务目标 ↗ · PyTorch · mmap / meta / assign模型加载教程 ↗
08 · CPU验证队列与资源归还
下载脚本比较非抢占FCFS/优先级排程，检查总工作量与等待；模拟有界KV池、轮次token预算、取消后仍有读者时禁止回收，以及迟到回调不应复活请求。它不实现vLLM scheduler或多机服务。
先固定请求到达、长度、模型与质量合同
记录接收/排队/拒绝/执行/结束各时间戳
验证每轮token与KV预算，注入取消和资源压力
比较路由/优先级/准入策略，计重算与重试
再测扩容就绪、缩容排空、同资源下的SLO满足率依据：vLLM · Scheduler预算与调度策略配置 ↗ · NVIDIA Dynamo · KV与负载感知副本路由 ↗
09 · 验收与跨平台比较
- 正确性：状态转换、预算、取消传播、共享KV引用和恢复输出。
- 服务：TTFT/ITL/端到端P95/P99、超时/拒绝/重试与有效完成吞吐。
- 公平：租户份额、普通请求最长等待、优先级/aging规则。
- 资源：活动KV、重算/迁移、冷热副本、加载与排空耗时。
- 负载：到达分布、输入/输出长度、缓存命中与同资源预算。
GPU/NPU后端可采用相似治理思路，但每轮成本、内存预算、通信和启动时间不同。保持服务目标和请求质量一致，再比较配置；不能因多加副本就把总吞吐增加归为调度算法收益。
- 优先级排序为何改善B，却没有缩短全部作业完成时间？
- 请求取消后，为什么有些KV块仍不能立即复用？
- 副本有前缀缓存，但排队很长时该怎样估计取舍？
流程位置与关联方法
这个方法可能出现在多个位置；计算线包含模型计算与算子实现，执行线包含运行时、内存和通信。
资料与核查范围
原理依据以原始论文和官方文档为主；算例与时间线是教学推导。文档核查日期：2026-10-10。引用 main / latest 文档时，实际接口以安装版本为准。
- vLLM · Scheduler预算与调度策略配置 ↗
- vLLM · KV不足、抢占和分块Prefill ↗
- NVIDIA Dynamo · KV与负载感知副本路由 ↗
- NVIDIA Dynamo · Planner负载与服务目标 ↗
- PyTorch · mmap / meta / assign模型加载教程 ↗
代码为接入片段或教学伪代码；本页没有声称完成 NVIDIA / 昇腾硬件实测。