Voice Proの初期ビルドでは、公式のQwen ASR ONNXエクスポート形式を使用してONNX Runtimeが活用されていました。動作はしましたが、製品化するのは困難でした。私たちが直面した問題と、現在アプリが動作するようになった理由は以下の通りです。 llama.cpp GGUF量子化モデルを使用。
問題1：インストールサイズ
ONNX Runtime、DirectMLプロバイダ、CUDAプロバイダ、およびモデルウェイトを搭載したVoice ProのWindows版のサイズは、 430 MB. Linux版も同様でした。まだ試したことのないディクテーションツールのために、そんなに多くのファイルをダウンロードしてもらうのは無理があります。
GGUFビルドは Windows版のサイズは83MB. コンパイル済みのllama.cppバイナリは非常に小さく、量子化されたベースモデルは約60MBです（fp16 ONNXでは約200MB）。また、CPU、CUDA、DirectML、Vulkan用の個別の実行プロバイダDLLは同梱していません——llama.cppは1つのバイナリで4つすべてを処理します。
問題2：コールドスタート
Windowsをクリーンインストールした状態でDirectMLを利用したONNX Runtimeでは、推論セッションの初期化に3～5秒かかりました。再起動後にユーザーが初めてホットキーを押すたびに、この遅延が発生しました。「すぐに話せる」ことがこのツールの本質であるため、これは許容できません。
同じハードウェア上で、llama.cppは約400msでGGUFモデルをコールドロードします。メモリマップされた重みを使用し、グラフのコンパイルステップがなく、初期化するためのランタイムホイールも不要です。
問題3：パッケージングの複雑さ
ONNX RuntimeはPythonウィールとして提供されており、つまり Pythonのバージョン、OS、CPUアーキテクチャごとに異なるホイール. GPUアクセラレーションを加えると、CUDAのバージョン数とDirectMLのバージョン数によって値が倍増する。私たちのパッケージツールであるNuitkaは間違ったバリアントを常にバンドルしていた。私たちは6つの条件分岐を持つビルドスクリプトを使用していた。
llama.cppは単一のC++バイナリです。プラットフォームごと（Windows x64、Linux x64）に一度コンパイルし、Voice Proが呼び出すネイティブ実行ファイルとして出荷します。推論にはPythonランタイムの依存関係は一切ありません——Pythonは単なる接着剤です。
問題4：小規模モデルにおける品質
量子化における懸念点は精度の低下です。実際、当社の内部評価セット上で、Q5_K_Mで量子化されたQwen3-ASR 0.6B（当社のベースモデル）のWERは、フルfp16 ONNXバージョンと比べて0.3％以内です。Q4_0の場合は明らかに性能が劣るため、デフォルトとしてQ5_K_Mを提供しています。最高精度が求められるユーザーは、モデルマネージャーからfp16版をダウンロードできます。
私たちが諦めたもの
llama.cppのASRサポートはONNX Runtimeよりも新しいものです。一部の特殊なモデルアーキテクチャにはまだGGUFコンバーターがありません。現時点では問題ありません——Qwen3-ASRはきれいに変換できます——しかし、将来根本的に異なるASRモデルを試したい場合は、フォールバックとしてONNXパスを維持する必要があるかもしれません。
最終的な成果：インストールサイズが5分の1、コールドスタートが約10倍高速、ビルドすべきバイナリが12個から1つに。最初からこれを行うべきでした。