Executar modelos locais agora ficou bom

• Mesmo em um Mac M2 de 2022, os LLMs locais melhoraram a ponto de serem práticos para perguntas de desenvolvimento, tarefas de código e checagem de documentação
• Os primeiros modelos locais eram lentos, difíceis de usar e pouco precisos em tarefas de programação, mas depois do GPT-OSS a frequência de revalidação com modelos via API diminuiu
• Com os lançamentos mais recentes da linha Gemma 4, o loop local de codificação com agente opera com cerca de 75% de precisão e velocidade em comparação com modelos de fronteira
• A combinação de Pi e LM Studio executa workflows com agentes por meio de um endpoint local de inferência, artefatos de modelo e uma configuração de isolamento com Docker
• Os modelos locais ainda têm limitações de latência de inferência, janelas de contexto pequenas e restrições de hardware, mas permitem observar e alterar diretamente o processamento de tokens, o prompt de sistema, a quantização e o harness

---

Onde os modelos locais estão agora

• Os primeiros modelos locais eram lentos, difíceis de usar e imprecisos na maioria das tarefas de programação
• A avaliação de que os modelos locais estavam muito atrás era, em geral, correta para uso pessoal até o lançamento do GPT-OSS
• O critério pessoal para um “modelo bom o suficiente” era se ainda era preciso confirmar de novo com um modelo via API, e o GPT-OSS foi o primeiro modelo a reduzir bastante essa frequência
• Até recentemente, os modelos locais eram usados principalmente como um Google rápido e personalizado para perguntas de desenvolvimento que não exigiam informação atualizada
• Depois dos lançamentos mais recentes da linha Gemma 4, o loop local de codificação com agente roda com cerca de 75% da precisão e da velocidade de modelos de fronteira {p:75}

Modelos usados e ambiente de execução

• Vários modelos locais foram executados em um Mac M2 de 2022 com 64GB de RAM e 1TB de armazenamento
  • Os modelos usados foram Mistral 7B, Gemma 3, OpenAI OSS-20B, Qwen 3 MOE, Qwen 2.5 Coder etc.
• A configuração de execução passou por raw llama.cpp, Open WebUI, llama-cpp-python, Ollama, llamafiles e LM Studio
• O modelo local padrão usado foi a implementação do LM Studio de gemma-4-26b-a4b

Casos reais de trabalho com agentes locais

• Um notebook foi refatorado para um repositório com 5 a 6 módulos em script Python
• Esses módulos foram ajustados com lint para usar type hints genéricos de acordo com a PEP 585
• A configuração local também foi usada para revisar textos de blog, escrever testes unitários e fazer a configuração inicial de um repositório de modelo two-tower para recomendações
• O repositório de modelo two-tower gerado pelo agente do zero era básico, mas já ia além do que parecia possível no ano passado
• Todos os workflows com agentes foram executados dentro de contêineres Docker com acesso de execução restrito

Uso de recursos e modelos pequenos mais recentes

• As tarefas realizadas estavam mais próximas de um Google personalizado ou consulta de documentação do que de algo revolucionário
• Durante o trabalho, o uso de GPU e RAM aumentou, e o cache K-V cresceu até 64GB de RAM
• Mesmo tarefas simples desse tipo de trabalho com modelos locais eram impossíveis até cerca de 6 meses atrás
• O Gemma-4-12b-qat impressionou pelo desempenho em relação ao tamanho desde logo após o lançamento
• A arquitetura do modelo leva a questionar que tipos de compromisso arquitetural são necessários quando há restrições de desempenho e custo

Configuração para executar modelos locais com agente

