Inferência de ML dentro da bid request: busca de features, batching e o preço de fallback

Um modelo que estima a probabilidade de clique e de conversão dentro do caminho de lance é julgado por um relógio que não é dele. A exchange para de ouvir no deadline dela, e uma previsão que chega depois desse momento não é uma resposta lenta: não é resposta nenhuma, e a computação já foi gasta.

O requisito costuma chegar como uma meta de latência para a inferência. Ele funciona melhor como uma subtração: o que sobra do deadline do leilão depois da rede, do parsing da requisição e das consultas de features, e que lance o bidder dá quando não sobra nada.

O deadline chega dentro da requisição, e a inferência fica com o restante

No OpenRTB 2.6, tmax é o tempo máximo em milissegundos que a exchange permite para receber lances, com a latência da Internet incluída, e ele prevalece sobre qualquer orientação que a exchange tenha dado antes. O orçamento não é uma configuração do seu serviço: ele viaja com cada requisição.

A documentação do Authorized Buyers do Google, atualizada em agosto de 2026, diz que o deadline em BidRequest.tmax normalmente vai de 80 a 1000 ms e cobre o tempo de rede até o trading location, além do tempo que o seu bidder leva para gerar uma resposta. Ela exige 85 por cento das respostas dentro do deadline, conforme vistas a partir do trading location, e restringe os bidders que não conseguem cumprir isso de forma consistente.

Então o deadline é uma soma, e o modelo detém um dos termos dela:

• A ida e volta até a exchange, que nenhum trabalho no modelo encurta
• O parsing da requisição e a seleção de candidatos por filtros de targeting, orçamento e frequência
• A busca de features do usuário e do contexto, normalmente uma chamada de rede com a sua própria cauda
• A avaliação dos candidatos que sobreviveram e, em seguida, a precificação e a codificação da resposta
• Uma margem para a variância de tudo o que está acima, lida nos seus próprios histogramas por exchange, e não em uma média

Carimbe um deadline absoluto na chegada, derivado do tmax menos o tempo de rede que você mede para aquela exchange, e passe a cada etapa o tempo restante em vez de um timeout fixo. A documentação do gRPC descreve o mesmo mecanismo: um deadline propagado vira um timeout com o tempo decorrido já descontado, e a aplicação servidora continua responsável por parar o trabalho que ela disparou.

Quando o restante é pequeno demais para pontuar, responda cedo. O OpenRTB 2.6 prevê duas formas de no-bid, uma resposta vazia com HTTP 204 ou uma bid response com um código de motivo em nbr, e incentiva o código de motivo. Uma resposta atrasada custa mais: o sistema de cota de callouts do Google envia menos callouts a um bidder que não responde a tempo, e se ajusta em questão de minutos.

Busca de features e avaliação do modelo falham de formas diferentes, então recebem orçamentos separados

Duas etapas se escondem sob a palavra inferência. A busca de features é entrada e saída: sinais de histórico, frequência e contexto vindos de um store remoto, com uma cauda que pertence à rede e a esse store. A avaliação é computação, um forward pass ou um percurso pelas árvores, com uma cauda que pertence à contenção de CPU dentro do seu próprio processo.

Um p99 que mistura os dois não diz qual deles consertar, então mantenha dois histogramas por exchange e classifique as features por onde elas vivem:

• Features da requisição, lidas da própria bid request: gratuitas, e a única classe que não tem como chegar atrasada
• Features de campanha e de criativo, mantidas na memória do processo e reconstruídas fora do hot path, então uma reconstrução lenta custa atualidade, e não um lance
• Features de usuário e de histórico vindas de um store remoto: a maior cauda, e o primeiro grupo a cortar quando o orçamento está curto
• Features cruzadas calculadas por requisição, cujo custo cresce com o número de candidatos

Uma busca com deadline precisa de um modelo que conte com a resposta ausente: treine com o grupo de features atrasado ausente em uma parcela dos exemplos, ou mantenha um segundo modelo sem ele, para que uma consulta cancelada mova a previsão de um jeito que você já mediu.

Dean e Barroso descreveram as hedged requests em The Tail at Scale, em 2013: depois de um breve atraso, envie uma segunda cópia para outra réplica e use a resposta que chegar primeiro. No benchmark deles com BigTable, um hedge enviado após 10 ms reduziu a latência no percentil 99,9 para recuperar 1.000 valores de 1.800 ms para 74 ms, enviando 2 por cento mais requisições. Dentro de um leilão, o atraso do hedge tem que sair da parcela restante da busca.

Escolha o formato do modelo pelo que roda no seu processo sem um salto de rede

A decisão de runtime é, na maior parte, uma decisão sobre onde a avaliação acontece. Um servidor de inferência separado acrescenta uma ida e volta e uma fila a cada requisição pontuada; a avaliação dentro do processo do bidder não acrescenta nenhuma das duas e, em troca, passa para você a memória e as threads dele. Quatro opções comuns:

