Handy作者开源transcribe.cpp：支持60多种转录模型与GPU加速，可替代whisper.cpp和ONNX

本地语音转录开发长期面临引擎分散的问题：开发者通常需要在 whisper.cpp 与 ONNX 之间做选择，而要适配苹果设备，还可能额外引入 MLX。这意味着同一套模型往往要针对不同引擎分别移植和维护。7月19日，语音转文字应用 Handy 的作者及维护者 sebjones 发布了基于 ggml 的语音转录库 transcribe.cpp，并推出 v0.1.0 版本，试图为跨平台本地语音应用提供一套更统一的方案。

transcribe.cpp 支持目前最新的转录模型。handy-computer 这一 Hugging Face 组织发布的每个模型，都经过数值验证和词错率（WER）测试，以确认其结果与官方参考实现保持一致。作者同时说明，当前版本仍处于 0.1.0 阶段，可能存在个人难以发现的问题，因此欢迎社区提交反馈并共同改进。

跨平台分发带来的现实问题

促成 transcribe.cpp 的直接原因，是 sebjones 在为 Handy 集成语音功能、分发跨平台应用时遇到的一系列问题。他表示，现有 ASR 推理栈在跨平台应用中的使用体验并不理想。市面上一些声称支持多种模型的库，往往存在维护状态不明、测试信息不足等情况，开发者很难判断项目是否会持续更新，是否考虑了官方绑定，能否真正用于桌面或移动应用，以及是否只是用于展示的演示代码。

性能同样是需要确认的因素：库是否进行过基准测试，运行速度是否优于 ONNX，都可能影响实际选型。对于需要将语音能力集成到 Handy 的 sebjones 来说，他需要的是一套下载模型文件后即可执行推理、并且能够与参考实现对齐的库。与此同时，推理应尽可能利用 GPU 获得更好的性能，能够方便嵌入 Handy，并兼容 Mac、Windows 和 Linux，而不是引入体量庞大的 PyTorch。

经过比较后，sebjones 选择了 ggml 作为基础。根据他的判断，ggml 拥有活跃的社区和较强的分发能力，适合用于构建跨平台的本地推理方案。

覆盖60多个模型并支持多种 GPU 后端

在功能层面，transcribe.cpp 提供了语音转录推理引擎，并覆盖较多模型。当前支持 16 个 ASR 模型族，模型总数超过 60 个，后续还会继续增加。

• 支持 Vulkan、Metal、CUDA 和 TinyBLAS 四条 GPU 加速路径。
• 支持流式转录和批量转录。
• 支持对模型进行数值验证和完整的 WER 扫描。
• 兼容 Handy 原本使用的部分 whisper.cpp 模型文件。

作者特别强调了 Vulkan 的作用，将其视为本地推理应用应具备的基础能力之一。他还针对每个支持的模型，在 Fedora 系统的 Ryzen 4750U 平台上进行了 CPU 加 Vulkan 的基准测试，并在自己的 M4 Max 上完成了另一组测试。

模型验证过程覆盖数千条语音片段，测试结果与参考实现非常接近，部分情况下可以完全一致。相关验证结果已经公开在 transcribe.cpp 仓库以及 Hugging Face 对应的模型页面中。

可作为 whisper.cpp 的替代方案

由于 Handy 原本基于 whisper.cpp 运行，sebjones 计划通过 Handy 的一次更新，将底层引擎替换为 transcribe.cpp。为了降低迁移成本，transcribe.cpp 保留了对随 Handy 发布的常见 .bin 文件的兼容，开发者可以直接使用这些文件运行推理。

目前，transcribe.cpp 的部分标志和功能还没有与 whisper.cpp 完全对齐，但在绝大多数使用场景下，其 whisper 实现已经具备足够的可靠性，性能也大致处于同一水平。因此，从现有 whisper.cpp 应用迁移到 transcribe.cpp，具备一定的可行性。

从一开始重视语言绑定

transcribe.cpp 使用 C/C++ 编写。为了让本地语音转录更容易被集成和分发，作者从项目初期就将语言绑定作为重点工作。他计划提供四类官方绑定，覆盖 Python、JavaScript 与 TypeScript、Rust，以及 Objective-C 与 Swift。

作者也欢迎社区贡献更多语言绑定，但前提是贡献者愿意承担相应的长期维护责任。相关设计很大程度上来自 Handy 的实际需求，而 Handy 本身的用户基础，也为 transcribe.cpp 的持续维护提供了动力。

推动 ASR 更多运行在本地

在 sebjones 看来，transcribe.cpp 的长期目标，是降低本地 ASR 的使用门槛。对于绝大多数设备而言，本地语音转录已经能够达到很高的准确率，许多场景没有必要将音频上传到云端。

他提到，即使是性能较弱的 RK3566 芯片，使用 transcribe.cpp 也可以仅依靠 CPU，以快于实时的速度运行模型。在采用先进模型并实现快于实时转录的情况下，功耗也只有几瓦。

他判断，未来出于隐私、成本或其他原因，更多推理任务会转移到本地运行，模型和应用的分发问题也会因此变得更加重要。transcribe.cpp 目前还无法从整体上解决这一问题，但作者希望它能够成为改善本地语音转录体验的一步。

项目支持与 AI 辅助开发

在项目致谢中，作者提到了多个提供帮助的组织和个人。Mozilla AI 及其 BiR 项目工程师 Davide，在项目尚处于构想阶段时便决定提供支持；ggml 及其贡献者构成了项目的基础；Modal 提供了用于 WER 测试和 CUDA 验证的算力积分；Blacksmith 负责了部分 CI/CD 工作；Hugging Face 则为 handy-computer 组织提供了模型存放的私有空间，同时也是本地 AI 社区的重要基础设施。

对于开发过程中是否使用了 AI 辅助，sebjones 的回答是肯定的。他表示，一个人依靠 ggml 在几个月内从零开始完成这样规模的推理引擎并不现实。不过，他也明确说明，当前这篇介绍中的文字没有一行由 AI 撰写，全部来自他本人。

原文链接：workshop.cjpais.com/projects/transcribe-cpp