Como escolher tamanho de modelo de IA certo (2026)

TL;DR

Tamanho de modelo de IA é decisão de engenharia, não de marketing. Esta é a pergunta que define o regime de produção: qual o melhor custo por chamada por classe de tarefa, dado o regime de pós-treinamento disponível.

• O tamanho de modelo de IA é a variável mais mal calibrada do vocabulário técnico em 2026: 10× parâmetros raramente entrega 10× capacidade útil.
• Modelos MoE (como Mixtral 8x7B, 47B totais mas ~13B ativos por token) provam que parâmetros totais e parâmetros ativos são duas métricas distintas.
• Pós-treinamento (SFT, RLHF, DPO) explica mais do que escala bruta: Phi-3 mini com 3.8B bate Llama 2 70B em raciocínio estruturado.
• Distillation e quantização 4-bit transformaram 7B em produção viável; o caso Posseidom mostra 7B local substituindo API 70B em extração e classificação.
• A decisão certa é por tarefa, latência, custo, privacidade e observabilidade. A cascata de modelos é a resposta operacional para quem não pode pagar 70B em toda chamada.

~ 14 min de leitura · 2408 palavras

O número de parâmetros é a variável mais visível e a mais mal interpretada

A escolha de tamanho de modelo de IA começa pela régua que se está usando: capacidade observada ou contagem publicada.

A lâmina 6 do deck *Right Sizing AI Models* abre com a matriz que falta em quase toda conversa sobre LLM: a relação entre capacidade observada e parâmetros publicados não é linear, não é monotônica, e em vários regimes é decrescente. O eixo horizontal é o número de parâmetros; o vertical, a nota em benchmarks de raciocínio estruturado. A nuvem de pontos forma três arquipélagos: o cluster dos 3B-8B pós-treinados (Phi-3, Qwen2.5-7B-Instruct, Mistral-7B-Instruct-v0.3), o cluster dos 30B-70B generalistas (Llama 3.1 70B, Qwen2.5-32B, Command-R-plus), e o cluster dos 200B+ com raciocínio multi-step forte (Llama 3.1 405B, DeepSeek V3, GPT-4o). Entre um cluster e outro há saltos de capacidade. Dentro de cada cluster, somar parâmetros rende retornos marginais decrescentes. A escolha de tamanho de modelo de IA em produção raramente cabe na curva teórica: o que conta é o regime de pós-treinamento. Esse padrão é o que torna a escolha de tamanho de modelo de IA uma decisão de custo, não de capacidade. Tamanho de modelo de IA aqui é função do regime, não da régua.

Três consequências operacionais saem direto da lâmina:

• A unidade de comparação não é “B” (bilhões de parâmetros); é cluster de regime de treinamento (dados, pós-treinamento, arquitetura).
• Comparar 7B com 70B faz sentido se forem regimes equivalentes; comparar 7B destilado de 70B com 70B sem fine-tune é comparar 7B consigo mesmo.
• A pergunta de engenharia não é “qual é o maior modelo que cabe no orçamento”, e sim “qual é o regime de treinamento que cobre a classe de tarefa com o menor custo marginal por chamada”.

A confusão entre essas duas perguntas explica por que a maior parte das avaliações internas em empresas brasileiras começa com “vamos testar o modelo de 400B” e termina com “para esta tarefa o 7B é melhor e custa 1%”. Marketing de fornecedor empurra o número grande; engenharia puxa para a curva de capacidade real.

Por que tamanho de modelo de IA 10× maior ≠ 10× mais capaz: a curva de escala tem regime

Tamanho de modelo de IA segue uma curva de retornos decrescentes fora do regime super-crítico.

A lâmina 11 do deck desenha a curva de retornos de escala observada em modelos de linguagem entre 2018 e 2026. O comportamento divide-se em três regimes:

• Regime sub-crítico (<2B): capacidade cresce com escala, mas em tarefas narrow (classificação binária, extração estruturada de campos) a curva achata cedo. Um 1.3B bem treinado empata com 7B genérico nessas tarefas.
• Regime intermediário (2B-70B): capacidade cresce quase logaritmicamente com parâmetros. Dobrar o modelo entrega 5-10% de capacidade adicional em benchmarks médios, com 2× o custo de inferência.
• Regime super-crítico (>70B): começam a emergir habilidades de raciocínio multi-step que não existiam em escala menor. Aqui o retorno sobre escala é alto, mas o custo marginal por token também — e a maioria das tarefas de produção não exige raciocínio multi-step.