• Regressão logística sobre features esparsas, uma soma sobre os pesos ativos: o modelo de camada única que McMahan e colegas descreveram para a previsão de cliques em anúncios do Google no KDD 2013
• Ensembles de árvores compilados ahead of time: o TL2cgen, do projeto dmlc, converte random forests e modelos de gradient boosting em código C distribuído como binário nativo
• Uma rede neural pequena no ONNX Runtime, cujo pool intra-op usa por padrão uma thread por núcleo físico, com spinning habilitado: onde os handlers já ocupam todos os núcleos, dimensione-o para a requisição, não para a máquina
• Um servidor separado, como Triton ou TensorFlow Serving, quando o modelo precisa de um acelerador ou de um ciclo de release próprio

A quantização é a outra alavanca de CPU, com dois custos declarados na própria documentação do ONNX Runtime: a quantização linear de 8 bits não é uma transformação sem perdas, e o overhead dela faz com que um desempenho pior em dispositivos antigos não seja raro. Para um modelo de CTR, a acurácia inclui a calibração, então compare as taxas previstas e observadas antes e depois.

Batching entre requisições gasta o recurso que um bidder menos tem

Fazer batching dos candidatos de uma requisição não custa espera, porque eles já existem. O batching dinâmico entre requisições aumenta o throughput fazendo as requisições esperarem por companhia, o oposto do que um deadline de leilão pede, e os próprios servidores de inferência dizem isso:

• O TensorFlow Serving limita a espera por um batch que não está cheio com batch_timeout_micros, usado para conter a latência de cauda, e, para sistemas só com CPU, sugere começar em 0, tendo em mente que 0 pode ser o valor ótimo
• O dynamic batcher do NVIDIA Triton segura um batch apenas enquanto nenhuma requisição tiver esperado mais do que um atraso máximo de fila configurado, e o guia dele sugere aumentar esse atraso até o orçamento de latência ser excedido
• A política de fila do Triton pode rejeitar ou adiar requisições que esperam na fila além de um timeout, transformando um score atrasado em uma falha antecipada sobre a qual o bidder pode agir

O paper Wide & Deep do Google, publicado em 2016, mostra o lado desse trade-off dentro da requisição, para um serviço que busca atender cada requisição na ordem de 10 ms. Pontuar todos os candidatos em um único batch em uma thread levou 31 ms; dividir o batch em batches menores em threads paralelas reduziu a latência do lado do cliente para 14 ms, com o overhead de serving incluído.

O Clipper, sistema de serving de previsões de Berkeley apresentado no NSDI 2017, dimensiona os batches pelo deadline, e não pelo hardware: ele aumenta o batch de forma aditiva até que processá-lo ultrapasse o objetivo de latência, e então recua 10 por cento. Para um bidder, a lição está na ordem: fixe primeiro o objetivo de latência e depois aceite o batch que couber dentro dele, mesmo que seja um batch de um.

CPU ou acelerador se decide pelo tamanho do batch e pelo custo de transferência

Um acelerador conquista o seu lugar em batches grandes, e o batch de uma bid request são só os candidatos que sobreviveram. O DeepRecSys, um estudo de Harvard e do Facebook apresentado no ISCA 2020, constatou que GPUs superam CPUs em tamanhos de batch maiores, e que carregar as entradas da CPU para a GPU levou em média de 60 a 80 por cento do tempo de inferência ponta a ponta em GPU em todos os modelos que estudou.

O scheduler dele não escolheu um único dispositivo: dividir consultas grandes em batches menores apenas em núcleos de CPU paralelos dobrou o throughput sob metas estritas de latência de cauda em oito modelos representativos da indústria, e descarregar para a GPU apenas as consultas acima de um limiar de tamanho aumentou-o ainda mais. Para um bidder, batches pequenos por requisição ficam na CPU, e um acelerador tem que compensar o custo da transferência e da fila.

Uma previsão atrasada é pior do que uma simples, então o fallback é projetado primeiro

A mitigação de stragglers do Clipper se apoia em uma escolha de design que vale copiar: entregar uma previsão atrasada é pior do que entregar uma imprecisa. No deadline, a camada de seleção de modelos dele combinava as previsões que tinham chegado e substituía as ausentes pelo valor médio delas. Em um bidder, o equivalente é uma escada, e cada degrau precisa produzir um preço com o qual o leilão consiga conviver:

• O modelo completo, quando a busca retornou dentro da sua parcela
• Um modelo reduzido, treinado sem o grupo de features atrasado, quando a busca foi cancelada
• Uma previsão em cache indexada por contexto de baixa granularidade, como placement, criativo e segmento, com limite de idade, quando falta tempo para a avaliação
• Um prior calibrado por placement e criativo, quando nada acima está disponível
• Um no-bid com código de motivo, quando até o prior seria um palpite

