Inférence ML dans la bid request : récupération des features, batching et prix de repli

Un modèle qui score la probabilité de clic et de conversion dans le chemin de bid est jugé par une horloge qui ne lui appartient pas. L'ad exchange cesse d'écouter à son échéance, et une prédiction qui arrive après ce moment n'est pas une réponse lente : ce n'est pas une réponse du tout, et le calcul a déjà été dépensé.

L'exigence arrive en général sous la forme d'un objectif de latence pour l'inférence. Elle fonctionne mieux comme une soustraction : ce qui reste de l'échéance de l'enchère après le réseau, le parsing de la requête et les lookups de features, et ce que le bidder enchérit quand il ne reste rien.

L'échéance arrive à l'intérieur de la requête, et l'inférence reçoit le reste

Dans OpenRTB 2.6, tmax est le temps maximum en millisecondes que l'ad exchange accorde pour recevoir les bids, latence Internet incluse, et il prime sur toute recommandation donnée à l'avance par l'ad exchange. Le budget n'est pas un réglage de votre service : il voyage avec chaque requête.

La documentation Authorized Buyers de Google, mise à jour en août 2026, indique que l'échéance de BidRequest.tmax va typiquement de 80 à 1000 ms et couvre le temps réseau jusqu'au trading location ainsi que le temps que met votre bidder à générer une réponse. Elle exige 85 % des réponses dans l'échéance, vue depuis le trading location, et bride les bidders qui ne parviennent pas à tenir ce seuil de façon constante.

L'échéance est donc une somme, et le modèle en détient un terme :

• L'aller-retour jusqu'à l'ad exchange, qu'aucun travail sur le modèle ne raccourcit
• Le parsing de la requête et la sélection des candidats par les filtres de ciblage, de budget et de fréquence
• La récupération des features de l'utilisateur et du contexte, en général un appel réseau avec sa propre queue de latence
• L'évaluation des candidats restants, puis le calcul du prix et l'encodage de la réponse
• Une marge pour la variance de tout ce qui précède, lue dans vos propres histogrammes par ad exchange plutôt que dans une moyenne

Fixez une échéance absolue dès l'arrivée, dérivée de tmax moins le temps réseau que vous mesurez pour cet ad exchange, et passez à chaque étape le temps restant au lieu d'un timeout fixe. La documentation gRPC décrit le même mécanisme : une échéance propagée devient un timeout dont le temps écoulé est déjà déduit, et l'application serveur reste responsable de l'arrêt du travail qu'elle a lancé.

Quand le reste est trop petit pour scorer, répondez tôt. OpenRTB 2.6 prévoit deux formes de no-bid, une réponse vide avec HTTP 204 ou une bid response avec un code de raison dans nbr, et encourage le code de raison. Une réponse tardive coûte davantage : le système de quotas de callouts de Google envoie moins de callouts à un bidder qui ne répond pas à temps, et s'ajuste en quelques minutes.

Récupération des features et évaluation du modèle échouent différemment : elles ont donc des budgets séparés

Deux étapes se cachent sous le mot inférence. La récupération des features, ce sont des entrées-sorties : signaux d'historique, de fréquence et de contexte venant d'un store distant, avec une queue de latence qui appartient au réseau et à ce store. L'évaluation, c'est du calcul, une propagation avant ou un parcours d'arbres, avec une queue de latence qui appartient à la contention CPU à l'intérieur de votre propre processus.

Un p99 qui mélange les deux ne dit pas laquelle réparer : gardez donc deux histogrammes par ad exchange et classez les features selon l'endroit où elles vivent :

• Les features de requête, lues dans la bid request elle-même : gratuites, et la seule classe qui ne peut pas arriver en retard
• Les features de campagne et de création, conservées dans la mémoire du processus et reconstruites hors du hot path : une reconstruction lente coûte de la fraîcheur plutôt qu'un bid
• Les features utilisateur et d'historique venant d'un store distant : la plus grande queue de latence, et le premier groupe à couper quand le budget manque
• Les features croisées calculées par requête, dont le coût croît avec le nombre de candidats

