我非常兴奋今天分享转录.cpp。转录.cpp 是一个基于 ggml 的转录库，支持所有最新的转录模型。每个在 Handy-computer HF 组织下发布的模型都经过数值验证和 WER 测试，以匹配参考实现。它在各个地方加速。我是 Handy 的作者和维护者。这个库源于将跨平台语音转文本应用程序分发给很多人的痛苦。这是一个 v0.1.0 的库，这意味着有一些我无法单独发现的瑕疵！请报告它们，让我们一起修复它们！ 动机 我想说的是，我认为使用当前的 ASR 推理堆栈分发跨平台应用程序是可怕的。你基本上只有 whisper.cpp 和 ONNX。就这些。你可以将 MLX 引入 Apple 设备，但现在你必须支持两个不同的引擎，并将模型移植到各自的引擎。我一直是 ONNX 的粉丝，因为它能迅速将模型支持带入 Handy，但仅仅使用 CPU 的性能却远未被发掘。市场上有一些随机库声称支持很多模型，但据我所知，它们的作者和测试都是未知的。它们给我留下的问题多于答案。它们何时停止维护这一库？创建者是否考虑过绑定，以便你能够在真实的桌面或移动应用中使用它？这实际上是演示代码吗？它是否经过基准测试？比 ONNX 更快吗？这就是导致转录.cpp 诞生的原因。作为 Handy 的维护者，我需要一个我可以信任的库。一个我可以下载文件并在其上运行推理的库。我希望知道，从引擎中得到的模型推理与参考实现同样优秀。为获得最佳性能，推理应在 GPU 上运行。它应该能够轻松嵌入 Handy，不能是一个庞大的 pytorch 库。它必须是在 Mac、Windows 和 Linux 上都能运行的东西。而 ggml 显然是最佳选择。它有一个强大的社区和一个很好的分发故事。 那么你能得到什么呢？ 你将获得一个快速且准确的推理引擎，具有广泛的模型支持。支持 16 个 ASR 家族（60+ 模型），并且将会有更多。通过 Vulkan、Metal、CUDA 和 TinyBLAS 加速。每个模型均经过数值验证和 WER 测试。支持流式转录。支持批量转录。或多或少可以替代 whisper.cpp。维护者支持的 4 种语言的绑定：Python、Javascript/Typescript、Rust、ObjC/Swift。 广泛的模型支持 我们打算支持尽可能多的最先进的转录模型。截至今天，我们支持大多数公开可用的现代转录模型。还有一些缺失，但很快会添加。加速支持 我的一个主要目标是能够在 Vulkan 上运行我想要的任何 ASR 模型。在我看来，这是任何发布本地推理的应用程序的最低要求。对于我们支持的每个模型，在 Fedora 上有一个相应的基准测试是来自 Ryzen 4750U（CPU + Vulkan），同时也在我的 M4 Max 上进行。 数值验证 我还想确保转录.cpp 的推理是准确的，并且尽可能接近参考实现。这在很大程度上源于使用从 Hugging Face 找到的 .onnx 模型时推理准确性的不确定性。为了确保我们所做的推理是正确的，我们对每个模型与参考进行数值验证。在数值验证的基础上，我们运行完整的 WER 测试，以确保无论参考输出什么，我们也输出相同的内容。这意味着每个模型都经过了数千次发音，结果与参考非常接近或相同。这些数据的结果已经在转录.cpp 仓库中发布，并且在 Hugging Face 上的每个模型中也有提供。 替换 whisper.cpp 转录.cpp 在很大程度上是 whisper.cpp 的替代品。这样做的主要原因是：Handy 使用了 whisper.cpp，我需要提供一个更新，将转录.cpp 替换掉它。我需要与在 whisper.cpp 中运行并随 Handy 一起提供的非常流行的 .bin 文件保持某种兼容性。转录.cpp 可以运行这些文件。whisper.cpp 中有一些标志和特性我们尚不支持，但我认为在绝大多数用例中，我们的 whisper 实现是可靠的，并且可以在性能方面与 whisper.cpp 相当。 真正的分发 语言绑定在我心中是开始的想法。虽然这个库是用 C/C++ 编写的，但我需要 Rust 的绑定。我也知道，为了让我们可以尽可能广泛地分发本地转录，至少需要良好的第一方绑定支持。我选择了 4 种语言，我认为它们代表了人们使用该库的地方。我欢迎其他人直接为项目贡献绑定，只要他们愿意承担维护的负担。当然，在一天结束时，许多事情...