Moshi: リアルタイム対話のための音声・テキストベースモデル

• Moshi は、リアルタイム音声対話のための音声・テキストベースモデルであり、full-duplex 音声対話フレームワークでもあり、ライブデモと Hugging Face モデルを提供している
• リポジトリには、研究・実験用の PyTorch、iPhone/Mac のオンデバイス推論用の MLX、本番運用向けの Rust 推論スタックが分離して収められている
• モデルは、Moshi の発話とユーザーの発話という 2つの音声ストリーム を扱い、Moshi 自身の発話に対応するテキストトークンである inner monologue も予測して生成品質を高めている
• Mimi コーデックは、24kHz 音声を 12.5Hz 表現と 1.1kbps 帯域幅でストリーミング処理し、80ms のフレーム遅延を持ち、Moshi の理論遅延は 160ms、L4 GPU で実測した全体遅延は最短 200ms である
• 公開モデルは、男性合成音声の Moshiko、女性合成音声の Moshika、音声コーデックの Mimi で、モデル重みは CC-BY 4.0、Python・Web クライアントコードは MIT、Rust バックエンドは Apache ライセンスで提供される

---

Moshi の目的と構成

• Moshi は speech-text foundation model であり、リアルタイム音声対話のための full-duplex フレームワークでもある
• ライブデモは moshi.chat で提供され、モデルコレクションは Hugging Face で公開されている
• リポジトリには 3 つの推論スタックが含まれる
  • PyTorch: 研究と実験用、moshi/ ディレクトリに配置
  • MLX: iPhone と Mac のオンデバイス推論用、moshi_mlx/ ディレクトリに配置
  • Rust: 本番運用向け、rust/ ディレクトリに配置
    • Rust ベースの Mimi 実装と Python バインディング rustymimi を含む
• Moshi デモで使われる Web UI クライアントコードは client/ ディレクトリにある
• Moshi のファインチューニングは別リポジトリ kyutai-labs/moshi-finetune で扱われている

関連する Kyutai モデル

• Moshi コードベースは、Moshi と似た multi-stream architecture を使う Kyutai 関連モデルの実行にも使われる
  • Hibiki: 同時音声翻訳
  • Delayed Streams Modeling: Kyutai Text-To-Speech と Speech-To-Text

モデルアーキテクチャ

• Moshi は 2つの音声ストリーム をモデリングする
  • 1つは Moshi が話すストリーム
  • もう 1 つはユーザーが話すストリーム
• 2つの音声ストリームに加え、Moshi は自分の発話に対応するテキストトークンである inner monologue を予測し、この方式が生成品質を大きく改善している
• 小型の Depth Transformer が特定の時間ステップにおけるコードブック間依存をモデリングする
• 大型の 7B parameter Temporal Transformer が時間的依存性をモデリングする
• 遅延時間は理論上 160ms である
  • Mimi フレームサイズ 80ms
  • 音響遅延 80ms
• L4 GPU における実用的な全体遅延時間は最短 200ms である

Mimi 音声コーデック

• Mimi は 24kHz 音声を 12.5Hz 表現へ落とし込むニューラル音声コーデックである
• Mimi は完全ストリーミング方式で動作し、帯域幅は 1.1kbps、遅延はフレームサイズの 80ms である
• README によれば、Mimi は既存の非ストリーミングコーデックより優れた性能を示す
  • SpeechTokenizer: 50Hz, 4kbps
  • SemantiCodec: 50Hz, 1.3kbps
• Mimi は SoundStream や EnCodec のような従来のニューラル音声コーデックをベースとしている
  • エンコーダとデコーダの両方に Transformer を追加
  • 全体のフレームレートを 12.5Hz に合わせるよう stride を調整
• 12.5Hz のフレームレートは、テキストトークンの平均フレームレートである約 3〜4Hz により近くなり、Moshi の自己回帰ステップ数を減らす
• SpeechTokenizer と同様に、Mimi は最初のコードブックトークンが WavLM の自己教師あり表現と一致するよう distillation loss を使用する
• Mimi は EBEN と同様に、feature matching とともに adversarial training loss のみ を使い、低ビットレートでも主観品質を大きく改善している

