Optimizing LLM Inference: Fluid-Guided Online Scheduling with Memory Constraints

关联论文：2504.11320
作者：Tom
更新：2026-07-25

一句话结论

WAIT 与 Nested WAIT 调度策略将 LLM 推理的 KV-cache 内存约束建模为在线调度问题，通过流体力学模型推导稳定区域边界，在接近过载和过载区间显著降低延迟并扩大安全运行范围。

解决什么真问题

LLM 推理服务每日成本高达百万美元级别，GPU 调度是延迟、吞吐量与成本的核心瓶颈。问题的本质困难在于内生性内存增长：每生成一个 token，KV-cache 就扩大一步，缓存溢出时正在处理的请求会被强制驱逐，导致先前计算全部浪费。

现有调度方法（如 FCFS、Shortest-Remaining-Time-First）在面对这种内存持续扩张时缺乏理论保证，无法系统性地扩大稳定运行区间。文章将推理重新建模为多阶段在线调度问题，纳入三个关键约束：内生内存增长、线性迭代时间（生成每个 token 耗时固定）、GPU 显存中的 KV-cache 上限。

核心方法

1. 流体力学（Fluid）模型

文章首先建立流体力学模型来刻画稳态批处理的均衡组成、内存需求与稳定区域。核心变量：

b(t)：时间 t 的批次大小（batch size）
m(t)：时间 t 的 KV-cache 内存占用
λ：请求到达率
μ：服务率（每个请求的 token 数）

在连续近似下，系统的内存演变满足：

dm/dt = λ·E[output_len] - μ·cache_release_per_token

稳定运行当且仅当到达率 λ 落在流体力学稳定区域内。原文未给出精确解析式，而是通过该模型推导出调度策略的设计原则。

2. WAIT 策略（已知输出长度）

WAIT（Waiting for Accumulated Inference Threshold）是一种基于阈值的准入规则：新请求进入前，需等待已接纳请求的累计推理进度达到某个阈值，确保批次组成在数学上可预测。

关键机制：准入控制 + 批次组成约束。设阈值 θ，当已接纳请求的已完成 token 数比例达到 θ 时，才接纳新请求。阈值由流体力学模型推导得出，保证系统稳定。

3. Nested WAIT（未知输出长度）

实际场景中输出长度往往未知。Nested WAIT 将解码阶段分为多个 segments，每个 segment 有独立的阈值设置。请求在各 segment 之间的推进受调控，额外维护一个安全缓冲区（safety buffer） 来对冲未知长度带来的内存溢出风险。

# 伪代码：Nested WAIT 核心逻辑
for segment in segments:
    accumulated = sum(req.completed_tokens for req in admitted)
    if accumulated >= segment.threshold:
        advance_to_next_segment(req)
        # 安全缓冲区动态调整
        safety_buffer = estimate_buffer(req, memory_pressure)

原文未给出精确公式，说明安全缓冲区大小由流体力学稳定性分析推导，但具体参数在论文附录（正文截断）。

关键实验与数据

模拟器：Vidur（Llama-2-7B，A100 GPU）
补充验证：附录有真实 GPU 实验
核心结果：
WAIT 和 Nested WAIT 扩大了稳定运行区间（相比 FCFS 等基线）
在接近过载（near-overloaded）和过载（overloaded）区间延迟显著降低
原文未给出具体百分比或数值（实验细节在附录中，正文摘要未量化）

亮点与局限

亮点： - 首次将 LLM 推理调度建模为有理论保证的在线优化问题，而非纯启发式 - 流体力学模型提供了可解释的稳定区域分析 - WAIT 策略简洁、可落地，Nested WAIT 处理了更难的未知长度场景

局限： - 实验数据未在摘要/引言中量化，读者无法直接评估提升幅度 - 流体力学模型是连续近似，真实离散调度可能有偏差 - 仅在 Llama-2-7B 上验证，更大模型（如 70B）的 KV-cache 行为可能不同 - 论文正文 79 页，核心数据大量在附录，完整评估需深入阅读

对工程落地的启发

LLM Serving 系统调度：vLLM/SGLang/TensorRT-LLM 等生产推理引擎的调度器设计可参考 WAIT 的阈值准入思路，特别是面向长输出场景（如 Code/Search）时
内存约束感知：KV-cache 不仅是存储问题，更是调度问题——在连续批处理（continuous batching）中动态决定谁能进入批次是关键
理论+仿真验证：流体力学模型给出稳定区间，Vidur 仿真做工程验证，是 LLM 系统研究的标准范式
安全缓冲区设计：Nested WAIT 的安全缓冲区思路可移植到 prefix caching 或 speculative decoding 场景

与同方向工作的关系

与 Orca/SpecInfer（连续批处理）的关系：WAIT 提供了准入控制层，解决的不是 batching 本身而是何时接纳新请求的问题
与 vLLM 的 PagedAttention 的关系：PagedAttention 管理 KV-cache 的物理布局，WAIT 决定哪些请求能被接纳——两者正交、可叠加
与 TGI（Text Generation Inference）的Prefix Caching 的关系：都是内存优化，但 WAIT 从调度理论出发，Prefix Caching 从缓存复用出发

适合谁读

