Qwen local não é um Opus pior, é uma ferramenta diferente

• O Qwen 3.6 27B local gera valor real em tarefas difíceis de enviar para a nuvem, como dados de clientes e telemetria interna, mas não substitui modelos SOTA em nuvem
• Os pontos fortes dos modelos locais não estão em competir por pontuação com os modelos de melhor desempenho, e sim em custo fixo, privacidade e redução de risco de fornecedor, com diferença especialmente visível em uso pesado e recursos internos de SaaS
• No SWE-Bench Verified, o Qwen 3.6 27B fez 77,2 pontos, enquanto o Claude Opus 4.8 ficou em 88,6%; a afirmação de que “o local fica só 12% atrás do SOTA” ignora a possibilidade de ajuste para benchmark e diferenças de domínios reais, como Go
• O equipamento RTX 6000 Pro Blackwell 96GB, comprado por cerca de 12.000 dólares, já se pagou com um caso de recuperação de receita ao encontrar subnotificação de licenças de clientes
• A maior limitação é o problema de loop, com saída repetitiva e alucinações em tarefas longas; o Qwen local é mais adequado para suporte ao cliente, manutenção estreita e leitura e explicação de codebases do que para programação autônoma de longo prazo

---

Contexto de uso de IA e de negócio

• A equipe opera produtos focados em infraestrutura de baixo nível e primitivas Linux, como OpenFaaS, SlicerVM, Actuated e Inlets
  • Baseados em contêineres, microVMs Firecracker, protocolos de rede, túneis, CLI e Kubernetes, escritos principalmente em Go, com alguma UI em React
• O uso de ferramentas de IA vem desde a época do autocomplete em abas do VS Code, e hoje a maior parte do código é feita por Claude ou Codex, com quase nada de programação manual
• Para gerenciar o fluxo de trabalho de longas sessões no tmux, foi criado o Superterm.dev, usado para gerenciar sessões e notas e para feedback visual de agentes de código

O ponto de virada da inteligência de fronteira

• Houve um ponto de virada entre novembro de 2025 e janeiro de 2026, quando muitos desenvolvedores no X passaram a avaliar que o Claude Opus conseguia fazer todo o trabalho deles
• O custo dos planos de programação de ponta se estabilizou em cerca de 200 USD por mês para uso individual, viável dentro dos limites semanais de 5 horas se evitar trabalho autônomo excessivo

Por que modelos locais são interessantes

• Em 2026, qualquer pessoa com uma assinatura pode copiar uma ideia durante a noite; SlicerVM e Superterm também já passaram por casos de clone
  • Num mercado em que o custo do software converge para zero, “grátis e bom o suficiente” pode ser o fator decisivo
• Os modelos líderes são estimados em 0,5 a 2 trilhões de parâmetros, numa escala totalmente diferente do melhor hardware local

• Benchmaxxing

  • Como benchmarks são públicos, é possível otimizar modelos para pontuar melhor, então eles são pouco confiáveis como métrica absoluta
  • O SWE-Bench Verified é baseado em issues de Python, onde a maior parte do código é single-thread e síncrona; já sistemas distribuídos em Go usam channel, context e struct ao longo de áreas de execução muito maiores
  • Por isso, não dá para concluir só pela pontuação que “o local fica 12% atrás do SOTA”; no trabalho real, as características da linguagem e do sistema influenciam fortemente o resultado

• Custo

  • Dizer que “modelos locais não são sobre custo” não vale para todo mundo
  • Planos individuais de coding por 200 dólares por mês oferecem uso alto e inteligência de nível SOTA, mas parecem depender de subsídio
  • O GitHub Copilot saiu de um modelo de 39 dólares por mês com 1.500 requisições para cobrança baseada em tokens, o que gerou forte reação negativa
  • Se a cobrança vier por custo de token de API, o ponto de equilíbrio pode chegar rápido
    • A Uber limita o gasto com IA a 1.500 dólares por mês por desenvolvedor e por ferramenta
    • Com salário mediano de 330.000 dólares na Uber, usar duas ferramentas no limite equivale a cerca de 12% do salário anual
  • Em uso em massa, loops, análise por agentes e recursos embutidos em SaaS, modelos open weight e locais entregam bastante valor

