LLMs locais rodando em GPUs ociosas dos computadores de desenvolvedores podem reduzir o gargalo de custos com APIs de LLMs em ambientes corporativos?

Introdução

Organizações estão cada vez mais dependentes de LLMs comerciais hospedados via API para tarefas de desenvolvimento de software. Isso traz três riscos crescentes: custo instável e crescente, dependência de um único fornecedor, e exposição de dados sensíveis a terceiros.

O preço do GitHub Copilot para faturamento agêntico, por exemplo, subiu de 10x a 50x para usuários intensivos após a mudança de modelo de cobrança em 2026^[1], e pesquisas de mercado independentes mostram uma pressão contínua de custo e reprecificação entre os principais provedores de LLM^[2]. Ao mesmo tempo, levantamentos de segurança apontam riscos reais de privacidade em assistentes de código baseados em nuvem^[3], e análises de mercado destacam o risco de dependência de fornecedor único como uma preocupação estratégica crescente para empresas^[4].

Do outro lado dessa equação está um recurso que a maioria das organizações já possui e mal utiliza: GPUs. Estudos de infraestrutura corporativa apontam utilização média de GPU em torno de apenas 5% fora de cargas de treinamento dedicadas^[5] — ou seja, a capacidade computacional já está lá, ociosa, na estação de trabalho do próprio desenvolvedor.

A premissa deste estudo é simples: para uma fração relevante das tarefas de desenvolvimento assistidas por IA que devs relatam usar no dia a dia^[6] — escrever, depurar, testar, documentar e revisar código — será que um modelo local, rodando na GPU ociosa da própria máquina, já entrega qualidade suficiente para substituir a chamada de API?

Metodologia: o que exatamente testamos

Para não cair em achismo, montamos um harness de execução real — não um benchmark sintético de completar código, mas um agente que efetivamente lê, cria e edita arquivos, e roda comandos, exatamente como uma ferramenta de coding assistant faria.

• 10 modelos especializados em código, de 3B a 30B de parâmetros, todos quantizados em 4-bit (padrão do Ollama para cada publisher) — todos encontrados e baixados diretamente do catálogo de modelos de código do próprio Ollama
• 14 tarefas, distribuídas em 7 categorias: correção de bug, adaptação, criação, explicação, teste, documentação e revisão de código
• Cada categoria testada em Python e C
• Hardware fixo: um único laptop consumer com GPU de 8 GB de VRAM — o cenário real de uma estação de trabalho corporativa comum, não um servidor de treinamento
• Agente com até 8 passos por tarefa, escolhendo entre ler arquivo, buscar código, criar arquivo, editar arquivo, rodar comando ou finalizar
• Contexto fixo em 4.096 tokens para todos os testes, garantindo comparação justa

Para deixar claro o que cada categoria realmente pedia ao modelo, e não só o nome abstrato dela, a tabela abaixo mostra a instância concreta de tarefa usada em cada linguagem:

Tarefas automatizáveis (correção de bug, adaptação, criação, teste e documentação) foram verificadas por compilação/execução real — sem julgamento manual. Tarefas de explicação e revisão de código foram avaliadas manualmente, em uma escala de 0 a 5.

Resultado principal: 25% de acerto médio, mas um outlier em 80%

Das 100 tentativas automaticamente verificáveis (10 modelos × 10 tarefas checáveis), apenas 25 (25,0%) produziram saída verificadamente correta. É um número baixo — mas mascara uma diferença enorme entre modelos.

É um resultado notável considerando que esse modelo é uma arquitetura Mixture-of-Experts (MoE) com 30B de parâmetros totais — cujo peso completo excede o orçamento de 8 GB de VRAM da GPU testada — mas apenas 3,3B de parâmetros ativos por token. Mesmo rodando parcialmente fora da GPU, ele entregou o melhor resultado do estudo.

O que o tokens/s não te conta: tempo de resposta final

Throughput isolado (tokens por segundo) esconde uma parte importante da experiência real: quantos passos o agente precisa para chegar numa resposta final, e qualquer overhead fixo por passo (reprocessamento de contexto, formatação de resultado de ferramenta). Por isso, além do tokens/s, medimos o tempo total, do pedido até a resposta final, em cada uma das 14 tarefas.

O achado é uma troca real entre velocidade e correção que o tokens/s por si só não revela: os quatro modelos mais rápidos em tempo de resposta (CodeQwen1.5, 20.8s; Qwen2.5-Coder, 25.5s; DeepSeek-Coder-V2, 25.6s; CodeGeeX4, 29.3s) estão todos no meio da tabela ou piores em correção automatizada — enquanto o Qwen3-Coder-30B-A3B, o melhor modelo do estudo em correção e qualidade, fica em sexto lugar em velocidade, com 50.1s por tarefa, quase 2,5x mais lento que o CodeQwen1.5.

Dois fatores se somam aqui: o throughput bruto do Qwen3-Coder é pouco mais da metade do CodeQwen1.5 (21.4 vs. 39.1 tokens/s, plausivelmente relacionado ao fato de seus pesos completos excederem os 8 GB de VRAM mesmo com apenas 3.3B de parâmetros ativos por token), e ele também usa mais passos de agente por tarefa em média (4.7 vs. 3.4) — a residência exata de GPU/CPU para esse modelo não foi medida de forma independente neste estudo.