LLM Serving 系统工程师：理解推理调度的理论基础，改进 vLLM/SGLang 的调度器
MLSys 研究者：流体力学模型在调度问题中的应用范式
对 LLM 推理成本优化感兴趣的研究者：提供从理论到仿真的完整分析框架

来源

arXiv 摘要：https://arxiv.org/abs/2504.11320
arXiv HTML（方法细节）：https://arxiv.org/html/2504.11320v4
论文卡（paper_cards/034-2504-11320.md）

工程落地与核查（Jay）

事实核查

✅ 核心问题定义准确：KV-cache 内生性增长、内存溢出时的计算浪费，这是 vLLM/PagedAttention 核心要解决的事实，描述正确。
✅ 流体力学建模思路：将连续批处理建模为流体近似是合理的理论简化，学术圈有先例（如 CloudPhysics 2013）。
✅ WAIT 策略机制：基于阈值准入控制的设计思路与论文 Abstract 一致。
⚠️ 具体数值缺失：解读明确标注了「原文摘要未量化」，这是诚实表述。但需注意：WAIT/Nested WAIT 的具体延迟降低幅度（%）、稳定区间扩大了多少，在正文摘要中没有，读者无法直接判断工程价值。
⚠️ Llama-2-7B 验证的局限：论文仅在 7B 验证，70B/405B 的 KV-cache 压力曲线完全不同，此方法在大模型上的有效性未验证。
⚠️ Vidur 模拟器的置信度：模拟器结果不等于真实 GPU 部署结果，附录的真实 GPU 实验数据被截断，无法评估模拟与真实的差距。

可读性精修建议

术语一致性：「接近过载」和「overloaded」在正文中未统一，建议统一为「near-overloaded regime」和「overloaded regime」并在首次出现时加注。
公式呈现：内存演变的微分方程可以更清晰地展示，比如补充「稳定条件：λ·E[L] < μ·C」形式的稳定边界。
代码注释补全：伪代码中 estimate_buffer 函数为空壳，建议补充：safety_buffer 通常与当前 admitted 请求的剩余 token 方差成正比，实践中可设为 2-3 倍的预估标准差。

工程落地要点

实际系统怎么用

WAIT/Nested WAIT 的核心思想是准入控制，而非替换现有的 batching 策略。在现有系统中集成思路：

vLLM 集成路径： - vLLM 当前使用 Speculative Decoding + PagedAttention，不直接支持 WAIT 准入控制 - 可在 vLLM 的 scheduler 层注入 WAIT 逻辑：在 accept_request 之前检查当前 batch 的 KV-cache 压力是否低于阈值 - 代码路径：vllm/core/scheduler.py 中的 _can_allocate 方法是准入控制入口
SGLang 集成路径： - SGLang 的 RadixAttention（prefix caching）与 WAIT 思想正交，更适合 prefix 复用场景 - WAIT 的阈值准入可作为 SGLang 调度器的额外 gate
自制 Serving 系统的最小实现： ```python # WAIT 准入控制的最小伪代码 class WAITScheduler: def init(self, memory_limit_gb, kv_cache_per_token_mb): self.memory_limit = memory_limit_gb * 1024 # MB self.kv_per_token = kv_cache_per_token_mb self.admitted = [] # 当前已接纳请求列表

def can_accept(self, req): # 计算若接纳新请求，总 KV-cache 会多大 total_tokens = sum(r.prefix_len + r.generated_len for r in self.admitted) projected = total_tokens + req.prefix_len projected_mb = projected * self.kv_per_token # WAIT 阈值：已接纳请求平均完成进度需 > θ if not self.admitted: return True avg_progress = sum(r.generated_len for r in self.admitted) / len(self.admitted) theta = 0.7 # 由流体力学模型确定 return avg_progress >= theta and projected_mb <= self.memory_limit ```

坑点与边界

WAIT 不适合短请求为主的场景：WAIT 依赖「等待累计进度」，如果请求大多是极短（<50 tokens），等待时间可能比节省的内存浪费更长，吞吐量反而下降。
阈值 θ 依赖流量分布：论文的 θ 是由固定流分布推导的，实际流量如果是突发性的（bursty），阈值需要动态调整。
Nested WAIT 的 segment 数：分段越多越精确，但调度开销越大。实践中 3-5 段是平衡点。
安全缓冲区估算：这是方法的黑盒部分，论文未给出具体公式，工程师需要自己 tuning。
模拟器 vs 真实：Vidur 是离散事件模拟，结果与真实 GPU 调度有差距。生产部署前必须实测。

论文可信度评估

理论贡献：★★★★☆（流体力学建模有原创性，提供了第一个有理论保证的调度框架）
工程可行性：★★★☆☆（阈值确定、安全缓冲区仍是黑盒，落地需要大量 tuning）
实验完整性：★★☆☆☆（核心数字未在摘要量化，附录截断，无法独立评估）

核查小结

WAIT/Nested WAIT 是 LLM 推理调度领域的有趣理论工作，但当前无法直接用于生产：核心参数未知、仅在 7B 验证、实验数字不透明。更实用的近期方向是将「准入控制」思想与 vLLM/SGLang 现有调度器结合，而非完整复现 WAIT。建议等论文完整版（附录数字公开）再决定是否跟进。