← #802

Transcribe.cpp：让本地语音转文字变得简单

文章摘要

transcribe.cpp 是一个基于 GGML 的语音转文字（speech-to-text）推理库，专门为跨平台分发而设计。作者 CJ Pais（sipjca）是流行的语音输入应用 Handy 的维护者，正是在给 Handy 做跨平台分发的过程中，他深刻体会到把 ASR 模型部署到 Mac、Windows 和 Linux 上有多痛苦，于是做了这个库。

核心能力上，它目前支持 16 个 ASR 模型家族、60 多个模型，并计划继续扩展。定位是 whisper.cpp 的大体兼容替代品，但支持的模型范围要宽得多。硬件加速方面，得益于 GGML 底座，它同时支持 Vulkan、Metal、CUDA 和 TinyBLAS 多条路径——作者特别强调，Vulkan 支持是本地推理部署的最低标准（言下之意是很多项目连这个都做不到，导致在非 NVIDIA、非 Apple 硬件上无法加速）。功能上同时支持流式（streaming）和批量转录。

质量保证是这个项目最扎实的部分：每一个模型都要经过与参考实现的数值验证，并在数千条语句上做完整的 WER（词错误率）测试，以确保精度与原实现一致。这在”随手包一层就发布”的开源 AI 项目里相当罕见。语言绑定方面提供 4 种由维护者亲自支持的绑定：Python、JavaScript/TypeScript、Rust 和 ObjC/Swift，覆盖桌面和移动端应用集成。性能基准在消费级硬件上测量，包括 Ryzen 4750U 和 M4 Max。

作者在文中阐述的动机被 HN 上广泛引用：他认为展望未来，出于各种原因会有越来越多的推理发生在本地，这就把”分发”问题推到了最前台——要让更多应用在本地跑推理，就必须让跑推理这件事变简单，目标是消除语音处理任务上不必要的云依赖。文章末尾还有一句被反复提及的声明：”这里的文字有用 AI 写的吗？没有。它们来自我的嘴或我的手指。”项目的资金来源方面，作者透露 Mozilla AI 赞助让他有时间认真对待这个项目并发出 v0.1.0，此外还有 Handy 社区的捐赠和一些赞助者。发帖时说话人分离（diarization）功能正在开发中。

HN 评论精华