• Para rodar um fluxo de agente local, é preciso um motor local de inferência de modelo, um harness de agente e artefatos locais do modelo
• O harness deve ser configurado para apontar para um endpoint local de inferência, e os artefatos de modelo baixados devem ser servidos pelo motor de inferência
• A configuração local atual usa Pi como harness de agente e LM Studio como servidor de inferência
• Seguiu-se o guia sobre configurar codificação com agente da Gemma 4 usando Pi e LM Studio, com algumas mudanças nas configurações
  • Em vez do Gemma 26B A4B usado no texto, foi usado o gemma-4-12b-qat, que é mais novo, menor e mais rápido, sem grande perda de precisão
  • Por segurança, todas as sessões do Pi rodam em contêineres Docker e recebem apenas permissão de bash, bloqueando execução de código Python e navegação na web
  • Em uma imagem separada para trabalho de pesquisa, há plano de permitir curl
  • Como roda dentro do Docker, foi preciso editar o models.json do Pi para que o Pi se comunicasse com o modelo

Método de isolamento baseado em Docker

• Na configuração do Pi, baseUrl foi definido como http://host.docker.internal:1234/v1, e a API foi configurada como openai-completions
• A configuração do Docker Compose monta models.json, o diretório de trabalho, a configuração do Pi e o diretório de sessões no contêiner
• O script de execução conecta o diretório de trabalho atual ao workspace do contêiner e, se necessário, adiciona um arquivo Compose de sandbox mais seguro
• O Pi roda no repositório em uso e sobe o Docker, então não consegue apagar diretamente arquivos ou diretórios do disco físico
• Foi possível passar uma configuração json de modelo personalizado para dentro do contêiner, e isso funcionou relativamente bem em ambiente de experimentação

Limitações que ainda restam

• Os modelos locais ainda podem ter inferência lenta, janelas de contexto pequenas, e o contexto disponível é limitado pelo hardware existente
• O ecossistema ficou muito mais fácil graças a ferramentas como o LM Studio e o botão Use This Model do Hugging Face
• As primeiras versões sofrem com problemas de incompatibilidade de template de prompt, mas esses problemas costumam ser corrigidos muito rapidamente
• Ainda é difícil ter certeza de que já estão prontos para uso direto em desenvolvimento de software de produção

Vantagens dos modelos locais e possibilidades de experimentação

• Com modelos locais, é possível observar quase tudo, inclusive o processo de inferência de tokens em tempo real
• Dá para verificar diretamente o fluxo de tokens de entrada e saída
• É possível mudar a janela de contexto local e observar quando o desempenho melhora ou piora
• Dá para investigar como os tokens são processados na GPU e também alterar o prompt de sistema e as configurações de quantização
• Também é possível colocar modelos para competir entre si ou mudar configurações do lado do harness e observar os resultados, ampliando continuamente as possibilidades de experimentação

[GN⁺]

Comentários do Hacker News

