当语音识别服务遇上"塞车"难题：Sprinklr工程师如何用排队技巧让AI更快响应

这项由印度Sprinklr公司工程团队完成的研究，以会议论文形式发表于2026年ICLR（国际学习表征会议）配套的CAO研讨会，论文编号为arXiv:2603.11273v1，提交时间为2026年3月11日。对原论文感兴趣的读者可以通过该编号在arXiv上查阅完整内容。

---

一、收银台前的"噩梦"：当语音识别系统被长队堵住

每次你对手机说"嘿，帮我订一杯咖啡"，背后都有一台语音识别系统在飞速工作。它把你说的话变成文字，再交给后续程序处理。这个过程听起来简单，但当同时有成百上千人发出请求时，情况就变得复杂了——就像超市里只有一个收银台，队伍里既有只买一瓶矿泉水的人，也有推着满满一购物车商品的顾客。

Sprinklr的工程师们发现了一个非常具体的问题：目前主流的语音识别服务系统（比如广泛使用的vLLM推理引擎），都默认采用"先来先服务"的排队方式。这没什么问题，直到一段很长的录音排在了最前面——它就像那位推着满载购物车的顾客，把后面一大排只买一瓶水的人全部堵死了。工程团队把这种现象称为"队头阻塞"，在技术圈里这是个老生常谈的痛点，但在语音识别领域，它带来的延迟问题始终没有得到系统性的解决。

于是，这支团队决定做一件听起来很简单、但实操起来颇有讲究的事：给语音识别排队系统加上"智能分流"能力。

---

二、关键发现：音频时长，就是最天然的"插队凭证"

在超市里，"快速通道"通常要求顾客购买商品不超过10件。判断一个顾客"快不快"，只需要数数他篮子里的东西。那么，判断一段语音识别请求"长不长"，有没有类似的简单方法？

Sprinklr的工程师们研究后发现，答案就藏在音频文件本身里：音频的时长。

这背后有一个简洁的逻辑链条。语音识别系统（以广泛使用的Whisper模型为例）处理一段音频时，主要分两步：第一步是"编码"，把音频转化为机器能理解的数字特征，这个过程时间比较固定；第二步是"解码"，把那些数字特征一个词一个词地翻译成文字，这个过程的时间会随着输出文字数量的增加而线性增长。换句话说，处理时间主要取决于最终输出了多少文字。

而人类说话的速度在不同人、不同场合下差异不大。一个人说话10秒，比说话5秒产出的文字大约多一倍。工程师们用LibriSpeech英语测试集和多语言的FLEURS数据集验证了这一点：把音频时长和最终输出的文字数量画成散点图，会发现两者之间呈现出非常清晰的线性关系，相关系数（R?）在英语上高达0.929，在西班牙语、印地语、阿拉伯语上也分别达到0.81、0.74和0.70。这意味着，只要知道一段音频有多长，就能相当准确地预测系统处理它需要多少时间。

这个发现极为关键，因为在文字生成领域（比如让AI写文章），没人知道它最终会写多长，必须靠专门训练的预测模型来猜。但语音识别不同——音频时长是请求送达时就已知的信息，完全不需要额外的预测步骤，零成本可得。

---

三、两种"分流策略"：激进派与温和派

有了这把"尺子"（音频时长），工程师们实现了两种排队策略，分别代表了不同的取舍哲学。

第一种叫做"最短任务优先"（SJF，Shortest Job First）。顾名思义，就是谁的音频最短，谁就先处理。这在操作系统调度理论里是一个经典算法，能在数学上保证所有请求的平均等待时间最短。实现起来也很直接：维护一个按音频时长排序的优先队列，系统每次从队列里取出时长最短的任务来处理。如果两个任务时长相同，先到的先处理，保持基本公平。整个插入和取出的操作效率是O(log n)——即便队列里有一千个任务，找到最短的那个也只需要很少的计算步骤。

