完全ローカル・リアルタイム音声対話の現在地
個人開発者が数ヶ月をかけて構築した音声対話システムが、Sourceにて報告された。クラウドAPIを一切使わない完全ローカル構成でありながら、リアルタイムに近い応答速度を実現している点が注目に値する。
システムの中核を担うのはQwen3.5-397B(Unslothの`UD-Q3_K_XL`量子化)だ。パラメータ数397Bという巨大モデルをローカルで動かすには相応のリソースが必要だが、MoE(Mixture of Experts)アーキテクチャの特性を活かし、VRAMは21.3GB以下に抑えている。24GBのGPUであれば、コンピュートグラフ用のヘッドルームを残しつつ動作可能だ。MoEのエキスパートはシステムRAMに展開され、約150GBを占有する。
STT(音声認識)にはWhisper-small、TTS(音声合成)にはOrpheus Q4_K_XLを採用。OrpheusのデコーダーはカスタムSNACデコーダーをONNX上で実装している。この構成が低遅延TTSを支える基盤となっている。
SSEストリーミングと割り込み処理——設計の核心
リアルタイム性を実現した鍵はSSE(Server-Sent Events)ストリーミングだ。LLMの生成トークンをストリームとして受け取りながら逐次TTSに渡すことで、生成完了を待たずに音声出力を開始できる。結果として体感遅延が大幅に削減される。
さらに重要なのが「割り込み可能性(interruptibility)」の実装だ。ユーザーが応答途中で発話した場合、直前に出力されていた内容のコンテキストを保持したまま処理を中断・再開できる。単純に生成を止めるだけでなく「何を言いかけていたか」を保持する点は、自然な対話体験に直結する。この実装の詳細はソースでは明かされていないが、コンテキスト保持の仕組みが設計の核心と考えられる。
KVキャッシュはbf16で動作している。ソースによれば、Qwen3.5はQ8 KVキャッシュで不安定な挙動(「spazzes out」)を示すため、bf16が選択された。コンテキスト長は131,072トークン——数時間分の会話を保持できる容量だ。
再現を目指す読者へ
このシステムの構成要素を整理すると以下になる。LLM:Qwen3.5-397B UD-Q3_K_XL、STT:Whisper-small、TTS:Orpheus Q4_K_XL+カスタムSNACデコーダー(ONNX)、KVキャッシュ:bf16、コンテキスト長:131,072トークン、VRAM:21.3GB以下(24GB GPU想定)、システムRAM:約150GB(MoEエキスパート)。
GitHubコードは近日公開予定とのことで、詳細な実装は公開後に確認できる見込みだ。150GBのRAM要件はハードルが高いが、MoEモデルのオフロード戦略として参考になる構成といえる。
完全ローカルで音声対話を実現しようとする開発者にとって、このシステムはSSEストリーミング×割り込み処理×KVキャッシュ選択という三点の設計判断が実装の要になる。GitHubリポジトリの公開を待ち、コードレベルで各実装を確認するのが次のアクションだ。
関連リンク
- Qwen3.5-397B-A17B-GGUF UD-Q3_K_XL(Unsloth / Hugging Face):記事で使用されているLLMの量子化GGUFファイル(179GB・3bit)の配布ページ。
- Orpheus TTS Q4_K_XL GGUF(Unsloth / Hugging Face):TTSに使用されているOrpheus 3B ftモデルのGGUF量子化版(UD-Q4_K_XL含む)配布ページ。
- Orpheus-TTS 公式リポジトリ(Canopy AI / GitHub):Orpheus TTSのオープンソース実装・コードおよびモデルカードの公式GitHub。
- Whisper(openai/whisper / GitHub):STTに使用されているOpenAI Whisper(small含む)のオープンソース公式リポジトリ。