• Não sei se ficou realmente bom. Eu uso muito modelos locais, mas executar localmente ainda é bem doloroso
  Modelos densos como Qwen 27B e Gemma 31B são bem inteligentes, mas lentos, e modelos mixture-of-experts (MoE) como Gemma 26B, Qwen 35B e North Mini Code 30B são rápidos, mas cometem muitos erros
  Para rodar direito, é preciso muita memória, e ao quantizar, o uso de ferramentas enfraquece. A maioria roda em quantização de 4 bits e fica se perguntando por que é ruim, mas na prática isso é como fazer uma lobotomia no modelo. Recomendo a quantização da Unsloth, e sugiro 6 bits para MoE e 5 bits para modelos densos
  Para acelerar o prefill, é preciso desempenho computacional; para acelerar o decode, é preciso largura de banda; e para acomodar tudo, também é preciso muita memória. Além disso, notebook vira uma máquina quente e barulhenta, o que atrapalha trabalhar
  Então, é bom? Não muito. Funciona
  Dito isso, eu acho que modelos abertos são o futuro e continuo contribuindo com o ecossistema. Seria bom se as pessoas mexessem nesses modelos e usassem pi para aprender como funcionam, mas não dá para esperar que só baixar o modelo já vá ser ótimo. Para substituir o “agente de programação” que a maioria quer, ainda é preciso muito ajuste e configuração

  • Minha experiência foi quase igual. Há um ou dois meses, experimentei os modelos recomendados no ollama em um desktop relativamente novo e potente (Radeon 6900 XT com 16GB de VRAM, Ryzen 9 7900X de 12 núcleos, 64GB de RAM do sistema)
    Os modelos que não eram focados em programação frequentemente travavam no ponto de apenas dizer “eu faria esta ação”, sem de fato chamar a ferramenta, e mesmo perguntando o que eu deveria configurar para mudar esse comportamento, não ajudavam. O Qwen insistia que não acreditava estar rodando no ollama, dizia que estava executando na nuvem da Alibaba e que não tinha permissão para acessar o sistema local
    Até os modelos para programação mal pensavam mais rápido do que eu digitava, e os casos em que podiam mostrar o processo de raciocínio também eram limitados
    A melhor experiência “gratuita” que encontrei até agora é OpenCode + Big Pickle. Não é muito inteligente, então o primeiro resultado costuma estar errado, mas o plano gratuito é generoso o bastante para eu usar com frequência por algumas horas durante cerca de um mês e só ter batido no limite umas duas vezes. Se o objetivo for execução realmente local, isso não serve, mas se o objetivo for “a melhor experiência sem assinatura nem custo por token”, até agora foi a opção menos ruim
  • Para rodar bem modelos locais, ainda acho que é preciso investir em hardware caro. Para rodar esses modelos com um cache KV adequado, você acaba querendo algo como 96GB de VRAM em uma arquitetura Blackwell recente
    Tentar fazer isso em Macs com memória unificada, processadores AI Max da AMD ou equipamentos parecidos com um DGX Spark chega perto de procurar sofrimento. O prefill destrói o desempenho
    Com as GPUs certas, fica muito melhor, mas ainda não chega ao nível de Sonnet ou DeepSeek 4 Flash, e menos ainda de Opus / DeepSeek Pro ou Mythos/Fable/GPT-5.5
    Se houver orçamento, energia e refrigeração suficientes, dá para montar um pipeline de dados bem decente, mas para código ainda costuma fazer mais sentido pagar um provedor de API
  • Talvez você nem devesse rodar esses modelos em um notebook com fortes limitações térmicas, e também não deveria esperar qualidade quase de ponta com inferência rápida no nível de grandes plataformas de nuvem
    Ainda assim, vale a pena tentar para não depender tanto de serviços centralizados
  • Gemma 4 é especialmente bom para tarefas de pipeline/automação
    Pela minha experiência, ele supera os modelos Qwen, até mesmo os de 100B+, em seguir regras ou em tarefas no estilo automação. A interpretação de imagens também é muito boa e, em benchmarks, aparece acima do Opus
    O Qwen tende a ignorar instruções e, se você não limitar explicitamente o formato de geração de tokens, ele insiste em produzir formatos errados
    Porém, no DGX Spark, Gemma 31B Q4 + MTP fica em cerca de 20 tokens/s, e Gemma 26B A4B em cerca de 60 tokens/s, então ainda é bem lento. Em placas Nvidia topo de linha, deve rodar bem mais rápido e caber na memória
    Para quem está começando com modelos locais, eu recomendaria focar em largura de banda de memória mais do que em RAM. Hoje, modelos com menos de 100B já bastam para automação e são muito úteis
    Concordo que, para programação/criação, ainda não há um motivo forte para usar modelos locais. Mas para tarefas como vasculhar listas de ações e fazer filtragem passa-altas de notícias, ou interpretar logs e screenshots, os modelos locais já dão conta
  • Fico pensando se não seria melhor ter uma máquina em algum lugar rodando os modelos e algumas pessoas compartilharem
    Acho que daria para justificar um Mac Studio M6 com algo como 256GB de RAM para algumas pessoas acessarem um modelo em comum. Notebook parece quente demais e lerdo demais para esse uso