A confusão clássica: tratar 70B como “10× melhor que 7B” porque o número é 10×. A régua real para 90% das tarefas de produção (extração, classificação, sumarização curta, geração de código boilerplate) é capacidade de 2B-7B pós-treinados. A regra de 70B só se aplica quando a tarefa exige raciocínio multi-step genuíno — o que é raro em sistemas em produção que precisam de respostas determinísticas por chamada, não de demonstrações de raciocínio aberto. Quando o tamanho de modelo de IA está superdimensionado para a tarefa, o custo sobe sem ganho de qualidade.

#Setup ollama pull para o regime "tarefa narrow"
ollama pull qwen2.5:7b-instruct-q4_K_M
ollama pull phi3:mini-4k-instruct-q4_K_M
ollama pull mistral:7b-instruct-q4_K_M

A escolha entre esses três 7B não é pelo tamanho — é pelo regime de pós-treinamento. Qwen2.5-7B-Instruct tem SFT e DPO fortes para tarefas estruturadas em PT-BR; Phi-3 mini tem 3.8B mas raciocínio estruturado acima de Llama 2 70B; Mistral-7B-Instruct-v0.3 equilibra os dois. Cada um vence em um regime de tarefa. Comparar o “melhor 7B” com “qualquer 70B” faz sentido; comparar “qualquer 7B” com “qualquer 70B” não diz nada. Tamanho de modelo de IA é função do regime de pós-treinamento.

MoE separou o jogo: parâmetros totais não são parâmetros ativos

Tamanho de modelo de IA em MoE é regido pelos parâmetros ativos por token, não pelos totais.

A lâmina 9 do deck expõe a distinção que mais decisões de arquitetura desconsideram: parâmetros totais ≠ parâmetros ativos por token. O exemplo canônico é Mixtral 8x7B (Mistral AI, dez/2023): 47B parâmetros totais, mas apenas ~13B ativos por token, selecionados por uma rede de roteamento. O custo de inferência é proporcional aos ativos, não aos totais.

Três pontos que a arquitetura MoE quebra — e que mudam o que tamanho de modelo de IA significa na prática:

• Custo de inferência é regido por ativos. Mixtral 8x7B cobra como um 13B, não como um 47B. Em regime de produção, a conta é tokens-processados-por-segundo, não peso-em-memória.
• Capacidade de conhecimento é regida por totais. As 8 sub-redes especialistas cobrem domínios diferentes. O “conhecimento total” do Mixtral 8x7B é de 47B; ele sabe mais do que um 13B denso, mas cobra como 13B.
• A régua de “B” do fornecedor virou ambígua. Dizer “modelo 47B” sem distinguir denso de esparso é a mesma categoria de erro de dizer “cluster de 64 vCPUs” sem distinguir se está ocioso ou saturado.

Mixtral 8x7B vence Llama 2 70B em vários benchmarks de raciocínio narrow com 4× menos custo de inferência. Em tarefas de conhecimento geral amplo (resposta a perguntas sobre eventos recentes, sumarização de textos longos com referências cruzadas), o 70B denso ainda vence — porque exige recall de todo o conhecimento, não apenas raciocínio sobre um subconjunto. Em produção, isso define o tamanho de modelo de IA mínimo viável para essa classe — abaixo desse tamanho de modelo de IA, a qualidade cai abaixo do aceitável. (resposta a perguntas sobre eventos recentes, summarização de textos longos com referências cruzadas), o 70B denso ainda vence — porque exige recall de todo o conhecimento, não apenas raciocínio sobre um subconjunto.

A implicação operacional: a próxima decisão de tamanho de modelo de IA precisa começar por essa pergunta — denso ou MoE, quantos ativos, qual regime. A escolha de tamanho de modelo de IA sem essa triagem é chute. a próxima vez que alguém disser “vamos usar o 70B porque é maior”, a primeira pergunta a fazer é “ele é denso ou MoE? Quantos ativos por token? Em qual regime de tarefa?”. Sem essa resposta, a comparação de tamanhos é ruído.

Dados e pós-treinamento explicam mais que a escala

