为什么 ChatGPT 永远都在"启发式调参"？arXiv 这篇立场论文，把 LLM serving 的下一站路线图喊出来了

关联论文：2605.01280

你做 LLM serving 这两年是不是经常踩同一类坑——

vLLM / SGLang 在某些 workload 上吞吐忽高忽低，换一批用户就崩；
长 prompt（RAG 长上下文 / agent 多轮）场景下首字时延抖动剧烈，明明 GPU 占用不到 50%，P99 却被某个长 prompt 拖到 5 秒；
KV cache 命中率调不出花，明明 system prompt 是一样的，每次都从头算一遍；
排队论教科书上的 JSQ / FIFO 拿过来，发现和 vLLM 的 Continuous Batching 套在一起完全对不上。

arXiv 2605.01280 是一篇立场论文（position paper），作者来自 Rice / Stanford / CMU 的 ML-Sys 圈，名字叫 LLM Serving Needs Mathematical Optimization, Not Just Heuristics——核心一句话：LLM 推理 serving 已经超越"通用启发式"的舒适区，必须把请求路由、调度、KV cache 淘汰当作可被数学建模与证明的算法问题。

这不是"调参教程"，是研究方向的路标：vLLM / SGLang 这一代系统已经把"算子优化到顶"，下一步的杠杆不在 GPU kernel，而在调度 / 路由 / 淘汰的策略设计——而这些策略应当像运筹学的车间调度、互联网的请求路由那样，建立带目标函数与约束的数学模型，并给出 provable guarantee。

算子优化到顶，下一站在哪里

过去三年 LLM serving 的优化主线是算子：

PagedAttention（vLLM，OSDI 2023）把 KV cache 分页管理；
Continuous Batching（Orca，OSDI 2022）让请求可以"中途插入"和"中途退出"；
Speculative Decoding（Leviathan / Chen 2023）让 draft model 替大模型先跑几步；
Prefix Sharing / RadixAttention（SGLang）让多轮对话和 few-shot prompt 共享 KV。

这些工作的共同特征：单请求怎么跑得更快。把单请求优化到极致后，多请求一起跑时整体表现取决于调度策略——而这部分几乎是空白。

论文作者（Zijie Zhou 等）把这件事拆成六类核心决策点：

决策点	当前主流策略	是否利用 LLM 特性
Request routing	JSQ / Round-robin	❌ 不知道 prompt 长度、输出长度分布
Batching / 调度	Continuous Batching + FIFO	⚠️ 按长度归一化，但仍是启发式
KV cache 淘汰	LRU / 近似 LRU	❌ 不知道哪些 attention head 即将被命中
Prefill-Decode 调度	同卡时间片	❌ 不知道哪个阶段会成为瓶颈
Speculative decoding 决策	固定 draft model	❌ 不知道哪类请求值得投机
负载再均衡 / 重调度	几乎不做	—

——每一行都还在用 90 年代分布式系统 / 操作系统的启发式，完全不利用 LLM 推理独有的结构特性。

为什么 LLM 推理这么"特别"——四个反常识特性

论文的核心论点：LLM serving 不是通用分布式计算——它有四个独特结构，通用启发式完全没考虑：

KV cache 动态增长。每生成一个 token，注意力 KV 就扩张一次，显存不是静态分配。这意味着传统的"一次性预分配 KV 池"在长输出场景会被打穿，而 vLLM 的 PagedAttention 只是把这个问题从"完全卡死"变成"碎片化抖动"。
Prefill 与 Decode 阶段不对称。Prefill 是计算密集（一次性吃满 prompt），Decode 是访存密集（每次只产一个 token）。两者争抢同一份 GPU 资源。论文称之为 "phase asymmetry tax"——据论文称，这种相互阻塞使吞吐下降一个数量级。
输出长度未知。服务器在调度时不知道这个请求会生成 50 个 token 还是 5000 个，这直接影响 batching 的"提前承诺成本"。所有"按长度归一化"的调度都依赖对未来输出长度的预测，而这个预测本身就是 serving 系统里最难的部分。
Continuous Batching 破坏稳态假设。vLLM/SGLang 引入的动态 batch 替换让请求可以"中途插入"和"中途退出"，打破了传统排队论的稳态假设（M/M/1、M/G/1 全部失效）。

