Quinto post da série sobre gateway de IA. Antes: por que existe, como montar, quanto custa em latência e onde o modelo local entra.

Resumo

  • Um pipeline real de análise de atendimentos — ligações e chats, em português — rodando em API proprietária de LLM. Funciona, e cobra três preços.
  • Destilei um modelo aberto de 9B a partir do próprio sistema em produção, com 5 mil exemplos. O prompt de 18 mil tokens encolheu para cerca de 400.
  • Na tarefa verificável, o aluno é estatisticamente indistinguível do professor contra gabarito humano independente.
  • Custo 36 vezes menor, calculado de fatura real e GPU-hora medida — não de tabela de preço.
  • A economia não vem de GPU barata. Vem de ela ser agendável — e isso muda quem consegue repetir o resultado.

1. Os três preços de uma API proprietária

O sistema funcionava. Essa é a parte importante — não era um projeto de resgate, era um pipeline em produção entregando análise de atendimento.

Mas ele cobrava três preços que raramente aparecem juntos na mesma conversa:

Fatura atrelada ao fornecedor. Todo volume novo é custo variável, e a régua de preço é de outra pessoa.

Latência e disponibilidade fora do seu controle. Quando o provedor degrada, você descobre junto com o usuário.

Dado pessoal saindo continuamente para terceiro. Atendimento é conversa de cliente. Cada chamada é uma transferência, e a LGPD tem opinião sobre isso.

Esse terceiro preço é o que muda a natureza da decisão. Os dois primeiros são otimizáveis; o terceiro é estrutural, e foi sobre ele que eu escrevi em Sua política de uso de IA não impede o vazamento.

A pergunta era direta: quanto da qualidade desse sistema dá para preservar destilando um modelo aberto pequeno, rodando em infraestrutura própria?

2. Escolher o modelo base com o prompt de produção

Primeira decisão de método, e a que mais me poupou tempo depois: avaliei 13 modelos abertos sob o mesmo prompt de produção, de 18 mil tokens. Não benchmark genérico.

Ranking público mede desempenho médio em tarefa média. O que decide aqui é desempenho na sua tarefa, com o seu prompt, no seu idioma — e a ordem dos modelos muda quando você troca o critério. Um modelo que lidera tabela pode desmontar num prompt longo em português com formato de saída rígido.

Se você for repetir isso: rode a seleção com o prompt que já está em produção, antes de treinar qualquer coisa. É barato e derruba metade dos candidatos.

3. A destilação

5 mil exemplos, gerados pelo próprio sistema em produção. O sistema em produção é o professor: ele já produziu, ao longo do tempo, o par entrada-saída que você precisa. Não foi preciso rotular nada do zero.

Isso é uma consequência prática do que eu argumentei no post sobre modelo local: o conjunto de treino é subproduto de ter rodado o modelo grande com rastro. Quem instrumentou a chamada desde o começo já tem o dataset; quem não instrumentou vai ter que esperar acumular.

Fine-tuning supervisionado, modelo aberto de 9B.

O detalhe que eu não esperava

O prompt de 18 mil tokens encolheu para cerca de 400.

Toda a configuração do projeto — as regras de classificação, o formato de saída, os casos de borda, o vocabulário do domínio — deixou de ser instrução repetida a cada chamada e passou a viver nos pesos do aluno.

Isso tem efeito direto na conta, e é uma parte grande do 36×: você não paga 18 mil tokens de entrada em toda requisição. Mas tem um efeito colateral que vale saber: a configuração que estava legível num arquivo de prompt agora está implícita no modelo. Mudar uma regra deixou de ser editar texto e passou a ser re-destilar. É uma troca, não um ganho puro.

4. O protocolo de avaliação

Esta é a parte que deu mais trabalho, e é a que eu defenderia primeiro se alguém contestasse o resultado.

Um número de qualidade sem protocolo não vale nada, porque quem produziu o modelo escolhe a métrica que o favorece. Então foram três instrumentos independentes:

Métrica automática, na parte da tarefa que é verificável.

Painel de juízes-LLM de fabricantes diferentes do professor. Isso importa: juiz da mesma família do professor tende a preferir a saída do professor. Usar famílias distintas remove parte desse viés.

