IA Local em 2026: VRAM, Modelos e o Custo Real Frente à API
O que cinco vídeos publicados entre julho e agosto de 2026 mostram sobre rodar IA localmente: quais modelos cabem em 4, 8 e 16GB de VRAM, os números reais de tokens por segundo em cada engine e o veredito financeiro completo de rodar local versus pagar API.
“Cabe na minha placa de vídeo?” e “compensa financeiramente?” são as duas perguntas que voltam sempre que o assunto é rodar IA localmente em vez de pagar por API. Para responder sem chutar número, reunimos cinco vídeos publicados entre julho e agosto de 2026 sobre o tema, de canais diferentes, com abordagens diferentes: um guia de hardware por faixa de VRAM, um panorama de ferramentas, dois testes práticos de modelos de fronteira em Mac e uma conta financeira feita do zero. Este artigo segue à risca o que cada resumo afirma: onde a fonte dá um número exato, ele entra no texto; onde não dá, o texto não inventa um.
A regra de ouro da VRAM (e o que acontece quando ela estoura)
No vídeo de Kauã Miguel - Dev, o argumento central é que o fator limitante para rodar um modelo local não é a RAM do sistema nem o processador: é a VRAM da placa de vídeo. A conta de bolso apresentada é direta: em quantização Q4, cada 1 bilhão de parâmetros do modelo consome aproximadamente 0,6 GB de VRAM.
O vídeo explica também o que acontece quando essa memória estoura: o modelo transborda para a RAM convencional, e a velocidade de inferência despenca, caindo de cerca de 30 tokens por segundo para menos de 4 tokens por segundo. Na prática, é a diferença entre um chat fluido e uma conversa travada, esperando cada palavra aparecer na tela.
O motor por trás de praticamente tudo é o llama.cpp, responsável pelo formato de empacotamento GGUF: um arquivo único que já vem com a quantização aplicada, comprimindo os pesos originais de FP16/FP32 para INT4/Q4. As três ferramentas comparadas no vídeo para rodar esse arquivo são:
- Ollama: focado em execução prática via linha de comando e servidor, no estilo Docker. Está catalogado em Recursos.
- LM Studio: interface visual rica, pensada para comparar modelos lado a lado. Também está em Recursos.
- Llamafile: executável universal e portátil, roda o modelo a partir de um único arquivo.
Para quem quer saber, antes de baixar qualquer coisa, o que a própria placa aguenta, o vídeo apresenta a ferramenta web Can I Run AI (canirunai.com), que também roda direto pelo terminal com o comando npx can-i-run-ai, fazendo um benchmark instantâneo do hardware.
As razões para rodar local que o vídeo lista são privacidade absoluta, segurança de dados corporativos (evitar enviar PDFs sensíveis para servidores externos de terceiros) e a possibilidade de operar totalmente offline.
Três modelos, três faixas de VRAM: os números do teste
O vídeo mais direto sobre “qual modelo cabe na minha placa” é o de ViktorKav, que testa modelos por faixa de VRAM e chega a uma recomendação para cada uma:
| VRAM da GPU | Modelo | Tipo | Contexto recomendado | Destaque de benchmark |
|---|---|---|---|---|
| 4 GB | G9 V3B (AI9 Stars) | Denso, 3B parâmetros | 8k–16k tokens | 48/48 em testes de function calling encadeado |
| 8 GB | Ling 3.0 Tiny (Inclusion AI / Ant Group) | Mixture of Experts (MoE) | 12k–19k tokens | O dobro de pontuação agêntica frente aos concorrentes da faixa; suporte nativo consistente a português |
| 16 GB | Qwen 3.8 27B | Denso, 27B parâmetros | 32k tokens | 68 em código e 51 em uso agêntico, líder isolado da faixa |
Para os três, a recomendação é rodar em Llama.cpp ou Ollama com o modo de raciocínio desligado, o que evita gargalos de latência, mas também significa que são modelos deliberadamente mais simples, não substitutos diretos de um modelo de fronteira. Para o Qwen 3.8 27B especificamente, a quantização recomendada é a IQ4_XS, que ocupa 14,6 GB e preserva 99,2% da precisão do modelo original em FP16/32, o que explica por que ele ainda cabe (com folga apertada) em 16 GB de VRAM.
Um alerta específico desse vídeo, sobre a “conta esquecida” de rodar agente de código local: o Claude Code envia cerca de 23.000 tokens de instruções de sistema antes mesmo da primeira mensagem do usuário, o que já satura sozinho uma placa de 4 GB. Alternativas mais leves nesse quesito são o OpenCode, com cerca de 7.000 tokens de system prompt, e o Codex, com cerca de 8.800 tokens. Ou seja: a ferramenta de agente escolhida pesa tanto quanto o modelo na hora de decidir o que cabe na sua placa.
Modelos de fronteira em Mac: Music Glimmer e DeepSeek V4 Flash
Dois vídeos testam modelos bem maiores, fora da faixa de “GPU de consumidor” das seções anteriores, rodando em Apple Silicon.
Music Glimmer, da Meta (testado por ViktorKav)
O Music Glimmer é um modelo de código aberto de 30B parâmetros, licenciado em Apache 2.0, desenvolvido pela Meta especificamente para funcionar como agente local autônomo e multimodal. No benchmark MCP Atlas de uso de ferramentas, ele atingiu 75,5%, contra 54,2% do Gemma 4, do Google.
Nos testes práticos do vídeo, o modelo deu conta de extrair automaticamente trailers oficiais em 4K AV1 do YouTube via script, converter em lote pastas de imagens complicadas (arquivos HEIC, GIFs de 12 quadros, PNG corrompido), analisar notas fiscais em imagem lendo até os rodapés, e encadear 8 sessões complexas de depuração de código com rollback seletivo, sem perder o histórico no meio do processo.
O trade-off fica na velocidade: por ser um modelo denso de 30B ativo o tempo todo (diferente de um MoE, que só ativa parte dos parâmetros por token), ele executa 3 vezes mais passos de verificação intermediários. O resultado é que roda de 10 a 50 vezes mais devagar localmente do que modelos gigantes em nuvem, como Opus 5 ou DeepSeek V4.
DeepSeek V4 Flash em Mac Studio (testado por AI ProgBr)
O canal AI ProgBr testou a versão Q4 do DeepSeek V4 Flash (280B de parâmetros totais, 12B ativos por token, ocupando 160 GB em disco) rodando em um Mac Studio M3 Ultra com 256 GB de memória unificada.
A escolha do motor de inferência fez diferença enorme na velocidade: LM Studio e MLX rodaram devagar, entre 3,6 e 5 tokens por segundo. Já um motor especializado chamado Dwarf Star (também citado como “DS4”), com aceleração via Metal, sustentou entre 30 e 35 tokens por segundo, de forma estável.
Com esse motor, o canal criou, de forma autônoma, um clone funcional de Angry Birds, uma landing page completa para uma creche (com busca de imagens incluída), e três clones de Flappy Bird em paralelo usando três subagentes em lote, cada um em um estilo diferente: Pixel Art, 3D com Three.js e estilo Matrix. O vídeo também aborda o papel do KV Cache e do cache hit/miss: como a reutilização de prefixos de prompt reduz o custo e o tempo de pré-processamento, tanto localmente quanto em chamadas de API.
Vale notar que os dois vídeos citam tamanhos ligeiramente diferentes para o DeepSeek V4 Flash (284B total / 13B ativos no vídeo de Anwar Hermuche, abaixo; 280B total / 12B ativos no vídeo do AI ProgBr). São arredondamentos de fontes distintas, não uma contradição grave, mas por isso cada número aqui está atribuído ao vídeo que o afirma.
A conta financeira completa: quanto custa rodar local de verdade
O vídeo mais longo do grupo, com quase 1h25 de duração, de Anwar Hermuche (Engenheiro de IA), é o único dos cinco que constrói a matemática do zero: arquitetura Transformer, tipos de parâmetro (FP32 a 4 bytes, FP16 a 2 bytes, INT4 a 0,5 byte), a perda de precisão da quantização, FLOPs, bandwidth de VRAM, KV cache, prefill e decode, tensor parallelism e Mixture of Experts.
O hardware de referência é o NVIDIA H100 NVL: 94 GB de VRAM, 3,9 TB/s de largura de banda de memória e TDP de 350 a 400W. É importante deixar claro que essa é escala de datacenter corporativo, não uma GPU de PC doméstico como as das seções anteriores.
Dois cenários de alocação são detalhados:
- Qwen 3.6 (27B em FP16): 54 GB de pesos mais 6 GB de KV cache e ativações, totalizando 60 GB em uma única GPU H100, com vazão de aproximadamente 52 tokens por segundo.
- DeepSeek V4 Flash (284B MoE em INT4, 13B ativos por token): 156 GB distribuídos em duas GPUs H100, via tensor parallelism e cabo NVLink, com vazão de aproximadamente 295 tokens por segundo.
Para o custo mensal, o vídeo usa a tarifa real da Enel SP (R$ 0,79/kWh, já somando ar-condicionado e CPU de suporte):
- Energia: R$ 114,47/mês com 1 GPU; R$ 235,00/mês com 2 GPUs.
- Depreciação de hardware em 5 anos (servidor entre R$ 300 mil e R$ 520 mil): entre R$ 5.041/mês e R$ 8.754/mês.
E aqui está o veredito, com números, por 1 milhão de tokens de saída:
| Rodando local | Via API em nuvem | |
|---|---|---|
| Qwen | R$ 76,50 | R$ 16,50 |
| DeepSeek | R$ 23,50 | R$ 1,54 |
A conclusão do vídeo é direta: as APIs em nuvem saem de 5 a 15 vezes mais baratas para o usuário individual, porque o provedor usa continuous batching: carrega os pesos do modelo uma única vez e atende centenas de usuários em paralelo, diluindo o custo fixo de hardware entre todos eles. Rodar local só se paga, financeiramente, para quem tem escala suficiente para saturar o hardware sozinho; para o resto, a justificativa para rodar local é privacidade estrita ou soberania de dados, não economia.
Onde a IA local ainda esbarra
Juntando os cinco vídeos, um padrão se repete:
- Modelo pequeno tem raciocínio deliberadamente limitado. Os três modelos recomendados por faixa de VRAM (4, 8 e 16 GB) rodam com o modo de raciocínio desligado para não travar; são opções ajustadas ao hardware, não substitutos de modelo de fronteira.
- A ferramenta de agente pesa tanto quanto o modelo. Só o system prompt do Claude Code (23 mil tokens) já satura uma placa de 4 GB antes da primeira resposta; OpenCode e Codex pesam bem menos nesse quesito.
- Modelo denso de fronteira é lento em hardware local. O Music Glimmer, rodando local, é de 10 a 50 vezes mais lento que modelos gigantes em nuvem, mesmo em um Mac razoavelmente robusto.
- O motor de inferência importa tanto quanto o modelo. No teste do DeepSeek V4 Flash, trocar LM Studio/MLX por um motor especializado (Dwarf Star) foi a diferença entre 5 tokens/s e 35 tokens/s no mesmo hardware.
- A economia de local vs. API depende de escala, e a conta real favorece a API. No único vídeo que fecha a conta até o fim, rodar local sai de 5 a 15 vezes mais caro por token de saída do que pagar API, mesmo usando hardware corporativo (H100), não uma placa de consumidor.
Regra prática
Nenhum dos cinco vídeos trata IA local como substituição automática de API, financeiramente falando. O padrão que emerge é: primeiro checar quanta VRAM você tem (ferramentas como Can I Run AI ajudam nisso), depois escolher o modelo e a quantização certos para essa faixa, testar a carga de trabalho real (chat é muito mais leve que agente de código) e só então decidir se compensa. Se a meta for economia, os números do vídeo de Anwar Hermuche são um alerta: mesmo em GPU de datacenter, a API sai mais barata. IA local compensa mesmo quando o motivo é privacidade, soberania de dados ou controle, não redução de custo por token.
Fontes
- “A IA Local Certa pra Sua Placa: 4, 8 e 16GB” — ViktorKav
- “Entenda IA Local de Uma Vez: Qual Modelo Cabe na Sua Placa de Vídeo” — Kauã Miguel - Dev
- “A Meta Fez a IA Local Que o Google Não Conseguiu” — ViktorKav
- “Rodar LLM local é mais barato que API? Fiz as CONTAS e ESSE é meu VEREDITO!” — Anwar Hermuche | Engenheiro de IA
- “DeepSeek V4 Flash LOCAL: já dá pra CANCELAR o Claude e o GPT?” — AI ProgBr
