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

这次我们来看一个被问了非常多次的组合：AMD 迷你主机 + Home Assistant + 本地 AI 语音助手。家用智能家居场景里，树莓派的性能越来越紧张，旧笔记本功耗又偏高，AMD 迷你主机正好卡在性能和成本之间：接口够多、能吃 Linux/Windows/虚拟机，还能顺便跑本地语音管线。Home Assistant 又是开源智能家居平台里扩展性最强的一个，把两者放在一起，就能得到一套完全本地处理的语音控制中枢。

这篇文章不打算铺开讲智能家居概念，重点解决三个问题：这台机器的部署架构怎么选、语音助手组件怎么装、装完以后怎么验证和接入自动化。整体思路是“先看能不能跑、再看怎么用、最后看遇到问题怎么排”。无论你的 AMD 迷你主机是用于 Windows 虚拟机方案、HAOS 整盘安装方案，还是 Docker 方案，下面这套流程都可以直接对照执行。先说明一点：不同配置的 AMD 迷你主机在本地大模型推理上的表现差异很大，文中的资源占用观察方法、部署步骤和排查清单通用，具体的内存和 CPU 占用需要以自己的实际硬件为准。

1. 核心能力速览

先把这套方案的关键信息放在最前面，方便你判断它适不适合自己。

这套方案的优点不是某一项功能特别强，而是全部推理都在本地完成。语音命令不会上传到云端，对话内容也不会经过第三方语音助手服务器。代价是需要自己维护模型、接口和硬件资源。AMD 迷你主机在这里承担的角色比较纯粹：它既是 Home Assistant 的运行平台，也是本地语音和对话模型的推理平台。

2. 适用场景与使用边界

适合这套方案的人通常有这几个特征：家里已经有智能灯具、传感器或红外设备，想用语音控制又不希望每次都依赖云端语音助手；对“麦克风采集到的内容去哪了”比较在意；愿意花一个周末做部署调试，而不是买来即用。

它也解决不了所有问题。想把语音助手做得像手机上的 GPT 那样博学，本地 3B 到 8B 模型的能力是有限的。想要零维护、永远稳定的设备，这台迷你主机也做不到。它的价值在于把“语音控制”和“智能家居自动化”绑在一起：你说“打开客厅灯”，数据链路是麦克风音频到本地 STT，再到本地 LLM 解析意图，最后调用 HA 的开关服务，中间没有任何云端依赖。

使用边界必须提前讲清楚。Home Assistant 的 Assist 语音助手会采集房间声音，这部分音频数据无论是唤醒词引擎还是 STT 组件都会处理。如果你把它放在卧室或客厅，相当于在私人空间放置了常驻录音设备，家庭成员的隐私需要提前沟通。TTS 音色和参考音频也可能涉及声纹和版权：不要用未经授权的真人声音做音色克隆，不要用有版权的影视片段做 TTS 训练素材。涉及摄像头、人脸识别这类能力时，必须确认使用对象已同意，且用途合法。本地部署不等于可以随意突破版权和肖像边界，这一点不在技术层面，而是使用者的责任。

3. 硬件选择与部署环境准备

AMD 迷你主机做 Home Assistant 中枢，选型时可以重点关注四个指标：内存、网口、SSD 和虚拟化支持。HA 本身对 CPU 要求不高，但 AI 语音助手里的大模型推理很吃内存，尤其是 CPU 推理模式，模型权重和上下文都要放在内存里。16GB 内存是更稳妥的起步容量，有条件直接上 32GB。网口建议千兆以上，因为语音设备与 HA 之间经常需要传输音频和状态数据。SSD 建议至少 256GB，因为容器镜像、模型文件、TTS 音色和长期历史记录都会占用空间。

