transcribe.cpp 发布：基于 ggml 的跨平台语音转录库，支持 16 个 ASR 模型族

今天我非常激动地分享 transcribe.cpp。

transcribe.cpp 是一个基于 ggml 的转录库，支持所有最新的转录模型。handy-computer HF 组织下发布的每一个模型都经过了数值验证和 WER 测试，以匹配参考实现。它在所有平台上都实现了加速。

我是 Handy 的作者和维护者。这个库源于向众多用户分发跨平台语音转文字应用时遇到的种种痛点。

这是一个 v0.1.0 版本的库，意味着还有一些我独自一人无法发现的粗糙之处！请 报告它们，让我们一起修复！

动机

让我直说吧。我认为用当前的 ASR 推理技术栈来分发跨平台应用是一件非常糟糕的事情。

你基本上只有 whisper.cpp 和 ONNX。就这些。你可以为 Apple 设备引入 MLX，但这样一来你就得支持两个不同的引擎，并为每个引擎移植模型。我一直很喜欢 ONNX，因为它能快速为 Handy 带来模型支持，但仅靠 CPU 会浪费太多性能。

市面上有一些零散的库声称支持大量模型，但据我所见，它们的作者不明，测试也不透明。它们留给我的疑问比答案还多。

他们什么时候会停止维护这个库？创建者有没有考虑过做绑定，让你能真正在桌面或移动应用里使用它？这本质上是不是演示代码？他们做过基准测试吗？它比 ONNX 更快吗？

而这正是 transcribe.cpp 诞生的原因。作为 Handy 的维护者，我需要一个可以信赖的库。一个我可以下载文件并对其运行推理的库。一个我能确信引擎中来自模型的推理与参考实现一样好的库。推理应该在 GPU 上运行以获得最佳性能。它应该能轻而易举地嵌入 Handy，不能是一个庞大的 pytorch 库。它必须是能在 Mac、Windows 和 Linux 上运行的东西。而 ggml 似乎是迄今为止最好的前进方向。它拥有强大的社区，以及出色的分发方案。

那么你能得到什么？

你得到一个快速且准确的推理引擎，并拥有广泛的模型支持。

• 支持 16 个 ASR 系列（60+ 个模型），且还有更多即将到来
• 通过 Vulkan、Metal、CUDA 和 TinyBLAS 实现加速
• 每个模型都经过了数值验证和 WER 测试
• 支持流式转录
• 支持批量转录
• 或多或少可以即插即用地替代 whisper.cpp
• Maintainer supported bindings in 4 Languages
  • Python
  • Javascript/Typescript
  • Rust
  • ObjC/Swift

广泛的模型支持

我们打算支持尽可能多的最先进转录模型。截至目前，我们已支持大多数公开可用的现代转录模型。仍有少数尚未支持，但很快就会加入。

加速支持

我的首要目标之一，是能在 Vulkan 上运行任何我想要的 ASR 模型。在我看来，这是任何提供本地推理的应用的底线。对于我们支持的每一个模型，都有对应的基准测试运行结果，来自 Fedora 上的 Ryzen 4750U（CPU + Vulkan），以及我的 M4 Max。

数值验证

我还想确保 transcribe.cpp 中的推理是准确的，并且尽可能贴近参考实现。这很大程度上源于我在 Hugging Face 上找到的 .onnx 模型在推理准确性方面存在极大的不确定性。为了确保我们所做的推理是正确的，我们对每个模型都对照参考实现进行数值验证。除了数值验证之外，我们还运行完整的 WER 扫描，以确保无论参考实现输出什么，我们输出的都是相同的结果。这意味着每个模型都经过了数千条语音的测试，结果与参考实现非常接近或完全一致。这些数据的结果发布在 transcribe.cpp 仓库中，同时也在 Hugging Face 上随每个模型一同发布。

可直接替换 whisper.cpp

