Model serving: quando usar inferência batch ou online

Um modelo treinado não gera valor enquanto suas predições não chegam a quem decide ou ao sistema que age. Essa entrega é o model serving, a etapa que disponibiliza as saídas do modelo para o resto da operação. E é aqui que muitos projetos de machine learning tomam a decisão errada: sobem um endpoint online sofisticado para um caso que um job noturno resolveria melhor, ou tentam encaixar uma decisão de transação em um lote que roda de madrugada.

A escolha do modo de serving define latência, custo e complexidade operacional. Ela também determina o quão atualizada a informação precisa estar no instante da predição. Antes de decidir, vale separar dois assuntos que costumam se confundir. Como os dados são movimentados e processados até chegar ao destino é uma discussão de arquitetura de dados, tratada no guia sobre batch e streaming no processamento de dados. Este artigo trata de outra pergunta: quando e como o modelo produz suas predições, e por qual caminho elas são servidas.

A decisão não tem vencedor absoluto. Um endpoint online que responde em milissegundos parece mais moderno, mas pode custar caro e ficar ocioso a maior parte do tempo. Um batch agendado parece antiquado, mas costuma aproveitar melhor a máquina. O objetivo deste guia é dar critérios verificáveis para escolher entre inferência em batch, endpoint online e inferência sobre stream conforme a real exigência do sistema.

O que é model serving e onde ele entra no ciclo de MLOps

Model serving é a camada que expõe as predições de um modelo já treinado para consumo. Ela vem depois de várias outras etapas do ciclo de vida de um modelo, e confundir essas etapas leva a decisões ruins de arquitetura. Para posicionar o serving dentro do fluxo completo, o guia de arquitetura de MLOps descreve o ciclo inteiro, do dado ao monitoramento.

• Treinamento do modelo: o processo que ajusta os parâmetros do modelo a partir de dados históricos. Acontece antes do serving e em outra infraestrutura.
• Pipelines de features: o código que calcula as variáveis de entrada (features) a partir dos dados brutos. Roda tanto para treino quanto para produção.
• Feature serving: disponibilizar essas features prontas para o modelo consumir no momento da predição, normalmente por uma feature store.
• Model serving: disponibilizar as predições do modelo, que é o tema deste texto.
• Retreinamento e monitoramento: atualizar o modelo quando o desempenho cai e vigiar a degradação em produção, assunto do guia sobre drift de modelo.

Dentro do model serving, ainda há três modos de produzir e entregar a predição: batch agendado, endpoint online e inferência sobre eventos ou stream. Cada modo é uma arquitetura diferente, com trade-offs próprios de latência, custo e operação. É essa escolha que o restante do artigo destrincha.

Os três modos de servir um modelo

Inferência em batch agendada

Na inferência em batch, o modelo processa um conjunto de registros de uma vez, em horários ou intervalos definidos, e grava o resultado para consumo posterior. Um job lê uma tabela, aplica o modelo a todas as linhas e escreve as predições em outra tabela, banco ou arquivo. Quando alguém precisa da predição, consulta o valor já calculado, sem chamar o modelo naquele instante.

Esse modelo pré-calcula predições e costuma aproveitar melhor a capacidade computacional, porque processa muitos registros por execução e não mantém infraestrutura ligada entre os ciclos. As plataformas gerenciadas seguem esse padrão de subir a máquina, rodar e liberar: a documentação do Azure Machine Learning descreve que os endpoints batch provisionam a computação quando o job começa e a desalocam quando ele termina, de modo que você paga apenas pelo tempo de uso. No Vertex AI, a predição em batch é um job assíncrono que roda direto sobre o modelo, sem precisar manter um endpoint no ar. No SageMaker, o Batch Transform é indicado justamente para quando não se precisa de um endpoint persistente.

A frequência de execução se relaciona diretamente com o frescor das features: rodar de hora em hora entrega predições mais atuais do que rodar uma vez por dia, ao custo de mais execuções. Como um job pode falhar no meio, o batch precisa ser reprocessável com segurança. A prática recomendada é tornar a escrita idempotente, ou seja, reexecutar o job produz o mesmo resultado sem duplicar registros, usando uma chave e gravação por upsert. O ponto fraco é claro: se o caso exige resposta imediata a um evento que acaba de acontecer, o batch não serve, porque a predição só existirá no próximo ciclo.

