El 27 de mayo de 2026, los autores Amir Mahla y Andres Marafioti publicaron una guía práctica para hacer que Reachy Mini mantenga conversaciones enteramente en local, sin enviar audio ni transcripciones a servicios en la nube. La propuesta permite instalar y enlazar toda la pila conversacional en el equipo del usuario y conectar la interfaz del robot a ese servidor local para que el flujo de audio y texto se procese dentro de la red doméstica o del laboratorio.
El núcleo técnico de la guía es la librería llamada speech — to-speech, que organiza una cascada de procesamiento VAD → STT → LLM → TTS y expone un WebSocket compatible con la Realtime API en la ruta /v1/realtime. Esa arquitectura en cascada orquesta detección de voz, reconocimiento, inferencia del modelo de lenguaje y síntesis de voz, y ofrece un protocolo conocido por la interfaz de Reachy Mini, de modo que la conexión del robot no requiere cambios profundos en la UI.
Para servir el modelo de lenguaje en local la guía recomienda utilizar llama.cpp; el comando de ejemplo que proponen es: llama — server -hf ggml-org/gemma — 4-E4B-it-GGUF -np 2 -c 65536 — fa on --swa-full. En el primer arranque el servidor descarga el modelo desde el Hub y en lanzamientos posteriores reutiliza la caché local. Las banderas sugeridas buscan mejorar la concurrencia, ampliar la ventana de contexto y habilitar optimizaciones como flash attention y caching de atención deslizante, lo que disminuye latencias en cargas multisesión.
La instalación y puesta en marcha del motor conversacional se describe con pasos concretos. Primero se instala la librería con uv pip install speech — to-speech; con el LLM ya en ejecución, se arranca el servicio de conversación local usando speech — to-speech --responses_api_base_url "http://127.0.0.1:8080" --responses_api_api_key "" --mode local. En ese primer inicio se descargan Parakeet y Qwen3TTS; en ejecuciones posteriores esos componentes se cargan desde la caché para acelerar arranques sucesivos.
La guía explica también cómo conectar Reachy Mini: abrir la aplicación de escritorio del robot, lanzar la app de conversación y, desde la interfaz, seleccionar el modo local mediante “edit connection” en la configuración del backend HF. Tras verificar que la UI reconoce el modo local, se puede volver a ejecutar speech — to-speech sin la opción --mode local para que el robot sirva la conversación desde el mismo equipo que ejecuta la interfaz.
En cuanto a recomendaciones por componente, los autores proponen Silero VAD v5 Tiny para detección de voz (ligero y preciso en CPU), Parakeet — TDT Streaming como motor STT (rápido y con buena calidad en inglés) y Qwen3 — TTS para síntesis (expresivo, multilingüe y de baja latencia). Señalan que estas son elecciones opinadas: la arquitectura en cascada está diseñada para permitir intercambiar cualquier módulo a medida que aparezcan modelos nuevos o más adecuados para un caso de uso particular.
La guía sitúa la aproximación local frente a alternativas abiertas y remotas: la cascada sigue siendo la opción más flexible en el ecosistema de código abierto y, con la configuración adecuada, también puede lograr bajas latencias. Para el LLM se admiten opciones locales (llama.cpp, MLX, Transformers, vLLM) o remotas mediante la Responses API (por ejemplo OpenAI, Gemini, HF Inference Endpoints), lo que permite separar la inferencia del lazo de voz y combinar recursos según disponibilidad y rendimiento.
Los beneficios de ejecutar todo en local se resumen en tres ventajas directas: privacidad (el audio no abandona la red local), ahorro en costes de uso de APIs (no hay tarifas por minuto o por token) y control total sobre la pipeline y sus actualizaciones. La librería speech — to-speech arranca un servidor WebSocket que implementa el mismo protocolo que Reachy Mini ya conoce, facilitando la transición sin rehacer la lógica de conexión del robot.
Por último, los autores advierten sobre límites y ajustes necesarios: existen compromisos entre velocidad y calidad en cada etapa — hay TTS más rápidos pero de menor calidad y STT más precisos pero más lentos— y recomiendan optimizar según el caso (soporte multilingüe frente a un único idioma objetivo). Aportan ejemplos de despliegue en dos terminales (por ejemplo, llama.cpp en uno y speech — to-speech en el otro) y muestran comandos para integrar la Responses API cuando convenga mitigar la latencia del LLM o delegar la inferencia a servicios remotos como alternativa temporal.
Fuentes
Respuestas (0)
Aún no hay respuestas en este tema.
