Como escolher, dimensionar e fazer deploy de modelos de pesos abertos em produção: qual modelo para qual tarefa, de qual tamanho, e em qual hardware — cobrindo CUDA e MLX.
Atualizado em maio de 2026 — reflete a onda de lançamentos de abril 2026 (DeepSeek V4, Qwen 3.6, Kimi K2.6).
Por que só modelos open-weights
APIs fechadas são fáceis. Você paga a conta, recebe a resposta. A engenharia interessante — e onde está a maior parte dos mal-entendidos — está do lado dos pesos abertos, onde você realmente precisa pensar em quantidade de parâmetros, arquitetura MoE, quantização, VRAM, e se o seu Mac Studio realmente roda aquele modelo de 1.6T que alguém tuitou.
Este guia cobre só modelos de pesos abertos. Todos os modelos descritos abaixo podem ser baixados, rodados no seu próprio hardware e enviados dentro de um produto sem pagar por token. A contrapartida é que você precisa entender o hardware. É disso que trata a maior parte deste guia.
Uma nota sobre atualidade: a fronteira de open-weights se move rápido — três dos modelos mais importantes deste guia (DeepSeek V4, Qwen 3.6, Kimi K2.6) saíram dentro de uma única janela de 30 dias em abril 2026. Os números de versão específicos vão continuar mudando. Os padrões arquiteturais e o dimensionamento de hardware não.
Parte 1 — Os modelos open-weights que importam em 2026
Existem aproximadamente 7 famílias de modelos que valem a pena conhecer para trabalho de produção real. Qualquer coisa que não esteja nesta lista é um artefato de pesquisa ou uma variante menor de uma destas.
DeepSeek — Família V4 (lançada em 24 de abril de 2026)
DeepSeek V4 é a fronteira atual de open-weights. Duas variantes lançadas simultaneamente, ambas sob licença MIT, ambas com contexto de 1M de tokens. A mudança arquitetural principal é a atenção híbrida CSA + HCA (Compressed Sparse Attention + Heavily Compressed Attention), que reduz os FLOPs de inferência para ~27% do V3.2 e a ocupação de KV cache para ~10% em contextos de 1M.
Tamanhos que você realmente usa:
- DeepSeek V4-Pro (MoE, 49B ativos / 1.6T totais) — classe fronteira, compete com Claude Opus e GPT-5 em código e raciocínio.
- DeepSeek V4-Flash (MoE, 13B ativos / 284B totais) — rápido, eficiente, executável em uma configuração multi-GPU que a maioria dos times consegue bancar.
- DeepSeek R1 (ainda mantido, MoE 37B/671B) — predecessor afinado para raciocínio; ainda relevante se você já está deployado nele ou quer uma opção de raciocínio fronteira menor.
Licença: MIT. Tão limpa quanto pode ser.
Casos de uso reais:
- “GPT-5 privado” auto-hospedado para uma empresa regulada — um banco grande (Itaú, Bradesco, Santander Brasil), uma operadora de saúde sujeita à LGPD, uma fintech sob regulação do BACEN, ou um órgão público sujeito a soberania de dados. V4-Pro em 8× H200 num datacenter privado é a resposta padrão em 2026 quando você não pode mandar dados para APIs fechadas mas precisa de qualidade fronteira.
- Pipeline de revisão de código em alto volume. V4-Flash processa pull requests, code review, sugestões de refatoração, ferramentas de migração automatizada. Com 13B parâmetros ativos, o throughput por GPU é excelente e o custo por token é desprezível depois do hardware.
- Análise de documentos longos em escalas que há seis meses só eram possíveis via API. O contexto de 1M do V4 com o novo mecanismo de atenção realmente funciona em ranges longos (o KV cache não explode). Útil para due diligence jurídica, revisão de literatura científica, análise de bases de código completas.
- Inferência barata via API da DeepSeek se você não quer auto-hospedar. V4-Flash a $0.14/M de tokens de entrada é ~18× mais barato que o flagship do GPT-5 e bom o suficiente para a maior parte do trabalho de produção.
- Base fronteira para fine-tunes proprietários. A licença MIT torna o fine-tuning comercial juridicamente limpo — importante para SaaS verticais que querem construir um modelo defensável em cima de uma base aberta.
Realidade de hardware: V4-Pro em precisão completa precisa de um cluster de 8× H100/H200. V4-Flash entra confortável em 2–4× H100 em FP8, ou um Mac Studio top de linha com quantização forte para inferência de um único usuário. A maioria dos times vai usar V4-Pro via API e auto-hospedar V4-Flash se precisar de controle.
Moonshot — Kimi K2.6 (lançado em abril 2026)
Kimi K2.6 é o modelo open-weights mais forte para programação em meados de 2026 — topo de cada benchmark relevante para tarefas de programação autônoma de longo horizonte. INT4 QAT nativo (treinamento consciente de quantização), o que significa que ele é especificamente construído para rodar quantizado sem perda de qualidade. Inclui capacidade de “agent swarm” — pode orquestrar até 300 sub-agentes em paralelo.
Tamanhos que você realmente usa:
- Kimi K2.6 (MoE, 32B ativos / 1T totais) — INT4 nativo, capacidade de visão, contexto de 256K.
- Kimi K2.5 (predecessor) — ainda amplamente deployado, mais barato de hospedar.
Licença: MIT Modificada (livre para quase todo uso comercial; atribuição obrigatória acima de 100M MAU ou $20M de receita mensal).
Casos de uso reais:
- Produtos de programação agêntica em produção (alternativas open-source a Cursor / Devin). K2.6 é o modelo por trás de vários deles em 2026. Economia competitiva contra APIs fechadas para startups de IA com aporte de VC.
- Code review e análise de PR auto-hospedado sobre bases de código corporativas. A quantização INT4 nativa é crítica aqui — você obtém qualidade de programação fronteira com materialmente menos hardware do que o V4-Pro exige.
- Tarefas autônomas de longo horizonte — a Moonshot demonstrou K2.6 executando 4.000+ chamadas a ferramentas ao longo de 12+ horas para completar um projeto real de engenharia. Útil para trabalho agêntico noturno em batch (migrações de bases de código, refactors em larga escala, geração de documentação).
- Bases de código poliglotas (Rust + Go + Python + frontend + DevOps). K2.6 generaliza entre linguagens melhor que a maioria dos modelos especializados em código, que tendem a ser muito focados em Python.
- Apps onde fazer deploy de capacidade fronteira de programação no seu próprio hardware é vantagem competitiva — software de defesa, sistemas de trading financeiro, firmware de dispositivos médicos. O código em si é a propriedade intelectual e não pode sair do prédio.
Realidade de hardware: O INT4 nativo significa que K2.6 é genuinamente deployável em 4× H100 ou 2× H200, o que é muito mais acessível que V4-Pro. Quantização forte roda num Mac Studio de 256GB para inferência de um único usuário.
Alibaba — Família Qwen 3.5 / 3.6
A família aberta mais completa. Cobre cada classe de tamanho desde sub-1B até flagships MoE de 1T. Qwen 3.5 (fevereiro 2026) foi o lançamento geracional principal; Qwen 3.6 (março-abril 2026) é o refresh focado em programação agêntica em cima. Ambas as linhas estão ativamente mantidas.
Tamanhos que você realmente usa (mix Qwen 3.5 / 3.6):
- Qwen 3.5 4B / 9B / 27B (denso) — todoterrenos fortes. O 9B especificamente faz 81.7 no GPQA Diamond, sem precedentes para modelos sub-30B.
- Qwen 3.6 27B (denso) — refresh do 27B com programação agêntica melhor.
- Qwen 3.6 35B-A3B (MoE, 3B ativos / 35B totais) — o ponto doce de throughput de todo o ecossistema open em 2026. Qualidade de 35B em velocidade de classe 3B.
- Qwen 3.5 122B-A10B (MoE, 10B ativos / 122B totais) — roda num Mac de 64GB.
- Qwen 3.5-397B-A17B flagship (MoE, 17B ativos / 397B totais) — classe fronteira.
- Qwen 3.6-Max-Preview — atualmente só API, não open-weight; mencionado só porque as derivadas open-weight do 3.6 fluem dele.
Licença: Apache 2.0 para tamanhos até ~30B; customizada (utilizável comercialmente) para os flagships maiores.
Casos de uso reais:
- Suporte multilíngue para produtos globais. Qwen lida com mandarim, japonês, coreano, indonésio, vietnamita, hindi, árabe, espanhol e português brasileiro em qualidade que Llama não consegue igualar. Para produtos brasileiros expandindo para LATAM (espanhol) e Ásia, Qwen é a escolha padrão.
- Backend de chat de alto throughput com orçamento de latência apertado. Qwen 3.6 35B-A3B serve 3–5× mais usuários concorrentes por GPU que alternativas densas de 30B porque só 3B parâmetros estão ativos por token. Melhor relação preço/desempenho para servir em produção em 2026.
- Programação agêntica local em Apple Silicon. Qwen 3.6 35B-A3B roda confortável num MacBook Pro M-series de 64GB via MLX. Essa combinação (MLX + 35B-A3B MoE) está virando o setup padrão de desenvolvedor solo.
- Deploy on-prem para empresas com requisitos de soberania de dados — pode rodar completamente desconectado da internet, atendendo a LGPD no Brasil, e às leis equivalentes no resto da LATAM (Ley 1581 na Colômbia, Ley 25.326 na Argentina, LFPDPPP no México).
- Base de fine-tuning para SaaS verticais. Os tamanhos Qwen 3.5 4B–14B são as bases de fine-tuning mais custo-eficientes do ecossistema — pequenas o suficiente para treinar numa única GPU, capazes o suficiente para mandar para produção.
- Deploy em edge. Os tamanhos Qwen 3.5 0.8B e 2B rodam em celulares e dispositivos IoT — útil para funcionalidades de IA offline em apps móveis.
Meta — Família Llama 4
A linha open mais suportada do mundo. Cada framework de inferência, biblioteca de fine-tuning e integração de ferramentas suporta Llama primeiro. Llama 4 introduziu MoE (Scout + Maverick) e multimodalidade nativa. Llama 3.3 70B continua sendo o cavalo de batalha denso; Llama 4 Behemoth (288B ativos / ~2T totais) foi anunciado como modelo professor mas não foi liberado como open-weights.
Tamanhos que você realmente usa:
- Llama 3.3 70B (denso) — ainda o 70B aberto mais deployado em produção.
- Llama 4 Scout (MoE, 17B ativos / 109B totais, 16 experts) — entra numa única H100 com quantização INT4, contexto de 10M tokens.
- Llama 4 Maverick (MoE, 17B ativos / 400B totais, 128 experts) — entra num único host H100 DGX (8× H100), contexto 1M, multimodal nativo.
Licença: Llama 4 Community License. Permissiva para a maioria dos usuários; exige licença especial acima de 700M MAU. Não disponível para empresas domiciliadas na UE no início de 2026 — vale verificar a licença atualizada antes de qualquer deploy cross-border a partir do Brasil para clientes europeus.
Casos de uso reais:
- Assistente interno de empresa treinado sobre seu wiki/documentação. Um fine-tune com LoRA de Llama 3.3 70B sobre documentação interna, servido via vLLM em uma única H100, dá a cada funcionário um equivalente privado do ChatGPT. O padrão de deploy de Llama mais comum em empresas de médio e grande porte no Brasil.
- RAG multimodal sobre bibliotecas de documentos (PDFs com diagramas, formulários escaneados, gráficos). A compreensão nativa de imagens do Llama 4 Scout + contexto de 10M lida com isso num único modelo. Caso típico no Brasil: arquivo histórico de atas notariais, prontuários médicos digitalizados, processos judiciais digitalizados pelo PJe.
- Workflows de documentos longos — análise de bases de código completas, processamento de documentos do tamanho de um livro, memória conversacional de múltiplas sessões. O contexto de 10M do Scout é genuinamente útil aqui.
- SaaS multi-tenant onde você precisa auto-hospedar. Llama é a opção aberta mais segura porque cada dependência que você precisaria (vLLM, TGI, Ollama, llama.cpp, MLX) suporta desde o dia zero.
- Times de fine-tuning que precisam de máximo suporte de bibliotecas. Llama é a base de fine-tuning mais documentada e suportada do ecossistema.
Mistral
O laboratório francês. Pragmático, bem licenciado, focado em código. Menos hype que DeepSeek ou Kimi, mais confiabilidade.
Tamanhos que você realmente usa:
- Mistral Small 3 (~24B denso) — eficiente, boa obediência a instruções.
- Mistral Medium / Large 3 — flagships densos e MoE classe fronteira.
- Codestral / Devstral — especializados em código; Devstral é afinado para programação agêntica multi-arquivo.
- Magistral (~24B raciocínio) — modelo aberto de raciocínio.
Licença: Apache 2.0 para a maioria dos lançamentos.
Casos de uso reais:
- Chatbot on-prem cumprindo regulamentação de proteção de dados — particularmente útil quando o cliente exige modelo de origem não-chinesa (alguns setores em defesa, banco e governo têm essa exigência explicitamente).
- Ferramenta de programação agêntica que edita múltiplos arquivos. Devstral foi feito especificamente para isso — é o modelo por trás de várias alternativas open-source ao Cursor.
- Backend de function-calling para features de produto. Os modelos Mistral são confiáveis para saída estruturada em JSON sem precisar de prompting exótico. Comum em features tipo “linguagem natural → consulta estruturada”.
- Processamento de documentos em português, espanhol, francês onde Mistral tem uma vantagem mensurável sobre Qwen em variantes europeias e algumas variantes latinas.
- Assistente de programação local barato em uma única GPU. Devstral 24B numa GPU de 24GB roda confortável e lida com tarefas reais de refatoração.
Google — Família Gemma
A resposta aberta da Google ao Llama e Qwen. Apache 2.0, tamanhos de ~1B a ~30B, com visão e tool calling na última geração.
Tamanhos que você realmente usa:
- Gemma 4 9B — modelo pequeno forte com visão + tool calling.
- Gemma 4 27B — denso de tamanho médio; boa obediência a instruções.
Licença: Apache 2.0.
Casos de uso reais:
- Agente local com tool calling em hardware modesto. Gemma 4 9B numa GPU de 16GB lida com function calling de forma confiável — bom para assistentes de desktop, extensões de browser, automação leve.
- Pipeline de extração de visão + texto sem pagar preços de API — ler screenshots, extrair dados de gráficos, processar formulários escaneados (usos típicos: digitalização de arquivos, automação de back-office em seguradoras, processamento de notas fiscais).
- Deploy em edge ou on-device para apps móveis, totens, dispositivos industriais. Gemma é a família aberta mais otimizada para isso.
- Apps onde Apache 2.0 é juridicamente exigida. Alguns processos de licitação pública e distribuições OSS exigem especificamente uma licença aprovada pela OSI. Gemma e Mistral são as opções mais limpas.
- Workloads em Google Cloud / Vertex AI onde Gemma tem suporte de infraestrutura de primeira classe.
NVIDIA — Família Nemotron
Os lançamentos abertos da NVIDIA, principalmente para mostrar o que o stack de treinamento e inferência deles consegue fazer. Vale considerar se você já está profundamente investido em CUDA/TensorRT/NeMo.
Tamanhos que você realmente usa:
- Nemotron Nano (~4B–9B) — raciocínio eficiente.
- Nemotron Cascade / Ultra — variantes MoE maiores afinadas para raciocínio.
Licença: Varia por lançamento; majoritariamente open-weight permissiva.
Casos de uso reais:
- Inferência em produção espremendo cada token/seg de H100/H200/B200. Nemotron é codesenhado com TensorRT-LLM e dá throughput mensuravelmente melhor que Llama/Qwen equivalente no mesmo hardware NVIDIA.
- Workloads de raciocínio em NVIDIA NIM microservices — se seu time de plataforma padronizou em NIM, Nemotron é o caminho de menor resistência.
- Times de fine-tuning que já usam NVIDIA NeMo. Ficar dentro de um único toolchain vale muito operacionalmente.
Parte 2 — 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.