O batch encaixa bem em propensão de compra recalculada todo dia, segmentação de clientes, previsão de demanda, priorização de leads, recomendações pré-computadas e scoring periódico de risco. A análise de risco com machine learning, por exemplo, costuma recalcular o score por janelas, sem exigir um endpoint no ar o tempo todo.

Endpoint online

No endpoint online, a aplicação envia uma requisição com os dados de entrada e recebe a predição de volta na hora, de forma síncrona. O modelo fica hospedado atrás de uma API, pronto para responder a cada chamada. Esse modo atende casos em que a predição participa de uma interação em andamento e alguém, ou algum sistema, espera a resposta para seguir adiante.

O endpoint online exige requisitos que o batch não tem. Latência baixa e alta disponibilidade viram metas de projeto. Picos de tráfego, concorrência e autoscaling passam a importar, porque o serviço precisa absorver variações de carga sem degradar. Entram na conta ainda a recuperação de features no momento da requisição, a serialização e o tráfego de rede a cada chamada, a observabilidade das predições, o versionamento do modelo com rollback e o comportamento definido para quando o serviço fica indisponível.

O custo tem uma característica que costuma surpreender: você paga pela capacidade provisionada mesmo quando o tráfego é baixo. A documentação do SageMaker reconhece que, se o tráfego não é constante ao longo do dia, sobra capacidade ociosa, o que leva a baixa utilização e recursos desperdiçados. No Vertex AI, a cobrança é por node ativo, inclusive pelos nós mínimos de espera, mesmo sem tráfego de inferência. Há opções gerenciadas que reduzem esse gasto ao escalar para zero quando não há requisições, como as variantes serverless e assíncrona do próprio SageMaker, mas elas reintroduzem o cold start, o atraso da primeira resposta quando a infraestrutura precisa subir do zero.

Casos típicos de endpoint online incluem decisão de fraude durante uma transação, personalização no meio de uma sessão, classificação em uma aplicação interativa, decisão de crédito durante a solicitação e ranking que precisa reagir à ação do usuário. O que não faz sentido é adotar o endpoint online como padrão só porque parece mais avançado. Se ninguém está esperando a resposta naquele segundo, a capacidade ligada o tempo todo vira custo sem contrapartida.

Inferência sobre stream ou eventos

No terceiro modo, eventos disparam predições conforme chegam. Em vez de um lote agendado ou de uma chamada síncrona da aplicação, um fluxo contínuo de eventos alimenta a inferência: uma leitura de sensor, uma transação, um clique. Aqui é importante separar três componentes que às vezes se misturam: o consumidor de eventos, que lê o fluxo; a engine de stream, que processa; e um eventual endpoint remoto, que pode ou não ser chamado para rodar o modelo.

Essa distinção define a arquitetura. O consumidor pode executar o modelo localmente, dentro do próprio processo de stream, evitando o salto de rede mas acoplando os recursos do modelo ao job. Ou pode chamar um serviço externo a cada evento, o que desacopla o modelo, mas adiciona latência de rede. A documentação do Apache Flink, ao tratar de acesso assíncrono a sistemas externos, alerta que a espera pela resposta de um sistema externo pode dominar o tempo de trabalho da aplicação de stream se as chamadas forem síncronas. Cada opção tem impacto diferente de latência, custo e operação.

O processamento também não é único. Ele pode ser registro a registro, em janelas de tempo ou em microbatches. E aqui vale desfazer um mito: streaming não significa automaticamente baixa latência. A documentação do Apache Spark descreve que o Structured Streaming, no modo micro-batch padrão, atinge latências da ordem de 100 milissegundos, enquanto o modo contínuo experimental chega a cerca de 1 milissegundo. Agregações em janela acumulam eventos antes de emitir um resultado, o que adiciona atraso por design. O Flink, por outro lado, processa evento a evento de forma nativa.