aarvin_roshin：引用了文章中关于”更多推理将在本地发生，因此分发问题浮到最前台”的段落，认为正中要害；同时引用作者关于”文字没有用 AI 写”的声明，”这让这类项目更值得信任、也更容易接近”。
boplicity：对”没用 AI”这一点提出有分量的反驳——他相当强烈地认为我们会被使用的工具塑形。语音转文字模型本身也是 LLM，它们的错误由训练中固有的期望所塑造，这反过来塑造了出现在屏幕上的词。”对于经常用它们的人，你会学到哪些词序更容易被准确转录，而这确实会成为你思考过程的一部分。久而久之，LLM 就缠进了你的思维。”
eventualcomp：反问 boplicity——”这不就等于说’我跟家人说话时用的词其实不是我自己的，因为我知道我父亲不是英语母语者又听力不好，所以我尽量用发音清晰、音节少的词’吗？”
iezepov：把这个思路再推一步，引用丘特切夫的名句”思想一旦说出便是谎言”——言语是思想的投影，而且是有损的投影，所以无论听者是谁，说和写都会影响思考。”不过关于 LLM 转录那条评论说得很准。”
ChadNauseam：技术性纠正——Parakeet，也就是 Handy 这类转录场景里可能最流行的模型，并不包含语音 LLM 或任何其他形式的 LLM。
yjftsjthsd-h：所以它主要是 whisper 的更好替代品？大体兼容，但支持更多模型、可能还有更多加速后端？sipjca（作者）确认：”差不多是这样，是 whisper.cpp 的替代，只是想让本地转录对任何在做应用的人都更容易上手。”
bengotow：全场最高热度的赞叹——”这是对社区的了不起的贡献，而这居然就……一个人做的？我一直往下读，等着看到底部的 A 轮融资公告。”他补充了一句被广泛认同的观察：”这是个很好的提醒：你可以用 AI 以最高速度喷射垃圾，也可以用它来放大你的抱负，做出比以往更严谨、更持久的东西。”不过他也说，虽然想把 transcribe.cpp 集成进自己维护的应用，但他觉得这个功能（一般来说）应该被集成进操作系统，或者通过 Handy 这样的应用做到”处处可用”。
sipjca（作者，回应）：确认是本人。赞助者和 Handy 的捐赠社区帮了大忙，”Mozilla AI 在让这项工作起步上非常有帮助。为 Handy 做这个曾是我的白日梦，他们赞助了我，让我能腾出时间认真对待这个项目并把 v0.1.0 发出门”。他也同意应该”无处不在”：”我希望有一天能把 libtranscribe 正式分发出去，让它更像一个系统库！这需要时间来稳定，但我认为我们能做到。”
sbinnee：我看到 Metal 几乎比 Vulkan 快 10 倍？为什么差距这么大？sipjca：这非常取决于硬件！那是拿 M4 Max 和带集成显卡的 Ryzen 4750U 比，”M4 Max 大概有 10 倍的算力和内存带宽哈哈”。
ukuina / SamPentz：都在问怎么加说话人分离。sipjca：正在做，”大概这周就来 :)”。simonw 找出了进行中的 PR（handy-computer/transcribe.cpp#85），发现用的是 IBM 的 Granite-Speech-4.1-2B-Plus 和/或 MOSS-Transcribe-Diarize。sipjca 补充他同时也在移植 NVIDIA 的 Sortformer 做多说话人分离，”parakeet multitalker 是推动这个改动的主要动力”。semiquaver 打趣道：”那应该叫 Diarize.cpp，不是 Transcribe.cpp。”
oezi：问了几个正交但关键的问题——对 whisper.cpp 的 drop-in 兼容目标定在多接近？逐词和逐字符时间戳在计划内吗？多语言转录和幻觉抑制呢？sipjca 坦诚回答：最终希望更完整地 drop-in 兼容，但目前部分功能支持还比较稀疏，”whisper 这些年被做了太多工作，很难支持每一种可能的东西。现在它比什么都更像一个平淡的标准实现”，当前首要目标是稳定核心头文件，模型特定的功能欢迎社区贡献。
shade：实战意向——他自己用 Nemotron 做了一个跨平台（Mac/Win/Linux）实时字幕应用，效果不错但”跟 ONNX 打交道挺烦人的”。既然这个有 Rust 支持（他的应用基于 Rust/Tauri），应该是个相当靠谱的候选，只需找一个不依赖 ONNX 的 Silero VAD 实现。他后来把自己的应用（larmindon）开源链接贴了出来，坦白首次运行体验不佳，需要手动下载模型文件再去设置里配置模型目录。
sneak：一条让不少人震惊的信息——iOS 上的系统原生听写要求每次请求都把你的通讯录上传给 Apple，即使你不用 iCloud，”因此我不得不把它关掉”。有人质疑说自己测试是本地离线工作的，sneak 回应称启用时的说明文字明确写着会在必要时把语音输入、通讯录和位置发给 Apple。espetro：”天啊，我第一次读到这件事。谢谢分享！我现在就停用内置听写。”jjice 补充说 iOS 27（需要更新的设备型号）会带来更好的、全部在设备上完成的转录。
ghm2199：在 Mac 和手机上都爱用 Handy，尤其是在原生模型表现不佳的场景（比如 Apple 的方案在特定领域词汇上会转错）。他问了一个务实的问题：如何看待从基金会获得维护资金？sipjca 说自己”算是意外成了开源维护者”，很幸运有不少人捐赠 Handy、也有个人和组织赞助，”老实说我就是热爱为开源做贡献并希望继续下去。相信 OSS 并推动它前进的组织通常和我最契合”。
qntmfred：给想试流式转录的人的提示——需要把模型换成支持流式的，最新的 parakeet 就支持，”我用了大概一周，是好东西 :)”。sipjca 列出 Handy 已支持的流式模型：Nemotron Streaming、Parakeet Unified、Voxtral Mini Realtime。
therealpygon：试了 nemotron 但”零标点是个硬伤”，用 unified 又没看到流式（原因是他为了避开快捷键冲突关掉了直接输入）。”不过无论如何，你得从我冰冷的手里才能撬走 Handy。太有用了。”
aomix：时机正好——他看到越来越多人谈把语音带进提示词工具链，”随口把脑子里的东西倒进文档 → 编辑一遍 → 发给机器人这个循环听起来很吸引人”。