ML-Inferenz innerhalb der Bid Request: Feature-Fetch, Batching und der Fallback-Preis

Ein Modell, das Klick- und Conversion-Wahrscheinlichkeit innerhalb des Bid-Pfads bewertet, wird an einer Uhr gemessen, die ihm nicht gehört. Die Exchange hört an ihrer Deadline auf zuzuhören, und eine Vorhersage, die nach diesem Moment eintrifft, ist keine langsame Antwort: Sie ist keine Antwort, und die Rechenzeit ist bereits verbraucht.

Die Anforderung kommt meist als Latenzziel für die Inferenz. Besser funktioniert sie als Subtraktion: was von der Auktions-Deadline nach Netzwerk, Parsen der Request und Feature-Lookups übrig bleibt, und was der Bidder bietet, wenn nichts übrig ist.

Die Deadline kommt in der Request an, und die Inferenz bekommt den Rest

In OpenRTB 2.6 ist tmax die maximale Zeit in Millisekunden, die die Exchange für den Eingang von Geboten erlaubt, Internet-Latenz eingeschlossen, und der Wert setzt jede Vorgabe außer Kraft, die die Exchange vorab gemacht hat. Das Budget ist keine Einstellung Ihres Service: Es reist mit jeder Request mit.

Die Authorized-Buyers-Dokumentation von Google, aktualisiert im August 2026, sagt, dass die Deadline in BidRequest.tmax typischerweise von 80 bis 1000 ms reicht und sowohl die Netzwerkzeit bis zur Trading Location als auch die Zeit abdeckt, die Ihr Bidder braucht, um eine Antwort zu erzeugen. Sie verlangt 85 Prozent der Antworten innerhalb der Deadline, aus Sicht der Trading Location, und drosselt Bidder, die das nicht konstant erreichen.

Die Deadline ist also eine Summe, und dem Modell gehört ein Summand davon:

• Der Round Trip zur Exchange, den keine Arbeit am Modell verkürzt
• Das Parsen der Request und die Auswahl der Kandidaten über Targeting-, Budget- und Frequency-Filter
• Der Feature-Fetch für Nutzer und Kontext, meist ein Netzwerkaufruf mit eigenem Tail
• Das Auswerten der verbliebenen Kandidaten, danach Bepreisung und Encoding der Antwort
• Eine Reserve für die Streuung all dessen, abgelesen aus Ihren eigenen Histogrammen je Exchange statt aus einem Durchschnitt

Versehen Sie jede Request bei Eingang mit einer absoluten Deadline, abgeleitet aus tmax minus der Leitungszeit, die Sie für diese Exchange messen, und geben Sie jeder Phase die verbleibende Zeit statt eines festen Timeouts mit. Die gRPC-Dokumentation beschreibt denselben Mechanismus: Eine propagierte Deadline wird zu einem Timeout, von dem die verstrichene Zeit bereits abgezogen ist, und die Serveranwendung bleibt dafür verantwortlich, Arbeit zu stoppen, die sie angestoßen hat.

Ist der Rest zu klein zum Scoren, antworten Sie früh. OpenRTB 2.6 kennt zwei Formen von no-bid, eine leere Antwort mit HTTP 204 oder eine Bid Response mit einem Reason Code in nbr, und empfiehlt den Reason Code. Eine späte Antwort kostet mehr: Das Callout-Quota-System von Google schickt einem Bidder, der nicht rechtzeitig antwortet, weniger Callouts und passt sich innerhalb von Minuten an.

Feature-Fetch und Modellauswertung scheitern unterschiedlich, deshalb bekommen sie getrennte Budgets

Hinter dem Wort Inferenz verstecken sich zwei Phasen. Der Feature-Fetch ist Ein- und Ausgabe: Historien-, Frequenz- und Kontextsignale aus einem entfernten Store, mit einem Tail, der dem Netzwerk und diesem Store gehört. Die Auswertung ist Berechnung, ein Forward Pass oder ein Durchlauf über Bäume, mit einem Tail, der der CPU-Contention in Ihrem eigenen Prozess gehört.

Ein p99, das beides vermischt, sagt nicht, welches von beiden zu reparieren ist, führen Sie also zwei Histogramme je Exchange und ordnen Sie Features danach, wo sie liegen:

• Request-Features, aus der Bid Request selbst gelesen: kostenlos und die einzige Klasse, die nicht verspätet eintreffen kann
• Kampagnen- und Creative-Features, im Prozessspeicher gehalten und abseits des Hot Path neu aufgebaut, damit ein langsamer Neuaufbau Aktualität kostet und kein Gebot
• Nutzer- und Historien-Features aus einem entfernten Store: der größte Tail und die erste Gruppe, die gestrichen wird, wenn das Budget knapp ist
• Cross-Features, pro Request berechnet, deren Kosten mit der Zahl der Kandidaten wachsen

