Empresas fazem fine-tuning de LLMs minúsculos para uma única tarefa em vez de usar APIs de modelos flagship

Mandar a um modelo de linguagem flagship, via API, a tarefa «encaixe este chamado em uma de dez categorias» é como contratar um ganhador do Nobel para atender ligações repetitivas em um call center. É com essa analogia que o Habr abre a análise de uma prática cada vez mais comum na IA corporativa: as empresas treinam um modelo minúsculo para uma única tarefa estreita e abrem mão do gigante generalista. Falamos de modelos de 0,5–3 bilhões de parâmetros, contra centenas de bilhões nos flagships. Depois da quantização, um modelo desses ocupa de algumas centenas de megabytes a cerca de dois gigabytes e roda em uma placa de vídeo barata, às vezes até em um processador comum.

Uma ressalva importante: o trecho disponível do material não traz benchmarks próprios. Por isso, os números abaixo são ordens de grandeza típicas desse tipo de projeto, não resultados de uma empresa específica.

Por que um modelo flagship é exagero aqui

Um modelo generalista sabe escrever código, raciocinar e manter um diálogo. Para classificar chamados ou validar uma estrutura JSON, nada disso é necessário, mas a conta chega a cada requisição: em dinheiro, em latência e em dependência de um provedor externo. Com milhões de chamadas repetitivas por dia, o custo cresce de forma linear, e a diferença de preço entre um modelo grande e um pequeno vira uma linha do orçamento.

Uma tarefa estreita tem um espaço de respostas fechado. Se o modelo precisa escolher uma entre dez categorias ou confirmar que uma resposta segue um esquema, ele não precisa saber de tudo. Basta aprender bem a distribuição desses dados específicos. Para isso, uma arquitetura compacta é suficiente, como as das famílias Llama 3.2 (1B e 3B), Qwen2.5 (a partir de 0,5B), Gemma ou Phi.

Como isso funciona na prática

O caminho típico é este. Primeiro, a equipe passa uma parte dos dados reais por um modelo forte e obtém uma rotulagem de referência, que é revisada por pessoas. Em seguida, faz o fine-tuning do modelo pequeno nesse dataset, em geral com LoRA ou QLoRA, ou seja, atualizando apenas um pequeno conjunto de pesos de adaptadores. Isso pode ser feito em uma única placa, em algumas horas. O método se chama destilação de conhecimento: o modelo grande atua como professor, e o pequeno absorve seu comportamento em um recorte limitado.

As características práticas que motivam essa abordagem:

• tamanho: 0,5–3 bilhões de parâmetros em vez de centenas de bilhões;
• memória: de centenas de megabytes a alguns gigabytes após quantização de 4–8 bits;
• hardware: uma placa de vídeo barata ou CPU;
• latência: dezenas de milissegundos para uma resposta curta, sem chamadas de rede para fora;
• dados: permanecem dentro do perímetro da empresa, o que importa para dados pessoais e gravações de chamadas;
• custo: o gasto por requisição é determinado pelo hardware próprio, e não pela tarifa do provedor.

Onde estão as armadilhas

O principal item de custo se desloca da inferência para os dados. Um dataset rotulado de qualidade custa horas de especialistas, e o resultado depende diretamente da sua limpeza. O modelo pequeno generaliza mal fora da tarefa: se surgir uma nova categoria de chamado ou o formato mudar, será preciso refazer o fine-tuning. São necessários monitoramento de drift de dados, um conjunto de testes e um processo de retreinamento, caso contrário a economia é consumida pela manutenção.

Há também os casos de borda. Formulações ambíguas e classes raras são tratadas pior pelo modelo pequeno do que por um flagship. Por isso, equipes maduras montam uma cascata: o modelo pequeno processa o fluxo principal, e os casos duvidosos, com baixa confiança, seguem para o modelo grande.

Por onde começar

Olhe para as suas chamadas a LLMs e separe aquelas em que a resposta cabe em um conjunto fixo de classes ou em um esquema. Essas são as melhores candidatas. Reúna alguns milhares de exemplos com rotulagem verificada, meça a acurácia do modelo flagship em uma amostra reservada e use esse valor como referência. Depois faça o fine-tuning do modelo pequeno e compare qualidade, latência e custo por requisição. Se a diferença de acurácia for aceitável, migre o fluxo para o modelo pequeno e mantenha o flagship como camada de reserva para as respostas incertas. O ideal é começar pelo cenário mais volumoso e mais enfadonho: é nele que o ganho aparece mais rápido.