Você usa LLMs abertos e assistentes de programação localmente? Compartilhe seu ambiente

• Um tópico Ask HN perguntando aos usuários do Hacker News como usam LLMs abertos e assistentes de programação localmente e em que hardware de laptop
• Quais modelos usam (ex.: Ollama, LM Studio etc.) e quais assistentes de programação open source/soluções de integração usam (ex.: plugins do VS Code)
• Que hardware de notebook usam (CPU, GPU/NPU, memória, GPU dedicada ou integrada, SO) e que desempenho isso entrega no fluxo de trabalho
• Para quais tarefas usam (completar código, refatoração, depuração, revisão de código)? E qual o nível de confiabilidade (o que funciona bem e o que ainda deixa a desejar)?

---

• 1) MacBook Pro / Mac Studio (M2~M4 Max, 64~128GB) + LM Studio/Ollama + VS Code Continue

  • Vantagens
    • Graças à memória unificada dos Macs, até Qwen3-Coder-30B-A3B, gpt-oss-20b e Gemma 27B rodam localmente sem drama, viabilizando um fluxo de “ler o código → resumir → fazer pequenas alterações”
    • Basta deixar o LM Studio API ou o Ollama serve ligados para que Continue.dev no VS Code, Zed e JetBrains se conectem direto, entregando na prática uma UX parecida com a do Claude Code
    • A baixa latência típica do Mac ajuda bastante: com algo em torno de 50~80 tok/s, complementação de código e geração de comentários não ficam engasgando
    • O fato de funcionar no avião/trem/offline é um grande diferencial, sendo adequado para manter “o código da empresa sem sair do ambiente interno”
  • Desvantagens
    • A partir de modelos acima de 20B, surgem problemas de aquecimento + ruído de ventoinha, e mesmo com um M4 Max 128GB os 120B ficam lentos ou já mostram limites
    • Cenários de agente “como o Claude 4.5 Sonnet, que vai até o fim num bash-in-a-loop” ainda ficam devendo
    • MacBooks de 24GB ou 32GB têm pouca alocação de VRAM, então no fim é preciso cair para a faixa de 7B~12B, e aumentar muito o contexto já deixa tudo lento

• 2) Estrutura com desktop/workstation equipado com RTX 3090·4090·Pro 6000 e notebook usado como cliente leve

  • Vantagens
    • Dá para testar de tudo: llama.cpp / vLLM / Ollama, e até rodar gpt-oss-120B “de forma lenta, mas de verdade”
    • Você abre Continue ou llama-vscode no VS Code do notebook, mas a inferência roda na máquina em casa, então quase não há impacto de bateria ou aquecimento no laptop
    • Tomando uma RTX 3090 24GB como referência, gpt-oss-20B e Qwen2.5/3 Coder 14~30B entregam velocidade de tokens utilizável no dia a dia, suficiente para autocomplete + pequenas refatorações
    • Muita gente sobe Open WebUI + Ollama em casa e acessa via VPN/Tailscale, mantendo um ambiente privado mesmo remotamente
  • Desvantagens
    • Se a VRAM da GPU for 24GB ou menos, 120B precisa de quantização pesada, com perda de qualidade claramente perceptível
    • O vLLM tem bom desempenho, mas instalar e compilar é incômodo, a ponto de surgirem comentários do tipo “tente rodar de novo com um runner atualizado”, o que aumenta o custo de manutenção
    • Portabilidade praticamente não existe, então essa arquitetura não serve para quem quer “resolver tudo de verdade só com um notebook”

• 3) Configuração centrada em gpt-oss-120B (Aider, Codex, agente local)

  • Vantagens
    • Várias pessoas disseram algo como “foi o que usei localmente que mais chegou perto do GPT-5”, indicando alta precisão em tarefas de programação
    • Experimentos reais já funcionam conectando isso a assistentes abertos como Aider, Codex e roocode para fazer revisão → correção → teste → commit de uma vez só
    • Também circularam dicas para forçar execução no llama.cpp com carga mista de CPU+GPU, fazendo até 8GB de VRAM quebrarem um galho, então o requisito de hardware é mais flexível do que parece
  • Desvantagens
    • O problema é a velocidade. Enquanto o ChatGPT termina o mesmo conjunto de 50 perguntas em 6 minutos, um 120B pode passar de 1 hora mastigando aquilo, então é algo para quem aceita esperar
    • Em ferramentas como o Codex, é preciso hardcodar parâmetros de inferência para evitar travamentos, e escrever um AGENTS.md robusto para que ele trabalhe de forma mais parecida com uma pessoa
    • Só com o notebook é difícil manter isso rodando por muito tempo por causa de calor, energia e memória; na prática, faz mais sentido como “notebook conectado a uma GPU remota”

