Ask HN: Alguém substituiu Claude/GPT por modelos locais na programação do dia a dia?

• Desenvolvedores estão começando a abandonar completamente os modelos em nuvem por motivos de privacidade de dados e uso gratuito de LLMs, conseguindo trabalhar com harnesses de programação offline containerizados e em sandbox sem chamadas para redes externas
• Os principais modelos usados são Qwen3.6 35B-A3B (com 3b de parâmetros ativos para alta velocidade) e modelos densos de 27B, com um trade-off entre precisão em programação e velocidade de geração de tokens
• A combinação mais citada é Pi harness com llama.cpp, e o fato de o tool calling ter começado a funcionar de forma consistente em modelos locais melhorou bastante a experiência de uso
• Em comparação com Claude Opus, os modelos locais ficam no nível de "um júnior que precisa de orientação vs. um sênior que projeta junto com você", tornando essencial usar prompts precisos e decompor tarefas
• Hoje, os modelos locais são avaliados como estando em um nível de cerca de 8 a 18 meses atrás em relação à fronteira, mas oferecem vantagens práticas como gratuidade, privacidade e ausência de preocupação com cotas

---

Casos de migração para modelos locais e configurações de hardware

• Qwen3.6 35B-A3B rodando em um Mac Studio 128GB ou MacBook com 36GB de RAM via Pi harness concluiu a reformulação completa da homepage e do blog de um site baseado em Django + Wagtail
  • Sem acesso à internet, o modelo nem sempre sabe como lidar com desenvolvimento em Wagtail, que é menos conhecido
  • Para tarefas complexas, usam Qwen3.5 122b, mas ele é bem mais lento por ter 10b de parâmetros ativos
• Em um ambiente com memória unificada Strix Halo 128GB, o Pi foi isolado em contêiner, permitindo acesso apenas ao diretório de trabalho e sem credenciais
  • Para chat e tradução usam Gemma 4 31B, e para áudio, Gemma 4 12B
  • Possuem vários modelos, como Qwen 3.5 122B-A10B, Nemotron 3 Super 122B-A12B, Step 3.7 Flash e GPT-OSS 120B, mas para programação o 35B-A3B é o ideal
• Em uma máquina com dual RTX3090 montada há 5 anos, modelos Qwen e Gemma atingem ~150tok/s com quantização UD-Q4_K_XL, processando todo o contexto de 300k dentro da VRAM
  • Isso substituiu uma assinatura Claude de $100/mês, e para uso pessoal o gratuito vem primeiro
  • Foram feitos vários projetos, como launcher para Android TV, portal de gerenciamento k8s, integração com Home Assistant e gestão de compras e dieta
• Com uma RTX 6000, a combinação Qwen 3.6 27b + Open Code cobre 90% do trabalho de programação, mas tarefas muito complexas e refinamento de UI ainda voltam para Codex
  • Em contexto de 256k, a qualidade e a velocidade caem acima de 100k e pioram bastante depois de 150k
• Em uma RTX 5090, Qwen 3.6 27b (quantização Q6) + llama.cpp foi usado limitando a GPU de 600W para 450W para reduzir ruído
  • O uso já se expandiu para tarefas rotineiras como commits de branch, criação de PR, conciliação de faturas via Stripe CLI e análise de carga no Elasticsearch

Tipos de modelo e características de desempenho

• A distinção entre MoE vs. modelos densos afeta diretamente a qualidade de programação
  • Qwen3.5-122B é na prática um 122B-A10B MoE, com apenas 10B ativos, enquanto Qwen3.6-27B é um modelo denso com todos os 27B sempre ativos
  • É possível aproximar a qualidade equivalente a um modelo denso pela média geométrica entre parâmetros totais e ativos do MoE, sqrt(35×10)≈18.7
  • MoE tem qualidade menor para o mesmo tamanho, mas é mais rápido, e grandes MoEs também podem rodar com offload para RAM da CPU
• O nível de quantização afeta a ocorrência de loops e a precisão
  • Quantização Q8 é mais lenta, mas reduz loops e economiza tempo total
  • A parte K do KV cache é muito sensível à quantização; com F16 K + Q8 V, os loops caem bastante
• Adicionar uma segunda GPU não serve para acelerar inferência, mas para aumentar a capacidade de VRAM
  • Gemma-4 31B denso e 26B MoE têm qualidade semelhante em Q4, mas o MoE é ~3x mais rápido (150tok/s vs 46tok/s)

Limitações dos modelos locais e estratégias de resposta

• Necessidade de prompts precisos

  • Se você deixar suposições em aberto, o modelo escolhe o caminho mais curto (por exemplo, CSS dentro de HTML) e produz um resultado que não é o melhor do ponto de vista de arquitetura
  • Se a arquitetura não for explicitada, ele faz mudanças rápidas e desorganizadas; se você não mandar remover mensagens de debug, elas ficam
  • Claude Opus infere a intenção do usuário, mas modelos menores da Qwen fazem apenas o que foi instruído; é preciso "ativar" explicitamente o conhecimento de design

• Loops e erros nas ferramentas de edição

  • Frequentemente erram chamadas de ferramenta de edição e, em vez de tentar novamente, gastam tokens de raciocínio relendo arquivos
  • Tentar de novo manualmente muitas vezes corrige a chamada de edição, mas o modelo presume que o problema é mais fundamental e desperdiça tokens
  • Uma abordagem de edição baseada em hash (referenciando o hash de cada linha de código) pode reduzir erros de edição, mas depois que a qualidade do contexto se esgota o comportamento degrada de outra forma
  • Restringir edições com regras em AGENTS.md, em vez de permitir reescritas completas, traz melhora parcial

• Gestão da janela de contexto

  • Uma janela de 65.000 já estoura só lendo a estrutura de arquivos de código; são necessários mais de 200k
  • Qwen3.6-35b processa normalmente 128k de um contexto de 256k com 16gb de VRAM
  • Qwen3.6-27B suporta contexto de 1 milhão de tokens e, em um DGX Spark, exige cerca de 100GB de memória com KV cache em f16

Problemas de prompt caching e preservação de raciocínio

• Modelos híbridos da Qwen têm problemas com prompt caching, reprocessando o contexto inteiro a cada turno
  • A maioria dos modelos locais não foi treinada para preservar todo o raciocínio entre turnos, então após longas cadeias de tool calling é preciso reprocessar sem o raciocínio mantido
  • Qwen 3.6 foi treinado para preservar raciocínio, e a configuração chat-template-kwargs = {"preserve_thinking": true} melhora a reutilização de cache
• LLMs modernos não usam apenas full attention, mas também local attention (sliding window, modelos de espaço de estado Mamba-2)
  • Full attention tem custo O(n²), é caro e fraco para raciocínios cujos valores mudam ao longo do tempo
  • Local attention salva snapshots e, ao recalcular o cache, reinicia a partir do último snapshot; mas se o snapshot for grande, há limite de retenção
  • Qwen 3.5 ou superior usa Gated DeltaNet, alternando camadas de attention e SSM
