SmartFlowAI
点击上方蓝字关注我们
作者：樊奇，上海交通大学硕士生
全文约 1400 字，预计阅读时间 6 分钟
在前两期内容中，我们介绍了 Orca 与 vLLM 这两个大模型推理系统。Orca 解决了任务级调度过于粗粒度的问题，而 vLLM 解决了 KV cache 导致的低效率内存管理问题。众所周知，输入的 prompt 的长度会影响到 prefill 阶段的时间，从而造成较大的 bubble。那么这部分 bubble 要如何优化呢？我们今天就来看一看《Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve》这篇论文所介绍的 Chunked Prefill 技术，源码位于 https://github.com/microsoft/sarathi-serve 。
背景与动机
随着大语言模型（LLM）的广泛应用（如聊天机器人、搜索引擎和代码助手），其推理阶段的计算需求逐渐成为主导 GPU 工作负载的关键挑战。推理阶段需要在高吞吐量与低延迟之间进行权衡，而现有的 LLM 推理系统通常难以兼顾这两个目标。特别是，推理任务的两个阶段：
Prefill 阶段：并行处理输入提示，生成第一个输出标记，具有高延迟但能充分利用 GPU。 Decode 阶段：逐个生成输出标记，延迟较低但计算利用率较低。
为优化这两个阶段的吞吐量与延迟，Sarathi-Serve 引入了一种高效的调度器，通过分块预填充（chunked-prefills）和无停滞调度（stall-free batching）实现了高吞吐量和低延迟的平衡。
Sarathi-Serve 的核心设计
分块预填充（Chunked-Prefills）
机制：将长的输入提示分割成近似相等的计算块，每次仅计算一部分提示的预填充内容。 优势：避免长时间预填充对 Decode 阶段的干扰，同时允许在 Decode 阶段中插入计算。 效果：显著降低每次迭代的延迟，使延迟与提示长度基本无关。
无停滞调度（Stall-Free Scheduling）
机制：将 Decode 阶段与分块预填充的请求合并到同一个批次中，避免暂停当前的 Decode 操作。 优势：通过动态调整批次中的 token 数量，最大限度利用 GPU 计算资源，并保证延迟目标（SLO）。 效果：减少 Decode 阶段的延迟峰值，同时提升系统整体吞吐量。
性能评估
吞吐量与延迟的权衡
测试模型与数据集：在多种模型（如 Mistral-7B、Yi-34B）和数据集（如 openchat_sharegpt4 和 arxiv_summarization）上测试。 结果：与现有系统（如 vLLM 和 Orca）相比，Sarathi-Serve 在严格的延迟目标下实现了最高 6.3 倍的吞吐量提升。
多 GPU 配置中的表现
实验设置：在混合并行（tensor-parallel 和 pipeline-parallel）配置下对 Falcon-180B 模型进行测试。 结果：在低带宽网络环境中，Sarathi-Serve 通过减少流水线气泡（pipeline bubbles）实现了高效的 GPU 利用率，相较于传统的纯张量并行配置，其性能提升超过 3.6 倍。
分块预填充的开销
分析：较小的分块会增加 KV 缓存访问次数，导致 GPU 利用率略有下降。 结论：尽管分块会引入一定的固定开销，但在合理的分块大小（如 2048 tokens）下，其对性能的影响可以忽略不计。
主要贡献
提出两项关键技术：分块预填充与无停滞调度。 显著性能提升：在多种模型和硬件配置下验证了 Sarathi-Serve 的广泛适用性。 开放代码：提供开源实现，促进社区进一步研究与优化。
结论
Sarathi-Serve 有效解决了 LLM 推理阶段吞吐量与延迟之间的权衡问题，为大规模在线服务系统提供了一种高效、可扩展的解决方案。未来的工作可以进一步探索在异构硬件环境下的应用，以及与其他调度策略（如分离预填充与解码）进行深入比较的可能性。
往期 · 推荐
🌠 番外：我们期待与读者共同探讨如何在 AI 的辅助下，更好地发挥人类的潜力，以及如何培养和维持那些 AI 难以取代的核心技能。通过深入分析和实践，我们可以更清晰地认识到 AI 的辅助作用，并在 AI 时代下找到人类的独特价值和发展空间。“机智流”公众号后台聊天框回复“cc”，加入机智流大模型交流群！
一起“点赞”三连👇
