AMD迷你主机+Home Assistant搭建本地AI语音助手全指南

从智能家居折腾的实际情况来看，很多人的第一台中控设备会选择树莓派，但真正用起来之后，往往会被性能上限、扩展接口和部署复杂程度卡住。后来我开始把目光放到 AMD 迷你主机上，配合 Home Assistant 搭建本地 AI 语音助手，整体体验比我预想中更稳。

这篇文章会把整套方案拆开讲清楚，从硬件选型、系统安装、Home Assistant 部署，再到本地语音识别、语音合成和大模型对话能力的接入，全部走一遍。无论你之前有没有接触过智能家居，只要愿意照着操作，都能在自己的迷你主机上跑出一套可用的本地 AI 语音助手。

1. 背景与核心概念

1.1 为什么选择 AMD 迷你主机作为智能家居中枢

先解释一下迷你主机是什么。它本质上是一台体积很小的 x86 台式机，通常采用笔记本内存、M.2 固态硬盘和低功耗处理器。相比树莓派这类 ARM 开发板，AMD 迷你主机的优势在于性能余量更大、内存可以上到 16GB 或 32GB、存储扩展更方便，而且很多型号本身就支持 7x24 小时不间断运行。

Home Assistant 是一个开源的家庭自动化平台，负责把各个品牌的智能设备统一接入到一个控制界面里。它本身对硬件要求不算高，但如果你打算在本地运行语音识别模型或大语言模型，那处理器性能和内存容量会直接决定体验。AMD 迷你主机的 CPU 多核性能普遍不弱，内置的核显在某些场景下还能辅助视频解码或推理加速，因此很适合作为本地智能中枢。

1.2 Home Assistant 与 AI 语音助手的关系

Home Assistant 对语音助手的支持已经形成了一套完整链路，官方称之为语音管道（Voice Pipeline）。简单来说，智能音箱接收到用户语音后，需要先经过“唤醒词检测—语音转文字—意图理解与对话生成—文字转语音—扬声器播放”这样几个环节。

传统智能音箱把录音上传到云端处理，Home Assistant 的不同之处在于它允许你把每个环节都放到本地执行。比如用 fast-whisper 做语音转文字，用 Piper 做语音合成，用 Ollama 跑本地大模型，这些服务全部可以运行在同一台 AMD 迷你主机上。

1.3 本地化 AI 语音助手的价值点

本地化方案最大的价值是可控和隐私。语音数据不经过第三方云端，家里的音频信息只停留在局域网里。另一个好处是不依赖外网，就算宽带断掉，基础的语音控制和设备开关仍然可以工作。

当然，本地化并不是没有代价。小模型在理解复杂指令时不如云端大模型聪明，本地部署也需要占用系统资源。但从实际使用来看，本地语音助手承担“关灯、调温度、查传感器状态”这类确定性指令已经非常够用，而且响应速度通常会比走云端的方案更快。

2. 环境准备与硬件选型

2.1 硬件清单与选型注意事项

本次方案不指定具体品牌和型号，重点说清楚选型时需要考虑的几个因素。

• CPU：建议 AMD Ryzen 5 或更高档次的处理器，核心数越多，同时跑 Home Assistant、语音识别模型和本地大模型时越从容。
• 内存：16GB 起步，如果打算运行 7B 级别的大语言模型，最好直接上 32GB。
• 存储：至少 512GB M.2 SSD。Home Assistant 的数据库日志会持续增长，语音识别模型和大模型文件也会占用不少空间。
• 网口：双千兆网口并不是必须，但如果你想让迷你主机兼任软路由，可以考虑带双网口的型号。
• 电源：尽量选择 DC 供电或自带外置电源适配器的型号，稳定性和功耗表现通常比杂牌电源更好。

如果手里已经有一台闲置的 AMD 笔记本或迷你主机，也不用刻意更换，先跑起来再根据瓶颈升级配件。

2.2 安装 Linux 系统或 Windows 的取舍

Home Assistant 官方推荐的操作系统是 Home Assistant OS，它可以直接烧录到 SSD 或 U 盘上启动。不过如果你想在同一台机器上同时运行其他服务，我更推荐先安装一个 Ubuntu Server LTS 或 Debian，再用 Docker 运行 Home Assistant。