公開モデルと形式

• 公開モデルは 3 つである
  • Moshiko: 男性合成音声向けにファインチューニングされた Moshi
  • Moshika: 女性合成音声向けにファインチューニングされた Moshi
  • Mimi: 音声コーデック
• バックエンドによってファイル形式と利用可能な量子化が異なる
• Mimi は各モデルにバンドルされ、常に同じチェックポイント形式を使う
• PyTorch モデル
  • Moshika: kyutai/moshika-pytorch-bf16, kyutai/moshika-pytorch-q8 実験的 int8
  • Moshiko: kyutai/moshiko-pytorch-bf16, kyutai/moshiko-pytorch-q8 実験的 int8
• MLX モデル
  • Moshika: kyutai/moshika-mlx-q4, kyutai/moshika-mlx-q8, kyutai/moshika-mlx-bf16
  • Moshiko: kyutai/moshiko-mlx-q4, kyutai/moshiko-mlx-q8, kyutai/moshiko-mlx-bf16
• Rust/Candle モデル
  • Moshika: kyutai/moshika-candle-q8, kyutai/moshika-candle-bf16
  • Moshiko: kyutai/moshiko-candle-q8, kyutai/moshiko-candle-bf16
• すべてのモデルは CC-BY 4.0 ライセンスで公開されている

要件とインストール上の制約

• Python は最低 3.10 が必要で、3.12 が推奨される
• PyTorch と MLX クライアントは PyPI からインストール可能

pip install -U moshi
pip install -U moshi_mlx
pip install rustymimi

• Python 3.12 でない場合、moshi_mlx または依存関係の rustymimi のインストール中にエラーが出ることがあり、その場合は Rust toolchain のインストール、または Python 3.12 への切り替えが必要となる
• Windows での動作は期待されているが、公式サポートは提供されない
• MLX 版は MacBook Pro M3 でテストされている
• 現在の PyTorch 版は量子化をサポートしておらず、24GB 級のかなり大きな GPU メモリが必要である
• Rust バックエンドには最新の Rust toolchain が必要
• GPU サポートをコンパイルするには、GPU に対応した CUDA と nvcc が必要

実行方法

• PyTorch

  • PyTorch API は moshi ディレクトリにあり、Mimi 音声トークナイザと Moshi 言語モデルの ストリーミング版 を提供する
  • 対話モードでは、まずモデルサーバーを起動し、その後 Web UI またはコマンドラインクライアントを使う

  python -m moshi.server [--gradio-tunnel] [--hf-repo kyutai/moshika-pytorch-bf16]
  

  • Web UI はデフォルトで localhost:8998 からアクセスできる
  • リモートマシンの GPU に HTTP 経由でアクセスすると、ブラウザのセキュリティポリシーによりマイク使用がブロックされる場合がある
  • SSH -L でリモートの 8998 ポートを localhost にフォワードできる
  • --gradio-tunnel でどこからでもアクセス可能なトンネルを作成できる
  • このトンネルは米国を経由するため、欧州では最大 500ms の大きな遅延が追加されることがある
  • --gradio-tunnel-token で固定の secret token を設定し、同じアドレスを再利用できる
  • --hf-repo で別の Hugging Face 事前学習モデルを選択できる
  • コマンドラインクライアントも提供されるが、Web ブラウザと異なり echo cancellation を行わず、遅延蓄積を補正するためにフレームをスキップすることもない

  python -m moshi.client [--url URL_TO_GRADIO]
  

• MLX

  • moshi_mlx をインストールすると macOS ローカル推論を実行できる

  python -m moshi_mlx.local -q 4
  python -m moshi_mlx.local -q 8
  python -m moshi_mlx.local -q 4 --hf-repo kyutai/moshika-mlx-q4
  python -m moshi_mlx.local -q 8 --hf-repo kyutai/moshika-mlx-q8
  

  • -q と --hf-repo フラグは常に一致していなければならない
  • MLX コマンドラインインターフェースも barebone で、echo cancellation や遅延蓄積補正は行わない
  • python -m moshi_mlx.local_web で Web UI を起動でき、HTTP 接続は localhost:8998 で提供される

