一个人干了四个月，把 16 家的语音模型塞进同一个库

一个人，四个月，16 个模型族，60 多个模型，Python、JS、Rust、Swift 四种语言绑定，Mac、Windows、Linux 全平台 GPU 加速。

周日早上刷 Hacker News 刷到这组数字，我的第一反应是不信。

这种项目简介我见得多了，大部分点进去一看，要么是套壳，要么是把别人的推理引擎攒一堆，README 写得比代码还长。但这个不太一样。项目叫 transcribe.cpp，昨天深夜刚发 v0.1.0，HN 上两百多分挂在首页。我从 README 一路看到每个模型的基准测试表格，再看到作者的发布博文，看完只想说一句，好家伙，这活儿干得是真扎实。

先用一句话讲清楚这玩意是什么。transcribe.cpp 是一个基于 ggml 的语音转文字推理库。ggml 你可能没直接听过，但你八成用过它的产物，llama.cpp 和 whisper.cpp 都跑在这套 C/C++ 张量运行时上面，特点是不依赖 PyTorch 那种几个 GB 的庞然大物，一个二进制文件加一个模型文件就能在你笔记本上跑起来。而 transcribe.cpp 干的事，是把市面上主流的语音识别模型，NVIDIA 的 Parakeet 和 Canary、OpenAI 的 Whisper、Mistral 的 Voxtral、IBM 的 Granite、阿里的 Qwen3-ASR 和 SenseVoice、复旦的 MOSS 转录模型，一共 16 个族 60 多个变体，全部塞进同一个引擎，统一成 GGUF 格式，统一的接口，统一在 Vulkan、Metal、CUDA 上加速。

对，你没看错，阿里和复旦的模型都在支持列表里。这个后面细说，那是我觉得对中文用户最惊喜的部分。

先聊聊为什么这事值得写。

你如果折腾过本地语音转文字，大概率被这个生态恶心过。三年前 whisper.cpp 横空出世的时候，大家都以为这事解决了，一个 C++ 实现，笔记本上实时转录，多香。但问题是 whisper.cpp 只跑 Whisper。而这三年语音识别模型跟下饺子一样，NVIDIA 的 Parakeet 系列在英文榜上把 Whisper 按着打，阿里的 SenseVoice 中文识别又快又准，还有一堆流式模型专门做低延迟场景。每一个新模型出来，你想在本地用，对不起，要么上 PyTorch 全家桶，要么找 ONNX 版本，苹果设备上还得考虑 MLX，三套引擎三套模型格式，谁跟谁都不兼容。

作者 CJ Pais 在博文里有段话我很有共鸣。他说网上确实有些号称支持一堆模型的库，但作者不明，测试不明，留给你的问题比答案多。这库明年还有人维护吗，有没有做过基准测试，推理结果跟官方实现对得上吗，还是其实就是个演示代码。

怎么说呢，这几个问题简直是所有开源基础设施的灵魂拷问。我自己选型的时候也是这套流程，先看 star 数，再看最后一次 commit 时间，再看 issue 区是不是坟场，最后祈祷。祈祷这一步通常最重要。

CJ Pais 的回答方式比较硬核。他是 Handy 的作者，一个开源的跨平台语音输入应用，你按个快捷键说话，它在本地转成文字帮你输入，声音不出电脑。就因为要给这个应用分发各种语音模型，他被上面那些问题折磨了个遍，最后一咬牙，在 Mozilla AI 的资助下花几个月用 ggml 从头写了一个统一引擎。

这里面我最欣赏的不是模型数量，是他做验证的方式。每一个模型都做了数值对齐，就是把 transcribe.cpp 的推理输出跟官方参考实现逐层对比，确保算出来的东西一致。在这之上还跑了完整的 WER 测试（词错率，语音识别的核心指标，转错的词占总词数的比例），每个模型过几千条语音样本，保证参考实现输出什么，它就输出什么。所有测试数据公开在仓库和 Hugging Face 上，每个模型都有一张跑分表，CPU 和 GPU 各多快，写得明明白白。

我是真的觉得这个标准应该成为所有推理引擎的及格线。要知道社区里太多移植版模型是转完格式能出字就算成功，至于精度掉了多少，鬼知道。他这种一个模型一个模型对数值的笨功夫，才是把「能跑」和「能用」隔开的那条线。

再说架构上的野心。transcribe.cpp 对自己的定位基本是语音界的 llama.cpp。这个类比值得展开一下。llama.cpp 当年最大的贡献其实不是快，是它用 GGUF 格式加统一运行时，终结了大语言模型本地部署的碎片时代。在那之后，任何新模型只要有 GGUF 版本，下载一个文件就能在任何设备上跑，模型作者不用再操心六个平台的适配。整个本地 LLM 生态，ollama、LM Studio、llamafile，全是搭在这块地基上长出来的。