• Depois de usar o Qwen3.6-27B com satisfação por algumas semanas, agora estou longe do meu hardware e preciso usar o Claude Sonnet 4.6, e isso parece um downgrade enorme
  Não sei como isso é possível. Tem opiniões fortes demais sem que eu tenha pedido, fala demais e, no geral, parece mais burro
  Claro, é um modelo muito maior, então deve ter mais conhecimento codificado, mas isso não ajuda se for desagradável conversar com ele. Além disso, conversar com ele custa dinheiro de verdade
  Fico me perguntando por que desgosto tanto dele. Talvez seja porque ele se vê não como uma ferramenta, mas quase como um igual. Porque age como se as opiniões dele tivessem peso
  O Qwen também pode agir como um estagiário excessivamente entusiasmado, mas se você disser que ele está sendo idiota, ele deixa o ego de lado. O Claude, na minha experiência, não fazia isso
  Em resumo, concordo totalmente com o título

  • Nunca gastei um centavo com inferência em nuvem, então não posso fazer uma comparação direta, mas posso dizer com certeza que o Qwen3.6-27B é um modelo local muito competente para tarefas de programação
    Tenho usado quase todos os dias no último mês e meio em uma máquina com M2 Ultra ou RTX 5090. Estou usando para tarefas pequenas e comuns no ggml-org [0], nada extraordinário, mas é uma ferramenta que com certeza ajuda um mantenedor
    Acho que teria usado muito mais se não gastasse tanto tempo revisando PRs. No momento uso um harness bem leve, basicamente um agente pi sem nada (pi -nc --offline) e um prompt de sistema curto [1] para ajustar ao meu estilo
    A velocidade de geração é de cerca de 100~150 tokens/s na RTX 5090 e cerca de 40 tokens/s no Mac. Eu definitivamente prefiro rodar na máquina com RTX porque é muito mais rápido, mas também rodo bastante no Mac para testar configurações locais e ter uma experiência mais ampla
    [0] - https://github.com/search?q=%22Assisted-by%22+user%3Aggml-or...
    [1] - https://github.com/ggml-org/llama.cpp/blob/master/.pi/gg/SYS...
  • Uso o Qwen3.6-27B todos os dias, inclusive como principal no trabalho, e venho usando quase sem parar desde logo após o lançamento. Acho que é o único modelo local pequeno que realmente vale a pena, se você conseguir executá-lo
    Pode ser pior que o Opus para algo como “adicione a funcionalidade grande X”, mas eu não quero isso do modelo. Eu quero pensar e que o modelo digite para mim. O Qwen 3.6 27B é totalmente suficiente para isso. Na minha experiência, o 35A3B e a linha Gemma foram um downgrade considerável
    Além disso, não há preocupação com rate limits, cotas ou filas em horário de pico. Você sempre pode ver todo o processo de pensamento, não precisa se preocupar com para onde os dados estão sendo enviados, e ele não vai piorar sorrateiramente
    Rodo com llama.cpp em 2×3090 usando configuração Q6_K_XL + MTP, com prefill de 500~1000 tokens/s, saída de 60 tokens/s e janela de contexto de 220 mil tokens. Depois de 160 mil tokens ele começa a ficar um pouco mais burro, e eu não uso quantização de KV
  • Esse ponto de “fala demais” é realmente irritante. Eu só queria que calasse a boca e respondesse de forma concisa
    Isso pode ser um subproduto da capacidade de raciocínio, mas eu queria que resumisse o processo de pensamento de forma muito mais simples. Há situações em que uma resposta de uma frase basta, mas os modelos de ponta escrevem no mínimo 5 parágrafos e tentam sugerir de 3 a 5 novas direções
    Mesmo pedindo para ir um passo de cada vez, só uma opção por vez, sem sugerir ativamente direções futuras, ainda é muito difícil controlar isso direito por prompt
    Mas agora eu mesmo acabei de fazer exatamente aquilo de que estava reclamando
  • Não vou generalizar só com base na minha experiência com Sonnet. Os modelos flagship equivalentes ao Opus na linha Claude são muito melhores
  • É engraçado que agentes de programação também tenham personalidade. Até têm aquela personalidade de “aquele colega” que você quer evitar, mesmo sabendo que faz o trabalho razoavelmente bem

