在 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 插件
对 RK3576 设备节点的访问权限，包括 /dev/rknpu 和 /dev/dma_heap
同一局域网中的 Home Assistant 实例，或者有足够资源能够直接在开发板上运行 Home Assistant

在 RK3576 开发板上克隆这个项目：

bash

git clone https://github.com/Hanzo-Huang/rk3576-home-assistant-voice.git
cd rk3576-home-assistant-voice

启动语音服务：

bash

sudo docker compose up -d --pull always

如果希望 Home Assistant 也运行在同一块开发板上，可以启用可选配置文件：

bash

sudo docker compose --profile homeassistant up -d --pull always

检查正在运行的容器和日志：

bash

sudo docker compose ps
sudo docker compose logs -f

2. 系统架构

这套方案把语音交互流程拆成了多个独立服务。Home Assistant 通过 Wyoming 协议与语音服务通信，并通过与 OpenAI 兼容的 API 与本地语言模型进行交互。

Code

用户
  │ 语音输入
  ▼
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`

默认语言模型是 Qwen2.5-1.5B-Instruct，采用 W4A16 量化。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 的内存。测试过的 3B W4A16 模型大约需要 2.5 GB 内存，因此在选择更大模型时，内存容量是一个非常重要的考量因素。

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。然后按下面的方式配置：

text

Backend: OpenAI Compatible Conversations API
API hostname: RK3576_BOARD_IP
API port: 8001
API path: /v1
API key: sk-local
Model name: rkllm-model

这里的 API key 只是这个本地服务的占位符。添加集成后，返回 Assist 流水线页面，并选择新的本地对话代理。

切换不同的 LLM

LLM 以 Docker 镜像的形式提供，因此用户可以在不修改 Home Assistant 配置的情况下更换模型。默认镜像如下：

yaml

image: ghcr.io/hanzo-huang/rkllm-docker/qwen2.5-1.5b-instruct:w4a16-rk3576

若要使用其他模型，可以从 rkllm-docker 仓库中挑选一个与 RK3576 兼容的镜像，然后替换 docker-compose.yml 中的 llm.image：

yaml

llm:
  image: <rkllm-docker-model-image>

随后再次运行上面的命令：

bash

sudo docker compose up -d

不同模型的内存占用、回答质量和延迟表现可能并不相同。在选择更大的模型之前，建议先查看对应模型的文档说明。

自定义唤醒词

默认的唤醒词模型是 ok_nabu。如果你想预加载其他支持的模型，可以在 docker-compose.yml 中修改 openwakeword 的命令：

yaml

command:
  - --uri
  - tcp://0.0.0.0:10400
  - --preload-model
  - ok_nabu

更改 Whisper 语言

Whisper 镜像内置了英文和中文词表。默认使用英文；如果想切换为中文，可以在 docker-compose.yml 的 Whisper 服务命令中添加 --language zh。

5. 进一步改进：支持更多模型

当前这套方案使用的是较精简的模型，目的是在回答质量、内存占用和延迟之间取得一个平衡。接下来很自然的一步，是把支持范围扩展到整条语音链路里的更多模型：语言模型、语音转文本模型，以及文本转语音的声音。

添加更多 LLM 模型

LLM 镜像可以直接在 docker-compose.yml 中替换。例如，把默认镜像：

yaml

image: ghcr.io/hanzo-huang/rkllm-docker/qwen2.5-1.5b-instruct:w4a16-rk3576

替换为 rkllm-docker 仓库中的另一个镜像，然后再次运行 sudo docker compose up -d：

bash

sudo docker compose up -d

添加更多 STT 模型

Whisper 目前用于语音识别。Whisper 服务可以继续扩展，支持更多模型尺寸、更多语言，以及转换成 RKNN 的编码器/解码器组合。这样一来，用户可以选择更小的模型来降低延迟，也可以选择更大的模型来提升转写准确率。

STT 支持最好包括：

英文、中文以及更多语言词表。
多种 Whisper 模型尺寸。
在 docker-compose.yml 中按模型进行配置。
转写准确率、内存占用和实时因子的基准测试。

添加更多 TTS 模型和声音

Piper 目前提供 Amy Medium 语音。可以把更多 Piper 声音打包进 TTS 镜像，让用户选择不同语言、口音和音色风格。也可以加入兼容 RKNN 的解码器模型，让 RK3576 的 NPU 支持更多语音配置。

TTS 支持最好包括：

多种 Piper 声音和语言。
通过 Compose 配置或 Home Assistant 进行语音选择。
不同的质量和速度配置。
流式输出和更短的音频片段，以便更快播放。

其他改进

未来还可以继续完善的方向包括：

为每个服务提供一个简单的模型选择变量。
针对不同模型组合做整条语音链路的基准测试。
增加 LLM 的流式响应，减少用户感知到的等待时间。
支持自定义唤醒词模型。
记录不同 RAM 容量下推荐的模型组合。

更大的模型通常能提升对话质量，但也会占用更多内存，并可能带来更高延迟。因此，最佳选择往往是在开发板性能和实际使用体验之间找到平衡。

结论

这个项目证明，现代化的 Home Assistant 语音助手并不一定必须依赖云端。通过把 Whisper、Piper、openWakeWord、Qwen 和 RK3576 的 NPU 组合起来，整个交互流程可以在一台紧凑的边缘设备上本地完成。

其结果是一个更加私密、可定制，并且与 Home Assistant 深度集成的语音界面，同时也为后续尝试更快、更大、更强大的模型留下了空间。