Agente IA autoalojado en Proxmox: la guía LXC 2026

Por qué los homelabbers de Proxmox están ejecutando agentes IA en contenedores LXC

Si ya tienes una máquina Proxmox zumbando bajo el escritorio con Pi-hole, Home Assistant y Nextcloud, añadir un agente IA autoalojado a esa pila es el siguiente paso obvio. La comunidad homelab ha convergido en gran medida en la misma respuesta sobre cómo hacerlo: mete el agente en un contenedor LXC, no en una VM, no en el host desnudo. Un tutorial reciente de Uptown4 y un artículo muy compartido en dev.to sobre siete agentes autónomos en un cluster Proxmox de 3 nodos llegan a LXC por la misma razón: un contenedor de agente consume 200-400 MB de RAM en reposo y casi cero CPU, así que puedes ejecutar de cinco a ocho en una máquina de 16 GB sin notarlo.

Este artículo explica cómo se ve realmente un agente IA autoalojado en Proxmox en 2026: cómo dimensionar el LXC, si ejecutar Docker dentro o ir nativo, cómo hacer backup para que una mala actualización no te cueste la memoria del agente, y dónde merece la pena el passthrough de GPU. Está escrito para alguien que ya conoce Proxmox y quiere una receta concreta, no una introducción a Proxmox.

LXC vs VM para un agente IA: los números importan de verdad

La pregunta más habitual es si usar un contenedor LXC o una VM QEMU completa. Para un agente IA basado en texto que habla con una API de LLM en la nube, LXC gana en todos los ejes que le importan a un homelabber.

La diferencia de sobrecarga es real. Un LXC Debian pelado consume 30-60 MB de RAM antes de arrancar ningún servicio, mientras que una VM Debian con la misma huella consume 200-400 MB, sobre todo porque el contenedor no necesita kernel invitado, QEMU ni estado de dispositivos virtio (fuente). La sobrecarga de CPU se sitúa en el 1-3 % para LXC frente al 5-15 % para VMs, y los contenedores arrancan en 1-3 segundos en lugar de 30-90. Un cluster de producción reportó 180 contenedores LXC en hardware que antes ejecutaba 35 VMs, una mejora de densidad de 5x.

Para un agente IA esto importa de forma concreta. El runtime del agente es pequeño: un proceso Python o Node, un Postgres para el estado y un listener de webhook. El trabajo pesado ocurre en la GPU de otro, en OpenAI, Anthropic o una VM Ollama local en el mismo host. El contenedor es un coordinador ligero, no una carga. Pagar la sobrecarga de una VM para alojar un coordinador es dinero que podrías gastar en más agentes.

El único punto donde ganan las VMs es en aislamiento. Si no confías en el código del agente ni en sus extensiones, una VM es una frontera más fuerte. Para un agente personal que hayas escrito tú o un runtime open source que hayas auditado, el modelo de kernel compartido de LXC está bien.

La receta de referencia: LXC Ubuntu 22.04, 2 núcleos, 2 GB, 8 GB de disco

El dimensionado por defecto para un primer agente IA autoalojado en Proxmox es pequeño a propósito. Siempre puedes hacer crecer el contenedor y no hay razón para reservar RAM que no estás usando.

Ajuste	Valor	Por qué
Plantilla	`ubuntu-22.04-standard`	La mejor base soportada para Docker, Node, Python
CPU	2 núcleos	La carga en reposo es trivial, pero las llamadas al LLM son picos de IO
RAM	2 GB	Suficiente margen para Postgres más el proceso del agente
Swap	512 MB	Seguro barato ante un pico de memoria estilo Chrome
Disco	8 GB local-lvm	Crécelo luego si añades un vector store en disco
Red	vmbr0, DHCP	Detrás de tu router, no directamente en WAN
No privilegiado	Sí	Por defecto; mantenlo salvo que necesites Docker
Features	`nesting=1, keyctl=1`	Solo si vas a ejecutar Docker dentro

Créalo desde la interfaz de Proxmox o con pct create desde una sesión SSH en el host. Si vas a ejecutar Docker dentro del contenedor (ver la siguiente sección), activa nesting y keyctl al crearlo, no después; cambiarlos más tarde implica editar la configuración y reiniciar el contenedor.

Una vez levantado, endurécelo como cualquier caja de la familia Debian. Un usuario no root con sudo, claves SSH en lugar de contraseñas, unattended-upgrades activo y el cliente Tailscale instalado si quieres alcanzarlo desde el móvil sin abrir un puerto en tu router.

¿Docker dentro del LXC o systemd nativo?

Hay dos filosofías sobre cómo ejecutar el proceso del agente y ambas funcionan.

Docker dentro del LXC. Instalas Docker en un contenedor Ubuntu 22.04 no privilegiado con nesting activado y ejecutas el agente desde un docker-compose.yml. Esto refleja lo que envían la mayoría de runtimes de agente IA autoalojados, así que sigues las instrucciones exactas del proveedor. El coste es un poco de complejidad: el contenedor debe crearse con features: nesting=1,keyctl=1 y depurar a veces implica preguntarse si el problema es del contenedor, de Docker o del agente. La guía de CoSci sobre Docker en un LXC de Proxmox cubre las flags necesarias en detalle.

