Reachy Mini 实现全本地化语音交互：深度解读

背景

随着具身智能（Embodied AI）的快速发展，机器人对实时语音交互的需求日益增长。然而，传统的云端语音处理方案往往面临数据隐私泄露、网络延迟不稳定以及持续的服务成本高昂等问题。对于像 Reachy Mini 这样的教育或家用机器人而言，用户更倾向于一种完全本地化、无需联网即可运行的解决方案，以确保音频数据不出本地网络，同时实现低延迟的流畅对话。

Hugging Face 近期发布了一项技术指南，展示了如何利用开源生态中的最新模型和工具链，将 Reachy Mini 的语音交互后端完全部署在本地硬件上。该方案基于其开源库 speech-to-speech，通过级联（Cascaded）架构，将语音活动检测（VAD）、语音转文字（STT）、大语言模型（LLM）和文字转语音（TTS）四个环节无缝连接，并通过兼容 Realtime API 的 WebSocket 接口与机器人连接。

核心内容

本文详细介绍了如何构建一个完全本地化的语音交互后端，使 Reachy Mini 能够在无云、无 API 密钥、数据不离开本地设备的情况下进行实时对话。整个系统由四个核心阶段组成：VAD、STT、LLM 和 TTS。

1. 核心架构：speech-to-speech 级联管道

该方案的核心是 speech-to-speech 库，它提供了一个级联处理管道。级联架构的优势在于灵活性，用户可以根据硬件性能和个人偏好替换其中的任何一个组件。推荐的默认组件组合包括：

• LLM: llama.cpp 配合 Gemma 4
• VAD: Silero VAD
• STT: Parakeet-TDT 0.6B v3
• TTS: Qwen3-TTS

2. 本地 LLM 服务部署

为了降低延迟并保护隐私，推荐使用 llama.cpp 在本地运行 LLM。

快速启动步骤：

1. 安装 llama.cpp（可通过 brew install llama.cpp 或 winget install llama.cpp）。
2. 运行以下命令启动服务器：

   llama-server -hf ggml-org/gemma-4-E4B-it-GGUF -np 2 -c 65536 -fa on --swa-full
   

参数详解：

• -hf ggml-org/gemma-4-E4B-it-GGUF：直接从 Hugging Face Hub 拉取模型。首次运行会下载模型，后续运行使用缓存。
• -np 2：设置两个并行槽位，允许服务器在处理第一个请求的同时接受第二个请求（如快速打断），避免阻塞。
• -c 65536：设置 64k 的上下文窗口，足以支持长对话。
• -fa on：启用 Flash Attention，在现代硬件上能显著加速推理并降低显存占用。
• --swa-full：启用全滑动窗口注意力缓存，而非重新计算。虽然增加少量 RAM 使用，但能显著加快 Gemma 模型的提示词处理速度。

3. 配置语音交互后端

在 LLM 服务运行的同时，配置 speech-to-speech 后端。

本地测试模式：

uv pip install speech-to-speech
speech-to-speech --responses_api_base_url "http://127.0.0.1:8080" --responses_api_api_key "" --mode local

此模式用于在终端中测试语音交互。首次运行会自动下载 STT 和 TTS 模型，后续启动速度较快。

连接机器人： 在 Reachy Mini 的桌面应用中，进入对话应用的 UI，点击 HF 后端的 "edit connection" 并选择本地模式，即可将机器人连接到本地后端。

4. 高级选项：解耦 LLM 推理与语音循环

为了进一步优化性能，speech-to-speech 支持通过 Responses API 协议将 LLM 推理引擎与语音循环解耦。这意味着 LLM 可以运行在独立的进程或服务器上，只要支持 Responses API 协议即可。

方案 A：llama.cpp 本地推理

• Terminal 1 (LLM Server): 运行 llama-server。
• Terminal 2 (Voice Loop): 运行 speech-to-speech，指定 --llm_backend responses-api 并指向本地 LLM 地址。

方案 B：vLLM 高性能推理 vLLM (≥ 0.21.0) 提供了对 Responses API 的完整支持，包括工具调用流式传输。

• 关键参数：
  • --enable-auto-tool-choice：启用自动工具选择。
  • --tool-call-parser <parser_name>：指定解析器（如 qwen3_coder 用于 Qwen3 模型）。
  • --default-chat-template-kwargs '{"enable_thinking":false}'：强烈建议关闭思考链（Thinking Chain）。在自然对话中，思考令牌会导致用户听到明显的静音延迟。除非进行复杂的代理任务，否则应保持关闭。
  • --speculative-config：启用多令牌预测（MTP），可显著降低端到端延迟。
• 示例命令：

  vllm serve Qwen/Qwen3-4B-Instruct-2507 \
  --port 8000 \
  --host 127.0.0.1 \
  --max-model-len 32768 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder \
  --default-chat-template-kwargs '{"enable_thinking":false}' \
  --speculative-config '{"method":"qwen3_next_mtp","num_speculative_tokens":1}'
  

方案 C & D：云端托管推理 如果本地硬件资源不足，可以使用 Hugging Face Inference Endpoints 或 Inference Providers（如 Together, Fireworks, Replicate）。只需将 --responses_api_base_url 指向托管端点 URL，并配置相应的 API Key 即可。

关键要点

• 完全本地化与隐私保护：整个管道（VAD、STT、LLM、TTS）均在本地硬件运行，音频数据永不离开本地网络，无需云服务。
• 零成本运行：无需支付按分钟或按令牌计费的 API 费用，硬件成本一次性投入。
• 高度可定制性：级联架构允许用户自由替换任何组件。例如，若追求单语言性能，可替换为更专用的 STT 或 TTS 模型；若追求速度，可选择更轻量级的模型。
• 低延迟优化策略：
  • 使用 Flash Attention (-fa on) 和滑动窗口注意力 (--swa-full) 加速 LLM 推理。
  • 在 vLLM 中启用多令牌预测（MTP）以进一步降低延迟。
  • 关键建议：在自然对话场景中，务必禁用 LLM 的“思考链”（Thinking Chain/Reasoning Channel），以避免因生成思考令牌而产生的用户感知延迟。
• 协议兼容性：speech-to-speech 暴露 /v1/realtime WebSocket 接口，完全兼容 Reachy Mini 现有的通信协议，使得集成变得极其简单。
• 推荐模型组合：
  • LLM: Gemma 4 或 Qwen3 (通过 llama.cpp 或 vLLM 运行)
  • STT: Parakeet-TDT 0.6B v3
  • TTS: Qwen3-TTS
  • VAD: Silero VAD

意义与影响

这项技术指南的发布标志着开源具身智能在落地应用上迈出了重要一步。

1. 降低具身智能门槛：通过提供一套开箱即用的本地化方案，开发者无需深厚的云服务运维知识或高昂的 API 预算，即可为机器人赋予高质量的实时语音交互能力。
2. **推动