嫌whisper.cpp和ONNX不夠用？Handy作者開源transcribe.cpp：60+轉錄模型、GPU加速、即插即用替代

本地語音轉錄領域的開發者長期以來面臨一個尷尬的困境：要在不同平台與裝置上部署應用，往往得同時維護多套推理引擎。無論是選擇小巧輕量的 whisper.cpp 或是著重效能的 ONNX Runtime，若要在蘋果生態系中發揮最佳效果，還得額外整合 MLX 框架，導致開發者必須為同一套模型反覆進行移植與適配。這股長期累積的痛點，終於迎來了一次直接且徹底的回應。 知名語音轉文字應用程式 Handy 的作者與維護者 sebjones，在 7 月 19 日正式開源了他為了解決跨平台分發痛點而從頭打造的新函式庫——transcribe.cpp，並同步釋出 v0.1.0 版本。這個基於 ggml 的語音轉錄庫，直接針對當前市面上所有主流的最新轉錄模型提供支援，而且透過其所屬的 handy-computer 組織在 Hugging Face 上發布的每一個模型，都經過了嚴謹的數值驗證與字錯誤率（WER）測試，確保轉錄結果能夠與官方參考實現高度一致。作者也在發布時坦承，這畢竟只是 0.1.0 版本，難免有他個人未能發現的粗糙之處，因此誠摯邀請社群一同回報問題，協力打磨。 催生 transcribe.cpp 的動力，源於一連串實際開發中令人感到挫折的現實。sebjones 直言，嘗試利用現有的自動語音辨識（ASR）推理軟體堆疊去分發真正的跨平台應用，體驗可說是相當糟糕。市場上雖然存在一些零星散落的函式庫，宣稱能夠支援大量模型，但這些專案往往作者不明、測試紀錄不清，留給開發者的只有一連串無解的疑問：這個函式庫何時會停止維護？作者有沒有考慮過提供官方語言綁定，讓開發者能夠在真正的桌面或行動應用程式中實際使用？它本質上會不會只是展示用的範例程式碼？有沒有做過效能基準測試？運算速度比 ONNX 快嗎？身為一個需要將語音功能整合進 Handy 的開發者，他想要的是一個能夠下載模型檔案後直接執行推理，且推理結果能與參考實現對得上的函式庫；推理必須在 GPU 上執行以獲得最佳效能；必須能夠輕鬆嵌入 Handy 的程式碼庫，而不是因此背負一個龐大的 PyTorch 環境；而且必須同時相容於 macOS、Windows 與 Linux。經過多方比較後，ggml 被他視為當前最理想的前進方向，因為它擁有強大的社群支援與出色的分發能力。 就具體技術能力而言，transcribe.cpp 為開發者提供了一個既快速又準確的推理引擎，並涵蓋了極為廣泛的模型支援範圍。它總共支援 16 個不同的 ASR 模型系列，加總起來超過 60 個具體模型，且官方承諾後續還會持續加入更多。在硬體加速方面，該函式庫透過 Vulkan、Metal、CUDA 以及 TinyBLAS 這四條路徑，將推理工作高效地搬移到 GPU 上處理。作者特別強調，他將 Vulkan 視為任何本地推理應用程式都應具備的底線要求，並且已經針對每一個支援的模型，在搭載 Fedora 系統的 Ryzen 4750U（同時測試 CPU 與 Vulkan 加速）以及他自己的 M4 Max 晶片上，都進行了完整的基準測試。此外，每個模型都經過了數值驗證與完整的 WER 掃描，這代表它們已經被數千條語音片段反覆測試與校正，其輸出結果與官方參考實現非常接近，甚至完全一致。這些驗證結果也都公開陳列在 transcribe.cpp 的官方倉庫與 Hugging Face 對應的模型頁面中。 在功能層面上，transcribe.cpp 同時支援串流式轉錄與批次轉錄，並且其設計目標之一，就是能夠成為 whisper.cpp 的即插即用替代方案。事實上，Handy 這款應用原本就是仰賴 whisper.cpp 來運作，而作者目前正打算利用 transcribe.cpp 發布一次更新，直接將後者替換掉。為了實現這個無痛轉移的目標，他特意讓 transcribe.cpp 保持了對隨著 Handy 一起發布的流行 .bin 檔案的相容性，換句話說，transcribe.cpp 可以直接載入並執行這些舊有的模型檔案。雖然部分指令標誌與功能尚未完全對齊，但在絕大多數使用案例下，其內建的 whisper 實作已經足夠可靠，效能表現也大致相當。 真正讓這個函式庫有機會被廣泛應用於真實產品中的關鍵，在於它從專案啟動的第一天起，就把語言綁定（language bindings）視為核心重點。函式庫本身是以 C/C++ 編寫而成，但作者不僅僅需要 Rust 綁定，他清楚意識到，如果要讓本地語音轉錄技術被廣泛分發，至少必須提供像樣且官方支援的綁定來撐場面。為此，他挑選了四種覆蓋度最具代表性的語言進行優先支援：Python、JavaScript 與 TypeScript、Rust，以及 Objective-C 與 Swift。他也歡迎社群在願意承擔後續維護責任的前提下，貢獻更多的語言綁定。 這一系列產品決策，很大程度上是由 Handy 這款應用本身的實際需求所驅動，而 Handy 本身的高人氣與用戶基礎，也反過來給了作者持續維護這個函式庫的動力。在作者看來，transcribe.cpp 的最終目標，就是讓在地端執行的自動語音辨識變得更加簡單易用。他認為，語音轉錄技術在絕大多數現代裝置上都能跑出極高的準確率，使用者根本沒有必要為了轉錄而把聲音資料上傳到雲端。他舉了一個相當硬派的例子來說明這個觀點：RK3566 這款效能不算強的晶片，使用 transcribe.cpp 在 CPU 上就能以超越即時的速度來執行模型推理；而若使用當前最先進的模型進行轉錄，不僅速度更快，總功耗也只有區區幾瓦。他據此判斷，未來基於各種不同的理由，將會有更多的 AI 推理工作發生在本地端，因此如何在各種裝置上順利分發與執行這些模型，就變成了一個至關重要的問題。transcribe.cpp 雖然遠遠沒有從整體上解決這個問題，但他希望這能算是向前邁出的一小步。 在致謝名單中，作者特別點名了多位關鍵助力者。他表示，Mozilla AI 及其 BiR 專案與工程師 Davide，在 transcribe.cpp 這個專案還只是一個模糊念頭的時候，就決定給予支持；ggml 專案及其所有貢獻者，則是整個專案能夠建立的基石；Modal 提供了用於 WER 測試與 CUDA 驗證所需的算力積分；Blacksmith 扛起了部分持續整合與持續交付（CI/CD）的工作；而 Hugging Face 不僅是本地 AI 社群的支柱，也為 handy-computer 這個組織提供了存放模型的私有空間。至於這個專案是否有使用 AI 輔助開發？作者回答得非常乾脆：當然有，一個人單靠 ggml 要在幾個月內從零寫出這種規模的引擎是不可能的。不過他強調，眼前這篇公告的文字沒有一行是 AI 生成，全部出自他自己的口與手。