ローカル音声認識に関して、開発者は長期間にわたり不快なジレンマに苦しんできた。Whisper.cppを使用するか、ONNXを使用するかのどちらかを選ばざるを得ず、Appleデバイスで動作させるにはMLXを追加しなければならず、これにより2つのエンジンを同時に維持し、各エンジンに対してモデルを移植しなければならない。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の4つの経路によって推論を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という4つの言語を選んだ。また、コミュニティが維持責任を担うことを前提に、他のバインディングの貢献も歓迎している。これらの決定は、主にHandyの要望に駆動されているが、Handy自体の人気により、作者はこのライブラリを継続的に維持する原動力を得ている。

作者の見解によれば、transcribe.cppの最終的な目標はローカルASRをより使いやすくすることである。ほとんどのデバイスでは高い精度で音声認識が可能であり、音声をクラウドに送る必要はまったくない。彼は硬派な例を挙げた。RK3566という性能が弱いチップでも、CPUでモデルをリアルタイムを超える速度で実行でき、最新のモデルを使ってリアルタイムを超える認識を実現し、消費電力は数ワット程度に抑えられる。彼は今後、さまざまな理由からローカルでの推論が増えると判断しており、配布問題が非常に重要になるだろう。transcribe.cppは全体的な解決策とはほど遠いが、前向きな一歩となることを期待している。

謝辞の中で、作者は多くの支援者を名指ししている。Mozilla AIとBiRプロジェクトのエンジニアDavideは、このプロジェクトが漠然としたアイデアだった頃から彼をサポートすることを決めた。ggmlとその貢献者たちはプロジェクトの基礎であり、ModalはWERテストとCUDA検証に計算リソースを提供した。Blacksmithは一部のCI/CDを担当し、Hugging FaceはローカルAIコミュニティの支柱であり、handy-computer組織のモデル格納のためのプライベートスペースを提供した。AIによる開発はあったのかと聞かれた際、彼は即座に答えた。「もちろんだ。1人が数ヶ月かけてggmlだけでこのような規模のエンジンを作ることは不可能だ。だが、今ここにある文章はどれもAIによって書かれたものではなく、すべて彼自身の口と手によって書かれたものである。」

原文リンク:workshop.cjpais.com/projects/transcribe-cpp