• 4) AMD Strix Halo / Ryzen AI / Framework 128GB e outros notebooks com muita RAM + llama.cpp/Continue.dev

  • Vantagens
    • Com 128GB de RAM, até Qwen3 Coder 30B se torna utilizável na prática, e dá para fazer um esquema híbrido em que apenas as camadas necessárias vão para GPU/NPU e o resto roda na RAM
    • Pelo relato das pessoas, foi uma opção realista em situações como “o código não pode sair da empresa” ou “como é AMD, os drivers em nuvem ainda deixam a desejar”
    • Uma arquitetura com um servidor simples de llama.cpp como o lemonade-server iniciando automaticamente no boot e o editor se conectando pela rede funciona bem
  • Desvantagens
    • Há relatos de que no Linux economia de energia/câmera/drivers ainda não estão redondos, e em alguns casos foi preciso esperar pelo kernel 6.18
    • O desempenho de NPU não chega perto do nível da NVIDIA, então “agentes de fronteira” ainda estão fora de alcance, ficando no máximo no papel de assistente de 20~30B
    • Material para AMD costuma exigir busca em repositórios do GitHub e fóruns, então a densidade de informação é menor do que no ecossistema Mac ou NVIDIA

• 5) Notebooks comuns com 16~32GB (MacBook Air, M2/M3 Pro com pouca RAM) + modelos de 7B~12B usados só para autocomplete FIM

  • Vantagens
    • Mesmo usando apenas qwen2.5-coder:7b, mistral 7b instruct ou gemma3:12b, já sai rapidamente coisa como “continue esta linha” ou “como era mesmo esta sintaxe SQL?”
    • Com o plugin llama-vscode ou o Continue.dev, o autocomplete continua funcionando mesmo sem internet, sem quebrar o ritmo de trabalho
    • A exigência de hardware é baixa, então quase não há aquecimento nem barulho de ventoinha, e a bateria também dura bem mais
  • Desvantagens
    • Basta o contexto ficar um pouco maior para a taxa de alucinação subir rápido, e tarefas como refatoração ou geração de testes, que exigem “entender vários arquivos ao mesmo tempo”, praticamente não são viáveis
    • No geral, as pessoas cravaram que “isso não substitui modelos de nuvem; é só para autocomplete”
    • Como é preciso comprimir bastante os modelos em 4 bits, o leque de opções fica reduzido

• 6) Configuração 100% offline / com foco em privacidade (Ollama + Open WebUI + VPN)

  • Vantagens
    • Se você deixar em casa um Mac Studio M4 Max 128GB ou um desktop com Ollama + Open WebUI, do lado de fora pode acessar de notebook ou celular por VPN e tudo continua local
    • Quem usa essa estrutura destacou pontos como “agora quase não uso mais o ChatGPT” e “como a versão não muda, os prompts ajustados não quebram”
    • Dentro de empresas, é a arquitetura mais fácil de explicar quando existe a exigência de que “nenhum código pode ser usado para treinamento”
  • Desvantagens
    • Você mesmo precisa cuidar de upgrade/troca dos modelos, então não existe aquela evolução automática do tipo “ficou mais inteligente sozinho”, como nos serviços em nuvem
    • Se a GPU for fraca, acima de 20B tudo desacelera rápido, e aí inevitavelmente vem a pergunta: “por que eu não fiz isso na nuvem?”

• 7) Consenso geral que emergiu

  • Ainda é difícil substituir Claude Code / GPT-5 + agente usando apenas um notebook, e o uso local hoje se encaixa melhor em geração curta de código, ajuda contextual, resumo e autocomplete
  • Por isso, os formatos mais recorrentes foram “notebook ↔ máquina parruda em casa” ou “Mac 128GB rodando rápido só modelos de 20~30B”
  • Ainda assim, todos repetiram a mesma ideia: se você precisa de privacidade garantida + latência quase zero + versão estável sem mudanças, a melhor resposta continua sendo local