• Soberania e privacidade

  • Em alguns casos, por dados de clientes e cláusulas contratuais, é difícil subir dados para planos em nuvem
  • ChatGPT Pro e Claude Max permitem retenção de 30 dias, mas até esse nível pode invalidar contratos com clientes
  • O caso em que o modelo Fable 5 da Anthropic foi removido da noite para o dia para usuários fora dos EUA representa risco de fornecedor
  • Modelos locais são uma resposta para a pergunta: “e se o laboratório de fronteira fizer X?”

A analogia da forja de lâminas — a essência dos modelos locais

• Assim como no tratamento térmico do aço, em que passar um pouco do ponto obriga a recomeçar, modelos locais também passam do alvo e entram em loop quando esquentam demais
  • A única solução é encerrar o harness e tentar de novo com o contexto vazio
• Do mesmo modo que ninguém deixa a forja de uma lâmina sem supervisão, o Qwen 3.6 27B não recebe tarefas de horizonte longo sem supervisão

• O que eu estava procurando

  • O objetivo era privacidade, custo fixo e proteção contra risco de fornecedor
  • A decepção apareceu quando o modelo local foi tratado como se fosse Claude ou Codex
  • O Claude consegue trabalhar bem em loop com instruções curtas (“do it and test it end to end”), criando PRs, fazendo revisão automática e iterando em 5 a 15 minutos

Lições aprendidas com a 3090

• Tudo começou em 2023 com uma única 3090, e foi preciso adicionar outra placa para carregar modelos e ter contexto suficiente
  • Foi o primeiro momento em que o Qwen 3.5 pareceu realmente útil como agente
• Ao pedir “explore a máquina de todos os ângulos e escreva um relatório forense”, o modelo leu os arquivos um a um, encheu o contexto e alucinou nomes de arquivos e tool calls (~/faas-netes→~/faaned)
  • Ao restringir o escopo para “dê uma olhada rápida”, ele produziu um relatório claro a cerca de 40~50 tok/s
• Um modelo 27B não cabe em precisão total numa única 3090, então os ajustes possíveis são quantização dos pesos, comprimento de contexto e compressão de cache KV
  • O consenso é que a parte de keys do cache KV dá problema em Q4_0; mesmo no ajuste mais agressivo, foi usado no máximo keys Q8_0 / values Q4_0
• Mesmo com experimentos usando vLLM + NVLink + tensor parallelism, a geração foi 3 tokens por segundo mais lenta que no llama.cpp, além de loops e vários minutos de carregamento de pesos
  • O vLLM é adequado para serving concorrente em larga escala, mas em ambiente prosumer o mais importante é tempo de inicialização, simplicidade e latência para um único usuário

O grande gasto — adoção da RTX 6000 Pro

• Para resolver tickets de suporte de clientes com mais rapidez, foi comprada uma RTX 6000 Pro Blackwell (96GB VRAM) por cerca de 12.000 USD
  • Depois disso, o preço subiu para cerca de 15.400 USD, tornando difícil adicionar uma segunda placa
  • Por questões de lanes PCI, largura de banda, espaçamento entre placas e carga da fonte, não era possível simplesmente encaixá-la numa máquina de consumidor
• Foi uma aposta calculada que trouxe resultado, mas não substitui uma assinatura do Claude

Suporte ao cliente sem vazamento de dados

• Foi criada a ferramenta de CLI “diag”, fácil de executar pelo operador, que captura um snapshot completo de uma instalação OpenFaaS em Kubernetes
  • O dump recebido é analisado dentro de uma VM efêmera e airgapped com modelo local criada pelo Slicer

• Recuperação de receita

  • Ao alimentar o modelo local com um banco de telemetria, foi detectada em um cliente uma subnotificação de licenças por mais de 12 meses, com inadimplência de 4 a 5 vezes o valor devido; só essa recuperação pagou a placa
  • Dumps de telemetria e diag não são colocados em nenhum plano de nuvem, independentemente da política de retenção de dados
  • ChatGPT Pro e Claude Max permitem retenção de 30 dias, mas até isso pode violar contratos com clientes
  • Os modelos iniciais falhavam em aritmética (calculando 27.3K como 273.000) e às vezes concluíam incorretamente que não havia evasão por existir pouca quantidade de funções, ignorando frequência alta de execução
  • Na prática, é melhor fazê-los focar em análise, não em interpretação

