1 ポイント 投稿者 GN⁺ 1 일 전 | 1件のコメント | WhatsAppで共有
  • transcribe.cpp は、複数の最新音声認識モデルを Mac・Windows・Linux アプリに簡単に組み込み、GPU で高速化するために作られた ggml ベースのライブラリ
  • 16のASRファミリー・60以上のモデル を Vulkan・Metal・CUDA・TinyBLAS で実行し、ストリーミング転写とバッチ転写の両方をサポート
  • すべてのモデルを参照実装と数値比較し、数千件の発話で WER テスト を実施し、検証結果をリポジトリと Hugging Face で公開
  • 既存の whisper.cpp 向け .bin ファイルを実行でき、ほとんどの用途で同等の性能で置き換え可能で、Python・JavaScript/TypeScript・Rust・ObjC/Swift の公式バインディングも提供
  • 低消費電力の RK3566 でもリアルタイム以上の速度で転写できるため、音声をクラウドに送らずにさまざまなデバイスへ ローカルASR を展開可能

クロスプラットフォームASR展開の制約

  • 既存のクロスプラットフォーム ASR 推論の選択肢は、実質的に whisper.cpp と ONNX に限られていた
    • Apple デバイスには MLX を追加できるが、その場合は 2 つのエンジンをサポートし、各エンジンごとにモデルを移植する必要がある
    • ONNX は Handy にモデルを素早く追加するのに有用だったが、CPU 専用実行では性能を十分に引き出しにくかった
  • 複数モデルをサポートする一部ライブラリは、作者やテスト水準、保守計画が不明確だった
    • 実際のデスクトップ・モバイルアプリで使えるバインディングがあるのか、デモコード止まりなのか、ベンチマークがあるのか、ONNX より速いのかを確認しにくかった
  • Handy のクロスプラットフォーム音声入力展開の経験をもとに、次の条件を満たすエンジンが必要だった
    • ファイルをダウンロードしてすぐに推論できること
    • 推論品質が 参照実装と同等か検証 できること
    • 最高性能のため GPU で実行できること
    • 大規模な PyTorch ライブラリなしで Handy に簡単に組み込めること
    • Mac・Windows・Linux で動作すること
  • ggml は強力なコミュニティと便利な展開方式を備えており、この要件を実現する基盤として選ばれた

対応モデルと高速化方式

  • transcribe.cpp は、高速で高精度な推論と幅広いモデル対応を目標としている
    • 16のASRファミリーと60以上のモデル に対応し、今後さらに追加予定
    • 公開されている最新の転写モデルの大半に対応しているが、まだ未対応のモデルもある
    • ストリーミング転写とバッチ転写の両方を提供
  • すべての対応モデルは次の高速化バックエンドで実行可能
    • Vulkan
    • Metal
    • CUDA
    • TinyBLAS
  • モデル別ベンチマークは Fedora 環境の Ryzen 4750U CPU・Vulkan と M4 Max で実施
  • Vulkan 対応をローカル推論アプリケーション展開の最低条件としている

参照実装と精度検証

  • Hugging Face で入手した .onnx モデルの推論精度を確信しにくかった経験を踏まえ、すべてのモデルを 参照実装と数値検証 した
  • 数値比較に加えて、全体の WER チェックを実行し、参照実装と同じ出力になるかを確認
    • モデルごとに数千件の発話を処理
    • 結果は参照実装と非常に近い、または同一
  • 検証データは transcribe.cpp リポジトリと handy-computer Hugging Face 組織 の各モデルページで公開されている

whisper.cpp 互換性

  • Handy で使っていた whisper.cpp を置き換えられるよう、ドロップイン代替に近い互換性 を実装
  • Handy とともに配布されていた whisper.cpp 向け .bin モデルファイルを transcribe.cpp でも実行できる
  • whisper.cpp の一部フラグと機能はまだサポートしていない
  • ほとんどの用途で whisper 実装は十分安定しており、おおむね同等の性能で whisper.cpp を置き換えられる

言語バインディングと保守

  • C/C++ で書かれており、ローカル転写をさまざまな環境へ展開できるよう 公式保守バインディング を提供
    • Python
    • JavaScript/TypeScript
    • Rust
    • ObjC/Swift
  • 他言語バインディングの貢献も歓迎するが、貢献者がそのバインディングの保守を担う必要がある
  • Handy の実際の要件がライブラリ設計に反映されており、Handy の保守経験をもとに transcribe.cpp も継続的に管理していく予定
  • さまざまな ASR モデルと実運用のユースケースを支えて得た経験を反映しているが、まだ対応できていない事例もあり、外部からの貢献を募っている
  • 現在のバージョンは v0.1.0 で、粗い部分が残っているため Issue 報告 を求めている

