如何使用 RK3576 将 Home Assistant 语音功能完全本地化

RK3576上的本地Home Assistant语音

云端语音助手在互联网中断、延迟增加或你开始疑惑每个指令的处理位置时，依然十分便捷。对于智能家居而言，“打开办公室的灯”应该感觉即时且私密。

我想要一个能够运行在本地网络上、并完成重要任务的Home Assistant语音助手。最终结果是一个Docker Compose配置，将Rockchip RK3576开发板转变为Assist的本地语音后端。

它集成了本地唤醒词检测、本地语音转文字、本地文字转语音以及一个小型本地大语言模型。Home Assistant 仍然支持常规集成。RK3576 板卡在后台负责处理加速的 AI 功能。

堆栈包含：

•openWakeWord 用于唤醒词检测

•语音转文字的低语

•Piper 语音转文字

•通过兼容 OpenAI 的 RKLLM API 访问 Qwen 2.5 1.5B

•Wyoming services for Home Assistant integration

•Docker Compose 的预构建 ARM64 容器

•RK3576 通过 Rockchip 的 NPU 栈实现加速

它做什么

设置完成后，语音交互感觉就像普通的 Home Assistant 语音助手一样。

你说唤醒词，Home Assistant 打开 Assist 管道。RK3576 上的 Whisper 将命令转录为语音。Home Assistant 处理意图，或向本地大语言模型发送会话请求。RK3576 上的 Piper 说出响应内容。

关键在于什么没有发生：Home Assistant 不需要了解 RKNN 模型、NPU 运行时、模型打包或针对特定板卡的音频处理。它与标准的 Wyoming 服务进行通信。

Docker Compose 堆栈暴露了四个本地服务：

•Piper 文本转语音在端口 10200

•在端口 10300 上进行 Whisper 语音转文字

•openWakeWord 在端口 10400

•RKLLM本地对话API，端口8001

我为何建造它

Home Assistant 已经拥有一个强大的本地语音生态系统，因此我不想替换其架构。我想要为它提供一个紧凑的本地后端，能够利用专为边缘推理设计的硬件来运行更重的AI工作负载。

RK3576 具有独特之处，它处于一个实用的中间位置。它体积小巧，可像家用电器一样使用，但内置了联发科 NPU，当模型正确准备后，能够有效加速真实模型的运行。

我的目标很简单：

•保持语音管道本地化

•在需要时使用 RK3576 加速器

•使用 Docker Compose 实现便捷的部署

•保持 Home Assistant 的硬件无关性

最后这一点决定了整个项目的实现方式。硬件特定的项目往往难以复现，因为每一层都了解太多关于电路板的信息。我想要的是相反的情况：Home Assistant 应该能够识别普通服务，而容器则负责处理 RK3576 的具体细节。

构建

总体而言，语音路径如下所示：

Wyoming是关键边界。它为Home Assistant提供了清晰的语音服务协议，也让这个项目有了一个隐藏杂乱部分的地方：RKNN执行、模型加载、硬件访问以及容器打包。

我并没有向Home Assistant介绍RK3576，而是围绕加速模型构建了兼容Wyoming的服务。这样以最佳方式让集成变得无趣。你只需在Home Assistant中添加这些服务，然后在Assist流程中选择它们，Home Assistant就会像处理其他本地的语音识别、语音合成和唤醒词提供程序一样来对待它们。

为何选择RK3576

这个项目并非试图在一块微小的电路板上构建一个云规模的助手，而是旨在实现本地智能家居控制和简短的本地对话。

这使得RK3576成为理想选择。其NPU可胜任AI工作负载，而该芯片板仍保持小巧、安静，并易于部署在网络中。默认的LLM为Qwen 2.5 1.5B，其规模设计有意适度。对于这种应用场景而言，可靠性和本地执行性能比拥有最大可能的模型更为重要。

RK3576 从工程角度来看也使该项目更具吸引力。在 NPU 上运行模型与在 ARM CPU 上运行通用的 Python 代码并不相同，模型格式、运行时环境、输入形状以及设备访问方式等细节都至关重要。挑战在于让这些细节从用户视角中消失。

部署与设置

完整的配置文件位于 GitHub 仓库中，包括 Docker Compose 文件、模型打包说明以及故障排除步骤。简要版本是：准备开发板，启动 Compose 堆栈，然后将本地服务添加到 Home Assistant 中。