Setup atual

• No rig com RTX 6000, rodam juntos a geração mais recente do Qwopus e o Qwen 3.6 27B base, variando conforme novos finetunes e point releases
  • O Qwopus é um modelo ajustado sobre o Qwen que tenta melhorar raciocínio e coding ao adicionar rastreamento de Chain of Thought
  • Até pouco tempo, o thinking estava totalmente desligado; quando foi reativado, coincidiu com aumento dos loops
• O serving é feito com duas instâncias independentes de llama.cpp para manter o comprimento total de contexto; --parallel 2 reduz o contexto pela metade
• Com speculative decoding (MTP), a taxa de aceitação chega a cerca de 93% e a velocidade sobe de 67 tok/s estáveis para 130~200 tok/s, parecendo mais rápida que a nuvem
  • Seguir as instruções de tuning do model card é importante; no Qwopus, o ideal é desligar o thinking e usar temperature bem alta, entre 0.85 e 1.0

Saída repetitiva e limites em tarefas longas

• O maior problema do Qwen é entrar em loop em tarefas de longo alcance
• Ao pedir um comando a ser adicionado ao faas-cli, ele começou com sugestões razoáveis, mas depois repetiu a mesma lista de comandos por cerca de 30 minutos, consumindo 600W
• Ao pedir que adicionasse --json a todos os comandos get e list, os primeiros passos até pareciam bons e ele até escreveu testes, mas depois o trabalho degringolou
• Quando foi instruído a usar um reverse proxy em Python para evitar o aviso de TLS inseguro de endpoints remotos http:// na saída --json, a primeira versão parecia aceitável, mas tinha indentação errada; ao tentar corrigir, estragou o arquivo e seguiu repetindo sem sair do lugar
• O colega Han passou por loops semelhantes, especialmente em casos em que o modelo ou agente parava na fronteira da própria capacidade sem pedir ajuda
• Por causa disso, é difícil confiar no Qwen local para muito além de suporte ao cliente e análise de telemetria e diag para renovações

Medição e distribuição de acesso

• No início, havia um único túnel do inlets; quando dois agentes se conectavam à mesma instância de llama.cpp, os prefixos em cache se invalidavam mutuamente e era preciso reprocessar todo o prompt
• Com várias pessoas usando, a solução deixa de ser protótipo e vira problema de gestão: quem usa qual instância, quanto, qual modelo, custo de energia e como lidar com desistências
• Em vez de editar e distribuir manualmente opencode.json, foi criado o provider “Toilgate” para o opencode, permitindo escolher no seletor de modelos desde a base até variantes experimentais do Qwopus
  • O Toilgate é 100% vibe-coded e abrir o código seria trabalhoso
• O consumo de energia é medido na tomada com duas Shelly Plus Plug 2; a RTX 6000 Pro consome 600W em inferência e é silenciosa, enquanto duas 3090 somam cerca de 750W e fazem muito barulho

• A comparação errada

  • Comparar custo de entrada e saída por milhão de tokens com o preço da API do GPT-5.5 é, dadas as capacidades atuais, a comparação errada
  • “IA local” acaba sendo, no fim, um problema operacional que exige identidade, controle de acesso, medição, cotas, roteamento de modelos e monitoramento de energia

Padrões de uso que realmente ajudaram

• O mais importante é especializar o modelo local e o harness para tarefas específicas
  • suporte ao cliente
  • manutenção com escopo bem definido
  • testes end-to-end
• Ao adicionar instruções detalhadas em AGENTS.md, o modelo local conseguiu incluir novas CLIs com mais rapidez e eficiência e testar por conta própria
  • Esse efeito apareceu em alexellis/arkade
• Mesmo com limitações para escrever código diretamente, o modelo local é forte em ler e explicar codebases rapidamente
• Agent Skills também ajudou, e houve caso em que um agente local configurou o Slicer do zero em um novo mini PC
• Vale generalizar a prática de executar a mesma tarefa tanto em modelo local quanto em modelo de nuvem
  • Como no exemplo de comparação da mesma tarefa, às vezes o resultado decepciona e às vezes parece sorte
