Esp32Robot入门04-服务端架构与本地Docker拉起实战进阶手把手教你用Docker部署小智助手服务端 文章简介在AI智能硬件开发中ESP32-S3因高性价比备受青睐但面对千亿参数的本地大模型与高负载的ASR/TTS语音服务其几百KB的片上内存和有限的算力显得捉襟见肘。如何让小巧的ESP32拥有“超强脑容量”答案就是局域网网关服务端架构本文将带你深度剖析开源小智语音助手xiaozhi-esp32服务端的信令与音频流通道划分使用 Mermaid 绘制高大上的系统时序图并手把手教你利用 Docker Compose 在本地Windows/macOS一键拉起服务端网关。针对开发者最常踩的“Docker 容器网络隔离”、“Ollama 局域网访问失败”以及“WebRTC 端口映射导致 iptables 崩溃”等宿主机网络痛点进行无保留的硬核避坑分享。读完本文你将成功打通硬件到服务端的“任督二脉”为后续接入本地大模型奠定坚实基础一、前言硬件资源极度有限如何让 ESP32 拥有“千亿级脑容量”ESP32-S3 是一块非常优秀的 SoC。它搭载 Xtensa® 双核 32 位 LX7 微处理器主频高达 240MHz支持 Wi-Fi 与蓝牙 5.0在智能家居、传感器采集、低功耗物联网设备中几乎打遍天下无敌手。然而在“生成式大语言模型LLM”与“实时语音交互Voice Chat”的浪潮下ESP32 遇到了前所未有的物理瓶颈内存SRAM饥饿ESP32-S3 只有 512KB SRAM。即使是带了 8MB PSRAM外部伪静态随机存储器的开发板在面对 HTTPS 握手需要几十KB的SSL上下文缓存、复杂的 JSON 解析、以及 Opus 音频编解码时PSRAM 也会被迅速占满稍有不慎就会触发Out of Memory (OOM)导致硬件频繁重启。算力限制本地运行 ASR自动语音识别与 TTS语音合成哪怕是最小的模型如 Whisper-Tiny也需要几百MB的内存和强大的 GPU/NPU 支持这在 ESP32 上是物理性不可能实现的。直连云端的痛点有些开发者尝试让 ESP32 直连 OpenAI、火山引擎或阿里百炼的 API。虽然可行但存在以下硬伤握手延迟高每次请求都需要进行 TLS 握手加上移动网络波动字词级延迟极高无法做到流畅对话。难以实现“打断机制”当用户在机器人说话时突然插话硬件直连模式很难实时监听到用户的音频并立即向云端发送打断信令交互极其生硬。多组件协同困难一个完整的语音交互包括 ASR - LLM - TTS 三个阶段。如果在硬件端串行调用这三个云端 API硬件需要处理复杂的网络状态机极易崩溃。为了解决这一痛点**“瘦客户端边缘网关Serverless Gateway”**的架构应运而生ESP32 在其中只扮演一个**“耳朵麦克风采集嘴巴扬声器播放”的物理媒介而将所有的“大脑思考LLM”、“耳朵听觉ASR”、“声带发声TTS”全部托管给部署在局域网或云端高配主机上的小智助手服务端xiaozhi-esp32-server**。通过这种架构你的 ESP32 将瞬间拥有本地部署的 Qwen-35B 甚至是千亿级大模型的“超硬核脑容量”且交互延迟可以被压缩到 500ms 以内二、服务端核心架构剖析信令与音频流的“双轨并行”小智助手服务端xiaozhi-esp32-server是一个基于 Node.js 编写的高性能实时通信网关。为了保证语音交互的实时性与低延迟它在设计上采用了信令通道与音频流通道双轨并行的设计方案。1. 信令通道与音频流通道的划分很多小白开发者会有疑问为什么不能用一个简单的 HTTP Post 请求把录好的语音发过去然后再接收生成的语音播放这是因为HTTP 是单向、无状态且高开销的。真正的实时语音交互要求“全双工Full-Duplex”——即设备在播放声音的同时还能持续采集麦克风输入以支持“实时打断Barge-in”。因此小智助手采用了以下划分方式信令通道Signaling Channel基于WebSocket协议。负责传输非音频的控制指令如设备状态上报helloping/pongWiFi 状态。对话控制状态机开始录音start_record、结束录音stop_record、大模型开始回复、大模型回复结束。控制指令修改音量、打断播放abort_speak、智能家居控制iot_control。音频流通道Audio Stream Channel基于WebSocket 二进制帧Opus 编码或WebRTC (whip/whep)协议。上行音频流UpstreamESP32 麦克风采集的 16KHz、16bit 单声道原始 PCM 信号通过硬件内置的 Opus 编码器压缩成 Opus 帧实时打包成二进制数据发送给网关。下行音频流Downstream网关将大模型输出的文本送入 TTS 合成TTS 输出的音频同样被编码为 Opus 帧通过网络流式推回给 ESP32ESP32 边接收边解码边播放实现“流式极速响应”。2. 核心架构时序图下面我们通过一张精美的 Mermaid 时序图来看看从小智机器人被唤醒到大模型思考并语音回复的完整数据流向CosyVoice / ChatTTS本地大模型 (Ollama)Faster-Whisper (ASR)小智网关服务端 (Gateway)ESP32 机器人 (Client)CosyVoice / ChatTTS本地大模型 (Ollama)Faster-Whisper (ASR)小智网关服务端 (Gateway)ESP32 机器人 (Client)1. 建立 WebSocket 全双工长连接2. 用户按键或语音唤醒开始对话loop[实时音频传输 (上行流)]3. 语音识别阶段4. 大模型推理阶段 (流式输出)5. 语音合成阶段 (流式音频生成)6. 实时音频传输 (下行流)loop[流式文本输出 (SSE/Stream)]发送连接请求 (含设备Token、版本信息)1校验成功返回 Ready 状态2发送信令: { event: start_listen }3发送二进制 Opus 音频数据帧 (20ms 间隔)4发送信令: { event: stop_listen } (用户说话结束)5推送完整音频数据进行本地极速识别6返回识别文本: 你好请问今天天气怎么样7发送 Prompt (带上下文与当前问题)8返回文本片段 (e.g., 今天, 天气, 晴朗...)9实时将文本片段送入 TTS 引擎10实时返回 Opus/PCM 音频片段11实时发送二进制下行 Opus 音频帧12边解码边通过 I2S 扬声器播放13播放完毕发送信令: { event: speak_finished }143. 架构方案对比表我们可以清晰地对比一下**“直连模式”与“局域网网关模式”**的物理指标帮助大家理解为什么网关模式是智能硬件的最佳实践对比维度硬件直连云端模式 (云API直连)局域网网关代理模式 (小智网关)备注说明首字响应延迟 (TTFT)1500ms ~ 3000ms (高延迟)300ms ~ 800ms (极低延迟)网关支持 TCP/UDP 连接预热与流式中转ESP32 内存占用极高 (需要处理 HTTPS, TLS, JSON 解析)极低 (只需处理基础 WebSocket 与 I2S 读写)腾出内存用于支持更高采样率和更复杂的硬件驱动打断灵敏度差 (网络回路长难以实时中止连接)极强 (网关本地检测到输入立刻下发 Abort 帧)带来“如真人般”插话即停的畅快体验扩展性与灵活性极差 (修改接口或模型需要重新烧录固件)极佳 (只需在服务端后台切换大模型或 ASR 接口)硬件出厂后功能在服务端无限升级断网运行能力无法运行局域网内完全本地化运行 (私密安全)适合家庭隐私保护、无网/弱网局域网环境三、本地 Docker 部署环境准备既然局域网服务端网关如此强大我们今天就用目前最流行、最方便扩展的Docker容器化技术在本地拉起这一整套服务1. 安装 Docker 与 Docker Compose无论你是 macOS 还是 Windows 用户首选的安装方案都是Docker Desktop。它为我们提供了一个直观的图形化管理界面并且默认打包集成了docker-compose工具。macOS 安装步骤访问 Docker 官网下载页根据你的芯片类型选择Mac with Apple Silicon适用于 M1/M2/M3 系列芯片推荐。Mac with Intel chip适用于老款 Intel 处理器芯片。下载.dmg文件后双击将 Docker 图标拖入Applications目录。在启动台中打开 Docker Desktop按照提示同意服务协议并授权安装系统辅助工具。打开终端Terminal运行以下命令验证安装docker--versiondocker-compose--versionWindows 安装步骤确保你的系统已启用WSL 2 (Windows Subsystem for Linux)。以管理员身份打开 PowerShell运行wsl --install然后重启电脑。访问 Docker 官网下载Docker Desktop for Windows安装包。运行安装程序确保勾选了“Use the WSL 2 based engine”选项。安装完成后根据提示重启并在 Docker Desktop 设置Settings-General中确认勾选了 “Use the WSL 2 based engine”在Resources-WSL Integration中勾选你所用的 Linux 发行版如 Ubuntu。打开 PowerShell运行docker --version验证。2. 配置镜像加速源彻底解决拉取超时痛点 在国内复杂的网络环境下拉取 Docker 官方 Hub 的镜像经常会遇到connection refused、timeout或者拉取速度只有几 KB 的崩溃情况。为了解决这一痛点我们必须配置国内镜像加速通道。配置方式打开 Docker Desktop点击右上角的齿轮按钮Settings。在左侧导航栏中选择Docker Engine。在右侧的 JSON 配置文件中找到或新增registry-mirrors字段将其修改为如下内容这里列出了目前国内各大高校、云厂商的优质可用镜像源以及常用的自建加速节点{registry-mirrors:[https://docker.m.daocloud.io,https://dockerpull.com,https://docker.1panel.live,https://mirror.baidubce.com,https://docker.trilib.org,https://registry.docker-cn.com],builder:{gc:{defaultKeepStorage:20GB,enabled:true}},experimental:false}[!NOTE]配置完成后点击右下角的“Apply restart”按钮Docker 守护进程会自动重新加载并重启。此时你的镜像拉取速度将会得到质的飞跃四、硬核 Docker Compose 一键部署准备好环境后我们在本地建立一个专属的项目工作目录用来存放我们的 Docker 配置文件和服务端配置。1. 创建项目目录结构在终端中执行以下命令在你的工作目录下创建xiaozhi-server文件夹mkdir-p/Users/mac/Dev/Ai/CSDN/esp32-robot-im/xiaozhi-server/configcd/Users/mac/Dev/Ai/CSDN/esp32-robot-im/xiaozhi-server我们的目录结构最终将如下所示xiaozhi-server/ ├── docker-compose.yml # Docker 容器一键编排配置文件 └── config/ └── config.json # 小智服务端的业务配置文件2. 编写docker-compose.yml配置文件在xiaozhi-server目录下创建一个名为docker-compose.yml的文件。我们提供了一份极其硬核、带有极其详尽的中文注释的配置文件。请写入以下内容version:3.8services:# ----------------------------------------------------# 1. 小智助手网关服务端容器 (xiaozhi-esp32-server)# ----------------------------------------------------xiaozhi-server:image:linyi99/xiaozhi-esp32-server:latest# 使用小智官方推荐的高性能 Node.js 镜像container_name:xiaozhi-serverrestart:unless-stopped# 宿主机网络模式选择# - Linux 环境推荐直接使用 network_mode: host 获得最低延迟与无障碍 UDP 通信。# - macOS / Windows 环境因为虚拟化网络层限制无法使用 host 模式需要显式映射端口。# 这里我们采用标准端口映射方便跨平台兼容。ports:-8000:8000/tcp# HTTP 服务端口用于设备配网握手及 API 请求-8001:8001/tcp# WebSocket 控制信令与音频流的主端口核心通道-8002:8002/udp# 备用 WebRTC 音频流通道所需的 UDP 接收端口volumes:# 将宿主机的配置文件挂载到容器内部方便实时修改配置而无需重新打包镜像-./config/config.json:/app/config/config.json:ro# 挂载设备认证或本地对话日志存储目录-./data:/app/dataenvironment:# 设置容器内时区为中国标准时间-TZAsia/Shanghai# 设置 Node.js 运行环境为生产环境-NODE_ENVproduction# 指定配置文件路径-CONFIG_PATH/app/config/config.jsonlogging:driver:json-fileoptions:max-size:10m# 限制单个日志文件最大为 10MBmax-file:3# 保留最近的 3 个日志文件防止宿主机磁盘被日志塞满3. 编写config/config.json业务配置文件在config目录下新建config.json配置文件。这里是小智服务端的“中枢神经”包含了大模型地址、ASR/TTS 提供商以及各项核心参数。我们对其进行了完整的中文注释化说明{server:{port:8001,description:小智助手 WebSocket 监听端口},log:{level:info,save_to_file:true},llm:{provider:openai,api_key:sk-rpLC63KQ4kD_kY7XVpJzYRRDyD7Mm_dzNb9XxikFW80,url:http://111.34.142.12:3090/v1,model:Qwen3.6-35B-A3B,system_prompt:你是一个开朗、幽默的智能机器人名字叫小智。你正在与人类进行实时语音对话请用简短、口语化、温暖的语言回答每次回答不要超过3句话。,temperature:0.7,max_tokens:150},asr:{provider:xfyun,description:ASR 语音识别配置初学者可先采用公有云服务后续专栏将手把手教你如何切换为本地部署的 Faster-Whisper,app_id:your_xfyun_app_id,api_key:your_xfyun_api_key,api_secret:your_xfyun_api_secret},tts:{provider:volcengine,description:TTS 语音合成配置支持火山引擎、阿里、百度等后续专栏同样会带大家本地部署并对接 CosyVoice/ChatTTS,app_id:your_volc_app_id,access_token:your_volc_access_token,voice_type:bv001_streaming}}[!WARNING]以上的config.json中配置的 ASR 和 TTS 需要填写你申请的 API Key。在后面的文章中我们将手把手带大家把 ASR 切换为本地零成本运行的 Faster-Whisper把 TTS 切换为极具真人情感的 CosyVoice实现100%全本地化闭环五、宿主机网络配置避坑指南全网最硬核干货在本地 Docker 部署小智服务端时90% 的开发者都会死在网络配置上。表现为大模型明明在宿主机跑得好好的容器里却怎么也连不上或者 ESP32 成功连接了服务但扬声器只有沙沙的杂音听不到声音。下面我们将这两个最经典的痛点彻底剖析清楚。1. 为什么音频流传输要求“极度苛刻”的网络配置小智助手底层传输音频如果使用 WebRTC 协议其工作原理与普通的 HTTP 网页浏览有着本质的区别HTTP/WebSocket通过固定的端口如8000/8001使用TCP 协议传输连接稳定容易进行端口映射。WebRTC (UDP 传输)为了极致的实时性WebRTC 使用UDP 协议。在进行音视频流媒体传输时它会在客户端与服务端之间动态协商一个随机的 UDP 端口范围通常在30000到60000之间来传输音频二进制数据包。❌ 桥接网络映射的灾难如果你在docker-compose.yml中尝试使用普通的端口映射把这几万个 UDP 端口暴露出来比如写成ports:-30000-60000:30000-60000/udp千万不要这么做当容器启动时Docker 守护进程会尝试在宿主机的系统内核中为这 30000 个端口中的每一个都创建一条iptables转发规则并为每个端口启动一个docker-proxy用户态代理进程。这会导致宿主机的 CPU 瞬间飙升到 100%。宿主机系统内存被几万个进程彻底榨干系统卡死崩溃。Docker 守护进程直接 OOM 崩溃。 最佳解决方案对于 Linux 宿主机物理机/云服务器直接在docker-compose.yml中将ports:字段全部删掉替换为network_mode:host这会让容器内的服务直接共享宿主机的网络命名空间完全没有虚拟网卡和端口映射的额外开销UDP 端口动态协商畅通无阻延迟降到物理最低对于 macOS / Windows 宿主机由于它们运行 Docker 实际上是基于轻量级虚拟机Hyperkit / WSL2不支持原生的host网络模式。因此小智服务端做了专门的优化将音频流默认合并进 WebSocket 的二进制帧中传输。这就是为什么我们在上面的配置中只需要映射8001端口就完美避开了动态 WebRTC 端口映射的噩梦对于想尝鲜 WebRTC 的用户可以通过配置限定较窄的 UDP 端口范围如单独映射8002/udp并配置网关使用单端口 WebRTC 技术如 ICE-Lite 或者是特定端口多路复用。2. 容器内部访问宿主机服务的“次元壁”当我们在电脑上使用 Ollama 本地部署了大模型如Qwen3.6-35B-A3B宿主机的访问地址通常是http://localhost:11434。很多同学理所当然地在小智服务端的config.json里配置url:http://localhost:11434/v1结果就是无休止的 Connection Refused 报错。为什么会这样在 Docker 的世界中网络命名空间是严格隔离的在小智服务端容器内部localhost或者127.0.0.1指向的是容器自己而不是你的宿主机容器内并没有运行 Ollama所以自然无法在localhost:11434找到任何服务。️ 终极避坑解决方案针对不同的操作系统我们需要采用不同的映射机制打破这堵“次元壁”操作系统宿主机本地大模型访问地址容器内应填写的 API URL 地址原理与核心配置macOShttp://localhost:11434http://host.docker.internal:11434/v1Docker Desktop 自动在容器内 DNS 中将host.docker.internal解析为宿主机的虚拟网关 IP。Windows (WSL2)http://127.0.0.1:11434http://host.docker.internal:11434/v1同上。需要确保 Docker Desktop 中的 WSL2 桥接网络是打通的。Linux (Ubuntu等)http://127.0.0.1:11434http://172.17.0.1:11434/v1或自定域名Linux 下需要通过docker0网卡的默认网关 IP通常是172.17.0.1访问宿主机。或者在 Compose 中配置额外 Hosts。针对 Linux 宿主机的 Compose 配置优化如果你使用的是纯 Linux 环境又不想硬编码 IP可以在docker-compose.yml中为服务添加extra_hosts字段把host.docker.internal映射为宿主机网卡网关services:xiaozhi-server:...extra_hosts:-host.docker.internal:host-gateway# 动态获取宿主机在 docker0 网卡上的网关 IP这样无论在什么操作系统下你在config.json里都可以统一愉快地填写http://host.docker.internal:11434/v1了六、启动运行与首次联调验证 万事俱备东风已到让我们亲手拉起服务见证奇迹的时刻。1. 运行 Docker 容器在终端的~/xiaozhi-server目录下运行以下命令启动服务docker-composeup-d-d参数表示在后台运行容器。Docker 会开始自动下载镜像并进行初始化。2. 检查运行状态与日志使用以下命令查看容器是否在正常运行dockerps如果看到xiaozhi-server的状态为Up说明容器已成功运行。接着我们通过实时日志查看服务端是否成功启动、是否成功监听了端口dockerlogs-fxiaozhi-server成功的日志输出示例[2026-05-21 19:40:00] INFO: XiaoZhi Server is running in production mode. [2026-05-21 19:40:00] INFO: Loading configuration from /app/config/config.json [2026-05-21 19:40:01] INFO: WebSocket Server is listening on ws://0.0.0.0:8001 [2026-05-21 19:40:01] INFO: HTTP API Gateway is listening on http://0.0.0.0:8000 [2026-05-21 19:40:01] INFO: Successfully connected to LLM Provider: Qwen3.6-35B-A3B如果看到以上日志恭喜你你的小智助手局域网服务端网关已经彻底拉起随时等待着你的 ESP32 机器人前来接入✅ 本文总结今天我们完成了小智机器人开发中最核心、也是最具里程碑意义的一步——部署局域网服务端网关我们一同探讨了网关架构优势通过“瘦客户端”模式解除 ESP32 的硬件性能封印让其瞬间拥有千亿级本地大模型的思考能力。双轨架构流向剖析了 WebSocket 信令通道与二进制音频流通道的划分与精妙配合。Docker 极速拉起在本地成功配置国内加速源并通过一份工业级的docker-compose.yml配置文件一键启动了服务端。网络闭坑精髓深度解析了 Docker 容器网络隔离原理解决了 macOS/Windows/Linux 等多平台下容器访问宿主机大模型Ollama的通信障碍。至此服务端的骨架已经搭建完毕。接下来我们需要为其注入真正的“灵魂” 下一篇预告在下一篇教程中我们将迎来最激动人心的核心环节《Esp32Robot入门05-大模型接口对接与配置灵魂注入让你的小智机器人开口说出第一句话》我们将手把手带你对接本地大模型配置 Ollama 并下载Qwen3.6-35B-A3B模型完成本地超大参数模型的极速对话测试。云端与本地大模型混合路由详解小智服务端的 LLM 配置细节教你如何优雅地在大模型输出的 JSON 格式中嵌入自定义字段。个性化 Prompt 调优秘籍如何通过精心设计的系统提示词把一个冰冷的大模型驯化为一个性格活泼、有问必答、甚至带点毒舌特性的“小智”语音玩偶。精彩不容错过我们下一章见大家在本地 Docker 部署过程中有遇到任何端口冲突或网络连不通的奇怪问题欢迎在评论区留言我会一一为大家解答如果本文对你有启发别忘了点赞、收藏加关注哦
Esp32Robot入门04-服务端架构与本地Docker拉起（实战进阶：手把手教你用Docker部署小智助手服务端）
Esp32Robot入门04-服务端架构与本地Docker拉起实战进阶手把手教你用Docker部署小智助手服务端 文章简介在AI智能硬件开发中ESP32-S3因高性价比备受青睐但面对千亿参数的本地大模型与高负载的ASR/TTS语音服务其几百KB的片上内存和有限的算力显得捉襟见肘。如何让小巧的ESP32拥有“超强脑容量”答案就是局域网网关服务端架构本文将带你深度剖析开源小智语音助手xiaozhi-esp32服务端的信令与音频流通道划分使用 Mermaid 绘制高大上的系统时序图并手把手教你利用 Docker Compose 在本地Windows/macOS一键拉起服务端网关。针对开发者最常踩的“Docker 容器网络隔离”、“Ollama 局域网访问失败”以及“WebRTC 端口映射导致 iptables 崩溃”等宿主机网络痛点进行无保留的硬核避坑分享。读完本文你将成功打通硬件到服务端的“任督二脉”为后续接入本地大模型奠定坚实基础一、前言硬件资源极度有限如何让 ESP32 拥有“千亿级脑容量”ESP32-S3 是一块非常优秀的 SoC。它搭载 Xtensa® 双核 32 位 LX7 微处理器主频高达 240MHz支持 Wi-Fi 与蓝牙 5.0在智能家居、传感器采集、低功耗物联网设备中几乎打遍天下无敌手。然而在“生成式大语言模型LLM”与“实时语音交互Voice Chat”的浪潮下ESP32 遇到了前所未有的物理瓶颈内存SRAM饥饿ESP32-S3 只有 512KB SRAM。即使是带了 8MB PSRAM外部伪静态随机存储器的开发板在面对 HTTPS 握手需要几十KB的SSL上下文缓存、复杂的 JSON 解析、以及 Opus 音频编解码时PSRAM 也会被迅速占满稍有不慎就会触发Out of Memory (OOM)导致硬件频繁重启。算力限制本地运行 ASR自动语音识别与 TTS语音合成哪怕是最小的模型如 Whisper-Tiny也需要几百MB的内存和强大的 GPU/NPU 支持这在 ESP32 上是物理性不可能实现的。直连云端的痛点有些开发者尝试让 ESP32 直连 OpenAI、火山引擎或阿里百炼的 API。虽然可行但存在以下硬伤握手延迟高每次请求都需要进行 TLS 握手加上移动网络波动字词级延迟极高无法做到流畅对话。难以实现“打断机制”当用户在机器人说话时突然插话硬件直连模式很难实时监听到用户的音频并立即向云端发送打断信令交互极其生硬。多组件协同困难一个完整的语音交互包括 ASR - LLM - TTS 三个阶段。如果在硬件端串行调用这三个云端 API硬件需要处理复杂的网络状态机极易崩溃。为了解决这一痛点**“瘦客户端边缘网关Serverless Gateway”**的架构应运而生ESP32 在其中只扮演一个**“耳朵麦克风采集嘴巴扬声器播放”的物理媒介而将所有的“大脑思考LLM”、“耳朵听觉ASR”、“声带发声TTS”全部托管给部署在局域网或云端高配主机上的小智助手服务端xiaozhi-esp32-server**。通过这种架构你的 ESP32 将瞬间拥有本地部署的 Qwen-35B 甚至是千亿级大模型的“超硬核脑容量”且交互延迟可以被压缩到 500ms 以内二、服务端核心架构剖析信令与音频流的“双轨并行”小智助手服务端xiaozhi-esp32-server是一个基于 Node.js 编写的高性能实时通信网关。为了保证语音交互的实时性与低延迟它在设计上采用了信令通道与音频流通道双轨并行的设计方案。1. 信令通道与音频流通道的划分很多小白开发者会有疑问为什么不能用一个简单的 HTTP Post 请求把录好的语音发过去然后再接收生成的语音播放这是因为HTTP 是单向、无状态且高开销的。真正的实时语音交互要求“全双工Full-Duplex”——即设备在播放声音的同时还能持续采集麦克风输入以支持“实时打断Barge-in”。因此小智助手采用了以下划分方式信令通道Signaling Channel基于WebSocket协议。负责传输非音频的控制指令如设备状态上报helloping/pongWiFi 状态。对话控制状态机开始录音start_record、结束录音stop_record、大模型开始回复、大模型回复结束。控制指令修改音量、打断播放abort_speak、智能家居控制iot_control。音频流通道Audio Stream Channel基于WebSocket 二进制帧Opus 编码或WebRTC (whip/whep)协议。上行音频流UpstreamESP32 麦克风采集的 16KHz、16bit 单声道原始 PCM 信号通过硬件内置的 Opus 编码器压缩成 Opus 帧实时打包成二进制数据发送给网关。下行音频流Downstream网关将大模型输出的文本送入 TTS 合成TTS 输出的音频同样被编码为 Opus 帧通过网络流式推回给 ESP32ESP32 边接收边解码边播放实现“流式极速响应”。2. 核心架构时序图下面我们通过一张精美的 Mermaid 时序图来看看从小智机器人被唤醒到大模型思考并语音回复的完整数据流向CosyVoice / ChatTTS本地大模型 (Ollama)Faster-Whisper (ASR)小智网关服务端 (Gateway)ESP32 机器人 (Client)CosyVoice / ChatTTS本地大模型 (Ollama)Faster-Whisper (ASR)小智网关服务端 (Gateway)ESP32 机器人 (Client)1. 建立 WebSocket 全双工长连接2. 用户按键或语音唤醒开始对话loop[实时音频传输 (上行流)]3. 语音识别阶段4. 大模型推理阶段 (流式输出)5. 语音合成阶段 (流式音频生成)6. 实时音频传输 (下行流)loop[流式文本输出 (SSE/Stream)]发送连接请求 (含设备Token、版本信息)1校验成功返回 Ready 状态2发送信令: { event: start_listen }3发送二进制 Opus 音频数据帧 (20ms 间隔)4发送信令: { event: stop_listen } (用户说话结束)5推送完整音频数据进行本地极速识别6返回识别文本: 你好请问今天天气怎么样7发送 Prompt (带上下文与当前问题)8返回文本片段 (e.g., 今天, 天气, 晴朗...)9实时将文本片段送入 TTS 引擎10实时返回 Opus/PCM 音频片段11实时发送二进制下行 Opus 音频帧12边解码边通过 I2S 扬声器播放13播放完毕发送信令: { event: speak_finished }143. 架构方案对比表我们可以清晰地对比一下**“直连模式”与“局域网网关模式”**的物理指标帮助大家理解为什么网关模式是智能硬件的最佳实践对比维度硬件直连云端模式 (云API直连)局域网网关代理模式 (小智网关)备注说明首字响应延迟 (TTFT)1500ms ~ 3000ms (高延迟)300ms ~ 800ms (极低延迟)网关支持 TCP/UDP 连接预热与流式中转ESP32 内存占用极高 (需要处理 HTTPS, TLS, JSON 解析)极低 (只需处理基础 WebSocket 与 I2S 读写)腾出内存用于支持更高采样率和更复杂的硬件驱动打断灵敏度差 (网络回路长难以实时中止连接)极强 (网关本地检测到输入立刻下发 Abort 帧)带来“如真人般”插话即停的畅快体验扩展性与灵活性极差 (修改接口或模型需要重新烧录固件)极佳 (只需在服务端后台切换大模型或 ASR 接口)硬件出厂后功能在服务端无限升级断网运行能力无法运行局域网内完全本地化运行 (私密安全)适合家庭隐私保护、无网/弱网局域网环境三、本地 Docker 部署环境准备既然局域网服务端网关如此强大我们今天就用目前最流行、最方便扩展的Docker容器化技术在本地拉起这一整套服务1. 安装 Docker 与 Docker Compose无论你是 macOS 还是 Windows 用户首选的安装方案都是Docker Desktop。它为我们提供了一个直观的图形化管理界面并且默认打包集成了docker-compose工具。macOS 安装步骤访问 Docker 官网下载页根据你的芯片类型选择Mac with Apple Silicon适用于 M1/M2/M3 系列芯片推荐。Mac with Intel chip适用于老款 Intel 处理器芯片。下载.dmg文件后双击将 Docker 图标拖入Applications目录。在启动台中打开 Docker Desktop按照提示同意服务协议并授权安装系统辅助工具。打开终端Terminal运行以下命令验证安装docker--versiondocker-compose--versionWindows 安装步骤确保你的系统已启用WSL 2 (Windows Subsystem for Linux)。以管理员身份打开 PowerShell运行wsl --install然后重启电脑。访问 Docker 官网下载Docker Desktop for Windows安装包。运行安装程序确保勾选了“Use the WSL 2 based engine”选项。安装完成后根据提示重启并在 Docker Desktop 设置Settings-General中确认勾选了 “Use the WSL 2 based engine”在Resources-WSL Integration中勾选你所用的 Linux 发行版如 Ubuntu。打开 PowerShell运行docker --version验证。2. 配置镜像加速源彻底解决拉取超时痛点 在国内复杂的网络环境下拉取 Docker 官方 Hub 的镜像经常会遇到connection refused、timeout或者拉取速度只有几 KB 的崩溃情况。为了解决这一痛点我们必须配置国内镜像加速通道。配置方式打开 Docker Desktop点击右上角的齿轮按钮Settings。在左侧导航栏中选择Docker Engine。在右侧的 JSON 配置文件中找到或新增registry-mirrors字段将其修改为如下内容这里列出了目前国内各大高校、云厂商的优质可用镜像源以及常用的自建加速节点{registry-mirrors:[https://docker.m.daocloud.io,https://dockerpull.com,https://docker.1panel.live,https://mirror.baidubce.com,https://docker.trilib.org,https://registry.docker-cn.com],builder:{gc:{defaultKeepStorage:20GB,enabled:true}},experimental:false}[!NOTE]配置完成后点击右下角的“Apply restart”按钮Docker 守护进程会自动重新加载并重启。此时你的镜像拉取速度将会得到质的飞跃四、硬核 Docker Compose 一键部署准备好环境后我们在本地建立一个专属的项目工作目录用来存放我们的 Docker 配置文件和服务端配置。1. 创建项目目录结构在终端中执行以下命令在你的工作目录下创建xiaozhi-server文件夹mkdir-p/Users/mac/Dev/Ai/CSDN/esp32-robot-im/xiaozhi-server/configcd/Users/mac/Dev/Ai/CSDN/esp32-robot-im/xiaozhi-server我们的目录结构最终将如下所示xiaozhi-server/ ├── docker-compose.yml # Docker 容器一键编排配置文件 └── config/ └── config.json # 小智服务端的业务配置文件2. 编写docker-compose.yml配置文件在xiaozhi-server目录下创建一个名为docker-compose.yml的文件。我们提供了一份极其硬核、带有极其详尽的中文注释的配置文件。请写入以下内容version:3.8services:# ----------------------------------------------------# 1. 小智助手网关服务端容器 (xiaozhi-esp32-server)# ----------------------------------------------------xiaozhi-server:image:linyi99/xiaozhi-esp32-server:latest# 使用小智官方推荐的高性能 Node.js 镜像container_name:xiaozhi-serverrestart:unless-stopped# 宿主机网络模式选择# - Linux 环境推荐直接使用 network_mode: host 获得最低延迟与无障碍 UDP 通信。# - macOS / Windows 环境因为虚拟化网络层限制无法使用 host 模式需要显式映射端口。# 这里我们采用标准端口映射方便跨平台兼容。ports:-8000:8000/tcp# HTTP 服务端口用于设备配网握手及 API 请求-8001:8001/tcp# WebSocket 控制信令与音频流的主端口核心通道-8002:8002/udp# 备用 WebRTC 音频流通道所需的 UDP 接收端口volumes:# 将宿主机的配置文件挂载到容器内部方便实时修改配置而无需重新打包镜像-./config/config.json:/app/config/config.json:ro# 挂载设备认证或本地对话日志存储目录-./data:/app/dataenvironment:# 设置容器内时区为中国标准时间-TZAsia/Shanghai# 设置 Node.js 运行环境为生产环境-NODE_ENVproduction# 指定配置文件路径-CONFIG_PATH/app/config/config.jsonlogging:driver:json-fileoptions:max-size:10m# 限制单个日志文件最大为 10MBmax-file:3# 保留最近的 3 个日志文件防止宿主机磁盘被日志塞满3. 编写config/config.json业务配置文件在config目录下新建config.json配置文件。这里是小智服务端的“中枢神经”包含了大模型地址、ASR/TTS 提供商以及各项核心参数。我们对其进行了完整的中文注释化说明{server:{port:8001,description:小智助手 WebSocket 监听端口},log:{level:info,save_to_file:true},llm:{provider:openai,api_key:sk-rpLC63KQ4kD_kY7XVpJzYRRDyD7Mm_dzNb9XxikFW80,url:http://111.34.142.12:3090/v1,model:Qwen3.6-35B-A3B,system_prompt:你是一个开朗、幽默的智能机器人名字叫小智。你正在与人类进行实时语音对话请用简短、口语化、温暖的语言回答每次回答不要超过3句话。,temperature:0.7,max_tokens:150},asr:{provider:xfyun,description:ASR 语音识别配置初学者可先采用公有云服务后续专栏将手把手教你如何切换为本地部署的 Faster-Whisper,app_id:your_xfyun_app_id,api_key:your_xfyun_api_key,api_secret:your_xfyun_api_secret},tts:{provider:volcengine,description:TTS 语音合成配置支持火山引擎、阿里、百度等后续专栏同样会带大家本地部署并对接 CosyVoice/ChatTTS,app_id:your_volc_app_id,access_token:your_volc_access_token,voice_type:bv001_streaming}}[!WARNING]以上的config.json中配置的 ASR 和 TTS 需要填写你申请的 API Key。在后面的文章中我们将手把手带大家把 ASR 切换为本地零成本运行的 Faster-Whisper把 TTS 切换为极具真人情感的 CosyVoice实现100%全本地化闭环五、宿主机网络配置避坑指南全网最硬核干货在本地 Docker 部署小智服务端时90% 的开发者都会死在网络配置上。表现为大模型明明在宿主机跑得好好的容器里却怎么也连不上或者 ESP32 成功连接了服务但扬声器只有沙沙的杂音听不到声音。下面我们将这两个最经典的痛点彻底剖析清楚。1. 为什么音频流传输要求“极度苛刻”的网络配置小智助手底层传输音频如果使用 WebRTC 协议其工作原理与普通的 HTTP 网页浏览有着本质的区别HTTP/WebSocket通过固定的端口如8000/8001使用TCP 协议传输连接稳定容易进行端口映射。WebRTC (UDP 传输)为了极致的实时性WebRTC 使用UDP 协议。在进行音视频流媒体传输时它会在客户端与服务端之间动态协商一个随机的 UDP 端口范围通常在30000到60000之间来传输音频二进制数据包。❌ 桥接网络映射的灾难如果你在docker-compose.yml中尝试使用普通的端口映射把这几万个 UDP 端口暴露出来比如写成ports:-30000-60000:30000-60000/udp千万不要这么做当容器启动时Docker 守护进程会尝试在宿主机的系统内核中为这 30000 个端口中的每一个都创建一条iptables转发规则并为每个端口启动一个docker-proxy用户态代理进程。这会导致宿主机的 CPU 瞬间飙升到 100%。宿主机系统内存被几万个进程彻底榨干系统卡死崩溃。Docker 守护进程直接 OOM 崩溃。 最佳解决方案对于 Linux 宿主机物理机/云服务器直接在docker-compose.yml中将ports:字段全部删掉替换为network_mode:host这会让容器内的服务直接共享宿主机的网络命名空间完全没有虚拟网卡和端口映射的额外开销UDP 端口动态协商畅通无阻延迟降到物理最低对于 macOS / Windows 宿主机由于它们运行 Docker 实际上是基于轻量级虚拟机Hyperkit / WSL2不支持原生的host网络模式。因此小智服务端做了专门的优化将音频流默认合并进 WebSocket 的二进制帧中传输。这就是为什么我们在上面的配置中只需要映射8001端口就完美避开了动态 WebRTC 端口映射的噩梦对于想尝鲜 WebRTC 的用户可以通过配置限定较窄的 UDP 端口范围如单独映射8002/udp并配置网关使用单端口 WebRTC 技术如 ICE-Lite 或者是特定端口多路复用。2. 容器内部访问宿主机服务的“次元壁”当我们在电脑上使用 Ollama 本地部署了大模型如Qwen3.6-35B-A3B宿主机的访问地址通常是http://localhost:11434。很多同学理所当然地在小智服务端的config.json里配置url:http://localhost:11434/v1结果就是无休止的 Connection Refused 报错。为什么会这样在 Docker 的世界中网络命名空间是严格隔离的在小智服务端容器内部localhost或者127.0.0.1指向的是容器自己而不是你的宿主机容器内并没有运行 Ollama所以自然无法在localhost:11434找到任何服务。️ 终极避坑解决方案针对不同的操作系统我们需要采用不同的映射机制打破这堵“次元壁”操作系统宿主机本地大模型访问地址容器内应填写的 API URL 地址原理与核心配置macOShttp://localhost:11434http://host.docker.internal:11434/v1Docker Desktop 自动在容器内 DNS 中将host.docker.internal解析为宿主机的虚拟网关 IP。Windows (WSL2)http://127.0.0.1:11434http://host.docker.internal:11434/v1同上。需要确保 Docker Desktop 中的 WSL2 桥接网络是打通的。Linux (Ubuntu等)http://127.0.0.1:11434http://172.17.0.1:11434/v1或自定域名Linux 下需要通过docker0网卡的默认网关 IP通常是172.17.0.1访问宿主机。或者在 Compose 中配置额外 Hosts。针对 Linux 宿主机的 Compose 配置优化如果你使用的是纯 Linux 环境又不想硬编码 IP可以在docker-compose.yml中为服务添加extra_hosts字段把host.docker.internal映射为宿主机网卡网关services:xiaozhi-server:...extra_hosts:-host.docker.internal:host-gateway# 动态获取宿主机在 docker0 网卡上的网关 IP这样无论在什么操作系统下你在config.json里都可以统一愉快地填写http://host.docker.internal:11434/v1了六、启动运行与首次联调验证 万事俱备东风已到让我们亲手拉起服务见证奇迹的时刻。1. 运行 Docker 容器在终端的~/xiaozhi-server目录下运行以下命令启动服务docker-composeup-d-d参数表示在后台运行容器。Docker 会开始自动下载镜像并进行初始化。2. 检查运行状态与日志使用以下命令查看容器是否在正常运行dockerps如果看到xiaozhi-server的状态为Up说明容器已成功运行。接着我们通过实时日志查看服务端是否成功启动、是否成功监听了端口dockerlogs-fxiaozhi-server成功的日志输出示例[2026-05-21 19:40:00] INFO: XiaoZhi Server is running in production mode. [2026-05-21 19:40:00] INFO: Loading configuration from /app/config/config.json [2026-05-21 19:40:01] INFO: WebSocket Server is listening on ws://0.0.0.0:8001 [2026-05-21 19:40:01] INFO: HTTP API Gateway is listening on http://0.0.0.0:8000 [2026-05-21 19:40:01] INFO: Successfully connected to LLM Provider: Qwen3.6-35B-A3B如果看到以上日志恭喜你你的小智助手局域网服务端网关已经彻底拉起随时等待着你的 ESP32 机器人前来接入✅ 本文总结今天我们完成了小智机器人开发中最核心、也是最具里程碑意义的一步——部署局域网服务端网关我们一同探讨了网关架构优势通过“瘦客户端”模式解除 ESP32 的硬件性能封印让其瞬间拥有千亿级本地大模型的思考能力。双轨架构流向剖析了 WebSocket 信令通道与二进制音频流通道的划分与精妙配合。Docker 极速拉起在本地成功配置国内加速源并通过一份工业级的docker-compose.yml配置文件一键启动了服务端。网络闭坑精髓深度解析了 Docker 容器网络隔离原理解决了 macOS/Windows/Linux 等多平台下容器访问宿主机大模型Ollama的通信障碍。至此服务端的骨架已经搭建完毕。接下来我们需要为其注入真正的“灵魂” 下一篇预告在下一篇教程中我们将迎来最激动人心的核心环节《Esp32Robot入门05-大模型接口对接与配置灵魂注入让你的小智机器人开口说出第一句话》我们将手把手带你对接本地大模型配置 Ollama 并下载Qwen3.6-35B-A3B模型完成本地超大参数模型的极速对话测试。云端与本地大模型混合路由详解小智服务端的 LLM 配置细节教你如何优雅地在大模型输出的 JSON 格式中嵌入自定义字段。个性化 Prompt 调优秘籍如何通过精心设计的系统提示词把一个冰冷的大模型驯化为一个性格活泼、有问必答、甚至带点毒舌特性的“小智”语音玩偶。精彩不容错过我们下一章见大家在本地 Docker 部署过程中有遇到任何端口冲突或网络连不通的奇怪问题欢迎在评论区留言我会一一为大家解答如果本文对你有启发别忘了点赞、收藏加关注哦