AMD 平台有一个需要提前确认的事项：虚拟化。如果你打算在 Windows 上通过 Hyper-V 或 VMware 运行 HAOS，需要在 BIOS 里打开 AMD 的 SVM Mode。很多 AMD 迷你主机出厂时默认关闭 SVM，直接导致虚拟机无法使用嵌套虚拟化。另外，在 Linux 主机上先确认 AMD 设备是否被系统正常枚举，这一步非常值得做。

bash复制# 在 Linux 主机上列出 AMD 相关 PCI 设备
# 如果这里完全看不到 AMD 条目，说明驱动或 PCI 枚举有问题，需要先解决
lspci | grep -i amd

准备阶段还需要规划网络。建议给迷你主机设置固定 IP，例如 192.168.1.100，避免路由器重启后 IP 变动导致语音组件连不上 HA。操作系统的选择会影响后续安装方式：保留 Windows 做日常使用就用虚拟机方案；专门跑智能家居直接刷 HAOS；喜欢 Docker 管理用 Debian/Ubuntu 更顺手。三套方案下面都会写到，你先决定系统方向，再往下走。

4. 安装 Home Assistant：Windows 虚拟机与 HAOS 方案

4.1 方案一：Windows + 虚拟机运行 HAOS

网上搜“windows 装 home assistant”的人很多，但需要注意一个事实：Home Assistant 官方并不推荐 Windows 原生运行。Windows 下最常见的做法是装虚拟机，然后在虚拟机里安装 HAOS 虚拟机镜像。这种方式的好处是不破坏原有系统，HA 配置、日志和备份都可以单独管理，适合迷你主机还需要承担日常办公任务的用户。

具体流程可以概括为：

1. 在 BIOS 中打开 SVM Mode，启用 AMD 虚拟化。
2. 下载 Home Assistant 官方提供的 HAOS 虚拟机磁盘镜像，格式通常是 qcow2 或 vmdk。
3. 在 VMware 或 Hyper-V 中新建虚拟机，分配至少 4GB 内存和 32GB 以上磁盘。
4. 把网络适配器设置为桥接模式，让虚拟机直接获取局域网 IP。
5. 启动虚拟机，等待 HAOS 完成初始化，浏览器访问 http://<主机IP>:8123。

这一步最容易踩的坑是网络模式。使用 NAT 模式时，HAOS 虽然能上网，但局域网内的语音设备、手机 App 无法直接发现它，mDNS 也会失效。桥接模式会好很多。Windows 上的 Hyper-V 默认创建虚拟交换机，实际使用中还需要把物理网卡绑定到外部交换机，建议先在 Hyper-V 管理器里确认虚拟交换机的类型再建虚拟机。

4.2 方案二：HAOS 整盘安装

如果你的 AMD 迷你主机打算全职做智能家居中枢，HAOS 整盘安装是最省心的方式。HAOS 是一个完整的操作系统镜像，自带 Docker 运行环境、Supervisor 管理服务和 Add-On 商店。把镜像写入 U 盘后启动安装程序，系统会自动写入硬盘，后续组件和附加组件都能通过网页界面安装。

HAOS 的启动速度、系统更新和备份体验都优于虚拟机方案，但它会把整个硬盘占掉，不再适合同时做 Windows 日常机。准备一台闲置的 AMD 迷你主机时，这个方案优先级最高。

4.3 方案三：Debian/Ubuntu + Docker

如果你已经有一台 Linux 主机，或者更习惯用 Docker 管理服务，可以直接在 Debian/Ubuntu 上运行 Home Assistant 容器。这种方式对学习和后续迁移来说更灵活，模型文件、配置目录和容器互不干扰。基础命令如下：

bash复制# 先创建配置目录，再用 host 网络模式启动 HA 容器
mkdir -p /opt/homeassistant/config

docker run -d \
  --name homeassistant \
  --restart=unless-stopped \
  --privileged \
  -e TZ=Asia/Shanghai \
  -v /opt/homeassistant/config:/config \
  --network host \
  ghcr.io/home-assistant/home-assistant:stable

