Agente de IA self-hosted no Proxmox: guia LXC 2026

Por que os homelabbers do Proxmox estão rodando agentes de IA em LXC

Se você já tem uma máquina Proxmox zumbindo embaixo da mesa com Pi-hole, Home Assistant e Nextcloud, adicionar um agente de IA self-hosted a essa stack é o próximo passo óbvio. A comunidade homelab convergiu em grande medida para a mesma resposta sobre como fazer isso: coloque o agente em um container LXC, não em uma VM, não no host cru. Um tutorial recente do Uptown4 e um texto muito compartilhado no dev.to sobre sete agentes autônomos num cluster Proxmox de 3 nós chegam ao LXC pela mesma razão: um container de agente fica ocioso com 200-400 MB de RAM e quase zero CPU, então você consegue rodar cinco a oito deles numa máquina de 16 GB sem sentir.

Este texto mostra como um agente de IA self-hosted no Proxmox realmente se parece em 2026: como dimensionar o LXC, se rodar Docker dentro dele ou ir nativo, como fazer backup para que uma atualização ruim não custe sua memória do agente, e onde o passthrough de GPU vale o esforço. É escrito para alguém que já conhece Proxmox e quer uma receita concreta, não uma introdução ao Proxmox.

LXC vs VM para um agente de IA: os números importam mesmo

A dúvida mais comum é se usar um container LXC ou uma VM QEMU completa. Para um agente de IA baseado em texto conversando com uma API de LLM na nuvem, o LXC ganha em todos os eixos que interessam a um homelabber.

A diferença de overhead é real. Um LXC Debian puro usa 30-60 MB de RAM antes de qualquer serviço, enquanto uma VM Debian com a mesma pegada usa 200-400 MB, principalmente porque o container não precisa de kernel convidado, QEMU ou estado de dispositivos virtio (fonte). O overhead de CPU fica em torno de 1-3% no LXC contra 5-15% nas VMs, e containers sobem em 1-3 segundos em vez de 30-90. Um cluster de produção relatou 180 containers LXC em hardware que antes tocava 35 VMs, uma densidade 5x maior.

Para um agente de IA isso importa de forma concreta. O runtime do agente em si é pequeno: um processo Python ou Node, um Postgres para estado e um listener de webhook. O trabalho pesado acontece na GPU de outra pessoa, no OpenAI, Anthropic ou uma VM Ollama local no mesmo host. O container é um coordenador leve, não uma carga. Pagar overhead de VM para hospedar um coordenador é dinheiro que você poderia gastar em mais agentes.

O único ponto em que as VMs ganham é isolamento. Se você não confia no código do agente ou nas suas extensões, uma VM é uma fronteira mais forte. Para um agente pessoal que você escreveu ou um runtime open source que você auditou, o modelo de kernel compartilhado do LXC dá conta.

A receita de referência: LXC Ubuntu 22.04, 2 núcleos, 2 GB, 8 GB de disco

O dimensionamento padrão para um primeiro agente de IA self-hosted no Proxmox é pequeno de propósito. Você sempre pode crescer o container e não há razão para reservar RAM que você não está usando.

Configuração	Valor	Por quê
Template	`ubuntu-22.04-standard`	A melhor base suportada para Docker, Node, Python
CPU	2 núcleos	Carga ociosa é trivial, mas chamadas ao LLM são picos de IO
RAM	2 GB	Folga suficiente para Postgres mais o processo do agente
Swap	512 MB	Seguro barato contra um pico de memória tipo Chrome
Disco	8 GB local-lvm	Cresça depois se adicionar um vector store em disco
Rede	vmbr0, DHCP	Atrás do seu roteador, não direto na WAN
Não privilegiado	Sim	Padrão; mantenha assim salvo se precisar de Docker
Features	`nesting=1, keyctl=1`	Só se você for rodar Docker dentro

Crie a partir da interface do Proxmox ou com pct create numa sessão SSH no host. Se você for rodar Docker dentro do container (ver a próxima seção), ative nesting e keyctl na criação, não depois; mudá-los mais tarde exige editar a config e reiniciar o container.

Depois do container no ar, endureça como qualquer caixa da família Debian. Um usuário não root com sudo, chaves SSH em vez de senhas, unattended-upgrades habilitado e o cliente Tailscale instalado se você quiser alcançá-lo pelo celular sem abrir uma porta no seu roteador.

Docker dentro do LXC, ou systemd nativo?

Existem duas filosofias para de fato rodar o processo do agente, e as duas funcionam.

Docker dentro do LXC. Você instala o Docker num container Ubuntu 22.04 não privilegiado com nesting habilitado e roda o agente a partir de um docker-compose.yml. Isso espelha o que a maioria dos runtimes de agente de IA self-hosted entrega, então você segue as instruções exatas do fornecedor. O custo é um pouco de complexidade: o container precisa ser criado com features: nesting=1,keyctl=1, e debugar às vezes vira perguntar se o problema é do container, do Docker ou do agente. O guia do CoSci sobre Docker num LXC do Proxmox cobre as flags necessárias em detalhe.

