原贴链接

大家好！今天有几个简短的问题：1. 为什么大多数基于流的Whisper实现要分块处理传入音频然后将转录内容拼接在一起？2. 为什么不缓存编码内容然后将其保存在内存中，只需对更多传入音频进行编码？3. 如果Whisper是一个自回归模型，并且它按顺序对音频进行编码……为什么不保持一个运行中的编码音频键值（KV）缓存并更新它？为什么要分批次处理？我们在例如大型语言模型（LLM）后端中经常看到这种连续缓存——例如Llama.cpp和MLX_lm都实现了提示缓存。保存编码的KV缓存，以便下次传入提示时，不需要再次计算对话历史中已编码的部分。然而，我找不到任何这样做的Whisper开源实现——除非我真的误解了代码（这很有可能）。就我从代码库中看到的情况而言；Whisper.cpp似乎是做滑动分块然后将它们拼接在一起。当你将其用于实时转录时，你可以看到其中的缺陷；在分块重叠并拼接在一起的地方会出现明显的错误。我还没有深入研究WhisperKit，但考虑到在从一个分块转换到下一个分块时它也有同样的典型错误，我只能假设它也有一个拼接实现。键值（KV）缓存重用/保持运行中的键值（KV）缓存将消除这些错误。这也将大大降低必须实现自定义逻辑来处理多个分块并以滑动窗口方式将它们拼接在一起的复杂性。你可以只让一个音频流进入，一个解码后的文本流输出。更简洁的代码，不需要多次计算重叠部分，与对静态文件进行推理相比不会降低转录准确性……在我看来好得令人难以置信。这让我认为，也许像我们在大型语言模型（LLM）中看到的连续提示缓存对Whisper来说就是不可能的……？这似乎是最简单的解释。但我不明白为什么会这样。有人知道吗？

讨论总结

该讨论围绕Whisper在实时转录中为何没有提示缓存展开。参与者分享了使用Whisper的成果、探讨技术实现的可能性与困难、比较不同工具的性能，整体氛围较为理性，大家从多个技术角度来分析这一问题。

主要观点

  1. 👍 使用特定设置达到较好延迟效果
    • 支持理由：通过完全本地实现、特定模型和后端以及特定GitHub仓库实现了2 - 3秒的延迟，效果很棒。
    • 反对声音：无。
  2. 🔥 提问者想法技术上可行但需实现
    • 正方观点：赞同提问者的想法在技术上可行，只是可能还没人去做或者未被发现。
    • 反方观点：无。
  3. 💡 Whisper的解码器和编码器与KV缓存的关系
    • Whisper的解码器能使用KV缓存，编码器不能，因为非因果掩码允许新音频修改现有KV值。
    • 同时还提到重新训练成本高、精度会变差等原因导致这种情况。
  4. 💡 Whisper模型存在30秒音频的语境窗口限制
    • 这会影响KV - cache值，在较长音频序列时仍需拼接技术。
    • 这一限制解释了为何采用拼接而非连续缓存更容易。
  5. 💡 模型每次只能处理10秒内容
    • 这可能是其处理音频方式相关疑问的一个原因。
    • 无反对意见。

金句与有趣评论

  1. “😂 I also worked on that lately. Using a fully local implementation and Whisper Turbo model with Faster - whisper backend, I achieved around 2 - 3 seconds of latency.”
    • 亮点：分享了自己的工作成果，展示了一种较好的实现方式。
  2. “🤔 我认为你所提出的在技术上绝对是可行的，只是需要有人去实现它（或者已经有人实现了只是我们搜索得不够）。”
    • 亮点：对提问者的想法表示认可并进行理性分析。
  3. “👀 The Decoder DOES USE KV CACHE. The Encoder CAN’T since non - causal masking allows new audio to modify the existing kv values.”
    • 亮点：解释了Whisper的解码器和编码器与KV缓存关系的关键原因。
  4. “🤔 这些模型有有限的语境窗口，Whisper最大为大约30秒的音频。”
    • 亮点：指出Whisper模型的语境窗口限制这一重要信息。
  5. “👀 模型本身每次只能处理10秒的时间。”
    • 亮点：简洁地给出了模型处理能力相关的重要事实。

情感分析

总体情感倾向为中性，主要分歧点较少。大家主要是在理性探讨技术问题，例如Whisper没有提示缓存可能的技术原因、模型本身的限制等，没有明显的情感偏向某一方的情况。

趋势与预测

  • 新兴话题：探索除Whisper外其他实现实时转录的途径。
  • 潜在影响：如果找到更好的实时转录优化方法，可能会提高相关音频处理领域的效率和准确性。

详细内容：

标题：关于 Whisper 实时转录中提示缓存的热门探讨

在 Reddit 上，一则题为“Whisper (Whisper.cpp/WhisperKit) for live transcription - why no prompt caching?”的帖子引起了广泛关注。该帖提出了一系列有关 Whisper 实时转录中提示缓存的疑问，获得了众多用户的参与和讨论。

原帖主要探讨了以下几个问题：为何多数基于流媒体的 Whisper 实现要将传入的音频分块处理然后拼接转录；为何不缓存编码内容并在内存中保存，以便对新传入的音频进行编码；既然 Whisper 是一个自回归模型，以顺序方式编码音频，为何不保持编码音频的运行键值缓存并更新，而非要分批次处理。

帖子引发的讨论方向主要集中在技术实现的可能性、潜在的限制以及与其他模型的对比。其中，有人分享道：“使用完全本地实现和 Whisper Turbo 模型与 Faster-whisper 后端，实现了约 2 - 3 秒的延迟。感谢这个 GitHub 仓库：GitHub - ufal/whisper_streaming: Whisper realtime streaming for long speech-to-text transcription and translation。它效果很棒！”

也有用户表示：“有趣的是，我今天也在研究如何使用 whisper(.cpp)进行本地实时转录，但和您一样，我只发现了您所描述的拼接方式，或者只是不断累积音频缓冲区并反复转录越来越长的片段……这效率非常低。”

还有用户提到：“我已经做了一些测试，通过 transformers 库实现 Whisper 时，KV - 缓存能正常工作。然而，有一个重要的限制：这些模型有有限的上下文窗口，Whisper 最多约 30 秒的音频。”

讨论中的共识在于大家都认为优化 Whisper 的实时转录处理方式是有必要的。特别有见地的观点如：“Whisper 是传统的变压器，编码器部分有非因果掩码，解码器有因果掩码。解码器使用 KV 缓存。编码器不能，因为非因果掩码允许新音频修改现有的 kv 值。”

争议点在于如何在技术上克服 Whisper 现有的限制来实现更高效的实时转录。有人认为，由于只有 OpenAI 拥有原始音频数据集，重新训练成本极高且新模型的准确性可能稍差，这是实现优化的瓶颈。

总的来说，关于 Whisper 实时转录中的提示缓存问题，Reddit 上的讨论展现了技术探索的复杂性和多样性，也为未来可能的改进方向提供了有价值的思考。