低消費電力デバイスまで広がるローカルASR

  • デバイス上で直接 ASR を実行しやすくし、音声を クラウドサービスへ送る必要を減らすこと が目標
  • 性能の低い RK3566 CPU でもモデルをリアルタイム以上の速度で実行できる
  • 最新モデルによるリアルタイム超の転写速度が数 W レベルの電力で動作する
  • より多くの推論をローカルで処理するには、アプリケーションに推論エンジンを展開して実行する過程が容易でなければならない
  • transcribe.cpp ひとつでローカル推論展開の問題全体を解決できるわけではないが、ローカル ASR の参入障壁を下げる一歩として開発された

プロジェクトを支えたサポート

  • Mozilla AIBiR プログラム、Mozilla AI の Davide が、具体的な製品形態がなかった初期探索段階からプロジェクトを支援
  • ggml はローカル推論アプリケーション展開を可能にする中核基盤
  • ModalWER テストと CUDA 検証 に使われるクレジットを提供
  • Blacksmith はリリース成果物を検査する CI/CD の一部を支援
  • Hugging Face は handy-computer 組織に非公開ストレージを提供し、モデルを自由にアップロードできるようにした

開発過程でのAI活用

  • ggml ベースでこの規模のエンジンを個人が数か月でゼロから書くのは難しいと判断し、開発に AI 支援 を活用
  • プロジェクト紹介文は AI で書いておらず、自分で話したり入力した文で構成されている

