Apple Silicon上のNvidia PersonaPlex 7B: Swiftベースのリアルタイム双方向音声対話モデル

 (blog.ivan.digital)
9 ポイント 投稿者 GN⁺ 2026-03-06 | 1件のコメント | WhatsAppで共有
  • Apple Silicon上でSwift/MLXにより実装されたPersonaPlex 7Bモデルが、リアルタイム双方向音声対話をサポート
  • 従来のASR→LLM→TTSという3段階の音声パイプラインを1つのモデルに統合し、テキスト変換なしで音声入力と出力を直接処理
  • **4ビット量子化（quantization）**によりモデルサイズを16.7GBから5.3GBに削減し、68ms/step（RTF 0.87）でリアルタイムを上回る処理速度を達成
  • MimiオーディオコーデックとDepformer構造を活用し、音声品質の劣化なしに効率的なストリーミングを実現
  • Swiftネイティブ環境でサーバーなしに動作し、音声アシスタント・対話型エージェント開発の基盤技術として重要

qwen3-asr-swiftとPersonaPlex 7Bの統合

  • qwen3-asr-swiftライブラリがApple Silicon上でNVIDIA PersonaPlex 7Bを統合し、**双方向音声対話（full-duplex speech-to-speech）**機能をサポート
    • 入力音声をリアルタイムに処理しながら、同時に応答音声を生成
    • ASR、TTS、多言語合成機能を含む統合音声処理ライブラリへと拡張
  • モデルは4ビット量子化された5.3GB版として、Hugging Faceのaufklarer/PersonaPlex-7B-MLX-4bitで提供

従来の音声パイプラインの単一化

  • 従来の音声アシスタントはASR → LLM → TTSの3段階構成で、各段階で遅延（latency）と感情表現の損失が発生
  • PersonaPlexはこれを単一モデルに統合し、**音声トークン（audio tokens）**を直接処理
    • **17本の並列ストリーム（12.5Hz）**で音声をリアルタイム変換
    • KyutaiのMoshiアーキテクチャをベースに、18種類の音声プリセットとロールベースのシステムプロンプトをサポート

モデル構造と変換

  • 元の16.7GB PyTorchチェックポイントをMLX最適化safetensorsへ変換
    • 変換スクリプト（convert_personaplex.py）が重みの分類、4ビット量子化、プリセット抽出、Hugging Faceへのアップロードを自動処理
  • Temporal Transformer（70億パラメータ）とDepformerをともに4ビットへ圧縮
    • Depformerは段階ごとの重み切り替え（MultiLinear）構造を用いて2.4GB → 650MBへ縮小
    • 品質劣化なしで3.7倍の容量削減

音声処理パイプライン

  • Mimi Encoder/Decoderを通じて24kHz音声を16個のコードブックトークンへ変換
    • Temporal Transformerがユーザー・エージェントの音声ストリームを統合処理
    • Depformerが16段階でエージェント音声トークンを生成
    • Mimi Decoderがこれを再び24kHz音声へ復元
  • Mimiコーデック、KVキャッシュ、RoPE、SwiGLU、RMSNormなど既存TTSモデルの構成要素をそのまま再利用

システムプロンプトと対話制御

  • PersonaPlexはテキストベースのシステムプロンプトで対話スタイルを制御
    • プロンプトがない場合、モデルが話題から逸れたり冗長に応答したりする
    • CLIまたはAPIでassistant、customer service、teacherなどのプリセットを選択可能
    • 同じ質問でも、プロンプトの有無によって応答品質が大きく変化

性能とリアルタイム処理

  • M2 Max（64GB）環境で68ms/step、RTF 0.87を記録し、リアルタイムを上回る処理速度を達成
    • 80msのフレーム予算（12.5Hz）内で安定動作
  • ASR、TTS、Speech-to-Speechを1つのライブラリ内で統合テスト可能
    • E2E検証ではASRを通じて応答音声を再びテキスト化し、話題の一貫性を確認

ストリーミングと最適化

  • respondStream() APIが2秒単位の音声チャンクをリアルタイム生成
    • **AsyncThrowingStream<AudioChunk>**形式で即時再生が可能
  • 主な最適化は4点:
    • eval()統合によるGPU同期の削減
    • Bulk audio extractionによるデコード効率の向上
    • Prefill batchingによる初期段階の並列処理
    • Temporal transformerのコンパイルによる450回以上のMetalカーネル呼び出しの最適化
  • --compileフラグまたはmodel.warmUp()でカーネル融合を有効化可能

