Introdução

Acredito que não é surpresa pra ninguém que atualmente existe uma nova corrida do ouro por poder computacional por parte das empresas de tecnologia e IA como Google, Meta, OpenAI, Anthropic, dentre outras. Essas empresas estão investindo bilhões de dólares para poder aumentar ou ter acesso a infraestrutura de GPUs, TPUs e, principalmente energética para alimentar esses servidores.

Essa fome por poder computacional é justificada pela máxima Bigger is Better, ou maior é melhor. Ou seja, quanto maior o modelo, com mais parâmetros, em tese, mais inteligente ele é. Por outro lado, mais poder computacional é necessário para treinar e operar esse modelo.

Nome do Modelo

Ano de lançamento

Número de parâmetros

GPT-3

2020

Estimado em 175 bilhões

ChatGPT-4

2023

Estimado em ~1.8 trilhões

ChatGPT-4o Mini

2024

Estimado em ~8 bilhões

GPT-5

2025

Estimado em ~2-5 trilhões

Comparação de performance entre LLaMa 8b vs 70B

Porém a oferta por GPUs de ponta, como a Nvidia H100, sofre uma grande escassez. De um lado, temos as big techs, startups, governos e centros de pesquisa competindo por esses chips. Do outro lado, a oferta é limitada por conta da complexa cadeia de suprimento de GPUs.

Bom, até o momento, realmente parece que quanto maior e com mais dados para treinamento tivermos, mais inteligente ficará o modelo. Mas, será que esse é um caminho sustável? Quando falamos de aplicações cada vez mais nichadas, utilizar um modelo menor e mais especializado não traria melhores resultados?

O especialista vs o generalista

Os LLMs generalistas, como o ChatGPT, funcionam como um canivete suíço. Eles são versáteis, capazes de lidar com uma ampla gama de tarefas — desde redação de textos até análise e escrita de código — de forma razoavelmente competente. No entanto, para uma tarefa específica e complexa, uma ferramenta dedicada sempre supera o desempenho de um modelo "faz-tudo".

Esse problema foi explorado pelos autores desse artigo que destacou que SLMs, quando treinados para tarefas específicas (como interações de agentes), não apenas atingem, mas muitas vezes superam a performance de LLMs muito maiores. Os autores demonstram que os modelos menores e mais especializados tem melhor capacidade de seguir instruções, menor latência e maior consistência em domínios específicos.

Não só isso, o custo de operação de SLMs é muito menor em comparação aos LLMs. Uma vez que um SLM muitas vezes tem uma fração do tamanho de um LLM isso se traduz em uma redução de custo operacional. Tanto treinar quanto operar esses modelos acaba sendo mais barato. Dado que será necessário menos VRAM para carregar o modelo e um modelo menor consegue ter um throughput maior e latência menor quando comparado com modelos gigan.

Especialmente sistemas agenticos, que tem como base a utilização de diversos especialistas para resolver um problema, utilizar um “enxame” de modelos especializados em detrimento de um único LLM pode trazer ganhos substânciais e possivelmente garantir a viabildiade economica do projeto.

Um exemplo do mundo real

Em Setembro de 2025 o JPMorgan&Chase publicou esse artigo. Nele os autores decorrem de sobre um problema específico do negócio do banco, analisar transações financeiras. Esse tipo de análise é importante para garantir conformidade regulatória, detecção de fraudes e auxiliar na tomada de decisões de negócio.

O objetivo do artigo foi utilizar um modelo de linguagem para processar transações do tipo point of sale que os modelos baseados em regras já utilizados não são capazes de capturar. A ideia é utilizar esse LLM para identificar o comerciante correspondente através da informação da transação que é um texto não padronizado.

Exemplo de dado de transação