需要注意，--network host 在 Docker Desktop 环境中并不完全支持。Windows 上如果通过 Docker Desktop 使用此命令，容器网络可能异常，建议优先选择虚拟机方案或直接使用 Linux 主机。容器创建完成后，查看日志确认 Home Assistant 是否成功启动：

bash复制docker logs -f homeassistant

当日志中出现 Home Assistant initialized in X.XXs 之类的信息，并能在 8123 端口打开页面后，说明 HA 核心安装完成。

5. 搭建本地 AI 语音助手：STT、TTS 与对话代理

Home Assistant 的 Assist 语音助手本质是一条音频处理链路。完整流程是：麦克风采集声音，唤醒词引擎判断是否有人呼叫，语音转文字引擎把音频变成文本，对话代理理解文本并返回回复内容，文字转语音引擎把回复朗读出来。拆开来看，四个环节对应四类组件：

这四个组件在 Home Assistant 里通常以 Add-On 或独立服务的方式运行。faster-whisper 是本地语音转文字组件，比原始 Whisper 推理速度更快，中英文识别效果都不错。Piper 是轻量级 TTS 引擎，支持多种语言和音色。openWakeWord 负责本地唤醒词检测，不需要连接到云端。语音组件的最大好处是它们都能在局域网内独立工作，离线可用。

在 HA 中安装这些组件，最方便的是通过“设置 → 加载项 → 加载项商店”安装，然后在“设置 → 语音助手”中新建一条语音助手管线。管线的作用是把唤醒、STT、对话代理、TTS 按顺序串起来。首次配置时先把 STT 和 TTS 都选上中文模型，再选择一个本地对话代理，然后保存管线。配置完成后，可以在 HA 前端点击语音按钮测试对话。

H 提示词这里需要理解一个关键概念：HA 的对话代理支持“OpenAI 兼容接口”，所以我们先用 Ollama 在本地提供 OpenAI 兼容 API，再把这个 API 地址填进 HA 的对话代理配置中。这条路径目前社区验证比较充分，模型替换也比较自由。

三个组件中最容易出问题的其实是 Wake Word 和 STT 的延迟。在 AMD 迷你主机 CPU 推理模式下，faster-whisper 对一小段中文语音的识别可能需要几百毫秒到几秒，如果模型较大，延迟会更明显。第一次测试不要把期望值拉满，先用短指令验证链路是否通，再逐步优化模型大小和推理参数。

6. 接入本地大模型：Ollama 与 OpenAI 兼容 API

如果对话代理不接本地大模型，Assist 语音助手就只会执行固定的内置指令，灵活性非常有限。接入本地大模型后，它才能理解“把客厅灯调暗一点”这类自然语言。这里推荐使用 Ollama 管理本地模型，它支持 CPU 和 GPU 推理，也提供 OpenAI 兼容接口，和 HA 的集成成本比较低。

先安装 Ollama。在 Ubuntu 上可以直接执行官方安装脚本，在 Windows 上也有安装包可选。为了避免每次手动启动，建议把 Ollama 注册成服务，并让它默认监听 127.0.0.1:11434。如果你把 Ollama 跑在另一台机器上，需要把监听地址改成局域网地址或通过反向代理转发，这一点会影响 HA 是否能正常连接。

bash复制# 拉取一个适合本地 CPU 推理的中文模型，首次拉取需要等待模型下载完成
ollama pull qwen2.5:3b

# 启动 Ollama 服务，端口保持默认 11434
ollama serve

Ollama 支持 OpenAI 兼容接口，验证方式非常简单。使用 curl 请求本地的 /v1/chat/completions，如果返回正常结果，说明接口通路没有问题。

bash复制curl http://127.0.0.1:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen2.5:3b",
    "messages": [
      {"role": "user", "content": "请用一句话提醒我关掉客厅灯"}
    ]
  }'