也有人想在 Windows 上部署，这个思路可行但不太省心。Windows 系统对于 Home Assistant 的硬件直通和 Docker 支持都绕了一圈，尤其在使用 USB 蓝牙适配器或 Zigbee 网关时，可能会遇到驱动层面的兼容问题。因此，比较省事的方式是给 AMD 迷你主机装 Linux，把系统资源集中在智能家居服务上。

以 Ubuntu Server 24.04 LTS 为例，写系统到 U 盘后正常安装，分区时选择一个容量足够的 SSD 即可。网络建议配置静态 IP，这样后面访问 Home Assistant 和各个语音组件时不会因为 DHCP 变动而断连。

2.3 AMD 平台的驱动与硬件加速说明

AMD 平台在 Linux 下的驱动支持相当省心。只要 BIOS 保持默认 UEFI 设置，现代内核自带的 amdgpu 内核模块就能驱动绝大多数 AMD 集成显卡和独显。你不需要像 Windows 那样额外安装 AMD Software、Adrenalin 之类的驱动包。

有些用户在 Windows 下会遇到右键菜单出现 AMD Software 之类的条目，如果觉得碍事，可以通过卸载对应的 AMD 驱动组件或使用 AMD Cleanup Utility 来处理。在 Linux 下基本不用关心这个问题。

需要说明的是，Home Assistant 本身并不依赖 GPU 加速。STT 模型 fast-whisper 在纯 CPU 环境下用 int8 量化也已经可以跑得不错。至于 NPU（神经网络处理器）这类新特性，目前很多开源语音组件还没有针对 AMD NPU 做适配，暂时可以把它看作预留能力，不要指望开箱即用。

3. Home Assistant 的安装与基础配置

3.1 使用 Docker 部署 Home Assistant

安装好 Ubuntu 之后，先更新系统并安装必要软件。

上面的命令执行完成后，确认 Docker 已经正常运行。接着创建目录结构，我用的是 /opt/homeassistant 作为配置根目录。

Home Assistant 的官方容器镜像包含了完整的运行时环境，配置目录和媒体文件目录分别挂载到宿主机上。为了确保后面访问 USB 设备或音频设备不被权限卡住，可以通过 --device 参数把相关设备映射进容器，但这一步可以先不做，等用到对应的硬件时再补充。

下面是比较精简的启动方式：

运行一段时间后，打开浏览器访问 http://迷你主机IP:8123，就能看到 Home Assistant 的初始化页面。

3.2 配置挂载目录与容器网络

如果打算长期使用，我更建议写一个 docker-compose.yml，让服务定义更清晰。下面是常见的配置：

yaml复制version: "3.8"
services:
  homeassistant:
    container_name: homeassistant
    image: ghcr.io/home-assistant/home-assistant:stable
    network_mode: host
    restart: unless-stopped
    privileged: true
    volumes:
      - /opt/homeassistant/config:/config
      - /opt/homeassistant/media:/media
    environment:
      - TZ=Asia/Shanghai

使用 network_mode: host 主要是为了方便 Home Assistant 与其他语音服务在同一网络内直接通信，也能减少容器 NAT 带来的端口映射麻烦。privileged: true 是为了让容器可以访问宿主机上的 USB 设备、蓝牙设备等敏感硬件，代价是隔离性变弱，生产环境建议结合具体设备需求来权衡。

挂载目录的权限要提前设置好，避免 Home Assistant 容器因为 config 目录不可写而启动失败。

3.3 首次初始化与 Add-ons 说明

第一次打开 Home Assistant 页面时，会要求你创建管理员账号、设置家庭名称和所在时区。完成初始化后，系统会进入主界面。

Home Assistant 的集成系统支持两种扩展方式：一种是直接通过页面添加集成（Integration），另一种是安装 Add-ons。由于我们是 Docker 方式部署，没有使用官方提供的 Supervised 环境，部分 Add-ons 无法直接使用，但这并不影响核心功能。

我们需要的是通过 HACS（Home Assistant Community Store）来安装自定义组件。HACS 是社区维护的扩展商店，很多语音助手相关组件都在里面。安装 HACS 只需要在终端执行几条命令，把刚下载的文件放到 config/custom_components 目录并重启服务。

这里给一个命令思路：

bash复制cd /opt/homeassistant/config
mkdir -p custom_components
cd custom_components
# 下载 hacs 压缩包并解压到 hacs 目录

具体版本号和下载地址建议以 HACS 官方仓库说明为准，安装完成后回到 Home Assistant 的“设备与服务”里就能找到 HACS 入口。

