Bid Request İçinde ML Çıkarımı: Feature Çekme, Batching ve Fallback Fiyatı

Tıklama ve dönüşüm olasılığını teklif yolunun içinde puanlayan bir model, sahibi olmadığı bir saatle yargılanır. Exchange kendi deadline'ında dinlemeyi bırakır ve o andan sonra gelen bir tahmin yavaş bir yanıt değildir: hiç yanıt değildir ve hesaplama çoktan harcanmıştır.

Gereksinim genellikle çıkarım için bir latency hedefi olarak gelir. Bir çıkarma işlemi olarak daha iyi işler: ağdan, isteğin ayrıştırılmasından ve feature sorgularından sonra açık artırma deadline'ından geriye ne kaldığı ve hiçbir şey kalmadığında bidder'ın ne teklif ettiği.

Deadline isteğin içinde gelir ve çıkarıma kalan süre düşer

OpenRTB 2.6'da tmax, exchange'in tekliflerin alınması için tanıdığı, İnternet gecikmesi dahil milisaniye cinsinden azami süredir ve exchange'in önceden verdiği tüm yönlendirmelerin yerine geçer. Bütçe, servisinizin bir ayarı değildir: her istekle birlikte taşınır.

Google'ın Ağustos 2026'da güncellenen Authorized Buyers dokümantasyonu, BidRequest.tmax içindeki deadline'ın tipik olarak 80 ile 1000 ms arasında değiştiğini ve bidder'ınızın yanıt üretmek için harcadığı sürenin yanı sıra işlem noktasına kadar olan ağ süresini de kapsadığını söyler. Yanıtların %85'inin işlem noktasından bakıldığında deadline içinde kalmasını şart koşar ve bunu tutarlı biçimde başaramayan bidder'ları kısıtlar.

Yani deadline bir toplamdır ve model bunun bir teriminin sahibidir:

• Exchange'e gidiş-dönüş; model üzerinde yapılan hiçbir iş bunu kısaltmaz
• İsteğin ayrıştırılması ve hedefleme, bütçe ve frekans filtreleriyle adayların seçilmesi
• Kullanıcı ve bağlam için feature çekme; genellikle kendi tail latency'si olan bir ağ çağrısıdır
• Elemeden geçen adayların değerlendirilmesi, ardından yanıtın fiyatlanması ve kodlanması
• Yukarıdakilerin tümünün varyansı için bir pay; bir ortalamadan değil, kendi exchange bazındaki histogramlarınızdan okunur

İstek geldiğinde, tmax'tan o exchange için ölçtüğünüz hat süresi çıkarılarak türetilen mutlak bir deadline damgalayın ve her aşamaya sabit bir zaman aşımı yerine kalan süreyi geçirin. Aynı mekanizmayı gRPC dokümantasyonu da anlatır: yayılan bir deadline, geçen süre zaten düşülmüş bir zaman aşımına dönüşür ve başlattığı işi durdurmaktan sunucu uygulaması sorumlu kalır.

Kalan süre puanlamaya yetmeyecek kadar azsa erken yanıt verin. OpenRTB 2.6 iki no-bid biçimi sunar - HTTP 204 ile boş bir yanıt ya da nbr içinde neden kodu olan bir teklif yanıtı - ve neden kodunu teşvik eder. Geç bir yanıt daha pahalıya mal olur: Google'ın callout kota sistemi zamanında yanıt vermeyen bir bidder'a daha az callout gönderir ve dakikalar içinde ayarlanır.

Feature çekme ve model değerlendirmesi farklı biçimlerde bozulur, bu yüzden ayrı bütçeler alır

Çıkarım sözcüğünün altında iki aşama saklanır. Feature çekme bir girdi/çıktı işidir: uzak bir depodan gelen geçmiş, frekans ve bağlam sinyalleri; tail latency'si ağa ve o depoya aittir. Değerlendirme ise hesaplamadır, bir forward pass ya da ağaçlar üzerinde bir gezinti; tail latency'si kendi sürecinizin içindeki CPU çekişmesine aittir.

İkisini karıştıran bir p99 hangisinin onarılacağını söylemez; bu yüzden exchange başına iki histogram tutun ve feature'ları nerede durduklarına göre ayırın:

• Bid request'in kendisinden okunan istek feature'ları: bedava ve geç kalamayan tek sınıf
• Kampanya ve kreatif feature'ları; süreç belleğinde tutulur ve hot path dışında yeniden kurulur, böylece yavaş bir yeniden kurulum bir teklife değil tazeliğe mal olur
• Uzak bir depodan gelen kullanıcı ve geçmiş feature'ları: en büyük tail latency ve bütçe yetmediğinde ilk kesilecek grup
• İstek başına hesaplanan çapraz feature'lar; maliyetleri aday sayısıyla birlikte büyür