• Vulkan é paradoxalmente mais rápido que ROCm, e manter o llama.cpp atualizado é importante para resolver problemas de reprocessamento
• É difícil resolver problemas de divergência do tokenizer, em que tokens gerados autoregressivamente são interpretados de forma diferente no prefill

Debate sobre custo e eficiência energética

• 2x RTX3090 custam cerca de $4400, o equivalente a 3,6 anos de Claude a $100/mês, sem incluir energia nem outras peças
  • Mesmo após 3,6 anos, é provável que GPUs de alta capacidade ainda mantenham preço alto
  • Em regiões com energia cara, há casos em que o ponto de equilíbrio cai para cerca de 1 ano
• O consumo de energia é menor do que o esperado
  • Em carga total de 1,2kw, o custo é de cerca de $0,12/hora, e com solar sai ainda mais barato
  • Inferência não pesa como jogos; o problema de energia é pequeno, com o sistema em idle a 200W e inferência entre 350W e 450W
• Sobre o momento de comprar hardware
  • Agora não é um bom momento; a próxima janela favorável deve ser daqui a 24–36 meses
  • Um Mac mini M4 Pro com 48gb de RAM unificada por cerca de ~$2k é recomendado como equipamento de inferência de entrada, com ~150tok/s e potencial para uso pelos próximos 10 anos
  • Uma AMD R9700 com 32gb de VRAM por ~$1200-1400 é mais vantajosa para IA do que 2x 9070
• Alugar (assinatura em nuvem) também é uma estratégia válida, e nem todo mundo pode investir muito dinheiro em hardware

Avaliação frente aos modelos de fronteira

• Repetem-se avaliações de que os modelos locais têm "qualidade de modelos de ponta de 8 a 12 meses atrás"
  • Em benchmarks, Qwen 3.6 35B-A3B supera Claude 4 Opus, mas há a possibilidade de benchmark hacking em alguns modelos open source
  • Em um teste de browser OS no YouTube, Qwen 3.6 gerou mais funcionalidades funcionando do que Claude 4 Opus
  • Ainda assim, isso seria no nível dos modelos de fronteira de um ano atrás, e há forte contestação à ideia de comparar um MoE com 3B ativos a Opus ou Sonnet atuais
• A divergência na definição de "nível Opus" é o centro da discussão
  • O nome passou a ser usado desde o Claude 3 Opus de 2024, mas ainda existe distância para os modelos mais recentes como Opus 4.8 e 4.6
  • Em novembro do ano passado, Opus 4.5 e GPT 5.2 marcaram um salto gradual nos modelos de fronteira, e normalmente "nível Opus" passa a significar algo depois do 4.5
  • Os maiores modelos com pesos abertos exigem hardware de classe servidor com 8x H100; modelos domésticos ainda não chegam lá
• Alguns avaliam os modelos locais como estando entre Haiku 4.5 e Sonnet 4.5, entregando bons resultados quando há microgerenciamento
• A diferença entre fronteira e local provavelmente sempre vai existir, mas para muitos usuários os modelos locais já são práticos

Estratégias de harness e fluxo de trabalho

• O Pi harness é o mais recomendado e tem perfil de kit para desenvolvimento de agentes, comparado a ser o "neovim do vscode do Claude"
  • Oferece ferramentas básicas (acesso a arquivos, edição e bash), com possibilidade de adicionar adaptadores MCP e extensões de busca web
  • O comando /tree permite voltar o contexto para antes de uma chamada de ferramenta que falhou, e /new reinicia o contexto
• Um fluxo hierárquico e com divisão de papéis ajuda a compensar limitações
  • Um modelo de fronteira escreve especificação, design e plano de execução, enquanto o modelo local implementa
  • Agentes são conectados por função (gerente de projeto, agente de schema, agente de programação), com orquestrador e Playwright repassando apenas erros para a etapa seguinte
  • As tarefas são quebradas em TODOs atômicos e os arquivos de referência são explicitados para economizar contexto
• O OpenCode às vezes altera o system prompt a cada turno, o que o torna incompatível com KV cache, e seu suporte a LLM local é manual e complexo
• O Ollama é criticado por adicionar modelos em nuvem e monetização; recomenda-se llama.cpp e llama-swap, e no macOS o llm-mlx é de 10-15% mais rápido

Exemplos de configurações concretas

• Em um ambiente com AMD 7900xtx 24gb + 5950x + 64gb DDR4, o Qwen3.6-27B-MTP-UD-Q4_K_XL roda em llama.cpp Vulkan
  • Flags principais: -ngl 99 (offload de todas as camadas para a GPU), -c 80000 (contexto de 80K), --cache-type-k q8_0 --cache-type-v q8_0 (KV cache de 8 bits), -fa on (flash attention), --spec-type draft-mtp (rascunho MTP)
  • Sampling: --temp 0.6 --top-p 0.95 --top-k 20 --min-p 0.0 (valores recomendados para programação com Qwen)
  • Desempenho: geração de tokens ~65t/s, processamento de prompt ~600t/s, cold start ~30 segundos
  • Com a combinação Crush harness + Headroom + busca web via Exa MCP, a assinatura pessoal do Claude Code foi cancelada
• Em uma V100 32GB, Qwen3.6-27B-UD-Q4_K_XL + Pi usa o fork llama-cpp-turboquant com patch MTP aplicado
  • Com 200.000 de contexto e --spec-type mpt --cache-type-k turbo3 --cache-type-v turbo3, chega a 45-60 t/s
• Em um Strix Halo 128GB, Qwen3.6-35B-A3B processa prompt a ~800tps e gera tokens a 50tps, quase sem consumir energia em idle
  • Lamenta-se a ausência de uma versão 122B, e em memória unificada modelos densos ficam lentos por limite de largura de banda
• Também aparecem reclamações sobre falta de detalhes, com pedidos para explicitar quantização, parâmetros, contexto, GPU, VRAM e configuração do harness

[b89kim]

Quando usei Pi-coding-agent+Qwen3.6-27B-MTP-GGUF, o desempenho ficou no nível do Sonnet 4.5. Foi suficiente para criar apps simples e, quando necessário, eu ocasionalmente conectava uma API gratuita (como GLM5.1). O consumo de energia de GPUs do nível da 4090/5090 realmente é alto, mas com um agent bem projetado não acontece com frequência de precisar deixá-lo rodando por horas.

[GN⁺]

Comentários do Hacker News

