Olá a todos!
Há uns dias apareceu no r/LocalLLaMA um post que me fez parar o que estava a fazer e ler atentamente. Não porque fosse particularmente bem escrito — o OP até levou com acusações de ter usado IA para escrever o post, o que é irónico dado o tema — mas porque alguém finalmente fez o que toda a gente devia fazer e ninguém faz: medir. Medir exactamente quanto do seu trabalho diário com LLMs realmente precisa de modelos de fronteira na cloud, e quanto pode correr localmente numa GPU que já tinha em casa a não fazer nada.
Os resultados, como o próprio título do post diz, são interessantes. Não no sentido de serem maus. No sentido de serem tão óbvios que muitos de nós nos sentimos estúpidos por nunca termos feito o exercício.
E o que me levou a escrever este post não foram só os números do OP. Foi a discussão que se gerou nos comentários — dezenas de developers a partilharem experiências semelhantes, a debaterem soluções de routing, a fazerem contas de electricidade ao cêntimo, e pelo menos um comentário técnico tão denso que merece um post só para ele. Mas acima de tudo, foi a ligação directa que vi entre o que este developer individual está a fazer e o que as empresas deviam estar a fazer para controlar os custos de IA que, como já escrevi aqui no blog, estão subsidiados e vão inevitavelmente subir.
Vamos a isto.
O experimento: 10 dias, 150 tarefas, uma 3090 e o taxímetro a contar.
O que o spencer_kw fez foi simples na concepção e trabalhoso na execução. Durante 10 dias, registou todas as tarefas do seu workflow de desenvolvimento: o que eram, quantos tokens de input e output consumiam, e se o modelo local — um Qwen 3.6 27B a correr numa RTX 3090 — conseguia ou não produzir resultados equivalentes ao modelo cloud que usava normalmente. Não usou benchmarks académicos. Pegou numa amostra aleatória de 150 tarefas reais e correu-as nos dois ambientes. Trabalho real, não simulações.
Os resultados dividiram-se em quatro categorias bastante claras.
A primeira categoria — leitura de ficheiros, scanning de projectos, explicação de código — representava 35% do workload dele. O modelo local acertou 97% das vezes comparado com o cloud. Trinta e cinco por cento do trabalho a correr essencialmente de borla, e ele estava a pagar API cloud para isto. Como ele próprio diz, pagar cloud aqui é deitar dinheiro fora.
A segunda categoria — escrita de testes, boilerplate, edições de ficheiro único — era outros 30% do trabalho. O modelo local acertou 88%. Os 12% de falhas eram edge cases que ele conseguia apanhar em code review. Portanto, mais 30% do workload onde o modelo local é perfeitamente utilizável com uma revisão humana mínima.
A terceira — debugging com contexto multi-ficheiro — representava 20% do trabalho, e aqui o local caiu para 61%. O cloud era claramente melhor, mas como o OP nota com toda a razão: melhor, mas não 17 vezes o preço melhor.
E a quarta — decisões de arquitectura, refactors complexos que tocam em 5 ou mais ficheiros — eram apenas 15% do trabalho. Aqui o local ficou nos 29%. Cloud genuinamente necessário.
A conclusão aritmética é devastadora na sua simplicidade: 65% do trabalho diário de coding deste developer corre de forma idêntica num modelo que lhe custa electricidade. Outros 20% são suficientemente próximos para aceitar a falha ocasional. Apenas 15% justifica genuinamente o preço de um modelo de fronteira na cloud.
E quando começou a fazer routing por tipo de tarefa — local para as duas primeiras categorias, cloud para as duas últimas — a factura de API passou de 85 dólares por mês para 22. A 3090 já lá estava, já estava paga, já estava ligada.
As contas que há preguiça de fazer (mas o Reddit fez)
O que tornou esta thread particularmente rica foi que os comentários não ficaram pela superfície. Vários utilizadores foram fazer as contas com rigor que envergonharia muitos business plans de startups de IA.
O ikkiho, num comentário que é praticamente um mini-paper, desmontou o argumento do custo de várias formas. Primeiro, lembrou que o número “17x mais barato” que o DeepSeek V4 apresenta em relação ao GPT-5.2 não é puramente sobre eficiência do modelo. É sobre economia de batch. Os providers de fronteira servem com batch sizes de 64 a 256, com continuous batching e reutilização de prefix-cache. O custo por token por segundo de GPU cai de forma praticamente linear com o batch efectivo até atingir o limite de compute. Uma 3090 a correr com batch de 1 está a pagar entre 10 a 20 vezes mais por token amortizado do que o provider faz no mesmo hardware. Ou seja: local é mais barato que cloud de fronteira, sim, mas não é tão barato quanto os preços do DeepSeek sugerem — porque o DeepSeek beneficia de escala de serving que tu em casa não tens.
Depois dissecou o porquê da queda para 61% no debugging multi-ficheiro. Não é simplesmente “contexto longo.” É qualidade de retrieval ao nível do KV-cache. Um modelo de 27B com Grouped Query Attention partilha key/value across 4 a 8 query heads, o que comprime a bandwidth de atenção por posição e se manifesta como menor precisão em tarefas de needle-in-haystack em contextos longos. A extensão de RoPE via yarn ou interpolação linear adiciona aliasing de frequência para além da distribuição original de treino. E aqui veio a sugestão prática: ganha-se 10 a 15% de volta com uma layer de RAG real — semântica mais AST mais filtros de git-blame — em vez de despejar o repo inteiro no contexto. Porque retrieval bate long-context attention a contagem de parâmetros fixa.
E sobre a queda para 29% nos refactors complexos, o diagnóstico foi igualmente preciso: é um bottleneck de profundidade de planeamento, não de contagem de parâmetros. Multi-step lookahead em decoding autoregressivo é compute-fixed, não parameter-fixed. Um modelo de 27B com budget de thinking de 4 a 8 mil tokens de raciocínio frequentemente fecha 5 a 10% desse gap, porque compute marginal de raciocínio compõe mais do que capacidade marginal de parâmetros nesta classe de tarefas.
E depois fez a conta da electricidade que o OP ignorou. Uma 3090 a 350W durante 12 horas por dia a 0.20 dólares por kWh dá cerca de 25 dólares por mês — mais do que os 22 dólares de cloud que o OP ficou a pagar. O argumento “já lá estava” funciona uma vez mas não generaliza para lá do sunk cost. Afinal a 3090 já estava paga e já estava ligada.
Outro comentador, o Sandoplay_, questionou com razão os 12 horas de GPU por dia — na prática, a GPU está idle a maior parte do tempo à espera da próxima prompt. A estimativa dele era que 4 horas de uso real seria generoso, o que baixa a conta para cerca de 8 dólares por mês. Mais razoável, e aí sim o local ganha claramente em custo.
O nihilistWithATwist fez a conta ao contrário: assumindo 25 tokens por segundo de throughput, 400W de consumo total do sistema, e 0.20 dólares por kWh, o custo por token fica em cerca de 1.2 milhões de tokens por dólar. Barato? Sim. Grátis? Não. E o Hylleh corrigiu que um modelo de 27B na 3090 está mais perto dos 50 tokens por segundo, o que melhora ainda mais a conta.
O problema do routing: como é que decides o que vai para onde?
Uma das perguntas mais votadas na thread veio do Opening-Broccoli9190: “Como é que fazes routing por tipo de tarefa? Construíste algum harness?”
E aqui a comunidade dividiu-se em duas escolas.
A escola pragmática apontou para ferramentas existentes. O Ariquitaun sugeriu o OpenCode, que permite configurar diferentes agentes para diferentes tarefas. O kleinishere apontou para um projecto no GitHub chamado oh-my-pi com configuração semelhante. O Pleasant-Shallot-707 mencionou o Hermes Agent e o seu sistema de workflow multi-agente com Kanban, onde podes especificar múltiplos modelos e usar hooks para activar o modelo certo por tarefa.
A escola técnica, representada pelo ikkiho, foi mais longe: routing treinado bate heurística manual. A sugestão dele é elegante na sua simplicidade. Rotulas 1000 tarefas passadas com o modelo cloud — “teria acertado / teria falhado” — treinas um classificador de 100 milhões de parâmetros sobre a descrição da tarefa, sumário da codebase, número de ficheiros, e tamanho esperado do diff, e fazes routing com base na predição, com abstenção para casos ambíguos. Custo de labeling: cerca de 5 dólares. E automatiza a decisão melhor do que qualquer regra escrita à mão.
O rob417 trouxe outra perspectiva prática: estava a usar o GitHub Copilot e levou um susto quando o sistema lhe disse que tinha gasto 35% do seu limite de 5 horas depois de apenas 5 requests. Passou a semana a testar Qwen 3.6 35B e Gemma4 26B na sua 5070. São perfeitamente capazes de escrever scripts de ficheiro único, que é o grosso do trabalho dele. E descobriu algo interessante: o Qwen 3.6 35B falhava sistematicamente dentro do plugin do VS Code Copilot, mas funcionava bem no OpenCode e no Pi. O problema não era o modelo — era o context bloat do harness do Copilot.
…se isto funciona para um developer, funciona para uma empresa
E é aqui que quero fazer a ponte que considero mais importante, e que a thread do Reddit não faz explicitamente mas que está implícita em cada comentário.
Se um developer individual consegue poupar 74% na sua factura de API fazendo routing inteligente entre local e cloud — de 85 para 22 dólares — imaginem o que uma empresa com 50, 100, 500 developers pode poupar. Os números escalam de forma brutal.
Vamos fazer contas simples. Uma empresa com 100 developers, cada um a gastar em média 85 dólares por mês em APIs de LLM, está a gastar 8.500 dólares por mês, ou 102.000 dólares por ano. Se implementar routing inteligente com as mesmas proporções do experimento do OP — local para 65% das tarefas, cloud apenas para os 35% que genuinamente precisam — essa factura cai para aproximadamente 27.200 dólares por ano. Uma poupança de quase 75.000 dólares anuais.
E isto é conservador. Muitas empresas têm custos de API muito superiores a 85 dólares por developer por mês, especialmente quando contam com pipelines de CI/CD que usam LLMs para code review automático, geração de testes, e documentação — tarefas que, como o experimento demonstra, são as primeiras candidatas a correr localmente.
Mas a poupança directa em API é apenas metade da história. A outra metade — e que já abordei extensamente no meu post sobre o custo escondido do token subsidiado — é a protecção contra o inevitável aumento de preços. Quando a Anthropic e a OpenAI fizerem IPO e os investidores institucionais exigirem margens reais, os preços dos tokens vão subir. Os preços actuais estão subsidiados por venture capital, e esse subsídio tem data de validade. Uma empresa que já tem 65% do seu workload a correr em infraestrutura própria está isolada de 65% desse aumento de preços, seja ele qual for.
E há uma terceira dimensão que raramente se discute: a disponibilidade. O brahh85 fez um ponto na thread que achei particularmente lúcido. Argumentou que em breve a procura por tokens cloud vai exceder a oferta por uma margem significativa, e que já estamos a ver os sinais — planos a sofrer cortes, rate limits a apertar, filas de espera para acesso a modelos de fronteira. Ter capacidade de inferência local é um hedge contra indisponibilidade, não apenas contra preço.
De notar que esta metodologia igualmente aplica-se a quem usa AI para tarefas de datacenter. O preço do hardware está caro sim, mas ao preço que os tokens estão a subir, rapidamente o investimento irá compensar.
O que uma empresa precisa para implementar isto
Falar é fácil. Implementar é outra conversa. Mas a thread do Reddit, em conjunto com o que tenho visto no mercado, sugere que as peças já existem. O que falta é montar o puzzle.
Primeiro, precisas de hardware. E aqui há uma nuance importante que o Mistercheese levantou na thread: correr modelos locais é mais lento que cloud, especialmente com contextos grandes, e o tempo que perdes a corrigir os 10-12% de falhas do modelo local pode custar mais em horas de developer do que os tokens que poupaste. É um ponto válido. A contrapartida, como ele próprio admite, é que podes correr o mesmo modelo localmente mas na cloud de um provider barato — o Qwen 3.6 Pro, por exemplo, é substancialmente mais rápido que local e custa alguns dólares por mês. A decisão entre local-local e local-cloud-barato depende do teu volume e da tua tolerância a latência.
Segundo, precisas de um sistema de routing. E aqui é onde a sugestão do classificador treinado do ikkiho brilha. Em vez de regras manuais do tipo “se o prompt menciona mais de 3 ficheiros, usa cloud”, treinas um modelo pequeno e rápido que aprende os padrões da tua codebase específica. Os custos são negligenciáveis — 5 dólares em labeling, minutos de treino — e o resultado é routing que melhora com o tempo à medida que acumulas mais dados.
Terceiro, precisas de métricas. E aqui volto ao ponto que faço sempre: se não estás a medir custo por feature, custo por developer, custo por workflow, estás a voar às cegas. O experimento do OP só foi possível porque ele registou cada tarefa durante 10 dias. A maioria dos developers — e das empresas — não faz ideia de como os seus tokens se distribuem por tipo de tarefa. Sem esse dado, routing inteligente é impossível.
O NineThreeTilNow trouxe um exemplo concreto do que acontece quando não medes. Tentou explicar a alguém que não precisava do Opus para operar um projecto inteiro a queimar tokens em tarefas triviais como ler ficheiros e gerar documentação. A resposta que recebeu foi que escrevia código horrível e que nada do que fizesse teria valor. A ironia, como ele nota, é que trabalhou como contractor para a Anthropic no Opus. Mas o ponto central não é a ironia pessoal — é que muita gente usa o modelo mais caro disponível para tudo, por preguiça ou por falta de dados que justifiquem fazer diferente. E depois testou uma abordagem híbrida: Claude para documentação de alto nível e Kimi para implementação. Os resultados ficaram a 1-2% do cenário all-cloud. E com o Gemma 4 31B a correr na 4090, o cenário local ficou ainda mais viável para as tarefas de documentação.
Se quiserem falem comigo. A empresa onde estou tem estado já a implementar PoC e infra deste tipo.
A sombra que paira sobre tudo isto: privacidade e controlo
Há um aspecto desta discussão que merece mais atenção do que recebe: o controlo sobre os dados.
O NineThreeTilNow levantou uma preocupação real sobre o Kimi e a Moonshot: treinam em tudo o que lhes envias, incluindo via API. Para uso pessoal, talvez não seja um problema. Para uma empresa que está a enviar código proprietário para um endpoint de inferência, é um risco que precisa de ser avaliado.
E aqui, o modelo local tem uma vantagem que nenhum provider cloud pode igualar, independentemente das suas políticas de privacidade: os dados nunca saem da tua rede. Para sectores regulados — saúde, finanças, defesa, administração pública — isto não é um nice-to-have. É frequentemente um requisito legal.
Uma empresa que implementa routing inteligente não está apenas a poupar dinheiro. Está a criar uma arquitectura onde os dados sensíveis ficam em modelos que controla, e apenas as queries que genuinamente precisam de capacidade de fronteira — e que podem ser adequadamente sanitizadas — saem para a cloud.
A falsa dicotomia: não é local vs. cloud, é local E cloud
Se há uma coisa que a thread do Reddit demonstra com clareza cristalina é que a dicotomia local-vs-cloud é falsa. Ninguém na thread argumenta que devas abandonar modelos de fronteira. O que argumentam — com dados — é que 65% do teu workload não precisa deles.
O jackyy83 resumiu bem: usa cloud para arquitectura de alto nível e decomposição de tarefas, usa local para implementar os detalhes. É um padrão que faz sentido intuitivo e que os dados do OP suportam: as tarefas onde o modelo local falha são exactamente as que requerem planeamento complexo e visão holística do projecto. As tarefas onde o local iguala o cloud são as de execução — leitura, escrita de código, boilerplate, testes.
É, no fundo, o mesmo padrão que usamos há décadas em engenharia de software: o arquitecto desenha, o developer implementa. A diferença é que agora o “developer” é um modelo de 27 mil milhões de parâmetros que corre na tua GPU e te custa cêntimos por hora.
O que isto significa para quem toma decisões
Se és CTO, VP de Engineering, ou simplesmente a pessoa na tua empresa que decide onde se gasta dinheiro em IA, o post do spencer_kw no Reddit é um wake-up call. Não porque te diga algo que não soubesses em teoria — todos sabemos que nem todas as tarefas precisam do modelo mais potente — mas porque quantifica essa intuição com dados reais.
E os dados dizem isto: estás provavelmente a gastar 3 a 4 vezes mais em tokens do que precisas. Não porque os tokens sejam caros demais. Mas porque estás a usar o modelo errado para a tarefa errada.
A solução não é complicada. É trabalhosa, sim, mas não é complicada. Mede o teu workload durante uma ou duas semanas. Classifica as tarefas por complexidade. Testa um modelo local ou cloud-barato nas categorias mais simples. Implementa routing. Mede de novo. E se precisares de ajuda contacta-nos.
E quando os preços dos tokens subirem — porque vão subir — vais estar contente por já ter 65% do teu workload isolado desse aumento.
Espero que tenham gostado do post.
Como sempre, se acharem alguma coisa fora do sítio, ou que denote reparo, já sabem onde me encontrar.
Um abraço.
Nuno
Fonte principal: thread do r/LocalLLaMA, “DeepSeek V4 being 17x cheaper got me to actually measure what I send to cloud vs what I could run locally. the results are stupid.” por spencer_kw, maio de 2026.
Podem chegar aos outros links indo através da thread.