我们迁移到 Groq，转录速度提升了 10 倍

上周我们切换到了新的转录后端。如果你最近处理过视频，你应该已经注意到了——它快了，明显地快了。

以下是发生的事情。

之前

自上线以来，我们一直在 GPU 实例上运行 Whisper Large V3。这套方案工作正常。一个 5 分钟的视频，根据服务器负载，转录大约需要 20-30 秒。不算差，也不算好。

问题在于扩展性。GPU 实例费用昂贵，高峰时期队列会积压。用户上传视频后，光等转录就要等 45 秒到 1 分钟。对于一个整个价值主张就是"快速字幕"的工具来说，这个等待时间已经开始损害用户体验。

我们研究了几个方案：增加 GPU 实例（昂贵）、使用更小的模型（准确性更差）、批处理优化（收益微薄）。都感觉不对。

然后我们测试了 Groq 的 LPU（Language Processing Unit）推理来运行 Whisper。第一个基准测试结果让我刷新了页面，以为计时器出了问题。

一个 10 分钟的视频。3.7 秒完成转录。这是 164 倍实时速度。

我重跑了一次。同样的结果。又跑了一个 30 分钟的播客单集。11 秒。

准确性是完全相同的——同样是 Whisper Large V3 模型，只是跑在不同的硬件上。相同的 8.4% 词错误率，相同的语言支持，相同的词级时间戳。唯一的区别是速度。

更快的处理速度。 转录曾经是瓶颈。现在渲染成了瓶颈（而渲染本来就已经很快了）。一个典型的 3 分钟 TikTok 视频端到端处理时间从约 45 秒缩短到约 15 秒。

不再有队列等待。 因为每次转录都如此之快，队列基本上不会积压。高峰时段的性能现在和非高峰时段一样。

更精确的词级时间戳。 这一点让我们有些意外。Groq 的实现返回的词级时间戳比我们之前的方案略微精确。我们说的是毫秒级的改进，但它让字幕动画明显更流畅——词语出现的时机与被说出的时刻完全一致，不会早 50ms 或晚 50ms。

迁移相对顺利。我们的转录工作线程已经在一个接口后面抽象了 Whisper API，所以切换后端主要是配置变更。难点在于处理响应格式的差异，以及确保我们的时间戳规范化能正确处理 Groq 的输出。

我们并行运行了两个后端一周时间，逐一对比输出结果。准确性在误差范围内（有时 Groq 略好，有时旧方案略好，从未有过有意义的差距）。速度一致快了 8-12 倍。

有一个地方我们做了改变：因为转录现在太快了，我们移除了转录步骤的进度轮询。以前会显示"正在转录... 40%... 60%..."——但现在从"正在转录"到"完成"快到进度条只是在闪烁。我们把它简化成了一个涵盖转录和渲染的单一"处理中"状态。

Groq 每分钟音频的费用实际上比运行我们自己的 GPU 实例更便宜。我不会分享具体数字，但成本降低的幅度足够显著，我们正在把节省下来的钱重新投入渲染容量。我们现在运行更多并发渲染工作线程，进一步缩短了等待时间。

这次迁移还带来了一个额外功能：支持 Whisper 所支持的全部 99 种语言的自动语言检测。之前我们有一个语言选择器，默认英语，需要手动切换。现在模型会自动检测语言。

这比你想象的更重要。我们有很多用户创作多语言内容，或者视频中有混合语言的音频。去掉手动语言选择这个步骤，消除了又一个摩擦点。

新的转录后端对所有用户已经上线。如果你今天处理视频，你已经在使用 Groq 了。如果你感受到了速度的差异——欢迎告诉我们，我们自己也感受到了。