• Greenpants: Privacidade de dados e LLMs grátis são importantes para mim, então uso o harness de codificação do Pi em contêineres e sandbox, totalmente offline
  Uso o Qwen3.6 35B em um Mac Studio 128GB ou MacBook 36GB, e como os parâmetros ativos são 3B, ele é bem rápido. Redesenhei completamente meu site e blog com Django + Wagtail, mas como o Wagtail é menos conhecido, sem internet o agente nem sempre entende bem
  Para tarefas complexas também usei o Qwen3.5 122B, mas como tem 10B ativos, é bem mais lento. Comparado a modelos grandes como o Claude, você precisa fazer perguntas com muita precisão, e qualquer suposição deixada em aberto normalmente é resolvida pelo caminho mais fácil, levando a escolhas arquiteturais questionáveis, como colocar CSS dentro do HTML
  Ele também erra bastante ao chamar ferramentas de edição e entra em loop. O Qwen3.6 35B tem conhecimento geral, mas é como um júnior que precisa ser guiado o tempo todo, enquanto o Claude Opus é mais parecido com um sênior que pensa na arquitetura junto com você. Se o Opus dá uma aceleração de 15x, o Qwen totalmente offline dá algo como 5x, mas ainda assim é impressionante por ser gratuito

  • lambda: Também rodo o Pi em contêiner e o conecto a um llama.cpp em outro contêiner
    Permito acesso à rede, mas bloqueio credenciais, e deixo acesso apenas ao diretório de trabalho e ~/.pi. Uso um notebook Strix Halo com 128GiB de memória unificada e, como prefiro não programar com ferramentas proprietárias, não consigo comparar de verdade com modelos de ponta
    Ainda sou cético em relação à IA, então passo mais tempo tentando quebrar os modelos e entender seus pontos fortes e fracos do que usando em produção, mas para codificação com agentes escolho com mais frequência o Qwen 3.6 35B-A3B. Para chat geral e tradução uso bastante o Gemma 4 31B, e para áudio o Gemma 4 12B
    Também mantenho Qwen 3.5 122B-A10B, Qwen 3.6 27B, Nemotron 3 Super 122B-A12B, Step 3.7 Flash, Minimax M2.7 e GPT-OSS 120B, mas nessa configuração o Qwen 3.6 35B-A3B está hoje mais perto do sweet spot para programação
  • geophile: Tive praticamente a mesma experiência. É preciso planejar com muito cuidado, dividir em etapas pequenas e independentes, e a pessoa precisa escrever o design de forma clara
    Se você deixar o qwen preencher os detalhes sozinho, ele entra em loop pouco antes de terminar de escrever. O problema de não conseguir editar também era estranho, então no AGENTS.md mudei para limitar edições e favorecer reescrita, e isso ajudou um pouco
  • adyavanapalli: Para ferramentas de edição, talvez valha considerar uma abordagem baseada em hash, em que cada linha de código recebe um hash e as substituições referenciam esse hash
    A abordagem pode ser vista em https://blog.can.ac/2026/02/12/the-harness-problem/. Não medi com benchmark de verdade, mas na prática senti menos erros de edição, embora possa variar conforme o ambiente

• horsawlarway: Para uso pessoal, cancelei a assinatura de 100 dólares por mês do Claude e substituí por um pi harness apontando para o unsloth studio e modelos Qwen e Gemma
  Em uma máquina com duas RTX3090 montada há cerca de 5 anos, rodo unsloth/Qwen3.6-35B-A3B-MTP-GGUF e unsloth/gemma-4-26B-A4B-it-GGUF com quantização UD-Q4_K_XL, e ambos entregam cerca de 150tok/s com contexto total de 300k dentro da VRAM
  Não é tão bom quanto o Claude, mas é grátis, e para uso pessoal essa diferença não é um grande problema. Também uso o OpenClaw ligado ao mesmo servidor de inferência, e ele se encaixa muito bem em usos com modelos locais
  Por exemplo, fiz um launcher alternativo para Android TV, um portal administrativo para serviços em k8s, integrações e automações do Home Assistant, gerenciamento de compras e refeições, e fluxos de trabalho do ComfyUI para gerar assets 3D. Se fosse software para ganhar dinheiro, eu ainda recomendaria um provedor pago, mas modelos locais também conseguem fazer coisas bem legais

  • rootlocus: Duas RTX3090 custam cerca de 4.400 dólares, o que, mesmo sem contar energia elétrica e outros componentes, equivale a 3,6 anos de Claude a 100 dólares por mês
  • kpw94: Se você está rodando gemma com quantização UD-Q4_K_XL, talvez valha olhar também modelos QAT como unsloth/gemma-4-26B-A4B-it-qat-GGUF
    Veja https://huggingface.co/unsloth/gemma-4-26B-A4B-it-qat-GGUF e https://blog.google/innovation-and-ai/technology/developers-.... A atualização de 9 de junho também adicionou suporte a MTP
  • twothreeone: Testei o mesmo unsloth/Qwen3.6-35B-A3B-MTP-GGUF em uma única 3090, com contexto de 128k e quantização Q4_K, e obtive algo em torno de 40~60tok/s
    O que mais incomodou foi a qualidade da saída em tarefas reais de codificação com complexidade média. Eu tinha que ficar alternando entre “empurrar via prompt” e “implementar diretamente”, o que trazia um custo alto de troca de contexto, e a cada poucos minutos eu precisava decidir se o problema era meu pedido ruim ou limitação do modelo
    Ele também não consegue fazer bem a transição de detalhes de implementação de baixo nível para design de alto nível, e nem renderiza coisas como tabelas com facilidade. Não tenho esses problemas no Claude, então por enquanto é difícil ver isso como substituto, embora eu espere que daqui a alguns meses isso mude. Substituí o Claude CLI por aider, mas essa escolha também pode não ser a ideal

