Baseten 优化 Qwen3-ASR 1.7B 批量转写，吞吐提升 7 倍

语音转文本分为两种截然不同的工作负载。一方面，实时转录关注的是延迟：语音智能体需要在用户说话后的几百毫秒内拿到文字结果。另一方面，批量转录关注的是吞吐量：播客网络、会议纪要产品和呼叫中心存档拥有数小时的录音，希望以尽可能低的成本完成转录。这意味着要让每块 GPU 处理尽可能多的音频小时数。

我们优化了 Baseten 上的 Qwen3-ASR 1.7B，在所有转录服务商中实现了最低的每音频分钟成本。与开箱即用的 vLLM 相比，优化后的技术栈在高并发下每秒转录的音频量提升了 7 倍。

Throughput vs. clip length for Qwen3-ASR 1.7B on vanilla vLLM versus Baseten's optimized stack, on a single RTX PRO 6000 at 64 concurrent requests. On vanilla vLLM, throughput plateaus around 380x real-time factor (RTF), and audio files over ten minutes don’t fit in one request. The optimized stack keeps climbing to 2,645x on 5-minute clips, and 3,128x on hour-long files. 在单块 RTX PRO 6000、64 个并发请求下，Qwen3-ASR 1.7B 在原生 vLLM 与 Baseten 优化技术栈上的吞吐量随音频片段长度的变化。在原生 vLLM 上，吞吐量在约 380 倍实时因子（RTF）处趋于平稳，且超过十分钟的音频文件无法放入单个请求。优化后的技术栈在 5 分钟片段上持续攀升至 2,645 倍，在长达一小时的音频文件上达到 3,128 倍。

Qwen3-ASR 1.7B：最准确的开放转录模型

Qwen3-ASR 1.7B 是 Qwen 团队的开源权重语音识别模型，以 Apache 2.0 许可证发布。它支持 30 多种语言和 22 种中文方言，并以 5.4% 的平均词错误率（WER）位于 Open ASR Leaderboard 的帕累托前沿。

我们实时部署的 Qwen3-ASR 1.7B 在 Coval 的语音转文本基准测试中也拥有最高的质量（即最低的 WER）和最低的延迟，该基准测试涵盖了市场上领先的转录模型，包括开源和闭源模型。

$Word error rate (WER) vs. model size for open-weight models on the Open ASR Leaderboard. Qwen3-ASR 1.7B (5.40%) sits on the Pareto frontier, within 0.07 points of NVIDIA Nemotron 3.5 Transcribe 30B-A4B (5.33%), the most accurate model, at a fraction of its size.$ Open ASR Leaderboard 上开源权重模型的词错误率（WER）与模型规模对比。Qwen3-ASR 1.7B（5.40%）位于帕累托前沿，与最准确的模型 NVIDIA Nemotron 3.5 Transcribe 30B-A4B（5.33%）仅相差 0.07 个百分点，而规模仅为其一小部分。

自发布之日起，Qwen3-ASR 就已在 Baseten 上提供批量转录服务。以下是我们如何让它比原生实现更快的方法。

我们优化的 Qwen3-ASR 技术栈

我们从 vLLM 的 OpenAI 兼容转录端点入手，该端点将音频切分为 30 秒窗口并分批送入模型。在此基础上，我们对请求在负载下的每个阶段进行了性能分析，重点聚焦于四个方面：

原生音频解码
KV 缓存量化（无质量损失）
主机到设备同步
请求处理

以下是使我们的吞吐量提升 7 倍以上的部分关键改动。

原生音频解码

在任何模型工作开始之前，服务器必须将上传的 M4A 或 MP3 文件转换为 16 kHz 单声道采样。

默认情况下，vLLM 的音频加载器使用 PyAV 在 Python 中逐帧解码音频，并即时重采样。每个帧步骤都会持有 Python 的全局解释器锁，因此解码线程是串行执行的，而非并行运行。这在高并发下造成 CPU 瓶颈，而 GPU 处于空闲状态。

我们将加载器替换为 torchcodec，它通过一次原生调用将整个文件交给 FFmpeg，在返回张量之前完成解码、重采样和降混。这种异步方式在编解码器处理请求时释放了解释器锁，输出与 PyAV 完全相同。

对于长文件，我们更进一步，按时间范围并行解码并下混文件。每个范围处理时带有少量重叠，确保拼接回去时比特级精确无误。经过这些改动，我们可以在远不到一秒的时间内预处理一小时的音频。

原生 vLLM 的 Python 解码器与 Baseten 原生解码器处理单个一分钟文件的解码耗时对比（服务端测量）。Python 解码器单独运行时耗时 76 毫秒，但 8 个文件同时解码时每个文件耗时 2,195 毫秒，因为线程在解释器锁上串行化。相比之下，原生解码器单独运行时耗时 45 毫秒，8 个并发时耗时 48 毫秒，因此解码吞吐量随线程数扩展。

KV 缓存量化

在高并发下，对 KV 缓存的注意力计算占 GPU 时间的最大份额。解码注意力是内存受限的：每一步都要读取每个运行序列的每个缓存键和值，当有 1,000 个 30 秒窗口在运行时，每一步都要读取整个缓存。

将 KV 缓存以 FP8 存储可将每一步读取的字节数减半，并使 GPU 内存中可容纳的序列数翻倍。一个挑战是 vLLM 默认的 FlashAttention-2 后端在 RTX PRO 6000 上不支持 FP8 缓存，这促使我们改用 FlashInfer 内核。FlashInfer FP8 将注意力内核的内存利用率从 50% 提升到 80%。

我们将权重保持在 BF16，因为权重量化增加了测试集上的词错误率（WER）。虽然 FP8 缓存也是有损的，但对准确率的影响极小，因为注意力计算仍保持全精度，且每一层都从全精度激活重新计算其缓存。

