推理框架大洗牌！浙大&阿里提出增强型LLM推理引擎，从原理到实测，彻底搞懂33倍吞吐量提升的秘密！

增强型大语言模型（LLMs）推理服务系统正成为下一代 Web 服务的关键基础设施，提升增强型 LLM 推理服务效率并优化服务级别目标 (Service Level Objectives，SLOs)对于改善用户体验至关重要。因此，推理系统必须在延迟限制内最大化请求处理能力，即提升有效吞吐量（effective throughput）。然而，现有系统面临两大挑战：(i) 依赖先到先服务（FCFS）调度策略导致严重的队头阻塞（head-of-line blocking），使大量请求的排队延迟超出SLOs；(ii) 静态的token批处理无法适应动态变化的负载和硬件状态。这两个因素都降低了有效吞吐量与服务质量。

针对上述挑战，浙江大学联合阿里的研究者们提出一种面向增强型LLM推理服务的高效推理框架AugServe，旨在降低排队延迟并提升有效吞吐量。该框架的核心思想是一种两阶段自适应请求调度策略。第一阶段，AugServe结合增强型 LLM 请求的推理特征来优化调度决策的执行顺序；第二阶段利用运行时信息持续优化调度决策，以动态适配请求特性与系统能力。此外，AugServe能基于硬件状态与实时负载动态调整token批处理机制，进一步提升吞吐量性能。实验结果表明，相较于vLLM和InferCept，AugServe 的有效吞吐量分别提升了 4.7–33.1 倍 和 3.3–13.2 倍，同时将首token延迟（TTFT）分别降低了96.3%和95.0%。

• 论文标题：

  AugServe: Adaptive Request Scheduling for Augmented Large Language Model Inference Serving

• 论文链接：
  https://arxiv.org/pdf/2512.04013

01 方法

图1展示了增强型 LLM 推理服务的工作流程 ：

• 在推理过程中，增强型LLM识别出实时信息需求并触发相应的工具调用；
• 推理过程随即暂停，等待外部增强模块的响应；
• 获得响应后，服务系统将其附加至已生成的序列中，并恢复正常的文本生成。

此外，推理系统需高效处理大量并发用户请求，且这些请求必须满足 SLOs 要求（例如，首 token 延迟需低于某一固定阈值）。因此，推理系统必须在延迟约束范围内最大化请求处理能力 ，该指标通常被称为有效吞吐量，定义为单位时间内成功完成并满足SLOs的请求数量，反映了系统的实时性能。

AugServe 由三个模块组成：

(1) 预测模块

高效调度需要预先了解请求的输出长度，而该信息在解码完成前是未知的。借鉴现有输出长度预测研究，研究团队微调了一个轻量级BERT-base-uncased模型，用于同时预测输出长度范围与API调用时长。该模型仅包含数百万参数，能以可忽略的开销实现快速预测，能够无缝集成至服务流水线。

针对输出长度预测，将长度范围离散化为若干区间（buckets），并将预测任务建模为分类问题。对于API调用时长预测，采用回归方法并利用不同API类型的观测时间分布进行建模。

研究团队在 Merge 和 ToolBench 数据集上分别以 70/30 和 60/40 的比例进行划分，用于模型训练和评估。实验结果表明，该模型在 ToolBench 上的输出长度预测准确率达到 85%，在 Merge 上达到 65%；API 调用时间的均方误差（MSE）分别约为 5 秒和 0.4 秒，足以支撑调度策略。

(2) 调度模块

在增强型LLM推理服务中，请求调度必须应对高度异构的特性，包括输入长度、输出长度、API调用时长及返回数据长度。

传统的单阶段调度器通常在请求进入系统时，仅依据预测的长度或响应时间对请求进行排序，这类静态决策容易放大预测误差。

例如，若将长请求误判为短请求并将其置于队列头部，在API调用期间丢弃其上下文并在返回后重新计算，将导致GPU内存过度占用并阻塞后续请求——这正是队头阻塞问题的一个典型实例。若缺乏运行时修正机制，此类错误将持续累积，显著增加排队延迟并降低系统吞吐量。

因此，一个高效的调度框架必须将预测信号与执行过程中的自适应修正相结合。基于此原则，研究团队提出了两阶段调度价值评估机制，分别在 API 调用前和调用后两个阶段对请求进行评估与优先级排序，从而将预测前瞻性与运行时自适应性有机融合。

• 第一阶段：预测性价值评估

当一个请求到达时，系统基于预测特征（包括输出长度范围、API 调用时长、返回内容长度以及上下文处理策略）计算一个临时调度价值。依据此调度价值对请求排序，系统可优先处理预期成本更低、完成速度更快的请求，从而缓解因长请求占据队列前端所引发的队头阻塞问题。

• 第二阶段：运行时修正与重排序

尽管第一阶段提供了基于预测的调度价值 ，但其准确性受限于输出长度、API 调用时间及策略预测中的不确定性。这些误差可能不断累积，导致请求优先级排序失真，进而增加整体排队延迟。

为缓解此问题，研究团队利用运行时观测数据替代预测值，对每个请求的调度价值进行修正。修正后的调度价值能更准确地反映请求的实际资源消耗，并用于API调用后的优先级重排序。