• bluejay2387: Faz cerca de 90% da programação com Qwen 3.6 27B, Open Code, skills customizadas e Semble
  Não é tão inteligente quanto CC ou Codex, mas dá para concluir a maior parte do trabalho. Como tem uma RTX 6000, o TPS é rápido o suficiente, e essa GPU originalmente era para outras tarefas
  Começou como um experimento para ver o quão perto dava para chegar dos modelos de fronteira, mas ficou bom o bastante para continuar usando. Para tarefas realmente complexas ou refinamento de UI, ainda volta para o Codex, e a UI parece ser o ponto mais fraco do Qwen
  Não é uma recomendação. Pouca gente tem uma RTX 6000, e o custo equivale a vários anos de assinatura do MAX CC ou Codex. Mesmo assim, o potencial existe, e daqui a alguns anos pode se tornar prático
  Em contexto de 256k, ajustou o compact target para 75%, e quando a conversa passa de 100k, a qualidade e a velocidade começam a cair; depois de 150k, fica bem problemático. Também testou o Qwen 3.5 122B, mas ele foi muito pior em programação do que o 3.6 27B. O Gemma 4 31B é bom em outras tarefas, mas para programação o Qwen fica na frente, e o Nemotron Super 120B também foi surpreendentemente pior do que o Qwen para programar

  • heipei: Roda Qwen 3.6 27B Q6 com llama.cpp em uma RTX 5090 e agora usa só o pi agent
    Como é local, não precisa se preocupar nem um pouco com preço por token, cotas, fuso horário ou sensibilidade dos dados. Limitou a GPU de 600W para 450W e, mesmo durante a inferência, ela fica bem silenciosa
    Acaba usando bastante não só para programar, mas também para tarefas cotidianas. Pede coisas como fazer commit em uma branch e abrir um PR, pegar faturas em aberto e vencidas com o Stripe CLI e cruzar com CSV do banco, resumir a causa da carga atual com credenciais do Elasticsearch, ou verificar se o codebase suporta X e onde isso está implementado
  • bo1024: Qwen3.5-122B na verdade é Qwen3.5-122B-A10B
    O A10B é um modelo mixture-of-experts, então só 10B de parâmetros são ativados por vez, enquanto o Qwen3.6-27B é um modelo denso em que todos os 27B parâmetros ficam sempre ativos. Por isso, em muitas tarefas, o modelo denso de 27B pode ser melhor do que o 122B-A10B
  • user43928: No trabalho, é obrigado a usar o Qwen 3.6 27B e acha que ele é quase inútil
    É melhor fazer por conta própria; ele implementa tudo de forma desastrosa ou erra completamente o debugging. Tirando algo como uma busca mais inteligente, qualquer coisa abaixo do Sonnet parece perda de tempo
    Também acha estranho usar Codex para refinar UI. O Codex é famoso por ser ruim de UI e fica bem atrás do Claude Opus. O próprio Altman postou que está melhorando isso no próximo modelo

• pierotofy: A combinação Llama.cpp + Qwen3.6-35B(MTP) + OpenCode é bem competente em uma única RTX 3090 e mais rápida do que a maioria dos modelos em nuvem
  A qualidade parece a de modelos de ponta de 8 a 12 meses atrás. As configurações estão em https://github.com/pierotofy/LocalCodingLLM/

  • jacobgold: Se “qualidade de modelo de ponta de 8 a 12 meses atrás” for o nível, isso é excelente para hobby, mas para um desenvolvedor profissional usar como base principal de agente de código, o ponto de corte foi mais ou menos 6 meses atrás, quando saiu o Opus 4.6
  • trueno: Tenho um MacBook Pro M4 Max com 128GB e queria mexer nisso, mas está faltando tempo
    Queria ouvir a experiência de usuários de Mac com uma configuração parecida. Vejo muita discussão sobre o lado local, mas a referência muda o tempo todo e os termos ainda não são familiares. Queria entender de forma objetiva o que se perde e o que se ganha ao ir para o local
  • atomicnumber3: Já não tenho vontade nenhuma de usar Claude

• codinhood: Acho que essa pergunta não vai render muitas respostas “de verdade”. Hoje o custo de oportunidade de não usar os modelos mais novos e melhores é alto demais
  Mesmo pesquisando todo mês, a conclusão continua a mesma. O tempo, esforço e custo para fazer modelos locais e ferramentas de programação ao redor chegarem perto do Sonnet/Opus no Claude Code ainda não valem a pena
  Se valessem, isso já teria virado notícia de tão disruptivo que seria. Não estou negando que alguém possa ter resolvido, mas isso parece mais uma aplicação da navalha de Ockham para não cair em um buraco sem fundo

  • pyeri: Esse trem do FOMO do custo de oportunidade vai chegar a um ponto de saturação, e eu acho que já passou dele
    Modelos de nível Mythos são estado da arte em raciocínio, mas não servem para muita coisa no tipo de problema que a maioria dos desenvolvedores tenta resolver. O mais provável é que algo por volta da família Sonnet/Opus 4.8 acabe sendo o nível amplamente usado nas empresas
    Os modelos locais ainda não chegaram lá, mas dá para usar DeepSeek, Kimi, GPT e MiniMax de forma barata por APIs como NVIDIA, OpenRouter e Groq, e eles chegam bem perto do nível do Sonnet
  • mark_l_watson: A mesma conclusão parece correta. Quero migrar para um sistema em camadas: local, API comercial tipo OpenCode + DeepSeek v4 flash e DeepSeek v4 Pro
    Assim dá para continuar fazendo o que precisa enquanto se move gradualmente mais coisas para o local. Mesmo no mesmo hardware, a configuração local está muito melhor do que há 2 meses e dramaticamente melhor do que há 6 meses
  • gunapologist99: Em vez de Ockham, talvez valha pensar em Pareto
    Se você realmente acredita que isso vai chegar lá em poucos anos, é melhor começar a mexer agora; e em projetos curtos ou pequenos, ou projetos grandes bem modularizados, você pode se surpreender bastante

• sosodev: Esta pergunta cobre uma faixa ampla demais de capacidades e expectativas. Se você estiver rodando só modelos de 8B e esperando vibe coding ou one-shot, vai ser difícil.
  Se você consegue rodar algo na faixa de 30B, eles se saem muito bem em tarefas com escopo adequado e bem definidas. Hoje, nessa faixa, Gemma4-31B e Qwen3.6-27B parecem ser os melhores.
  Se quiser inferência mais rápida, pode trocar para modelos MoE, mas eles caem de forma perceptível na maioria das tarefas. Em tarefas de escopo pequeno, one-shot e vibe coding até funcionam, mas ainda assim vão muito melhor com orientação.
  Se você quer capacidade de nível frontier, precisa de pelo menos 128GB de memória e muita computação ou muita paciência. A maioria das pessoas não tem dinheiro ou paciência suficientes. A paciência com modelos locais não é só esperar pelos tokens, mas também o esforço de configurar tudo para o seu workflow e hardware e fazer funcionar direito.

  • argee: Em um MacBook M4 Pro com 48GB de RAM, uso Gemma 4 26B A4B para estudar Rust e responder várias perguntas.
    Não acredito que ele vá se sair bem em one-shot, exceto talvez em mudanças bem triviais no IDE ou no harness. Ainda assim, se houver um humano ao volante olhando a estrada e andando abaixo do limite de velocidade, ele é rápido e bom o bastante como copiloto para tarefas de contexto pequeno a médio.
    Comparado com alguns anos atrás, é impressionante, e acho que sem isso eu quase não usaria IA para programar. Não gosto da sensação de ficar mais burro ou travado quando a conexão com a internet cai.
  • user43928: Pedi a um modelo pequeno, especificamente o GPT 5.4 Mini, para mover uma alteração de 10 a 20 linhas de código para outro arquivo, e na segunda tentativa ele ainda mudou o código e introduziu um bug.
    Eu não esperava confiabilidade perfeita, mas achei que, apontando a diferença, pelo menos na segunda vez ele acertaria. Na prática, ele afirmou com confiança que o código estava igual e ainda adicionou outro bug sutil.
    Não sei que tipo de trabalho seria suficiente para um modelo tão lixo. Ele consegue fingir competência por alguns minutos, mas no fim o resultado não bate. No máximo, acho que serve para busca mais inteligente ou autocomplete.

