1台の推論サーバーで、ローカル音声アシスタントを複数の部屋で利用できる？

はい。複数の部屋で1台のローカル音声推論サーバーを共有できます。各部屋にはマイク／スピーカーサテライトが必要ですが、音声認識、言語モデルによる推論、音声合成といった負荷の高い処理はホームサーバー上で中央実行できます。マイクの近くでウェイクワード検出または音声区間検出を行うと、アイドル状態の部屋が継続的にサーバーへ音声をストリーミングしないため、システムを最も効率よく拡張できます。

主な制限要因は部屋の数ではありません。同時に話す人の数と、パイプラインの各段階で必要となる計算量です。ほとんどアイドル状態のサテライト6台のほうが、2つの部屋でWhisper、LLM、TTSの処理が重なって発生する場合よりも扱いやすいことがあります。

複数の部屋に対応するローカル音声アーキテクチャはどのようなものか

キッチンのサテライト ----寝室のサテライト -----オフィスのサテライト -------> ローカル音声サーバー
リビングルームのサテライト --/      |
                              +-- STT
                              +-- インテント／LLM
                              +-- TTS
                              +-- Home Assistant／ツール

サテライトの役割は軽量なままにできます。音声を収録し、ウェイクワードまたは発話を検出し、部屋の識別情報をリクエストに付加し、返された音声を再生し、必要に応じてローカルのミュート操作を処理します。

Home Assistantの現在のWyoming統合は、この分離の好例です。Assistを、Whisper、Piper、Speech-to-Phrase、openWakeWordなどのローカル音声認識、音声合成、ウェイクワードシステムに接続できます。

ローカルウェイクワード検出が大きな効果を発揮する理由

すべてのサテライトが24時間365日サーバーへ音声をストリーミングする場合、有線LANまたは安定したWi-Fi LANであればネットワークトラフィックは通常まだ十分処理できます。しかし中央マシンは複数の音声ストリームを継続的に検査しなければなりません。また、各部屋の環境音が中央サービスに届くため、プライバシーが及ぶ範囲も広がります。

より優れた設計は次のとおりです。

部屋のサテライト
  |
  +-- ローカルウェイクワード／VAD
  |
  +-- トリガー後のみ
          |
          v
      発話をストリーミング
          |
          v
   中央推論

Home Assistantの音声サテライトのドキュメントでは、常時ストリーミング、発話時ストリーミング、ローカルウェイクワードの各モードについて説明しています。また、小型のサテライトハードウェアでローカルのウェイクワード検出や音声クリーンアップを処理できるため、中央サーバーに同じ負荷をかけずに多数のサテライトを運用できることも記載されています。

1台のサーバーは、1つの共有会話を意味しない

これはアプリケーション層で最も重要なルールです。推論プロセスは共有できますが、各部屋またはユーザーには独自のセッション状態が必要です。

この分離がないと、「それを消して」のようなフォローアップが、別の部屋のコンテキストを誤って引き継ぐ可能性があります。サーバーはすべての発話にセッション識別子を付加し、それをSTT、意図の解決、ツールの実行、TTS再生まで引き継ぐ必要があります。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

部屋のコンテキストで短いコマンドを改善できる

マルチルームシステムには、単一のスマートスピーカーにはない情報があります。マイクがどこにあるかを把握しているのです。

毎回「リビングの照明を消して」と言わせる代わりに、サテライトがエリア識別子を提供できます。

発話：「照明を消して」
部屋："キッチン"

解決されたアクション：
Home Assistant -> キッチンの照明 -> オフ

これは、短いコマンドに高価な汎用LLMを必ずしも必要としない、決定論的なホームコントロールで特に役立ちます。ZimaSpaceによるHome Assistantのローカル処理拡大に関する解説では、焦点を絞ったローカルパイプラインが、より自由度の高いリクエスト向けの大規模モデルと共存できる理由を説明しています。

最初にボトルネックになるのは何か？

音声処理はパイプラインなので、必要なステージのうち最も遅いものが体感遅延を決めます。

家庭での利用では、同時発話が頻繁に起こることはほとんどありません。そのため、すべての部屋が常に同時に話し続けられるだけの計算資源を用意する代わりに、サーバーは短い処理のバーストをキューに入れられます。

STT、LLM、TTSは1つのGPUを共有できるか？

可能ですが、メモリとスケジューリングが重要です。複数のモデルを同時に読み込むと、どの単一ステージにも必要な量を超えるVRAMを消費する可能性があります。小型サーバーでは、異なるデバイスや実行モードを使用できます。