systemd nativo. Você pula o Docker por completo e instala o agente, seu runtime Python ou Node, e o Postgres direto no LXC como serviços systemd. É mais leve, mais fácil de raciocinar e se dá bem melhor com snapshots do LXC (você está fotografando um filesystem real, não uma pilha de camadas overlay). O custo é que nem todo agente open source publica instruções limpas de systemd, então você pode acabar traduzindo um Dockerfile para uma unit systemd na mão.

Para uma primeira montagem, Docker dentro do LXC é quase sempre a escolha pragmática, ele deixa você seguir o runtime escolhido sem desvio. Para um agente homelab de vida longa que você planeja atualizar por anos, systemd nativo vale o esforço. Veja nosso guia de agente de IA self-hosted em Docker para a forma do compose-file que ambos os caminhos alcançam.

Snapshots e backups: a única coisa que você não pode pular

Um agente de IA acumula memória: conversas, embeddings, tarefas agendadas, preferências por usuário. Um mês depois, esse estado vale mais que o próprio container. O Proxmox te dá duas ferramentas relacionadas mas distintas para protegê-lo, e vale ser explícito sobre a diferença: um snapshot não é um backup. Um snapshot mora no mesmo disco do container, então um SSD morto leva os dois.

A receita em escala homelab que aguenta na prática:

Snapshot antes de cada atualização. Na aba Snapshots do container, tire um logo antes de apt upgrade, antes de editar o docker-compose.yml, antes de virar uma feature flag. Voltar atrás é um clique se a atualização quebrar o loop de ferramentas do agente.
Backups noturnos para o Proxmox Backup Server. PBS é a ferramenta certa: faz deduplicação de comprimento variável, então sete backups noturnos de um LXC de 4 GB ocupam mais perto de 4 GB do que 28 GB. Rode o PBS numa segunda caixa pequena ou num NAS, não no próprio host Proxmox.
Modo snapshot, não modo stop. Para um agente com o qual as pessoas conversam no Telegram, o modo snapshot é o padrão certo: o container segue rodando durante o backup. O modo stop é mais seguro para bancos de dados mas perde mensagens que chegam.
Retenha com uma política. Uma retenção comum que funciona para agentes pessoais: guarde os últimos 3 backups, diários por 7 dias, semanais por 4 semanas, mensais por 6 meses. Teste o caminho de restore ao menos uma vez, antes de precisar de verdade.

Se você pular o PBS, ao menos mande arquivos do vzdump para um disco externo num cron. Perder a memória de um agente homelab por um disco morto é um jeito ruim de descobrir que snapshots nunca foram backups.

GPU passthrough: quase sempre não vale a pena

O sonho sedutor do homelab é uma GPU local rodando Ollama, junto com um agente LXC no Proxmox, para que a stack toda fique dentro de casa. É tecnicamente possível e, com o setup certo, gratificante. Mas seja honesto sobre o trade-off.

A maioria dos homelabs é limitada em banda para inferência local de verdade. Uma única RTX 3090 vai rodar um modelo de 32B a talvez 30-50 tokens por segundo, o que dá conta para chat mas fica lento para um agente que faz chamadas a ferramentas em loop. Qualquer coisa maior precisa de GPUs profissionais que custam mais que um carro usado. E o imposto operacional é real: módulos de kernel, esquisitices de PCIe passthrough, atualizações de driver que quebram o namespace do LXC, tudo com o que você não se inscreveu ao querer um assistente de IA no Telegram.

O padrão homelab pragmático em 2026 é o setup caixa pequena, cérebro grande em outro lugar. Rode o agente num LXC de 2 GB num Mini-PC usado de 200 dólares que gasta centavos de eletricidade, e deixe o modelo morar no OpenRouter, OpenAI ou Anthropic. Sua narrativa de privacidade é "o código do agente roda no meu hardware, a chamada à API é sem estado, o provedor não retém dados", o que é defensável e barato. Se depois você quiser modelos locais para tarefas específicas, coloque o Ollama numa VM irmã com passthrough de GPU e deixe o agente chamá-la como um provedor entre vários.

Quando Proxmox é a resposta errada

Proxmox é fantástico se você já se comprometeu com ele. Se não, seja honesto sobre se é isso que você realmente quer.

Você só quer um agente de IA no Telegram. Hospedagem gerenciada é um minuto e um café. Proxmox é um fim de semana e um Mini-PC usado. Veja nossa análise de preços de Hermes Agent self-hosted vs gerenciado.
Você ainda não roda Proxmox. A curva de aprendizado do Proxmox compensa para um homelab de 10 serviços, não para um único agente de IA. Um VPS de 5 dólares e Docker Compose te levam lá numa noite.
Você quer uma fronteira de segurança forte entre o agente e todo o resto da caixa. Use uma VM, não um LXC, ou uma máquina separada de vez.

A alternativa Hermify: mesma propriedade, sem container

Existe um caminho do meio no qual muitos homelabbers acabam depois de alguns ciclos de atualização. Rode o chato no Proxmox (Home Assistant, mídia, rede) e deixe um Hermes Agent gerenciado cuidar do lado de IA. Você fica com a mesma narrativa de "seus dados, sua chave de modelo, seu agente" sem um LXC para cuidar nem uma política de retenção do PBS para pensar. A Hermify gerencia a frota de containers, você traz sua chave OpenRouter ou OpenAI e o agente vive no Telegram em cerca de um minuto. Comece com a Hermify se essa troca soa mais interessante que outro nó no seu cluster.