Un proceso basta: por qué seis contenedores sobran para autoalojar tu IA
El despliegue típico de un asistente de IA en casa levanta seis servicios para cinco usuarios. Un análisis defiende lo contrario: un único proceso sobre SQLite.
Abre el compose de casi cualquier asistente de IA autoalojado y te encuentras lo mismo: el contenedor de la aplicación, Redis para la cola, Postgres para el estado, un worker, normalmente una base de datos vectorial y, de propina, un proxy inverso. Seis servicios para una casa con cinco personas.
La pregunta es qué te compra esa arquitectura a esa escala. Una cola existe para que el trabajo sobreviva a un reinicio y para poder escalar workers en horizontal. No estás escalando workers en horizontal: tienes una máquina debajo de un escritorio. El broker se justifica cuando productores y consumidores crecen por separado, cuando la tarea tiene que sobrevivir al proceso que la aceptó o cuando varios servicios comparten los mismos eventos. Son problemas reales a escala real. Con cinco usuarios no aplica ninguno, y los has pagado todos igual: seis cosas que pueden fallar, seis ficheros de log, seis rondas de actualizaciones y un síntoma en la interfaz cuya causa está a tres saltos, en un contenedor que no estabas mirando.
Un proceso, sin broker
Octop, de TencentCloud, va por el otro camino. Un solo proceso sirve el panel web, el backend de la CLI, todos los canales de chat y el planificador de tareas. No hay broker. Cada superficie entra por el mismo manejador en proceso, y el estado completo se reconstruye desde una base de datos SQLite en el arranque.
Ahí está la parte que hace el trabajo. La tolerancia a reinicios suele venir de colas durables y un apagado cuidadoso; aquí viene de que el proceso no guarda nada autoritativo. Lo matas como quieras: al arrancar lee la base de datos y se recompone solo. No hay nada en memoria que merezca conservarse, que es una propiedad bastante más fuerte que conservarlo bien.
SQLite en modo WAL no es aquí un compromiso. Para una carga de muchas lecturas concurrentes y pocas escrituras sobre una sola máquina es simplemente la elección correcta: sin pool de conexiones, sin segundo demonio, sin ajustes, y el backup es copiar un fichero. Octop ofrece Postgres como opción, no como suposición. Ese orden es la señal de que alguien miró la carga real antes de copiar una arquitectura de referencia.
Dónde se rompe
Los límites son reales y toca decirlos. Un proceso es un dominio de fallo único: no puedes poner la pasarela de chat en una máquina y el runtime del agente en otra. Y hay un número de usuarios a partir del cual esto deja de ser elegante y empieza a ser un cuello de botella. Para un hogar o un equipo de cinco, ese techo es teórico y la simplicidad operativa se cobra a diario; con cincuenta usuarios concurrentes, la forma es la equivocada.
Hay además un detalle práctico que se salta a menudo: antes de autoalojar cualquier cosa con acceso remoto, tu ancho de banda de subida decide si es usable, y una prueba de velocidad responde eso antes de descubrirlo a las malas.
La discusión de fondo no es Octop. Es si seguimos desplegando arquitecturas de referencia de seis servicios para cargas que nunca las van a necesitar. El texto original avisa de que hay dos advertencias que conocer antes de lanzar el instalador, aunque no las detalla en el resumen, y no incluye ni demo ni cifras de rendimiento medidas por un tercero.