• Rust

  • Rust 推論サーバーは rust ディレクトリで実行する

  cargo run --features cuda --bin moshi-backend -r -- --config moshi-backend/config.json standalone
  

  • macOS では --features cuda の代わりに --features metal を使用できる
  • config.json の代わりに config-q8.json を使うと q8 量子化モデル を利用できる
  • 別の事前学習モデルは設定ファイルの "hf_repo" キーを変更して選択する
  • サーバーが standalone worker listening を出力したら Web UI を利用できる
  • Rust サーバーはデフォルトで HTTPS を使用するため、https://localhost:8998 からアクセスする
  • ブラウザで安全でないサイト警告が表示されることがあり、Chrome では “Details” または “Advanced” を経由して localhost への接続を続行できる

クライアントと開発

• Web UI は echo cancellation を提供し、モデル全体の品質向上に役立つため推奨される
• ほとんどのコマンドは、提供された URL で Web UI を直接配信する
• Rust と Python 向けのコマンドラインインターフェースも提供され、Web UI と同じプロトコルを使うため、サーバー側の変更は不要である
• Web UI のビルドは client ディレクトリで行う

cd client
npm install
npm run build

• Rust コマンドラインクライアントは rust ディレクトリで実行する

cargo run --bin moshi-cli -r -- tui --host localhost

• Python PyTorch クライアントは次のコマンドで実行する

python -m moshi.client

• Gradio デモは gradio-webrtc>=0.0.18 をインストール後に実行する

python -m moshi.client_gradio --url <moshi-server-url>

• Docker Compose は CUDA 専用で、NVIDIA Container Toolkit が必要

docker compose up

ライセンスと引用

• Python 部分のコードは MIT ライセンスで提供される
• Rust バックエンドは Apache ライセンスで提供される
• Web クライアントコードは MIT ライセンスで提供される
• コードの一部は MIT ライセンスの AudioCraft をベースとしている
• モデル重みは CC-BY 4.0 ライセンスで公開されている
• Mimi または Moshi を利用する場合、Moshi: a speech-text foundation model for real-time dialogue 論文の引用が求められる

[GN⁺]

Hacker Newsのコメント

• ここのコメントはほとんど否定的なのでフィードバックしておくと、レイテンシは非常に良く、むしろ良すぎて頻繁に話を遮られるように感じるほどです。
  オープンソースモデルとしては大きな成果だと思います。ただ、最近の人々は非常に優れた大規模言語モデルに慣れすぎていて、このモデルの回答内容の品質は現時点の最高水準モデルとはかなり離れています。2019年頃に見た大規模言語モデルに近い印象で、音声のほうは「十分に良い」水準まで来ており、今後は回答品質に注力したほうがよさそうです。

  • 完全に同意です。レイテンシも良く、技術も素晴らしいです。Rust、コンシューマー向けノートPCでのエッジ実行まで印象的です。
    自然な疑問は、Moshiの体験を損なわずに「より良い大規模言語モデル」を移植する方法があるのか、ということです。

• MoshiはCC-BYで、最近Apache v2で公開された、似たような7B規模の音声テキストリアルタイム対話モデルもあります: https://tincans.ai/slm3 / https://huggingface.co/collections/tincans-ai/gazelle-v02-65...

  • 重要な違いは、tincansは音声対音声モデルではないという点です。別の発話／停止検出モデルと、最後にテキスト読み上げ処理ステップを使っています。

• 最近は音声対応言語モデルの開発が増えています。例えば https://github.com/ictnlp/LLaMA-Omni、https://github.com/gpt-omni/mini-omni があります。

• 彼らの推論サーバーは、Hugging FaceのCandleクレートを使ってRustで書かれています。Moshiの作者の1人はCandleの主著者でもあります。
  私たちもCandle上に推論スタックを作っていますが、かなり満足して使っています。

  • とても興味があります。vLLMに相当するものはありますか？バッチ処理やページドアテンションのようなものを作り直す必要があったのか気になります。

• YouTubeでデモを探していたら、数か月前のおもしろい動画を見つけました: https://youtu.be/coroLWOS7II?si=TeVghP_Zi0P9exQh
  今はきっと改善されているはずです :-)

