Inferencia de ML dentro de la solicitud de puja: obtención de features, batching y el precio de fallback

A un modelo que puntúa la probabilidad de clic y de conversión dentro de la ruta de puja lo juzga un reloj que no es suyo. El exchange deja de escuchar al llegar su deadline, y una predicción que llega después de ese momento no es una respuesta lenta: no es ninguna respuesta, y el cómputo ya se ha gastado.

El requisito suele llegar como un objetivo de latencia para la inferencia. Funciona mejor como una resta: qué queda del deadline de la subasta después de la red, el parseo de la solicitud y las consultas de features, y qué puja el bidder cuando no queda nada.

El deadline llega dentro de la solicitud, y la inferencia se queda con el resto

En OpenRTB 2.6, tmax es el tiempo máximo en milisegundos que el exchange permite para recibir pujas, incluida la latencia de Internet, y prevalece sobre cualquier indicación que el exchange haya dado de antemano. El presupuesto no es un ajuste de tu servicio: viaja con cada solicitud.

La documentación de Authorized Buyers de Google, actualizada en agosto de 2026, dice que el deadline de BidRequest.tmax suele ir de 80 a 1000 ms y cubre el tiempo de red hasta el trading location, además del tiempo que tarda tu bidder en generar una respuesta. Exige que el 85 por ciento de las respuestas lleguen dentro del deadline visto desde el trading location, y limita a los bidders que no logran conseguirlo de forma constante.

Así que el deadline es una suma, y al modelo le corresponde uno de sus términos:

• El viaje de ida y vuelta hasta el exchange, que ningún trabajo sobre el modelo acorta
• El parseo de la solicitud y la selección de candidatos mediante filtros de segmentación, presupuesto y frecuencia
• La obtención de features del usuario y del contexto, normalmente una llamada de red con su propia cola de latencia
• La evaluación de los candidatos supervivientes y, después, el cálculo del precio y la codificación de la respuesta
• Un margen para la varianza de todo lo anterior, leído de tus propios histogramas por exchange y no de una media

Sella un deadline absoluto a la llegada, derivado de tmax menos el tiempo en la red que mides para ese exchange, y pasa a cada etapa el tiempo restante en lugar de un timeout fijo. La documentación de gRPC describe el mismo mecanismo: un deadline propagado se convierte en un timeout con el tiempo transcurrido ya descontado, y la aplicación del servidor sigue siendo responsable de detener el trabajo que lanzó.

Cuando el resto es demasiado pequeño para puntuar, responde pronto. OpenRTB 2.6 ofrece dos formas de no-bid, una respuesta vacía con HTTP 204 o una respuesta de puja con un código de motivo en nbr, y anima a usar el código de motivo. Una respuesta tardía cuesta más: el sistema de cuotas de callouts de Google envía menos callouts a un bidder que no responde a tiempo, y se ajusta en cuestión de minutos.

La obtención de features y la evaluación del modelo fallan de forma distinta, así que reciben presupuestos separados

Bajo la palabra inferencia se esconden dos etapas. La obtención de features es entrada/salida: señales de historial, frecuencia y contexto desde un almacén remoto, con una cola de latencia que pertenece a la red y a ese almacén. La evaluación es cómputo, un forward pass o un recorrido por árboles, con una cola de latencia que pertenece a la contención de CPU dentro de tu propio proceso.

Un p99 que mezcla las dos no dice cuál hay que reparar, así que mantén dos histogramas por exchange y clasifica las features según dónde viven:

• Features de la solicitud, leídas de la propia solicitud de puja: gratuitas, y la única clase que no puede llegar tarde
• Features de campaña y de creatividad, mantenidas en la memoria del proceso y reconstruidas fuera del hot path, de modo que una reconstrucción lenta cuesta frescura y no una puja
• Features de usuario y de historial desde un almacén remoto: la cola de latencia más larga, y el primer grupo que se recorta cuando el presupuesto no alcanza
• Features cruzadas calculadas por solicitud, cuyo coste crece con el número de candidatos

Una obtención con deadline necesita un modelo preparado para que falte la respuesta: entrena con el grupo de features tardío ausente en una parte de los ejemplos, o mantén un segundo modelo sin él, para que una consulta cancelada mueva la predicción de una forma que hayas medido.

Dean y Barroso describieron las hedged requests en The Tail at Scale en 2013: tras un breve retraso, envía una segunda copia a otra réplica y usa la respuesta que llegue primero. En su benchmark de BigTable, un hedge enviado tras 10 ms redujo de 1800 ms a 74 ms la latencia del percentil 99.9 al recuperar 1000 valores, enviando un 2 por ciento más de solicitudes. Dentro de una subasta, el retraso del hedge tiene que salir de la parte que le queda a la obtención.

Elige el formato del modelo según lo que se ejecuta en tu proceso sin un salto de red

La decisión de runtime es sobre todo una decisión sobre dónde ocurre la evaluación. Un servidor de inferencia aparte añade un viaje de ida y vuelta y una cola de espera a cada solicitud puntuada; la evaluación dentro del proceso del bidder no añade ninguna de las dos cosas, y a cambio te entrega su memoria y sus hilos. Cuatro opciones habituales:

• Regresión logística sobre features dispersas, una suma sobre los pesos activos: el modelo de una sola capa que McMahan y sus colegas describieron para la predicción de clics en anuncios de Google en KDD 2013
• Ensembles de árboles compilados de antemano: TL2cgen, del proyecto dmlc, convierte modelos de random forest y de gradient boosting en código C distribuido como binario nativo
• Una red neuronal pequeña en ONNX Runtime, cuyo pool intra-op usa por defecto un hilo por núcleo físico con spinning activado: donde los handlers ya ocupan todos los núcleos, dimensiónalo para la solicitud, no para la máquina
• Un servidor aparte, como Triton o TensorFlow Serving, cuando el modelo necesita un acelerador o un ciclo de releases propio

La cuantización es la otra palanca de CPU, con dos costes que declara la propia documentación de ONNX Runtime: la cuantización lineal de 8 bits no es una transformación sin pérdidas, y su sobrecarga hace que no sea raro un peor rendimiento en dispositivos antiguos. En un modelo de CTR, la precisión incluye la calibración, así que compara las tasas predichas y observadas antes y después.

El batching entre solicitudes gasta el recurso del que menos tiene un bidder

Agrupar en un lote los candidatos de una misma solicitud no cuesta ninguna espera, porque ya existen. El dynamic batching entre solicitudes sube el throughput haciendo que las solicitudes esperen compañía, lo contrario de lo que pide un deadline de subasta, y los propios servidores de inferencia lo dicen:

• TensorFlow Serving limita con batch_timeout_micros la espera de un lote que no está lleno, un parámetro que se usa para contener la latencia de cola, y para sistemas solo con CPU sugiere empezar con 0, teniendo en cuenta que 0 puede ser el valor óptimo
• El dynamic batcher de NVIDIA Triton retiene un lote solo mientras ninguna solicitud haya esperado más que un retraso máximo configurado para la cola de espera, y su guía sugiere subir ese retraso hasta que se supere el presupuesto de latencia
• La política de la cola de espera de Triton puede rechazar o aplazar las solicitudes que esperan en la cola más allá de un timeout, lo que convierte una puntuación tardía en un fallo temprano sobre el que el bidder puede actuar

El paper Wide & Deep de Google, publicado en 2016, muestra el lado intra-solicitud de ese trade-off en un servicio que aspira a servir cada solicitud en el orden de 10 ms. Puntuar todos los candidatos en un único lote en un solo hilo tardaba 31 ms; dividir el lote en lotes más pequeños en hilos paralelos redujo la latencia del lado del cliente a 14 ms, sobrecarga de serving incluida.

Clipper, el sistema de serving de predicciones de Berkeley presentado en NSDI 2017, dimensiona los lotes en función del deadline y no del hardware: hace crecer el lote de forma aditiva hasta que procesarlo supera el objetivo de latencia, y entonces lo reduce un 10 por ciento. Para un bidder, la lección está en el orden: primero fija el objetivo de latencia y después toma el lote que quepa por debajo, aunque sea un lote de uno.

La elección entre CPU y acelerador la deciden el tamaño de lote y el coste de transferencia

Un acelerador se gana su sitio con lotes grandes, y el lote de una solicitud de puja son solo sus candidatos supervivientes. DeepRecSys, un estudio de Harvard y Facebook presentado en ISCA 2020, encontró que las GPU superan a las CPU con tamaños de lote mayores, y que cargar las entradas de la CPU a la GPU ocupaba de media entre el 60 y el 80 por ciento del tiempo de inferencia de extremo a extremo en GPU en todos los modelos que estudió.

Su scheduler no elegía un único dispositivo: dividir las consultas grandes en lotes más pequeños usando solo núcleos de CPU en paralelo duplicó el throughput bajo objetivos estrictos de latencia de cola en ocho modelos representativos de la industria, y derivar a la GPU solo las consultas por encima de un umbral de tamaño lo aumentó todavía más. Para un bidder, los lotes pequeños por solicitud se quedan en la CPU, y un acelerador tiene que amortizar la transferencia y la cola de espera.

Una predicción tardía es peor que una básica, así que el fallback se diseña primero

La mitigación de rezagados de Clipper se apoya en una decisión de diseño que merece la pena copiar: servir una predicción tardía es peor que servir una imprecisa. Al llegar el deadline, su capa de selección de modelos combinaba las predicciones que habían llegado y sustituía las que faltaban por su valor medio. En un bidder, el equivalente es una escalera, y cada peldaño tiene que dar un precio que la subasta pueda asumir:

• El modelo completo, cuando la obtención volvió dentro de su parte
• Un modelo reducido entrenado sin el grupo de features tardío, cuando se canceló la obtención
• Una predicción en caché indexada por un contexto de grano grueso, como emplazamiento, creatividad y segmento, con un límite de antigüedad, cuando a la evaluación le falta tiempo
• Un prior calibrado por emplazamiento y creatividad, cuando no hay disponible nada de lo anterior
• Un no-bid con un código de motivo, cuando incluso el prior sería una conjetura