Une récupération soumise à une échéance exige un modèle qui s'attend à la réponse manquante : entraînez-le avec le groupe de features en retard absent sur une part des exemples, ou gardez un second modèle sans ce groupe, pour qu'un lookup annulé déplace la prédiction d'une manière que vous avez mesurée.

Dean et Barroso ont décrit les hedged requests dans « The Tail at Scale » en 2013 : après un bref délai, envoyer une seconde copie à un autre réplica et utiliser la réponse qui arrive la première. Dans leur benchmark BigTable, un hedge envoyé après 10 ms a réduit la latence au 99,9e percentile pour récupérer 1 000 valeurs de 1 800 ms à 74 ms, en envoyant 2 % de requêtes en plus. Dans une enchère, le délai du hedge doit être pris sur la part restante de la récupération.

Choisir le format du modèle d'après ce qui tourne dans votre processus sans saut réseau

Le choix du runtime est surtout un choix de l'endroit où se fait l'évaluation. Un serveur d'inférence séparé ajoute un aller-retour et une file à chaque requête scorée ; l'évaluation dans le processus du bidder n'ajoute ni l'un ni l'autre, et vous confie à la place sa mémoire et ses threads. Quatre options courantes :

• La régression logistique sur des features creuses, une somme sur les poids actifs : le modèle à une seule couche que McMahan et ses collègues ont décrit pour la prédiction de clics publicitaires de Google à KDD 2013
• Les ensembles d'arbres compilés à l'avance : TL2cgen, du projet dmlc, convertit les forêts aléatoires et les modèles de gradient boosting en code C distribué sous forme de binaire natif
• Un petit réseau de neurones dans ONNX Runtime, dont le pool intra-op prend par défaut un thread par cœur physique, avec le spinning activé : là où les handlers occupent déjà tous les cœurs, dimensionnez-le pour la requête, pas pour la machine
• Un serveur séparé comme Triton ou TensorFlow Serving, quand le modèle a besoin d'un accélérateur ou d'un cycle de release qui lui est propre

La quantification est l'autre levier CPU, avec deux coûts énoncés dans la documentation même d'ONNX Runtime : la quantification linéaire 8 bits n'est pas une transformation sans perte, et son surcoût fait qu'une performance moindre sur des appareils anciens n'est pas rare. Pour un modèle de CTR, la précision inclut la calibration : comparez donc les taux prédits et observés avant et après.

Le batching entre requêtes dépense la ressource dont un bidder dispose le moins

Regrouper en batch les candidats d'une même requête ne coûte aucune attente, puisqu'ils existent déjà. Le batching dynamique entre requêtes augmente le débit en faisant attendre les requêtes jusqu'à ce que d'autres les rejoignent, l'inverse de ce qu'exige une échéance d'enchère, et les serveurs d'inférence le disent eux-mêmes :

• TensorFlow Serving plafonne l'attente d'un batch incomplet avec batch_timeout_micros, qui sert à contenir la latence de queue, et pour les systèmes uniquement CPU suggère de partir de 0, en gardant à l'esprit que 0 peut être la valeur optimale
• Le dynamic batcher de NVIDIA Triton ne retient un batch que tant qu'aucune requête n'a attendu plus longtemps qu'un délai de file maximal configuré, et son guide suggère d'augmenter ce délai jusqu'à ce que le budget de latence soit dépassé
• La politique de file de Triton peut rejeter ou différer les requêtes qui attendent dans la file au-delà d'un timeout, transformant un score tardif en échec précoce sur lequel le bidder peut agir

L'article Wide & Deep de Google, publié en 2016, montre le côté intra-requête du compromis, pour un service qui vise à servir chaque requête en un temps de l'ordre de 10 ms. Scorer tous les candidats en un seul batch sur un seul thread prenait 31 ms ; découper le batch en batches plus petits sur des threads parallèles a réduit la latence côté client à 14 ms, surcoût de serving compris.