不过，SJF有个显而易见的副作用：如果源源不断地有新的短音频涌入，队列里那些长音频可能永远没有机会被处理，陷入"无限等待"，这种现象叫做"饥饿"。对于那些录了一段较长会议的用户来说，体验会非常糟糕。

第二种策略叫做"最高响应比优先"（HRRN，Highest Response Ratio Next），专门用来解决SJF的饥饿问题。它的核心思想是：给每个任务动态计算一个"优先分数"，计算公式是（等待时间 + 预估处理时间）÷ 预估处理时间。这个公式很有意思：一个短任务刚到时，预估处理时间小，分子里的等待时间也是零，所以得分不高；但随着它在队列里等待时间变长，分子越来越大，得分也随之攀升，最终会超过那些不断涌入的新短任务。而一个长任务，虽然每次计算时分母很大，但只要它等得够久，迟早也能获得足够高的分数排到前面。

换句话说，HRRN就像一个"积分兑换"系统——短任务天然有优势，但长任务只要耐心等待，积累足够的"等待积分"，照样能排上号，不会被无限插队。

---

四、实验设计：用两种"考场环境"检验策略的真实效果

光有理论不够，工程师们把这两种策略实际集成到了vLLM这个主流推理引擎里，然后在真实的语音识别场景下做了系统测试。

测试用的模型是Whisper的最大版本whisper-large-v3，参数量达到15亿，运行在一块英伟达A100显卡上。为了让测试结果更有说服力，他们设计了两个截然不同的数据集场景。

第一个场景使用的是LibriSpeech test-clean数据集的原始版本。这是一个标准的英语语音测试集，音频时长从1秒到35秒不等，平均约7.4秒，整体分布是右偏的——也就是说，大多数音频比较短，只有少数音频特别长。这种分布很接近真实世界里语音助手的使用场景：大部分指令都很简短，偶尔才有长段录音。

第二个场景则是他们自己构造的"合成数据集"：从LibriSpeech里精心挑选，凑出时长恰好为5秒、10秒、15秒、20秒、25秒、30秒各一批的音频，使得长短音频数量相等，均匀分布，平均时长提升到17.5秒。这样做的目的是测试：当短音频不再占多数时，那些依赖"短任务比较多"才能发挥优势的策略，是否还能继续奏效？如果在这种均匀分布下策略的效果消失了，就说明之前的好结果只是碰巧利用了数据集的特性，并不普遍。

两个场景都模拟了真实的持续请求流：请求按照泊松过程随机到来（这是描述"随机但有一定规律"的标准统计模型），每次测试运行5分钟，请求到达速率从每秒1个到每秒25个逐步增加，覆盖了从轻松应对到严重过载的全部工况。所有三种策略（原始的先来先服务、SJF、HRRN）在完全相同的请求序列上测试，确保对比是公平的。

评估指标主要有两个：端到端延迟（E2EL），即从用户发出请求到收到完整转录结果的全部时间；首词延迟（TTFT），即从发出请求到收到第一个输出词的时间，更直接反映"感知响应速度"。两个指标都同时关注中位数（P50，代表普通用户的典型体验）和90百分位数（P90，代表最慢的那10%用户的体验）。

---

五、数据说话：惊喜与代价同在

在LibriSpeech原始数据集上，三种策略的表现随着请求速率的提升呈现出非常鲜明的分化。

当请求速率较低（每秒1到10个）时，系统处理能力绰绰有余，三种策略的表现差异不大。即便如此，在每秒10个请求这个边界位置，SJF已经能把P50和P90的端到端延迟各降低6%和8%，HRRN则能把两者都降低8%，说明只要队列稍微有点积压，排队顺序就开始产生作用。

进入中等负载阶段（每秒10到20个请求），差距开始拉开。以每秒17个请求为例，SJF能把P50延迟降低23%，但代价是P90延迟小幅上升5%——少数长音频开始感受到被"插队"的影响。HRRN把P50降低了10%，P90上升9%，表现比SJF温和但更均衡。

