A Parte 2 detalha a economia do dimensionamento dos LLMs modernos e os custos reais de memória e processamento para executar os modelos atuais.
Dimensionamento: denso vs MoE, e o que cada um custa
Esta é a seção onde a maioria erra.
Os dois números de parâmetros que importam
Cada LLM moderno tem dois tamanhos relevantes:
- Parâmetros totais — quão grande o modelo é em disco e em memória. Determina a capacidade de hardware necessária.
- Parâmetros ativos por token — quantos parâmetros realmente computam para cada token gerado. Determina o throughput (tokens/seg) e o custo de energia.
Para modelos densos, esses números são iguais. Llama 3.3 70B usa todos os 70B para cada token.
Para MoE (Mixture of Experts), são muito diferentes. DeepSeek V4-Pro tem 1.6T totais mas só 49B ativos por token. O modelo é enorme em memória mas computa como um 49B para cada token gerado. Esse é o ponto inteiro de MoE — capacidade sem compute proporcional.
Implicações práticas
| Denso | MoE | |
|---|---|---|
| Memória necessária | = parâmetros totais × bytes/parâmetro | = parâmetros totais × bytes/parâmetro (igual — todos os experts precisam estar carregados) |
| Throughput por GPU | proporcional a parâmetros totais | proporcional a parâmetros ativos |
| Melhor para | comportamento previsível, fine-tuning fácil, deploy em uma única GPU | servir alto volume, capacidade fronteira sem compute fronteira |
| Pior para | escalar capacidade além do que cabe numa GPU | deploy de um único usuário em pequena escala (você paga o custo total de memória sem servir usuários suficientes para amortizar) |
Regra prática: se você tem um usuário ou poucos, modelos densos te dão melhor qualidade por GB de VRAM. Se está servindo muitos usuários concorrentes, MoE ganha decisivamente porque você paga o custo de memória uma vez e serve muitos requests na velocidade dos parâmetros ativos.
A matemática de memória
Memória aproximada necessária para carregar um modelo:
memória ≈ parâmetros × bytes_por_parâmetro + KV cache + overhead
Bytes por parâmetro:
| Precisão | Bytes/parâm | Qualidade | Quando usar |
|---|---|---|---|
| FP16 / BF16 | 2 | Referência | Servir em produção em GPUs de datacenter |
| FP8 | 1 | Perto da referência | Servir em produção moderno em H100/H200 |
| INT8 | 1 | Perda mínima | Servir em produção quando FP8 não está disponível |
| INT4 (Q4_K_M, AWQ, GPTQ) | 0.5 | Pequena mas aceitável | O default para inferência local |
| INT3 / INT2 | 0.25–0.4 | Degradação perceptível | Último recurso para encaixar um modelo fronteira em hardware de consumo |
Some 10–30% de overhead para KV cache (escala com o tamanho do contexto) e runtime.
Caso especial — modelos com quantização nativa como Kimi K2.6 são treinados com quantização (QAT), o que significa que a inferência INT4 é o deploy pretendido, não um fallback degradado. A perda de qualidade vs precisão completa é essencialmente zero.
Exemplos calculados (modelos atuais)
| Modelo | Params totais | Params ativos | Memória FP16 | Memória INT8 | Memória INT4 |
|---|---|---|---|---|---|
| Gemma 4 9B | 9B (denso) | 9B | ~18 GB | ~9 GB | ~5 GB |
| Mistral Small 3 24B | 24B (denso) | 24B | ~48 GB | ~24 GB | ~12 GB |
| Qwen 3.5 27B | 27B (denso) | 27B | ~54 GB | ~27 GB | ~14 GB |
| Qwen 3.6 35B-A3B (MoE) | 35B | 3B | ~70 GB | ~35 GB | ~18 GB |
| Llama 3.3 70B | 70B (denso) | 70B | ~140 GB | ~70 GB | ~35 GB |
| Llama 4 Scout (MoE) | 109B | 17B | ~218 GB | ~109 GB | ~55 GB |
| Qwen 3.5 122B-A10B (MoE) | 122B | 10B | ~244 GB | ~122 GB | ~61 GB |
| DeepSeek V4-Flash (MoE) | 284B | 13B | ~568 GB | ~284 GB | ~142 GB |
| Llama 4 Maverick (MoE) | 400B | 17B | ~800 GB | ~400 GB | ~200 GB |
| Qwen 3.5-397B-A17B (MoE) | 397B | 17B | ~794 GB | ~397 GB | ~199 GB |
| Kimi K2.6 (MoE, INT4 nativo) | 1T | 32B | — | — | ~500 GB (nativo) |
| DeepSeek V4-Pro (MoE) | 1.6T | 49B | ~3.2 TB | ~1.6 TB | ~800 GB |
Esses são só os pesos. Some 10–30% em cima para KV cache e overhead.
Parte 3 — Hardware: CUDA e MLX, números reais
Dois caminhos viáveis em 2026: NVIDIA CUDA (o padrão de produção) e Apple MLX/Metal (a jogada de valor para inferência de modelos grandes de um único usuário). AMD está melhorando mas ainda não é uma opção mainstream para servir LLMs em produção.
Nota sobre disponibilidade no Brasil e LATAM: GPUs de datacenter (A100, H100, H200, B200) são difíceis e caras de comprar diretamente na região. A realidade prática para a maioria dos times brasileiros e latino-americanos é: alugar na AWS São Paulo (sa-east-1), GCP, Azure Brasil Sul, ou provedores especializados como Lambda Labs, RunPod, Vast.ai. Custos de importação, impostos federais e estaduais (II + IPI + ICMS + PIS/COFINS), e prazos de entrega para hardware on-prem fazem com que a nuvem seja quase sempre mais barata para começar — especialmente no Brasil onde a carga tributária pode quase dobrar o custo final do hardware importado.
Tier 1 — GPU única de consumo (NVIDIA)
| Hardware | VRAM | O que roda (INT4) | O que roda (FP16) | Uso realista |
|---|---|---|---|---|
| RTX 3060 12GB | 12 GB | Até ~13B denso, Gemma 4 9B INT4 | Até ~7B denso | Hobbyista, aprendizado, máquina de dev para modelos pequenos |
| RTX 4070 Ti / 5070 16GB | 16 GB | Até ~22B denso, Gemma 4 9B FP16 | Até ~8B denso | Assistente de código pequeno, agentes Gemma |
| RTX 4090 24GB | 24 GB | Até ~34B denso, Qwen 3.6 35B-A3B | Até ~13B denso | O verdadeiro ponto doce para desenvolvedores solo |
| RTX 5090 32GB | 32 GB | Até ~50B denso, Mistral Small FP8 | Até ~16B denso | Mais folga, prova-futuro o tamanho de contexto |
Exemplos de throughput (RTX 4090):
- Llama 3.3 70B Q4 — ~20–35 t/s
- Qwen 3.6 35B-A3B Q4 — ~50–80 t/s (vantagem de MoE — só 3B ativos)
- Mistral Small 24B Q4 — ~40–60 t/s
Cenários reais de produção neste tier:
- Desenvolvedor solo rodando um assistente de código privado (Devstral 24B ou Qwen 3.6 35B-A3B).
- RAG interno de time pequeno sobre documentos da empresa (Llama 3.3 70B Q4).
- Protótipo de startup antes de mover para hardware de produção.
- Workflows agênticos locais para power users (Gemma 4 9B com tool calling).
Tier 2 — Workstation multi-GPU de consumo
| Hardware | VRAM | O que roda | Uso realista |
|---|---|---|---|
| 2× RTX 4090 (paralelismo de tensores em vLLM) | 48 GB | Llama 3.3 70B FP8, Qwen 3.6 35B-A3B FP16 | Servir em produção para time pequeno, experimentos de fine-tuning |
| 2× RTX 5090 | 64 GB | 70B em FP16, Llama 4 Scout em INT4 | Servir local sério, deploy MoE de tier médio |
| 4× RTX 4090 / 5090 | 96–128 GB | Llama 4 Scout em FP8/FP16, Qwen 3.5 122B-A10B em INT4 | Produção mono-tenant para ferramenta interna |
Aviso: GPUs de consumo não são projetadas para carga sustentada 24/7. Refrigeração e energia viram problemas reais de engenharia. Para qualquer coisa além de uma única workstation, considere GPUs de datacenter.
Cenários reais de produção:
- Tooling de IA interno para SaaS médio de ~50–200 funcionários.
- Fine-tuning de um modelo 70B com LoRA / QLoRA.
- Servidor de inferência interno para um time de engenharia de 5–20 pessoas.
Tier 3 — Apple Silicon (MLX / Metal)
Onde a Apple é genuinamente competitiva — e onde a maioria entende errado o trade-off.
A vantagem: memória unificada. Um Mac Studio com 256GB de memória unificada consegue sustentar modelos que de outra forma exigiriam 4–8× H100s — a uma fração do preço (~$10K USD para o Mac vs $80K+ USD para o equivalente em GPU). Importante para o Brasil e LATAM onde importar Macs é mais barato e rápido que importar GPUs de datacenter NVIDIA — Macs entram pelo regime tradicional de importação de eletrônicos enquanto GPUs de datacenter passam por classificações fiscais piores.
A pegadinha: menor throughput por request. Os cores de GPU da Apple têm FLOPS bruto menor que NVIDIA de datacenter, e o stack de software de inferência (MLX, llama.cpp Metal backend) ainda não iguala as otimizações do CUDA (variantes de FlashAttention, aceleração FP8, batching avançado).
| Hardware | Memória unificada | O que roda confortável (INT4) | Uso realista |
|---|---|---|---|
| MacBook Pro M4 Max 36GB | 36 GB | Até ~50B denso, Qwen 3.6 35B-A3B | Assistente de código de desenvolvedor solo |
| MacBook Pro M4 Max 64GB | 64 GB | Llama 3.3 70B Q4, Qwen 3.5 122B-A10B Q4 | Power user, demos, avaliação de modelos |
| Mac Studio M3 Ultra 96GB | 96 GB | Llama 3.3 70B FP8, Llama 4 Scout INT4 | Single-user pesado, assistente compartilhado em escritório pequeno |
| Mac Studio M3 Ultra 192GB | 192 GB | Llama 4 Scout FP8, Llama 4 Maverick INT4, DeepSeek V4-Flash INT4 | Inferência de MoE fronteira para um único usuário |
| Mac Studio M4 Ultra 256–512GB | 256+ GB | DeepSeek V4-Flash FP8, Kimi K2.6 INT4 nativo, V4-Pro com quantização forte | Inferência fronteira local séria; a máquina de manchete “rodando modelos de 1T localmente” |
Exemplos de throughput (Mac Studio M3 Ultra, benchmarks reais):
- Llama 3.3 70B Q4 — ~10–15 t/s (vs 20–35 na 4090, mas o Mac monta modelos muito maiores)
- Qwen 3.6 35B-A3B Q4 — ~25–40 t/s; MLX roda aproximadamente 2× mais rápido que Ollama no mesmo modelo — vale a pena saber
- Kimi K2.6 INT4 nativo — t/s de um dígito mas roda, que é o ponto
- DeepSeek V4-Flash INT4 — ~5–10 t/s em máquinas de 192GB+
MLX vs llama.cpp em Apple Silicon: MLX (o framework nativo da Apple) dá o melhor desempenho para muitos modelos — até 2× sobre llama.cpp Metal em Qwen 3.6 35B-A3B em benchmarks publicados. llama.cpp tem suporte mais amplo de modelos. A maioria das pessoas acaba usando os dois dependendo do modelo.
Cenários reais de produção:
- Desenvolvedor solo ou time pequeno rodando Llama 3.3 70B ou Qwen 3.6 35B-A3B localmente para trabalho diário de código — a melhor relação preço/desempenho para esse caso de uso em 2026.
- Pesquisador avaliando modelos abertos fronteira sem acesso a datacenter.
- Consultoria pequena dando demos in loco de modelos grandes para clientes que exigem ver o modelo rodar fora da nuvem.
- Power user focado em privacidade rodando um modelo fronteira completamente offline.
- O Mac Studio de 256GB+ especificamente para “demonstrar Kimi K2.6 ou DeepSeek V4-Flash em uma única máquina.”
Para o que MLX NÃO serve: servir alta concorrência. Se você precisa servir mais de ~5 usuários concorrentes, NVIDIA ganha decisivamente.
Tier 4 — GPU única de datacenter
| Hardware | VRAM | O que roda (FP16) | Características de throughput |
|---|---|---|---|
| A100 80GB | 80 GB | Llama 3.3 70B FP16, Mistral Large denso, Qwen 3.6 35B-A3B com contexto enorme | Cavalo de batalha confiável; ~2× mais lento que H100 mas mais barato |
| H100 80GB | 80 GB | Igual à A100 + suporte FP8 nativo; Llama 4 Scout INT4 | Padrão de produção para modelos classe 70B |
| H200 141GB | 141 GB | Llama 4 Scout FP16, Qwen 3.5 122B-A10B FP16, contextos muito longos | Melhor GPU única para MoE classe 100B |
| B200 (Blackwell) | 192 GB | DeepSeek V4-Flash INT4, modelos MoE maiores | Tier topo atual; salto grande de throughput sobre H100 |
Cenários reais de produção:
- Servir em produção para SaaS com centenas a milhares de usuários (vLLM + Llama 70B em H100).
- Pipeline de processamento em batch (extrair dados estruturados de milhões de documentos).
- Plataforma de IA interna corporativa servindo milhares de funcionários.
- Fine-tuning de modelos 7B–13B em precisão completa; LoRA em 70B.
Custo realista no Brasil: Na nuvem — $2–5 USD/hora dependendo do provedor. AWS São Paulo tende a custar 20–30% mais que us-east. Para workloads sensíveis à latência ou que processam dados de cidadãos brasileiros, vale a região local mesmo com o premium. On-prem H100 — ~$25–40K USD por GPU mais o servidor, sem contar impostos de importação que podem chegar a ~80–100% do valor declarado dependendo da classificação fiscal.
Tier 5 — Cluster multi-GPU de datacenter
| Configuração | VRAM total | O que roda | Caso de uso |
|---|---|---|---|
| 4× H100 / 2× H200 | 320–280 GB | Kimi K2.6 INT4 nativo, DeepSeek V4-Flash FP8, Llama 4 Maverick INT4 | A nova linha base de “modelo aberto fronteira” em 2026 |
| 8× H100 (um nó DGX) | 640 GB | Llama 4 Maverick FP8, DeepSeek V4-Flash FP16, Kimi K2.6 FP8 | Configuração padrão para “modelo aberto fronteira em produção” |
| 8× H200 | 1.1 TB | DeepSeek V4-Pro INT8, Kimi K2.6 FP16 | Servir MoE fronteira com qualidade máxima |
| 16× H100+ (multi-nó, InfiniBand) | 1.3 TB+ | DeepSeek V4-Pro FP16, servir fronteira com contexto muito longo | Servir hiperescala, provedores de modelos |
Cenários reais de produção:
- Auto-hospedar DeepSeek V4 para uma empresa regulada (banco, hospital, governo).
- Startup servindo um modelo aberto fronteira como seu próprio produto API.
- Plataforma de IA multi-tenant com milhares de usuários concorrentes.
- Laboratório de pesquisa rodando inferência fronteira + experimentos de fine-tuning.
Parte 4 — Matriz rápida de decisão
| Se a sua situação é… | Escolha este modelo | Neste hardware |
|---|---|---|
| Dev solo, quer assistente de código | Qwen 3.6 35B-A3B ou Devstral 24B | RTX 4090 / Mac M4 Max 36GB+ |
| Time pequeno, RAG interno sobre documentos | Llama 3.3 70B (Q4) | RTX 4090 / Mac Studio 96GB / H100 na nuvem |
| SaaS médio, precisa auto-hospedar features de IA | Llama 3.3 70B ou Qwen 3.6 35B-A3B | 1× H100 com vLLM |
| Empresa com requisitos de soberania de dados (LGPD) | Mistral Small / Medium ou Qwen 3.6 35B-A3B | 1× H100 ou 2× RTX 5090, datacenter local |
| Produto multilíngue (BR + LATAM + Ásia) | Família Qwen 3.5 / 3.6 | Dimensionado ao seu tráfego |
| Qualidade open fronteira, indústria regulada (banco/saúde/governo) | DeepSeek V4-Pro | Cluster 8× H200 |
| Agente de programação fronteira auto-hospedado | Kimi K2.6 (INT4 nativo) | 4× H100 ou 2× H200 |
| Produto open de programação agêntica (startup) | Kimi K2.6 ou DeepSeek V4-Flash | Single H100 DGX ou provedor hosted |
| Pesquisa de raciocínio/matemática | DeepSeek R1 ou V4-Pro | 8× H100 / H200 |
| Agente local com tool calling com orçamento apertado | Gemma 4 9B | RTX 4070 Ti / Mac M3 Pro |
| Visão + texto em hardware de consumo | Gemma 4 9B (visão) ou Llama 4 Scout | RTX 4090 / Mac M4 Max |
| Modelo fronteira em uma única máquina para uso pessoal | Kimi K2.6 (INT4 nativo) ou DeepSeek V4-Flash | Mac Studio M4 Ultra 256GB+ |
| Espremer máximo throughput de hardware NVIDIA | Variantes Nemotron | H100/H200/B200 com TensorRT-LLM |
| Contexto longo (>1M tokens) | Llama 4 Scout (10M) ou DeepSeek V4 (1M) | Dimensionado ao modelo |
Parte 5 — Três padrões que vale internalizar
1. MoE é para servir, denso é para caber. Rodando um usuário em uma máquina? Modelos densos te dão mais qualidade por GB de memória. Servindo muitos usuários? MoE ganha porque a quantidade de parâmetros ativos define seu custo por token enquanto a quantidade de parâmetros totais define sua conta única de memória.
2. O Mac Studio é real, mas só para inferência de modelos grandes com um único usuário. Um Mac Studio de 256GB roda modelos que custariam $80K+ USD em hardware NVIDIA, em velocidades de um único usuário. Genuinamente útil para desenvolvedores solo, pesquisadores, consultorias pequenas. Especialmente relevante no Brasil e LATAM onde o custo e dificuldade de importar GPUs de datacenter NVIDIA fazem do Mac uma alternativa prática séria. Não é plataforma para servir em produção — para isso, NVIDIA ganha em throughput, batching e maturidade de software. Use MLX em vez de llama.cpp quando ambos suportarem o modelo — speedups mensuráveis de 2× em 2026.
3. A quantização nativa muda a matemática do deploy. Kimi K2.6 sai em INT4 nativo. DeepSeek V4 sai em mistura FP8 + FP4. Isso é uma mudança importante em relação ao mundo antigo onde quantização sempre era um trade-off de qualidade-vs-caber. Para modelos com quantização nativa, INT4 é o deploy pretendido — você não está abrindo mão de nada. Espere mais modelos seguindo esse padrão ao longo de 2026.
Reflexão final
Pesos abertos em 2026 cobrem todo o espectro de qualidade. Não existe mais capacidade fronteira disponível só por trás de uma API fechada — DeepSeek V4-Pro, Kimi K2.6, e Qwen 3.6 Max estão todos a uma distância de golpe de GPT-5 e Claude Opus nos benchmarks que importam para trabalho de produção. A pergunta real de engenharia já não é “aberto vs fechado” — é “qual modelo aberto, em qual quantização, em qual hardware, para qual workload.” Os números deste guia devem te dar o suficiente para tomar essa decisão sem chutar.
Para o Brasil e LATAM especificamente, o caso de auto-hospedar modelos open-weights é ainda mais forte que em outras regiões: regulamentação de soberania de dados em cada país (LGPD no Brasil, Ley 1581 na Colômbia, LFPDPPP no México, Ley 25.326 na Argentina), volatilidade cambial que torna imprevisíveis os custos em USD das APIs (especialmente sentida no Brasil e Argentina), e latência a partir de datacenters norte-americanos que importa para experiências de usuário sensíveis. A estratégia vencedora típica é: começar em API para validar produto, mover o volume sustentado para auto-hospedagem assim que o gasto mensal justificar o investimento — e quando o volume justificar on-prem, considerar seriamente a economia tributária de processar tudo localmente em vez de pagar APIs em dólar.
O ritmo vai continuar. Espere outra onda grande de lançamentos para o final do Q3 2026 — provavelmente DeepSeek V4.x, Qwen 4 e um refresh de Llama 4.x. Os padrões arquiteturais — economia de MoE, trade-offs de quantização, MLX vs CUDA, matriz de dimensionamento-para-hardware — não vão mudar. Construa seu sistema em torno dos padrões, não dos nomes dos modelos.