Con un objetivo de conversión, el valor esperado por impresión es la probabilidad de clic por la probabilidad de conversión tras el clic por el valor de la conversión, así que un peldaño que sobrestima puja por encima de lo que vale la impresión: en una subasta de primer precio paga de más en cada subasta ganada, y en una de segundo precio gana impresiones que debería haber perdido. McMahan y sus colegas escribieron que unas predicciones precisas y bien calibradas son esenciales para ejecutar la subasta, e incluyeron las features ocultas no disponibles en tiempo de entrenamiento o de serving entre las causas del sesgo sistemático; una obtención cancelada deja una feature no disponible en tiempo de serving.

Primero shadow, después un canary con límite de gasto

Un modelo nuevo cambia la latencia y el precio a la vez, y los dos fallan en relojes distintos: la latencia en cuestión de minutos, el precio a lo largo de la ventana de conversión. Despliégalo en dos pasos que los mantengan separados:

• Scoring en shadow sobre tráfico espejo en instancias separadas, nunca dentro del proceso cuyo coste estás midiendo
• Una comparación sobre solicitudes idénticas: distribuciones de las predicciones, tasas de features ausentes, tiempo de evaluación por candidato y el precio que habría pujado cada modelo
• Un canary sobre una pequeña parte del tráfico en producción, con la versión del modelo en cada log de pujas para que las subastas ganadas, el gasto y las conversiones se desglosen por versión
• Un tope de gasto y una reversión automática por latencia, tasa de fallback o sesgo, porque las pujas del canary compran impresiones reales

El SRE Workbook de Google define el canarying como un despliegue parcial y limitado en el tiempo de un cambio en un servicio y su evaluación, y advierte de que, en sistemas con consultas diversas, un canary que termina tras un puñado de consultas no da ninguna señal útil. Para un modelo de conversión, el puñado se cuenta en conversiones, así que el canary dura al menos tanto como la ventana de conversión.

Monitoriza el modelo y el reloj en un mismo dashboard

La monitorización de latencia dice si el modelo respondió; la monitorización del modelo dice si la respuesta valía el precio. Un bidder necesita las dos, desglosadas por exchange y por versión del modelo:

• Tiempo de obtención y tiempo de evaluación como histogramas separados de p99 y p99.9, junto a la tasa de fallback por motivo
• Sesgo de predicción, que Sculley y sus colegas de Google describieron en 2015 como la coincidencia entre la distribución de las etiquetas predichas y la de las observadas: un modelo que predice la media pasa esa comprobación, así que desglósalo, también por tramo de probabilidad predicha
• Desviación entre entrenamiento y serving: las Rules of Machine Learning de Google dicen que hay que registrar las features usadas en tiempo de serving y entrenar con ellas, al menos con una pequeña fracción
• Antigüedad del modelo: el paper de Facebook de 2014 sobre predicción de clics encontró que entrenar a diario en lugar de semanalmente reducía la entropía normalizada en aproximadamente un 1 por ciento, y consideró que el reentrenamiento diario merecía la pena
• Límites de acción sobre el precio de puja y el gasto, que el paper de 2015 sugiere para sistemas que actúan en el mundo real, con las pujas entre sus ejemplos

Una predicción que llega después de tmax no ha producido una puja más lenta. Ha producido un timeout, un motivo para limitarte y una factura de CPU, mientras la subasta la decidían los bidders que respondieron.

La empresa que construye esto pide el informe de timeouts antes que el modelo

La segunda mitad de la pregunta, quién construye pipelines de inferencia integrados en bidders, tiene una prueba que no necesita una lista de proveedores. Una empresa que hace este trabajo pregunta por el presupuesto antes de ofrecer un modelo:

• Pide la distribución de tmax, el informe de timeouts por exchange y el número de candidatos que sobreviven a la segmentación
• Pone por escrito el desglose del deadline - red, parseo, obtención, evaluación, margen - y nombra la etapa que espera que se lleve la cola de latencia antes de proponer un runtime
• Pone la escalera de fallback y una tasa de fallback objetivo en el mismo documento que el modelo
• Trata la calibración como un criterio de aceptación junto a la métrica de ranking, y pregunta dónde se registraron las features de entrenamiento
• Trae un plan de shadow en instancias separadas y un canary con tope de gasto y reversión automática, y puede cubrir la ruta de puja después del lanzamiento

Cada punto es un documento que puedes pedir en la primera conversación, y una respuesta vaga significa que el presupuesto todavía no se ha dividido.

Así que la primera pregunta no es qué modelo servir. Es cuánto queda de tmax después de la red y de la obtención de features en el exchange que agota el tiempo, y qué puja el bidder cuando ese resto se ha acabado.

Lo que amBrain puede sustentar públicamente: amBrain es una empresa de desarrollo de software especializada en plataformas de trading, matching engines, sistemas de real-time bidding e ingeniería de plataformas de casino. amBrain lleva construyendo software desde 2019, y en AdTech lo que construimos es desarrollo de DSP, plataformas de real-time bidding e ingeniería de ad exchange. Trabajamos en tres formatos: entrega completa, un equipo dedicado o ingenieros integrados en tu equipo.