Tras armar tu Reachy Mini, lo siguiente era instalar la app de conversación y empezar a hablarle. Hasta ahora había que mandar el audio a un servidor en la nube. Ya no. Hugging Face publicó la guía para correr el stack completo sin salir de la red local.

El stack se apoya en speech-to-speech, un pipeline en cascada VAD → STT → LLM → TTS que expone un WebSocket /v1/realtime compatible con la Realtime API. Una vez levantado el backend, se apunta el robot desde la UI.

Las cascadas son la opción más flexible del paisaje open source actual, y con las piezas correctas también son las más rápidas. Hugging Face recomienda componentes específicos, pero el punto de una cascada es justamente que cualquier pieza es reemplazable. Cada semana aparecen modelos nuevos.

TL;DR: desplegá un backend de voz local para Reachy Mini con la biblioteca speech-to-speech. Recomendados: llama.cpp con Gemma 4, Silero VAD, Parakeet-TDT 0.6B v3 para STT, Qwen3-TTS para síntesis.

¿Cómo arranco la conversación local?

La guía corre todo el pipeline en tu máquina: sin nube, sin claves de API, sin datos saliendo del equipo.

Servir el LLM en local

Para servir el LLM se usa llama.cpp. La forma más simple de instalarlo es brew install llama.cpp o winget install llama.cpp. Más detalle en la documentación. Luego:

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

La primera vez descarga el modelo. Los siguientes arranques son rápidos.

Levantar speech-to-speech

Código
uv pip install speech-to-speech

Y, en otra terminal mientras se sirve el LLM:

Código
speech-to-speech --responses_api_base_url "http://127.0.0.1:8080" --responses_api_api_key "" --mode local

Ya se puede hablar al modelo desde la terminal. La primera ejecución descarga Parakeet-TDT 0.6B v3 y Qwen3-TTS.

Conectar el robot al stack local

Con llama.cpp y speech-to-speech corriendo, se arranca el robot con la app de escritorio y se lanza la conversation app. En la UI hay que elegir el modo local desde "edit connection" en el backend de Hugging Face. Listo.

¿Por qué correr el servidor speech-to-speech propio?

Los backends realtime alojados son cómodos, pero administrar el motor propio destraba tres cosas:

  • Privacidad: el audio nunca sale de la red local, todo el pipeline corre sobre hardware propio.
  • Cero costos de API: sin tarifas por minuto ni por token.
  • Control total del pipeline: cualquier pieza es intercambiable (VAD, STT, LLM, TTS) según lo que aparezca en el Hub.

El repo speech-to-speech ofrece todo eso desde un único CLI. Levanta un servidor WebSocket en /v1/realtime que habla el mismo protocolo que ya conoce Reachy Mini.

¿Cuáles son los defaults para VAD, STT y TTS?

El pipeline de voz en cascada tiene cuatro etapas: VAD, STT, LLM y TTS. Para tres de ellas, Hugging Face deja defaults sólidos: Silero VAD, Parakeet-TDT 0.6B v3 para transcripción y Qwen3-TTS para síntesis. Son opciones opinadas, intercambiables si tenés preferencia distinta.

¿Qué LLM elegir?

El LLM es la capa con mayor impacto sobre la latencia y el rendimiento general. Hay dos rutas: correr un modelo localmente (llama.cpp, MLX, Transformers, vLLM) o usar un servidor con Responses API (OpenAI, Gemini, HF Inference Endpoints, llama.cpp, vLLM, etc).

El cuello de botella principal es la latencia de inferencia. Por eso, el motor soporta una modalidad donde el LLM vive en un proceso aparte mientras hable el protocolo Responses API. Se levantan dos terminales: una con el modelo, otra con el voice loop, comunicadas por HTTP.

Opción 1: llama.cpp en una terminal, speech-to-speech en otra

Terminal 1:

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

Terminal 2:

Código
speech-to-speech --mode realtime --stt parakeet-tdt --tts qwen3 --llm_backend responses-api --model_name "unsloth/Qwen3-4B-Instruct-2507-GGUF" --responses_api_base_url "http://127.0.0.1:8080/v1"

Opción 2: vLLM en una terminal, speech-to-speech en otra

Requiere vLLM ≥ 0.21.0. El soporte completo del protocolo Responses API, incluyendo streaming de tool-calls usado por speech-to-speech, llegó en 0.21.0.

Para servir un modelo con vLLM hacen falta tres flags:

  • --enable-auto-tool-choice
  • --tool-call-parser <parser> (ej. qwen3_coder para Qwen3 instruct, llama3_json para Llama 3, hermes para Hermes).
  • --default-chat-template-kwargs '{"enable_thinking":false}': desactiva el canal de razonamiento <think> en modelos que lo soportan. Para conversación natural conviene mantenerlo apagado, cada token de pensamiento es latencia que el usuario percibe como silencio antes de que el robot hable.

Opción 3: Hugging Face Inference Endpoints

Mismo protocolo, pero el modelo corre en GPU gestionada por Hugging Face. Apuntás el voice loop a la URL del endpoint con tu token HF_TOKEN.

Opción 4: Hugging Face Inference Providers

Sin gestionar endpoint propio, usando un Inference Provider. Hugging Face rutea el request a backends de terceros (Together, Fireworks, Replicate) desde una URL única.

Opción 5: OpenAI o compatible

Para probar contra un modelo frontier sin infraestructura, basta apuntar el mismo flag a OpenAI con --model_name "gpt-5.4" y el OPENAI_API_KEY. Los flags --responses_api_* funcionan igual con cualquier proveedor compatible (OpenRouter, Together, Fireworks).

¿Y si corro el LLM en el mismo proceso?

Opción A: LLM local en MLX (Apple Silicon)

En Mac, MLX es la vía con menos fricción para un modelo real con latencia razonable. Hugging Face recomienda Qwen3-4B-Instruct-2507, suficientemente chico para sentirse instantáneo en chips de la serie M y capaz de sostener conversación.

Código
speech-to-speech --llm_backend mlx-lm --model_name "mlx-community/Qwen3-4B-Instruct-2507-bf16"

El servidor escucha por defecto en ws://127.0.0.1:8765/v1/realtime.

Opción B: LLM local en Transformers (CUDA / CPU / MPS)

Misma idea pero con transformers puro. Útil si corrés CUDA, Linux o si querés intercambiar modelos libremente sin reconvertir pesos para MLX.

Código
speech-to-speech --llm_backend transformers --model_name "Qwen/Qwen3-4B-Instruct-2507"

¿Motor en el laptop, app en el robot?

Si el voice engine corre en el laptop y la conversation app vive en el Reachy Mini Wireless, lo único que cambia es la URL. El motor debe bindearse a una dirección LAN (no 127.0.0.1) y desde el robot se selecciona la IP del laptop (192.168.x.x o 10.x.x.x).

Cierre

Quedás con un voice loop completamente local: el robot escucha con Silero, transcribe con Parakeet-TDT 0.6B v3, piensa con el LLM elegido (MLX local, Transformers, un servidor vLLM o llama.cpp al lado, o un endpoint Responses API alojado) y responde con Qwen3-TTS.

Repositorios: huggingface/speech-to-speech y pollen-robotics/reachy_mini_conversation_app.