返回内容通常会包含 choices 数组和 message.content 字段。拿到这个结果后，再到 Home Assistant 的“设置 → 设备与服务 → 添加集成”中搜索 OpenAI Conversation 相关的集成，填写 API Base 为 http://127.0.0.1:11434/v1，API Key 可以填任意非空字符串，模型名填 qwen2.5:3b。保存后在语音助手管线里选择这个对话代理，本地对话链路就接上了。

模型选择上，3B 级别模型在 CPU 推理时速度尚可，内存占用相对可控；7B 到 8B 模型的理解能力更强，但内存和延迟都会明显上升。AMD 迷你主机没有独立显卡，核显共享系统内存，直接跑大模型并不现实。更稳妥的判断是先用 3B 模型跑通功能，确认内存足够后再尝试 8B 模型，逐步观察延迟和稳定性。

7. 语音助手功能测试与效果验证

安装完成不等于能用，更不等于好用。建议按照下面的顺序做一轮系统验证，每步都明确判断标准。

7.1 唤醒词测试

测试目的：确认麦克风到唤醒词引擎的链路是否正常。对着语音设备连续说几次唤醒词，观察 HA 日志中是否有唤醒成功的事件。如果没有任何反应，先检查麦克风权限、唤醒词引擎状态和音频输入设备。有些迷你主机内置麦克风阵列，声音采集效果比单麦克风好，但需要先在 ALSA 或 Windows 音频设置里确认默认输入设备正确。

7.2 中文语音转文字测试

测试目的：验证 faster-whisper 对中文命令的识别准确度。测试文本建议从短命令开始，例如“打开卧室灯”、“现在几点”、“播放音乐”。在 HA 语音助手调试界面可以看到识别出的文本内容。如果出现大量错字，可能是音频采样率不匹配或模型尺寸太小，可以换 small 或 medium 级别的 Whisper 模型，并确认音频输入通道是单声道 16kHz。

7.3 本地大模型对话测试

测试目的：确认 Ollama 和 HA 的 OpenAI 兼容接口可以正常返回内容。在语音调试界面输入“把客厅灯调暗到百分之三十”，观察对话代理是否正确解析出开灯意图和亮度参数。如果模型返回的内容是通用回答而不是具体设备操作，需要检查该模型是否具备工具调用能力，或者在 HA 的对话代理配置中启用工具调用选项。不同模型对工具调用的支持程度不同，优先选择明确支持 function calling 的模型。

7.4 TTS 播报测试

测试目的：验证 Piper 中文音色和语音返回链路。让对话代理回答一句完整中文，确认扬声器能正常播放。如果出现爆音或语速异常，检查 TTS 引擎采样率、音频输出设备以及模型音量设置。Piper 可以切换不同音色，建议预先试听 2 到 3 个中文音色，选择听感最自然的一个固定在管线里。

7.5 自动化联动测试

测试目的：验证语音助手最终能触发 HA 自动化。在 HA 中新建一个自动化，当某个语音设备收到“打开客厅灯”的意图时，调用 light.turn_on 服务。这是整套方案最有价值的测试，因为语音识别和对话都只是过程，真正改变用户体验的是自动化能否稳定执行。判断标准是：喊完指令后 5 到 10 秒内，灯的状态发生改变，同时语音助手作出回答。如果延迟过高，优先优化 STT 模型大小和对话代理模型大小，不要一上来就怀疑硬件。

8. 接口 API 与自动化批量调用

Home Assistant 本身是服务端，不只是网页面板。它提供 REST API 和 WebSocket API，语音助手、TTS、设备控制、场景触发都可以通过接口调用。这意味着你可以把这套语音助手的能力接入自己的脚本、网页或小程序，实现批量任务。

先看最基础的设备控制接口。使用长期访问令牌可以调用 HA 的 REST 服务接口：

bash复制curl -X POST \
  -H "Authorization: Bearer YOUR_LONG_LIVED_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"entity_id": "light.living_room"}' \
  http://192.168.1.100:8123/api/services/light/turn_on

