负载漂移下 ASR 服务中的持续时间感知调度

TL;DR 利用音频时长作为处理时间的可靠代理，将 SJF 与 HRRN 调度集成到 vLLM，在 ASR 工作负载漂移下显著降低中位延迟，HRRN 兼顾尾延迟控制。

问题

在大规模自动语音识别（ASR）服务中，端到端（E2E）延迟是核心体验指标，尤其在语音助手、实时字幕和同声传译等交互场景，亚秒级响应至关重要。当前主流推理引擎（如 vLLM）普遍采用先到先服务（FCFS）调度策略，简单易实现，但忽视了不同请求处理时间的显著差异。

然而，FCFS 存在明显的队头阻塞（head-of-line blocking）问题：在负载波动（workload drift）下，若长音频请求先到达，其后的大量短请求会被阻塞，导致中位延迟剧烈增加，请求完成时间变得不可预测。ASR 模型（如 Whisper）的处理时间与输入音频时长高度线性相关，但现有调度器并未利用这一先验知识进行优化，使得系统在重载或突发流量时延迟恶化，且长尾延迟（P90）尤为脆弱。

该问题的难点在于：如何将音频时长这种廉价可得的特征转化为有效的调度决策信号，同时维持低调度开销（<0.1ms/请求）且不牺牲吞吐量。单纯采用最短作业优先（SJF）虽可大幅降低中位延迟，但会导致长请求饥饿，尾延迟急剧上升，破坏用户体验公平性。工程上需要一种能动态平衡延迟与公平的调度机制，并能在负载漂移下稳定工作。

这一挑战与大型语言模型（LLM）服务中基于输出长度预测的调度优化类似，都是利用输入特征对处理时间进行预测，以重塑请求执行顺序，提升交互式 AI 应用的响应性。

核心洞察

• 音频时长是 ASR 请求处理时间的天然且准确的代理，使得经典短作业优先调度可以直接应用于 ASR 推理服务。这一洞察的独特之处在于回避了通用 LLM 推理中输出长度难以预测的难题——因为 ASR 模型的输入是音频，其持续时间在请求抵达时即已可知，并且与编码器-解码器处理时间高度线性相关。这为无需复杂学习或预测器的实时调度提供了简单且有效的设计基础，与已有的基于运行时内存或迭代次数等非直接信号的方法形成对比，显著降低了实现复杂度和额外延迟。
• HRRN 动态老化机制在减少中位延迟与控制长请求尾延迟之间实现实用平衡，尤其应对工作负载漂移。与 SJF 单纯追求中位延迟最优却导致长请求饥饿不同，HRRN 通过综合考虑等待时间和预期服务时间，自适应地提升长等待请求的优先级，将 90 分位尾延迟恶化控制在 24% 以内，同时仍取得 28% 的中位延迟降低。该策略在无需预先定义严格优先级类别或执行预先抢占的情况下，自动适应请求大小分布的变化，为交互式 ASR 服务提供了更鲁棒的体验质量保障，超越了静态调度或简单大小阈值的方案。

方法

核心思路：利用音频时长作为处理时间代理

该方法在 vLLM 推理引擎中引入时长感知调度，以应对 ASR 工作负载漂移。其关键洞察是：对于 Whisper 等主流 ASR 模型，输入音频的物理时长与模型推理耗时高度相关，因此可直接用作作业处理时间（Service Time）的准确估计，无需额外预测模型。

调度器改造流程

1. 请求到达与时长获取
   每个 ASR 请求在进入调度队列时，会携带其音频时长元数据。调度器据此将请求标记为不同的 Request Class，时长即为服务时间估计值。

2. 调度策略实现

   • SJF (Shortest Job First)：始终从就绪队列中选择估计服务时间最短的请求执行。该策略最大程度降低中位数延迟，但缺少长请求防饿死机制，在高负载下会导致尾部延迟显著恶化。
   • HRRN (Highest Response Ratio Next)：每个请求动态计算响应比 R = (WaitingTime + ServiceTime) / ServiceTime，每次调度选择 R 最高的请求。随着请求等待时间增加，其优先级逐渐提升，从而在偏好短作业的同时，为长请求提供隐性老化保护，实现中位数延迟与尾部延迟之间的折中。

3. 与 vLLM 调度循环集成
   在原生 vLLM 的 FCFS 调度点插入基于优先级的选取逻辑；为支持 SJF/HRRN，实现细粒度抢占（当前运行的长请求可被新到达的更高优先级请求打断），避免队头阻塞。整个调度决策的额外开销控制在 < 0.1 ms/请求，且不损失吞吐。

实效与差异

实验表明，SJF 可将中位数 E2E 延迟降低最高 73%，但 90 百分位尾部延迟恶化近一倍；HRRN 则在降低中位数延迟 28% 的同时，将尾部延迟恶化控制在 24% 以内，且在负载漂移下同样稳定。

与面向 LLM 推理的调度（通常需预测输出长度）不同，本方法利用 ASR 领域中音频时长与处理时间的确定性关系，规避了预测误差，实现轻量、即插即用的调度升级，是大小调度（Size-based Scheduling）在语音服务场景的首次工程化验证。

实验

实验设计