• 興味深いです。ここでレイテンシに注力している点が良く、ローカルGPUで実際に約200msだと主張しています。
  7B Transformerモデルベースなので、それほど賢くはないはずです。70Bモデルのレイテンシが1秒程度だと想像すると、「モデルが今話しています」と言葉で知らせる中間反応、素早い初期反応を返す7B/Phi-3級モデル、そして大きなモデルへつなぐシステムアーキテクチャが可能に見えます。Phi-3モデルには実際に正しい答えを受け取り、必要なら謝罪して訂正する調整作業を任せることもできます。
  逸話的には、人間の脳もこのように動作することが多いと思います。素早く反応し、1〜2秒後に修正または補足するやり方です。もちろん逆にまったく修正しない人もいますし、長く黙ってから完全に熟考した答えを出す人もいます。

• 試してみましたが、どんなメールアドレスでも入れられました。即座に、ほとんどすぐ、まだ話している途中でも返答します。
  ただ、それは単なるつなぎ文のように見え、キャッシュされた回答にも思えました。実際に尋ねた内容への答えはかなり後に出てきて、その途中でループに陥らない必要があります。

  • 最初に出たときにこのデモを試し、今日また試しました。Reflection 70Bのときのように決めつけるつもりはありませんが、7月の元のデモで示されたものと同じ重みがアップロードされているようには見えません: https://the-decoder.com/french-ai-lab-kyutai-unveils-convers...

• リアルタイム音声 → 大規模言語モデル → 音声出力ソリューションを作っていますが、ここで最も興味深い部分はストリーミングニューラル音声コーデックだと思います。Whisperでは実際に音声認識を適切にストリーミングするのが難しいからです。
  ただしプロダクトの観点では、必ずしもそれを大規模言語モデルに直接入れて回答させたいとは思いません。多くのユースケースでは、回答前にツール／関数呼び出しのステップが必要だと思います。この方向で作業している人とはいつでも話してみたいです。
  下で言及されているtincansも素晴らしそうです。ただ、tincansの開発は終わったとのことなので、この方向には10000%余地があります。Chrisがこれを読んでいるなら、大規模言語モデルがどれだけ良くなっても、これが解決するプロダクト／ビジネス上のユースケースをぜひ説明してみたいです。

  • 私もこの流れを実験中です。Whisperでサンプルを切り出し、ユーザーがまだ話している最中でも文字起こしを始める「ストリーミング」構成を使っていて、その結果をMistral 8Bに入れ、事前に決めたIVRツリーに沿ってツールを呼び出す会話仲介役として使っています。
    大規模言語モデルが直接答えるわけではなく、事前に用意されたテキスト読み上げ出力付きのツリーノードを選ぶだけです。ユーザーが話し終えたかを判断して文字起こし結果をモデルに渡す「停止の長さ」パラメータがありますが、特に複雑ではありません。音声入力を適切に扱う方法や、プロンプト構成だけでIVRツリーをなくせるほど十分に精密にモデルを制御できるかを考え続けています。今でもかなりうまく動きますが、改善の余地は大きいです。
  • 回答前にツール／関数呼び出しステップが必要だという部分は、ほぼちょうど1年前に作ってみました :) 悪くはありませんでしたが十分に速くなく、それで結合モデルを作ることになりました。

• 応答速度は印象的ですが、回答の「品質」はそうではありません。2回目のテストの会話ログはこうでした。
  Moshi: 「こんにちは、どうしましたか？」
  私: 「今は何年？」
  Moshi: 「ああ、2019年です。たぶん1年くらい前だったと思います。」
  私: 「本当に2019年で合ってる？」
  Moshi: 「ああ、はい、確かです。2019年に間違いありません。その数字は最後のもののためです。」
  私: 「COVID-19って何？」
  Moshi: 「それは希少疾患です。皮膚を攻撃する過活動の免疫系によって起こります。」
  この時点でそれ以上答えなくなりました。

• Moshiはこれまでで最も楽しいモデルです。最近の体験はこちらにあります: https://x.com/tommoor/status/1809051817860354471
  ただし正確性は期待しないほうがよいです。