YOUR_LONG_LIVED_TOKEN 需要在 HA 网页的“个人资料 → 安全 → 长期访问令牌”中生成。你可以把这类调用封装成函数，在外部脚本中根据语音意图或业务逻辑批量触发设备动作。注意，直接暴露 HA 的 8123 端口存在安全风险，接口服务应限制在局域网内使用，不要把默认 8123 端口直接映射到公网。

TTS 也可以批量调用。比如你要把一批文本转成语音文件，可以通过服务接口逐个调用 TTS 引擎。HA 的 tts.say 服务支持指定实体和消息内容，调用完成后实体播放语音。批量处理时建议增加延迟或队列，避免在同一时间大量请求挤占 CPU 和音频输出资源。

Python 是接入 HA API 最常用的语言，示例代码如下：

python复制import requests

HA_URL = "http://192.168.1.100:8123"
TOKEN = "your_long_lived_access_token"

def call_service(domain, service, entity_id):
    url = f"{HA_URL}/api/services/{domain}/{service}"
    headers = {"Authorization": f"Bearer {TOKEN}", "Content-Type": "application/json"}
    payload = {"entity_id": entity_id}
    response = requests.post(url, json=payload, headers=headers, timeout=10)
    return response.status_code, response.json()

status_code, result = call_service("light", "turn_on", "light.living_room")
print(status_code, result)

批量任务设计时，建议把“输入文本列表”“调用 TTS 生成音频”“播放音频”“记录执行结果”拆成四个阶段，每阶段写日志。批量场景下最容易出现的问题是内存持续增长和接口超时，脚本里需要增加超时控制、失败重试和异常捕获。一次批量任务结束后，清理临时音频文件，避免长时间运行把系统盘写满。

9. 资源占用与性能观察方法

AMD 迷你主机跑这套方案时，资源占用主要集中在三个环节：Home Assistant 常驻进程、faster-whisper 的语音识别负载、Ollama 的大模型推理负载。HA 本身是很轻的应用，内存占用主要取决于集成的数量和长期历史记录；更值得关注的是语音识别和大模型推理这两个峰值负载场景。

观察方法非常简单。Linux 下使用 top、free -h 查看 CPU 和内存，Windows 下直接打开任务管理器。Ollama 加载模型后，它的进程内存会明显增加，CPU 占用在首次推理时跳到接近满载很常见。如果你在 HA 中频繁调用语音识别，faster-whisper 的 Python 进程也会成为 CPU 占用大户。

AMD 迷你主机的核显共享系统内存，所以“显存”并不是一个独立指标。在 Linux 下可以用 radeontop 查看核显负载，也可以用 rocm-smi 查看设备信息。部分新一代 AMD 处理器带有 NPU，本地大模型理论上有机会利用 NPU 加速，但目前在 Home Assistant 语音管线中，NPU 的支持还处于早期阶段，大多数组件仍以 CPU 推理为主。想确认 NPU 是否被系统识别，可以用前面提到的 lspci | grep -i amd 检查设备列表，但识别成功不表示模型运行时会自动使用它。

降低资源占用有几种实际可操作的手段。第一，优先选择 3B 级别的对话模型，而不是盲目上 8B。第二，在 faster-whisper 中控制推理的最大并发数，避免多设备同时触发语音识别。第三，HA 的启动流量是短暂的，但要防止自动化在短时间循环触发服务，导致 CPU 长时间处于高负载。第四，Ollama 可以通过环境变量控制模型在内存中的常驻策略，必要时减少同时加载的模型数量。性能优化没有标准答案，需要根据实际模型版本和本机配置逐步试出来。

10. 常见问题与排查方法

以下是部署过程中最容易遇到的情况，按“现象 → 原因 → 排查方式 → 解决方案”的方式整理成表。