优化后解码器各阶段所选的精度。音频编码器和解码器权重保持 BF16，因为编码器只占 GPU 时间的一小部分，且 FP8 量化的权重会影响准确率。KV 缓存作为内存流量的最大来源，改为 FP8，这使每一步所需的字节数减半，并使在途序列数翻倍。注意力数学运算以全精度运行，并在每一层从全精度激活重新计算，因此舍入误差不会累积。

最小化主机到设备的同步

在负载下，GPU 跟踪显示即使内核接近其硬件极限，步骤之间仍存在空闲。

这些间隙来自 CPU；正常情况下，CPU 在 GPU 仍在工作时准备下一步，但为此，注意力后端需要每个序列的长度，而该长度存储在 GPU 上。将其复制回来迫使 CPU 等待 GPU 完成。因此，下一步无法提前准备，而 GPU 在等待期间也处于空闲状态。

音频编码器在每一层都做同样的事，读取最大片段长度以确定其注意力掩码的大小。每次回读都是一个同步点：CPU 在它返回之前无法入队下一个内核，因此 GPU 会断流。

由于这两个值在步骤开始前在 CPU 上已知，我们保留主机端副本并据此构建元数据和掩码，从而消除空闲时间。负载下的 GPU 利用率从 86% 提升到 97%，引擎从 CPU 受限变为 GPU 受限。

请求处理

除了这些改动，我们还调整了请求在服务器中的流转方式，使预处理在 64 个并发请求下能跟上 GPU 的速度。

四个 API 服务器进程运行在引擎之前，因此不同请求的音频解码和 log-mel 特征提取会在多个进程间并行进行，而不是在单个进程内争抢资源。

由于解码不再在解释器锁上串行化，我们将每个进程中的预处理线程池扩大了一倍。

结果

对于下文报告的所有结果，“Vanilla vLLM”指的是未做任何改动的上游 vLLM 上的 Qwen3-ASR 1.7B，而我们的优化实现则包含上述改动。两者均运行在单张 RTX PRO 6000 上，使用相同的权重。

吞吐量结果：吞吐量提升 7 倍以上

在 64 个并发请求下测试，每秒实际耗时转录的音频秒数显示，我们的优化实现相比 vLLM 吞吐量提升最高可达 7 倍。

我们无法在 vanilla vLLM 上测试超过 10 分钟的音频片段，因为它们无法放入单个请求中。

Throughput vs. concurrent requests for 5-minute clips on vanilla vLLM versus Baseten's optimized stack. Vanilla vLLM plateaus around 380x real-time factor from 16 concurrent requests onward, while the optimized stack keeps scaling to 2,645x at 64 concurrent, because decode no longer serializes requests, eliminating idle GPU time. 在 vanilla vLLM 与 Baseten 优化栈上，5 分钟片段的吞吐量与并发请求数的关系。Vanilla vLLM 从 16 个并发请求开始，实时因子在 380 倍左右趋于平稳，而优化栈在 64 并发时持续扩展至 2,645 倍，因为解码不再串行化请求，消除了 GPU 空闲时间。

增益随片段长度增长，从 10 秒片段的 4 倍到 5 分钟片段的 7 倍，并且我们的栈在 30 分钟和 1 小时文件上继续攀升，而这些文件此前无法放入单个请求。

延迟结果：延迟降低 6.9 倍

与吞吐量类似，延迟改进也随负载增加而扩大。对于 5 分钟片段，单个请求从 5.1 秒降至 1.5 秒，在 64 个并发请求下，中位数从 50 秒降至 7.3 秒。

此前必须由调用方拆分的文件现在可以在单个请求中返回：30 分钟音频耗时 3.0 秒，完整一小时耗时 4.7 秒。

Median latency vs. concurrent requests for 5-minute clips on vanilla vLLM vs. our optimized stack. On vanilla vLLM, latency climbs from 5.1 sec at a single request to 50.4 sec at 64 concurrent requests, while the optimized stack stays between 1.5 sec and 7.3 sec across the same range, a gap that grows from 3.4x to 6.9x as load increases. 在 vanilla vLLM 与我们的优化栈上，5 分钟片段的中位延迟与并发请求数的关系。在 vanilla vLLM 上，延迟从单个请求的 5.1 秒攀升至 64 并发请求的 50.4 秒，而优化栈在同一范围内保持在 1.5 秒至 7.3 秒之间，随着负载增加，差距从 3.4 倍扩大至 6.9 倍。

每音频小时成本

吞吐量影响价格，因为用相同的 GPU 分钟（或秒）可以完成更多工作。

按照 Baseten 对专用 RTX PRO 6000 的标价以及上述持续吞吐量，优化部署转录一小时音频的成本约为十分之一美分（每音频小时 $0.0013），比同一模型在 vanilla vLLM 上的 $0.011 低 8 倍。

我们的实现成本也比流行的闭源提供商低约 277 倍，后者的价格在 $0.21-$0.36 之间。

Baseten 成本通过在一张 RTX PRO 6000 上以一小时文件饱和运行并使用标价估算；闭源提供商定价根据本博客最后更新日期时其当前旗舰批处理模型的公开按需付费定价估算。

为您的批处理转录工作负载试用 Qwen3-ASR

这个优化的 Qwen3-ASR 部署是我们模型库中的默认选项。一键部署，并使用任何 OpenAI 兼容的转录客户端调用它，或将其与Nemotron 3 Diarization 配对以获得说话人归属的转录文本。

如果你需要的是实时转写，我们的流式 Qwen3-ASR 预设提供的是同一个模型。对于更大批量的工作负载，或者你希望我们优化的特定模型，请联系我们与我们的工程师交流！