RK3576 上でプライベートな Home Assistant 音声アシスタントを構築する
Rockchip RK3576 上でプライベートかつローカル実行できる Home Assistant 音声アシスタントを構築します。Whisper による音声認識、Piper による音声合成、openWakeWord によるウェイクワード検出、Qwen によるローカル会話を組み合わせ、RK3576 の NPU で高速化します。
RK3576 上でプライベートな Home Assistant 音声アシスタントを構築する
Home Assistant Assist は、単なるクラウド連携の音声インターフェイスにとどまりません。Rockchip RK3576 を使えば、音声認識、ウェイクワード検出、言語モデルによる推論、音声合成まで、音声の一連の流れをローカルで実行できます。
このプロジェクトでは、その仕組みを Docker Compose スタックとしてまとめました。Whisper、Piper、openWakeWord、Qwen を組み合わせ、RK3576 の NPU で主要な AI 処理を高速化します。
1. クイックスタート
必要なもの
- Linux ARM64 で動作する Rockchip RK3576 ボード
- Docker Engine と Docker Compose プラグイン
/dev/rknpuと/dev/dma_heapを含む RK3576 のデバイスノードへのアクセス- 同じネットワーク上の Home Assistant インスタンス、またはボード上で Home Assistant を動かせる十分なリソース
RK3576 ボード上でプロジェクトをクローンします。
git clone https://github.com/Hanzo-Huang/rk3576-home-assistant-voice.git
cd rk3576-home-assistant-voice音声サービスを起動します。
sudo docker compose up -d --pull alwaysHome Assistant も同じボード上で動かしたい場合は、オプションのプロファイルを使います。
sudo docker compose --profile homeassistant up -d --pull always動作中のコンテナとログを確認します。
sudo docker compose ps
sudo docker compose logs -f2. アーキテクチャ
このスタックでは、音声対話の各段階をそれぞれ独立したサービスとして分けています。Home Assistant は Wyoming プロトコル経由で音声サービスと通信し、OpenAI 互換 API を通じてローカルの言語モデルと接続します。
ユーザー
│ 音声入力
▼
Home Assistant Assist
│ 音声
▼
openWakeWord ── 起動 ──▶ Whisper STT
│ 文字起こし
▼
Qwen 2.5 ローカル LLM
│ 応答テキスト
▼
Piper TTS
│ 音声応答
▼
Home Assistant Assist
│
▼
ユーザー
Whisper STT、Qwen 2.5、Piper TTS は RK3576 の NPU で加速されます。各サービスは次のポートで公開されます。
| サービス | 機能 | ポート |
|---|---|---|
| Piper | テキスト読み上げ | 10200 |
| Whisper | 音声認識 | 10300 |
| openWakeWord | ウェイクワード検出 | 10400 |
| RKLLM API | OpenAI 互換のローカル LLM API | 8001 |
デフォルトの言語モデルは、W4A16 量子化を採用した Qwen2.5-1.5B-Instruct です。RKLLM サービスはこれを Home Assistant から利用できるローカル会話エージェントとして提供し、音声リクエストを外部プロバイダーに送ることなく処理できるようにします。
3. パフォーマンス
テスト済みの構成は次のとおりです。
- 音声認識に Whisper
- 会話に Qwen2.5-1.5B-Instruct
- 音声合成に Piper Amy Medium
RK3576 の NPU で加速したモデルを使った場合、測定されたレイテンシは次のとおりです。
| ステージ | 時間 |
|---|---|
| Whisper 文字起こし | 0.626 s |
| LLM 応答 | 2.82 s |
| Piper 合成 | 0.474 s |
エンドツーエンドの応答時間は、話された内容の長さ、生成される回答の長さ、そして Home Assistant 自体の処理時間によって変わります。とはいえ、RK3576 はエッジ環境で応答性の高いプライベートな音声アシスタントを実現する、実用的な基盤です。
1.5B モデルはおよそ 1.5 GB の RAM を使います。テスト済みの 3B W4A16 モデルはおよそ 2.5 GB の RAM を必要とし、より大きなモデルを選ぶ際にはメモリ容量をしっかり見ておく必要があります。
4. セットアップガイド
Wyoming サービスを追加する
Home Assistant で 設定 → デバイスとサービス を開き、統合の追加 を選択して Wyoming Protocol を検索します。
RK3576 ボードの IP アドレスをホストとして使い、次のサービスを追加します。
| サービス | ポート |
|---|---|
| Whisper STT | 10300 |
| Piper TTS | 10200 |
| openWakeWord | 10400 |
Assist パイプラインを作る
設定 → 音声アシスタント を開き、Assist パイプラインを作成または編集します。次を選択します。
- 音声認識用の Wyoming Whisper サービス
- 音声合成用の Wyoming Piper サービス
- ウェイクワード検出用の Wyoming openWakeWord サービス
ローカル会話エージェントを設定する
Qwen を会話エージェントとして使うには、HACS から Local LLM integration をインストールします。次の値で設定してください。
Backend: OpenAI Compatible Conversations API
API hostname: RK3576_BOARD_IP
API port: 8001
API path: /v1
API key: sk-local
Model name: rkllm-modelAPI キーは、このローカルサーバー向けのプレースホルダーです。統合を追加したら、Assist パイプラインに戻って、新しいローカル会話エージェントを選択してください。
別の LLM を選ぶ
LLM は Docker イメージとして提供されているため、Home Assistant の設定を変えずにモデルを差し替えられます。デフォルトイメージは次のとおりです。
image: ghcr.io/hanzo-huang/rkllm-docker/qwen2.5-1.5b-instruct:w4a16-rk3576別のモデルを使うには、rkllm-docker リポジトリ から RK3576 互換のイメージを選び、docker-compose.yml の llm.image の値を置き換えます。
llm:
image: <rkllm-docker-model-image>その後、スタックを再起動します。
sudo docker compose up -d利用可能なモデルによって、RAM 要件、応答品質、レイテンシが異なります。より大きなモデルを選ぶ前に、必ずモデルのドキュメントを確認してください。
ウェイクワードをカスタマイズする
デフォルトのウェイクワードモデルは ok_nabu です。docker-compose.yml の openwakeword コマンドを変更して、別の対応モデルをプリロードできます。
command:
- --uri
- tcp://0.0.0.0:10400
- --preload-model
- ok_nabuWhisper の言語を変更する
Whisper イメージには英語と中国語向けの語彙が含まれています。英語がデフォルトですが、docker-compose.yml の Whisper サービスコマンドに --language zh を追加することで中国語を選択できます。
5. 改善案:より多くのモデルを追加する
現在の構成では、品質・メモリ使用量・レイテンシのバランスを取るためにコンパクトなモデルを使っています。次の自然な一歩は、音声パイプライン全体でさらに多くのモデルを扱えるようにすることです。対象は、言語モデル、STT モデル、TTS 音声です。
LLM モデルを増やす
LLM イメージは docker-compose.yml で変更できます。たとえば、デフォルトイメージを次のように置き換えます。
image: ghcr.io/hanzo-huang/rkllm-docker/qwen2.5-1.5b-instruct:w4a16-rk3576別の rkllm-docker リポジトリ のイメージに差し替えたうえで、スタックを再起動します。
sudo docker compose up -dSTT モデルを増やす
現在は Whisper を音声認識に使用しています。Whisper サービスは、より多くのモデルサイズ、言語、RKNN 変換済みのエンコーダー/デコーダー対をサポートするよう拡張できます。小さいモデルでレイテンシを抑えることも、大きいモデルで認識精度を高めることも可能です。
STT の対応範囲には次のような項目が含まれるべきです。
- 英語、中国語、その他言語の語彙
- 複数の Whisper モデルサイズ
docker-compose.ymlでのモデル別設定- 文字起こし精度、メモリ使用量、リアルタイム係数のベンチマーク
TTS モデルと音声を増やす
現在は Piper Amy Medium を使用しています。TTS イメージにさらに多くの Piper 音声を同梱すれば、言語、アクセント、話し方の異なる音声を選べるようになります。RKNN 対応のデコーダーモデルを追加して、RK3576 の NPU をより多くの音声構成で活用することもできます。
TTS の対応範囲には次のような項目が含まれます。
- 複数の Piper 音声と言語
- Compose 設定または Home Assistant からの音声選択
- 品質と速度の異なるプロファイル
- より高速な再生のためのストリーミングと短い音声チャンク
その他の改善
今後の改善としては、次のようなものも考えられます。
- 各サービスに対するシンプルなモデル選択変数
- モデルの組み合わせごとのパイプライン全体のベンチマーク
- 体感応答時間を短くする LLM ストリーミング応答
- カスタムウェイクワードモデルのサポート
- RAM 容量ごとの推奨モデル組み合わせの文書化
より大きなモデルは会話品質を向上させますが、より多くの RAM を必要とし、レイテンシも増える可能性があります。最適なモデルは、ボードの性能と家庭で求める体験のバランスで決めるのがよいでしょう。
結論
このプロジェクトは、現代的な Home Assistant 音声アシスタントがクラウドに依存しなくてもよいことを示しています。オープンソースの音声モデル、Docker、Wyoming プロトコル、RK3576 の NPU 加速を組み合わせることで、コンパクトなエッジデバイス上で音声インタラクション全体をローカル実行できます。
その結果、Home Assistant と緊密に統合され、しかもプライバシー保護やカスタマイズ性に優れた音声インターフェイスを実現できる一方で、将来的により高速で大規模なモデルにも自然に拡張できます。