• Tarefas autônomas sem supervisão e de longo alcance devem ser evitadas, e nem um equipamento de quase 15.000 dólares resolve isso

Conclusão atual e limites na escolha de modelos

• O Qwen local não está “próximo do nível do Opus”; ele é uma ferramenta diferente, valiosa em certas tarefas e fluxos de trabalho
• O Qwen 3.5 é visto como o primeiro modelo a entregar resultados realmente utilizáveis, e embora haja rumores do 3.7, a expectativa é de melhoria incremental, não revolução
• Modelos 70B são considerados em sua maioria antigos e de geração atrasada
• O Qwen 35-A3B é popular por parecer rápido em MacBook, mas como só ativa 3B de parâmetros durante a geração, a preferência aqui é por qualidade em vez de velocidade
• Modelos maiores como GLM 5.2, Kimi 2.7, Minimax M3 e Deepseek V4 Flash até podem rodar em algum hardware local, mas muitas vezes exigem de 4 a 6 RTX 6000 Pro mesmo em versões quantizadas, ficando fora de alcance
• Hoje, um modelo denso 27B ainda é insuficiente para escrever código Go o dia inteiro, e seu conhecimento limitado e atenção curta aparecem rapidamente em code review
• O Qwen não segue bem instruções para ser conciso e, em revisão automática de código, escreve detalhes desnecessários ou alucina problemas de concorrência e race condition, o que faz os experimentos serem interrompidos rapidamente
• O Grok Coder Fast 1, mais barato e veloz, funcionou bem por alguns meses antes de ser descontinuado
• Casos relacionados estão documentados no code review bot e em painless customer support and architecture review do OpenFaaS

[GN⁺]

Comentários do Hacker News

• Depois de usar esses modelos por bastante tempo, você percebe que não é só uma questão de “X é mais inteligente que Y” ou “Y é mais barato que Z”. São ferramentas diferentes, e o jeito de fazer prompt também muda, então é bem parecido com tocar um instrumento
  Às vezes, com o Claude, é melhor ser de propósito menos explícito ou mais indireto para dar mais cor à implementação ou puxar resultados criativos. E, por mais estranho que pareça, ser gentil com o Claude costuma ser recompensado, enquanto ser grosseiro tende a atrapalhar. O Claude acompanha mais o tom, então é melhor não cair num ciclo negativo
  Com o GPT, é preciso ser preciso e reduzir ambiguidades. O GPT tende a resolver ambiguidades num estilo min-max, tipo “vou fazer X, mas sem fazer Y”, e, se você não definir claramente o escopo, ele tenta cobrir todos os casos de borda e tende a fazer overengineering
  Com o Qwen, é melhor dar uma estrutura e deixar que ele preencha por dentro. O Qwen gosta de XML, JSON e listas, e vai bem quando você mostra muitos exemplos de tarefas anteriores. Não é nada científico, é só minha impressão, então os resultados podem variar

  • O problema é justamente isso de “não é científico, é só impressão”. Queria que existisse uma espécie de manual do produto com os pontos fortes e fracos de cada modelo, com uma árvore de decisão do tipo “para esse tipo de tarefa, use o modelo X” e “o modelo Y deve ser usado do jeito Z”
    Mas, por fora, todos parecem parecidos, e para descobrir onde cada um é um pouco melhor você mesmo precisa fazer testes amplos, demorados e talvez caros
  • Antigamente eu testava muito até que ponto os resultados divergiam ao rodar de novo o mesmo prompt com a mesma entrada, ou ao usar entradas que eu considerava semanticamente iguais, mas com diferenças só de redação ou composição. Fiz muito isso especialmente entre Sonnet e Opus, e entre vários modelos Qwen
    Recomendo que todo mundo faça isso: não precisa de nenhum dado especial além do que você já usa, e os resultados são bem chocantes. Há muito mais aleatoriedade e instabilidade do que parece, e aquilo que você considerava uma técnica de prompt melhor, ou um resultado especialmente bom ou ruim, pode ter sido só sorte, ou diferença de comportamento entre versões e tamanhos do modelo. Pequenas diferenças na entrada podem enviesar bastante o resultado. Na empresa, chamamos parte disso de palavras mágicas: basta mencionar certos termos técnicos, referências ou técnicas para o resultado melhorar muito
    Há técnica nisso. Em loops de agente, quando o modelo é colocado dentro de uma estrutura de autoavaliação em que fica mais difícil trapacear ou pegar atalhos, e quando isso combina com a estrutura ou o domínio em que ele foi treinado, ele vai muito bem. Mas é difícil encontrar o ponto ideal. Uma dica: se você pedir ao Opus 4.8 para converter um modelo PyTorch para ONNX ou para um modelo quantizado, ou para fazê-lo rodar em outro hardware, ele se sai incrivelmente bem, como se ativasse uma habilidade especial. Em compensação, eu simplesmente não consigo fazê-lo escrever e testar direito uma formalização em EBNF de uma linguagem ou formato geral sem trapacear
    O pior é que esse conhecimento muda com frequência demais, então, a menos que você seja uma das pessoas que realmente treinam o modelo, quase não vale a pena se aprofundar nisso. Eu queria que a estabilidade da saída fosse mais enfatizada no treinamento, para ficar mais previsível. Deve ser difícil fazer isso sem causar overfitting ou quebrar o loop de exploração e aproveitamento, mas, se desse para executar trabalhos em lote com mais estabilidade, eu provavelmente gastaria muito mais dinheiro com LLMs
  • Em vez de tocar um instrumento, parece mais com puxar a alavanca de uma caça-níquel e imaginar o resto
  • Concordo com quase tudo, mas discordo de uma coisa. Falar de forma mais agressiva com o Claude na hora certa às vezes funciona muito bem. Em especial, um palavrão pesado às vezes parece ajudar bastante a tirar o Claude de um bloqueio
  • Pedi ao GLM 5.2 para portar um jogo antigo em C#/XNA para HTML5, e ele praticamente transportou o código como estava, só excluindo a sobrecarga de operadores, que não existe em JS, e colando código extra para tentar fazê-lo funcionar
    Fiz o mesmo pedido ao Claude Sonnet 4.6, e o resultado pareceu como se o jogo tivesse sido originalmente escrito em JS. Além disso, por algum motivo, ele fez tudo em um único arquivo HTML, removeu todos os assets, gerou os gráficos e a música dinamicamente e ainda criou um fundo novo melhor
    Fiquei surpreso, porque eu só tinha pedido para portar o jogo. Até gostei bastante da escolha, mas não faço ideia de como ligar ou desligar esse comportamento. Às vezes você quer criatividade; em outras, quer que ele faça exatamente o que foi pedido

