- Reúne em um único repositório a configuração de hardware, ajustes de switch PCIe e configuração de execução em Docker para rodar localmente LLMs de última geração e conversão de voz para texto
- O orçamento de cerca de US$ 2 mil mira uma configuração com 2× RTX 3090, garantindo 48 GB de VRAM para executar o Qwen3.6-27B e STT local baseado no
whisper-large-v3
- O orçamento de cerca de US$ 40 mil pressupõe uma configuração com 4× RTX PRO 6000 Blackwell Workstation, garantindo 384 GB de VRAM para obter inteligência de modelo bem próxima à do Claude Opus
- O sistema real com 4× RTX 6000 Pro combina uma máquina baseada em EPYC/DDR4 usados com um switch PCIe Gen4 c-payne, processando a comunicação P2P entre GPUs dentro do fabric do switch em vez de passar pelo root complex da CPU
- Com BIOS, GRUB, ACS e limites de energia ajustados, o P2P chega ao line rate Gen4, com 27,5 GB/s unidirecional, 50,4 GB/s bidirecional e latência de 0,37–0,45 µs
Faixas de orçamento para executar LLMs localmente
- Esta configuração é voltada a usuários que querem executar localmente modelos de última geração e conversão de voz para texto
- O repositório inclui o hardware em uso, os motivos da compra, dicas de configuração, a forma de executar STT local e a configuração de execução de modelos baseada em contêineres Docker
- Há uma observação de que o conteúdo, exceto a tabela do README, não foi escrito por IA
-
Configuração de cerca de US$ 2 mil
- Propõe uma configuração com 2× RTX 3090, totalizando 48 GB de VRAM
- Nessa configuração, é possível executar o Qwen3.6-27B
- O STT local usa o whisper-large-v3, com o harness multiplataforma
stt para acesso
./runners/stt traz uma configuração de STT pronta para execução que presume haver apenas cerca de 11 GB de VRAM em uma GPU Nvidia- O STT local é tratado como uma ferramenta mais conveniente do que serviços hospedados
-
Configuração de cerca de US$ 40 mil
- Pressupõe uma configuração com 4× RTX 6000 Pro, totalizando 384 GB de VRAM
- Nessa faixa de preço, ela é descrita como uma etapa em que se obtém inteligência de modelo bem próxima à do Claude Opus
- Em 2026-07, o modelo atual mais indicado para 4× RTX6kPRO é apresentado como
GLM-5.2-Int8Mix-NVFP4-REAP-594B
- A configuração de execução está em
runners/GLM-5.2-594B
- Outra abordagem mencionada é conectar um cluster com 4× DGX Spark para obter 512 GB de VRAM e usar o Qwen3.7-27B como um cérebro grande e lento, enquanto ele processa rapidamente tarefas repetitivas
Hardware real com 4× RTX 6000 Pro
- O sistema real é montado em torno de 4× RTX PRO 6000 Blackwell Workstation
- Cada GPU tem 96 GB, totalizando 384 GB de VRAM, com preço de cerca de US$ 46.000
- A máquina usa EPYC de geração anterior e peças DDR4 do eBay para reduzir o custo do sistema base e concentrar o gasto em VRAM
- Como, em julho de 2026, sistemas baseados em PCIe5/DDR5 estão muito caros, a escolha foi por um switch PCIe Gen4 e uma máquina baseada em DDR4
-
BOM do sistema base
- O sistema base é composto principalmente por peças EPYC de geração anterior compradas no eBay
- As principais peças e preços são os seguintes
- Placa-mãe ASRock Rack ROMED8-2T: US$ 715
- CPU AMD EPYC Milan 7313P de 16 núcleos a 3,0 GHz: US$ 504
- 8× 16 GB Crucial DDR4 ECC RDIMM, total de 128 GB de RAM: US$ 642
- 2× PSU Super Flower 1700 W: US$ 750
- Switch PCIe c-payne Microchip Switchtec PM40100 Gen4: cerca de US$ 1.330
- NVMe de boot de 4 TB: US$ 291
- 2× NVMe de 8 TB para pesos de modelos: US$ 1.200
- O total do sistema base é US$ 5.587
-
Switch PCIe Gen4
- Usa um switch PCIe4 da c-payne para lidar com a comunicação entre GPUs de forma quase direta
- Na etapa de allreduce do paralelismo de tensores, os dados entre GPUs se movem dentro do fabric do switch, sem passar pelo PCI root complex
- O sub-BOM do switch fica em cerca de € 1.220, aproximadamente US$ 1.330
- Switch PCIe Gen4 5× x16 baseado no Microchip Switchtec PM40100
- SlimSAS PCIe Gen4 Host Adapter x16
- 2 cabos SlimSAS SFF-8654 8i
- Foi construído manualmente um gabinete de madeira para as GPUs e o switch PCI, o que levou cerca de um dia
- A ventoinha embutida do switch PCI era muito barulhenta e parecia inútil, então foi removida da placa
Armazenamento dos pesos dos modelos e forma de execução
- Todos os pesos dos modelos são armazenados localmente em um sistema de arquivos ZFS replicado em dois drives de 8 TB
- O sistema de arquivos é montado em
~/storage
- O modelo a executar é primeiro baixado localmente com o seguinte comando
hf download <model-name> --local-dir ~/storage/<model-name>
- Cada modelo tem um
docker-compose.yml em um diretório separado e roda dentro de seu próprio contêiner Docker
- As configurações de execução estão em
./runners/
- Cada contêiner monta
~/storage/models como somente leitura para ler os pesos em cache
- Quando o modelo é servido em
http://clank.j.co:5000, ele é acessado pelo opencode hospedado em uma VM em outra máquina
- Um servidor DNS interno mapeia
clank.j.co para a máquina de LLM, mas também é possível usar o formato http://<llm-machine-ip>:5000
Harness de agente e configuração de ferramentas
- Em uma VM separada, é usado um aplicativo que cria uma sessão tmux para cada diretório da árvore
~/src e executa uma instância do opencode em cada sessão
- Cada instância do
opencode usa como backend a API HTTP da máquina de inferência, em http://clank.j.co:5000
- O ponto central para usar bem modelos open source é tratado como configuração de ferramentas
- O resumo de
skills/ inclui as seguintes ferramentas
- Navegação e busca na web via camofox, chave de API do kagi.com e searXNG
- Comunicação e notificações via bot do Telegram
- Instância local privada do Gitea para colaboração em código-fonte
- O agente pode trabalhar de forma interativa junto com o usuário na sessão, ou receber tarefas para tratar issues do Gitea e abrir PRs
- Esse trabalho roda dentro de uma VM em sandbox, e a comunicação com o host ocorre apenas por montagem de sistema de arquivos compartilhado
Switch PCIe e configuração multi-GPU
-
Configurações de BIOS
- Na placa-mãe ROMED8-2T, as configurações da BIOS foram ajustadas para evitar que a velocidade do switch PCI caia
AMD PCIE Link Width é configurado como x16 para o slot do switch- A configuração anterior de bifurcação x8/x8 dividia o slot, fazendo com que o link upstream treinasse como Gen4 x8
- Os 2 cabos SlimSAS 8i precisam estar conectados, e cada cabo fica responsável por x8
- PCIe Link Speed é forçado para Gen4
- Dispositivos Blackwell Gen5 podem falhar no treinamento e cair para Gen1 ao negociar automaticamente por meio de um switch Gen4
- ASPM é configurado como Disabled
- ASPM L1 reduz links ociosos para 2,5 GT/s
- Essa era a causa de o
lspci parecer mostrar downgrade para Gen1, mas sob carga ele opera em Gen4
- Re-Size BAR é configurado como Enabled
- Necessário para expor toda a BAR de 96 GB de VRAM e para P2P entre GPUs
- SR-IOV é configurado como Disabled
- É uma configuração para evitar overhead de IOMMU e interferência no P2P em um ambiente de inferência bare metal
- Preferred IO fica em Auto
- Definir manualmente o barramento
81 do switch c-payne pode trazer uma pequena melhora de latência, mas é uma otimização, não uma correção, e o número do barramento pode mudar após alterações na BIOS
-
Redriver e cabos
- Seguindo a orientação da c-payne, o ganho do redriver foi reduzido para
lvl 3 com a c-payne tool
- O nível de ganho varia conforme o comprimento dos cabos do conector SAS
- Foram pedidos poucos cabos da c-payne, então cabos SAS aparentemente parecidos foram comprados na Amazon, mas pequenas diferenças causaram problemas e foi preciso pedir novamente
Kernel, ACS e limite de energia
-
GRUB e NVIDIA UVM
- Os seguintes parâmetros de kernel são configurados em
/etc/default/grub
GRUB_CMDLINE_LINUX="iommu=off amd_iommu=off nomodeset"
sudo update-grub
- Sem
iommu=off, o NCCL trava em P2P multi-GPU
- Para a correção de P2P do NVIDIA UVM, a seguinte configuração é aplicada
echo 'options nvidia_uvm uvm_disable_hmm=1' | sudo tee /etc/modprobe.d/uvm.conf
sudo update-initramfs -u
-
Desativação do ACS
- Se o ACS estiver ativado por padrão, o tráfego P2P passa pela porta raiz da CPU em vez de permanecer dentro do fabric do switch
- Nessa situação, o efeito do switch PCIe desaparece
- Como
pcie_acs_override exige um kernel com patch, o ACS é desativado em runtime com setpci
- A cada boot, um serviço systemd oneshot executa
/usr/local/bin/disable-acs.sh
- A forma de validação é a seguinte
- Em
lspci -vvv | grep ACSCtl, tudo deve aparecer com sinal de menos
- Em
nvidia-smi topo -m, as quatro GPUs devem aparecer como PIX entre si, e não como PHB/NODE
./tools/measure-gpu-speed.sh permite medir facilmente largura de banda P2P e latência
-
Limite de energia das GPUs
- Para evitar instalar um circuito de 220 V, o sistema roda em um único circuito de 110 V, mas com a energia das GPUs limitada
- Via systemd, o persistence mode e o limite de energia são aplicados no boot
sudo nvidia-smi -pm 1
sudo nvidia-smi -pl 350
- O limite de energia das GPUs é de 350 W por GPU, enquanto o padrão é 600 W
- 4×350 W equivale a 1.400 W de carga nas GPUs, valor ajustado ao orçamento das PSUs
- Na etapa com uma única PSU de 1700 W antes do circuito de 240 V, as GPUs operavam em cerca de 260 W
- 4×260 W = 1.040 W de GPU
- Somando cerca de 280 W do sistema, o total fica em aproximadamente 1.320 W
- A validação é feita com
nvidia-smi --query-gpu=index,power.limit,power.draw --format=csv
Resultados medidos e referências
- O upstream em direção à CPU é Gen4 x16, com cerca de 30 GB/s
- O P2P via switch é de 27,5 GB/s unidirecional e 50,4 GB/s bidirecional
- A latência é de 0,37–0,45 µs, no nível do line rate Gen4
- Se o ASPM estiver ativo em algum ponto, o
lspci pode exibir links downstream ociosos das GPUs como 2.5GT/s (downgraded)
- Essa indicação é cosmética, e os links são retreinados para Gen4 quando há carga
-
Resources
- local-inference-lab/rtx6kpro: repositório atualizado com frequência sobre o uso de 4, 6 e 8 placas RTX 6000 Pro
- c-payne: switch PCI indie usado nesta configuração
- RTX6kPRO Discord: servidor Discord que trata de benchmarks da RTX6kPRO e testes de novos modelos
1 comentários
Comentários do Hacker News
Usei bastante LLMs locais e gastei dinheiro demais com hardware, mas é preciso baixar as expectativas e ler bem as condições detalhadas
O build grande do artigo começa com um orçamento de US$ 40 mil, mas inclui 4 GPUs de US$ 12 mil cada, então na prática fica mais perto de US$ 50 mil a US$ 55 mil
Configurações locais frequentemente dependem de técnicas como quantização ou REAP para fazer o modelo caber no hardware. Há muitas alegações de que a quantização de 4 bits é sem perdas, mas isso vem de medições de divergência KL em corpora pequenos; quando usada em tarefas de programação com contexto longo, a queda de qualidade é evidente. Mesmo em tarefas não relacionadas a código, como análise de datasets, é possível medir diferenças de qualidade consideráveis entre quantização de 4 bits, 8 bits e, às vezes, o original em 16 bits
O texto também recomenda usar modelos REAP, o que significa que alguém podou parte dos pesos para tornar o modelo menor. A ideia é remover pesos menos úteis para certas tarefas, mas a qualidade geral da saída cai de novo
A armadilha é que, quando as pessoas dizem “rodo o GLM-5.2 localmente”, isso parece impressionante ao olhar os benchmarks, mas na realidade elas não estão rodando o GLM-5.2, e sim um modelo derivado que descartou a maioria dos bits e removeu alguns especialistas. Em tarefas muito pequenas ou em chat, a diferença entre modelos quantizados/REAP e o original não aparece muito, mas em trabalhos longos, em que pequenos erros se acumulam, a diferença fica dolorosa
Aí, como você já gastou US$ 50 mil, acaba entrando naquela ladeira escorregadia de pensar que, para melhorar um pouco a qualidade e fazer o investimento valer a pena, basta comprar mais uma ou duas GPUs de US$ 12 mil
Para tarefas de programação, é preciso dividir a sessão em várias chamadas. Criei https://github.com/aka-rider/orqestra, mas hoje em dia, em praticamente qualquer ambiente de execução de ferramentas, dá para fazer algo parecido por conta própria
O ponto principal é manter separada a sessão que consome contexto lendo código e chamando ferramentas, e fazer com que ela gere um relatório em Markdown do tipo “o código e a documentação relevantes estão aqui, e a evidência é esta”, para reduzir alucinações. A sessão de planejamento fica separada; como modelos pequenos pulam detalhes, faço o crítico e o arquiteto trocarem mensagens de 1 a 3 vezes, e faço o trabalhador e o verificador também iterarem pelo mesmo motivo
O Qwen3.6 consegue passar horas procurando bugs complexos em modo somente leitura e geralmente os encontra. A correção que ele sugere provavelmente será meio gambiarra, mas com o Sonnet é a mesma coisa
O Qwen3.6 consegue escrever código mecanicamente seguindo um plano feito pelo Opus. Depois disso, é preciso fazer prompts como: “revise diretamente suas alterações. Há bugs? Faça uma validação cruzada com o plano original para ver se faltou algo. Há alguma violação do CLAUDE.md?”. Mas isso também precisa ser feito exatamente da mesma forma com o Sonnet
Também uso LLMs locais para reindexar a base de conhecimento. Na triagem de tickets, mesmo deixando só anotações brutas como “painel único para renderização de erros, mover todas as mensagens de erro”, ele consegue devolver uma especificação cerca de 90% pronta, com objetivo e contexto anexados
É excelente para tarefas pequenas, mas, na primeira tarefa grande que dei, ele esqueceu qual era o ambiente de execução do agente e começou a usar o formato errado para chamadas de ferramentas. Ele estava rodando em um Pi, mas acreditava estar rodando no Claude e tentou chamar ferramentas do Claude que não existiam
Ele não escreve uma aplicação inteira sozinho, mas resolveu um problema chato de rede na minha tailnet que eu não tinha tempo nem vontade de investigar, e frequentemente me faz encarar tarefas simples que eu evitava porque o custo de pesquisa era alto. Não é o Opus, mas é útil, e não preciso ficar preocupado se estou tirando valor suficiente de uma assinatura ou de custos de API
Ferramentas pequenas como processamento de linguagem natural, síntese de voz, processamento de imagem, engenharia de áudio, processamento de sinais e plugins de difusão para o Krita são ótimas para configurações locais. Também escrevi um texto curto há alguns dias[1]
[1] https://abishekmuthian.com/multiple-20-ai-plans-are-better-t...
A ideia de que “por cerca de US$ 40 mil, a inteligência do modelo sobe um patamar e chega bem perto do Claude Opus” equivale ao custo de usar o Claude Opus 4.8 ou o Codex GPT 5.5 por 16,8 anos, considerando US$ 200 por mês.
Eu realmente gosto de rodar modelos locais, mas ainda é absurdamente caro, a qualidade é inferior e, se houver backdoors, também pode ser perigoso. Sinceramente, eu gostaria muito que não fosse assim.
Mas tenho dúvidas se um equipamento local conseguiria, na prática, processar o equivalente a US$ 4.000 por mês de uso de API. Isso porque é difícil para uma máquina local rodar prompts em paralelo com a mesma eficiência dos vários data centers da Anthropic.
Empresas como OpenAI e Anthropic ainda vendem planos a preços subsidiados por capital de risco, e esse capital em algum momento vai querer retorno.
Usei 1 bilhão de tokens no primeiro mês com OEM spark, o que passaria de US$ 1.000 no Opus. Não é uma comparação justa porque o padrão de tokens é diferente, mas depois disso a velocidade também melhorou 2 a 3 vezes graças a melhorias no vLLM, principalmente MTP. O DiffusionGemma é cerca de 4 vezes mais rápido que o Gemma comum.
Você também não possui fibra óptica; então por que possuir mais um ativo caro, incômodo e que se deprecia rapidamente?
Alugando GPU na nuvem, dá para participar da cultura de posse, controle de dados, controle de preços e cultura hacker sem montar uma enorme caixa Frankenstein de hobby. Essa caixa é cara, destilada a ponto de ser praticamente menos útil, e sua manutenção é uma dor de cabeça.
Dizem “US$ 40 mil e quase Opus”, mas se o GLM 5.2 é “quase Opus”, então para inferência confortável são necessárias no mínimo 8x H200, o que fica mais perto de US$ 400 mil do que de US$ 40 mil.
O texto sugere usar um modelo modificado: “GLM-5.2 podado com REAP, com cerca de 22% dos especialistas removidos, quantizado em Int8-mix NVFP4, cerca de 594B parâmetros”.
Fico curioso para saber como ele se comporta de verdade fora dos benchmarks. O Qwen3.6 também costuma cair em loops durante a inferência com quantização de 6 bits, e aqui ainda removeram parte dos especialistas. Às vezes, um modelo menor em 8 ou 16 bits pode ser mais inteligente que um modelo grande lobotomizado. Parece haver um consenso de que, para programação, é melhor não descer abaixo de 8 bits.
Também não está claro quanto contexto utilizável sobra ao encaixar esse modelo lobotomizado em 4 RTX 6000. Abaixo de 100k, muitas vezes você bate na compactação antes de reunir o contexto necessário, então fica quase inutilizável. Verifiquei no repositório e o contexto era de 240k.
Quero saber se ele simplesmente não roda ou se fica lento demais para ser usável. Gostaria de validar localmente o build e os conceitos de um modelo de ponta e, quando os preços de GPU caírem bastante daqui a 18–24 meses, completar o restante.
Quer dizer que dá para rodar centenas de prompts ao mesmo tempo?
Isso está no llamacpp. A pessoa que criou o heretic também criou estratégias de prevenção de loops e diversificação de nível atual.
A menos que você simplesmente queira fazer isso, não há necessidade prática de rodar 8x H200. A exceção é se você precisar atender regularmente muitos usuários ou agentes simultâneos.
Também há opções intermediárias. Ao garantir 128 GB de VRAM, hoje já existem várias opções que oferecem esse volume por meio de uma arquitetura de memória unificada, e dá para rodar o DeepSeek V4 flash em boa velocidade via DwarfStar.
Eu não gastaria esse dinheiro, mas para muita gente acho que esse seria um compromisso adequado.
Mas é preciso usar o Pi. O claude code tem contexto de bootstrap demais, então tudo fica muito mais lento.
“Com 2 placas RTX 3090, somando 48 GB de VRAM, dá para rodar o Qwen3.6-27B, e é um modelo excelente”, dizem, mas por US$ 3 mil dá para comprar um M5 MacBook Pro com 48 GB de memória compartilhada, e que também não é uma caixa enorme.
Ou também vale considerar gastar esse dinheiro com provedores de hospedagem em nuvem. Pelo menos até certo ponto, talvez saia muito mais barato. Claro, poder rodar o modelo localmente é algo muito legal.
Mas só depois de usar algo decente, como o Gemma 4 31B e o Qwen 3.6 27B, percebi o quanto eles são úteis.
Você para de se preocupar se está compartilhando informações sensíveis, deixa de se preocupar se os tokens vão acabar e também não precisa se preocupar com a disponibilidade da IA remota. LLMs locais têm muito valor.
Duas 3090 têm, no total, 1,87 TB/s de largura de banda de memória, 0,936 TB/s por placa, enquanto o M5 MacBook Pro tem apenas 0,3 TB/s. O chip Max chega a 0,63 TB/s, mas essa configuração é uma máquina de US$ 10 mil.
Por isso, o Qwen 27B roda rápido o bastante para trabalho real em duas 3090, mas parece dolorosamente lento em um MacBook Pro. Além disso, ao rodar modelos grandes no MacBook Pro, a UI engasga e o teclado esquenta. É muito melhor deixar duas 3090 no porão e acessar pelo MacBook.
Não é só a velocidade de geração de tokens, mas também o tempo até o primeiro token, ou seja, o tempo de processamento do prompt. O hardware M5 é excelente por si só, mas a GPU ainda é muito mais rápida.
Rodar o modelo numa caixa com GPU também tem a vantagem de permitir usar o notebook no colo sem transformá-lo em um prato quente.
Portanto, tanto o prefill limitado por FLOPS quanto o decode limitado por largura de banda serão lentos.
Acabei de montar um LLM local nesta semana, então minha experiência pode ajudar. Escolhi uma placa Arc B70 da Intel, de 32 GB, que é mais barata que a 3090 e tem mais RAM, mas um barramento de memória mais lento.
Escolhi essa placa porque os modelos que quero usar são um pouco grandes para caber confortavelmente em 24 GB, e eu também precisava de espaço para manter carregados alguns modelos pequenos de autocompletar e reconhecimento de fala. Além disso, eu já tinha um servidor barato, e para usar duas GPUs teria que trocar a placa-mãe, a fonte de alimentação e provavelmente até o gabinete.
A configuração foi bem complicada. A linha da Intel precisa de um pacote de drivers chamado “level zero” para oferecer suporte a SYCL, algo mais ou menos como a versão da Intel do CUDA, e foi difícil fazer isso funcionar corretamente. Rodo o llama.cpp em um contêiner Docker, e também deu algum trabalho fazer o contêiner enxergar a placa. Também é necessário um kernel dos últimos meses.
Depois que tudo começou a funcionar, o resultado foi muito impressionante para um investimento de US$ 1 mil. Rodando o Qwen 3.6 35B com quantização q4, ele usa cerca de 3/4 da RAM e chega a aproximadamente 88 tokens/s. Se você quer um modelo de tamanho razoável por pouco dinheiro, é uma opção.
A B70 tem barramento de 256 bits a 2375 MHz, 608 GB/s, enquanto a 3090 tem barramento de 384 bits a 2438 MHz, 936 GB/s. Não é que seja mais lenta; ela tem menos canais, ou seja, é mais estreita.
O qwen3.6-27b consegue rodar a variante q4 em uma única 3090, mesmo com cerca de 250K de contexto total.
Ele é rápido o bastante para não ser frustrante, então o ganho de velocidade de usar duas 3090 não vale a pena para mim. Também há a opção de rodar q6 em duas placas com metade da velocidade e um contexto menor, mas, de qualquer forma, ele não vai competir com modelos de ponta atuais; então, se você ainda não tem duas 3090, acho que, nos preços atuais, uma única placa é o melhor investimento. Com um ambiente de execução bem configurado, é suficiente para fazer muita coisa.
Na minha experiência, nessa precisão a acurácia de recuperação em contextos longos cai bastante. Achei melhor manter o cache KV em q8 e trabalhar com contexto de 120k.
Sobre isso, fico curioso para saber qual é o melhor sistema de isolamento que dá para usar hoje. Não sei se é preciso chegar a uma VM completa e pesada, ou se algo parecido com o Firecracker já basta
Parece haver armadilhas sutis em cada opção possível, daquelas em que é fácil dar um tiro no próprio pé, e acabar, na prática, sem segurança nenhuma. VMs são usadas porque dá para confiar de fato que segurança é um princípio fundamental dessa tecnologia, e não algo do tipo “use estas 20 flags e aperte os olhos que deve ficar tudo bem”
Primeiro é preciso modelar os vetores de ataque.
rm -rfé bloqueado com restrições de escrita, ecurl malware.sh | shpode ser contido restringindo a execução em diretórios graváveis (seatbelt/SELinux). Só limitar escrita em diretórios sensíveis provavelmente já neutraliza boa parte dos malwares de forma considerávelVazamento de credenciais se resolve limpando variáveis de ambiente, proibindo leitura de .ssh, .aws etc., e não deixando o LLM perto do sistema operacional
Criei um pequeno utilitário para macOS, https://github.com/aka-rider/leash, mas também dá para fazer com scripts bash
Se quiser algo leve, dá para usar algo como bubblewrap[1], ou uma microVM como libkrun[2]; se quiser também as ferramentas relacionadas, dá para ir até um Docker completo
[1] https://github.com/containers/bubblewrap
[2] https://github.com/libkrun/libkrun
Entendo a incerteza de como saber, de fato, que tudo está rigidamente bloqueado
Pessoalmente, acho que VMs ou microVMs são o caminho certo. Diferentemente de contêineres, elas foram projetadas como fronteiras reais de segurança. Mesmo em comparação com bubblewrap, dá para entregar ao agente o filesystem inteiro e rodar em modo YOLO, enquanto no bubblewrap é preciso inicializar e disponibilizar cada ferramenta de desenvolvimento uma a uma, montar com segurança diretórios de configuração, caches de pacotes etc., e ainda assim é provável continuar encontrando erros de permissão. O isolamento também é muito mais fraco
O suporte ao ambiente de execução é limitado, mas me parece bastante razoável rodar o processo do ambiente de execução no host e delegar todas as chamadas de ferramentas e interações com o filesystem para a VM. Assim, dá para manter dados de sessão e chaves de autenticação na máquina principal, sem que nunca entrem no contexto. Em compensação, o próprio ambiente de execução passa a fazer parte da fronteira de segurança, e esse é o trade-off
Como mover dados para dentro e para fora da VM também vira uma questão de usabilidade. Estou usando scripts que empurram o repositório git local para a VM e depois o trazem de volta como se fosse um remoto; assim, a VM não consegue iniciar conexões para o host e nem precisa ter credenciais git. Mas, para quem quer que o agente faça push direto para o GitHub, isso pode ser esforço demais
As opções que testei ou vi para VMs em si são qemu + libvirt, crun-vm e a família libkrun. qemu + libvirt dá trabalho para acertar, mas é muito validado e altamente configurável. crun-vm é uma PoC de uma camada de integração de alto nível entre podman e qemu; parece abandonado, mas é interessante por se apoiar em ferramentas existentes e padrões. libkrun é um participante mais novo e tem wrappers como microsandbox, smolvm e krunvm. Tudo isso considerando Linux
Parece estranho fazer tanto esforço assim para usar um LLM. Especialmente correr atrás do que há de estado da arte desse jeito
Se coisas como o Claude sumissem amanhã, eu não piscaria
Não entendo por que as pessoas trocam suas circunvoluções cerebrais por acesso a uma máquina de slop. Uma boa analogia talvez seja dar a um carpinteiro habilidoso uma máquina que produz móveis um ou dois níveis abaixo da qualidade da Ikea. Ela dá conta do trabalho? Na maioria das vezes, sim. O carpinteiro gosta do processo? Não
Pela minha experiência, nunca rodei um modelo muito quantizado, como q4, ou modificado em algum grau, e pensei “uau, isso é realmente incrível”. Pelo contrário: depois de alguns prompts, ia para a lixeira
Tenho uma RTX 6000 PRO de 96 GB, e o que consigo rodar confortavelmente é algo como Qwen 3.6 27B ou MoE, Gemma 4 31B. Ao rodar os modelos em precisão total e com comprimento máximo de contexto, esse é o limite
Eles têm bom desempenho e servem para vários usos, como programação e pesquisa na internet. Pelas minhas contas, se você provavelmente for gastar mais de US$ 2.400 por ano com a Anthropic, pode fazer sentido comprar uma placa dessas, mas terá de aceitar a queda de qualidade. De todo modo, é uma incógnita se humanos ainda estarão programando daqui a 5 anos