systemd nativo. Te saltas Docker por completo e instalas el agente, su runtime Python o Node y Postgres directamente en el LXC como servicios systemd. Es más ligero, más fácil de razonar y encaja mucho mejor con los snapshots de LXC (estás fotografiando un sistema de ficheros real, no una pila de capas overlay). El coste es que no todos los agentes open source publican instrucciones limpias para systemd, así que puede que acabes traduciendo un Dockerfile a un unit de systemd tú mismo.

Para un primer montaje, Docker dentro del LXC es casi siempre la elección pragmática, te permite seguir el runtime elegido sin desviación. Para un agente homelab de larga vida que planeas actualizar durante años, systemd nativo merece el esfuerzo. Consulta nuestra guía de agente IA autoalojado en Docker para ver la forma del compose-file al que llegan ambos caminos.

Snapshots y backups: lo único que no puedes saltarte

Un agente IA acumula memoria: conversaciones, embeddings, trabajos programados, preferencias por usuario. Un mes después, ese estado vale más que el contenedor en sí. Proxmox te da dos herramientas relacionadas pero distintas para protegerlo, y merece la pena ser explícitos con la diferencia: un snapshot no es un backup. Un snapshot vive en el mismo disco que el contenedor, así que un SSD muerto se lleva los dos.

La receta a escala homelab que aguanta en la práctica:

Snapshot antes de cada actualización. Desde la pestaña Snapshots del contenedor, haz uno justo antes de apt upgrade, antes de editar docker-compose.yml, antes de activar un feature flag. Volver atrás es un clic si la actualización rompe el bucle de herramientas del agente.
Backups nocturnos a Proxmox Backup Server. PBS es la herramienta correcta: hace deduplicación de longitud variable, así que siete backups nocturnos de un LXC de 4 GB ocupan más cerca de 4 GB que de 28 GB. Ejecuta PBS en una segunda caja pequeña o en un NAS, no en el propio host Proxmox.
Modo snapshot, no modo stop. Para un agente con el que la gente habla en Telegram, el modo snapshot es el correcto por defecto: el contenedor sigue corriendo durante el backup. El modo stop es más seguro para bases de datos pero pierde mensajes entrantes.
Retén con una política. Una retención común que funciona para agentes personales: guarda los últimos 3 backups, diarios durante 7 días, semanales durante 4 semanas, mensuales durante 6 meses. Prueba el camino de restauración al menos una vez, antes de necesitarlo de verdad.

Si te saltas PBS, al menos manda los archivos de vzdump a un disco externo con un cron. Perder la memoria de un agente homelab por un disco muerto es una mala forma de descubrir que los snapshots nunca fueron backups.

Passthrough de GPU: casi nunca merece la pena

El sueño seductor del homelab es una GPU local corriendo Ollama, emparejada con un agente LXC en Proxmox, para que toda la pila se quede dentro de casa. Es técnicamente posible y, con el setup adecuado, satisfactorio. Pero sé honesto con el trade-off.

La mayoría de homelabs están limitados en ancho de banda para inferencia local seria. Una única RTX 3090 ejecutará un modelo de 32B a unos 30-50 tokens por segundo, lo cual se siente bien para un chat pero lento para un agente que hace llamadas a herramientas en bucle. Cualquier cosa mayor necesita GPUs profesionales que cuestan más que un coche usado. Y el impuesto operativo es real: módulos de kernel, peculiaridades del passthrough PCIe, actualizaciones de driver que rompen el namespace del LXC, cosas todas que no firmaste al querer un asistente IA en Telegram.

El patrón homelab pragmático en 2026 es el setup caja pequeña, cerebro grande en otro sitio. Ejecuta el agente en un LXC de 2 GB sobre un Mini-PC usado de 200 dólares que gasta céntimos de electricidad, y deja que el modelo viva en OpenRouter, OpenAI o Anthropic. Tu narrativa de privacidad es "el código del agente corre en mi hardware, la llamada a la API es sin estado, el proveedor no retiene datos", que es defendible y barata. Si más adelante quieres modelos locales para tareas concretas, mete Ollama en una VM hermana con passthrough de GPU y deja que el agente la llame como un proveedor más entre varios.

Cuándo Proxmox es la respuesta equivocada

Proxmox es fantástico si ya te has comprometido con él. Si no, sé honesto sobre si es lo que realmente quieres.

Solo quieres un agente IA en Telegram. El hosting gestionado es un minuto y un café. Proxmox es un fin de semana y un Mini-PC usado. Mira nuestro análisis de precios de Hermes Agent autoalojado vs gestionado.
Todavía no ejecutas Proxmox. La curva de aprendizaje de Proxmox merece la pena para un homelab de 10 servicios, no para un solo agente IA. Un VPS de 5 dólares y Docker Compose te llevan ahí en una tarde.
Quieres una frontera de seguridad fuerte entre el agente y todo lo demás de la caja. Usa una VM, no un LXC, o una máquina separada por completo.

La alternativa Hermify: misma propiedad, sin contenedor

Hay un camino intermedio en el que muchos homelabbers acaban tras unos ciclos de actualización. Ejecuta lo aburrido en Proxmox (Home Assistant, media, red) y deja que un Hermes Agent gestionado se encargue del lado IA. Consigues la misma narrativa de "tus datos, tu clave de modelo, tu agente" sin un LXC que cuidar ni una política de retención de PBS que pensar. Hermify gestiona la flota de contenedores, tú traes tu clave de OpenRouter u OpenAI y el agente vive en Telegram en aproximadamente un minuto. Empieza con Hermify si ese trade te resulta más interesante que otro nodo en tu cluster.