本地语音转录这块，开发者长期被困在一个尴尬的夹缝里:要么用whisper.cpp，要么用ONNX，想上苹果设备还得再塞一个MLX，等于同时维护两套引擎、为每个引擎各移植一遍模型。7月19日，知名语音转文字应用Handy的作者和维护者sebjones，把他在分发跨平台应用时踩过的坑，直接炼成了一个新库transcribe.cpp，并发布v0.1.0版本。这是一个基于ggml的语音转录库，支持当下所有最新的转录模型，且handy-computer这个Hugging Face组织下发布的每一个模型，都经过了数值验证和词错率（WER）测试，确保与官方参考实现一致。作者也坦承，这是0.1.0版本，难免有他一个人发现不了的粗糙之处，欢迎社区报告一起修。
催生transcribe.cpp的，是一连串憋屈的现实。sebjones直言，用现有的ASR推理栈去分发跨平台应用，体验非常糟糕。市面上虽有一些零散库声称支持大量模型，但作者不明、测试不清，留给他的是一连串疑问:这个库什么时候会停更?作者有没有考虑过官方绑定，让你能在真正的桌面或移动应用里用?它本质上是不是只是演示代码?做过基准测试吗?比ONNX快吗?作为一个需要把语音功能塞进Handy的人，他想要的是一个能下载模型文件就直接跑推理、且推理结果能和参考实现对得上的库;推理要跑在GPU上拿最佳性能，要能轻松嵌进Handy，而不是背上一个庞大的PyTorch;必须同时兼容Mac、Windows和Linux。几经比较，ggml成了他眼中最好的前进方向，既有强大社区，分发能力也出色。
落到具体能力上，transcribe.cpp给开发者交付的是一个又快又准的推理引擎，外加极其广泛的模型覆盖。它支持16个ASR模型族、合计60多个模型，更多模型还在路上。加速方面，它通过Vulkan、Metal、CUDA和TinyBLAS四条路径把推理搬到GPU上，作者尤其把Vulkan当成任何本地推理应用的底线，并为每个支持的模型在Fedora系统的Ryzen4750U（CPU加Vulkan）以及自己的M4Max上做了基准测试。每个模型都经过数值验证与完整的WER扫描，意味着它们被数千条语音片段反复打磨，输出与参考实现非常接近甚至完全一致，这些验证结果同时公开在transcribe.cpp仓库和Hugging Face对应模型页面里。功能层面，它支持流式转录与批量转录，并且基本可以作为whisper.cpp的即插即用替代方案——Handy原本就跑在whisper.cpp上，作者正是要用transcribe.cpp发一个更新把它换掉，为此他特意保持了对whisper.cpp随Handy发布的流行.bin文件的兼容，transcribe.cpp能直接运行这些文件;虽然部分标志和功能尚未对齐，但绝大多数用例下其whisper实现足够可靠，性能也大致相当。
真正让这个库有望走进真实产品的，是它从第一天起就把语言绑定当成了重点。库本身用C/C++写成，作者不仅需要Rust绑定，也清楚要让本地语音转录被广泛分发，至少得有像样的官方绑定撑场面。他挑了四种覆盖度最具代表性的语言:Python、JavaScript与TypeScript、Rust，以及Objective-C与Swift。他也欢迎社区在愿意承担维护的前提下贡献更多绑定。这些决策很大程度上由Handy的诉求驱动，而Handy本身的高人气，也让作者有了持续维护这个库的动力。
在作者看来，transcribe.cpp的终极目标是让本地ASR变得更易用。语音转录在绝大多数设备上都能跑出极高准确率，根本没必要把声音传到云端。他举了一个硬核例子:RK3566这块性能羸弱的芯片，用transcribe.cpp在CPU上就能以快于实时的速度跑模型，而用上最先进模型做快于实时的转录，功耗也只有几瓦。他判断，未来出于各种原因，会有更多推理发生在本地，分发问题因此变得至关重要;transcribe.cpp虽然远没从整体上解决它，但希望是向前的一小步。
在致谢里，作者点名了多位助力者:Mozilla AI及其BiR项目与工程师Davide在该项目还只是个模糊念头时就决定支持他;ggml及其贡献者是整个项目的地基;Modal提供了用于WER测试和CUDA验证的算力积分;Blacksmith扛起了部分CI/CD;Hugging Face则既是本地AI社区的支柱，也为handy-computer组织提供了模型存放的私有空间。至于是否有AI辅助开发，作者回答得很干脆:当然有，一个人靠ggml在几个月内从零写出这种规模的引擎是不可能的，但眼前这些文字没有一行是AI写的，全部出自他自己的口和手。
原文链接:workshop.cjpais.com/projects/transcribe-cpp