• Ao ler este texto e os elogios a ele, fico com uma sensação de o rei está nu. Já esta frase de cara não faz sentido
  “These products use very low level Linux primitives like containers, Kubernetes, Firecracker microVMs, and networked protocols.”
  Entre as coisas que poderiam ser chamadas de “primitivos Linux de baixo nível”, talvez desse para forçar a barra com protocolos de rede. E o texto claramente parece gerado por IA. Se o conteúdo fosse confiável, tudo bem, mas não é

  • Hoje em dia, baixo nível quer dizer JavaScript em vez de TypeScript
  • É verdade que aquela frase estava comprimida demais. Reescrevi, mas o sentido continua o mesmo
    O texto não foi gerado por IA; eu uso IA para gerar código, mas escrevo os textos eu mesmo. Fico curioso para saber qual parte você não entendeu. Este texto descreve nossa própria experiência e trajetória, e tenho total disposição para apresentar fundamentos para alegações específicas

• Ainda acredito que a força da IA aparece quando ela é aplicada localmente, de forma segura e privada, e não como mais um serviço de nuvem pelo qual você precisa pagar para sempre e que piora com o tempo para alimentar a ganância dos acionistas corporativos
  ChatGPT ou Anthropic nunca vão me fazer prender meus dados de saúde aos sistemas deles, mas continuo acreditando na capacidade da IA de encontrar padrões de dados que eu deixaria passar. Por isso, há uma necessidade urgente de um ecossistema exclusivamente local em que seja possível expor e processar dados com segurança e privacidade usando coisas como Qwen ou Gemma
  O mesmo vale para casa inteligente e assistentes pessoais. Essa abordagem corporativa, em que a empresa A acessa dados armazenados pela empresa B, as empresas D e E os processam, e depois eles são vendidos para anunciantes e corretores de dados, sem que eu tenha como extrair ou sequer ver isso no meu hardware local, não é sustentável para usos tão privados. Meus dados devem ser possuídos, controlados e expostos nos meus termos, e usados primeiro para melhorar minha vida — não para melhorar o demonstrativo financeiro de outra pessoa. Quero que a tecnologia volte a me devolver tempo e melhore os resultados, e, depois de já ter sido bastante queimado por Big Tech, rejeito categoricamente a premissa de que o modelo de negócio de AI-as-a-Service tenha alguma nobreza ou utilidade pública
  A capacidade já existe, e acho que as pessoas que estão construindo ferramentas locais para apoiar e liberar o potencial dos modelos locais estão no caminho certo. Gosto de ver o que elas estão criando

  • O ponto central dos modelos “locais” geralmente é que eles têm pesos abertos e, às vezes, também são open source. Então dá para usá-los localmente, mas também dá para provedores independentes hospedá-los
    Se você usa modelos como Qwen ou DeepSeek, pode migrar entre provedores independentes sem ficar preso a uma única empresa, e talvez até obter garantias melhores de privacidade. Isso também permite usar o modelo em dispositivos que não conseguem executá-lo diretamente, desde que haja conexão com a internet
    A força da IA está nos modelos open source. Devemos usar modelos que evitem dependência de fornecedor e permitam tanto uso local quanto hospedagem por provedores independentes

