- ストリーミング音声認識をネイティブ環境とブラウザの両方で実行できるRustベースの実装で、Burn MLフレームワークを使用
- モデルはMistralのVoxtral Mini 4B Realtimeをベースとしており、WASM + WebGPUによりブラウザタブ内で完全なクライアントサイド推論を実行
- **Q4 GGUF量子化モデル（2.5GB）**はブラウザで実行可能で、**SafeTensorsベースのF32モデル（9GB）**はネイティブ環境で動作
- ブラウザの制約（2GB割り当て、4GBアドレス空間、GPU読み取り制限など）を解決するため、シャーディング、2段階ロード、非同期テンソル処理などの技術を適用
- Apache-2.0ライセンスで公開されており、HuggingFace Spacesでリアルタイムデモを体験可能
Voxtral Mini 4B Realtime (Rust) 概要
- MistralのVoxtral Mini 4B RealtimeモデルをRustとBurn MLフレームワークで完全実装
- ストリーミング音声認識をローカルおよびブラウザ環境で実行可能
- ブラウザ版はWASM（WebAssembly）とWebGPUを活用してクライアントサイドで動作
- **Q4 GGUF量子化モデル（約2.5GB）**はブラウザで実行され、**F32 SafeTensorsモデル（約9GB）**はネイティブ環境で使用
- HuggingFace Spacesでリアルタイムデモを提供
アーキテクチャ
- 入力音声（16kHz mono）はMelスペクトログラムに変換された後、**エンコーダ（32層）とデコーダ（26層）**を経てテキストに変換
- 主な処理ステップ
- Melスペクトログラム → エンコーダ（32層、1280次元）→ Conv 4xダウンサンプル → アダプタ（3072次元）→ デコーダ（GQA 32Q/8KV）
- 2つの推論パスを提供
- F32（native）: SafeTensorsベース、Burnテンソル演算を使用
- Q4 GGUF（native + browser）: GGUF Q4_0量子化、カスタムWGSLシェーダを使用
ブラウザ実行のための技術的解決策
- ブラウザ内で4Bモデルを実行するため、5つの制約条件を解決
- 2GB割り当て制限 →
ShardedCursorで複数バッファを読み込み
- 4GBアドレス空間制限 → 2段階ロード（パース後にリーダーを解放し、その後に最終化）
- 1.5GiB埋め込みテーブル → GPU Q4埋め込み + CPU行参照
- GPU同期読み取り禁止 →
into_data_async().awaitを使用
- 256ワークグループ制限 → cubecl-wgpuパッチでカーネルサイズを制限
Q4パディング補正
- 基本のmistral-commonは音声を32個の無音トークンでパディングするが、これはデコーダの38個のプレフィックスの半分しかカバーしない
- Q4_0量子化モデルではこのため、音声がすぐに始まる入力でエラーが発生
- これを解決するため、**パディングを76トークン（=38デコーダトークン）**に拡張し、プレフィックス全体を無音で埋める
ビルドとテスト
- ビルドオプション
- デフォルト:
cargo build --release (wgpu + native-tokenizer)
- ブラウザ向け:
wasm-pack build --target web --features wasm
- テスト
- GPUベースのユニットテストおよび統合テストをサポート
- E2EブラウザテストはPlaywright + 実GPU環境で実施
- CIではGPUがないため関連テストは省略
モデル準備とシャーディング
ライセンスとリソース
1件のコメント
Hacker Newsのコメント
興味のある人向けに、@antirez が Voxtral Mini 4B の C 実装を公開している
antirez/voxtral.c で確認できる
自分は 自分のフォーク版 を作って、CUDA 実装といくつかの改善を追加しているところ
かなりうまく動くが、まだ Mistral AI の API エンドポイントの速度には及ばない
いきなりコードを書くというより、まず関連資料を読んで学ぶべきだと思うので、参考になるガイドがあれば知りたい
違いはよく分からないが、コミュニティの反応はこちらの方が良さそう
デモを試したところ、Mic ボタンを押して録音し、その後 “Stop and transcribe” を押さないと結果が出なかった
ユーザーが話したあと 1〜2 秒以内にすぐ字幕が出る 本当のリアルタイムモードにできるのか気になる
Hugging Face のサーバーデモ は GPU ベースの 8.5GB モデルでそれを実現している
ただし リングバッファベースの UI を作れば、それに近い形では実装できる
自分は Flutter で Whisper をこの方式で使っていて、llama.cpp の GGUF 推論も Dart で動かしている
M4 Max でもリアルタイムではなく、Whisper は 2022 年以降のデバイスなら ONNX でほぼリアルタイムになる
コンシューマー向けハードウェアでは、精度（WER）の向上より 推論速度の方が重要だと思う
こういう オンプレミスのオープンモデルこそ、本当に必要な方向性だ
ユーザーも企業もどちらもこういう形を好む。Mistral はそこをうまく捉えたようだ
オープンモデルの時代はこれからさらに面白くなりそうだ
素晴らしい仕事だ。handy.computer と連携できると良さそうだし、ストリーミング対応の予定があるのかも気になる
最初のバージョンはおそらくストリーミングには対応しないはず
おかげで良いツールを知ることができたし、今は Voxtral 対応が本当に必要だと感じている
モデルについてはあまり詳しくないが、Nvidia Parakeet を使ってみたところ非常によく動いた
こういう 9GB 級のモデルはリアルタイムで使うなら GPU メモリに常駐させておく必要があるのか、それとも毎回ロードしてもよいのか気になる
短い文はほぼ即座に、長い文でも 1〜3 秒以内に変換される
わずかな精度低下は、AI と会話する用途ではほとんど問題にならない
Handy というオープンソースアプリ（リンク）で Parakeet V3 を使っているが、C 実装はずっと遅かった
STT では 速度が UX の核心だ
遅延が出るのは新しいモデルを読み込むときや、大きなコンテキストを切り替えるときだ
ほとんどの場合はすでにモデルがロード済みなので、主要な変数は tokens per second になる
複数エージェントを使う複雑な構成では、コンテキスト切り替えのせいで遅くなる
ik_llama の プロンプトキャッシュはこうした状況で速度向上に役立つ
つまり、頻繁にモデルやコンテキストを切り替えない限り、重みのロード遅延は大きな問題ではないということだ
ブラウザタブ 1 つが 2.5GB のモデルをダウンロードして、すぐ削除される構造が効率的なのか疑問だ
インターネット速度やストレージ容量が安くなったとはいえ、このやり方は無駄に感じる
クライアント側計算は良いが、この規模のモデルなら サーバーで動かすべきに思える
しかし LLM 向けの Web API 標準ができれば変わるかもしれない
ブラウザがユーザーの好みのモデルと通信してローカル／リモート推論を抽象化すれば、サイトごとにモデルを共有できるようになる
2026 年に 2.5GB のローカルモデルが問題だというなら、もう何が安全圏なのか分からない
不可能→集中化→ローカルへと発展してきて、その代償が 2.5GB なら十分受け入れられる範囲だ
ブラウザで動くのはすごいが、Web サイトがバックグラウンドで 2.5GB をダウンロードする世界は望んでいない
Nano は ローカルストレージに保存され、サイト間で共有されるので、一度ダウンロードすれば済む
Mistral はそうではないようだ
関連する統計は このブログ記事 にまとめられている
パッケージのインストールや実行ファイルのダウンロードよりは、ブラウザのサンドボックス環境の方が安全だと思う
こういうのもそのうち普通になるだろう :-)
自分の環境（Firefox、Asahi Linux、M1 Pro）では 誤動作する
“hello” と言ったら、1 分ほど後に変な単語が繰り返し出力された
単純な質問だが、Mistral のようなオープンモデルは OpenAI や Anthropic と比べてどの程度の水準なのか気になる
個人用マシンで プライベートに LLM 機能を使えるくらいなのか、
それともまだ商用モデルには大きく及ばない段階なのか知りたい
興味深いプロジェクトだし、burn フレームワークが使われているのも嬉しい
ただ Chromium の最新バージョンで実行したところ、システムがフリーズして OS が強制終了した
モデルのダウンロード直後に VPN 接続も切れたが、帯域制限はかけていなかったので理由が分からない