• mgsram: Depois de usar LLMs locais por cerca de um ano, agora me estabilizei em uma combinação de Qwen3.6 27B dense GGUF, OpenCode e llmster(LM Studio) em um Mac Studio com 512GB de RAM.
  Também testei o Qwen 3.6 35B-A3B, mas a precisão do modelo dense é um nível acima, em troca de sacrificar tokens por segundo. O Qwen3.6 27B normalmente entrega algo em torno de 25~40tok/s.
  No começo eu usava para ferramentas simples, mas nos últimos 3 a 4 meses venho realmente usando em codificação de nível de produção em uma stack automotiva C/C++ e em ferramentas Python. A velocidade menor até ajuda a avançar num ritmo apropriado.
  Para desenvolvimento novo e reescritas, eu uso o Sonnet junto para criar design, arquitetura, raciocínio e um plano detalhado de execução, depois quebro isso em partes e coloco em prompts precisos. Em trabalho sobre código existente, é preciso julgamento, e quando sinto os limites do modelo local, volto para o Claude Code.
  Recentemente, com o Qwen 3.6, reescrevi por completo um serviço de gerenciamento de energia em C com base em código C++ existente, um parser complexo de especificações em Excel, e uma ferramenta que traduz conteúdo em CJK para inglês e o insere em um KG.

  • russelg: Se você tem 512GB, talvez valha a pena olhar também para rodar deepseek4: https://github.com/antirez/ds4

• 3abiton: Como todo mundo mencionou Qwen, eu também rodo Qwen 3.6 35B Q8(MTP) com Strix Halo e llama.cpp.
  Consigo algo em torno de 40~50t/s e o desempenho é realmente muito bom. Já usei direto no zsh com forge-code, e em contexto longo acima de 150k a qualidade cai e ele começa a esquecer.

• wsintra2022: Lendo os comentários aqui, às vezes não dá para saber se são bots tentando desincentivar uso local em nome dos provedores de IA, ou pessoas que realmente tiveram experiências ruins com modelos locais.
  Rodar Qwen 3.6 27B 8k quantizado em um Mac Studio 64GB não é uma superpotência universal de nível frontier, é só bom. É grátis, privado, e a mágica é levar engenheiros experientes de preguiçosos a ainda mais preguiçosos.
  Eu uso llama.cpp e opencode para planejar e executar mudanças no código, depois vou me deitar na rede, lavar a louça ou fazer outra coisa. Entro por tmux e ssh para verificar. Essa parte é o que realmente impressiona.

  • epolanski: Na indústria de “engenharia” de software, há muitos ninjas de Leetcode do MIT escrevendo um slop React+Tailwind inútil e cheio de memory leak, então a linha de base é muito baixa.

• garethsprice: Em uma Ada 4000 com 20GB de VRAM, uso OpenCode + OhMyOpenCode + Qwen 3.6 35B-A3B Q_4_KM, e a geração fica em torno de 55tok/s.
  Como o OpenCode anexa muito contexto, a sensação é de ser mais lento do que os números sugerem. Muita gente também citou Pi, então vou olhar isso em breve.
  Faço o planejamento com Opus, deixo o agente local seguir isso, e depois valido com Opus. Não é 100% local, mas esses modelos estão cada vez mais virando parte do workflow de produção.
  Talvez ainda não valha a pena para quem não gosta de mexer nisso por hobby, gastando tempo e dinheiro. Não é tão bom quanto Opus ou outros modelos frontier, mas, na faixa em que o trabalho repetitivo aumenta, é “bom o bastante”.
  Você não precisa de um Rolls Royce para ir ao supermercado se tem um Corolla usado. Isso também viabiliza novos workflows cujo custo seria pesado com LLMs frontier. Deixei rodando durante a noite testes de fuzz como se fosse um usuário com Chrome devtools MCP, incluindo checagem multimodal de screenshots, e pensando no custo de Claude+screenshots isso impressiona.
  A frase “12 a 18 meses atrás do frontier” parece correta. Daqui a 12 a 18 meses, talvez dê para rodar localmente um modelo no nível do Opus por menos de 5 mil dólares, mas os modelos frontier também terão avançado ainda mais.

• arjie: Não é local e também não é coding interativo, mas eu rodo DeepSeek V4 Flash com duas RTX Pro 6000 Blackwell.
  A velocidade bruta é 160tok/s, mas é um modelo de raciocínio. Meu uso é geração automática de código e revisão automática de outros sistemas. Quando deixo o Pi escrever código às vezes, ele é muito rápido, mas por hábito continuo usando mais CC e Codex.

  • akersten: Fico curioso sobre onde você conseguiu as RTX Pro 6000 Blackwell.
    Todos os sites que encontrei estavam sem estoque, vendiam só para empresas ou pareciam suspeitos.
  • leptons: Fico curioso se você já mediu o consumo de energia desse setup. Me preocupo com quanto isso sairia por mês.

• stymaar: roda o Qwen3.6-35B-A3B em um Strix Halo 128GB Bosgame M5
  Tem VRAM até demais para esse modelo, mas a Qwen não lançou uma versão 122B do Qwen3.6 que seria a ideal para o meu hardware. Em compensação, a conta de luz é praticamente irrelevante. Como originalmente é um chip de notebook, quase não consome em idle, e mesmo processando prompts fica pouco acima de 120W
  O Qwen3.6 é surpreendentemente eficaz, então só uso Claude às vezes, em cerca de 10% das minhas necessidades totais. Mesmo com o plano mais barato, continuo abaixo da cota. A velocidade é de cerca de 800tps no processamento do prompt e 50tps na geração de tokens, sem usar decodificação especulativa

  • manmal: queria saber se você também testou a versão densa de 27B. Para código, ela é muito melhor

• Kostic: para uso pessoal, conecto o VSCode ao llama.cpp e rodo Qwen 3.6 27B ou Gemma 4 31B, e isso já é suficiente para cancelar assinaturas de cloud
  O Qwen fica em q4@176k de contexto na primeira GPU, com MTP em algo como 70~50tok/s, então é bem bom para programação. O Gemma usa as duas GPUs, com q8@64k de contexto, e faz análise de sentimento de documentos, resumo, revisão e tradução a 25tok/s
  É um pouco lento para workflows em lote, mas dá para usar. Se o llama.cpp passar a suportar MTP no modo tensor split, acho que ainda dá para melhorar
  No trabalho, como não sou eu quem paga o custo, ainda uso LLMs de fronteira, e claro que são melhores. Espero que daqui a um ano apareça um modelo de 30B no nível do Sonnet 4.6/Opus 4.5
  O processamento de prompt começa em 800t/s e cai até 400t/s. Como meus prompts iniciais normalmente têm entre 16k e 24k tokens, isso leva de 60 a 90 segundos para processar; não é ótimo, mas é aceitável