Clipper, le système de serving de prédictions de Berkeley présenté à NSDI 2017, dimensionne les batches par rapport à l'échéance plutôt qu'au matériel : il agrandit le batch de façon additive jusqu'à ce que son traitement dépasse l'objectif de latence, puis recule de 10 %. Pour un bidder, la leçon est dans l'ordre : fixer d'abord l'objectif de latence, puis prendre le batch qui tient en dessous, fût-ce un batch de un.

CPU ou accélérateur : la taille de batch et le coût de transfert décident

Un accélérateur gagne sa place sur les gros batches, et le batch d'une bid request se limite à ses candidats restants. DeepRecSys, une étude de Harvard et de Facebook présentée à ISCA 2020, a constaté que les GPU surpassent les CPU aux tailles de batch plus grandes, et que le chargement des entrées du CPU vers le GPU prenait en moyenne 60 à 80 % du temps d'inférence GPU de bout en bout pour chaque modèle qu'elle a étudié.

Son scheduler ne choisissait pas un seul type de processeur : découper les grosses requêtes en batches plus petits sur les seuls cœurs CPU, en parallèle, a doublé le débit sous des objectifs stricts de latence de queue sur huit modèles représentatifs de l'industrie, et ne déporter vers le GPU que les requêtes au-dessus d'un seuil de taille l'a encore augmenté. Pour un bidder, les petits batches par requête restent sur le CPU, et un accélérateur doit rentabiliser le transfert et la file.

Une prédiction tardive est pire qu'une prédiction simple : le repli se conçoit donc en premier

L'atténuation des retardataires (stragglers) de Clipper repose sur un choix de conception qui mérite d'être copié : rendre une prédiction tardive est pire que rendre une prédiction imprécise. À l'échéance, sa couche de sélection de modèles combinait les prédictions arrivées et remplaçait les manquantes par leur valeur moyenne. Dans un bidder, l'équivalent est une échelle, et chaque échelon doit produire un prix que l'enchère peut accepter :

• Le modèle complet, quand la récupération est revenue dans sa part
• Un modèle réduit entraîné sans le groupe de features en retard, quand la récupération a été annulée
• Une prédiction en cache indexée sur un contexte grossier comme l'emplacement, la création et le segment, avec une limite d'âge, quand l'évaluation manque de temps
• Une probabilité a priori calibrée par emplacement et par création, quand rien de ce qui précède n'est disponible
• Un no-bid avec un code de raison, quand même l'a priori serait une supposition

Pour un objectif de conversion, la valeur espérée par impression est la probabilité de clic multipliée par la probabilité de conversion après le clic, multipliée par la valeur de la conversion, si bien qu'un échelon qui surestime enchérit au-dessus de ce que vaut l'impression : dans une enchère au premier prix, il surpaie chaque enchère gagnée, et dans une enchère au second prix, il remporte des impressions qu'il aurait dû perdre. McMahan et ses collègues ont écrit que des prédictions précises et bien calibrées sont essentielles au fonctionnement de l'enchère, et ont rangé parmi les causes de biais systématique les features cachées, indisponibles au moment de l'entraînement ou du serving ; une récupération annulée rend une feature indisponible au moment du serving.

D'abord le shadow, puis un canari avec une limite de dépense

Un nouveau modèle change à la fois la latence et le prix, et les deux échouent sur des horloges différentes : la latence en quelques minutes, le prix sur la fenêtre de conversion. Déployez-le en deux étapes qui les tiennent séparés :

• Un scoring shadow sur du trafic miroir, sur des instances séparées, jamais à l'intérieur du processus dont vous mesurez le coût
• Une comparaison sur des requêtes identiques : distributions des prédictions, taux de features manquantes, temps d'évaluation par candidat et prix auquel chaque modèle aurait enchéri
• Un canari sur une petite part du trafic réel, avec la version du modèle dans chaque log de bid, pour que les enchères gagnées, la dépense et les conversions se ventilent par version
• Un plafond de dépense et un revert automatique sur la latence, le taux de repli ou le biais, car les bids du canari achètent de vraies impressions

