Três faixas de tamanho
Modelo de linguagem não é uma categoria única. Tem rede com algumas centenas de milhões de parâmetros rodando no celular, modelo de 7B a 70B servindo a maior parte dos produtos em produção, e família com centenas de bilhões de parâmetros para tarefa difícil.
Na conversa, tudo vira "LLM". Time de produto pede GPT-4 para classificar e-mail. Engenheiro sobe um 405B para extrair CPF de PDF. O custo sobe, a latência estoura, e o ganho de qualidade é marginal.
Escolher escala é escolher trade-off: capacidade de raciocínio, custo por token, tempo de resposta, requisito de GPU e facilidade de rodar on-premise. Abaixo organizo o espectro em três faixas.
Small Language Models (SLM): tipicamente abaixo de 3B parâmetros. Rápidos, baratos, rodam em CPU ou hardware modesto. Servem para tarefas estreitas: classificação de intent, extração de entidades, roteamento de chamadas, moderação simples.
LLMs de produção: faixa de 7B a 70B (às vezes até ~100B em deploy dedicado). Equilíbrio entre qualidade e custo. É aqui que mora a maior parte dos sistemas RAG, chatbots corporativos e agentes com ferramentas.
Frontier models: os maiores modelos comerciais e de pesquisa (GPT-4o, Claude Opus, Gemini Ultra e similares). Máxima capacidade de raciocínio e conhecimento geral, com custo e latência proporcionais.
Onde brilha
RAG, chat corporativo, agentes com ferramentas, fine-tuning com LoRA
Limite comum
Tarefas que exigem conhecimento amplo e planejamento profundo
Cenário de uso
A demo acima compara latência, custo e cenários. Clique num caso de uso para ver qual faixa serve como ponto de partida.
SLM: pequeno, rápido, tarefa definida
SLMs existem porque nem todo problema precisa de raciocínio aberto. Se a saída é uma entre cinco categorias, um modelo de 1B bem treinado costuma bastar.
Vantagens:
- Inferência em milissegundos em CPU
- Custo quase zero em volume alto
- Possibilidade de rodar offline (privacidade, edge)
- Fine-tuning barato com poucos exemplos
Limites:
- Contexto curto
- Dificuldade com instruções ambíguas
- Sem capacidade de planejar várias etapas
Exemplo com Ollama local:
import ollama
response = ollama.chat(
model="llama3.2:1b",
messages=[
{"role": "system", "content": "Classifique o texto em: suporte, vendas, financeiro, spam."},
{"role": "user", "content": "Quero cancelar minha assinatura e receber estorno."},
],
)
print(response["message"]["content"]) # esperado: financeiro
Para classificação em escala, muitas equipes ainda preferem um modelo clássico (XGBoost, logistic regression) com embeddings. SLM entra quando a tarefa precisa de compreensão textual flexível sem subir para 7B+.
LLM de produção: o padrão para aplicações generativas
A faixa 7B-70B concentra o que a indústria chama de "LLM" em projetos reais. Modelos como Llama 3.1 8B, Mistral 7B ou GPT-4o mini respondem bem com RAG, seguem instruções e aceitam fine-tuning leve (LoRA).
Quando usar:
- Q&A sobre base de documentos
- Agentes que chamam APIs e bancos de dados
- Geração de texto com tom controlado via prompt
- Prototipagem antes de decidir se precisa de frontier
from openai import OpenAI
client = OpenAI()
response = client.chat.completions.create(
model="gpt-4o-mini",
messages=[
{"role": "system", "content": "Responda com base no contexto. Se não souber, diga."},
{"role": "user", "content": f"Contexto: {context}\n\nPergunta: {question}"},
],
temperature=0.2,
)
Custo e latência são previsíveis. Com quantização (GGUF, AWQ, GPTQ) um 7B roda em uma GPU consumer. Um 70B pede infraestrutura maior, mas ainda é self-hosted em muitas empresas.
Frontier models: quando o problema exige o topo
Frontier models são os que ainda definem o teto de desempenho em benchmarks de raciocínio, código e conhecimento geral. Fazem sentido quando:
- A tarefa envolve múltiplas etapas de raciocínio sem pipeline fixo
- O erro tem custo alto (jurídico, médico, financeiro com baixa tolerância)
- O time ainda explora o espaço de solução e precisa de máxima flexibilidade
- Um modelo menor falhou em evals com dados reais
O preço por token pode ser 10x a 50x maior que um LLM médio. Latência de vários segundos é normal. Dependência de API externa traz questões de compliance.
Padrão comum em produção: modelo menor na borda, frontier no escalonamento. O SLM ou LLM médio resolve 80% dos casos; consultas difíceis sobem para o frontier.
def route_query(question: str, complexity_score: float) -> str:
if complexity_score < 0.3:
return "llama3.2:1b" # SLM: triagem
if complexity_score < 0.7:
return "gpt-4o-mini" # LLM: RAG padrão
return "gpt-4o" # Frontier: raciocínio pesado
Critérios de decisão
Perguntas objetivas antes de escolher:
- A saída é fechada (classe, JSON fixo) ou aberta (texto livre)?
- Quantos tokens de contexto entram por chamada?
- Qual latência o usuário aceita?
- Dado sensível pode sair da sua infraestrutura?
- Existe dataset rotulado para fine-tune de um modelo menor?
Regra prática: comece pelo menor modelo que passa nos seus evals. Suba de escala só quando tiver evidência de que o menor falhou.
| Tarefa | Começar com | Escalar para |
|---|---|---|
| Classificação de tickets | SLM ou ML clássico | LLM 7B se ambiguidade alta |
| RAG corporativo | LLM 7B-13B | Frontier se faithfulness insuficiente |
| Agente multi-tool | LLM 13B-70B | Frontier em subtarefas críticas |
| Análise de contrato longo | LLM 70B + RAG | Frontier se raciocínio jurídico complexo |
Erros frequentes na escolha
Subir direto para frontier "para garantir qualidade" sem medir. Na maioria dos casos um 8B com RAG bem feito iguala ou supera um modelo grande com retrieval ruim.
Ignorar quantização e serving. Um 70B quantizado em 4-bit pode custar menos que um frontier via API em volume alto.
Confundir tamanho com especialização. Um SLM fine-tuned no seu domínio pode bater um frontier generalista em tarefa estreita.
Não versionar qual modelo responde cada rota. Em sistemas híbridos, logue modelo, latência e custo por requisição.
Conclusão
SLM resolve tarefa estreita com custo mínimo. LLMs na faixa 7B–70B carregam a maior parte dos sistemas de RAG, agentes e chat corporativo. Frontier models ficam para raciocínio difícil ou como fallback quando evals com dados reais mostram que o modelo menor não dá conta.
Defina evals, teste o menor modelo possível, meça latência e custo, e escale com dados. Os posts sobre embeddings e RAG neste blog assumem um LLM de produção; agentes e fine-tuning mostram como especializar ainda mais a escolha.