——四个特性叠在一起，让所有通用启发式（JSQ / FIFO / LRU / 固定 draft model）在长尾 workload 下都变成"经验调参"。

论文主张：把 serving 写成数学优化问题

论文的核心主张是：现在 serving 系统的瓶颈不再是 GPU 算子，而是"调度/路由/淘汰的策略设计"。这些策略应当像运筹学的车间调度、互联网的请求路由那样，建立带目标函数与约束的数学模型，并给出 provable guarantee。

论文举了几个示意（不是完整定理）：

Routing 视角（伪代码化）：

max Σ_i U_i(throughput_i) - λ · E[queueing_delay]
s.t. prompt_length_i ≤ GPU_capacity_j
     expected_output_length_i = \hat{o}_i  # 这是最难的预测

这里 $\hat{o}_i$（预估输出长度）是生产环境里最难的部分——论文作者自己都承认。

Prefill-Decode 视角：

视为二阶段随机过程 → 用 MDP / Lyapunov drift-plus-penalty 建模
→ 求 throughput-optimal 的"何时切分请求、何时合并执行"策略

KV cache 淘汰视角：

传统 LRU 等价于假设 future hit 的期望与最近访问时间呈简单衰减
→ 但 LLM 请求的 attention pattern 有显著结构（system prompt、prefix、few-shot 例）
→ 应当用请求级别的 attention 访问统计来估计 future hit

——这些都不是新算法，而是"应当用什么工具箱"的路线图。

三个可借鉴的工具箱

论文调研了三个领域可以迁移到 LLM serving：

Online algorithms / Skeleton framework：把 unknown output length 当成 online revelation，给出 competitive ratio。Internet routing 里 30 年的工作可以无缝对接到 prompt routing。
Lyapunov drift-plus-penalty：把 KV 显存与时延做成虚拟队列，证明稳定性。无线网络 / 数据中心网络的"动态资源分配"有大量现成方法。
Robust / Stochastic optimization：在输出长度分布不确定的情况下给出 worst-case 保证。这是 serving 场景的真实需求——生产环境的输出长度分布永远是 heavy-tail 的。

——论文末尾甚至给出了一份"未来 3-5 年的研究议程清单"，从"output length prediction"到"speculative decoding as contextual bandit"全列了。

这件事为什么重要——为什么不是"又一篇 position paper"

position paper 满天飞，凭什么这一篇值得读？

因为vLLM / SGLang 这一代系统确实"算子优化到顶"了——再挖 kernel 优化的边际收益正在快速下降。下一个能让 ChatGPT 类应用P99 latency 砍掉 30% 以上的杠杆，几乎一定落在"调度 / 路由 / 淘汰的算法化"上。

更直接的信号：业界已经在朝这个方向走，但还没形成框架。比如 vLLM 的 chunked prefill、SGLang 的 radix attention prefix cache，都是"调度层"的工程优化，但都是 ad-hoc 的启发式——论文把它们"算法化"为一类统一问题。

论文的价值不在答案（它没给完整原型），在坐标系：它把所有"看似工程问题"的决策点统一抽象为"应当被数学化的算法问题"，给 ML-Sys 社区提供了新的研究方向——vLLM 之后的下一代 serving 系统长什么样，论文给了一张路线图。

几个工程坑位（论文没明说但落地必踩）