• Programadores estão acostumados a não pagar por ferramentas. Mesmo um notebook básico (SSD, vários núcleos, 16 GB de RAM) é absurdamente poderoso para desenvolvimento em C/C++/Rust e até Python
  Mas de repente isso deixa de bastar, e você volta a usar o computador de outra pessoa, alugando uma ferramenta todos os dias. Pior ainda, você acaba usando um modelo diferente a cada dia, e em alguns dias alguma força tipo máfia pode pressionar o fabricante e você talvez nem consiga alugar uma boa ferramenta
  A maioria das outras profissões precisa investir bastante em ferramentas. Se você quer ferramentas boas, precisa de algo como 64 GB de memória de GPU (por exemplo, 2×5090) e uns 96 GB de RAM. Se você paga US$ 200 mil a um engenheiro especializado, gastar US$ 50 mil em ferramentas a cada dois anos também parece bastante razoável

• É uma tendência com a qual empresas como a Anthropic deveriam se preocupar. Quanto mais fácil ficar rodar modelos localmente, menor tende a ser o teto de preço que elas conseguem cobrar
  Não é que vá desaparecer totalmente quem paga $$$$$ por mês, mas muita gente vai multiplicar a mensalidade por 12 ou 24 e pensar: “Será que dá para montar um modelo local por menos que isso e recuperar o investimento em 1 ou 2 anos?”
  Se uma parcela significativa dos clientes optar por comprar em vez de alugar, empresas com modelo de negócio centrado em locação podem de repente passar a sofrer com falta de clientes

  • Nos últimos 20 anos, aconteceu exatamente o oposto na computação em nuvem. Não acho que essa mudança vá acontecer com modelos de IA
    Isso já está quase gravado no modelo de negócios à americana: terceirizar tudo. Ninguém quer administrar sala de servidores por conta própria, e mesmo pagando 2 ou 3 vezes mais, prefere terceirizar junto a dor de cabeça e a responsabilidade
    Com IA vai ser a mesma coisa. Tanto faz pagar esse prêmio para a Anthropic ou para a AWS
    Trabalho numa empresa relativamente pequena e recentemente tivemos um incidente ligado à infraestrutura local. Mesmo com o total de downtime interno nos últimos 5 anos sendo muito menor do que uma única grande falha recente da AWS, o CEO agora vem pressionando com a ideia de que hospedar infraestrutura própria não é confiável
    Todo mundo quer se livrar do trabalho chato e da responsabilidade
  • Pensei que isso pode ser parecido com a diferença entre pagar Netflix e baixar por torrent para rodar no Plex
    O usuário comum e majoritário provavelmente vai pagar por algo que já venha configurado e pronto para usar. Os mais técnicos ou mais determinados vão fazer por conta própria, mas fico curioso sobre qual será a proporção entre esses dois grupos
  • Fico curioso para saber em que momento empresas com forte foco em programação vão começar a operar seus próprios clusters de IA on-premises
    Não sei se já existiu a ideia de vender algo como uma máquina com 4 GPUs que a equipe de engenharia possa colocar em algum armário e usar para rodar os modelos que quiser
    Não seria atraente para todo mundo, mas com a questão de confiança em torno dos hyperscalers sugando dados das pessoas para treinar modelos, certamente haverá lugares que verão valor em máquinas e modelos que possam controlar com transparência e, se necessário, ir lá pessoalmente e arrancar da tomada
  • Esses modelos locais conseguem fazer parte do que modelos que não são de ponta fazem, mas para mim isso não tem tanto valor
    Só com Sonnet 4.6 já dá para trabalhar praticamente o dia todo por 20 dólares por mês. E o Sonnet ainda é muito mais poderoso do que qualquer modelo que eu consiga auto-hospedar num Mac M2
    Talvez eu mude de ideia se todo mundo migrar para cobrança por uso de tokens, mas no modelo de assinatura isso não fecha financeiramente
    É divertido. Mas não faz sentido econômico
  • Eles estão se mexendo com força para impedir que qualquer coisa rode localmente
    A OpenAI comprando toda a RAM disponível no mercado spot fez o preço de RAM/VRAM subir 6 vezes, e GPUs e computadores decentes ficaram fora do alcance da maioria
    Alguns poucos com muito dinheiro talvez consigam comprar um Mac Studio de 512GB ou uma RTX Pro 6000 por 13 mil dólares para rodar um modelo local bem razoável, mas a maioria vai ter de usar API
    Em algum momento a Nvidia pode dizer: “Não estamos vendendo tantas 6000 assim, e podemos lucrar 4 vezes mais com GPUs só para datacenter, então vamos cancelar.” Aí vira algo impossível de conseguir, e pode se tornar inviável para pessoas comuns rodarem localmente modelos razoáveis que estejam cerca de 1 ano atrás do estado da arte