• 防饥饿机制

在最终调度价值的基础上，研究团队引入一个防饥饿项，以确保长时间等待的请求能够逐步获得更高的优先级。等待时间定义为当前时间与该请求上次调度时间之间的差值，引入系数α ，用于调控公平性与吞吐量之间的权衡：

(3) 动态 token 批处理（Dynamic Token Batching）

现有系统通常采用固定的batch token上限来保护 GPU 内存，但这种静态策略限制了系统吞吐量。

为解决这一问题，研究团队设计了一种动态 token 批处理模块，根据运行时资源可用情况动态调整每轮迭代可处理的最大 token 数量。其中，需要监控两个关键指标：(i) 空闲的GPU内存； (ii) 已暂停请求的上下文内存。将已暂停的内存配置为可以被活跃请求抢占，因此这两部分之和被视为可用容量。

为防止可用 GPU 内存的瞬时波动导致token预算过度扩展和内存过载，研究团队引入了有界约束，既保证了实时条件下的灵活扩展，又避免了因短期内存波动而产生过度调整。

02 评估

如图 7所示 ，在所有负载水平下，AugServe 均取得最高的有效吞吐量。

在 Merge 数据集上（对应图7中的三种实验配置），AugServe 的有效吞吐量分别比 vLLM 平均提升 33.2×、5.9× 和 15.0×，比 InferCept 提升 12.9×、3.4× 和 6.8×。在 ToolBench 数据集上也观察到类似的性能优势。例如，在H800 GPU上以 5.0 req/s 的负载运行ToolBench任务时，vLLM 和 InferCept 的有效吞吐量分别为 0.25 req/s 和 0.21 req/s，而 AugServe 仍维持在约 2.35 req/s 的高水平。

随着负载增加，FCFS调度引发更严重的HoL阻塞，高并发则加剧GPU内存争用，导致频繁的KV交换和重计算。这些因素增加了延迟，造成大量请求未能满足SLOs，导致vLLM和InferCept的吞吐量大幅下降。相比之下，AugServe 通过智能调度与动态批处理，缓解了高负载下的队头阻塞与显存瓶颈。因此在消费级 GPU （如 RTX 4090）上优势显著，有效吞吐量超越vLLM和 InferCept 10 倍以上。

图7 在不同模型和 GPU 上，vLLM、InferCept 和 AugServe 在 Merge 与 ToolBench 数据集上的有效吞吐量（req/s）对比结果

图 8 展示了 AugServe 与 vLLM、InferCept 在不同配置下的平均 TTFT 对比。**在所有实验场景中，AugServe 均显著优于基线方法，TTFT 最高降低 96.3%和95.0%。随着负载增加，各系统的 TTFT 均有所上升，但 AugServe 仍保持卓越性能。**例如，在 H800 GPU 上以 5.0 req/s 的负载运行 Merge 任务时，AugServe 的平均 TTFT 相比 InferCept 和 vLLM 分别降低了 90.8% 和 90.5%。

图8 在不同模型和 GPU 上，vLLM、InferCept 和 AugServe 在 Merge 与 ToolBench 数据集上的TTFT对比结果

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

第一阶段（10天）：初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。

• 大模型 AI 能干什么？
• 大模型是怎样获得「智能」的？
• 用好 AI 的核心心法
• 大模型应用业务架构
• 大模型应用技术架构
• 代码示例：向 GPT-3.5 灌入新知识
• 提示工程的意义和核心思想
• Prompt 典型构成
• 指令调优方法论
• 思维链和思维树
• Prompt 攻击和防范
• …

第二阶段（30天）：高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。

• 为什么要做 RAG
• 搭建一个简单的 ChatPDF
• 检索的基础概念
• 什么是向量表示（Embeddings）
• 向量数据库与向量检索
• 基于向量检索的 RAG
• 搭建 RAG 系统的扩展知识
• 混合检索与 RAG-Fusion 简介
• 向量模型本地部署
• …

第三阶段（30天）：模型训练

恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。

到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？

• 为什么要做 RAG
• 什么是模型
• 什么是模型训练
• 求解器 & 损失函数简介
• 小实验2：手写一个简单的神经网络并训练它
• 什么是训练/预训练/微调/轻量化微调
• Transformer结构简介
• 轻量化微调
• 实验数据集的构建
• …

第四阶段（20天）：商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。

• 硬件选型
• 带你了解全球大模型
• 使用国产大模型服务
• 搭建 OpenAI 代理
• 热身：基于阿里云 PAI 部署 Stable Diffusion
• 在本地计算机运行大模型
• 大模型的私有化部署
• 基于 vLLM 部署大模型
• 案例：如何优雅地在阿里云私有部署开源大模型
• 部署一套开源 LLM 项目
• 内容安全
• 互联网信息服务算法备案
• …

学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越优秀的自己。

如果你能在15天内完成所有的任务，那你堪称天才。然而，如果你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的正确特征了。

这份完整版的大模型 AI 学习资料已经上传优快云，朋友们如果需要可以微信扫描下方优快云官方认证二维码免费领取【保证100%免费】