输出长度预测是核心基础设施。论文路由优化公式里依赖 $\hat{o}_i$（预估输出长度），这在生产环境里是最难的部分。实际可行方案：用历史数据离线训练一个轻量回归模型（输入：prompt 长度 + 用户类型 + 时间段），输出 token 数分布期望。上线初期保守做法：按 75 百分位长度做预分配，宁可浪费显存也不要频繁重调度。绝对不要：把 $\hat{o}_i$ 当成确定性值放进路由模型，否则 variance 会把你的优化全部吃掉。
多轮对话的 session 分桶。多轮对话场景下输出长度跟 system prompt 的详细程度强相关，如果历史统计没按 session 分桶，预测会严重偏斜。
Prefix-Aware KV Cache 的实现路径。LRU 替换为 prefix-aware LRU，在工程上不需要推翻现有实现，只需在 cache key 里加入 prefix fingerprint：cache_key = (model_id, session_id, prompt_prefix_hash, token_position)。这样 system prompt 和 few-shot 示例对应的 KV 块天然被保留，而对话内容对应的块按 LRU 淘汰。
Speculative Decoding 的 contextual bandit 化。把"何时启用、启用哪个 draft model"建模成 contextual bandit，根据请求特征在线学习。这是从"工程经验"过渡到"算法设计"的典型案例。
验证预算（validation budget）必须设上限。任何"自调参"系统都要有预算上限，否则会在边缘 case 上耗尽资源。论文暗示的元优化方向都要小心 reward hacking。
重型 vs 轻量策略的边界。论文对"启发式工程"的批评可能被实践派反驳——毕竟 vLLM 的 LRU + Continuous Batching 在绝大多数生产负载上已经足够好。"足够好"和"理论上最优"之间的差距是商业问题，不是研究问题——这就是 position paper 性质的局限。

谁该读这篇

LLM infra 工程师：想从"调参"过渡到"做策略设计"的人，本文是最好的入门 motivation。
ML-Sys 研究者：在找"下一个能发顶会的问题"的人，本文给出了清晰的 research agenda。
运筹 / 排队论 / 网络研究者：想把自己的工具箱搬到 AI 领域的人，本文给出了对接点。
AI 平台架构师 / Tech Lead：在做"为什么我的 serving 在某些 workload 上抖"的归因分析时，本文提供诊断词汇。
不适合：只想"看一两个数字就下班"的读者；本文是 position paper，消化它需要一定的 ML-Sys 与运筹学背景。

一句话总结

LLM serving 已经走到"算子优化到顶"的分水岭——vLLM / SGLang 之后的下一代系统长什么样，arXiv 2605.01280 给了张明确路线图：把请求路由、调度、KV cache 淘汰当作可被数学建模与证明的算法问题，从运筹学的车间调度、网络的请求路由、理论 CS 的在线算法中借鉴工具箱，给出 provable guarantee——论文不是答案，是坐标系；它给 ML-Sys 圈划出了未来 3-5 年最大的研究杠杆所在。

三个标题变体

为什么 ChatGPT 永远都在"启发式调参"？arXiv 这篇立场论文，把 LLM serving 的下一站路线图喊出来了
vLLM 之后的下一代 serving 系统长什么样——arXiv 2605.01280 把"调参手艺"升级成"数学优化"路线图
LLM 推理系统的瓶颈不在 GPU kernel，在调度策略——这篇 position paper 给 ML-Sys 圈划了未来 3-5 年的研究杠杆

小红书风格卡片文案（可直接发布）

🚀 你做 LLM serving 这两年是不是经常踩同一类坑——

vLLM / SGLang 在某些 workload 上吞吐忽高忽低，换一批用户就崩 📉
长 prompt 场景下首字时延抖动剧烈，明明 GPU 占用不到 50%，P99 却被长 prompt 拖到 5 秒 ⏱️
KV cache 命中率调不出花，system prompt 一样的多轮对话每次都从头算 💾
排队论教科书上的 JSQ / FIFO 拿过来和 Continuous Batching 套在一起完全对不上 📚

arXiv 2605.01280 是一篇立场论文，标题：LLM Serving Needs Mathematical Optimization, Not Just Heuristics