[kaydash]

Em vez de usar uma VPN, acho que seria melhor configurar um bearer token e usar tunelamento SSH.

[savvykang]

Acho que começar com self-hosting de LLM vai continuar não compensando, por causa do alto custo inicial de investimento antecipado, pelos próximos 5 anos. Pretendo voltar a considerar isso daqui a 3~5 anos, quando surgir um hardware razoavelmente rápido com vantagem de preço, ao menos para autocompletar código.

Configurações que avaliei

1. Configuração all-in-one: não dá para rodar LLM no equipamento de trabalho. Falta RAM até para rodar ferramentas de desenvolvimento e apps baseados em navegador.
2. Configuração com máquina dedicada para LLM: na empresa não tem placa de vídeo, então não dá para rodar. E, mesmo para um PC pessoal, não é fácil bancar antecipadamente uma máquina com essa especificação.

[GN⁺]

Comentários do Hacker News

• Comprei um Dell Precision 3620 Tower i7-7700 usado porque queria mexer diretamente com IA
  Fiz upgrade da RAM e também troquei a fonte para instalar uma RTX 3060 como GPU
  Instalei Ubuntu Server, configurei como um nó do cluster k3s da minha casa e estou rodando Ollama e OpenWebUI
  Uso principalmente para tagueamento e resumo com IA no Karakeep, mas também estou aproveitando para analisar a câmera da garagem com código Python para detectar veículos de entrega

• Estou rodando Ollama via CPU em um Dell Precision T710 (Xeon E6320, 120GB RAM, RAID5 SSD 240TB), sem GPU
  Estou tocando um projeto para indexar com RAG as leis eleitorais dos 50 estados e visualizar problemas de inconsistência de termos e alucinações
  O objetivo é identificar lacunas de integridade nos procedimentos eleitorais
  O mapa mental relacionado pode ser visto em Election Frauds v1.4 Mindmap PDF

  • É realmente incrível usar seu talento em projetos sociais assim

• Eu programo com LLM local, mas no notebook isso é impensável
  Uso em um servidor com GPU, trocando de modelo com llama.cpp + llama-swap
  O setup com que fiquei mais satisfeito é Aider + gpt-oss-120b
  Talvez também dê com Ryzen AI Max+ 128GB RAM, mas hardware que não é NVIDIA é muito lento
  Também dá para escolher apenas provedores sem retenção de dados via OpenRouter
  Mas GPT5 e Claude são muito mais rápidos e baratos do que rodar localmente

  • Montei um agente RAG com gpt-oss-120b e o alimentei com a documentação do GCP
    O ChatGPT fez 46/50 em 6 minutos, e o gpt-oss-120b fez 47/50 em 1 hora
    Rodei em um ambiente com i7 + 64GB RAM + GPU com 8GB de VRAM
  • Link do GitHub do llama-swap

• Se você quiser rodar um agente local de código no Mac, pode fazer assim

  1. npm install -g @openai/codex
  2. brew install ollama; ollama serve
  3. ollama pull gpt-oss:20b
  4. codex --oss -m gpt-oss:20b
     Funciona sem internet e exige Mac M1 ou superior + 24GB de memória GPU
     O modelo 120b tem desempenho 1,5x melhor que o 20b, mas exige 5x mais recursos
  • LM Studio é mais simples e também integra com JetBrains IDE ou Zed
  • Fiquei curioso se alguém conseguiu produzir código realmente valioso com o modelo 20b

• Estou rodando Qwen3-Coder-30B-A3B Q4 quant com llama.cpp em um MacBook Pro 64GB
  No VSCode uso continue.dev com um prompt de sistema curto
  Consigo 50 tokens por segundo na geração e 550 tokens de throughput
  Em tarefas curtas e claras, mostra qualidade parecida com modelos frontier
  Estou satisfeito porque é rápido e estável mesmo offline
  Para tarefas mais complexas, uso as APIs do Claude ou do Deepseek

  • Você já testou o modelo Instinct do continue.dev? Queria saber como ele se compara ao Qwen
  • Também pediram para compartilhar o link de download no Hugging Face e perguntaram se, em uma máquina de 128GB, seria melhor usar outro quant
  • Também houve um comentário perguntando como rodar Qwen3 no llama-vscode (link da issue)

