A decisão de SLM vs LLM parou de ser sobre qual modelo é mais inteligente. Virou conta. Em operações com agentes de IA, a maior parte do trabalho é repetitiva e de domínio estreito, e nesse terreno o modelo pequeno entrega quase o mesmo resultado a uma fração do custo. O CTO que dimensiona errado paga caro por tarefa que um modelo menor resolveria. Este artigo mostra os 5 indicadores que transformam essa escolha em número e ajudam a escalar IA sem estourar o orçamento.
O que muda quando o CTO separa SLM de LLM
SLM: modelo de linguagem pequeno, especializado num domínio, barato e rápido de rodar.
LLM: modelo de linguagem grande, generalista, com mais capacidade e custo bem mais alto por tarefa.
Por muito tempo a régua foi simples: use o maior modelo disponível e pronto. Isso fazia sentido quando o gargalo era capacidade. Hoje o gargalo é custo em escala. Um agente de IA não escreve ensaios. Ele classifica intenção, extrai campos de um documento, gera uma resposta estruturada e roteia para o próximo passo. São tarefas estreitas e repetidas milhares de vezes por dia.
A pesquisa da NVIDIA publicada em 2025, intitulada Small Language Models are the Future of Agentic AI, sustenta três pontos: os modelos pequenos já são capazes o bastante para a maior parte das tarefas de um agente, são mais adequados a sistemas agênticos e são bem mais econômicos. Os autores estimam que servir um SLM de 7 bilhões de parâmetros sai de 10 a 30 vezes mais barato que servir um modelo grande de 70 a 175 bilhões.
Para o CTO, a virada é mental antes de ser técnica. A pergunta deixa de ser qual modelo é mais inteligente e passa a ser qual o menor modelo que resolve esta tarefa específica com qualidade aceitável.
Por que SLM vs LLM virou decisão de custo, não de capacidade?
Porque o custo de inferência é o que mata o projeto, não a falta de capacidade do modelo. A maioria dos pilotos de IA morre na conta de fim de mês, quando o volume real bate e o preço por token vira uma linha relevante no orçamento.
O número que assusta veio da Gartner. A consultoria prevê que mais de 40% dos projetos de IA agêntica serão cancelados até o fim de 2027, por custo crescente, valor de negócio pouco claro ou controle de risco insuficiente. Custo aparece logo no topo da lista.
A ordem de grandeza ajuda a entender. Estimativas de mercado para 2026 colocam um endpoint privado de SLM em torno de US$500 a US$2.000 por mês para 10 mil consultas diárias, enquanto a mesma operação rodando em API de modelo grande, em volume alto, pode passar de US$30 mil por mês. A diferença não é marginal. É de uma ordem de grandeza.
Vale o contraponto: o custo de rodar modelos grandes está caindo rápido. A Gartner projeta que, até 2030, a inferência num LLM de 1 trilhão de parâmetros custará mais de 90% menos que em 2025. Mesmo assim, a economia relativa do SLM no volume repetitivo continua valendo, porque a tarefa simples não precisa do modelo caro nem quando ele fica mais barato.
Quais indicadores o CTO mede para decidir SLM vs LLM?
A decisão de SLM vs LLM deixa de ser opinião quando vira painel. Cinco indicadores cobrem o essencial e cabem em qualquer ferramenta de observabilidade decente.
| Indicador | O que mede | Faixa de referência |
|---|---|---|
| Custo por tarefa concluída | Quanto custa cada tarefa que o agente fecha de fato | Comparar SLM e LLM na mesma tarefa |
| Latência p95 | Tempo de resposta nos 95% piores casos | Abaixo de 8s em fluxo síncrono |
| Taxa de sucesso em domínio estreito | % de tarefas resolvidas sem intervenção humana | SLM ajustado costuma empatar com LLM aqui |
| Tráfego roteável para SLM | % do volume que um modelo pequeno resolve | Quanto maior, maior a economia possível |
| Custo da camada de roteamento | Gateway, observabilidade e manutenção do roteador | Não pode comer a economia do SLM |
O indicador que mais surpreende o CTO é o quarto. Em projetos de IA que estruturei em mid-market BR, quando a empresa mede de verdade quanto do tráfego é tarefa simples, o número costuma passar de 70%. Isso significa que a maior parte das chamadas ao modelo caro era desperdício, e que existe economia real esperando ser capturada com roteamento.
Por que a resposta quase nunca é só SLM ou só LLM?
Porque a arquitetura que funciona é mista. Os modelos pequenos cuidam do volume repetitivo. O modelo grande fica reservado para os poucos passos genuinamente difíceis, como raciocínio aberto ou tarefa fora do domínio treinado.
Essa lógica de arquitetura heterogênea aparece nas análises de 2026 e também na literatura técnica sobre sistemas agênticos com SLM: roteie a tarefa de alta frequência para o modelo especializado e mantenha o generalista para a exceção. O segredo está no roteador, a peça que decide qual modelo atende cada chamada. Sem ele, ou você paga caro por tudo, ou degrada a qualidade tentando forçar o modelo pequeno em tarefa que ele não dá conta.
É por isso que dimensionar modelo anda junto com orquestrar agentes. Quem já estruturou a camada de coordenação encontra o roteamento como passo natural, assunto que detalhei em orquestração multi-agente para empresas de médio porte.
SLM vs LLM: quando ainda vale usar o modelo grande?
Vale, e bastante, em situações específicas. O erro não é usar LLM. O erro é usar LLM para tudo. O modelo grande continua sendo a escolha certa quando a tarefa é aberta, exige raciocínio em vários passos ou cai fora do domínio para o qual o modelo pequeno foi ajustado.
Três sinais indicam que o LLM se justifica. Primeiro, a tarefa muda muito a cada chamada e não dá para prever o formato da resposta. Segundo, o passo exige juntar contexto de fontes diferentes e raciocinar sobre isso, não só extrair um campo. Terceiro, o volume é baixo, então o custo por chamada não escala a ponto de pesar no orçamento.
Os critérios opostos apontam para o SLM. Tarefa repetitiva, formato de saída previsível, domínio estreito e volume alto. Classificar intenção de um ticket, extrair dados de uma nota fiscal, resumir uma conversa e decidir o próximo passo de um fluxo são exemplos clássicos. Para esses casos, um modelo pequeno ajustado costuma empatar com o grande na taxa de sucesso e ganhar de longe no custo.
A decisão de SLM vs LLM, portanto, não se resolve por preferência de modelo. Se resolve tarefa por tarefa, com o roteador mandando cada chamada para o menor modelo que entrega o resultado. É trabalho de engenharia de custo, e é exatamente o que falta na maioria dos pilotos que viram caso de cancelamento.
O erro de dimensionamento que estoura o orçamento de IA
Conectando os dois dados centrais deste artigo, chego ao insight que mais economiza dinheiro de cliente. A NVIDIA mostra que o trabalho de um agente é majoritariamente tarefa estreita e repetida. A Gartner mostra que 40% dos projetos serão cancelados, com custo na frente. Ligando os dois: o cancelamento não é um problema de IA. É um problema de dimensionamento.
A empresa coloca um LLM de fronteira para classificar ticket e extrair campo de pedido, paga preço de raciocínio avançado por tarefa de rotina, e a conta estoura antes de o valor aparecer. O projeto é cancelado por custo, quando o que faltou foi escolher o tamanho certo de modelo para cada passo.
No Brasil esse erro dói mais. O custo de inferência é dolarizado, então cada chamada desnecessária ao modelo caro carrega câmbio embutido. Recomendo ao CTO brasileiro tratar dimensionamento de modelo como item de FinOps desde o piloto, não como otimização para depois. A diferença entre um projeto que escala e um que morre na planilha costuma estar nessa escolha, não na qualidade do modelo.
Próximos passos para esta semana
Cinco ações para o CTO sair da intuição e dimensionar IA por custo:
- Liste as tarefas que seus agentes executam e marque quais são estreitas e repetidas. Essas são candidatas a SLM.
- Meça o custo por tarefa concluída no modelo atual. Sem esse número, qualquer decisão é chute.
- Rode um teste lado a lado: a mesma tarefa de rotina num SLM ajustado e num LLM, comparando custo e taxa de sucesso.
- Estime o percentual de tráfego roteável para modelo pequeno. Acima de 50%, o roteamento se paga rápido.
- Trate inferência como linha de FinOps já no piloto, com câmbio considerado, e não como surpresa de fim de mês.
O CTO que mede esses cinco indicadores para de discutir qual modelo é mais inteligente e passa a discutir qual modelo é mais barato para cada tarefa. É essa disciplina que separa o projeto de IA que escala do que vira mais um piloto cancelado na conta do trimestre. Esse rigor de custo é o mesmo que sustenta a margem cobrada no indicador de crescimento com lucro do conselho.
Perguntas frequentes
Comentários (0)