Construyendo un asistente de voz LLM totalmente local para controlar mi hogar inteligente

Recepción del proyecto y construcciones similares

• Muchos comentaristas están construyendo asistentes de voz locales comparables, a menudo con Home Assistant como núcleo.
• Algunos usan solo modelos locales; otros prototipan primero con APIs de OpenAI/Mistral y luego apuntan a hacerlo local.
• Varias personas comparten pequeños wrappers o bibliotecas para simplificar la llamada a funciones y la integración con Python o Home Assistant.

Hardware, rendimiento y cuantización

• Se pone mucho énfasis en usar GPUs: el principal cuello de botella es el tiempo hasta el primer token, especialmente con prompts grandes que incluyen el estado completo del hogar.
• Las GPUs de gama media (p. ej., tarjetas de consumo de 16 GB) se ven como buenas en VRAM por dólar y con menor consumo que tarjetas usadas de centros de datos, que pueden exigir demasiado a las fuentes de alimentación y a los UPS.
• La cuantización a 4 bits (GPTQ, AWQ) se usa comúnmente; la gente informa ~17 tok/s en modelos tipo Mixtral como “usable pero no ágil”.
• Algunos ejecutan modelos de 7B–20B en GPUs de 8–12 GB o incluso solo con CPU para experimentar.

Comportamiento del modelo, gramáticas y salida estructurada

• Varios comentarios sugieren usar gramáticas (GBNF/BNF en llama.cpp) o bibliotecas que restringen la salida a JSON válido, en lugar de depender solo del formato indicado en el prompt.
• Se debate si la falta de prompts de sistema en Mixtral lo hace más vulnerable a la inyección de prompts; algunos sugieren variantes afinadas u otros modelos con mejor soporte de “system”.
• Hay debate sobre la capacidad de modelos de ~7B: algunos los encuentran casi a la altura de GPT‑4 para tareas concretas; otros los consideran poco fiables para automatización compleja y estructurada.

Integración con Home Assistant y dirección futura

• El proyecto Home Assistant tiene la intención de incluir funcionalidad basada en LLM, pero quiere:
  • Una API local para LLM más rica y estandarizada (más allá de “simplemente copiar OpenAI”).
  • Llamada a funciones robusta o gramáticas restringidas para que las acciones JSON sean siempre directamente seguras de ejecutar.
• Ideas: libros de reglas en lenguaje natural para el comportamiento del hogar, automatizaciones sugeridas por IA a partir del historial y cambio con un solo clic entre modelos locales mediante complementos.
• Se plantean preocupaciones sobre los requisitos de hardware; otros señalan que HA es modular y que LLMs/STT/TTS pueden ejecutarse en máquinas separadas y más potentes.

Seguridad, protección y red

• Varios comentaristas se preocupan por los LLMs controlando dispositivos físicos (hornos, cerraduras, puertas). Las mitigaciones sugeridas incluyen:
  • Controles de seguridad codificados a mano sobre las salidas.
  • Limitar qué servicios/entidades puede invocar el LLM.
  • Controles tipo ACL/RBAC, a veces mediante APIs no documentadas de HA.
• Algunos temen modelos maliciosos o “durmientes”; otros argumentan que el riesgo real es la exposición general del IoT, no los LLMs en particular.
• Exponer Home Assistant directamente a Internet es controvertido; algunos lo hacen detrás de WAFs/VLANs, pero la mayoría prefiere VPN/WireGuard.

Canal de voz y UX

• La latencia es una preocupación recurrente: 8+ segundos desde el habla hasta la primera respuesta se considera ampliamente marginal.
• Sugerencias:
  • Reglas de intención/gramática en el front-end para comandos simples.
  • Caché de frases frecuentes e incluso de audio TTS.
  • Respuestas tempranas de “un momento” y transmisión de la respuesta a TTS.
• La palabra de activación y la calidad del micrófono siguen siendo problemas prácticos; los dispositivos ESP32-S3 con modelos de wake-word y micrófonos I2S son experimentos populares.