En serio, ¿quieres que tu robot hable y piense sin enviar nada a la nube? Ahora puedes: Reachy Mini puede conversar totalmente en local usando el stack speech-to-speech de Hugging Face. Audio que no sale de tu red, sin llaves de API, sin costos por uso. Suena bien, ¿no?
Qué hace este artículo
Te guío paso a paso para levantar un backend de voz local para Reachy Mini usando una cascada VAD -> STT -> LLM -> TTS que expone un WebSocket compatible con /v1/realtime. Es un enfoque técnico, pero práctico: ejemplo de comandos, por qué elegir ciertos modelos, y cómo optimizar latencia para tener conversaciones fluidas.
La idea central: cascada speech-to-speech
Una cascada separa la tubería en cuatro etapas claras: VAD (detección de voz), STT (transcripción), LLM (razonamiento / diálogo) y TTS (voz de salida). Eso te da control total: cambias VAD, pruebas otro STT, subes o bajas la calidad del TTS. ¿La ventaja? Privacidad, cero costos de API y flexibilidad para mejorar piezas cuando aparezcan modelos nuevos.
Hugging Face recomienda una combinación que funciona muy bien hoy:
- VAD: Silero VAD v5 - pequeño, preciso y funciona en CPU.
- STT: Parakeet-TDT - streaming-friendly y rápido.
- LLM: opciones locales con
llama.cpp,vLLM,MLXotransformers. - TTS: Qwen3-TTS - expresivo, multilingüe y con baja latencia.
Levantar el servidor LLM (ejemplo con llama.cpp)
Si vas por llama.cpp usa el binario llama-server. Instalarlo es simple (brew o winget), luego ejecutas:
llama-server -hf ggml-org/gemma-4-E4B-it-GGUF -np 2 -c 65536 -fa on --swa-full
¿Qué hacen esos flags?
-hf ggml-org/gemma-4-E4B-it-GGUF- descarga el modelo desde el Hub la primera vez y lo usa desde cache luego.-np 2- dos ranuras paralelas para atender interrupciones sin bloquear la primera solicitud.-c 65536- ventana de contexto de 64k compartida entre ranuras, útil para conversaciones largas.-fa on- flash attention: más rápido y menos memoria en hardware moderno.--swa-full- mantiene la cache de atención sliding-window para procesar prompts más rápido, a cambio de algo de RAM.
La primera vez tarda en descargar el modelo; después arranca rápido.
Iniciar el motor de voz local (speech-to-speech)
Instala la librería y arranca el motor en modo local mientras el LLM está corriendo en otra terminal:
pip install speech-to-speech
speech-to-speech --responses_api_base_url "http://127.0.0.1:8080" --responses_api_api_key "" --mode local
La primera ejecución descargará Parakeet y Qwen3-TTS; luego los inicios son rápidos. El CLI arranca un WebSocket en /v1/realtime que Reachy Mini conoce.
Modo realtime con backend separado (Responses API)
Si prefieres que el LLM esté en otro proceso o máquina, el speech-to-speech habla el protocolo Responses API. Ejemplo con llama.cpp server + cliente speech-to-speech:
Terminal 1: llama.cpp
llama-server -hf ggml-org/gemma-4-E4B-it-GGUF -np 2 -c 65536 -fa on --swa-full
Terminal 2: cliente speech-to-speech en modo realtime
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"
Para menor latencia en sistemas más avanzados se recomienda vLLM. Cuando uses vLLM necesitas tres flags casi obligatorios:
--enable-auto-tool-choice--tool-call-parser <tool_parser_name>- selecciona el parser por familia de modelos (por ejemploqwen3_coderollama3_json).--default-chat-template-kwargs '{"enable_thinking":false}'- desactiva el canal de razonamiento que genera tokens de pensamiento que el usuario percibe como silencio.
Ejemplo de servidor vLLM para Qwen3-4B-Instruct-2507 con MTP (Multi-Token Prediction):
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}'
MTP ayuda mucho a la latencia de extremo a extremo; actívalo si el modelo lo soporta.
Cliente speech-to-speech que apunta a vLLM:
speech-to-speech \
--mode realtime \
--stt parakeet-tdt \
--tts qwen3 \
--llm_backend responses-api \
--model_name "Qwen/Qwen3-4B-Instruct-2507" \
--responses_api_base_url "http://127.0.0.1:8000/v1"
Si prefieres usar un endpoint gestionado o proveedores externos, el mismo flag --responses_api_base_url se adapta: cambia la URL y agrega la clave --responses_api_api_key cuando sea necesario.
Otras opciones de backend LLM
- MLX en Mac: si estás en un Mac con chip M la opción
mlx-lmsuele dar la mejor experiencia con latencia baja. Ejemplo:
speech-to-speech --llm_backend mlx-lm --model_name "mlx-community/Qwen3-4B-Instruct-2507-bf16"
-
Transformers en CUDA/Linux: si tienes una GPU en Linux y quieres cambiar modelos sin convertir pesos, usa
--llm_backend transformers. -
Usar un proveedor: apunta
--responses_api_base_urlal endpoint del proveedor o al router de Hugging Face para probar modelos más grandes sin infra propia.
Conectar Reachy Mini desde otra máquina
Si el engine de voz corre en tu laptop y Reachy Mini está en la red, asegúrate de que el servidor escuche en una dirección LAN y no solo en 127.0.0.1. Desde la app de conversación de Reachy seleccionas la IP de tu laptop.
Cómo encontrar tu IP:
- macOS:
ipconfig getifaddr en0(wifi) oipconfig getifaddr en1(ethernet) - Linux:
hostname -I - Windows:
ipconfigy busca IPv4 Address
Usa la IP 192.168.x.x o 10.x.x.x. Si aparece 169.254.x.x no estás en la red.
Trade-offs y optimizaciones prácticas
Cada etapa tiene compensaciones. Quieres la menor latencia posible para que el robot responda natural, pero también buena calidad de voz y transcripción. Algunas recomendaciones rápidas:
- Optimiza el LLM para latencia: modelos pequeños bien afinados (Qwen3-4B, Gemma pequeños) o MTP en vLLM.
- Si tu caso es un solo idioma, prioriza modelos STT/TTS optimizados para ese idioma para ganar calidad.
- Mantén
enable_thinking=falsesi buscas conversación fluida sin pausas largas por razonamiento interno.
En mi experiencia probando esta pila en un Mac M1 y en una laptop con GPU, MLX se sintió instantáneo en el primero, mientras que vLLM con MTP redujo la latencia en GPU de servidor significativamente. Lo bueno es que puedes probar y cambiar piezas sin rehacer toda la arquitectura.
Para terminar
Si te interesa privacidad y control sobre la experiencia conversacional de tu robot, correr todo en local es un salto pragmático. No es magia: son componentes concretos que puedes instalar, probar y reemplazar cuando aparezcan mejores modelos. ¿Qué combinación vas a probar primero?