Na prática, isso significa que a escolha de modelo para uso interativo em uma estação de trabalho deve tratar o tempo de resposta final como um critério próprio — não assumir que ele decorre diretamente do tokens/s ou da correção. O modelo mais correto testado aqui também é comparativamente lento para responder, e uma equipe otimizando para uso interativo e ágil pode razoavelmente trocar parte da correção pelos tempos de resposta abaixo de 30 segundos do CodeQwen1.5, Qwen2.5-Coder ou DeepSeek-Coder-V2, dependendo da tolerância a erro da tarefa.

Dois modelos MoE quase idênticos, comportamentos opostos

Qwen3-Coder-30B-A3B e North Mini Code 1.0 compartilham um perfil de arquitetura quase idêntico (30–30.5B de parâmetros totais, 3–3.3B ativos por token), mas produziram resultados muito diferentes (8/10 vs. 1/10 de acerto automatizado).

A inspeção das transcrições por tentativa mostra que isso não foi, principalmente, uma questão de qualidade de código: o North Mini Code esgotou seu orçamento de 8 passos sem sinalizar "concluído" em 8 de suas 14 tentativas, contra 2 de 14 do Qwen3-Coder — e uma tarefa cujo modelo nunca sinaliza conclusão é pontuada como não verificada, independentemente da qualidade de qualquer trabalho parcial realizado. O throughput médio foi comparável (20.5 vs. 21.4 tokens/s), então a diferença tampouco é primariamente um efeito de velocidade.

Confiabilidade estrutural, competência de código e honestidade textual são capacidades separáveis

Ao todo, dos 634 passos de geração registrados no estudo principal, 19,9% (126/634) não continham uma ação estruturada sintaticamente válida — variando de 5% (Qwen3-Coder) a 46% (Code Llama 7B). Essa taxa não foi, por si só, um bom preditor de correção: o DeepSeek-Coder 6.7B teve a segunda menor taxa de ações inválidas do estudo (6%) e ainda assim 0/10 de acerto automatizado, enquanto o CodeGeeX4 combinou uma taxa de inválidas mediana (27%) com o segundo melhor acerto (4/10).

O achado mais preocupante, no entanto, é sobre honestidade. O StarCoder2 (2/10 de acerto automatizado, um resultado relativamente respeitável) tirou 0.00 de 5 em todas as quatro tarefas de linguagem natural — fabricando, nas quatro vezes, uma descrição fluente e detalhada de uma função de soma de dois argumentos que não existe em nenhum dos arquivos fornecidos.

Limitações honestas

Este é um estudo de ponto único, não uma medição estatística robusta, e é importante dizer isso claramente:

• Uma única execução por par modelo-tarefa. A amostragem de LLMs é estocástica; nenhum número aqui tem uma medida de variância associada.
• Notas de linguagem natural de um único avaliador, sem segundo avaliador independente ou medida de concordância entre avaliadores.
• Uma única configuração de hardware e quantização (4-bit, 8 GB de VRAM) — os resultados são específicos a esse orçamento de VRAM.
• 14 tarefas escritas à mão pelo autor do estudo, com conhecimento prévio dos modos de falha esperados dos modelos — não uma amostra representativa extraída por processo independente.

Comparações entre modelos com pontuação agregada próxima (por exemplo, CodeGeeX4 e DeepSeek-Coder-V2, ambos 4/10) não devem ser lidas como um ranking confiável entre eles.

Conclusão

A premissa motivadora deste estudo agora tem suporte afirmativo, ainda que estreito: existe pelo menos um modelo open-weight atualmente disponível (Qwen3-Coder-30B-A3B) capaz de, rodando em hardware onde nem cabe inteiramente, atingir 80% de acerto verificado e nota perfeita em qualidade textual — uma evidência de que redirecionar capacidade de GPU ociosa para IA local é uma decisão de engenharia defensável, ao menos para as categorias de tarefa testadas aqui.

Mas isso não é uma afirmação sobre "modelos locais" como categoria. A taxa agregada de 25% entre os dez modelos, e a fabricação completa e fluente de um deles em toda tarefa de linguagem natural, mostram que essa capacidade ainda não é uma propriedade genérica — é uma propriedade de lançamentos específicos de modelo, que precisa ser identificada empiricamente, no hardware e na mistura de tarefas que uma equipe realmente pretende usar.

Dado esse cenário — hardware de VRAM limitada e modelos locais que ainda falham na maioria das tarefas mais exigentes — a estratégia mais realista não é substituir a IA paga, e sim segmentar por complexidade: direcionar para o modelo local as tarefas mais simples, porém de altíssima frequência no dia a dia do desenvolvedor (correção de bugs pontuais, pequenas adaptações, documentação, testes de rotina), e reservar a LLM paga apenas para o que exige raciocínio mais complexo. Como essas tarefas simples são justamente as mais repetidas, mesmo uma taxa de acerto local moderada já representa uma economia relevante de tokens pagos ao longo do tempo. Nessa lógica, o sistema mais eficiente não é "local vs. nuvem", mas um modelo híbrido, combinando as duas opções conforme a complexidade real de cada tarefa.