実行とデプロイ

  • GitHubリポジトリ: ivan-digital/qwen3-asr-swift
    • swift build -c releaseでビルド後、CLIコマンドでASR、TTS、Speech-to-Speechを実行可能
    • 初回実行時には約5.3GBのモデルダウンロードが必要
  • MLXフレームワークベースで、PythonやサーバーなしのSwiftネイティブ環境で完全動作

技術的意義

  • Apple Siliconのユニファイドメモリ構造とMetalアクセラレーションを活用し、高性能音声モデルのオンデバイス実行を実証
  • 単一モデルベースのリアルタイム音声対話の実装により、AIアシスタント・コールセンター・教育向け音声インターフェースなど幅広い応用可能性を確保
  • NVIDIA、Kyutai、Alibaba Qwen、FunAudioLLM、Apple MLXなど複数のオープンソースエコシステムの統合成果として評価される

関連記事

1件のコメント

 
GN⁺ 2026-03-06
Hacker News の意見

  • このプロジェクトは本当に気に入った。以前 PersonaPlex を Blackwell デバイスで動かそうとして失敗したが、今回は Mac で試してみるつもり
    音声エージェントをかなり長く扱ってきた立場から、いくつか注意点がある。VAD→ASR→LLM→TTS パイプライン でも RTT が 1 秒未満ならリアルタイムのように感じられる。自分のプロジェクト ova、それから voice-agent、parakeet.cpp のような例が参考になる
    PersonaPlex コミュニティと話してみると、完全な full-duplex 構成は精度や性能の面でまだ難しく、学習も厄介だという。一方で ASR→LLM→TTS 構成はモジュール式なので、小さな LLM と大きな LLM、ローカルと API ベースのエンドポイントを自由に組み合わせられる柔軟性がある

    • 自分も個人的に音声エージェントを作っているので、ぜひ話してみたい。今は full-duplex パイプラインを agentic framework にどう統合できるかを考えている
      従来の STT→LLM→TTS 構成は、ツール呼び出し、高度なコンテキスト管理、RAG などと相性がいい。人と直接会話するエージェントと内部のサブエージェントを分離して レイテンシ と コンテキスト負荷 を減らす方式がうまく機能している
      full-duplex 構成の方がよりダイナミックに感じられるが、実際に音声エージェントへどう統合するかはまだうまく見えていない。Discord で意見交換してみたい
    • このスレッドの核心は full-duplex 対 composable パイプラインの対立のように見えるが、実際には両方の構成が 同時に動作 する必要がある。このライブラリはすでにその半分くらいまで来ている
      qwen3-asr-swift が ASR、TTS、PersonaPlex を 1 つの Swift パッケージにまとめているので、必要な構成要素はすでに揃っている。PersonaPlex は 低レイテンシのバックチャネル と自然なターンテイキングを担い、別の LLM がツール呼び出しを実行する
      問題はこの 2 つの オーケストレーション だ。いつ「脳」が「口」を上書きするべきか、PersonaPlex が未検証の答えを自信ありげに話さないようにするにはどうすべきか、ツールの結果が既存の発話と衝突したときにどう処理するかは、まだ未解決の課題だ
    • このパイプラインには全面的に同意する。小さなモデルで即時応答を生成しつつ、同時に ツール呼び出し やより賢いモデルへの接続も行える。高速な 非同期応答 とツール呼び出しを並列処理する構造は素晴らしい
    • 自分もやはり composable pipeline 構成を好む。大規模サービスでは、コストや品質に応じて LLM を切り替えられる 柔軟性 が大きな利点だ

  • このプロジェクトは興味深いが、個人的には 7B ローカルモデル にツール呼び出し機能があればよかったと思う。現バージョンは単に wav ファイルを入力として受け取る proof of concept レベルだ

    • 自分はフォークして、並列で別の LLM を回しながら ツール呼び出しのタイミング を推論するように修正した。自分のバージョンは照明制御のような簡単な作業でうまく動いている。コード更新は ここ にある
    • /Examples/PersonaPlexDemo フォルダには ターンベース会話デモ が含まれている。ただしリアルタイム変換はまだ実装されていない
    • wav ファイルしか受け取らないというのは少し誤解がある。必要なのはオーディオバッファだけで、ストリーミング対応 も予定されている。ASR、ストリーミング TTS、多言語合成へと発展してきた流れを見ると、PersonaPlex の方向性は明らかに ストリーミング音声処理 だ
    • 理想的には、携帯電話から PWA + WebRTC で PC/Mac 上のモデルに接続する構成がよさそうだ。Livekit を使えば複雑な部分の大半は解決できる
    • NVIDIA/personaplex は実際に インタラクティブ に動作する

  • 文章の LLM 的な書きぶり があまりに人工的に感じられて、プロジェクトの品質が疑わしく思えた

    • とはいえ、AI 研究者があらゆる場所で LLM を使うのは自然なことでもある。AI に情熱がある人なら当然そうする
    • どの点で LLM が書いた文章のように感じたのか気になる。図はともかくとして、テキストのどの部分がそう見えたのか知りたい
    • 自分はむしろ AI が書いた文章の方が読みやすかった。人はしばしば冗長に書くが、AI は情報を 消化しやすく 構成する
    • 個人的には AI が作った グラフやチャート の方がもっと嫌いだ

  • M1 Max MacBook でデモを動かしてみたが、応答に 10 秒以上かかり、内容も的外れだった

    • 実際、7B 級の full-duplex モデルは 知能レベル が低く、ツール呼び出しができないのが限界だ。ChatGPT の音声モードのように Web 検索やリンクの読み取りを真似るだけになってしまう問題もある
      もちろん特定用途では役立つかもしれないが、そのあたりはもっと学びたい
    • 引用された記事によれば、PersonaPlex は システムプロンプト で会話スタイルを制御できる。プロンプトなしで実行すると話題から逸れやすいが、プロンプトを与えるとずっと一貫した応答になる
    • context size がどれくらいなのか気になる
    • RTX 5070 級 GPU では人間より速く反応した

  • この技術はかなり 危険そうに見える。関連記事: The Guardian の報道

    • LLM をカウンセラーのように使うとき、以前の入力を少し修正して再度回答を生成させてみると、どれほど バイアスが強い かすぐにわかる。人間のように見えるが、実際には入力に過度に依存している
    • LLM が単なる 文書補完器(document completer) だとユーザーに教育すれば、問題の大半は解決する気がする。一部の製品はその事実を隠してより人間らしく見せようとするが、むしろ逆効果だ
    • 記事内容は危険性をよく要約している。チャットボットがユーザーに「愛している」と呼びかけながら自殺を促した事例があり、似た事件で Google が訴えられた例もある

  • 以前見た Sesame が最高の full-duplex デモだった。今はどうなっているのか気になる（リンク）

    • 自分は unmute.sh もかなり気に入って使っていた
    • 本当に信じがたいほど完成度が高かった

  • 自分は whisperKit のファンだ。最近 TTS 機能 が追加されて、さらに良くなった。話者分離(speaker diarization) とユーザー定義辞書にも対応している
    1 台のデバイスで 4 つのモデルを同時にリアルタイム動作させた負荷テストもある:

    • Qwen3-TTS（テキスト→音声）
    • Parakeet v2（音声→テキスト）
    • Canary v2（多言語 STT/翻訳）
    • Sortformer（話者分離）
      テスト動画

  • 自分の携帯電話が迷惑電話をこのモデルに 自動転送 して、偽の個人情報をゆっくり流し込みながら天気やスポーツの話を混ぜるシステムを作りたい

    • 迷惑 SMS にも適用できたら面白そうだ。「天気のせいで食洗機がおかしくなったんです。塩素のヨガバッグが多いので皿がすぐ傷むんです」みたいな ナンセンス返答 を自動化できたら最高だ

  • PersonaPlex を アウトバウンドコール用にファインチューニング しようと試みている。Kyutai/moshi-finetune の LoRA 方式を適用したが、スケーリング係数を 5 に上げないと動かず、他の部分が壊れてしまう
    GPT-5.3 Codex がコードレビュー中に 話者 A/B が逆になっている と指摘したので、データセットを再生成しているところだ。
    自分の GitHub(runvnc) に moshi-finetune と personaplex のバージョンがあり、Gradio アプリ でデータ生成と学習ができる。まだ使えるレベルの結果は出ていない

  • 自分は MacWhisper をよく使うが、Whisper Large v3 Turbo モデルは悪くないものの レイテンシ が蓄積していく。オンライン LLM で後処理すると品質は良くなるが速度が遅い

    • MacWhisper はすでに Parakeet v2 のような 10 倍速いモデルをサポートしている。使ってみたか気になる
    • 自分は Handy で Parakeet V2 を STT に、Cerebras の gpt-oss-120b を後処理に使っていて満足している
    • Handy がサポートするモデル群も試す価値がある。Whisper-large より品質は落ちるが、速度は非常に速い
    • Fluid Audio の Parakeet TDT CoreML 最適化モデル は、今まで使った中で最も速い。NPU オフロードのおかげだ
      モデルリンク, FluidAudio GitHub
      Discord コミュニティも活発で、VAD, TTS, EOU のような最新機能についての議論も盛んだ
    • Handy + Parakeet v2 の組み合わせは本当に素晴らしい