核心一句话：LLM 推理 serving 已经超越"通用启发式"的舒适区，必须把请求路由、调度、KV cache 淘汰当作可被数学建模与证明的算法问题 🧠

📌 为什么算子优化到顶了：

过去三年 LLM serving 的优化主线是算子——PagedAttention、Continuous Batching、Speculative Decoding、Prefix Sharing / RadixAttention。共同特征：单请求怎么跑得更快。多请求一起跑时整体表现取决于调度策略——而这部分几乎是空白 ⚠️

📌 论文梳理的六类决策点（全部还在用 90 年代启发式）：

决策点	当前主流策略	是否利用 LLM 特性
Request routing	JSQ / Round-robin	❌ 不知道 prompt 长度、输出长度分布
Batching / 调度	Continuous Batching + FIFO	⚠️ 按长度归一化，但仍是启发式
KV cache 淘汰	LRU / 近似 LRU	❌ 不知道哪些 attention head 即将被命中
Prefill-Decode 调度	同卡时间片	❌ 不知道哪个阶段会成为瓶颈
Speculative decoding 决策	固定 draft model	❌ 不知道哪类请求值得投机
负载再均衡	几乎不做	—

📌 LLM 推理的四个反常识特性（为什么不能套通用分布式计算）：

KV cache 动态增长——每生成一个 token，注意力 KV 扩张一次，显存不是静态分配
Prefill 与 Decode 阶段不对称——计算密集 vs 访存密集，争抢同一份 GPU 资源；据论文称吞吐下降一个数量级
输出长度未知——服务器调度时不知道这个请求会生成 50 还是 5000 个 token
Continuous Batching 破坏稳态假设——动态 batch 替换让 M/M/1、M/G/1 全部失效

📌 三个可借鉴的工具箱： 1. Online algorithms / Skeleton framework——把 unknown output length 当成 online revelation，给出 competitive ratio 2. Lyapunov drift-plus-penalty——把 KV 显存与时延做成虚拟队列，证明稳定性 3. Robust / Stochastic optimization——在输出长度分布不确定的情况下给出 worst-case 保证

🔥 为什么这篇 position paper 值得读：

vLLM / SGLang 已经算子优化到顶——再挖 kernel 边际收益快速下降
业界已经在朝调度层走（chunked prefill、radix attention prefix cache）但都是 ad-hoc 启发式——本文把它们"算法化"为一类统一问题
论文给的是坐标系，不是答案——未来 3-5 年能让 ChatGPT 类应用 P99 砍 30%+ 的杠杆，几乎一定落在调度 / 路由 / 淘汰的算法化上

⚠️ 工程坑位（论文没明说但落地必踩）： 1. 输出长度预测是核心基础设施——按 75 百分位长度做预分配，不要把 $\hat{o}_i$ 当确定性值 2. 多轮对话必须按 session 分桶，否则 system prompt 长度变化会让预测严重偏斜 3. Prefix-Aware KV Cache 实现路径——在 cache key 里加入 prefix fingerprint，无需推翻现有 LRU 实现 4. Speculative Decoding 的 contextual bandit 化——把"何时启用、启用哪个 draft model"建模成在线学习 5. 任何"自调参"系统都要设 validation budget 上限，否则会在边缘 case 上耗尽资源 6. "足够好"和"理论上最优"之间的差距是商业问题不是研究问题——position paper 的局限

📌 未来 3-5 年 ML-Sys 圈的最大杠杆：

不是再挖一个 kernel 优化，而是把车间调度、TCP 拥塞控制、互联网路由 30 年的成熟工具箱搬到 LLM serving——vLLM 之后的下一代 serving 系统长什么样，论文给了一张路线图 🗺️

📎 论文 ID：2605.01280 💬 评论区：你团队的 LLM serving 在哪些 workload 下抖过最厉害？你更愿意堆 GPU 还是重写调度策略？

人工智能 #AI科普 #大模型 #LLM #MLSys #推理优化 #vLLM #SGLang #论文分享 #程序员 #技术分享 #深度学习 #AI基建