到了高负载阶段（每秒20到25个请求），系统开始明显过载，效果更加戏剧化。在每秒25个请求时，SJF的表现令人瞠目结舌：P50端到端延迟从5423毫秒骤降到1486毫秒，降幅高达73%；P50首词延迟从4273毫秒降至296毫秒，降幅达93%。但硬币的另一面同样触目惊心：P90端到端延迟从8334毫秒反升到16405毫秒，涨幅达97%——那些长音频的用户，等待时间几乎翻倍了。

HRRN在这个场景下展现了它的价值：P50端到端延迟降低28%，P50首词延迟降低33%，而P90端到端延迟仅上升24%。这个"24%"和SJF的"97%"放在一起，就能清楚看出HRRN为长任务用户提供了实质性的保护。

在合成均匀分布数据集上，结论发生了微妙但重要的变化。SJF的P50延迟优势依然存在并且幅度相近——每秒25个请求时P50降低67%——这证明排队顺序优化的价值并不依赖于"短音频特别多"这一前提。更有趣的是，SJF的P90尾部代价反而变小了：同样在每秒25个请求时，P90延迟上升幅度只有29%，远低于LibriSpeech场景下的97%。原因也不难理解：在均匀分布里，长音频和短音频到达频率相同，队列里不会被短音频"淹没"，长音频不会被持续插队，饥饿现象自然减轻。HRRN的尾部代价也相应收窄到14%。

关于系统吞吐量，工程师们专门核查了一个重要问题：换了排队策略会不会影响系统整体的处理速度？答案是不会。所有三种策略的吞吐量曲线完全重合，LibriSpeech数据集下系统饱和点在每秒约18个请求，合成数据集下约为每秒13个请求，与策略无关。每次排队决策带来的额外计算开销平均不足0.1毫秒，相比系统处理一段音频所需的几十到上百毫秒完全可以忽略不计。

---

六、极端考验：500个请求同时砸来会怎样

为了测试边界情况，工程师们还设计了一个"突发洪峰"实验：把全部500条LibriSpeech录音同时提交给系统，模拟突发流量暴增的极端场景。

在这种情况下，三种策略的差距比持续过载场景要小得多，这在逻辑上完全说得通——因为所有请求一瞬间全部入队，SJF在处理早期可以快速清掉短任务，但后续不再有新的短任务持续"插队"，所以饥饿现象不会那么严重，SJF的优势也相应减弱。具体数字上，SJF把P50首词延迟降低2.1%，P50端到端延迟降低3.7%；HRRN则分别降低9.6%和10.7%。在这个场景下，HRRN反而全面超越了SJF——因为随着突发请求被逐渐处理，等待时间长的请求会积累更高的响应比，HRRN的"等待积分"机制在此充分发挥了作用，避免了任何任务陷入极端等待。

此外，工程师们还在规模较小的Whisper-Medium模型（参数量7.69亿，约为Large-v3的一半）上重复了实验。结论一致：策略排名顺序相同，SJF对P25延迟的改善最显著，HRRN在中位和尾部之间提供最均衡的保护，只是系统饱和点提升到了约每秒21个请求（因为小模型运算更快）。这说明这套方法并非针对某个特定模型大小"调参"出来的，而是具有更广泛的适用性。

---

七、落地实现：只需修改250行代码

一项好的工程研究不只是证明"能行"，还要证明"好做"。这支团队特别在论文中公开了实现细节，让其他工程师可以直接参考。

整个修改只涉及vLLM引擎的五个文件，新增约250行代码，不需要改动核心的请求数据结构。具体来说，在接收音频请求的API端点，系统会在进行声学预处理之前先读取音频的原始时长，乘以一个语言相关的系数κ（English为5.34个词元/秒），得到预估输出词元数，然后把这个数字附加到请求参数里传给调度器。调度器里的SJF队列用一个最小堆按（预估词元数、到达时间、请求ID）三元组排序；HRRN队列则在每次取任务时实时计算所有队列中任务的响应比，取最高的那个。切换策略只需要在启动vLLM时加一个命令行参数：`--scheduling-policy sjf` 或 `--scheduling-policy hrrn`，其他什么都不用改。