1件のコメント

 
GN⁺ 1 일 전
Hacker Newsのコメント
  • とても良さそう。ただ、未知の言語の意味ではなく、音を**国際音声記号(IPA)**で転写する機能はモデルのドキュメントでは見つけられなかった
    話者が1万人にも満たない少数言語では、言語別モデルを訓練するためのリソースが永久に不足するかもしれない。言語を識別せず、音声そのものをIPAに移すモデルがあれば、世界中の少数言語を研究する言語学者にとって大きな助けになるはず

    • 実際の発話には省略や縮約が多く、言語を知っていても単語より音素転写の方がはるかに難しい。https://huggingface.co/spaces/KoelLabs/IPA-Transcription-EN のようなモデルもあるが、エラー率は非常に高い
    • 妻の家族は、中国のダオ族・ヤオ族の下位集団である Iu Mien の出身。Mienは独立した言語だが、話者の大半は事実上読み書きができず、教材や講座もほとんどないため学ぶのが難しい
      文字資料も少ないので、『プロジェクト・ヘイル・メアリー』のように翻訳システムを自分で作りたい
    • この機能をサポートするモデルはほとんど知らないため、現時点ではライブラリの範囲外だが、適したモデルがあれば喜んで対応するつもり
    • **自動音素認識(APR)**モデルはいくつかあるが、性能はそこそこという程度
    • こうしたモデルは、実用的にするには自分が聞くと想定する音声の範囲を知っている必要がありそう。IPAが表す音は非常に多いが、個々の言語が使うのはその一部だけ
      英語の暗いlと明るいl(ball/light)、有気音のp(pin/spin)は、他の言語では意味を区別し得るが英語ではそうではない。言語学者ができるだけ忠実なIPA転写を受け取ったうえで、手作業で正規化したいのか気になる
  • リリースおめでとう。Macとスマホで Handy を便利に使っており、Apple標準の音声認識が特定分野の用語を誤認識する場面で特に役立っている
    メンテナンス費用を財団から支援してもらう案はどうだろう。こうしたプロジェクトの対価を受け取るなら、どんな組織を探し、どのように支援を依頼するのかも知りたい

    • Handyが人気になったことで、意図せずオープンソースメンテナーになり、幸い個人の寄付と複数のスポンサーが作業を支援してくれている
      オープンソースに貢献する仕事を続けたいので、それを支持するところなら歓迎で、特にオープンソースを信じて発展させる組織とは相性が良い。詳しい相談は contact@handy.computer で可能
    • iOSのOS標準の音声入力は、iCloudを使っていなくてもリクエストのたびに連絡先をAppleへアップロードする必要があるため、オフにせざるを得ない
  • いくつもの音声テキスト変換システムは発話そのものは正確に認識するが、望むワークフローをサポートしていない。文書を開いて話すと、カーソル位置に最小遅延で継続的に入力されるべき
    録音を止めてからまとめて貼り付ける方式は役に立たず、連続入力が肝心

    • むしろ録音が終わってからまとめて転写する方式の方が自分には合っていた。リアルタイム入力を見ると、転写ミスを確認することに気を取られて考えを最後までつなげにくい
      1つのテーマについて頭の中の内容を5〜10分間すべて話してから見直す方が、思考の流れを断ち切らないのでより有用
    • 望むなら Handy を比較的簡単に修正して実装できる。アプリの正式機能としても追加する予定だが、先に解決すべきことが多い
    • 英単語は周囲の文脈がないと確定できない場合が多い。たとえば thereとtheir は発音だけでは区別できない
    • 転写機能の有用性は使い方によって変わる。音声入力中に別のウィンドウを開いたり、グラフやデータを見たりすると、発話を裏付ける情報を提供しやすい
      一部のアプリは、コピーした内容や見ている内容まで転写コンテキストとして活用して結果を改善する: https://superwhisper.com/docs/common-issues/context#types-of...
    • https://github.com/electronstudio/low_latency_dictation でこの方式を試したが、リアルタイムモデルの精度が低かった。そのため、テキストを確定する前に、より正確なモデルで2回目の処理を行っている
  • Whisper.cppのようにコンテキストを入力して精度を大きく高められるのか気になる

    • 可能
  • メンテナーがサポートする4つの言語バインディングのうち、Python向けは https://github.com/handy-computer/transcribe.cpp/tree/main/b... にある
    まだ依存関係を含むPyPIバイナリwheelはなく、現在のPyPIライブラリは別途インストールしたライブラリをctypesで呼び出すが、今後リリースする計画のようだ

    • CUDAパッケージ用の追加ストレージを求めるPRをPyPIに出したが、まだ承認されていないようだ。バインディングの**開発者体験(DX)**を改善するのを手伝ってほしい
  • ちょうど良いタイミングで見つけた。プロンプトツールに**音声合成(TTS)**を含めるという話をよく目にしていて、自分で試してみたかった
    思い浮かぶ考えを長く話して文書にし、編集してからAIに送るという循環作業は魅力的に見える

  • コミュニティへのものすごい貢献なのに、1人で作ったという点に驚いた。最後にSeries Aの資金調達発表でも出てくるのかと思った
    AIで低品質な成果物を素早く大量に吐き出すこともできるが、野心を広げて以前より厳密で長く残るものを作ることもできるのだと示している。Transcribe.cppを直接アプリに入れるより、こうした機能はOSやHandyのようなアプリを通じてどこでも利用可能であるべきだと思う

    • 作者でありメンテナーでもあり、スポンサーとHandyコミュニティからの寄付が大きな助けになった。特に Mozilla AI が初期作業を支援し、Handyのための漠然とした夢を実際のプロジェクトへ発展させ、v0.1.0をリリースする時間を確保してくれた
      いつかはlibtranscribeをきちんと配布し、システムライブラリのようなものにしたい。安定化には時間がかかるだろうが、可能だと思っている
  • 既存の transcribe-rs よりはるかにうまく動作する。オフライン音声入力アプリも新しいライブラリを使うように更新したところ、速度が大幅に向上した: https://github.com/notune/android_transcribe_app

  • 今後さまざまな理由でローカル推論が増えていき、より多くのアプリがそれを使うには実行と配布が容易になる必要がある、という見立ては正確だ
    この記事のどの単語も AI が書いたものではなく、口や指から出たものだという点も、このプロジェクトをより信頼しやすく、近づきやすいものにしている

    • 私たちが使うツールは思考を形作るので、この主張には同意しにくい。音声認識 LLM も結局は LLM であり、学習過程に内在する期待に沿って誤りが形成され、画面に表示される単語にも影響する
      頻繁に使っていると、どの単語の並びが正確に文字起こしされるのかを学ぶようになり、それが思考プロセスの一部になる。時間が経つとLLM と思考が絡み合うため、このような形での AI 利用も最終的な文章を実際に変えうる
  • ローカルで文字起こし API サーバーを運用しようと調べる中で、似た問題に遭遇した。最も不足していたのはストリーミング対応と、認識時に優先度を上げたい特殊な単語への対応だったが、ここにはストリーミングがあるのでうれしい

    • whisper.cpp が登場してから、3090 Ti サーバーで自前運用している。より速くて優れた代替が出てきたとしても問題なく動き続けており、重みは小さく、必要な速度を十分に上回っている
      次のようにローカルのホームサーバーに載せれば、簡単にローカル文字起こし APIを作れる。推論パラメータは少し調整が必要だが、一度固めれば非常によく動作する

      MODEL="/home/user/projects/ggml-org/whisper.cpp/models/ggml-large-v3-turbo.bin"
      WHISPER_SERVER_BIN="/home/user/projects/ggml-org/whisper.cpp/build/bin/whisper-server"
      "$WHISPER_SERVER_BIN" --model "$MODEL" --language en --host 127.0.0.1 --port 7812

    • 単語の重み付け調整はかなり後になってから対応される可能性が高いが、ストリーミングはすでに提供されている
      誰かがコードベースに良いサーバー例をコントリビュートし、問題解決も手伝ってくれるか、transcribe.cpp またはバインディングを使って他の言語で堅牢なサーバーを作ってくれることを期待している。完成したらメインプロジェクトから直接リンクするつもりもある