LLM 推理调度：把 GPU 显存当流体推，为什么 WAIT 能稳住过载区间

  • 关联论文：2504.11320 · Optimizing LLM Inference: Fluid-Guided Online Scheduling with Memory Constraints

为什么这件事重要

LLM 推理服务的成本动辄每日百万美元级，调度器是延迟、吞吐量、成本的共同瓶颈。这个问题之所以难，根源是内生性内存增长——每生成一个 token，KV-cache 就大一步，缓存溢出时正在处理的请求会被强制驱逐，先前算的所有 token 全部作废。

FCFS、Shortest-Remaining-Time-First 这类经典策略面对这种"持续扩张"的内存时没有理论保证，没法系统性扩大稳定运行区间。2504.11320 这篇把推理重新建模为带内存约束的多阶段在线调度问题，用流体力学（fluid）模型推导稳定区域，给出了第一个有理论保证的调度框架：WAIT 与 Nested WAIT。

核心机制

论文建立流体模型刻画稳态批处理的批次大小 b(t)、KV-cache 内存占用 m(t)、请求到达率 λ、服务率 μ。在连续近似下，dm/dt = λ·E[output_len] − μ·cache_release_per_token，稳定运行要求 λ 落在流体力学稳定区域内。

WAIT 策略（已知输出长度）：阈值准入规则。设阈值 θ，新请求进入前需等已接纳请求的累计推理进度达到 θ，保证批次组成数学可预测。这是准入控制层，不是替换 batching——和 vLLM 的 PagedAttention（管物理布局）、SGLang 的 RadixAttention（管 prefix 复用）正交可叠加。

Nested WAIT（未知输出长度）：把解码阶段切成多个 segments，每个 segment 有独立阈值；额外维护安全缓冲区（safety buffer）对冲未知长度带来的内存溢出风险，缓冲区大小由稳定性分析推导。

证据边界

  • 核心数字未在摘要量化：WAIT/Nested WAIT 在 near-overloaded 和 overloaded 区间的延迟降低幅度、稳定区间扩大比例，论文正文摘要没有给出，完整数据在 79 页正文后的附录，摘要截断。
  • 仅在 Llama-2-7B 验证：70B/405B 的 KV-cache 压力曲线完全不同，大模型上方法有效性未验证。
  • 模拟器 vs 真实 GPU：主结果来自 Vidur 仿真器（A100），真实 GPU 实验在附录，数据被截断，无法评估模拟与真实的差距。
  • 流体模型是连续近似：真实离散调度可能偏离。
  • 阈值 θ 依赖流量分布：固定流分布推导的 θ，突发流量下需动态调整。

工程局限

WAIT 不适合短请求为主（<50 tokens）的场景——等待累计进度的时间可能比内存浪费更长，吞吐量反而下降。安全缓冲区估算论文未给具体公式，是方法的黑盒部分，工程师需要自己 tuning。Nested WAIT 的分段数实践中 3–5 段是平衡点：分段越多越精确但调度开销越大。

落地路径：当前生产推理引擎（vLLM / SGLang / TensorRT-LLM）的调度器里注入 WAIT 逻辑——vLLM 的 vllm/core/scheduler.py::_can_allocate 是准入控制入口，可在 accept_request 前检查当前 batch 的 KV-cache 压力是否低于阈值。生产部署前必须用真实 GPU 实测，不能只跑 Vidur 仿真。

标题变体

  1. 《LLM 推理调度：把 KV-cache 当流体推，WAIT 如何稳住过载区间》
  2. 《GPU 显存像水位线：为什么 FCFS 在长文本场景会算到一半被踢掉》
  3. 《准入控制 vs PagedAttention：vLLM 调度器还能再加一道 WAIT 闸》

小红书卡片

⚙️ LLM 推理服务每天烧百万美元，调度器是真正的成本阀门。

FCFS、Shortest-Remaining-Time-First 这些老策略面对 KV-cache 持续扩张时没有理论保证——缓存满了，正在算的请求被踢出去，前面算的 token 全废。

2504.11320 把这个问题重新建模成"带内存约束的在线调度"，用流体力学推稳定区域，给出 WAIT（已知输出长度）和 Nested WAIT（未知输出长度，用分段+安全缓冲区对冲）两套策略。核心思想是阈值准入：新请求进来前，先等已接纳请求的累计推理进度达到 θ，保证批次组成数学可预测。

实测效果：在接近过载和过载区间延迟显著降低、稳定运行区间扩大——但具体数字论文摘要没给，藏在 79 页后的附录。

落地关键是把它当准入层注入现有调度器，不是替换 batching。和 vLLM 的 PagedAttention、SGLang 的 RadixAttention 正交可叠加。生产部署前别只跑 Vidur 仿真，必须用真实 GPU 实测——尤其短请求场景，WAIT 的等待可能比节省的内存浪费还长。