Deadline'ı olan bir çekme, eksik yanıtı hesaba katan bir model ister: modeli örneklerin bir kısmında geç gelen feature grubu eksik olacak şekilde eğitin ya da o grup olmadan ikinci bir model tutun; böylece iptal edilen bir sorgu tahmini, ölçmüş olduğunuz bir biçimde kaydırır.

Dean ve Barroso, 2013'te The Tail at Scale makalesinde hedged request'leri tarif etti: kısa bir gecikmenin ardından başka bir replikaya ikinci bir kopya gönderin ve hangi yanıt önce gelirse onu kullanın. BigTable kıyaslamalarında 10 ms sonra gönderilen bir hedge isteği, 1.000 değeri getirmenin 99,9'uncu yüzdelik latency'sini 1.800 ms'den 74 ms'ye indirdi ve bunu yaparken %2 daha fazla istek gönderdi. Bir açık artırmanın içinde hedge gecikmesi, çekmenin kalan payından gelmek zorundadır.

Model formatını, sürecinizin içinde ağ hop'u olmadan neyin çalıştığına göre seçin

Runtime kararı büyük ölçüde değerlendirmenin nerede yapılacağına dair bir karardır. Ayrı bir çıkarım sunucusu, puanlanan her isteğe bir gidiş-dönüş ve bir kuyruk ekler; bidder sürecinin içinde değerlendirme ikisini de eklemez, bunun yerine belleğini ve thread'lerini size devreder. Yaygın dört seçenek:

• Seyrek feature'lar üzerinde lojistik regresyon, yani aktif ağırlıklar üzerinde bir toplam: McMahan ve meslektaşlarının KDD 2013'te Google'ın reklam tıklama tahmini için anlattığı tek katmanlı model
• Önceden (ahead-of-time) derlenmiş ağaç ensemble'ları: dmlc projesinden TL2cgen, rastgele ormanları ve gradient boosting modellerini native binary olarak dağıtılan C koduna dönüştürür
• ONNX Runtime'da küçük bir sinir ağı; intra-op havuzu varsayılan olarak fiziksel çekirdek başına bir thread ve etkin spinning ile gelir: handler'lar zaten her çekirdeği meşgul ediyorsa, havuzu makineye göre değil isteğe göre boyutlandırın
• Triton ya da TensorFlow Serving gibi ayrı bir sunucu; model bir hızlandırıcıya ya da kendine ait bir sürüm döngüsüne ihtiyaç duyuyorsa

Nicemleme (quantization) diğer CPU kaldıracıdır ve ONNX Runtime'ın kendi dokümantasyonunda belirtilen iki bedeli vardır: 8 bit doğrusal nicemleme kayıpsız bir dönüşüm değildir ve getirdiği ek yük, eski cihazlarda daha kötü performansı nadir olmaktan çıkarır. Bir CTR modeli için doğruluk kalibrasyonu da kapsar; bu yüzden tahmin edilen ve gözlemlenen oranları öncesinde ve sonrasında karşılaştırın.

İstekler arası batching, bidder'ın en az sahip olduğu kaynağı harcar

Tek bir isteğin adaylarını batch'lemenin bekleme maliyeti yoktur, çünkü adaylar zaten mevcuttur. İstekler arası dinamik batching, istekleri başka istekler gelsin diye bekleterek throughput'u artırır; bu, bir açık artırma deadline'ının istediğinin tam tersidir ve çıkarım sunucuları bunu kendileri de söyler:

• TensorFlow Serving, dolmamış bir batch için bekleme süresini batch_timeout_micros ile sınırlar; bu parametre tail latency'yi dizginlemek için kullanılır ve yalnızca CPU'lu sistemlerde, 0'ın en uygun değer olabileceği de akılda tutularak 0'dan başlanması önerilir
• NVIDIA Triton'ın dinamik batcher'ı bir batch'i yalnızca hiçbir istek yapılandırılmış azami kuyruk gecikmesinden uzun beklemediği sürece tutar ve rehberi bu gecikmeyi latency bütçesi aşılana kadar artırmayı önerir
• Triton'ın kuyruk politikası, kuyrukta bir zaman aşımını aşacak kadar bekleyen istekleri reddedebilir ya da erteleyebilir; böylece geç bir skoru, bidder'ın göre davranabileceği erken bir hataya çevirir

Google'ın 2016'da yayımlanan Wide & Deep makalesi, her isteği 10 ms mertebesinde sunmayı hedefleyen bir servis için bu ödünleşimin istek içi tarafını gösterir. Tüm adayları tek bir thread üzerinde tek bir batch'te puanlamak 31 ms sürdü; batch'i paralel thread'lerde daha küçük batch'lere bölmek, serving ek yükü dahil istemci tarafı latency'yi 14 ms'ye indirdi.

