本地语音识别的工具箱,长年就两条路:whisper.cpp,或者 ONNX。想把语音转文字塞进跨平台桌面应用,基本绕不开这两个选择。再往外找,是一堆维护周期不明、有没有跑过 GPU 全靠猜的野生仓库。
Handy 的作者干脆自己写了一个:transcribe.cpp v0.1.0。这是一个基于 ggml 的语音识别推理库,号称支持 16 个 ASR 家族、60 多个模型,每个模型都过了数值校验和词错误率(WER)测试。它真正要补的,是分发和信任——这块本地语音识别一直没人认真做。
覆盖了什么,谁能直接用
加速走 Vulkan、Metal、CUDA、TinyBLAS 四条路,转写支持流式和批量两种模式。语言绑定覆盖 Python、JavaScript/TypeScript、Rust、ObjC/Swift,全部由作者本人维护。
对开发者最实际的一条:它大体是 whisper.cpp 的平替,常见的 .bin 模型文件可以直接跑,性能大致相当。但不是全面替代——whisper.cpp 里一部分参数和功能它还没补齐。
| 维度 | whisper.cpp / ONNX 旧栈 | transcribe.cpp v0.1.0 |
|---|---|---|
| 模型覆盖 | 各自绑定单一模型家族 | 统一接口接 16 家族、60+ 模型 |
| 加速后端 | 需自行拼接引擎 | Vulkan/Metal/CUDA/TinyBLAS 内置 |
| 校验方式 | 开发者自行抽样验证 | 作者自称逐模型数值比对 + WER 公开 |
| 语言绑定 | 各社区各自维护 | 四门绑定,单一作者维护 |
| 成熟度 | 多年迭代,生态成熟 | v0.1.0,单人维护 |
这对两类人意味着不同的事。正在做跨平台本地转写应用的工程师,可以先在非生产分支里试跑:用现成的 .bin 模型直接替换 whisper.cpp,自己跑一遍延迟和 WER 对比,但暂时别把生产链路整体切过去——whisper.cpp 里没补齐的那部分参数,可能正好是你在用的。
关注端侧 AI、隐私计算和推理基础设施的技术读者,更该看的是它给"语音不上云"多提供了一条统一分发通道,不用再为每个模型家族单独接一遍 ONNX Runtime。但基准数据来自项目自身,现阶段不建议直接写进选型报告。
校验怎么做的,可信到什么程度
这个库真正的分水岭,在于验证方式。作者称每个发布在 handy-computer 这个 Hugging Face 组织下的模型,都跑过与参考实现的数值比对,并做了大规模 WER 测试,结果公开在仓库和 Hugging Face 上。
这比单纯堆模型数量值钱。过去开发者拿到一个 Hugging Face 上的 .onnx 模型,常常不知道推理对不对、准不准,只能自己抽样验证,心里没底。
但这些校验、基准测试、"支持多数现代模型"的说法,目前全部来自作者一人的仓库和自述,还没有第三方复现过。作者提到 RK3566 这类低功耗设备能跑出快于实时的转写速度——这是一台具体机型上的具体结果,不能当成"随便什么设备都能跑赢实时"的通用结论。
瓶颈从模型能力,挪到了工程整合
本地 AI 的卡点,正从"模型能不能用"转向"工程能不能扛"。SOTA 语音识别模型几瓦功耗就能跑出实时转写,这一点早没什么争议。难的是把几十个模型、四种 GPU 后端、四门语言绑定,做成一个能被长期信任的分发层。
这才是 transcribe.cpp 现在唯一拿得出手的东西。护城河不在模型数量,在做过验证、给了绑定、有人愿意一直修。
问题是这个"一直会修",目前压在一个人身上。项目背后有 Mozilla AI 的 BiR 计划、Modal 和 Blacksmith 给的算力和 CI 额度,阵容不算小,但代码、验证、绑定、issue,都是作者一人在扛。v0.1.0 这个版本号已经写明态度:能用,但还没磨光。
开源世界里,单人维护的关键基础设施不止一次出过教训,一个几行代码的小包停摆,能拖垮半个前端生态。transcribe.cpp 要成为别人应用里的地基,考验的不是发布那天的功能清单,是三年后作者还在不在。
接下来值得盯的,不是它又加了几个模型,而是有没有第三方跑出独立的 WER 复现数据,有没有除作者之外的人开始提交 PR、修 issue。这两件事任何一件成立,transcribe.cpp 才算真正迈过"个人项目"这道坎。