4. 搭建本地 AI 语音助手核心组件

4.1 语音管道的组成与技术协议

在 Home Assistant 中配置语音管道之前，需要先理解几个角色。

• 唤醒词检测（Wake Word）：持续监听麦克风，只有在听到指定唤醒词时才触发后续识别流程。
• 语音转文字（Speech-to-Text，STT）：把用户说出的音频转换成文字，常用模型有 faster-whisper。
• 对话代理（Conversation Agent）：处理文字指令，可以调用 Home Assistant 的服务，也可以连接大模型进行自由对话。
• 文字转语音（Text-to-Speech，TTS）：把回复内容转换成语音，Piper 是社区常用的本地 TTS 引擎。

这些服务之间通过 Wyoming 协议进行通信。Wyoming 是一个简单、稳定的本地 WebSocket 协议，几乎所有主流语音组件都支持它。我们不需要手动实现协议，只要保证这些服务在局域网内可以被 Home Assistant 访问到就行。

4.2 部署 faster-whisper 本地语音识别

faster-whisper 是一个基于 CTranslate2 重构的 Whisper 推理引擎，相比原始 OpenAI Whisper，它在 CPU 上的速度更快、显存占用更低。社区提供了封装好的 Wyoming 服务镜像，可以直接用 Docker 部署。

下面是一个较小规模模型的部署示例：

bash复制docker run -d \
  --name faster-whisper \
  -p 10300:10300 \
  -v /opt/whisper:/data \
  --restart unless-stopped \
  rhasspy/wyoming-faster-whisper:latest \
  --model tiny-int8 \
  --language zh \
  --beam-size 1

参数说明：

• --model tiny-int8：选择模型规格。如果对中文识别准确率有更高要求，可以换成 small-int8 之类的模型，但耗时会增加。
• --language zh：限定识别语言为中文，可以减少搜索空间，提升准确率。
• --beam-size 1：降低解码搜索量，换得更快响应。

第一次启动时会自动从 Hugging Face 下载模型文件。如果你的网络不稳定，可以先用浏览器手动下载模型到指定目录，再启动容器。

4.3 部署 Piper 本地语音合成

Piper 是专门面向离线嵌入式场景的 TTS 引擎，声音清晰，模型体积小，非常适合在 AMD 迷你主机上运行。部署方式同样采用社区封装好的 Wyoming 容器：

bash复制docker run -d \
  --name piper \
  -p 10200:10200 \
  -v /opt/piper:/data \
  --restart unless-stopped \
  rhasspy/wyoming-piper:latest \
  --voice zh_CN-huayan-medium

这里 zh_CN-huayan-medium 是中文语音模型的名字。启动后，Piper 会在 10200 端口提供 TTS 能力。

如果你希望声音听起来更自然一些，可以找一个适合自己的语音模型文件，放进挂载目录后在启动参数里指定文件路径。不要一次性加载太多语音，模型文件读进内存后会占用不少空间。

4.4 部署 OpenWakeWord 唤醒词服务

唤醒词服务的作用是让麦克风保持低功耗监听，而不用一直对音频做全量识别。OpenWakeWord 是社区常用的开源唤醒词方案。

bash复制docker run -d \
  --name openwakeword \
  -p 10400:10400 \
  --restart unless-stopped \
  rhasspy/wyoming-openwakeword:latest \
  --preload-model ok_nabu

不同唤醒词模型的名称可以在 OpenWakeWord 的模型列表里查看。第一次使用建议先用官方默认模型，测试识别率之后再考虑训练自定义唤醒词。

这里还要提一个关键点：唤醒词服务需要访问麦克风采集音频数据。如果用 Docker 运行，需要把宿主机声卡设备映射进容器，并且确认用户对 /dev/snd 目录有读取权限。否则容器内部拿不到音频流，唤醒词服务会一直显示“等待音频”之类的状态。

4.5 在 Home Assistant 中装配语音管道

前面四个服务跑起来之后，进入 Home Assistant 页面，打开“设置—语音助手”，点击添加语音助手。页面里会要求你选择唤醒词引擎、语音转文字引擎、对话代理和语音合成引擎。这里直接选择你已经部署好的 Wyoming 服务即可。

如果没有自动发现这些服务，可以手动添加集成。集成类型选择 Wyoming，填入迷你主机的 IP 和对应端口。