• Se for comprar um Mac, recomendo pelo menos um modelo Pro
  O Air não tem ventoinha, então não gerencia bem o calor, e acho o Studio melhor que o Mac mini
  Dá para ajustar as ventoinhas de forma mais agressiva com o app TG Pro (cerca de US$ 20)
  Rodo o modelo GPT OSS 20B em um MacBook Pro M4 Pro + 24GB RAM, mas a janela de contexto é pequena
  Em um modelo com 128GB, imagino que dê para programar offline o dia inteiro

  • O Mac mini também tem ventoinha, e o Studio é só a versão com chip mais potente
  • Se for comprar um Mac, o ideal é uma configuração com chip Max ou Ultra + memória no máximo
  • O MacBook Pro de 128GB tem desempenho de cache de contexto avassalador
  • A janela de contexto padrão é pequena, mas no gpt-oss-20b dá para expandir em 4x
  • Houve quem dissesse que, mesmo com M3/M4 + 128GB, a velocidade de processamento de prompts longos é lenta

• Estou usando um Apple M4 Max 128GB junto com um GPD Win 4 (Ubuntu 24.04) conectado via USB-C
  Combino Claude Code, RA.Aid e llama.cpp para distribuir tarefas com o Agent Organizer
  O Claude automatiza desde o desenho da arquitetura até a revisão de código

  • Houve perguntas sobre qual papel o GPD Win 4 cumpre, e se ele é usado para processamento distribuído com modelos menores
  • Também perguntaram a velocidade de processamento de tokens de cada modelo
  • Teve gente curiosa para saber o que exatamente é o Agent Organizer usado

• Se você quiser ver workstations para LLM, recomendo o canal do YouTube do Alex Ziskind(@AZisk)
  Ele cobre várias reviews de workstations para LLM local
  As apresentações são bem organizadas e os conselhos são práticos

  • Deve ter patrocínio, mas impressiona ele assumir o risco de comprar o equipamento com o próprio dinheiro para avaliar
  • Teve também comentário recomendando o canal como “sem enrolação, vai direto ao ponto”

• Eu uso principalmente LMStudio e Ollama em um MacBook Pro M4 Max 128GB
  Os modelos são qwen3-coder-30b A3B Instruct 8-bit MLX e gpt-oss-120b-MXFP4-Q8
  Há limites para geração de código em grande escala, mas para resumir e documentar repositórios locais já é mais que suficiente
  A comunidade em torno disso também é bem ativa

  • r/LocalLLM
  • r/LocalLLaMA
  • No Mac, usando Coderunner(link do GitHub), dá para executar em sandbox com segurança o código gerado por LLM
  • Se você conectar a API do LM Studio ao qwen CLI, dá para montar um ambiente parecido com o Claude Code
    Para gerar README, a preferência é por gemma3-27b-it-qat e gpt-oss-120b

• Estou rodando Qwen3:32b via CLI em um MacBook Pro M1 Pro 32GB + Asahi Linux
  Uso para obter ajuda com assembly ARMv8 e assuntos ligados a SoC
  A velocidade é boa o bastante, só um pouco abaixo da velocidade de leitura
  Ouvi dizer que o Qwen3-coder é mais rápido e isso despertou meu interesse
  Prefiro um ambiente totalmente local, sem cloud nem integração com agentes
  Como o Ollama se afastou do foco em uso offline, agora quero migrar para llama.cpp
  Estou pensando se vou conseguir usar os modelos do Ollama como estão, já que o formato é diferente
  [Atenção] No Linux, o consumo de energia é alto, então é preciso usar sempre na tomada

  • O Qwen3 Coder tem arquitetura MoE (3B ativos de 30B), então é muito mais rápido
    É menos inteligente em tarefas gerais, mas mais eficiente em tarefas centradas em código

[chcv0313]

Continuando a ler..... acabei pensando que, surpreendentemente, talvez exista demanda pelo DGX SPARK? No começo, eu pensava: aquilo tem um custo-benefício horrível, quem compraria isso! Mas,

[aer0700]

Por causa da política interna de segurança, não usamos nenhuma API externa de LLM, e estamos usando o GPT OSS fornecido pelo departamento interno de gerenciamento de nuvem com base em vllm.

[aer0700]

É meio discutível chamar isso de local.