本地語音轉錄這塊，開發者長期被困在一個尷尬的夾縫裏:要麼用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成了他眼中最好的前進方向，既有強大社區，分發能力也出色。

image.png

落到具體能力上，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