转录.cpp

transcribe.cpp 2026 年 4 月 - 现在我非常高兴今天能分享 transcribe.cpp。 transcribe.cpp 是一个基于 ggml 的转录库，支持所有最新的转录模型。在手持计算机 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 测试 支持流转录 支持批量转录 或多或少地减少 耳语.cpp 替换 维护者支持 4 种语言的绑定 Python Javascript/Typescript Rust ObjC/Swift 广泛模型支持 我们打算支持尽可能多的最先进的转录模型。截至今天，我们支持大多数公开可用的现代转录模型。还有一些缺失，但很快就会添加。加速支持 我的首要目标之一是在 Vulkan 上运行我想要的任何 ASR 模型。在我看来，这是任何传送本地推理的应用程序的底线。对于我们支持的每种型号，在 Fedora 以及我的 M4 Max 上都有一个在 Ryzen 4750U（CPU + Vulkan）上运行的相应基准测试。数值验证 我还想确保 transcribe.cpp 中的推理是准确的并且尽可能接近参考实现。这很大程度上来自于使用我在 Hugging Face 上发现的 .onnx 模型时推理准确性的巨大不确定性。为了确保我们所做的推论是正确的，我们对每个模型与参考进行数值验证。除了数值验证之外，我们还运行完整的 WER 扫描，以确保无论参考输出如何，我们都会输出相同的内容。这意味着每个模型都经过了数千次表达，并且与参考非常接近或相同。这些数据的结果发布在 transcribe.cpp 存储库以及 Hugging Face 上的每个模型中。 Drop In Whisper.cpp 替换 transcribe.cpp 或多或少是对 Whisper.cpp 支持的下降。主要原因是：Handy 使用了 Whisper.cpp，我需要使用 transcribe.cpp 发布更新来替换它。我需要与非常流行的 .bin 文件保持一定的兼容性，这些文件在 Whisper.cpp 中运行并随 Handy 一起提供。 transcribe.cpp 可以运行它们。耳语.cpp 中有一些我们尚不支持的标志和功能。但我认为对于绝大多数用例，我们的耳语实现是可靠的，可以取代耳语.cpp，同时具有大致相同的性能。我一开始就想到了真实分发语言绑定。虽然这个库是用 C/C++ 编写的，但我需要 Rust 中的绑定。我还知道，为了让我们尽可能广泛地分发本地转录，它至少需要良好的第一方绑定支持。我选择了 4 种我认为相当能代表人们使用该库的语言。我也欢迎其他人直接为该项目贡献绑定，前提是他们愿意承担这样做的维护负担。当然，还有一个