Dois fatores foram cruciais:

  1. O alto volume de dados das transações financeiras chegando a até 50 milhões de transações diariamente (isso dá ~34722 por minuto!!!). O que faz com que o modelo tenha que responder em milissegundos;

  2. Manter o custo de operação baixo (esquece subir um cluster de GPU “só" pra isso).

Dado que dados de transações financeiras são confidenciais, nenhum modelo comercial, como o ChatGPT ou Claude pode ser utilizado. Dessa forma, somente modelos open source que possam ser deployados dentro da infraestrutura interna foram considerados para os testes.

Os modelos escolhidos por arquitetura:

  • Arquitetura Encoder Only:

    • SentenceBERT;

    • Modelo propietário Encoder Only.

  • Arquitetura Decoder Only:

    • LLaMa3-8b;

    • Modelo propietário Decoder Only.

  • Arquitetura Encoder-Decoder:

    • Flan-T5;

    • Modelo propietário Encoder-Decoder

Os modelos foram comparados da seguinte forma:

  1. Modelo open source sem fine tune, as is;

  2. Modelo open source com fine tune, tornando-o específico para análisar os dados das transações financeiras;

  3. Modelo propietário treinado do zero para análisar os dados das transações.

Resultados do teste

Quando olhamos para os resultados dos modelos Encoder only, foi curioso o fato do modelo SBERT com fine tune ter performance 4% abaixo do próprio SBERT sem fine tune. A hipótese que os autores levantaram para explicar esse comportamento foi:

A possível razão é que os dados de transação não estão bem alinhados com a estrutura do modelo e o conjunto de dados original, introduzindo ruídos e vieses aos quais o modelo não estava previamente exposto.

Entretando o modelo propietário performou melhor que o SBERT na tarefa proposta, mesmo sendo menor que o SBERT.

Indo para os modelos Decoder-Only, como já era de se esperar o LLaMa3-8b sem fine tune foi o modelo que pior performou, porém o LLaMa3-8b com fine tune performou muito bem, chegando a 72,89% de acurácia. Por outro lado, o modelo propietário atingiu acurácia similiar 72,07% com somente 1.7M de parametros(!!!).

Por fim, o Flan-T5 com seus 220M de parametros e da arquitetura Encoder-Decoder performou 2% abaixo (70,14% vs. 68,31%) do modelo propietário que tem somente 1.5M de parametros(!!!).

Tabela comparativa modelos e custo de treinamento e inferencia

Como mostrado na tabela acima e pra surpresa de 0 pessoas, os modelos propietários são muito mais baratos de serem operados, dada a baixa quantidade de parametros que eles possuem quando comparado com os modelos open source utilizados nos testes.

Preços e recursos computacionais instâncias da família g4dn. Ressaltando os tamanhos xlarge e 12xlarge

Acima temos uma tabela comparativa diretamente do Vantage com os recursos computacionais e preço das intâncias utilizadas pelos autores. É possível ver que foi utilizado uma GPU Nvidia T4. Essa sendo considerada uma das GPUs mais simples que temos disponíveis nos dias de hoje.

Tabela comparativa do tempo de execução dos modelos propietários

Quando olhamos para o tempo de execução dos modelos propietários, podemos ver o modelo da arquitetura Encoder-Decoder é o mais rápido no momento da inferência e para treinamento, sendo também o que tem a menor quantidade de parâmetros.

Uma vez que o modelo Decoder-Only teve a melhor performance e o tempo de inferência está dentro do que os autores consideram como aceitável para operação, ele foi incluído na arquitetura de processamento de transações como fallback caso nenhum dos métodos já existentes baseados em regras não fossem capazes de extrair as informações de forma satisfatória.

Arquitetura de deploy do modelo

E se não bastasse todo esse ganho, o projeto ainda levou a uma economia de $13.2M/ano(!!!).

Conclusão

A IA genrativa veio para ficar, seja bolha ou não, é inegável o impacto que essa tecnologia gerou e ainda irá gerar em nossas vidas. É inegável o quanto que vimos nos últimos tempos o crescente surgimento de startups que tem seus produtos impulsionados por AI. Porém, são poucas dessas startups que conseguem gerar lucro, principalmente dado ao alto custo de operação, seja pagando por tokens através de algum provedor ou fazendo o deploy dos modelos em infraestrutura própria.

O que os artigos que quis trazer hoje mostram é que existe um caminho mais pragmático, eficiente e, em última análise, mais inteligente. Ao utilizar SLMs especialistas para realizar a tarefa proposta pode levar a um custo operacional menor e consequentemente a viabilidade economica do projeto.

Só que criar um sistema com diversos especialistas também não é nada trivial. Enquanto qualquer desenvolvedor consegue fácilmente integrar com um provedor de LLM, criar SLMs especialistas envolve conhecimento de diversas frentes:

  • Ciência de dados → Traduzir o problema de negócio de forma a conseguir escolher qual modelo e quais dados utilizar (ou criar) para realizar o fine tuning do modelo;

  • Infraestrutura → Conseguir calcular quanto de recurso o modelo irá consumir para ser treinado e operado de forma a minizar os recursos utilizados sem negligenciar as demandas do negócio;

  • Engenharia de software → Integrar esses pool de especialistas em uma aplicação que gere valor para os clientes.

Por fim, o que quero dizer é o seguinte: criar aplicações que utilizem SLMs em detrimento dos LLMs pode ser o caminho viável para tornar projetos baseados em NLP economicamente viáveis e isso só será possível através de pessoal altamente capacitado.

Reply

or to participate

Keep Reading

No posts found