• Eu gostaria de ver o código produzido com isso. Quero usar modelos locais e tenho o hardware, mas quando tento usar como substitutos dos modelos de ponta como GPT 5.5 xhigh ou Opus, ainda não estão prontos para substituir
  Por causa da qualidade e dos obstáculos, o fluxo de trabalho fica lento demais, e às vezes até estragam a sintaxe de chamada de ferramentas
  Ainda assim, para fluxos menores e mais bem definidos ou para edições do tipo “mude exatamente esta parte desta forma”, parece suficiente. Estou esperando amadurecer a ponto de substituir o estado da arte atual, e vejo esse momento como o ponto de virada
  Já que estamos falando de modelos locais, DiffusionGemma — e modelos de difusão em geral — não deveriam ser subestimados para uso local. Em geral, o problema do local é que LLMs não usam o hardware com eficiência a menos que agrupem várias requisições em batch e executem várias ao mesmo tempo, o que exige uma abordagem diferente. Já modelos de difusão são muito mais rápidos em um único prompt, e a diferença não é pequena
  Hoje mesmo portei o suporte a diffusiongemma-26B-A4B-it do Transformers para o Candle e ainda acrescentei algumas otimizações; durante a inferência, no Candle ele está voando a cerca de 450 tokens/s (aprox. 19 iterações/s). Na biblioteca HF Transformers, ficava em cerca de 180 tokens/s (aprox. 11 iterações/s). Mesmo rodando um LLM de tamanho parecido no vLLM, acho que nunca passei de 250 tokens/s em prompt único, então isso é interessante para modelo local

  • Modelos de difusão são difíceis de treinar direito a partir de tamanhos médio-altos, e a qualidade é inferior à de um modelo típico que gera um token por vez do mesmo tamanho

• Com 2.600 dólares dá para comprar duas GPUs AMD 9700 com 32GB de RAM por placa e consumo de cerca de 285W. Tanto o custo quanto o consumo são menores que os da 5090
  Usando uma build do VLLM com patch do AITER, dá para rodar Qwen3.6 27B FP8 em cerca de 45~50 TPS com janela de contexto completa em sessões reais de programação no Opencode ou no PI
  Eu realmente espero que continuem saindo mais modelos densos na faixa dos 30B, mas mesmo só com o Qwen3.6 já dá para tocar bastante trabalho de agente
  Só que a stack do ROCm não é para quem não está disposto a fuçar e aplicar patches por conta própria

• Fico me perguntando por que o critério de cada pessoa para um agent coding “bom” varia tanto.
  Por um lado, é realmente impressionante termos chegado de um nível de inteligência tipo “tocar ‘Set a Timer’ no Apple Music” até um nível que talvez consiga passar no teste de Turing, mas, na prática, ainda está longe de chamar modelos pequenos de “bons” para algo além de demos técnicas.
  Para mim, um modelo 7B é só um eco borrado da Wikipedia. Um modelo Gemma em 4 bits é ruim demais até para gerar com estabilidade um JSON de chamada de ferramenta ou copiar uma única linha de código para aplicar um patch.
  O Qwen exige tantos detalhes e tanto cuidado para não entrar em loop de destruição ou perder o contexto que muitas vezes as instruções que eu preciso dar acabam ficando maiores do que o código final que ele produz.
  Será que existe algum prompt mágico que eu não conheço? Ou será que as outras pessoas são muito mais pacientes ou têm expectativas muito mais baixas?

  • Eu tinha uma dúvida parecida. Acho que a razão para as expectativas diferentes é que a carga de trabalho é diferente.
    Em scripts pequenos, glue code e mudanças simples de CRUD, modelos menores como o Qwen3.6-27B podem funcionar muito melhor do que em codebases maiores e mais bagunçadas.
  • Existe um pouco de critério baixo, e ele fica ainda mais baixo com o tempo, mas, pela minha experiência, a configuração descrita ainda está baixa demais.
    Rodando Qwen/Gemma na faixa de 27/35B em FP8, fica melhor que o gemini-2.5, mas pior que o gemini-3.1. O DS4-flash FP8 pode rodar em dois DGX Spark, e a situação continua melhorando. O DiffusionGemma recentemente ficou 4x mais rápido na geração de tokens.
    Resumindo, parece que os modelos que você testou são pequenos demais ou estão quantizados em excesso.

