Reachy Mini ejecuta conversaciones locales con IA | Keryc
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, MLX o transformers.
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
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 ejemplo qwen3_coder o llama3_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):
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-lm suele dar la mejor experiencia con latencia baja. Ejemplo:
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_url al 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) o ipconfig getifaddr en1 (ethernet)
Linux: hostname -I
Windows: ipconfig y 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=false si 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?
