小智自建后端怎么选：四个开源实现的差别和配置要求

小智默认可以接官方服务器，注册账号就能用。那为什么还有人要自建？

常见的理由有几个：数据不想过别人的服务器、想换成自己的大模型和 TTS、要做产品得掌握后端、纯粹想搞明白这条链路怎么跑的。

这些理由都成立。但自建不是免费的——它把"用别人的服务"换成了"自己运维一套服务"。这篇先帮你判断该不该建、建哪个，再讲要准备什么。

上游列出的四个实现

按小智上游 README 提到的社区服务端项目：

项目	语言
xinnan-tech/xiaozhi-esp32-server	Python
joey-zhou/xiaozhi-esp32-server-java	Java
AnimeAIChat/xiaozhi-server-go	Golang
hackers365/xiaozhi-esp32-server-golang	Golang

四个，两个是 Go。选哪个，最实际的判断标准是"你能改动哪个"——服务端你是要长期维护的，选一个你熟悉的语言，比选一个功能列表更长但你看不懂的强得多。

如果你没有语言偏好、只想找资料最好找的，Python 那个（xinnan-tech）在社区里讨论度最高，文档也相对完整，下面的配置数据就以它为例。Java 那个（joey-zhou）走的是企业级管理平台路线，把设备监控、音色定制、角色切换、对话记录管理做成了前后端一体的方案——如果你要管的是一批设备而不是一台，这个定位更对路。

两种安装方式，先选对

以 Python 版为例，它提供两种安装方式，差别不只是"装多装少"：

最简化安装 —— 智能对话、单体管理，数据存在配置文件里。 配置要求：全 API 方案约 2 核 2G；如果要跑本地语音识别（FunASR），2 核 4G。

全模块安装 —— 多用户 / 多智能体管理、Web 控制台、数据存数据库。 配置要求：全 API 方案约 2 核 4G；含本地语音识别方案 4 核 8G。

怎么选：

• 只是自己玩、一台设备、想快点跑通 → 最简化。改配置文件虽然原始，但少一层数据库和控制台，出问题好查得多。
• 要管多个设备/多个角色，或者要给别人用 → 全模块。控制台省下的手工操作，很快就能把多出来的配置成本赚回来。

注意"全 API"和"本地"这个变量，它对配置要求的影响比安装方式本身还大：本地跑语音识别（FunASR 这类）能省 API 费用、数据不出门，代价是内存和 CPU 要求翻倍。4 核 8G 已经不是随便一台旧笔记本能舒服跑的了。

部署方式上，Docker 和本地源码两种都支持。没有特殊需求就用 Docker——自建服务端的依赖不算简单，Docker 能省掉一大堆环境问题。

自建之后，你还要接什么

这是最容易被低估的部分。"自建服务端"不等于"什么都自己跑"，服务端更像一个调度中枢，真正干活的几个模型你还得挑：

ASR（语音识别） —— 可以本地跑 FunASR、SherpaASR，也可以调火山、讯飞、腾讯等 API。 LLM（大模型） —— 支持阿里百炼、火山引擎、DeepSeek、智谱、Gemini 等符合 OpenAI 接口的平台。 TTS（语音合成） —— 有 EdgeTTS 这类免费平台，也可以接火山、讯飞等商业服务。 VLLM（视觉模型） —— 阿里百炼、智谱 ChatGLM 等支持 OpenAI 接口的服务。

也就是说：自建服务端解决的是"链路归我控制"，不是"不用花钱"。 除非 ASR/TTS 全用本地或免费方案，否则你只是把账单从一处换到了另几处。

还有一点要说清楚：这类开源项目通常会声明与第三方 API 服务商没有商业合作关系，密钥要你自己配。所以选型时把各家 API 的价格、限流、备案要求一起考虑进去，别只看功能表。

设备怎么知道要连你的服务器

这是自建里最容易卡住的一环，也是文档里往往一笔带过的地方：服务端跑起来了，设备却还在连官方的。

要理解的是：服务端地址是设备侧的配置，服务端自己跑得再好，设备不知道去哪找它也没用。所以自建的完整工作量其实是两半——把服务端跑起来，再把设备指过去，很多人只做了前一半。

指过去之后，连不上的常见原因有这么几类，按出现频率排：

一、地址或端口不对。 最基础但也最常见。注意区分局域网地址和公网地址——你在本机浏览器能打开控制台，不代表设备能连上：设备走的是另一条网络路径。

二、设备和服务器不在同一个网络里。 服务端跑在你电脑上、设备连的是手机热点，这就通不了。自建初期先让两者在同一个局域网，把变量降到最少。

三、防火墙 / 端口没放行。 服务端起来了，端口没对外开放。Docker 部署时还要确认端口映射有没有配对。

四、协议对不上。 小智支持 WebSocket 和 MQTT+UDP 等不同传输方式，设备侧和服务端侧得说同一种。

排查这一段有个很省事的办法：先在电脑上用工具连一下你的服务端，确认服务本身是通的。通了再查设备侧——这样就把"服务端有问题"和"设备连不上"这两件事分开了，不用两头猜。

自建之前，先问自己三个问题

一、我现在跑通过官方那条路吗？ 如果没有，先用官方服务器把设备跑通。理由很简单：设备侧和服务端侧的问题混在一起排查，难度是叠乘的。先用官方服务器确认"我的板子是好的、固件是对的"，再换服务端，这时候出问题你就知道是新引入的那一半。这一步能省下的时间，比自建本身花的时间还多。

二、我要的是隐私、可控，还是省钱？

• 图隐私 → 那 ASR/TTS 也得尽量本地，配置要求直接上到 4 核 8G 那一档；
• 图可控（换模型、改逻辑、接自己的业务）→ 那全 API 方案就够，配置要求低得多；
• 图省钱 → 先算笔账。一台常年开着的服务器 + 各家 API，未必比官方方案便宜。省钱通常不是自建的好理由。

三、这台服务器谁来管？ 自建意味着你要管更新、管故障、管备份。设备在你手上不响的时候，你得知道是设备的问题还是你服务器的问题——这是自建之后新增的一整类排查工作，也是很多人自建后又退回官方的原因。

小结

自建服务端是条好路，但它的价值在可控，不在省事也不在省钱。

建议的推进顺序是：官方服务器跑通 → 想清楚自建要解决什么 → 选一个你能读懂的语言的实现 → 用 Docker 最简化装一遍跑通 → 再按需要升级到全模块和本地模型。

一上来就冲 4 核 8G 全本地全模块，是自建失败率最高的走法。

相关：小智自建后端 xiaozhi-server讲部署实操，小智怎么把语音送上云讲设备和服务端之间的传输协议，小智怎么换音色和人设讲自建之后音色人设怎么配。