• Gosto de rodar dois modelos localmente. São o qwen3.6 27B 8 bits (denso) e o qwen3.6 35B 4 bits (mistura de especialistas).
  O 27B é mais inteligente e confiável, mas mais lento. O 35B é mais rápido e continua muito inteligente, mas fica abaixo do 27B e é um pouco menos estável. A razão é a arquitetura de mistura de especialistas (MoE), que ativa só parte dos parâmetros e por isso deixa o modelo muito mais rápido.
  Rodo o 27B em um MacBook Pro M5 Max + 40 núcleos de GPU + 128 GB de RAM. Nessa máquina absurda dá para manter o 27B e o 35B carregados na memória ao mesmo tempo e ainda sobrar espaço para outras tarefas. Mas, por ser um notebook, é impossível deixar LLM local rodando o tempo todo. Fica quente e barulhento demais.
  Mais interessante é rodar o modelo 35B em um MacMini M4 com 64 GB de RAM. É rápido e dá conta de muita coisa. Por exemplo, escaneia, extrai e classifica emails, e continua monitorando a caixa de entrada e trabalhando. Também uso como assistente pessoal Hermes para perguntar coisas como “Quando é o próximo lançamento da Starship?” e “Quem joga hoje na Copa do Mundo? Me fala umas curiosidades também”.
  O próximo plano é uma workstation RTX Pro 6000 Blackwell para deixar no porão. Quero rodar Qwen muito rápido, com vários threads/prompts/agentes ao mesmo tempo. Se o orçamento permitir, quero uma configuração com 2× RTX Pro 6000 para rodar DeepSeek v4 flash e usar em pesquisa.

  • Você conseguiu algo como uma chave de API de busca do Brave para esse “Hermes”?
  • Eu realmente queria uma RTX 6000 Pro, mas como justificar isso se custa o equivalente a 10 anos de Claude Max?

• No dia a dia, hospedo o Qwen3.6:27b, mas queria muito hospedar o deepseekv4 flash. É um modelo “bom” demais pelo tamanho/velocidade/preço.
  Fico curioso para saber quando as empresas vão parar de pagar assinatura para todo desenvolvedor e começar a hospedar modelos on-premises para trabalho do dia a dia. Já são bons o suficiente e relativamente baratos.

• Você não perguntou, mas nenhum de nós acha que se deva usar os modelos topo de linha mais recentes para escrever código ou para quase qualquer coisa.
  Em vez disso, deveríamos desenvolver modelos abertos para tarefas específicas e aprender a programar, escrever e desenhar com dedos de osso e cérebro de carne.
  Grandes empresas e centros de pesquisa até podem usar isso para gerar código, matemática etc., com especialistas verificando se o resultado está correto, mas mesmo assim pode não valer o custo. Por exemplo, a OpenAI teve prejuízo líquido de 36 bilhões de dólares no ano passado, os modelos abertos já chegaram bem perto, e o plano inteiro da IA está ficando sem os otários de quem arrancar dinheiro.
  Há muita coisa que dá para fazer até com modelos muito pequenos, e muitas tarefas não exigem um nível absurdo de computação e memória, mas gente demais pesquisa pouco esse lado.