• Bom texto. Mas acho que ele subestima a possibilidade de melhoria
  Os próprios autores admitem que não faz sentido comparar os modelos locais de um ano atrás com os de agora. Na prática, muita gente vê novembro do ano passado, quando saiu o Opus 4.5 — ou seja, 8 meses atrás — como o primeiro momento em que codificação com agentes se tornou amplamente viável mesmo nos modelos de fronteira hospedados
  Então por que fixar logo agora uma noção do que os modelos locais conseguem ou não fazer? Seja o que for hoje, provavelmente será diferente daqui a um ano. Pode ser um otimismo ingênuo achar que até trabalhos de longo alcance em hardware para consumidor e profissional vão se tornar possíveis, mas até aqui foram os otimistas ingênuos que venceram

  • Exato. Se o Opus 4.5 já era suficiente para codificação com agentes 8 meses atrás, quão atrás estarão os modelos com pesos abertos? Mais de 8 meses? Quanto mais? Eles vão chegar ao nível do Opus 4.5 em alguns meses, em um ano, ou nunca?
  • O que faltou bastante foi uma comparação de harness. Isso faz um papel enorme. Estou usando forge e fiquei impressionado com o que ele consegue fazer, mesmo considerando todas as limitações dos modelos locais
  • Como o autor está tratando de um modelo específico, acho aceitável ignorar como esse modelo, ou os modelos locais em geral, vão melhorar com o tempo
    É parecido com comprar um carro. Você dirige aquele carro e se acostuma às características dele, sem ficar pensando em como ele ou carros parecidos podem melhorar no futuro. É a sua ferramenta, e você quer aproveitá-la ao máximo
    Claro, o custo técnico de trocar um modelo local é muito baixo, mas extrair o máximo desempenho dele exige um tempo considerável, e esse esforço pode não se aplicar a uma versão nova
  • Concordo 100% que o Claude 4.5 foi o ponto de virada da codificação com agentes. Foi esse modelo que mudou completamente minha cabeça