预构建的ARM64镜像正是实现这一功能的关键。用户在尝试该项目之前，无需转换模型、在板上构建容器或手动整理大型模型文件。

1. 准备RK3576板

安装 Linux ARM64 镜像，将板子连接到网络，然后安装 Docker Engine 和 Docker Compose 插件。基于 RKNN 的容器需要访问 Rockchip 加速器，因此 Compose 文件为语音和大语言模型服务分配了所需的设备权限。

2. 克隆项目

3. 启动语音服务

如果 Home Assistant 已经在网路上的其他位置运行，请使用此路径。你应该能看到 Whisper、Piper、openWakeWord 和 RKLLM 的容器。

4. 可选：在同一块板上运行 Home Assistant

然后打开：

5.在 Home Assistant 中添加Wyoming的服务

在 Home Assistant 中，进入设置 → 设备与服务 → 添加集成 → Wyoming 协议，然后添加：

•语音转文字：RK3576主板IP：10300

•Piper 文本转语音：RK3576 板载 IP：10200

•openWakeWord: RK3576_BOARD_IP:10400

6. 创建辅助流水线

进入设置 → 语音助手，然后创建或编辑一个助手流程，并选择 RK3576 Whisper、Piper 和 openWakeWord 服务。

7. 添加本地LLM

通过 HACS 安装本地 LLM 集成，然后将其配置为与 OpenAI 兼容的端点：

在辅助流程中选择此对话代理。

8. 测试它

尝试以下命令：

•打开办公室的灯。

•“哪些灯亮了?”

•将台灯调至30%。

•现在几点了?

测试时查看日志：

表现

我还需要发布最终的基准数据，但以下是我会跟踪以实现实用 Home Assistant 语音体验的测量指标：

•低语转录：典型房间控制指令耗时0.626秒

•LLM响应：2.82秒。

•Piper合成：从文本响应到可播放音频仅需0.474秒

重要的工程目标不仅仅是原始的模型速度。整个系统需要具备响应感：唤醒词检测应迅速触发，转录不应阻塞辅助流程，语音合成也应尽早开始，以确保交互仍能保持对话般的自然感。

挑战

第一个挑战是“Whisper”。语音转文字在模型本身方面涉及大量实际的音频处理，而RK3576的路径又增加了另一层：模型需要在NPU上通过RKNN运行。服务必须接受普通的Home Assistant音频，将其预处理为加速模型所需的格式，并通过Wyoming返回文本转录结果。

Piper 的结构有所不同。文本处理和编码器可以保持与普通 Python 和 ONNX 流程相近，但解码器则通过 RKNN 运行。这要求对加速路径进行封装，以确保 Home Assistant 仍能接收到普通的流式音频，而不会看到任何模型特定的限制。

第三个挑战是界面设计。本可以轻松地只开发一个作为定制演示的版本，但那并不是目标。Wyoming 使项目在 Home Assistant 上看起来像是原生的，同时将 RK3576 特定的代码保留在容器内部。

打包与推断同样重要。大型模型文件不应直接包含在源代码树中，但如果每个用户都需要手动组装这些文件，这样的项目就毫无用处了。构建流程会下载发布版本的存档、验证校验和、准备资源，并生成ARM64镜像，供Docker Compose拉取使用。

我学到的东西

最实用的设计选择是保持边界严格。Home Assistant 仍作为整体协调者，RK3576 板卡提供本地 AI 服务，Wyoming 则在两者之间建立连接，同时不泄露硬件细节。

这种分离也让项目更容易进行更改。同一服务架构下，可以更换不同的RK3576兼容的Whisper模型、另一种Piper语音或不同的RKLLM图像，而用户界面的集成保持不变。

另一个教训是，包装是工程的一部分，而非事后考虑。一个能正常运行的原型很有趣。而使用预构建容器的Compose堆栈，是另一位开发者可以实际尝试的东西。

结果

RK3576 板卡可作为 Home Assistant 的本地语音后端：唤醒词、语音识别(STT)、文本转语音(TTS)以及本地对话均在边缘设备上运行，而 Home Assistant 仍继续使用标准的集成方式。

关键在于界面设计。Home Assistant 保持简洁且不依赖硬件，而 RK3576 则负责 Wyoming 服务背后的专用加速处理。这正是我所追求的平衡：一个感觉像是家庭一部分的语音助手，同时依然保持开放、本地化和可定制性。

本文编译自hackster.io