• CPUまたはiGPUでSTT。
• GPUでLLM。
• CPUでTTS。
• または、短いSTT／LLM／TTSジョブを1つのアクセラレーター上で順番に処理する。

2つ目の設計はハードウェアを節約できますが、2つの部屋が同時に話すときの遅延が増える可能性があります。単なる1秒あたりの生トークン数ではなく、最初の文字起こしまでの時間と最初の音声出力までの時間を測定してください。

ある部屋のスピーカーが別の部屋のマイクを起動しないようにする

マルチルーム音声では、音響上の問題が生じます。アシスタント自身のTTS音声が別のサテライトに聞こえ、新しいリクエストとして解釈される可能性があります。

使用：

• 周囲のすべての音声をオープンな文字起こしにかけるのではなく、ローカルのウェイクワードを使用する。
• エコーキャンセルとノイズ抑制。
• サテライトが必要に応じて自身の応答中にマイクを抑制できるようにする再生状態。
• 部屋ごとの音量。
• 日常的な制御向けの短い応答表現。

1つのスピーカーが話すたびに家中のマイクをすべてミュートしてフィードバックを解決しようとしないでください。そうすると、複数の部屋を同時に使う際の柔軟性が不必要に損なわれます。

ホームサーバーのキュー容量はどのように決めるべきですか？

現実的な同時実行数から始めます。サテライトが8台ある4人家族の家庭でも、同時リクエストが2件を超えることはめったにないでしょう。音声ジョブを無制限に積み上げるのではなく、上限付きのキューを設定します。

音声リクエスト
   |
   +-- スロット空き -> すぐに実行
   |
   +-- 短いキュー -> 「少々お待ちください」／待機
   |
   +-- キュー満杯 -> 明確に失敗

優先度付けも役立ちます。決定論的な照明制御コマンドが、長い会話型LLMの回答の後ろで待たされるべきではありません。高速なホームコントロールのインテントは小規模なパイプラインに振り分け、実際に大規模モデルが必要な質問には大規模モデルを割り当てます。

サーバーがローカルだとプライバシーは向上しますが、権限も重要です

ローカル推論を中央で行えば音声をクラウドサービスに送らずに済みますが、すべてのサテライトが、ロック、照明、メディア、アラーム、プライベートデータを制御できる特権システムに接続することになります。

部屋とユーザーのコンテキストを権限ポリシーに関連付けます。ゲストルームのサテライトには照明や温度の制御を許可しても、カレンダーやプライベートなNASファイルへのアクセスは許可しないようにできます。子ども部屋には、まったく別のツールセットを設定することもできます。

より広範なオーケストレーション層については、ローカルAIツールの信頼境界ガイドで、音声認識だけでは管理権限を付与すべきでない理由を説明しています。

マルチルーム音声展開チェックリスト

• 各サテライトに固定の部屋IDを割り当てます。
• 可能な場合は、サテライト上でウェイクワード検出またはVADを実行します。
• 部屋／セッションごとに会話状態を分離して保持します。
• 定型的なホームコントロールコマンドには、高速で決定論的な経路を使用します。
• 高コストなSTT／LLMジョブは、同時実行数に上限を設けたキューに入れます。
• 複数ユーザーが重なった場合のレイテンシーを測定します。
• エコーキャンセル／フィードバック防止を有効にします。
• 各部屋には必要なツールだけを提供します。
• 重要なホームコントロールコマンド用に、ローカルのフォールバックを用意します。

よくある質問

各部屋に専用のAIコンピューターが必要ですか？

いいえ。サテライトは安価なマイク／スピーカーのエンドポイントにできます。高コストなモデルは中央サーバー上で1回だけ実行できます。

複数の部屋から同時にサーバーへ話しかけられますか？

ランタイムに十分な同時処理能力または短いキューがあるなら、実行してもかまいません。モデルの重みを共有している場合でも、各リクエストには個別のセッション状態と音声状態が必要です。

ウェイクワード検出は中央で実行すべきですか？

可能です。ただし、ローカルでウェイク検出を行うと、常時音声ストリーミング、中央サーバーの負荷、プライバシーへの露出を減らせます。サテライトハードウェアが対応している場合、一般的にはこちらのほうがすっきりしたマルチルーム構成です。

最終結論

1台のローカル推論サーバーで、家中の音声サテライトに対応できます。 エンドポイントはシンプルに保ち、ウェイク検出を各部屋側に寄せ、高コストなモデルを一元化し、セッションごとに分離します。スピーカーの台数ではなく同時発話数を基準にサイジングし、定型コマンドは高速なローカル経路に振り分けて、ある部屋での長いLLM会話によって家全体の応答が遅く感じられないようにします。