Operar um stream traz uma lista própria de preocupações: tratamento de eventos atrasados e fora de ordem com marcas de tempo (watermarks), diferença entre tempo do evento e tempo de processamento, estado mantido entre eventos, garantias de entrega, duplicidade e backpressure, que é a propagação da pressão quando a produção supera o consumo. Há também a questão do reprocessamento e o custo de manter a infraestrutura de eventos ligada continuamente. Sobre entrega, a documentação do Apache Kafka distingue três garantias: no máximo uma vez, ao menos uma vez (o padrão do Kafka) e exatamente uma vez. A escolha muda o risco de perder ou duplicar predições.

Esse modo encaixa em sensores industriais, telemetria, detecção de anomalias, atualização de risco após um evento, priorização de alertas e manutenção preditiva. Servir modelos sobre eventos exige mais engenharia de dados contínua do que os outros dois modos.

Os quatro critérios para escolher o modo de model serving

A decisão sobre model serving se organiza em torno de quatro critérios. Nenhum deles isolado decide; é a combinação que aponta o modo mais adequado.

Latência aceitável

A primeira pergunta é quanto tempo a predição pode esperar. As respostas variam bastante: algumas podem esperar horas, outras minutos, outras seguem um fluxo assíncrono em que o pedido é registrado e respondido depois, e outras precisam voltar dentro de uma interação, no meio de uma transação. Cada faixa aponta para um modo diferente.

O erro é fixar faixas universais rígidas. A latência necessária deve ser derivada do impacto para o usuário e do SLO (Service Level Objective, o alvo de nível de serviço acordado para o produto), não de um número decorado. Uma recomendação de vitrine que aparece meio segundo depois raramente muda a experiência; uma autorização de pagamento que trava por meio segundo, sim.

Frescor das features

Frequência da predição e frescor da feature são coisas distintas, e essa confusão custa caro. Aumentar a frequência das predições não resolve automaticamente features desatualizadas: se o dado de entrada foi calculado há um dia, rodar o modelo de minuto em minuto só repete a predição sobre um dado velho.

As features podem estar pré-computadas, ser consultadas em uma feature store ou ser transformadas durante a requisição. A feature store normalmente separa um repositório offline, com histórico para treino e batch, de um online, com os valores mais recentes para consulta em baixa latência. A documentação da Feast e a da Databricks descrevem esse recorte, e reforçam que usar a feature store com o mesmo código de cálculo em treino e em produção evita o train-serve skew, a divergência entre o dado que o modelo viu no treino e o que recebe em produção. Também é possível calcular features sob demanda, no instante da requisição, quando o valor depende de dados que só existem naquele momento. Manter treino e produção consistentes é um pré-requisito de correção que a Feast trata com junções ponto no tempo, para não vazar informação do futuro para o treino.

Custo por predição

O custo raramente é avaliado da forma certa. A conta que importa não é o preço da máquina por hora, e sim o custo de cada predição que a operação de fato usa. Uma forma conceitual de enxergar isso:

Custo por predição = custo total do serving no período ÷ predições efetivamente utilizadas.

O numerador reúne muito mais do que a computação: tempo ocioso, armazenamento, transferência de dados, consultas a features, orquestração, infraestrutura de streaming, autoscaling, cold starts, observabilidade, suporte operacional e aceleradores como GPUs. O denominador é o detalhe que muda tudo: contam apenas as predições usadas, não as geradas. Um batch que calcula score para a base inteira toda noite, mas cujas predições quase nunca são consultadas, tem custo unitário alto apesar do custo por linha baixo.

Vale separar três noções. O custo unitário é o preço de uma predição isolada. O custo total é o gasto do serviço no período. E o custo de oportunidade é o valor perdido por latência alta ou indisponibilidade, quando uma resposta lenta ou ausente deixa dinheiro na mesa. Um endpoint pouco usado pode ter custo total baixo e, ainda assim, custo por predição altíssimo.

Volume e padrão de tráfego

O comportamento da demanda inclina a balança. Volume previsível e alto, concentrado em janelas, favorece o batch, que agrupa muitos registros por execução. Tráfego constante ou com picos e sazonalidade, disparado por ações que não dá para prever, empurra para o online com elasticidade. Também pesam a quantidade de registros por execução, a possibilidade de agrupar predições e a necessidade de escalar rápido.