A composição de pós-treinamento pesa mais na régua de tamanho de modelo de IA do que o número bruto.

A lâmina 11 lista cinco critérios de decisão de modelo. O quarto é qualidade do pós-treinamento: SFT (supervised fine-tuning), RLHF (reinforcement learning from human feedback), DPO (direct preference optimization). Esses três estágios é que transformam um modelo base de 7B em um assistente de produção. Sem eles, 7B é um completador de texto; com eles, 7B é uma ferramenta que recusa prompt malicioso, segue formato JSON estável e responde com a persona definida pelo time.

O caso empírico mais forte em 2024 foi o Phi-3 mini (Microsoft, abr/2024): 3.8B parâmetros, pós-treinamento pesado em dados sintéticos de alta qualidade, bateu Llama 2 70B em benchmarks de raciocínio estruturado (MMLU subset, GSM-8K, HumanEval). O efeito do pós-treinamento foi equivalente a ~20× de escala bruta. Park et al. (IEEE 2024) demonstraram em “Stronger Models are NOT Stronger Teachers” que distillation de modelos menores, pós-treinados, é mais eficiente do que distillation de modelos maiores sem pós-treinamento. Aluno bom não é definido pelo tamanho do professor; é definido pela qualidade do sinal que o professor transmite.

A implicação prática para times que operam em produção:

• Não comparar base models. Comparar o Llama 3.1 8B-Instruct com o Llama 3.1 70B-Instruct compara regimes de pós-treinamento. Comparar o Llama 3.1 8B-Base com o Mixtral 8x7B-Instruct compara um modelo base com um modelo pós-treinado — categorias diferentes.
• Auditar o pipeline de pós-treinamento do modelo candidato. Quantos ciclos de RLHF? Tem DPO? O dataset de SFT é dedicado ou genérico? A resposta muda a régua.
• Distillation de modelo próprio é viável a partir de 50-100k exemplos de produção. É o caminho para um 7B que supera um 70B genérico no domínio do time.

Distillation e quantização 4-bit democratizaram o 7B

Tamanho de modelo de IA 7B destilado é competitivo em produção para tarefas narrow com 50k+ exemplos.

A lâmina 14 do deck mostra o fluxograma de engenharia que o Posseidom adotou para tarefas internas: classificação de tickets, extração de campos de NF-e, sumarização de logs. O fluxo é: tarefa narrow → 7B destilado do modelo de produção do fornecedor (Qwen2.5 32B Instruct como professor) → quantização 4-bit via GGUF ou AWQ → deployed em máquina on-prem com GPU A-class única (RTX 4090 ou similar) → exposto via API local.

Os números que o Posseidom reportou (caso real, sem identificação específica) (caso real, sem identificação específica): latência p50 de 180ms por chamada em extração de NF-e com 7B quantizado 4-bit, contra 850ms da API 70B remota; custo de inferência local de ~$0.00003 por chamada, contra ~$0.0025 da API. O ponto de virada não foi desempenho — foi privacidade: NF-e contém dados fiscais e CPF/CNPJ que a LGPD classifica como sensíveis. Manter a chamada dentro do datacenter da empresa eliminou o risco contratual com o fornecedor de API.

A condição para o 7B funcionar é tarefa narrow com dataset de distillation. O tamanho de modelo de IA certo aqui é função direta do tipo de saída esperada. Em extração de campos, a saída é JSON estável com ~10 chaves; o 7B destilado nesse padrão erra menos de 1% das chamadas após 30k exemplos de treino. Em geração aberta, o mesmo 7B perde feio para o 70B. A escolha não é entre “7B” e “70B”; é entre “tarefa narrow, dado de distillation, 7B local” e “tarefa aberta, sem dado, 70B remoto”.

#Trecho de pipeline de distillation de Qwen2.5 32B para 7B local
Nao execute sem revisar a task inteira
from transformers import AutoModelForCausalLM, AutoTokenizer
import torch

teacher = "Qwen/Qwen2.5-32B-Instruct"
student_base = "Qwen/Qwen2.5-7B-Instruct"

Etapa 1 - gerar dataset de distillation: 50k pares (prompt, resposta_teacher)
Etapa 2 - SFT do student_base sobre o dataset
Etapa 3 - aplicar AWQ ou GGUF q4_K_M para quantizacao
Etapa 4 - deploy via ollama ou vLLM local