语音这边一直没有等到这块地基。whisper.cpp 证明了本地转录可行，但它是为一个模型建的一栋房子，不是一片地。transcribe.cpp 想做的就是那片地，还顺便把兼容性做了，它基本可以直接替换 whisper.cpp，连社区里流传的那些 whisper .bin 模型文件都能直接跑。

有点子牛逼的是性能下限。作者说一块 RK3566，就是那种两百块钱开发板上的低端 ARM 芯片，用 transcribe.cpp 跑模型都能超过实时速度，功耗几瓦。你手里随便哪台机器，跑本地转录都是绰绰有余的。

好，通稿部分到此为止，聊点跟你我更相关的。

对中文用户来说，这个项目最实在的一点，是支持列表里那几个中文模型。Qwen3-ASR 有 0.6B 和 1.7B 两个尺寸，SenseVoice 和 FunASR 是阿里系里中文识别的老牌选手，还有复旦的 MOSS 转录模型，中英双语，自带说话人分离（就是转录的同时标出哪句话是谁说的）。这几个名字凑齐，一个纯本地的中文会议纪要工具的原料就全了。录音丢进去，出来的是带说话人标签的文字稿，全程不联网，一分钱 API 费不花。

你可以想想自己现在是怎么处理会议录音的。要么传给某个云服务，隐私协议看都没看就点了同意。要么开着某个会员制的转写工具，一小时录音扣掉一小时额度。而实际上你那台 M 系列芯片的 Mac，或者带独显的工作机，本地转这段录音比云端来回还快。中间缺的从来不是算力，是一个让人信得过的、不用配 conda 环境的推理引擎。

对写代码的朋友，上手成本大概是这样。cmake 两条命令构建，Apple Silicon 自动走 Metal，N 卡开个 CUDA 选项，A 卡和核显走 Vulkan。模型从 Hugging Face 下预转换好的 GGUF，量化版本从 F16 到 Q4_K_M 都有现成的（量化就是把模型权重从高精度压到低精度，体积小好几倍，精度损失可控）。输入要求 16kHz 单声道 WAV，其他格式 ffmpeg 一行转过去。然后一条命令，音频进，文字出。绑定有 Python、JS/TS、Rust、Swift 四种，而且是作者自己维护的一等公民，不是社区飞过来贴一下的那种。想给自己的笔记软件加个语音输入，给播客工具加个自动字幕，路已经铺到门口了。

坦率讲，我日常工作里很大一块就是给模型搭推理和调度的架子，所以看到「维护者亲自支持的语言绑定」这行字的时候格外有感触。一个库好不好用，一半看核心代码，另一半看这些不性感的部分，绑定、打包、格式兼容、错误信息。愿意把这些脏活全揽下来的作者，不多。

当然，泼盆冷水的话也得说在前面。这是个 v0.1.0，作者自己承认毛边不少，等着大家报 issue。whisper.cpp 的一些参数和功能还没对齐，个别新模型还没进来。更现实的风险是，这是个高度依赖单一作者的项目，CJ Pais 哪天忙不过来了怎么办，这个问题现在没人能回答。好的信号是他有 Handy 这个正在维护的应用当需求来源，Mozilla AI 在背后出钱，模型托管和 CI 也都有赞助，这比纯凭热情的周末项目稳得多。但如果你打算把它放进生产环境，我的建议是再等两个版本，先拿它做内部工具和个人项目，反正 MIT 协议，跑通了就是你的。

博文末尾有个小细节我挺喜欢。有人问他这项目是不是 AI 辅助写的，他说当然是，一个人几个月从零写出这种规模的引擎，不借助 AI 不可能。但博文的文字有没有 AI 写的，没有，每个字都出自我的嘴或我的手指。

这个坦然劲儿很对我胃口。用 AI 写引擎，自己写博客，工具归工具，声音归声音。

回到开头那组数字。一个人，四个月，16 个模型族。我现在完全信了，而且我觉得这事还有个更大的背景。过去一年大家都在聊端侧智能，聊来聊去多是芯片厂的 PPT。但转录这件事是真的已经到了，最好的开源语音模型，此刻就能在你的旧笔记本上超实时地跑，识别质量跟云端没有肉眼可见的差距。缺的那层工程地基，现在有人一块砖一块砖地砌出来了。

你的声音，你开会说的话，你半夜对着手机的碎碎念，可以只属于你自己的硬盘。在什么都往云上跑的年头，能有一座自己的小岛，挺好。

项目在 GitHub，模型在 Hugging Face，HN 的讨论串也值得翻翻。周末还长，够你把第一段录音跑出来了。