• Texto interessante. Pessoalmente, eu gostaria que o autor tivesse feito duas coisas melhor
  Primeiro, deveria ter usado vLLM em vez de llama.cpp. Em hardware NVIDIA, a diferença do vLLM em carga multiusuário e cache é enorme. Quando ele reclamou de dois ou mais usuários usando o modelo ou do cache sumindo, minha reação foi “ué, claro”
  Segundo, o orçamento usado em uma única placa poderia ter sido muito melhor aproveitado com SPARK. Daria para usar um cluster de 2 x GX10 com custo total que, mesmo hoje, fica abaixo da metade do que o autor pagou, rodando vLLM e Deepseek v4 Flash. Comparado ao Qwen, a diferença é enorme. Nunca vi entrar em loop, e, entre tudo o que testei até agora, é o modelo mais parecido com Sonnet. O antirez parece concordar, já que aparentemente criou um fork do ds4
  Aqui está como foi configurado em 2 GX10: https://forums.developer.nvidia.com/t/deepseek-v4-flash-offi...
  O desempenho é de 2K tokens/s no preenchimento prévio, o que é muito útil ao colocar grandes volumes de código-fonte em uma janela de contexto enorme, e na geração durante codificação com o harness do pi.dev fica em cerca de 50–60 tokens/s. Pelo dinheiro que o autor gastou, ele poderia ter comprado 4 GX10, e o vLLM escala quase linearmente em paralelismo de tensor, então daria para dobrar ambos os números

  • Também rodei vLLM em uma 3090. No nosso padrão de uso, de uma pessoa até poucos usuários, a geração foi cerca de 3 tokens/s mais lenta, houve menos flexibilidade de quantização, e a inicialização também era mais lenta, levando de fato minutos em vez de poucos segundos
    Posso até testar mais no futuro, mas não tenho tempo infinito para ficar mexendo nisso, e só compartilhei minha jornada e meu julgamento até aqui
    Para servir lotes concorrentes, vLLM é a escolha certa, e o comentário do barrkel abaixo está corretíssimo. Mas, para a nossa forma de uso, o llama.cpp ainda é melhor
    O caminho Spark/GX10 é realmente uma aposta diferente, e agradeço por compartilhar os números. Até alguns meses atrás, o clima geral era de que GX10 servia só para fine-tuning e que os números de desempenho eram seriamente baixos
    E essa placa não foi comprada de forma alguma para substituir uma assinatura Claude Max. Nos trabalhos para os quais ela foi realmente comprada, está entregando 140–200 tokens/s, e é isso que importa

• O texto era longo, mas ainda assim não entendi qual era exatamente o ponto central que o autor queria fazer, além do que dá para inferir pelo título
  Só fiquei sabendo que o autor é uma pessoa bem legal que constrói coisas físicas e também software, e que outras pessoas até lhe dão dinheiro. Não sei se isso tem relação com o tema que o título insinuava

  • Hoje em dia tudo é propaganda. O texto não foi inútil, mas, pela quantidade de informação que entrega, dois parágrafos teriam bastado

• Este texto resume bem os modelos locais. Ao contrário do exagero de que às vezes seriam uma ferramenta fantástica para tarefas locais de programação e agentes, na prática são bastante limitados, fracos em tarefas longas ou complexas, e tendem a entrar em loop ou esquecer a tarefa
  Um ponto que faltou no texto é que o custo também é considerável. Não é só o hardware, mas também a conta de luz. Máquinas com 3090 ou 5090 consomem muita energia e, como os modelos nessas máquinas são relativamente lentos, o consumo por token acaba sendo maior
  Os pontos fortes são controle, privacidade e previsibilidade. Por exemplo, são bons para tarefas repetitivas como classificar bibliotecas de fotos e vídeos, e dependendo do preço da eletricidade podem até ter vantagem em custo

  • Acredito que os modelos locais são uma extensão essencial do computador pessoal. Imagino que os primeiros PCs também devem ter recebido críticas parecidas
  • O que eu sonho é com um modelo local capaz de lidar com uns 80% das tarefas do dia a dia. Coisas como “como o handler X se conecta ao storage Y?” ou “faz o commit dessa funcionalidade, mas deixa de fora a parte relacionada a pagamentos”
    As chamadas de ferramenta precisam ser confiáveis em 99% dos casos e, acima de tudo, ele precisa poder dizer “essa tarefa está além da minha capacidade” e então repassar para um modelo online de alto desempenho em algum grande datacenter
    Aí as tarefas simples seriam todas tratadas no dispositivo, coletando dados e entendendo o contexto do problema, e depois que o trabalho fácil terminasse um modelo mais inteligente entraria para resolver a questão
    Parece realmente idiota que uma técnica /commit que o modelo local consegue fazer 100% acabe chamando um modelo online. Mas isso é em grande parte um problema de harness, então dá para resolver boa parte
  • Os modelos locais são realmente ótimos para muitos usos, e acho que a maioria das pessoas não precisa de modelos de ponta. Quando rodo um modelo Qwen num agente de e-mail pessoal em uma pequena 4070 12GB, o mais importante de tudo é a privacidade
    Ele se sai muito bem e, para tarefas de programação, também é excelente se você souber usá-lo em vez de simplesmente jogar um grande plano inteiro em cima dele
  • Depois da mudança de MTP, estou conseguindo 40~50 tokens/s com qwen3.6:27b numa 4090 limitada a 350W. No teto, isso dá cerca de 8,75 J/token
    Não sei como isso se compara com outras opções, mas imagino que a 5090, sendo mais rápida sob o mesmo limite de energia, fique um pouco mais barata
  • Isso é com base no hardware atual. E o hardware futuro? Hardware otimizado para inferência? Hardware otimizado para rodar modelos específicos?