O ponto central é a utilização. Baixa utilização torna um endpoint provisionado caro por predição, porque a capacidade fica ligada esperando um tráfego que não vem. Volumes grandes e previsíveis, ao contrário, diluem o custo fixo do job de batch entre milhões de linhas processadas de uma vez.

Comparativo e matriz de decisão

A tabela a seguir resume os três modos pelos critérios que mais influenciam a escolha. Ela serve para posicionar as opções, não para declarar uma vencedora.

A comparação por critério ajuda, mas a decisão real acontece por cenário. A matriz abaixo cruza situações comuns com uma recomendação condicional, sempre dependente do contexto.

Os custos que passam despercebidos

Quase todo estouro de orçamento em serving vem de itens que ninguém somou no início. O mais comum é o endpoint ocioso: réplicas mínimas e capacidade provisionada continuam faturando mesmo sem requisições. O princípio vale para qualquer capacidade reservada. A documentação do Google Cloud, ao tratar de GPU em execução gerenciada, deixa explícito que a GPU é cobrada durante todo o ciclo de vida da instância e que instâncias mínimas são cobradas à taxa cheia mesmo ociosas. Uma GPU subutilizada reservada para picos raros é um dos gastos mais silenciosos de uma arquitetura online.

Há outros componentes fáceis de esquecer. Cold starts trocam custo por latência: manter capacidade quente elimina o atraso, mas você paga pela reserva. A documentação do AWS Lambda, base da inferência serverless do SageMaker, afirma que a concorrência provisionada é cobrada continuamente, inclusive quando o ambiente nunca processa uma requisição. Some a isso autoscaling, monitoramento, logs, rastreamento das predições, a feature store online, transferência de dados, filas, a infraestrutura de streaming, reprocessamentos, o suporte de plantão e a complexidade de implantação e rollback. Operar um endpoint com alta disponibilidade em contêineres orquestrados tem seu próprio custo de engenharia, como discutido no guia sobre deploy em Docker e Kubernetes.

A leitura correta é que o menor tempo de resposta cobra um custo operacional maior. A decisão de pagar por ele deve partir do valor gerado pela redução da latência. Se cortar o tempo de resposta de horas para milissegundos não muda o resultado do negócio, o gasto extra não se justifica.

Arquiteturas híbridas: combinar sem multiplicar custo

Nem toda decisão é escolher um modo único. Muitas arquiteturas maduras combinam modos para equilibrar custo e experiência. Alguns padrões recorrentes ajudam a enxergar as possibilidades:

• Recomendação em batch com reranking online: o conjunto de candidatos é pré-calculado em batch, e um modelo leve reordena os itens no momento da requisição, com o contexto da sessão.
• Score base em batch ajustado por eventos: um score é calculado periodicamente e refinado por eventos recentes, sem recalcular tudo a cada evento.
• Fallback para predições pré-calculadas: quando o endpoint online falha ou estoura a latência, a aplicação recorre a um valor pré-computado, preservando a resposta.
• Eventos acumulados em microbatches: em vez de rodar o modelo evento a evento, o fluxo agrupa eventos em pequenos lotes, reduzindo o custo por predição.
• Modelos distintos para online e offline: um modelo enxuto atende as decisões online, enquanto um mais pesado roda em batch para análises que toleram espera.

O ganho dessas combinações é real, mas elas somam superfícies de operação. Cada modo adicional traz seu monitoramento, seu modo de falha e sua manutenção. A arquitetura híbrida não é uma solução automática: ela compensa quando cada peça resolve uma restrição concreta, e vira peso morto quando é adotada por sofisticação.

Checklist de decisão e erros comuns

Antes de definir o modo, vale responder a um roteiro objetivo. Ele transforma os quatro critérios em perguntas práticas:

• A predição precisa participar de uma interação em andamento?
• O resultado pode ser pré-calculado?
• Com que frequência as features realmente mudam?
• Quantas predições serão efetivamente consumidas?
• O tráfego é constante, previsível, esporádico ou concentrado?
• Há capacidade para operar um endpoint com alta disponibilidade?
• Existe infraestrutura de eventos já mantida pela organização?
• Qual é o comportamento aceitável em caso de falha?
• É necessário reprocessar eventos ou registros?
• Quanto custa manter a infraestrutura disponível sem uso?
• Uma arquitetura híbrida reduz o custo sem comprometer o produto?

Com essas respostas em mãos, o fluxograma abaixo encadeia as perguntas de maior peso e conduz a um ponto de partida para cada situação. Ele é um guia de decisão, não uma regra universal: o contexto sempre ajusta o destino.

Fluxograma de decisão do modo de model serving por latência, frescor, volume e custo. Fonte: BIX Tecnologia.

Alguns erros aparecem com frequência nessa escolha. Adotar o endpoint online como padrão, por parecer mais moderno, leva a pagar por capacidade ociosa sem necessidade. Tratar streaming como sinônimo de baixa latência ignora que micro-batches e janelas adicionam atraso. Aumentar a frequência do batch para corrigir features velhas não resolve o frescor do dado de entrada. Dimensionar o serving pelo custo da máquina, e não pelo custo por predição usada, esconde o desperdício. Reconhecer esses padrões antes de escrever a primeira linha de infraestrutura evita retrabalho caro.

A escolha do modo de model serving raramente é definitiva, e quase nunca é única. Ela nasce de quatro perguntas, sobre latência, frescor, custo e demanda, respondidas a partir do valor que a predição gera para o negócio. Um endpoint online se justifica quando a predição participa de uma interação e alguém espera por ela; o batch entrega mais eficiência quando o volume é previsível e a resposta pode esperar; o stream encaixa quando os eventos ditam o ritmo. Rever essa decisão à medida que o produto evolui é parte da maturidade de MLOps, e não um sinal de erro inicial.

Se sua empresa está estruturando o serving dos seus modelos e precisa equilibrar latência, custo e frescor sem sobre-dimensionar a infraestrutura, nossos especialistas podem ajudar a desenhar a arquitetura certa para o seu contexto. A BIX trabalha com múltiplas soluções de dados, nuvem e engenharia, e a escolha ideal varia conforme a realidade de cada operação. Fale com a nossa equipe e avance na maturidade dos seus dados. ⬇️

O que é model serving em machine learning? Model serving é a etapa que disponibiliza as predições de um modelo treinado para os sistemas que as consomem. Ela pode acontecer de três formas: em batch agendado, quando as predições são pré-calculadas em lote; por endpoint online, quando o modelo responde em tempo real a cada requisição; ou sobre stream, quando eventos disparam a inferência conforme chegam.

Qual a diferença entre inferência em batch e inferência online? A inferência em batch processa muitos registros de uma vez, em horários definidos, e grava o resultado para consulta posterior, com latência de minutos a horas e baixo custo ocioso. A inferência online responde de forma síncrona a cada requisição, com latência baixa, mas mantém capacidade provisionada e paga por ela mesmo com pouco tráfego.

Quando usar um endpoint online em vez de batch? Use endpoint online quando a predição participa de uma interação em andamento e alguém, ou algum sistema, espera a resposta para seguir, como em decisão de fraude ou crédito durante uma transação. Se a predição pode ser pré-calculada e consultada depois, o batch tende a ser mais econômico e simples de operar.

Streaming sempre significa baixa latência? Não. Um fluxo de eventos pode processar a inferência registro a registro, em janelas ou em microbatches, e cada abordagem tem uma latência diferente. A documentação do Apache Spark, por exemplo, descreve latências da ordem de 100 milissegundos no modo micro-batch padrão. Janelas de agregação acumulam eventos antes de emitir o resultado, o que adiciona atraso.

Como calcular o custo por predição no model serving? Divida o custo total do serving no período pela quantidade de predições efetivamente utilizadas. O custo total inclui computação, tempo ocioso, armazenamento, consultas a features, transferência de dados, observabilidade e aceleradores como GPUs. Predições geradas e nunca consumidas elevam o custo unitário, mesmo quando o custo por registro parece baixo.