• jodoherty: usa Gemma 4 31B em uma RTX Pro 6000 Blackwell com o Pi para toda a programação com agentes
  Acho útil, e esse projeto paralelo se parece com a forma como eu defino escopo e executo projetos no trabalho: https://git.theodohertyfamily.com/wg-wrap.git/tree/README.md https://git.theodohertyfamily.com/wg-wrap.git/tree/CASE_STUD...
  É preciso aplicar arquitetura cuidadosa e bastante TDD. Resolvo as partes difíceis no começo para empacotar tudo em uma interface simples e fácil de usar, eliminando o risco técnico
  Em alguns projetos, isso é 2~3 vezes mais rápido do que escrever tudo na mão; em projetos chatos ou muito amplos, ajuda a reunir e testar ideias rapidamente, economizando de 5 a 10 vezes o tempo
  Minha configuração alterna entre vLLM com nvidia/Gemma-4-31B-IT-NVFP4 e llama.cpp com unsloth/gemma-4-31B-it-qat-GGUF, que tem MTP. Limito a energia da GPU a 400W. Hoje, a configuração do llama.cpp entrega 60~150t/s dependendo da taxa de aceitação do draft no MTP, e o prefill fica em 1500~4000t/s dependendo do comprimento e da profundidade do contexto

• jborak: roda Qwen3.6 27B MTP Q6_K no llama.cpp com quatro RTX 5070 e um AMD Threadripper 1950X de primeira geração, e usa o Pi muito bem como driver diário
  A velocidade fica em torno de 50~60tok/s. Também conecto outros apps, como o OpenWeb UI, e recentemente defini o gateway de LLM Bifrost como ponto de entrada padrão para acesso aos modelos
  Também testei o Qwen3.6 35B A3B, mas para programação o 27B funciona melhor. Como é um modelo denso, ele é mais lento, mas a qualidade parece bem superior. O 35B A3B faz 130~140tok/s sem MTP, então é absurdamente rápido
  Não é obrigatório ter quatro 5070 para rodar o Qwen3.6 27B; três, talvez até duas, podem bastar. Mas, se você usar MTP para acelerar o 27B, o modelo draft precisa do próprio contexto, então consome mais memória
  Também é bom lembrar que o prompt de sistema das ferramentas é carregado no modelo em cada conversa. Quando ligo o Pi, o começo é muito responsivo, mas ao interagir pelo Hermes CLI, cada prompt carrega bastante contexto com skills, tools etc. e isso permanece até o fim da conversa, deixando tudo bem mais lento
  Privacidade é legal, mas também gosto do fato de não haver cota nem preocupação com uso. Se o futuro for “engenharia de loops”, com modelos na nuvem você vai queimar tokens e dinheiro. Meu sistema consome 200W em idle e 350~450W sob carga pesada de inferência, e a decodificação não é tão eficiente, então as GPUs ficam ociosas com mais frequência do que eu esperava. Avanços como diffusion talvez acelerem a decodificação e aumentem o uso das GPUs ociosas

  • zakisaad: queria entender por que você escolheu a 5070 para uma configuração com 4 placas
    À primeira vista, parece mais inclinada para desempenho de computação e com pouca VRAM, então boa para gamer, mas não tão boa para rodar LLM. Eu também uso uma 5070 no meu desktop

• cuttysnark: com modelos locais, teve algum sucesso ao encadear vários agentes em um workflow
  Cada agente usa prompts e modelos do ollama diferentes conforme o papel. Um agente de gerente de projeto ou de schema (qwen3:14b) não usa o mesmo modelo que um agente de programação (qwen2.5-coder:7b)
  Entre cada etapa há um orquestrador e tarefas com Playwright, tentando expor erros ao agente que gerou o bloco de código anterior. Só blocos sem erro passam para a próxima etapa
  A maior melhoria foi adicionar uma definição de serviço backend-for-agents, para que o agente de schema gere apenas um manifest baseado em tarefas e o passe ao próximo agente. Resumindo, você define o workflow para dividir o trabalho em tarefas bem específicas para os agentes e passar adiante para a próxima etapa. Isso evita que eles percam a base e também cria pontos em que uma pessoa pode intervir em fluxos que estejam 25% ou 90% prontos

  • pianopatrick: se existissem benchmarks e competições de workflow assim, daria para ver o que realmente funciona
    Algo como: “usar apenas esta GPU de consumidor, com o modelo e o workflow que quiser, e ver quão bem resolve o benchmark xyz”. Seria legal algo como um “The Local AI challenge”, dando no máximo 1 hora para os participantes e pontuando proporção respondida, taxa de acerto e tempo total
  • sowbug: queria saber se você já tentou colocar os agentes para competir entre si
    Por exemplo, dar a mesma tarefa de programação para dois modelos, ou para seeds diferentes do mesmo modelo, e fazer um revisor escolher o melhor resultado. Há quem veja o cérebro humano como algo que funciona assim também, com milhares de minicolunas corticais olhando a situação de formas ligeiramente diferentes e votando por maioria

• HappySweeney: Tenho Optane e muita RAM, então experimentei durante a noite um modelo próximo do modelo completo, escrevendo funções a cerca de 0,7 t/s
  O teste atual é substituir uma função em Scala por uma função de transposição de matriz de bits usando AVX512. Os modelos em nuvem fazem isso com facilidade, mas Kimi 2.6 e GLM 5.1 fracassam miseravelmente

• etoxin: Ainda não consegui substituir. Em projetos do trabalho uso openspec e, para imitar hardware local sem gastar uma fortuna, pago pelas versões hospedadas dos modelos locais populares mais recentes
  A maioria dos modelos locais pequenos ainda não lida direito com chamada de ferramentas, mas os maiores agora já fazem isso razoavelmente bem. Um ponto do lado local que ainda não vi ser considerado é que engenheiros produtivos normalmente rodam vários chats de CLI ao mesmo tempo junto com git worktree. Eu geralmente mantenho 3 worktrees e chats de CLI abertos

