[Paper] FASER：细粒度阶段管理用于动态 LLM 服务中的推测解码

Source: arXiv - 2604.20503v1

概览

本文提出了 FASER，一种用于服务大语言模型（LLMs）的新系统，使投机解码（SD）在真实世界、流量变化的工作负载中更加灵活。通过在更细粒度上管理草稿和验证阶段，FASER 的吞吐量提升最高可达 53 %，延迟相比最佳现有服务堆栈降低近一半。

关键贡献

• 细粒度的每请求投机长度 – 不再为整个批次使用单一草稿长度，FASER 根据每个查询的特性定制投机 token 的数量。
• 验证过程中的提前剪枝 – 一旦识别出被拒绝的草稿 token，即刻将其丢弃，防止下游工作浪费。
• 分块的验证前沿 – 将验证步骤拆分为多个小的“前沿”，这些前沿可以与正在进行的草稿阶段并行运行，实现空间复用且几乎不产生干扰。
• 与 vLLM 集成的原型 – 在普通 GPU 上展示了实际收益（吞吐量提升最高达 53 %，延迟降低最高达 1.92×）。
• 动态负载自适应 – 系统能够在低流量（GPU 资源未充分利用）和高流量（GPU 过载）场景下自动平衡资源。

方法论

1. 动态投机长度选择 – 对于每个传入请求，FASER 根据模型的置信度和当前系统负载预测一个最优的草稿长度。该预测轻量且在 GPU 核心启动前于 CPU 端运行。
2. 提前令牌剪枝 – 在验证阶段将草稿令牌与真实模型进行比对时，任何未通过验证测试的令牌会被立即丢弃，从而释放 GPU 通道供其他工作使用。
3. 基于前沿的验证 – 验证工作被划分为若干小的、相互独立的块（前沿）。每个前沿可以在其对应的草稿块完成后立即启动，使草稿和验证内核在时间上实现重叠。
4. 细粒度空间复用 – GPU 调度器被指示为草稿前沿和验证前沿分配独立的线程块，确保它们共享同一 SM（流式多处理器）而不争用相同的寄存器或共享内存。
5. 与 vLLM 的集成 – 作者对 vLLM 的请求调度器进行补丁，加入 FASER 的策略，然后在标准 LLM 基准（如 LLaMA‑2‑13B、Mistral‑7B）上测量端到端的延迟和吞吐量。

结果与发现

这些收益在混合负载条件下最为显著，此时传统 SD 要么停滞（低负载），要么使 GPU 超负荷（高负载）。通过持续调整投机长度并重叠各阶段，FASER 使 GPU 保持忙碌而不会被无用工作淹没。

Practical Implications

• Higher QPS for SaaS LLM APIs – Cloud providers can serve more requests per GPU, reducing cost per token and enabling cheaper pricing tiers.
• Lower latency for interactive apps – Chatbots, code assistants, and IDE plugins benefit from sub‑second response times even when the backend is under heavy load.
• Better resource elasticity – Operators can run fewer GPU instances while still meeting SLAs, simplifying autoscaling logic that otherwise has to over‑provision for traffic spikes.
• Compatibility with existing stacks – Since FASER is built on top of vLLM and only tweaks the scheduler and kernel launch patterns, it can be dropped into most PyTorch‑based serving pipelines with minimal code changes.
• Potential for edge deployment – On devices with limited compute (e.g., on‑device inference accelerators), the early pruning and fine‑grained phase overlap can conserve power and improve real‑time responsiveness.

限制与未来工作

• 模型特定调优 – 最佳的投机长度预测器是针对每个模型单独训练的；将其扩展到异构模型库可能需要额外的工程工作。
• GPU 架构依赖 – 空间复用策略假设有足够的 SM（流式多处理器）来容纳并行的草稿和验证前沿；核心较少的老旧 GPU 可能收益降低。
• 调度开销 – 动态的每请求决策会增加少量 CPU 开销，在极高请求率下可能成为瓶颈。
• 未来方向 作者提出包括：
  1. 通过强化学习自动化投机长度预测器。
  2. 探索多 GPU 协调以实现分布式服务。
  3. 将前沿概念扩展到管道的其他阶段，例如 token 后处理或检索增强生成。

作者

• Wenyan Chen
• Chengzhi Lu
• Yanying Lin
• Dmitrii Ustiugov

论文信息

• arXiv ID: 2604.20503v1
• 分类: cs.DC
• 发布时间: 2026年4月22日
• PDF: 下载 PDF