NSDI 2017'de sunulan Berkeley tahmin sunma sistemi Clipper, batch'leri donanıma göre değil deadline'a göre boyutlandırır: batch'i, işlenmesi latency hedefini aşana kadar toplamsal olarak büyütür, ardından %10 geri çekilir. Bir bidder için ders sıralamadadır: önce latency hedefini sabitleyin, sonra altına hangi batch sığıyorsa onu alın, tek elemanlı bir batch bile olsa.

CPU mu hızlandırıcı mı sorusuna batch boyutu ve aktarım maliyeti karar verir

Bir hızlandırıcı yerini büyük batch'lerde hak eder; bir bid request'in batch'i ise yalnızca elemeden geçen adaylarıdır. ISCA 2020'de sunulan bir Harvard ve Facebook çalışması olan DeepRecSys, daha büyük batch boyutlarında GPU'ların CPU'lardan daha iyi performans gösterdiğini ve incelediği her modelde girdilerin CPU'dan GPU'ya yüklenmesinin uçtan uca GPU çıkarım süresinin ortalama %60 ile %80'ini aldığını buldu.

Scheduler'ı tek bir cihaz seçmedi: büyük sorguları yalnızca paralel CPU çekirdeklerinde daha küçük batch'lere bölmek, sektörü temsil eden sekiz modelde katı tail latency hedefleri altında throughput'u iki katına çıkardı; yalnızca belirli bir boyut eşiğinin üzerindeki sorguları GPU'ya aktarmak ise onu daha da artırdı. Bir bidder için istek başına küçük batch'ler CPU'da kalır ve bir hızlandırıcı, aktarımın ve kuyruğun maliyetini geri kazandırmak zorundadır.

Geç bir tahmin sade bir tahminden kötüdür, bu yüzden önce fallback tasarlanır

Clipper'ın straggler azaltma mekanizması, kopyalanmaya değer bir tasarım tercihine dayanır: geç bir tahmin sunmak, isabetsiz bir tahmin sunmaktan daha kötüdür. Deadline geldiğinde model seçim katmanı, gelmiş olan tahminleri birleştirdi ve eksik olanların yerine ortalama değerlerini koydu. Bir bidder'da bunun karşılığı bir merdivendir ve her basamak, açık artırmanın kabullenebileceği bir fiyat üretmek zorundadır:

• Tam model; çekme kendi payı içinde döndüyse
• Geç gelen feature grubu olmadan eğitilmiş küçültülmüş bir model; çekme iptal edildiyse
• Yerleşim, kreatif ve segment gibi kaba bir bağlama göre anahtarlanmış, yaş sınırı olan, önbelleğe alınmış bir tahmin; değerlendirmeye süre yetmediğinde
• Yerleşim ve kreatif başına kalibre edilmiş bir önsel (prior); yukarıdakilerin hiçbiri mevcut değilse
• Neden koduyla bir no-bid; önsel bile göz kararından ibaret olacaksa

Dönüşüm hedefi için gösterim başına beklenen değer, tıklama olasılığı çarpı tıklamadan sonraki dönüşüm olasılığı çarpı dönüşümün değeridir; dolayısıyla yüksek seyreden bir basamak, gösterimin değerinin üzerinde teklif verir: birinci fiyat açık artırmasında her kazanımda fazla öder, ikinci fiyat açık artırmasında ise kaybetmesi gereken gösterimleri kazanır. McMahan ve meslektaşları, doğru ve iyi kalibre edilmiş tahminlerin açık artırmayı yürütmek için vazgeçilmez olduğunu yazdı ve eğitim ya da serving anında mevcut olmayan gizli feature'ları sistematik yanlılığın nedenleri arasında saydı; iptal edilen bir çekme, bir feature'ı serving anında mevcut olmaktan çıkarır.

Önce gölge, sonra harcama limitli bir canary

Yeni bir model latency'yi ve fiyatı aynı anda değiştirir ve ikisi farklı zaman ölçeklerinde bozulur: latency dakikalar içinde, fiyat dönüşüm penceresi boyunca. Modeli, bu ikisini birbirinden ayrı tutan iki adımda devreye alın:

• Ayrı örneklerde aynalanmış trafik üzerinde gölge puanlama; asla maliyetini ölçtüğünüz sürecin içinde değil
• Aynı istekler üzerinde bir karşılaştırma: tahmin dağılımları, eksik feature oranları, aday başına değerlendirme süresi ve her modelin teklif edeceği fiyat
• Her teklif logunda model sürümünün yer aldığı, canlı trafiğin küçük bir payında çalışan bir canary; böylece kazanımlar, harcama ve dönüşümler sürüme göre ayrışır
• Bir harcama tavanı ve latency, fallback oranı ya da yanlılık üzerinden tetiklenen otomatik geri alma; çünkü canary teklifleri gerçek gösterimler satın alır