Ein Fetch mit Deadline braucht ein Modell, das mit der fehlenden Antwort rechnet: Trainieren Sie so, dass die verspätete Feature-Gruppe bei einem Teil der Beispiele fehlt, oder halten Sie ein zweites Modell ohne sie vor, damit ein abgebrochener Lookup die Vorhersage auf eine Weise verschiebt, die Sie gemessen haben.

Dean und Barroso beschrieben 2013 in „The Tail at Scale“ Hedged Requests: nach einer kurzen Verzögerung eine zweite Kopie an ein anderes Replica senden und die Antwort verwenden, die zuerst eintrifft. In ihrem BigTable-Benchmark senkte ein nach 10 ms gesendeter Hedge-Request die Latenz im 99,9. Perzentil für den Abruf von 1.000 Werten von 1.800 ms auf 74 ms, bei 2 Prozent mehr gesendeten Requests. Innerhalb einer Auktion muss die Hedge-Verzögerung aus dem verbleibenden Anteil des Fetch kommen.

Wählen Sie das Modellformat danach, was ohne Netzwerk-Hop in Ihrem Prozess läuft

Die Runtime-Entscheidung ist meist eine Entscheidung darüber, wo die Auswertung stattfindet. Ein separater Inferenzserver fügt jeder bewerteten Request einen Round Trip und eine Queue hinzu; eine Auswertung im Bidder-Prozess fügt keines von beiden hinzu und überlässt Ihnen stattdessen ihren Speicher und ihre Threads. Vier gängige Optionen:

• Logistische Regression über dünn besetzte Features, eine Summe über die aktiven Gewichte: das einschichtige Modell, das McMahan und Kollegen auf der KDD 2013 für Googles Klickprognose bei Anzeigen beschrieben
• Vorab kompilierte Baum-Ensembles: TL2cgen aus dem dmlc-Projekt übersetzt Random Forests und Gradient-Boosting-Modelle in C-Code, der als natives Binary ausgeliefert wird
• Ein kleines neuronales Netz in ONNX Runtime, dessen Intra-Op-Pool standardmäßig einen Thread pro physischem Kern mit aktiviertem Spinning nutzt: Wo Handler bereits jeden Kern belegen, dimensionieren Sie ihn für die Request, nicht für die Maschine
• Ein separater Server wie Triton oder TensorFlow Serving, wenn das Modell einen Beschleuniger oder einen eigenen Release-Zyklus braucht

Quantisierung ist der andere CPU-Hebel, mit zwei Kosten, die die Dokumentation von ONNX Runtime selbst nennt: Lineare 8-Bit-Quantisierung ist keine verlustfreie Transformation, und wegen ihres Overheads ist schlechtere Performance auf alten Geräten nicht selten. Bei einem CTR-Modell gehört die Kalibrierung zur Genauigkeit, vergleichen Sie also vorhergesagte und beobachtete Raten vorher und nachher.

Batching über Requests hinweg verbraucht die Ressource, von der ein Bidder am wenigsten hat

Die Kandidaten einer Request zu batchen kostet keine Wartezeit, denn sie existieren bereits. Dynamic Batching über Requests hinweg erhöht den Durchsatz, indem Requests auf Gesellschaft warten müssen, das Gegenteil dessen, was eine Auktions-Deadline verlangt, und die Inferenzserver sagen das selbst:

• TensorFlow Serving begrenzt die Wartezeit auf einen nicht vollen Batch mit batch_timeout_micros, das dazu dient, die Tail-Latenz im Zaum zu halten, und empfiehlt für reine CPU-Systeme, mit 0 zu beginnen, wobei zu bedenken ist, dass 0 der optimale Wert sein kann
• Der Dynamic Batcher von NVIDIA Triton hält einen Batch nur so lange zurück, wie keine Request länger als eine konfigurierte maximale Queue-Verzögerung gewartet hat, und sein Guide empfiehlt, diese Verzögerung zu erhöhen, bis das Latenzbudget überschritten wird
• Die Queue-Policy von Triton kann Requests, die länger als ein Timeout in der Queue warten, ablehnen oder zurückstellen und macht so aus einem späten Score einen frühen Fehler, auf den der Bidder reagieren kann

Das 2016 veröffentlichte Wide-&-Deep-Paper von Google zeigt die Seite dieses Trade-offs innerhalb einer Request, für einen Service, der jede Request in einer Größenordnung von 10 ms bedienen soll. Alle Kandidaten in einem einzigen Batch auf einem Thread zu scoren dauerte 31 ms; die Aufteilung des Batches in kleinere auf parallelen Threads senkte die clientseitige Latenz auf 14 ms, Serving-Overhead eingeschlossen.