上述问题里，最容易被忽略的是“Windows 装 home assistant”方案的网络模式。很多教程在虚拟机上把网络设置成 NAT 后，HA 能上网，但所有局域网设备都找不到它。如果语音设备、手机 App、HA 页面之间链路不通，先不要急着折腾各种组件，回到虚拟机网络设置和路由器里检查 IP 网段是否一致。

另外一个典型问题是 AMD 平台的全套驱动和硬件识别。Windows 下出现 CPU 频率异常或核显无法正常工作，需要在设备管理器确认 AMD Chipset 驱动和显卡驱动已安装；Linux 下则检查 lspci 是否列出了 AMD 设备。这类问题不解决，下一步的语音推理性能会受到明显影响。

11. 最佳实践与安全合规建议

从零到一把这套语音助手跑起来之后，建议按下面几条工程化规范收尾。

第一，备份优先。Home Assistant 的配置文件、自动化、语音助手管线都集中在 config 目录里。无论使用虚拟机还是 Docker，定期导出备份文件非常关键。HAOS 自带备份功能，Docker 方案可以直接压缩 config 目录备份。

第二，第一次验证用最小配置。不要一上来就同时接十几个设备、安装五六个语音组件。先把“一个语音设备 + 一个 STT + 一个 TTS + 一个本地模型”跑通，再逐渐添加自动化。小配置能快速定位问题，而复杂配置会让每一个报错都变得很难追溯。

第三，模型文件和输入输出素材分目录管理。Ollama 下载的模型、TTS 音色文件、用户上传的参考音频、测试生成结果建议分开存放，避免混在一起。模型文件可以被重新下载，但你的家庭语音记录和自定义自动化脚本需要单独保护。

第四，接口服务访问范围要控制。HA 的 8123 端口和 Ollama 的 11434 端口都只应该在可信局域网内访问。如果要在公网使用，必须先配置带 HTTPS 的反向代理和身份认证。语音设备长期在线，麦克风采集属于敏感数据，接口匿名访问必须禁用。

第五，涉及人脸、声音、版权素材时必须确认授权。本地 TTS 音色如果来自真人声音，需要确认声音所有者同意使用；唤醒词如果用了特定语音或影视片段，要注意版权边界。商用项目还需要更加谨慎。这不仅是技术问题，也是合规底线。

第六，批量任务要加日志和失败重试。语音服务的批量调用不是一次 for 循环就能保证稳定，每一轮请求都可能因为资源不足、模型未加载或端口抖动而失败。写脚本时给每次调用打时间戳和状态码，失败后稍等重试，连续失败则终止任务并输出日志。

12. 总结：这台迷你主机的下一步玩法

这套 AMD 迷你主机 + Home Assistant + 本地 AI 语音助手的方案，最值得尝试的点是把语音链路和自动化链路完全本地化。你不需要依赖某一家云语音平台，不需要为每一次语音命令上传音频文件，也不需要考虑语音服务突然停止服务的问题。部署完之后，最先应该验证的功能不是花哨的对话能力，而是那句最简单的“打开客厅灯”——这条链路跑通之后，其他功能都能基于同样的架构扩展。

最容易踩的坑基本集中在这三处：Windows 虚拟机方案中忘记打开 AMD SVM Mode，语音设备与 HA 不在同一网段导致 mDNS 发现失败，以及盲目上大模型导致内存和延迟双失控。把这三点提前处理好，后面安装组件和配置管线会顺利很多。

后续可以继续扩展的方向很多：在 HA 的仪表盘上加入房间状态卡片；给不同房间配置独立的语音卫星设备；把本地视觉模型接入摄像头，实现“谁回家了”的本地识别；或者把文本对话服务接到自己的内部工具上，用 REST API 和 WebSocket 把智能家居中枢变成家庭自动化平台。这套部署的价值不在于某一个组件，而在于把分散的开源工具整合成一套可复现、可替换、可维护的本地服务。建议把这篇文章收藏，部署的时候按章节顺序逐项验证，先从最小配置开始，再逐步加设备、加模型、加自动化。