• blurbleblurble: No momento, acho que o limite não está tanto no modelo em si, mas na usabilidade dos harnesses alternativos, aos quais faltam de forma estranha recursos como gerenciamento de fila, interrupção, subagentes e metas

  • coder543: Concordo totalmente. Também é irritante que o OpenCode não pareça tentar dar suporte adequado a LLMs locais
    Dá para fazer o OpenCode funcionar, mas a configuração é muito manual e desajeitada. Criei um script que converte automaticamente a configuração do llama-server para a configuração do OpenCode, e isso ajuda, mas não é o ideal
    Nas horas vagas, considerei seriamente fazer mais um harness de programação. Tenho algumas ideias de como fazer melhor
  • horsawlarway: Pi é decente
    Já usei os agentes de CLI do Claude, Cursor e Pi, além de harnesses personalizados que eu mesmo fiz, e até o gastown; o Pi simplesmente é suficiente. Faz o que eu preciso, as ferramentas padrão são boas, integra bem com outras ferramentas e me faz me preocupar menos
    Se você conseguir rodar modelos na faixa de 30B em uma velocidade decente, muita gente vai se surpreender bastante com o Pi. Com extensões como https://pi.dev/packages/pi-mcp-adapter?name=mcp e https://pi.dev/packages/pi-web-access?name=search, você também ganha acesso via MCP a ferramentas web, busca do Perplexity, controle do Chrome com https://browsermcp.io/, e do Firefox com https://github.com/mozilla/firefox-devtools-mcp
    Não é tão bom quanto os modelos topo de linha subsidiados, mas é grátis e ainda assim competente. Pessoalmente, também tenho me divertido bastante com https://pi.dev/docs/latest/sdk; outros provedores cobram milhares de dólares por mês por esse tipo de acesso à API
  • Insanity: Ouvi coisas boas sobre o pi.dev, mas ainda não experimentei. Talvez ele resolva parte dessas funcionalidades ausentes que você mencionou

• _bobm: Quando você fala em modelos Claude/GPT, precisa pensar no que esse “modelo” realmente é
  Basta lembrar como o GPT pode enviar a parte de raciocínio aos poucos e anexar resumos em cabeçalhos Markdown do próprio bloco de raciocínio. Se você observar o endpoint da API e o comportamento de saída, esses chamados modelos SOTA não são o que parecem à primeira vista e, em termos de infraestrutura, nem de longe são comparáveis a um modelo local
  Há uma enorme orquestração por trás de uma operação dessa escala, e as restrições dela levam a inovações das quais não se fala. Não acho que seja impossível alcançar, mas servir um modelo local com llama ou vLLM é só o nível A, B, C do alfabeto
  O que realmente seria necessário é reproduzir a orquestração sugerida acima. Um “modelo” SOTA não é um único modelo, e sim uma orquestração profunda de vários modelos trabalhando juntos. Por isso, um modelo único não vai alcançar isso até reproduzir essa orquestração em treinamento e arquitetura
  Acho que o modelo em si, dentro dessa composição orquestrada oferecida ao consumidor comum, não seria tão melhor que o Qwen 3.6. Quando você muda a perspectiva, começa a enxergar a escala da “mágica”

  • XCSme: Não entendo por que você acha que os modelos SOTA são uma orquestração profunda de vários modelos
    Também gostaria de ver um exemplo mais concreto disso que você disse sobre o GPT enviar a parte do raciocínio com resumos em cabeçalhos Markdown

• cheekygeeky: Nosso desenvolvedor de software é a pessoa mais inteligente que já conheci, e usa OpenCode e Tmux com modelos open source
  Para programação, ele prefere DeepSeek e diz que é “muito bom”. Roda em um i9, 128 GB de RAM e duas 3090. https://www.msn.com/en-us/news/technology/china-s-open-deeps...

• pianopatrick: Acho que seria útil haver benchmarks e competições para esse tipo de fluxo de trabalho, para vermos o que realmente funciona bem
  Algo como “usando apenas esta GPU de consumo, quão bem você resolve o benchmark xyz com o modelo e fluxo de trabalho que quiser”. Eu gostaria de ver uma competição tipo “The Local AI challenge”, em que os participantes têm no máximo 1 hora e são pontuados por proporção de respostas, taxa de acerto e tempo de conclusão

• bravetraveler: Uso de forma quase “natural”, e todo o pouco uso de LLM que faço é local
  Em um sistema Strix com 128 GB, variantes menos densas de Qwen ou Gemma produzem 50–80 tok/s. Não tenho intenção de assinar Anthropic/OpenAI etc., e mesmo que este fosse o último modelo local, eu não precisaria. O uso de ferramentas dentro do modelo cobre a preocupação com atualidade

• GodelNumbering: Como alguém que conversa com LLM o dia inteiro, acho que a combinação modelo de fronteira open source + bom harness já é suficiente
  Para uma implantação totalmente local, ainda faltam uma ou duas gerações de hardware para eu migrar de vez. Só que as fabricantes de hardware estão priorizando tão fortemente o setor de datacenters que talvez isso não chegue tão cedo

• milchek: Tentei em um MacBook Pro com 36GB, mas não tive muito sucesso além de tarefas bem básicas
  Mesmo usando modelos pequenos, o contexto se esgotava rápido e a lentidão era um problema. Para conseguir um desempenho minimamente decente, parece que seriam necessários 128GB de memória, o que aumenta muito o custo do hardware
  No fim, a questão é escolher entre assinar um modelo de ponta ou enterrar esse dinheiro em equipamento. Claro, se privacidade for importante, quase não há alternativa além de gastar com hardware de alto nível

• acc_297: Fico curioso se ajudaria aplicar RLHF rotineiramente a um modelo de porte médio em cada prompt, ajustando-o finamente aos hábitos pessoais de uso
  Não sei se ajustar o modelo manualmente iria piorá-lo ou melhorá-lo. Seria bom se um feedback consistente pudesse reduzir tiques de modelos genéricos, como bajulação excessiva, verbosidade e a irritante mania de explicar tudo por meio de analogias, mas não sei se o feedback de prompt de uma única pessoa seria suficiente
  Também ouvi dizer que agentes internos de empresas ajustados com documentação interna apresentam comportamentos estranhos e não são necessariamente mais úteis do que modelos padrão. Seria ótimo poder editar todas as respostas do agente e fazer ajuste fino a partir da diferença entre a resposta original e a editada
  Pessoalmente, eu removeria muitos adjetivos e refinaria para respostas mais diretas, mas ao ver o trabalho de pesquisadores de alinhamento como Owain Evans, fico preocupado que esse tipo de ajuste possa empurrar o modelo para tendências imprevisíveis

  • htrp: O Cursor está fazendo algo assim. Acho que usa a Fireworks como provedora: https://cursor.com/blog/real-time-rl-for-composer
  • rolisz: Quero tentar algo parecido no agente OpenClaw
    Acho que o trabalho do Owain Evans era SFT. Alguém no Twitter disse que RL é menos vulnerável ao fenômeno que ele mostrou, então quero testar por conta própria