Os 5 critérios de decisão: tarefa, latência, custo, privacidade, observabilidade

Esses cinco critérios é que definem o tamanho de modelo de IA final escolhido para cada classe.

A lâmina 11 resume os cinco critérios que se aplicam antes de qualquer comparação de benchmark:

• Classe de tarefa. Narrow (extração, classificação, sumarização curta, JSON estável) ou aberta (raciocínio multi-step, geração criativa, planejamento)? Narrow → 2B-7B. Aberta → 30B-70B+ ou API.
• Latência aceitável. p50 ≤ 200ms em UX conversacional exige 7B quantizado local ou API 70B com cache agressivo. p50 ≤ 2s permite 70B remoto. p50 ≤ 10s permite 400B remoto com reasoning mode.
• Custo por chamada. Custo marginal define o break-even entre 7B local (capex + opex baixo) e 70B remoto (opex variável). Em volume alto (≥ 1M chamadas/mês), local ganha; em volume baixo, remoto ganha.
• Privacidade e residência de dados. LGPD, dados fiscais, dados de saúde, dados de clientes B2B com NDA → inferência local é frequentemente obrigatória, não opcional. API remota exige contrato robusto e DPA assinado.
• Observabilidade. Quem opera o sistema precisa ver qual tamanho de modelo de IA respondeu cada chamada, em qual latência, com qual score de confiança. Modelo local permite log de prompts, completions e métricas em stack própria (Langfuse, Phoenix, Helicone self-hosted). Modelo remoto depende do que o fornecedor expõe — frequentemente, apenas contadores de uso.

A cascata é o que organiza a decisão. Não existe “o melhor modelo”; existe a melhor sequência de modelos para a classe de tarefa, atualizada a cada release de fornecedor. Tamanho de modelo de IA aqui é função da tarefa, não da régua do fornecedor. A lâmina 9 do deck apresenta a estratégia de cascata como padrão: 7B local tenta primeiro; em falha de confiança (logprob < threshold) ou rejeição de formato, escala para 32B remoto; em raciocínio multi-step genuíno, escala para 200B+. O custo médio ponderado desce 60-80% em relação a "tudo via 70B", e a latência p50 também — porque a maioria das chamadas resolve no 7B.

A cascata de modelos como estratégia de produção

A cascata é a operacionalização do tamanho de modelo de IA certo por classe de tarefa.

O fluxo de engenharia da lâmina 14 transforma o critério em pipeline:

1. Entrada do usuário chega com classe de tarefa classificada (narrow, semi-aberta, aberta). Classificador leve (até 1B) decide o regime. 2. Modelo local 7B tenta resolver. Se score de confiança > 0.85 e formato validado, responde. 3. Escalonamento para 32B-70B remoto ocorre em score de confiança entre 0.5 e 0.85, ou em formato inválido. 4. Escalonamento para 200B+ ocorre em raciocínio multi-step explícito (palavras-chave: “explique passo a passo”, “compare”, “analise”), ou em score de confiança < 0.5. 5. Log de toda a cascata alimenta dataset de distillation para o 7B local na próxima sprint. O regime narrow migra do remoto para o local ao longo de meses; tamanho de modelo de IA vira então decisão de arquitetura, não de compra. o custo médio desce continuamente.

A cascata não é novidade conceitual. É a aplicação de mixture-of-experts em tempo de inferência no nível de produto, com o especialista sendo o modelo, não a sub-rede. O que a torna viável em 2026 é a maturidade dos modelos 7B pós-treinados e a queda do custo de inferência local por chamada eles resolvem narrow o suficiente para a cascata pagar o custo do escalonamento seletivo.

A escolha do tamanho de modelo de IA, em produção, deixa de ser decisão de compra e vira decisão de arquitetura de pipeline. O critério de aceitação de uma cascata não é qual tamanho venceu; é quantas chamadas resolveram no nível mais barato com qualidade aceitável. O próximo gargalo não é qual modelo escolher — é medir a qualidade da cascata antes de ir para produção.

—

Leitura relacionada

• Token não é palavra — unidade de medida base.
• Iteração com IA: 5 práticas — loop prompt↔resposta.
• Tamanho de modelo de IA — pré-requisito.