Como rodar um agente de IA em uma VM e manter o modelo na GPU do host: o esquema com o Strata

Um agente que instala pacotes, executa scripts e edita arquivos sozinho economiza horas de trabalho. Mas, na prática, você está dando a um estagiário permissões de administrador no seu notebook. Uma alucinação em um script de limpeza ou um postinstall em um repositório desconhecido, e as consequências aparecem no seu sistema principal.

A saída óbvia é uma máquina virtual. O problema é que, em geral, não dá para repassar a GPU a ela, e um modelo local sem placa de vídeo roda de forma torturantemente lenta. Uma análise publicada no Habr propõe separar o "cérebro" das "mãos".

Como funciona o esquema

São três blocos.

O host cuida da inferência. Nele roda o aplicativo desktop Strata, que sobe uma API compatível com a OpenAI (porta padrão: 47831). Código de terceiros não chega aqui nem é executado aqui.

A máquina virtual em modo NAT é a sandbox. Nela ficam o VS Code e o plugin Cline; é ali também que se extraem arquivos, se instalam dependências e se executam scripts suspeitos. Se algo der errado, a VM volta de um snapshot em cerca de cinco segundos.

O gateway de rede redireciona à força todo o tráfego do hipervisor no host para um proxy SOCKS, por meio do Proxifier. Se o código analisado tiver telemetria ou uma conexão reversa, só o IP do proxy sai para fora, e não o da rede doméstica.

Um exemplo simples: você quer analisar rapidamente um repositório desconhecido do GitHub. Clona o projeto na VM e pede ao agente que compile e rode os testes. O modelo processa na placa de vídeo do host, mas tudo é executado dentro da sandbox.

Onde tudo costuma quebrar

O mais interessante aqui são as duas armadilhas de rede, mais do que a ideia em si.

A primeira: os servidores locais de modelos (Strata, Ollama, LM Studio) escutam por padrão apenas em 127.0.0.1. Da VM, eles não aparecem nem pelo gateway 10.0.2.2. O autor resolve isso com o portproxy, recurso nativo do Windows. Um único comando netsh interface portproxy redireciona a porta, e uma regra de firewall a libera. O teste é simples: curl.exe 10.0.2.2:47831/v1/models, executado dentro da VM, deve retornar um JSON com a lista de modelos. Dele se tira o campo id exato, que será necessário no Cline.

A segunda armadilha é menos óbvia. Quando a VM acessa 10.0.2.2, quem acaba processando o pacote é o svchost.exe do sistema. O Proxifier o intercepta e tenta enviá-lo a um endereço local por meio do servidor SOCKS remoto. A conexão trava. A solução é uma regra de exceção: aplicativos — Any (justamente porque o tráfego passa pelo svchost), hosts — 10.0.2.2, 127.0.0.1, localhost e sub-redes locais, porta — 47831, ação — Direct. A regra precisa ficar acima da regra geral do hipervisor. Como a porta é fixa, o resto da saída da VM para a internet continua passando somente pelo proxy.

No Cline, as configurações são estas: provedor OpenAI Compatible, Base URL 10.0.2.2:47831/v1, chave — qualquer palavra não vazia, Model ID — o nome retornado na resposta do servidor. Vale desativar modelos separados para os modos Plan e Act, para não duplicar a configuração.

O que considerar na prática

O isolamento depende de disciplina. Na VM, desative as pastas compartilhadas e a área de transferência bidirecional; do contrário, a sandbox perde o sentido. Não faça login em contas pessoais nem mantenha ali chaves e tokens reais: o Auto-approve do Cline permite ao agente tudo o que estiver acessível dentro da máquina.

Há também um ponto fraco que o artigo não aborda. O comando portproxy usa listenaddress=0.0.0.0, ou seja, a porta escuta em todas as interfaces do host, e a regra de firewall do exemplo não restringe a origem. Se você usa uma rede Wi-Fi compartilhada, vale limitar a regra à sub-rede da VM por meio do parâmetro remoteip ou vincular o listenaddress ao endereço do adaptador virtual. Essa é uma conclusão nossa, e não uma recomendação do autor. Além disso, a VM não oferece garantia absoluta: a fuga do hipervisor é rara, mas possível, e o snapshot recente precisará ser atualizado.

O resumo para o desenvolvedor: o que você precisa não é de um agente "inteligente", e sim de um agente na jaula. O esquema se monta em uma noite com software gratuito e serve para auditar código de terceiros, analisar pacotes suspeitos e testar o modo autônomo. Vale exportar o perfil do Proxifier e criar um snapshot limpo logo depois de verificar o IP externo.