实验基于 vLLM 推理引擎，将音频时长作为作业处理时间的代理，集成 SJF 与 HRRN 调度策略，并与默认的 FCFS 基线对比。数据集使用 LibriSpeech test-clean 原始划分及一个人工构造的时长分布漂移版本（Synthetic LibriSpeech Split），以模拟真实负载变化。评估指标包括端到端中位延迟、90 百分位尾延迟、吞吐量及调度开销。

关键发现

在高负载下，SJF 将端到端中位延迟最多降低 73% ，但长请求遭受饥饿，导致 90 百分位尾延迟上升 97% ，暴露了公平性缺陷。HRRN 在缩短中位延迟 28% 的同时将尾延迟劣化控制在 24% 以内，实现更均衡的权衡。二者均未引入吞吐量损失，且每请求调度开销低于 0.1 ms。负载漂移条件下增益保持稳定。

与基线对比解读

FCFS 对请求时长无感知，在负载突发或混合时长场景下易出现线头阻塞。SJF 显著优化了中位延迟，但以牺牲长请求为代价，不符合关注尾延迟的服务等级目标（SLO）。HRRN 动态计算响应比，兼顾等待时间与估计执行时间，既能有效缓解线头阻塞，又避免了极端饥饿，为延迟敏感ASR服务提供了一种无损吞吐的实用调度替代方案。

行业影响

落地场景

基于音频时长感知的调度策略可广泛应用于基于 Whisper 等 ASR 模型的大规模语音识别服务，如：

• 云语音 API 平台（类似 AWS Transcribe、Google Speech-to-Text），处理客户上传的批量或流式音频。
• 实时字幕与翻译系统，例如在线会议、直播、在线教育的实时字幕生成场景。
• 语音助手与智能音箱，需要快速响应短指令，同时不阻塞长对话流。
• 客服通话后分析，将大量录音转为文本，负载常出现突发高峰。

商业价值

• 提升用户体验：中位端到端延迟降低最多 73%（SJF），HRRN 方案在降低 28% 中位延迟的同时，将尾部延迟恶化控制在 24% 以内，避免少数长请求长时间等待。这直接满足语音交互场景对低延迟的苛刻要求，减少用户流失。
• 降本增效：通过缓解队头阻塞，减少空闲等待，提高 GPU 利用率；同时无需增加硬件即可支撑相同 QoS，降低单位请求成本。在 vLLM 等流行推理引擎中，调度开销 <0.1 ms/请求，无吞吐量损失。
• 增强 SLA 保障：对于服务等级协议中 P90/P99 尾延迟有严格要求的语音 API 产品，HRRN 可在不牺牲长请求的情况下控制尾部，提升服务竞争力与客户续费率。

与现有产品/工作流的接口

• 推理引擎集成：调度策略已实现在 vLLM 内部，可作为插件式调度器开关。现有采用 vLLM 的 Whisper serving 堆栈只需更新调度模块配置即可启用，无需改动模型或请求处理管线。
• 请求元数据传递：客户端或 API 网关需在请求头中携带音频时长（可从文件头或第一块数据预先解析），推理服务据此分配优先级。此改动轻量，与现有 REST/gRPC 接口兼容。
• 与自动扩缩容协同：在负载漂移（workload drift）下策略自动适应，可配合 Kubernetes HPA 等组件，在流量高峰维持尾延迟稳定。

具体落地案例

1. 云服务商的语音转文字 API：某云平台每日处理数十万小时音频，请求时长从几秒到几十分钟不均。使用 HRRN 调度后，短音频（如语音指令）响应时间显著下降，同时长音频（如会议录音）不会被饿死，服务整体 P95 延迟改善，客户投诉减少，无需新增 GPU 节点。
2. 在线教育实时字幕：直播课中大量学生开启字幕功能，并发请求突发增长。基于 FCFS 时，长句子音频可能阻塞后续短句子，导致字幕延迟抖动。集成 HRRN 后，短句字幕迅速返回，长句稍等但不会超时，师生互动更流畅，平台 NPS 提升。

局限

• **静音敏感性问题**：论文依赖音频时长作为处理时间的代理，但实际音频中可能包含大量静音段（如说话停顿、环境静音），导致时长高估实际计算量。尽管作者承认这一问题，但未提出补偿或剪裁方案，可能在高静音占比的录音上退化，使得短实际处理时间的请求被错误排到后面，削弱调度收益。
• **自适应参数缺失**：HRRN 调度中响应比阈值 κ 固定为 1.0，而不同负载模式（如长短请求比例变化）下最优 κ 可能不同。论文指出未来需研究自适应 κ，但当前结果依赖手动选择。此外，动态策略切换（如负载低时回退 FCFS）未实现，限制了在负载大幅波动时的鲁棒性。
• **模型与引擎泛化性**：仅基于 Whisper 模型与 vLLM 引擎验证，未探讨其他 ASR 架构（如 Conformer、Wav2Vec2）或推理框架（如 TensorRT-LLM、ONNX Runtime）。音频时长与处理时间的线性关系可能在某些模型（例如使用注意力掩码或流式解码的模型）上减弱，且不同引擎的请求排队机制可能影响调度收益，限制了结论的通用性。