完成装配后，你还需要在 Home Assistant 里准备一个可以接收语音消息的实体。比较常见的是买个 ESP32 开发板做成语音卫星，或者直接用带有麦克风和扬声器的树莓派做 Dev Container。如果你暂时没有语音硬件，也可以通过 Home Assistant 配套 App 在手机上测试，App 里自带的语音输入会直接走语音管道。

5. 接入本地大模型，让语音助手具备对话能力

5.1 Ollama 本地大模型部署

对话代理是语音助手的大脑。如果你不接入大模型，Home Assistant 只能执行有限的内置指令模板。接入大模型后，语音助手就能理解“帮我把客厅的灯调暗一点”这种自然语言指令，甚至可以进行简单的闲聊。

Ollama 是目前在本地跑大模型最方便的工具之一。它支持 AMD CPU 的推理，并提供和 OpenAI 兼容的 API 接口，可以很方便地和 Home Assistant 对接。

在 Ubuntu 下安装 Ollama 很简单：

bash复制curl -fsSL https://ollama.com/install.sh | sh

安装完成后，拉取一个适合 CPU 推理的中文模型：

bash复制ollama pull qwen2.5:7b-instruct

如果你的内存只有 16GB，可以先用 qwen2.5:3b-instruct 跑通流程。7B 参数模型在纯 CPU 环境下大约需要 8GB 内存，生成速度取决于 AMD 处理器的多核性能。

5.2 将 Ollama 配置为 Home Assistant 对话代理

新版 Home Assistant 支持 OpenAI 兼容的对话接口，Ollama 就提供了这样的接口，默认端口是 11434。

例如，在 Home Assistant 的“设备与服务”中，选择“添加集成”，找到与 OpenAI 或 Ollama 相关的自定义集成。如果没有现成的集成，也可以通过 HACS 安装 Community 提供的大模型对话集成。

对于通用配置，逻辑如下：

• API 地址填写：http://迷你主机IP:11434/v1
• 模型名称填写：qwen2.5:7b-instruct
• 对话代理名称：自定义一个名字，便于在语音助手里选择

配置完成后，回到语音助手的设置页，把对话代理切换到你刚添加的这个模型上。此时向语音助手提问，就会走“语音识别—大模型对话—语音合成”的全链路。

5.3 云端大模型 API 的备选思路

如果你不想本地跑大模型，或者希望语音助手在复杂对话上有更好表现，也可以在对话代理里接入云端大模型的 API。Home Assistant 官方集成直接支持 OpenAI 兼容的配置方式，很多大模型服务商都提供这类接口。

使用云端 API 的优点是响应速度快、理解能力强，缺点是语音内容需要发送到服务商服务器。如果家里只是日常使用，建议在对话代理里配置一个开关或权限策略，控制哪些设备可以被语音助手操作，避免一句“把所有门都锁了”造成意外。

6. 实测与性能观察

6.1 负载与内存占用观察

当 Home Assistant、faster-whisper、Piper、OpenWakeWord 和 Ollama 全部运行时，观察系统资源占用会发现几个现象。

• Home Assistant 本身占用不高，长期运行大约占用几百 MB 到 1GB 内存。
• faster-whisper 的 tiny-int8 模型在 CPU 模式下，一次识别大约需要 0.5 到 2 秒，内存占用不到 1GB。
• Piper TTS 模型很小，CPU 消耗也很低。
• Ollama 运行 7B 模型时，内存占用会达到 6GB 到 9GB，语音助手空闲时它会常驻内存。

如果内存紧张，可以限制 Ollama 的并发请求数，或者让 Ollama 在空闲一段时间后自动卸载模型。结合上面的情况，16GB 内存的 AMD 迷你主机刚好够用，32GB 会更宽松。

6.2 响应延迟与优化思路

测量完整链路后，典型的中文语音指令等待时间大致如下：唤醒词触发约 0.3 秒，STT 识别约 1 到 2 秒，大模型生成回复约 2 到 5 秒，TTS 合成约 0.5 秒。合计下来，从说完话到听到回复大约在 3 到 8 秒之间，属于可以接受但不算极致的水平。

想要缩短延迟，可以从几个方向入手：

• STT 模型从 tiny-int8 换到更小的 base-int8，但准确率会有所下降。
• Ollama 关闭多并发请求，集中算力处理当前指令。
• 给 Home Assistant 和语音组件设置各自独立的内存阈值，避免互相争抢。
• 使用 AMD 处理器自带的核显运行部分推理，不过目前的 Wyoming 组件对硬件加速支持还不完整，需要实验确认。