Google SRE Workbook, canary uygulamasını bir servisteki bir değişikliğin kısmi ve süre sınırlı dağıtımı ve bunun değerlendirilmesi olarak tanımlar ve çeşitli sorgular alan sistemlerde bir avuç sorgudan sonra bitirilen bir canary'nin işe yarar bir sinyal vermediği konusunda uyarır. Bir dönüşüm modeli için o bir avuç, dönüşüm cinsinden sayılır; bu yüzden canary en az dönüşüm penceresi kadar çalışır.

Modeli ve saati tek bir panoda izleyin

Latency izleme, modelin yanıt verip vermediğini söyler; model izleme ise yanıtın fiyatına değip değmediğini. Bir bidder'ın ikisine de, exchange başına ve model sürümü başına dilimlenmiş olarak ihtiyacı vardır:

• Çekme süresi ve değerlendirme süresi ayrı p99 ve p99.9 histogramları olarak, nedene göre fallback oranının yanında
• Tahmin yanlılığı; Google'daki Sculley ve meslektaşları 2015'te bunu, tahmin edilen etiketlerin gözlemlenen etiketlerin dağılımıyla örtüşmesi olarak tarif etti: ortalamayı tahmin eden bir model bu kontrolden geçer, bu yüzden dilimleyin, tahmin edilen olasılık kovasına göre de
• Training-serving skew (eğitim ile serving arasındaki kayma): Google'ın Rules of Machine Learning rehberi, serving anında kullanılan feature'ları loglamayı ve en azından küçük bir kısmı için bunlarla eğitmeyi söyler
• Model yaşı: Facebook'un 2014 tarihli tıklama tahmini makalesi, haftalık yerine günlük eğitimin normalize entropiyi yaklaşık %1 düşürdüğünü buldu ve günlük yeniden eğitimi buna değer gördü
• Teklif fiyatı ve harcama üzerinde eylem limitleri; 2015 makalesi bunları gerçek dünyada eyleme geçen sistemler için önerir ve örnekleri arasında teklif verme de yer alır

Bir tahmin tmax'tan sonra geliyorsa daha yavaş bir teklif üretmiş olmaz. Bir zaman aşımı, sizi kısıtlamak için bir gerekçe ve bir CPU faturası üretmiştir; bu arada açık artırmayı yanıt veren bidder'lar belirlemiştir.

Bunu kuran firma, modelden önce zaman aşımı raporunu ister

Sorunun ikinci yarısının - bidder'lara gömülü çıkarım pipeline'larını kimin kurduğu - bir satıcı listesine ihtiyaç duymayan bir testi var. Bu işi yapan bir firma, bir model önermeden önce bütçeyi sorar:

• Şunları ister: tmax dağılımı, exchange bazında zaman aşımı raporu ve hedeflemeden geçen aday sayısı
• Bir runtime önermeden önce deadline dağılımını - hat, ayrıştırma, çekme, değerlendirme, pay - yazıya döker ve tail latency'nin sahibi olmasını beklediği aşamayı adlandırır
• Fallback merdivenini ve hedef bir fallback oranını modelle aynı belgeye koyar
• Kalibrasyonu sıralama metriğinin yanında bir kabul ölçütü olarak ele alır ve eğitim feature'larının nerede loglandığını sorar
• Ayrı örneklerde çalışan bir gölge planı ile harcama tavanı ve otomatik geri alması olan bir canary getirir; lansmandan sonra teklif yoluna ekip ayırabilir

Her madde ilk görüşmede isteyebileceğiniz bir belgedir ve muğlak bir yanıt, bütçenin henüz bölünmediği anlamına gelir.

Yani ilk soru hangi modelin sunulacağı değildir. Soru, zaman aşımına uğrayan exchange'de hattan ve feature çekmeden sonra tmax'tan ne kadar kaldığı ve bu kalan tükendiğinde bidder'ın ne teklif ettiğidir.

amBrain'in kamuya kanıtlayabildikleri: amBrain; trading platformları, matching engine'ler, real-time bidding sistemleri ve casino platformu mühendisliği alanlarında uzmanlaşmış bir yazılım geliştirme şirketidir. amBrain 2019'dan beri yazılım geliştiriyor ve AdTech'te kurduğumuz şey DSP geliştirme, real-time bidding platformları ve ad exchange mühendisliğidir. Üç formatta çalışıyoruz: tam teslim, özel ekip ya da sizin ekibinize yerleşen mühendisler.