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

背景

随着具身智能（Embodied AI）的发展，机器人对实时语音交互的需求日益增长。然而，传统的云端语音处理方案往往面临数据隐私泄露、网络延迟以及 API 调用成本高昂等痛点。对于像 Reachy Mini 这样的教育和服务机器人而言，用户希望能够在不依赖外部云服务、不暴露音频数据的前提下，实现流畅、低延迟的人机对话。

Hugging Face 博客近期发布了一篇技术指南，详细介绍了如何通过本地部署一套基于 speech-to-speech 库的语音到语音（Speech-to-Speech）管道，将 Reachy Mini 完全本地化。该方案利用级联架构（Cascaded Pipeline），将语音活动检测（VAD）、语音转文本（STT）、大语言模型（LLM）和文本转语音（TTS）四个环节整合在一起，并通过兼容 Realtime API 的 WebSocket 接口与机器人连接。这一方案不仅确保了数据不出本地机器，还通过灵活的组件替换机制，让用户能够在隐私、速度和音质之间找到最佳平衡。

核心内容

1. 本地化 LLM 服务部署

实现全本地交互的第一步是部署一个高效的本地 LLM 推理服务器。文章推荐使用 Hugging Face 的 llama.cpp 工具，因其安装简便且性能优异。

• 模型选择：推荐使用 ggml-org/gemma-4-E4B-it-GGUF。Gemma 系列模型在保持较小体积的同时，提供了出色的指令跟随能力。
• 启动命令与参数解析：

  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：启用滑动窗口注意力（Sliding Window Attention）的全缓存模式。虽然会消耗少量 RAM，但在 Gemma 模型上能显著加快提示词（Prompt）的处理速度。

2. 搭建 Speech-to-Speech 管道

在 LLM 服务运行后，需要部署语音处理管道。Hugging Face 提供了 speech-to-speech 库，它是一个级联 VAD → STT → LLM → TTS 的管道，暴露出兼容 Realtime API 的 /v1/realtime WebSocket 接口。

• 安装：

  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
  

  首次运行会自动下载 Parakeet-TDT 0.6B v3（STT 模型）和 Qwen3-TTS（TTS 模型），后续启动将非常迅速。用户可以直接在终端中与模型进行语音对话。

• 连接 Reachy Mini： 在确认本地管道工作正常后，启动 Reachy Mini 的桌面应用和对话应用。在对话应用的 UI 中，点击 HF 后端的“编辑连接”（Edit Connection），选择本地模式，即可将机器人指向本地的 speech-to-speech 服务。

3. 架构优势与组件替换

级联架构是目前开源领域最灵活且速度最快的方案之一。其核心优势在于模块化：

• VAD（语音活动检测）：Silero VAD 是推荐默认项。
• STT（语音转文本）：推荐 Parakeet-TDT 0.6B v3，在速度和多语言支持之间取得了良好平衡。
• TTS（文本转语音）：推荐 Qwen3-TTS。

用户可以根据需求替换任何组件。例如，如果需要更高的 TTS 音质，可以选择更慢的模型；如果只针对单一语言优化，可以替换为更高效的单语言模型。

4. 高级配置：解耦 LLM 与语音循环

为了进一步降低延迟，文章介绍了将 LLM 推理与语音处理解耦的高级用法。通过支持 Responses API 协议的服务器，可以将 LLM 放在独立的进程中，通过 HTTP 通信。

• Option 1: 使用 llama.cpp 在终端 1 运行 llama-server，在终端 2 运行 speech-to-speech，并指定 --llm_backend responses-api 和对应的 URL。

• Option 2: 使用 vLLM（推荐用于高性能场景） vLLM ≥ 0.21.0 版本完全支持 Responses API 协议，包括工具调用流式传输。

  • 关键参数：
    • --enable-auto-tool-choice：启用自动工具选择。
    • --tool-call-parser：指定解析器（如 qwen3_coder 用于 Qwen3 模型，llama3_json 用于 Llama 3）。
    • --default-chat-template-kwargs '{"enable_thinking":false}'：强烈建议关闭“思考”通道。对于自然对话，开启思考会导致用户听到长时间的沉默（因为思考 token 不计入语音输出），严重影响体验。
    • --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}'
    

    随后在 speech-to-speech 中指向 http://127.0.0.1:8000/v1。

• Option 3 & 4: 云端托管方案 如果不想管理本地 GPU，可以使用 Hugging Face Inference Endpoints（托管 GPU）或 Inference Providers（路由到 Together, Fireworks 等第三方后端）。只需修改 responses_api_base_url 和 api_key 即可。

关键要点

• 完全本地化：通过本地部署 llama.cpp 和 speech-to-speech，实现音频数据不离开本地机器，保障隐私，且无需支付 API 费用。
• 级联架构的灵活性：采用 VAD → STT → LLM → TTS 的级联设计，允许用户根据硬件能力和需求（如多语言 vs 单语言、速度 vs 音质）自由替换各个组件。
• 推荐模型组合：
  • LLM: Gemma 4 (通过 llama.cpp) 或 Qwen3 (通过 vLLM)。
  • STT: Parakeet-TDT 0.6B v3。
  • TTS: Qwen3-TTS。
  • VAD: Silero VAD。
• 延迟优化策略：