Anotador humano cego, sem saber qual saída veio de qual sistema.

5. O que os três instrumentos disseram

Na tarefa verificável — scoring binário, Sim/Não — o aluno destilado teve 87% de concordância com o professor.

E o teste que importa mais: contra um gabarito humano independente, o aluno é estatisticamente indistinguível do professor. Não é "quase tão bom" — é que a diferença entre os dois não sobrevive ao teste com a amostra disponível.

Nos campos abertos, sob comparação cega, os juízes não separaram a análise do modelo de 9B da análise do sistema em produção em 92% dos casos.

No custo, 36 vezes menor — e calculado de fatura real e GPU-hora medida, não de tabela de preço multiplicada por estimativa de volume.

6. Dois aprendizados que valem mais que os números

6.1 A economia não é a GPU ser barata. É ela ser agendável.

Este é o ponto que mais gente erra ao fazer a conta.

O mês inteiro de inferência coube em cerca de 11 GPU-horas. A carga é em rajada: o pipeline processa lotes de atendimento, não tráfego contínuo.

A mesma GPU ligada 24 horas por dia, sete dias por semana, custaria mais que a API. O ganho não veio de hardware barato — veio de ligar a máquina só quando há trabalho.

Consequência prática, e ela contradiz o modelo mental comum: se a sua carga é interativa e constante, a conta do modelo local é muito pior do que a deste caso. Antes de projetar economia, olhe o perfil da sua carga. Rajada agenda; interativo não.

6.2 Avaliação vale mais que treino

O esforço do trabalho não foi o fine-tuning. Fine-tuning de um 9B com 5 mil exemplos é questão de horas.

O esforço foi construir um protocolo de comparação defensável: mesmo prompt para todos, juízes de famílias diferentes do professor, validação humana cega, e análise de poder para saber o que a amostra pode e o que não pode afirmar.

Essa última parte é a que quase nunca aparece. Sem análise de poder, "o aluno empatou com o professor" pode significar tanto "são equivalentes" quanto "a amostra é pequena demais para detectar a diferença". São conclusões opostas e só o cálculo separa uma da outra.

Se você for fazer isso na sua empresa e tiver que cortar escopo, corte no treino, não na avaliação. Um modelo pior com medição confiável é decisão; um modelo melhor com medição frouxa é aposta.

7. O entregável não é o modelo

O produto final não é o arquivo de pesos. Pesos envelhecem — muda o domínio, muda o produto, sai um modelo base melhor.

O entregável é o fluxo: a empresa consegue re-destilar a partir do tráfego novo, re-avaliar contra o mesmo protocolo, e promover uma versão nova com critério automático em vez de opinião.

É a mesma ideia do alias de tarefa no gateway: a decisão de qual modelo atende qual tarefa vira configuração revisável, não escolha enterrada em código. O modelo destilado entra como o destino do alias local, e trocar de versão é uma linha.

8. Para quem isso serve

Se a sua carga é interativa e constante, refaça a conta com o seu perfil antes de qualquer coisa. O 36× deste caso vem de carga em rajada, e não transfere.

Se a sua tarefa é aberta — redação livre, raciocínio longo, síntese sobre muito contexto — um 9B destilado não vai empatar com um modelo de fronteira. Esse resultado é de tarefa estreita e bem definida, que é onde a destilação funciona.

Se o seu problema é dado pessoal saindo da empresa, aí a conversa muda de natureza: mesmo sem ganho de custo, o modelo local é a única opção que transforma a garantia de contratual em técnica.

E antes de tudo isso, o passo zero continua o mesmo: saber quais tarefas você tem e quanto cada uma roda. O diagnóstico responde a primeira metade em minutos.

Como ajudamos times a adotar IA

Trabalhamos com times de engenharia que buscam incorporar IA ao dia a dia de desenvolvimento — não como experimento, mas como parte real do fluxo de trabalho.

Isso passa por escolher as ferramentas certas para o contexto do time, configurá-las de forma que façam sentido para a política de dados da empresa e garantir que os desenvolvedores saibam usá-las de um jeito que realmente aumente a produtividade, em vez de gerar mais fricção.

Se você tem um time de desenvolvimento e está tentando colocar IA para trabalhar de forma séria, fale com a gente.