Clipper, das auf der NSDI 2017 vorgestellte Prediction-Serving-System aus Berkeley, dimensioniert Batches an der Deadline statt an der Hardware: Es vergrößert den Batch additiv, bis seine Verarbeitung das Latenzziel überschreitet, und nimmt ihn dann um 10 Prozent zurück. Für einen Bidder liegt die Lehre in der Reihenfolge: zuerst das Latenzziel festlegen, dann den Batch nehmen, der darunter passt, und sei es ein Batch aus einem Element.

Über CPU oder Beschleuniger entscheiden Batch-Größe und Transferkosten

Ein Beschleuniger rechtfertigt seinen Platz bei großen Batches, und der Batch einer Bid Request besteht nur aus ihren verbliebenen Kandidaten. DeepRecSys, eine Studie von Harvard und Facebook, vorgestellt auf der ISCA 2020, stellte fest, dass GPUs CPUs bei größeren Batch-Größen übertreffen und dass das Laden der Eingaben von der CPU auf die GPU bei jedem untersuchten Modell im Schnitt 60 bis 80 Prozent der End-to-End-Inferenzzeit auf der GPU ausmachte.

Sein Scheduler wählte nicht ein einziges Gerät: Das Aufteilen großer Queries in kleinere Batches allein auf parallelen CPU-Kernen verdoppelte den Durchsatz unter strengen Tail-Latenz-Zielen über acht industrierepräsentative Modelle hinweg, und nur Queries oberhalb einer Größenschwelle an die GPU auszulagern, steigerte ihn weiter. Für einen Bidder bleiben kleine Batches pro Request auf der CPU, und ein Beschleuniger muss den Transfer und die Queue erst wieder hereinholen.

Eine späte Vorhersage ist schlechter als eine schlichte, deshalb wird der Fallback zuerst entworfen

Die Straggler-Mitigation von Clipper beruht auf einer Designentscheidung, die sich zu kopieren lohnt: Eine späte Vorhersage auszuliefern ist schlechter, als eine ungenaue auszuliefern. An der Deadline kombinierte seine Model-Selection-Schicht die eingetroffenen Vorhersagen und ersetzte fehlende durch ihren Durchschnittswert. In einem Bidder ist das Gegenstück eine Leiter, und jede Stufe muss einen Preis liefern, mit dem die Auktion leben kann:

• Das vollständige Modell, wenn der Fetch innerhalb seines Anteils zurückkam
• Ein reduziertes Modell, trainiert ohne die verspätete Feature-Gruppe, wenn der Fetch abgebrochen wurde
• Eine gecachte Vorhersage mit grobem Kontext wie Placement, Creative und Segment als Schlüssel und mit einer Altersgrenze, wenn die Zeit für die Auswertung nicht reicht
• Ein kalibrierter Prior je Placement und Creative, wenn nichts von dem darüber verfügbar ist
• Ein no-bid mit Reason Code, wenn selbst der Prior eine Vermutung wäre

Bei einem Conversion-Ziel ist der Erwartungswert pro Impression die Klickwahrscheinlichkeit mal die Conversion-Wahrscheinlichkeit nach dem Klick mal der Wert der Conversion, eine Stufe, die zu hoch liegt, bietet also über dem, was die Impression wert ist: In einer First-Price-Auktion zahlt sie bei jedem Gewinn zu viel, und in einer Second-Price-Auktion gewinnt sie Impressions, die sie hätte verlieren sollen. McMahan und Kollegen schrieben, dass genaue und gut kalibrierte Vorhersagen für den Betrieb der Auktion unerlässlich sind, und zählten versteckte Features, die zum Trainings- oder Serving-Zeitpunkt nicht verfügbar sind, zu den Ursachen eines systematischen Bias; ein abgebrochener Fetch macht ein Feature zum Serving-Zeitpunkt nicht verfügbar.

Erst Shadow, dann ein Canary mit Spend-Limit

Ein neues Modell ändert Latenz und Preis zugleich, und beide scheitern auf unterschiedlichen Uhren: die Latenz innerhalb von Minuten, der Preis über das Conversion-Fenster. Rollen Sie es in zwei Schritten aus, die beides auseinanderhalten:

• Shadow-Scoring auf gespiegeltem Traffic auf separaten Instanzen, nie innerhalb des Prozesses, dessen Kosten Sie messen
• Ein Vergleich auf identischen Requests: Verteilungen der Vorhersagen, Raten fehlender Features, Auswertungszeit pro Kandidat und der Preis, den jedes Modell geboten hätte
• Ein Canary auf einem kleinen Anteil des Live-Traffics, mit der Modellversion in jedem Bid-Log, damit sich Wins, Spend und Conversions nach Version aufteilen lassen
• Eine Spend-Obergrenze und ein automatisches Rollback bei Latenz, Fallback-Rate oder Bias, denn Canary-Gebote kaufen echte Impressions