---

八、还没解决的问题：研究团队的坦诚自述

论文中难得地列出了若干已知局限，这种坦诚值得关注。

第一个局限是"静音干扰"：如果一段音频里有大量停顿、前后有长段静默，实际说话内容其实很少，但按照总时长估算的话会高估处理时间。解决方案也有现成的：在估算前先用一个轻量级的语音活动检测（VAD）模块，只计算真正有声音的那部分时长。比如Silero VAD这类模型，每条音频额外处理时间不超过5毫秒，几乎无感。

第二个局限是"多语言系数固定"：当前实现对所有语言用同一个κ值，但不同语言的词元密度差异显著——比如阿拉伯语的κ是4.5，英语是5.34，西班牙语是3.3，如果混合多语言处理，固定系数会带来估算偏差。更精细的实现可以根据用户提交的语言标识自动选择对应的κ值。

第三个局限是"策略静态不切换"：现有实验把三种策略分别单独评测，实际生产环境里，系统负载会随时间波动——闲时没必要用SJF增加尾部风险，忙时才需要激进策略。未来可以实现一个动态监控机制，根据实时队列深度、尾部延迟指标和饥饿信号，在FCFS、SJF和HRRN之间自动切换。

---

归根结底，这项研究做了一件用"旧钥匙开新锁"的事。操作系统调度领域里几十年前就有的经典算法，在语音识别服务这个具体场景下找到了一把极其合适的钥匙——音频时长，一个天然可得、无需预测、完全免费的信号。实验结果表明，借助这个信号，系统在高负载下的典型响应延迟可以压缩三分之二以上，而改动成本极低，对现有系统几乎没有破坏性。

这对普通用户意味着什么？当你在嘈杂的会议室里说了一大段话等待系统转录，而服务器那边正好挤满了请求时，用了HRRN策略的系统不会让你等到崩溃，也不会为了照顾你而饿死其他短请求的用户——它在两者之间找到了一个更合理的平衡点。更快的首词出现时间，对于实时字幕、同声传译这类对延迟极度敏感的应用来说，意义尤为直接。

当然，这项研究只在单卡A100上测试，多卡分布式场景下调度逻辑会更复杂，那是下一步的探索空间。对于想深入了解技术细节的读者，可以在arXiv上通过编号2603.11273找到这篇论文的完整版本，附录里还提供了详细的代码实现说明。

---

Q&A

Q1：音频时长为什么能预测语音识别的处理时间？

A：因为人类说话速度相对稳定，音频越长，说的词越多，系统需要生成的文字也越多，而语音识别系统的处理时间主要取决于输出文字数量。研究发现英语音频时长与输出词元数量的相关系数高达0.929，这意味着时长几乎可以直接当作处理时间的替代指标来使用。

Q2：SJF和HRRN哪种调度策略更适合实际部署？

A：取决于对"公平性"的要求。SJF在高负载下能把系统中位延迟降低73%，但会让长音频用户的等待时间翻倍；HRRN牺牲部分中位延迟改善（降低28%），但把长音频用户的额外等待控制在24%以内。对于有服务级别协议、不能让任何用户等太久的场景，HRRN更稳妥。对流量突发型场景，实验也显示HRRN全面优于SJF。

Q3：在vLLM中启用这两种调度策略改动大吗？

A：改动非常小。Sprinklr团队的实现总共只修改了5个文件、新增约250行代码，不需要改动核心数据结构。切换策略只需要在启动vLLM时加一个命令行参数`--scheduling-policy sjf`或`--scheduling-policy hrrn`，每次调度决策的额外时间开销平均不超过0.1毫秒，对系统整体吞吐量没有任何影响。