Como colocar um modelo de IA pra funcionar no seu projeto — o básico

O que é model serving e os desafios de produção

Da pesquisa ao sistema real

Model serving é a prática de expor modelos de machine learning treinados como serviços consumíveis por outras aplicações. Enquanto treinar um modelo envolve um ambiente controlado com dados fixos, colocá-lo em produção exige lidar com variabilidade de carga, latência aceitável, custo de infraestrutura e disponibilidade contínua. A maioria dos projetos de IA fracassa não no treinamento, mas na etapa de serving - onde as premissas de pesquisa colidem com a realidade operacional.

Formatos de modelo - ONNX, TensorFlow SavedModel, PyTorch

Portabilidade e otimização entre frameworks

Cada framework de deep learning exporta modelos em formatos diferentes: PyTorch usa TorchScript ou arquivos .pt, TensorFlow exporta SavedModel ou TFLite, e ONNX (Open Neural Network Exchange) funciona como formato intermediário portável entre qualquer framework. Converter modelos para ONNX permite usar runtimes otimizados como ONNX Runtime, que aplica otimizações de grafo, quantização e fusão de operadores independentemente de como o modelo foi treinado. A escolha do formato impacta diretamente latência de inferência, tamanho do artefato e compatibilidade com hardware de aceleração.

APIs de inferência - REST, gRPC, streaming

Protocolos adequados para cada caso de uso

A interface entre o modelo e o mundo externo pode ser REST/HTTP para casos simples e compatibilidade máxima, gRPC para latência baixa e comunicação entre microsserviços com schema bem definido via Protocol Buffers, ou streaming via Server-Sent Events e WebSockets para modelos que geram saída incrementalmente como LLMs. A escolha do protocolo afeta o design do cliente, o comportamento em caso de erro e a capacidade de observabilidade. Em cenários de alta frequência de requisições, o overhead do HTTP/1.1 com JSON pode ser um gargalo mensurável comparado a gRPC binário.

Triton Inference Server - serving de alto desempenho

Infraestrutura da NVIDIA para inferência em escala

O NVIDIA Triton Inference Server é uma solução open source projetada para servir múltiplos modelos de diferentes frameworks (TensorFlow, PyTorch, ONNX, TensorRT) em GPUs e CPUs com gerenciamento de concorrência, batching dinâmico e suporte a pipelines de inferência encadeados. Ele expõe uma API gRPC e HTTP padronizada e inclui métricas de desempenho nativas para Prometheus. Para equipes que precisam de alto throughput com múltiplos modelos em um único servidor GPU, o Triton reduz significativamente a complexidade operacional comparado a soluções caseiras.

Latência e throughput em inferência

As métricas que definem a experiência do usuário

Latência é o tempo total desde a requisição até a resposta, enquanto throughput mede quantas requisições por segundo o sistema processa. Em model serving, existe uma tensão fundamental entre os dois: otimizar para throughput via batching aumenta a latência individual, enquanto otimizar para latência mínima desperdiça capacidade de GPU. Técnicas como quantização INT8, pruning de camadas e distilação de modelos reduzem o custo computacional por inferência. Para aplicações interativas, SLOs de latência no percentil P99 são mais relevantes do que a média - pois um outlier de 5 segundos destrói a experiência mesmo que 95% das respostas sejam rápidas.

Batching - processando múltiplas requisições juntas

Eficiência de GPU através de paralelismo

GPUs são processadores massivamente paralelos projetados para executar o mesmo cálculo em muitos dados simultaneamente. O batching agrupa múltiplas requisições individuais em uma única operação de inferência, aumentando o aproveitamento da GPU e reduzindo o custo por inferência. O batching estático exige que o cliente envie lotes com tamanho fixo, enquanto o batching dinâmico acumula requisições por um tempo máximo configurável antes de processá-las. Em LLMs, o continuous batching (ou iteration-level scheduling) permite processar requisições de diferentes comprimentos juntas, maximizando o preenchimento da janela de contexto disponível da GPU.

GPU serving vs CPU serving - custos e trade-offs

Escolhendo a infraestrutura certa para cada modelo

GPUs oferecem aceleração de 10x a 100x para modelos de deep learning densos em operações de álgebra linear, mas seu custo mensal em cloud pode ser proibitivo para modelos pequenos ou baixo tráfego. CPUs modernas com suporte a instruções AVX-512 e frameworks como ONNX Runtime com otimizações para x86 entregam latência aceitável para modelos menores ou quantizados. A decisão correta envolve calcular o custo por inferência: modelos de classificação simples rodando em CPU podem custar 50x menos por requisição do que em GPU quando o volume não justifica manter a GPU alocada. Instâncias spot e autoscaling são estratégias para equilibrar custo e disponibilidade.

Versionamento e A/B testing de modelos

Evolução de modelos sem downtime e com dados de decisão

Modelos evoluem com novos dados, arquiteturas melhores e correções de bias - e cada versão precisa coexistir com a anterior durante a transição. Ferramentas como MLflow Model Registry e Seldon Core permitem registrar versões, promover modelos de staging para produção e fazer rollback imediato em caso de regressão. O A/B testing de modelos direciona uma porcentagem do tráfego para a nova versão, comparando métricas de negócio (conversão, satisfação) e técnicas (acurácia, latência) antes de migrar 100% dos usuários. Shadow mode envia a mesma requisição para dois modelos em paralelo sem expor o resultado do modelo novo, permitindo comparação segura em produção.

Monitoramento de modelos em produção

Detectando degradação antes que o usuário perceba

Diferente de APIs convencionais onde um bug é binário, modelos degradam gradualmente: data drift (a distribuição dos dados de entrada muda), concept drift (a relação entre entrada e saída muda no mundo real) e feature skew (o pre-processamento em produção difere do treinamento). Monitorar distribuição estatística das features de entrada, comparar predições com ground truth quando disponível e rastrear métricas de negócio downstream permite detectar degradação antes que ela impacte resultado. Ferramentas como Evidently, Fiddler e Arize automatizam detecção de drift e alertas. Um pipeline de retreinamento automático fechando o loop é o estado da arte para sistemas de ML em produção.

Conclusão

Model serving como disciplina de engenharia

Colocar modelos em produção de forma confiável exige tanto expertise em ML quanto em engenharia de sistemas. Latência, custo, versionamento e monitoramento não são detalhes operacionais - são parte central da entrega de valor com IA. Continue em: Fundamentos obrigatórios antes de produção.

Model Serving no YouTube

Machine Learning em Produção - Fundamentos de MLOps

ONNX Runtime e Otimização de Inferência

GPU vs CPU para Inferência de Modelos

Triton Inference Server na Prática

Batching e Throughput em Model Serving

Monitoramento de Modelos com Evidently e Arize