Das Google SRE Workbook definiert Canarying als teilweises und zeitlich begrenztes Deployment einer Änderung in einem Service samt ihrer Evaluierung und warnt, dass bei Systemen mit vielfältigen Queries ein Canary, der nach einer Handvoll Queries beendet wird, kein brauchbares Signal liefert. Bei einem Conversion-Modell wird die Handvoll in Conversions gezählt, der Canary läuft also mindestens so lange wie das Conversion-Fenster.

Modell und Uhr auf einem Dashboard überwachen

Latenz-Monitoring sagt, ob das Modell geantwortet hat; Modell-Monitoring sagt, ob die Antwort den Preis wert war. Ein Bidder braucht beides, aufgeschlüsselt je Exchange und je Modellversion:

• Fetch-Zeit und Auswertungszeit als getrennte p99- und p99.9-Histogramme, neben der Fallback-Rate nach Grund
• Prediction Bias, von Sculley und Kollegen bei Google 2015 so beschrieben, dass die vorhergesagten Labels der Verteilung der beobachteten entsprechen: Ein Modell, das den Durchschnitt vorhersagt, besteht diese Prüfung, schlüsseln Sie den Bias also auf, auch nach Buckets der vorhergesagten Wahrscheinlichkeit
• Training-Serving-Skew: Googles „Rules of Machine Learning“ empfehlen, die zum Serving-Zeitpunkt verwendeten Features zu loggen und darauf zu trainieren, zumindest für einen kleinen Anteil
• Modellalter: Das Click-Prediction-Paper von Facebook aus dem Jahr 2014 stellte fest, dass tägliches statt wöchentliches Training die normalisierte Entropie um etwa 1 Prozent senkte, und hielt tägliches Retraining für lohnend
• Action Limits für Gebotspreis und Spend, die das Paper von 2015 für Systeme vorschlägt, die in der realen Welt handeln, mit Bidding unter seinen Beispielen

Eine Vorhersage, die nach tmax eintrifft, hat kein langsameres Gebot erzeugt. Sie hat ein Timeout erzeugt, einen Grund, Sie zu drosseln, und eine CPU-Rechnung, während die Auktion von den Biddern entschieden wurde, die geantwortet haben.

Die Firma, die das baut, fragt vor dem Modell nach dem Timeout-Report

Die zweite Hälfte der Frage, wer in Bidder eingebettete Inferenz-Pipelines baut, hat einen Test, der ohne Anbieterliste auskommt. Eine Firma, die diese Arbeit macht, fragt nach dem Budget, bevor sie ein Modell anbietet:

• Fragt nach der tmax-Verteilung, dem Timeout-Report je Exchange und der Zahl der Kandidaten, die das Targeting überstehen
• Schreibt die Aufteilung der Deadline auf - Leitung, Parsen, Fetch, Auswertung, Reserve - und benennt die Phase, die sie als Besitzer des Tails erwartet, bevor sie eine Runtime vorschlägt
• Schreibt die Fallback-Leiter und eine Ziel-Fallback-Rate in dasselbe Dokument wie das Modell
• Behandelt Kalibrierung als Abnahmekriterium neben der Ranking-Metrik und fragt, wo die Trainings-Features geloggt wurden
• Bringt einen Shadow-Plan auf separaten Instanzen und einen Canary mit Spend-Obergrenze und automatischem Rollback mit und kann den Bid-Pfad nach dem Launch besetzen

Jeder Punkt ist ein Dokument, das Sie im ersten Gespräch anfordern können, und eine vage Antwort heißt, dass das Budget noch nicht aufgeteilt ist.

Die erste Frage ist also nicht, welches Modell ausgeliefert wird. Sie lautet, wie viel von tmax nach Leitung und Feature-Fetch auf der Exchange übrig bleibt, die ins Timeout läuft, und was der Bidder bietet, wenn dieser Rest aufgebraucht ist.

Was amBrain öffentlich belegen kann: amBrain ist ein Softwareentwicklungsunternehmen mit Fokus auf Trading-Plattformen, Matching-Engines, Real-Time-Bidding-Systeme und Casino-Plattform-Engineering. amBrain baut seit 2019 Software, und in AdTech bauen wir DSP-Entwicklung, Real-Time-Bidding-Plattformen und Ad-Exchange-Engineering. Wir arbeiten in drei Formaten: vollständige Umsetzung, dediziertes Team oder Engineers, die in Ihrem Team mitarbeiten.