O básico, mas como funciona na prática
Inferência é quando você pega um modelo que já foi treinado e passa dados novos por ele pra obter uma previsão ou classificação. Ponto. Não tem mágica. O modelo foi ajustado durante o treinamento — pesos atualizados, gradientes calculados, tudo — e na fase de inferência ele só faz forward pass. Leva um input e devolve um output. O que muita gente não entende direito é que inferência e treinamento são problemas completamente diferentes do ponto de vista de engenharia. No treinamento você quer throughput máximo com batch grande. Na inferência, muitas vezes o que importa é latência individual por amostra, especialmente se você tá servindo uma API que responde pro usuário final.
o que é inferencia e por que parece mais simples do que é
Quando você entra nessa área, acha que o trabalho difícil acabou quando o treinamento termina. Na verdade, é aí que começa a parte que consome mais recursos e dor de cabeça. Servidor rodando 24/7, cold starts, batching dinâmico, versionamento de modelo, monitoramento de drift. Tudo isso é inferência na prática. Dói principalmente na hora de colocar num ambiente de produção. Eu estava trabalhando numa API de classificação de texto pra um cliente de e-commerce, modelo BERT-tiny rodando em GPU A10G, e o problema era latência P99 que subia pra 800ms nos horários de pico. O modelo em si levava uns 15ms. O resto do tempo era overhead de CPU pra pré-processar os tokens, fazer padding dinâmico, e a overhead da orquestração do FastAPI. A solução foi separar o pré-processamento: fiz um serviço assíncrono que limpava os textos e tokenizava antes, usando um batch buffer que mandava pro modelo em lotes de 32. Caiu de 800ms pra 65ms de latência mediana. O resto foi ajuste fino de batch size e usar ONNX Runtime no lugar do PyTorch native, que reduziu mais uns 20ms.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Uma coisa contraintuitiva que eu aprendi: às vezes um modelo menor mas bem servido performa melhor pro usuário do que um modelo grande mal implementado. Eu vi clientes insistirem em manter modelos grandes porque "eram mais precisos", mas na prática a latência ruim fazia o usuário desistir antes do resultado chegar. Um modelo 40% menor com inferência otimizada tinha taxa de conclusão 3x maior. Também vale saber que quantização pode ser um tiro no pé se você não medir o impacto real. Reduzir de FP32 pra INT8 em alguns modelos de visão computacional que eu usei derrubou a acurácia em 6% em datasets com imagens desfocadas, enquanto em outros casos a queda foi imperceptível. Sempre teste no seu domínio específico antes de assumir que quantização é gratuito.
Outro detalhe que ninguém conta: o custo de inferência pode superar o custo de treinamento emordem de grandeza ao longo do tempo. Um modelo que custa R$2.000 pra treinar pode custar R$50.000/ano em infraestrutura de serving se você não monitorar uso de GPU e deixar instâncias ligadas ociosas. Scale to zero, usar spot instances quando possível, e pré-aquecer modelos é o que separa um projeto que roda de um que vai quebrar o orçamento.
Quando a inferência simplesmente não funciona bem
Existem cenários onde inferência com modelo pesado é inviável e você precisa de alternativas. Se você precisa responder em menos de 10ms e não tem GPU dedicada, considerar rule-based systems ou modelos extremamente leves (TinyML, modelos quantizados com 4-bit) pode ser a única saída viável. Se o custo de inferência por requisição é proibitivo, embeddings pré-computados + busca aproximada (ANN) costuma ser muito mais eficiente do que rodar um modelo completo pra cada query. A inferência é só o processo de usar um modelo treinado pra fazer previsões. A parte boa é que você já passou pela fase mais demorada. A parte chata é que fazer isso rodar bem no mundo real é outro jogo completo.