transcribe.cpp 或多或少可以直接替换 whisper.cpp。主要原因在于：Handy 之前使用的是 whisper.cpp，而我需要发布一个用 transcribe.cpp 替换它的更新。我需要保持与那些非常流行的 .bin 文件的某种兼容性，这些文件在 whisper.cpp 中运行，并随 Handy 一同发布。transcribe.cpp 可以运行它们。whisper.cpp 中有一些标志和功能我们尚不支持。但我认为对于绝大多数用例来说，我们的 whisper 实现是可靠的，可以替换 whisper.cpp，同时性能大致相当。

真实分布

一开始我就考虑到了语言绑定。虽然这个库是用 C/C++ 编写的，但我需要 Rust 的绑定。我也知道，为了让本地转录尽可能广泛地分发，至少需要对绑定有一方提供的像样支持。我选择了 4 种语言，我认为它们相当能代表人们会使用这个库的场景。我也欢迎其他人直接向项目贡献绑定，前提是他们愿意承担相应的维护负担。

当然，归根结底，很多决定都是由 Handy 驱动的。由于 Handy 很受欢迎，我打算维护这个库，就像我一直尽力维护 Handy 一样。我打算成为一个持续维护开源项目、并在力所能及之处为生态做出贡献的人。

如果没有 Handy，这个库根本不会存在，因为我不会遇到试图支持一堆不同 ASR 模型的问题。我也永远不会了解到人们对 ASR 的各种使用场景。我已尽力覆盖我听到最多的那些场景。当然，库中目前仍有一些情况未被处理。如果有我遗漏的东西，欢迎你为这个库做贡献！

让本地语音转文字更易用

transcribe.cpp 的目标非常明确，就是让本地运行的 ASR 变得更简单。我们知道，转录在大多数设备上都能极其准确地运行，完全没有必要把你的语音发送到云服务。一台 RK3566 凭借其孱弱的 CPU，就能通过 transcribe.cpp 以快于实时的速度运行模型。用 SOTA 模型进行快于实时的转录，只需几瓦的功耗。这不是希望或梦想，这是事实。

我认为，展望未来，出于这样或那样的原因，越来越多的推理将开始在本地发生。这就把分发这件事推到了台前。要让更多应用在本地运行推理，我们就需要让运行推理变得更简单。当然，transcribe.cpp 并不能整体解决这个问题，还有很长的路要走，但我希望它是向前迈出的一小步。我确实学到了很多。

致谢

我非常感谢所有支持这个项目的人。

首先也是最要感谢的是 Mozilla AI、他们的 BiR 计划，以及来自 Mozilla AI 的 Davide。这个项目很大程度上是我脑海中的一个问题，我带着它去找他们，他们决定支持我解决这个问题。当时 transcribe.cpp 甚至还不是一个具体的想法，我只是在探索如何在 Handy 中解决加速分发的问题。所以，非常感谢他们、他们的支持，以及帮助这个项目成为现实。

ggml。没有 ggml 以及所有为其做出贡献的人，这个项目就不可能实现。非常感谢大家所做的工作。我认为 ggml 在帮助分发本地推理应用变得简单可行方面，确实做出了令人惊叹的贡献。

Modal 也给了我至关重要的帮助。我联系了他们，他们给了我额度。这些额度被用于进行 WER 测试，并确保该库在 CUDA 上运行良好。能够验证工作的正确性，这是巨大的帮助。

Blacksmith 帮助为 transcribe.cpp 提供部分 CI/CD 支持。我同样联系了他们，他们立即回复并提供了额度。当然，CI/CD 对于确保发布的所有内容至少经过一定程度的测试至关重要。

Hugging Face，既因为它是本地 AI 社区的中流砥柱，也因为它为 handy-computer 组织提供了私有存储，让我可以按自己的意愿上传模型。

有 AI 辅助吗？

是的，绝对有。我认为单凭一个人，不可能在几个月内使用 ggml 从零开始写出如此规模的引擎，而没有外部帮助。那么这里的文字有哪部分是 AI 写的吗？没有。它们都出自我的口或我的手。