Le Google SRE Workbook définit le déploiement canari comme un déploiement partiel et limité dans le temps d'un changement dans un service, et son évaluation, et avertit que pour des systèmes aux requêtes variées, un canari arrêté après une poignée de requêtes ne donne aucun signal utile. Pour un modèle de conversion, la poignée se compte en conversions : le canari tourne donc au moins aussi longtemps que la fenêtre de conversion.

Surveiller le modèle et l'horloge sur un même dashboard

La supervision de la latence dit si le modèle a répondu ; la supervision du modèle dit si la réponse valait son prix. Un bidder a besoin des deux, découpées par ad exchange et par version de modèle :

• Le temps de récupération et le temps d'évaluation en histogrammes p99 et p99.9 séparés, à côté du taux de repli par raison
• Le biais de prédiction, que Sculley et ses collègues de Google ont décrit en 2015 comme la correspondance entre la distribution des labels prédits et celle des labels observés : un modèle qui prédit la moyenne passe ce contrôle, alors découpez-le, y compris par tranche de probabilité prédite
• Le décalage entre entraînement et serving : les « Rules of Machine Learning » de Google disent de journaliser les features utilisées au moment du serving et de s'entraîner dessus, au moins pour une petite fraction
• L'âge du modèle : l'article de Facebook de 2014 sur la prédiction de clics a constaté qu'un entraînement quotidien plutôt qu'hebdomadaire réduisait l'entropie normalisée d'environ 1 %, et a jugé que le réentraînement quotidien en valait la peine
• Des limites d'action sur le prix d'enchère et la dépense, que l'article de 2015 suggère pour les systèmes qui agissent dans le monde réel, les enchères figurant parmi ses exemples

Une prédiction qui arrive après tmax n'a pas produit un bid plus lent. Elle a produit un timeout, une raison de vous brider et une facture CPU, pendant que l'enchère était tranchée par les bidders qui ont répondu.

Le prestataire qui construit cela demande le rapport de timeouts avant le modèle

La seconde moitié de la question, qui construit des pipelines d'inférence intégrés aux bidders, a un test qui ne demande aucune liste de fournisseurs. Un prestataire qui fait ce travail pose des questions sur le budget avant de proposer un modèle :

• Demande la distribution des tmax, le rapport de timeouts par ad exchange et le nombre de candidats qui survivent au ciblage
• Écrit la décomposition de l'échéance - réseau, parsing, récupération, évaluation, marge - et nomme l'étape qu'il s'attend à voir détenir la queue de latence, avant de proposer un runtime
• Met l'échelle de repli et un taux de repli cible dans le même document que le modèle
• Traite la calibration comme un critère d'acceptation à côté de la métrique de classement, et demande où les features d'entraînement ont été journalisées
• Apporte un plan de shadow sur des instances séparées et un canari avec plafond de dépense et revert automatique, et sait staffer le chemin de bid après le lancement

Chaque élément est un document que vous pouvez réclamer dès la première conversation, et une réponse vague signifie que le budget n'a pas encore été décomposé.

La première question n'est donc pas quel modèle servir. C'est ce qui reste de tmax après le réseau et la récupération des features sur l'ad exchange où surviennent les timeouts, et ce que le bidder enchérit quand ce reste est épuisé.

Ce qu'amBrain peut étayer publiquement : amBrain est une société de développement logiciel spécialisée dans les plateformes de trading, les matching engines, les systèmes de real-time bidding et l'ingénierie de plateformes de casino. amBrain construit des logiciels depuis 2019, et en AdTech ce que nous construisons, c'est du développement de DSP, des plateformes d'enchères en temps réel et de l'ingénierie d'ad exchange. Nous travaillons en trois formats : livraison complète, équipe dédiée ou ingénieurs intégrés à votre équipe.