6.3 AMD NPU 在大模型场景中的现状

新的 AMD 处理器开始集成 NPU，理论上可以加速低功耗 AI 推理。但从目前社区支持来看，无论是 Ollama 还是 faster-whisper，默认都没有针对 AMD NPU 做适配。

如果你的迷你主机带有 NPU，可以把它当作一个未来可用的储备能力，现阶段不要依赖它。AMD 在 Windows 驱动里提供的 AMD NPU 相关驱动和工具，也主要服务于 Windows 侧的 AI 应用，Linux 生态还需要时间成熟。

7. 常见问题与排查思路

7.1 典型问题与解决对照表

7.2 音频与硬件访问的深层排查

如果你遇到音频相关的问题，需要先确认宿主机的音频设备在正常出声。在 Ubuntu 上执行 aplay -l 可以列出声卡设备列表，如果这里什么都看不到，说明系统本身就没有识别到声卡。

接着在容器创建时添加设备映射：

bash复制docker run -d \
  --device /dev/snd:/dev/snd \
  ...

然后进入容器执行 aplay -l 验证声卡是否可见。如果容器内不可见，检查是否为 AppArmor 或 SELinux 限制导致。多数情况下关掉 AppArmor 对容器的限制就能解决，但这会降低系统安全性，建议先确认你的使用场景可接受再操作。

8. 最佳实践与生产环境建议

8.1 存储与备份策略

Home Assistant 长期运行会产生大量历史记录，数据库文件会持续膨胀。建议打开“记录器”集成中的自动清理，或者定期手动清除老旧记录。更稳妥的做法是把数据库单独挂载到性能更好的 SSD 上，避免数据库读写影响系统整体性能。

备份方面，/opt/homeassistant/config 目录是整个智能家居的核心，里面保存了设备配置、自动化脚本和自定义组件。建议至少做到每天备份一次，备份时先暂停容器写入，再压缩配置目录。如果你有 NAS，把备份文件同步到 NAS 上会更放心。

8.2 安全与远程访问

无论是在本地还是远程使用，都必须给 Home Assistant 设置强密码，并开启两步验证。内网环境下虽然风险较低，但家庭网络里可能存在其他设备被入侵的情况，智能家居系统一定要当管理后台对待，而不是提供一个敞开的大门。

如果需要在外网访问智能家居，建议使用具备内置认证的反向代理方案，或者通过官方推荐的云服务，不要直接把 8123 端口映射到公网。那样做很容易被扫描工具盯上，轻则被爆破，重则设备被恶意接管。

8.3 模型选型与功耗控制

针对 AMD 迷你主机的功耗表现，本地 AI 服务的负载波动其实很大。Ollama 在生成回复时 CPU 可能长时间保持高频运行，整机功耗会明显上升。如果设备放在卧室等对噪音和温度敏感的环境，可以在 BIOS 中调整处理器 TDP，或者通过 cpupower 限制 CPU 频率，把性能优先切换成静音模式。

模型选择也建议按场景分层：简单设备控制用 Home Assistant 内置规则和模板就足够，需要复杂语义理解时再调用本地大模型，直接减少大模型的调用频率，功耗和使用体验都能得到优化。

8.4 维护与升级顺序

Home Assistant 的升级频率并不低，社区版本的迭代速度也比较快。升级前要先备份配置文件，然后查看升级公告，确认你使用的自定义组件是否兼容新版本，避免升级后 HACS 里的部分组件失效。

容器方式升级其实很干净，只需要拉取新镜像并重新创建容器。要注意的是，升级后如果遇到启动失败，可以先通过 Docker 切换到旧版本镜像，优先恢复可用性，再慢慢排查原因。

不要在数据未备份的情况下执行任何升级或配置变更。这条原则非常重要。

整套方案跑通之后，你会发现本地 AI 语音助手并不是一个遥不可及的玩具。AMD 迷你主机提供了足够性能，Home Assistant 负责把各种设备串联起来，Ollama 和 Wyoming 组件则带来了完整的语音交互链路。

如果你准备开始动手，我的建议是先跑通最小闭环：一台 AMD 迷你主机、一套 Home Assistant、一个 STT 服务、一个 TTS 服务、一个小模型对话代理。确认整条链路正常之后，再逐步加入唤醒词、语音卫星、自定义自动化等更复杂的功能。先稳定后扩展，排查成本会低很多。