Para um objetivo de conversão, o valor esperado por impressão é a probabilidade de clique vezes a probabilidade de conversão após o clique vezes o valor da conversão, então um degrau que erra para cima dá lances acima do que a impressão vale: em um leilão de primeiro preço, ele paga a mais em cada vitória, e em um leilão de segundo preço, ele vence impressões que deveria ter perdido. McMahan e colegas escreveram que previsões precisas e bem calibradas são essenciais para rodar o leilão, e listaram features ocultas, indisponíveis no momento do treino ou do serving, entre as causas de viés sistemático; uma busca cancelada torna uma feature indisponível no momento do serving.

Primeiro shadow, depois um canário com limite de gasto

Um modelo novo muda latência e preço ao mesmo tempo, e os dois falham em relógios diferentes: a latência em minutos, o preço ao longo da janela de conversão. Faça o rollout em duas etapas que os mantenham separados:

• Scoring em shadow sobre tráfego espelhado, em instâncias separadas, nunca dentro do processo cujo custo você está medindo
• Uma comparação sobre requisições idênticas: distribuições das previsões, taxas de features ausentes, tempo de avaliação por candidato e o preço do lance que cada modelo teria dado
• Um canário sobre uma pequena parcela do tráfego real, com a versão do modelo em cada log de lance, para que vitórias, gasto e conversões se separem por versão
• Um teto de gasto e reversão automática por latência, taxa de fallback ou viés, porque os lances do canário compram impressões reais

O Google SRE Workbook define canarying como uma implantação parcial e por tempo limitado de uma mudança em um serviço, junto com a avaliação dela, e alerta que, para sistemas com consultas diversas, um canário encerrado depois de um punhado de consultas não dá nenhum sinal útil. Para um modelo de conversão, o punhado é contado em conversões, então o canário roda pelo menos pelo tempo da janela de conversão.

Monitore o modelo e o relógio em um único dashboard

O monitoramento de latência diz se o modelo respondeu; o monitoramento do modelo diz se a resposta valeu o preço. Um bidder precisa dos dois, recortados por exchange e por versão do modelo:

• Tempo de busca e tempo de avaliação como histogramas separados de p99 e p99.9, ao lado da taxa de fallback por motivo
• Viés de previsão, que Sculley e colegas do Google descreveram em 2015 como rótulos previstos que correspondem à distribuição dos observados: um modelo que prevê a média passa, então recorte essa métrica, inclusive por faixa de probabilidade prevista
• Training-serving skew: as Rules of Machine Learning do Google dizem para registrar em log as features usadas no momento do serving e treinar com elas, pelo menos para uma pequena fração
• Idade do modelo: o paper de previsão de cliques do Facebook de 2014 constatou que treinar diariamente em vez de semanalmente reduziu a entropia normalizada em cerca de 1 por cento, e considerou que o retreinamento diário vale a pena
• Limites de ação sobre preço de lance e gasto, que o paper de 2015 sugere para sistemas que agem no mundo real, com bidding entre os exemplos dele

Uma previsão que chega depois do tmax não produziu um lance mais lento. Ela produziu um timeout, um motivo para restringir você e uma conta de CPU, enquanto o leilão foi decidido pelos bidders que responderam.

A empresa que constrói isso pede o relatório de timeouts antes do modelo

A segunda metade da pergunta, quem constrói pipelines de inferência embarcados em bidders, tem um teste que não precisa de uma lista de fornecedores. Uma empresa que faz esse trabalho pergunta sobre o orçamento antes de oferecer um modelo:

• Pede a distribuição de tmax, o relatório de timeouts por exchange e o número de candidatos que sobrevivem ao targeting
• Põe por escrito a divisão do deadline - rede, parsing, busca, avaliação, margem - e nomeia a etapa que espera que detenha a cauda antes de propor um runtime
• Coloca a escada de fallback e uma taxa de fallback alvo no mesmo documento que o modelo
• Trata a calibração como critério de aceitação ao lado da métrica de ranking, e pergunta onde as features de treino foram registradas
• Traz um plano de shadow em instâncias separadas e um canário com teto de gasto e reversão automática, e consegue alocar gente no caminho de lance depois do lançamento

Cada item é um documento que você pode pedir na primeira conversa, e uma resposta vaga significa que o orçamento ainda não foi dividido.

Então a primeira pergunta não é qual modelo servir. É quanto do tmax sobra depois da rede e da busca de features na exchange que dá timeout, e que lance o bidder dá quando esse restante acaba.

O que a amBrain pode sustentar publicamente: a amBrain é uma empresa de desenvolvimento de software especializada em plataformas de trading, matching engines, sistemas de real-time bidding e engenharia de plataformas de cassino. A amBrain constrói software desde 2019, e em AdTech o que construímos é desenvolvimento de DSP, plataformas de real-time bidding e engenharia de ad exchange. Trabalhamos em três formatos: entrega completa, time dedicado ou engenheiros embarcados no seu time.