02 推理运行时：把请求变成每一轮 GPU 工作

运行时负责在有限资源上推进多个请求。模型知道怎样做一次前向计算，运行时还要决定谁先算、这一轮算多少、状态放哪里，以及取消或抢占时怎样收尾。

配套设计文档：图册 D3 请求运行与 D4 状态收尾。先看冷/热路径，再对照具体实现。

先看动态演示：推理过程动态图解用三个可逐步播放的演示讲清张量怎样变化、每轮怎样组 batch、PagedAttention 怎样存取 KV。

1. 先追通一次请求

输入校验、分词
→ 创建请求状态，进入等待队列
→ 检查 token 预算、可用 KV 空间、缓存与外部依赖
→ 组成这一轮模型输入
→ GPU 前向与采样
→ 更新已计算位置、输出和停止条件
→ 下一轮，或结束并回收资源

这里的箭头是逻辑依赖，真实实现可以把 CPU 准备、设备执行和通信重叠。区分“任务已提交”“GPU 已完成”和“结果已经发布”，才能正确理解异步路径。

问题	常见机制	需要付出的代价或约束
长短请求怎样共存	Continuous batching：按轮次加入和移出请求	需要维护动态状态，不能只按静态 batch 理解
长 Prefill 阻塞 Decode	Chunked prefill：拆分输入计算，分配 token 预算	chunk 大小影响吞吐、延迟和调度开销
显存不足	准入、抢占、重算或卸载	被抢占请求的延迟与恢复成本
CPU 准备不够快	重叠调度、输入准备、CUDA Graph 等	数据依赖、shape 限制和额外 buffer 生命周期
外部缓存尚未加载	显式记录依赖，等到消费条件满足	不能拿“查到 key”当“可以跳过计算”
请求被取消	停止后续工作，处理已提交任务，再回收	在途 GPU/NIC 工作不会因删掉请求对象而消失

调度不是只排序。至少同时考虑请求队列、每轮 token 数、可用状态空间和尚未完成的依赖。吞吐提高也要检查短请求是否被长请求拖慢。

运行时知道哪些 token 尚未计算，KV 管理层知道哪些状态可以共享或回收，存储层知道对象位置和读写保护，传输层报告字节移动进度。实现可能把多个职责放在同一模块，但阅读时仍要分别标出。

例如一个请求命中远端 4K 前缀：先确认语义和布局，再分配目标空间，加载数据，完成必要的设备同步，最后才能把这段前缀记为可用。具体 hook 顺序以选定引擎版本为准。

实现案例	阅读入口	对照问题
vLLM	实现概览、请求源码链、架构图	EngineCore、Scheduler、Runner 如何交接状态？
SGLang	实现概览、Runtime、知识地图	调度、缓存匹配、执行和重叠分别在哪个边界？

先追一个实现的正常路径与取消路径，再对照另一实现。比较状态和协议，不要求类名或线程结构一一对应。

画出四个请求在 token 预算为 8 时的一轮调度；说明“有 token 预算但无法执行”的两个原因；标出请求、KV 页和在途传输分别由谁持有。然后做调度实验，再进入KV 管理。