• heisenbit: Dá trabalho configurar, mas estou aprendendo bastante no processo
  Num M4 MBP com 48GB, uso principalmente qwen/qwen3.6-35b-a3b mlx, e sobra memória por pouco para um Docker dev-container e tarefas básicas. Rodo com LM Studio e uso no VSCode
  Fazer alterações no prompt de sistema para melhorar a integração com ferramentas fez uma grande diferença. Antes disso, ele frequentemente regenerava código em vez de aplicar mudanças, o que mais atrapalhava do que ajudava
  Para evitar ruído e calor, uso quase sempre no modo de baixo consumo, mesmo ligado na tomada. No desempenho máximo a velocidade é cerca de duas vezes maior, mas o consumo de energia é mais que o dobro
  O máximo que consegui fazer foi uma reorganização simples de uma página, e separar uma store do Pinia falhou. O GPT-5.4 faz essa tarefa sem problemas. Acho que o desempenho ainda pode melhorar com mais ajustes nas orientações de uso de ferramentas e nas ferramentas de apoio ao redor

• nfrankel: Tentei, e em teoria funciona: https://blog.frankel.ch/tokensparsamkeit-coding-assistants/#...
  Os resultados variam conforme o modelo e, no fim, o limite é o computador. Infelizmente, meu equipamento não deu conta

• K0balt: Tenho obtido resultados bem bons com qwen 3.6 27b dense
  Dependendo da tarefa, ele fica próximo do Claude Haiku 4.5, e talvez às vezes chegue ao nível do Sonnet

  • kadoban: Queria saber com quais ferramentas você está tocando o fluxo de trabalho
  • kandros: Para tarefa de programação, eu preferiria perguntar ao açougueiro do que ao Haiku

• jderekw: Uso AMD Lemonade no equipamento do dia a dia
  Comecei com Ollama, passei para LMStudio e agora padronizei no AMD Lemonade, que ajuda a monitorar cRAM, CPU, GPU e gRAM. Os recursos multimodelo do Lemonade facilitam rodar uma pilha de LLM, fala-para-texto, NPU e geração de imagem
  A plataforma funciona em chipsets Nvidia, Apple, Intel e AMD

• redox99: Modelos que dá para rodar em casa, como o Qwen 35B, não chegam nem perto do Opus ou GPT 5.5
  Os modelos abertos que chegam perto disso estão na casa de 1T de parâmetros, então pode esquecer rodar em casa. É como dirigir um carro velho caindo aos pedaços: pode até ter gente dizendo que serve para ir de A a B e que está tudo bem, mas não está
  A menos que você precise de privacidade absoluta, esteja fazendo por diversão ou por um caso especial como num avião, não há motivo lógico. Se você não consegue pagar nem os US$20 super subsidiados do Codex, usar API de modelos chineses dá uma surra nesses modelos pequenos

  • pbasista: Fico curioso sobre em que fatos objetivos ou benchmarks se baseia a avaliação de que “modelos que dá para rodar em casa, como o Qwen 35B, não chegam nem perto do Opus ou GPT 5.5”
  • xgulfie: Você não precisa de uma Ferrari para ir ao trabalho

• sj_tech: Num Mac Mini com 128GB, uso Qwen 3.6 35B A3B para codificação com agente via GitHub Copilot Extension for VSCode
  É decente para o tamanho do modelo, mas vejo ele entrar em loop quando o problema fica grande demais. Serve bem para ganhar tempo mandando ele fazer coisas que você já sabe fazer

• julianlam: Num Framework 13 com 32GB de memória, rodo Qwen 3.6 35B-A3B no llama.cpp e consigo 15 tok/s
  Ele gera código e texto mais rápido do que eu consigo ler

• moezd: Ainda não. Sem os jogos puros da Apple ou uma GPU decente, mesmo com muita RAM e muitas threads, você fica só na faixa de 30 a 50 tok/s, e isso com o thinking desligado
  Sem esse tipo de otimização, o modelo engole MCP, skills e descrições de agentes à vontade, e você fica vendo tinta secar antes de aparecer o primeiro token de saída
  Servir modelos locais exige economizar cada token da janela de contexto, o que vai exatamente na direção oposta da forma como Claude/GPT/Copilot estão empurrando o setor

  • amarshall: thinking não muda a velocidade de saída. A velocidade mediana de saída dos modelos da Anthropic é algo em torno de 40 a 60 t/s

• mitchell_h: Tentei, mas a janela de contexto não era grande o suficiente

  • coder543: O Qwen3.6-27B suporta uma janela de contexto de 1 milhão de tokens
    Claro, você precisa de hardware capaz de rodar isso, e no meu DGX Spark, usar o modelo q4_k_xl com todo o KV cache em f16 exige cerca de 100GB de memória
  • lysace: Tive resultado parecido. Minha RTX 4070 tem só 12GB, então fico me perguntando se 24/32GB realmente melhora o suficiente para ser útil na prática
  • deadbabe: Em vez de deixar em aberto, é só fazer um prompt mais direto

• drnick1: Tenho curiosidade sobre qual é o melhor modelo de programação atual que dá para rodar em uma GPU avançada de consumidor
  Supondo uma RTX 3090/4090, também queria saber que stack vocês recomendam. Algo como Llama.cpp + OpenCode?

• bijowo1676: Achei interessante a configuração de usar um modelo frontier caro para escrever e atualizar documentos em Markdown como especificações do app, requisitos do produto e arquitetura, e depois fazer um modelo barato ou local implementar essas especificações
  O Markdown comprime melhor a informação do que centenas de arquivos-fonte, então cabe melhor na janela de contexto, mas são necessárias uma segunda e terceira passadas para lapidar as partes mais brutas. Queria saber se alguém já tentou trabalhar desse jeito

• grmnygrmny2: Tenho uma objeção ética ao uso de produtos da OpenAI ou da Anthropic, então também relutei em adotar LLMs
  Os modelos locais resolvem a maior parte da minha objeção moral, então venho usando há cerca de um mês no trabalho e em projetos pessoais. O hardware que tenho são Macs com 32 GB e um PC gamer com 3080 de 10 GB, então meu limite é algo como Qwen3.6-35B-A3B em várias quantizações, mas isso basta
  Consigo algo em torno de 200~400 PP e 20~30 TG, e levei um tempo para aprender a usar bem. Em algumas tarefas é preciso acompanhar ou dar direção, mas ainda assim é bem útil
  Nunca usei CC, então não posso comparar, mas funciona como um bom assistente ou programador em par, de C++ embarcado até Vue. Seria bom poder rodar um 27B, e às vezes este modelo parece quase entender alguma coisa, mas não consegue; ainda assim isso é raro
  Em muitas tarefas economiza bastante tempo, e gostei da capacidade de investigar bugs e corrigi-los mesmo com instruções bem vagas. Para o harness, uso um Pi