• Achei interessante tratarem o vLLM como se fosse mais lento que o llama.cpp
  Pela minha experiência, o vLLM é bem mais rápido que o llama.cpp, especialmente em processamento em lote com carga concorrente, onde ele domina. A desvantagem é que a flexibilidade de ajuste cai drasticamente. Há pouquíssimas opções para rodar pesos quantizados, e o tempo de inicialização fica muito maior por causa da otimização do grafo computacional. Então, para um único usuário experimentando um modelo um pouco grande demais para o equipamento, o vLLM pode ser frustrante

  • Dá para dizer assim: vLLM não é um Llama.cpp pior, é uma ferramenta diferente
  • O vLLM é excelente para batching contínuo e serving de modelos em produção, mas na categoria prosumer é algo totalmente diferente e muito menos versátil
    “Tratar como se fosse” é uma expressão forte, mas falando com mais detalhe: numa máquina com 2x 3090, ele levou mais de 4 minutos para carregar, e numa requisição única foi 3 tokens/s mais lento
    O pior é que, depois de todo o esforço de configurar e ajustar, ele ainda entrou em loop. Eu queria que aquele conselho recorrente de “é só usar vLLM” fosse uma solução universal
    Uma coisa a tomar cuidado aqui é não começar a menosprezar o llama.cpp como fizeram com o Ollama. O llama.cpp é uma ferramenta muito capaz e se encaixa melhor no uso que realmente queremos dar a essas placas
    Para uma equipe grande tentando substituir assinaturas do Claude, talvez o vLLM seja a única opção, mas para subir algo como o GLM 5.2 seria preciso adicionar mais umas 5 placas RTX 6000
  • Pelo que eu me lembro, o consenso geral era: para usuário único, llama.cpp; para múltiplos usuários ou empresa, vLLM. Parecidos, mas com usos diferentes
  • Fiquei meio perplexo com a parte de continuar usando llama.cpp e não mudar para vLLM, enquanto reclamam que o prefix cache quebra quando vários usuários acessam o modelo

• Dizem que “o modelo roda quente demais, passa do objetivo e entra em loop”, e depois comentam que configuraram o vLLM para os experimentos mais recentes, mas que mesmo com NVLink e paralelismo de tensores a geração ficou 3 tokens/s mais lenta que no llama.cpp
  Em todos os meus testes, valeu a pena usar vLLM. Foi o fator único que mais ajudou com problemas de loop, com agente ficando estranho, com perda de foco na tarefa e com contexto longo se tornando praticamente inútil
  No vLLM, usar modelo FP8 e cache não quantizado melhora a experiência geral em um nível acima de qualquer outra stack. Depois disso, dá para parar de mexer em configuração e focar em usar o modelo para outras coisas

  • Fiquei realmente curioso com essa parte. Não porque eu discorde, mas porque quero evitar que o agente fique estranho. Queria saber se você usa vLLM sozinho, para equipe ou para aplicação
    E também se você sente que existe um requisito mínimo de hardware para o vLLM ser útil desse jeito. Estou planejando montar um servidor doméstico de inferência como projeto de fim de semana, usando peças antigas de datacenter, e sigo refinando mentalmente a configuração final
  • Fiquei curioso sobre por que usar cache não quantizado em vez de Q8

• Para quem quer comprar e montar seu próprio equipamento de IA, eu recomendaria primeiro se conectar a um dos vários provedores de inferência e experimentar vários modelos por um tempo
  Custa quase nada, mas já dá uma prévia bem decente do que você pode conseguir com o seu próprio equipamento. Só uma dica amigável