模型性能使用 Qwen3-ASR 实现最快、成本最低的批量转写

使用 Qwen3-ASR 转写一小时音频仅需十分之一美分，吞吐量提升 7 倍，延迟降低 6.9 倍，且对质量没有明显影响。

作者

Hasan KhanAnsel Erol

发布于

2026 年 10 月 28 日

分享

    发布于

    2026 年 10 月 28 日

    How Baseten gets 7x throughput on Qwen3-ASR batch transcription简要总结

    Qwen3-ASR 1.7B 位于 Hugging Face 的 开放 ASR 排行榜的帕累托前沿，但要高效地将其用于批量转写，还需要细致的优化。我们结合了原生音频解码、KV 缓存量化以及减少不必要的主机到设备同步，在单张 RTX PRO 6000 上以高并发实现了每秒转写音频量提升 7 倍。对于长达一小时的文件，我们可持续达到超过 3,000 倍的实时因子（RTF），每音频小时成本约为十分之一美分，且词错误率没有明显变化。

    语音转文本可分为两种截然不同的工作负载。一方面，实时转写关注的是延迟：语音智能体需要在说话人开口后的几百毫秒内拿到文字。另一方面，批量转写关注的是吞吐量：播客网络、会议纪要产品和呼叫中心档案拥有数小时的录音，希望以尽可能低的成本完成转写。这意味着要让每块 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）位于 开放 ASR 排行榜 的帕累托前沿。

    我们实时部署的 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.开放 ASR 排行榜上开源权重模型的词错误率（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 秒窗口并分批送入模型。在此基础上，我们对请求在负载下的每个阶段进行了性能分析，重点聚焦于四个方面：

    1. 原生音频解码

    2. KV 缓存量化（不损失质量）

    3. 主机到设备同步

    4. 请求处理

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

    原生音频解码

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

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

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

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

    ✕Decode time per one-minute file for vanilla vLLM's Python decoder versus Baseten's native decoder, measured server-side. The Python decoder takes 76 ms on its own, but 2,195 ms per file when 8 files decode at once, because the threads serialize on the interpreter lock. In contrast, the native decoder takes 45 ms alone and 48 ms with 8 at once, so decode throughput scales with the number of threads.在服务器端测量的原生 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 缓存也是有损的，但对准确率的影响极小，因为注意力计算仍保持全精度，且每一层都会从全精度激活重新计算其缓存。

    ✕Precision chosen per stage in the optimized decoder. The audio encoder and decoder weights stay in BF16, since the encoder is a small share of GPU time and FP8-quantized weights affected accuracy. The KV cache, the largest source of memory traffic, moves to FP8, which requires half the bytes per step and enables twice the sequences in flight. The attention math runs at full precision and is recomputed from full-precision activations every layer, so rounding errors won’t compound.优化解码器各阶段所选的精度。音频编码器和解码器权重保持 BF16，因为编码器只占 GPU 时间的一小部分，而 FP8 量化权重会影响准确率。KV 缓存是内存流量的最大来源，改为 FP8 后，每步所需字节数减半，可同时运行的序列数翻倍。注意力计算以全精度运行，并在每一层从全精度激活重新计算，因此舍入误差不会累积。

    尽量减少主机与设备之间的同步

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

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

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

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

    请求处理

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

    四个 API 服务器进程运行在引擎之前，因此不同请求的音频解码和对数梅尔特征提取可以在多个进程间并行进行，而不是在一个进程内争用。

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

    结果

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

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

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

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

    ✕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.5 分钟片段在 vanilla vLLM 与 Baseten 优化栈上的吞吐量随并发请求数变化。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.5 分钟片段在 vanilla vLLM 与我们的优化栈上的中位延迟随并发请求数变化。在 vanilla vLLM 上，延迟从单个请求的 5.1 秒攀升到 64 个并发请求的 50.4 秒，而优化栈在同一范围内保持在 1.5 秒到 7.3 秒之间，随着负载增加，差距从 3.4 倍扩大到 6.9 倍。

    每音频小时成本

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

    按照 Baseten 专用 RTX PRO 6000 的标价和上述持续吞吐量，优化部署转写一小时音频的成本约为 1/10 美分（每音频小时 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 预设 提供相同的模型。对于更大的批处理工作负载或您希望我们优化的特定模型，请 联系我们 与我们的工程师交流！

    订阅我们的新闻通讯

    随时了解模型性能、推理基础设施等最新信息。

    ‌
    $?/$