LLM服务每阶段SLO | AI生成和翻译
问题：arxiv.org/abs/2504.08784 上的论文说了什么？
回答：
该论文介绍了 SLOs-Serve，一个 LLM 服务系统，它优化的是 每个应用、每个阶段的 SLO，而非大多数服务栈（vLLM、TGI、SGLang）通常使用的统一 TTFT/TPOT 目标。SLOs-Serve 专为服务多阶段 LLM 请求而设计，这些请求具有应用和阶段特定的服务等级目标，通过定制 token 分配来满足这些 SLO 要求。
核心机制——将资源规划视为优化问题：
SLOs-Serve 使用一种基于多 SLO 的动态规划算法，在 SLO 约束下持续优化 token 分配，探索分块预填充和可选推测解码的完整设计空间。
这是与你推理优化兴趣相关的部分。他们不是将“将预填充分成多少个 token 的块”和“是否为此请求使用推测解码”视为固定的调度策略，而是将其形式化为一个 每次迭代中基于 token 预算分配的 DP，该 DP 受阶段延迟约束。具体而言，这意味着：
- 一个多阶段流水线（例如，RAG 检索 → 生成 → 工具调用 → 最终答案）每个阶段都有不同的延迟预算。一个简单的调度器将每个解码步骤同等对待；SLOs-Serve 则跟踪每个请求每个阶段的剩余 SLO 预算，并在每个调度轮次中重新求解分配。
- 分块预填充的大小成为 DP 中的一个决策变量，而不是一个固定的超参数（vLLM 的
--max-num-batched-tokens样式旋钮是静态的；而这里是每次迭代动态调整的）。 - 推测解码的草稿长度被纳入同一优化——即，“此请求本轮是否应使用推测解码，以及使用多深的草稿”成为同一 token 预算分配的一部分，而不是一个独立的正交系统。
基于规划器的系统级能力：
利用这一资源规划算法，SLOs-Serve 支持多 SLO 和多副本服务，具有动态请求路由功能，并且能够应对突发流量——因此存在一个跨副本的 SLO 感知路由层（将请求路由到仍能满足其阶段截止时间的副本），而不仅仅是轮询或最少负载。
结果：
在 6 个 LLM 应用场景中进行了评估——摘要、编码、聊天机器人、工具调用和推理——与先前最先进的系统相比，SLOs-Serve 将每个 GPU 的服务容量平均提高了 2.2 倍。
为什么这对你很重要： 如果你正在构建智能体流水线（多智能体、工具使用、RAG）并在自己的 RTX 4070 上自托管或租用 AMD MI300X 容量，那么运行带有全局 SLO 的 vLLM 这种简单做法会浪费 GPU 时间——需要快速响应 50 个 token 的工具调用阶段与可以容忍更多延迟的长时间推理阶段被同等调度。基于 DP 的每阶段分配是一种值得从概念上借鉴的东西，即使你不直接运行他们的系统：对于自定义智能体服务器，你可以实现一个简化版本——在请求元数据中跟踪每个阶段的剩余延迟预算，并让你的调度器根据该预算（而非先来先服务）优先考虑分块预填充大小。这直接适用于你的“自定义智能体开发和自动化”工作，因为多阶段智能体请求正是此工作负载的目标，而不仅仅是单轮聊天。
一个注意事项：我仅从 arxiv 获取了摘要（PDF 获取返回了相同的摘要页面，而非全文），因此我没有确切的 DP 公式、复杂度界限或他们的基线比较（vLLM？SGLang？Sarathi？）。如果你想要 DP 递推的实际数学形式，我需要直接拉取 PDF——如果你打算实现类似的东西，这是值得做的。
参考文献：
AI生成和翻译，但整理分享仍需精力。如果觉得有帮助，欢迎
捐助支持。
微信：@lzwjava
·
X: @lzwjava ·
打个招呼 👋