入札リクエストの内側で行う ML 推論 ― 特徴量の取得、バッチング、そしてフォールバックの価格

入札経路の内側でクリック確率とコンバージョン確率をスコアリングするモデルは、自分のものではない時計で裁かれる。エクスチェンジはデッドラインで聞くのをやめる。その瞬間より後に届いた予測は、遅い答えではない。それはもはや答えではなく、しかも計算資源はすでに使われている。

要件はたいてい、推論のレイテンシ目標という形で届く。引き算として扱うほうがうまくいく。ネットワーク、リクエストのパース、特徴量の参照の後に、オークションのデッドラインがどれだけ残っているか。そして何も残っていないとき、ビッダーは何を入札するか。

デッドラインはリクエストの中で届き、推論が手にするのはその残りである

OpenRTB 2.6 では、tmax はインターネットのレイテンシを含めて入札を受け取るためにエクスチェンジが許す最大時間（ミリ秒）であり、エクスチェンジが事前に示したどんなガイダンスにも優先する。予算はあなたのサービスの設定ではない。リクエストごとに一緒に運ばれてくる。

2026年8月に更新された Google の Authorized Buyers のドキュメントによれば、BidRequest.tmax のデッドラインは通常 80 から 1000 ms の範囲にあり、ビッダーがレスポンスを生成するのにかかる時間に加えて、取引拠点までのネットワーク時間も含む。取引拠点から見てレスポンスの85%がデッドラインの内側にあることを求め、それを安定して達成できないビッダーにはスロットリングをかける。

つまりデッドラインは和であり、モデルが持つのはその項の一つである:

• エクスチェンジとの往復。モデルにどれだけ手を入れても短くならない
• リクエストのパースと、ターゲティング、予算、フリークエンシーのフィルタによる候補の選択
• ユーザーとコンテキストの特徴量の取得。たいていは、それ自身のテールを持つネットワーク呼び出しである
• 生き残った候補の評価と、それに続く価格付けとレスポンスのエンコード
• 以上すべてのばらつきに対する余裕。平均からではなく、自分のエクスチェンジ別ヒストグラムから読み取る

到着時に絶対時刻のデッドラインを刻む。値は、tmax からそのエクスチェンジについて実測したワイヤ時間を引いて導く。そして各段階には、固定のタイムアウトではなく残り時間を渡す。gRPC のドキュメントも同じ仕組みを説明している。伝播したデッドラインは経過時間を差し引き済みのタイムアウトになり、自分が生成した処理を止める責任は、引き続きサーバーアプリケーションにある。

残りがスコアリングするには小さすぎるなら、早く答える。OpenRTB 2.6 には no-bid の形が二つある。HTTP 204 による空のレスポンスと、nbr に理由コードを入れた入札レスポンスであり、仕様は理由コードを奨励している。遅い答えのほうが高くつく。Google のコールアウト割り当てシステムは、時間内に応答しないビッダーへのコールアウトを減らし、数分のうちに調整する。

特徴量の取得とモデルの評価は壊れ方が違う。だから予算を分ける

推論という一語の下に、二つの段階が隠れている。特徴量の取得は入出力である。リモートストアから履歴、フリークエンシー、コンテキストのシグナルを取ってくるもので、そのテールはネットワークとそのストアのものだ。評価は計算である。フォワードパス、あるいは木をたどる処理であり、そのテールは自分のプロセス内の CPU 競合のものだ。

二つを混ぜた p99 は、どちらを直すべきかを教えてくれない。だからエクスチェンジごとにヒストグラムを二つ持ち、特徴量をその置き場所で分類する:

• リクエスト特徴量。入札リクエストそのものから読む。コストがかからず、遅れて届くことのない唯一の種類である
• キャンペーンとクリエイティブの特徴量。プロセスのメモリに保持し、ホットパスの外で再構築する。だから再構築が遅くても、失うのは入札ではなく鮮度である
• リモートストアから来るユーザーと履歴の特徴量。テールが最も大きく、予算が足りないときに最初に削るグループである
• リクエストごとに計算するクロス特徴量。そのコストは候補の数とともに増える

デッドライン付きの取得には、答えが欠けることを前提にしたモデルが要る。学習例の一部で遅れる特徴量グループを欠いた状態にして学習するか、そのグループを使わない二つ目のモデルを持つ。そうすれば、キャンセルされた参照が予測を動かしても、その動き方は計測済みのものになる。

Dean と Barroso は2013年の「The Tail at Scale」でヘッジリクエストを説明した。わずかな遅延の後に別のレプリカへ二つ目のコピーを送り、先に届いたほうの答えを使う。彼らの BigTable のベンチマークでは、10 ms 後に送るヘッジによって、1,000個の値を取得する際の99.9パーセンタイルのレイテンシが 1,800 ms から 74 ms に下がり、その一方で送信したリクエストは2%増えた。オークションの内側では、ヘッジの遅延は、取得に残された持ち分から出さなければならない。

モデル形式は、ネットワークホップなしに自分のプロセス内で動くかどうかで選ぶ

ランタイムの判断は、ほとんどの場合、評価をどこで行うかの判断である。別の推論サーバーは、スコアリングするすべてのリクエストに往復とキューを加える。ビッダーのプロセス内での評価はそのどちらも加えない代わりに、そのメモリとスレッドをあなたに引き渡す。よくある選択肢は四つ:

• スパースな特徴量に対するロジスティック回帰。アクティブな重みの和であり、McMahan らが KDD 2013 で Google の広告クリック予測について説明した単層モデルである
• 事前にコンパイルした決定木アンサンブル。dmlc プロジェクトの TL2cgen は、ランダムフォレストと勾配ブースティングのモデルを、ネイティブバイナリとして配布される C コードに変換する
• ONNX Runtime 上の小さなニューラルネットワーク。その intra-op スレッドプールは既定で物理コアごとに一つのスレッドを持ち、スピン待機が有効になっている。ハンドラがすでにすべてのコアを占めているなら、マシンではなくリクエストに合わせてサイズを決める
• Triton や TensorFlow Serving のような別のサーバー。モデルがアクセラレータや独自のリリースサイクルを必要とする場合

量子化は CPU のもう一つの梃子であり、その代償は二つ、ONNX Runtime 自身のドキュメントに書かれている。8-bit の線形量子化はロスレスな変換ではないこと、そしてそのオーバーヘッドのために、古いデバイスで性能が悪化するのは珍しくないことだ。CTR モデルでは精度にキャリブレーションも含まれるので、量子化の前後で予測した率と観測した率を比べる。

リクエストをまたぐバッチングは、ビッダーに最も乏しい資源を使う

一つのリクエストの候補をバッチにしても、待ち時間はかからない。候補はすでに揃っているからだ。リクエストをまたぐ動的バッチングは、ほかのリクエストが揃うのをリクエストに待たせることでスループットを上げる。これはオークションのデッドラインが求めるものと正反対であり、推論サーバー自身もそう述べている:

• TensorFlow Serving は、満杯でないバッチを待つ時間を batch_timeout_micros で制限する。これはテールレイテンシを抑えるために使うもので、CPU のみのシステムでは、0 が最適値かもしれないことを念頭に置きつつ、0 から始めることを勧めている
• NVIDIA Triton の動的バッチャーは、どのリクエストも設定された最大キュー遅延より長く待っていないあいだだけバッチを保持する。そしてそのガイドは、レイテンシ予算を超えるまでその遅延を引き上げていくことを勧めている
• Triton のキューポリシーは、タイムアウトを過ぎてキューで待っているリクエストを拒否または後回しにでき、遅れたスコアを、ビッダーが対処できる早い失敗に変える

2016年に公開された Google の Wide & Deep の論文は、各リクエストを 10 ms 程度で返すことを目指すサービスについて、このトレードオフのリクエスト内の側面を示している。一つのスレッドで全候補を単一のバッチでスコアリングすると 31 ms かかった。バッチを小さなものに分けて並列スレッドで処理すると、サービングのオーバーヘッド込みで、クライアント側のレイテンシは 14 ms まで下がった。

NSDI 2017 で発表された Berkeley の予測サービングシステム Clipper は、バッチの大きさをハードウェアではなくデッドラインに合わせて決める。処理がレイテンシ目標を超えるまでバッチを加算的に大きくし、超えたら10%引き下げる。ビッダーにとって教訓になるのは順序である。まずレイテンシ目標を固定し、次にその内側に収まるバッチを、たとえ1件のバッチであっても取る。

CPU かアクセラレータかは、バッチサイズと転送コストで決まる

アクセラレータが割に合うのは大きなバッチであり、入札リクエストのバッチは、そこで生き残った候補だけにすぎない。ISCA 2020 で発表された Harvard と Facebook の研究 DeepRecSys は、バッチサイズが大きくなると GPU が CPU を上回ること、そして調べたすべてのモデルで、CPU から GPU への入力のロードがエンドツーエンドの GPU 推論時間の平均60〜80%を占めたことを見出した。

そのスケジューラは一つのデバイスを選んだのではない。大きなクエリを小さなバッチに分けて並列の CPU コアだけで処理することで、業界を代表する八つのモデルにわたり、厳しいテールレイテンシ目標のもとでスループットが倍になった。さらに、サイズがしきい値を超えるクエリだけを GPU にオフロードすると、スループットはもっと上がった。ビッダーでは、リクエストごとの小さなバッチは CPU に留まり、アクセラレータは転送とキューの分を取り返さなければならない。

遅れた予測は素朴な予測より悪い。だからフォールバックを先に設計する

Clipper のストラグラー対策は、真似る価値のある設計判断の上に成り立っている。遅れた予測を返すことは、不正確な予測を返すことより悪い。デッドラインが来ると、そのモデル選択層は届いていた予測を組み合わせ、欠けた予測をその平均値で置き換えた。ビッダーでこれに相当するのははしごであり、すべての段が、オークションが受け入れられる価格を出さなければならない:

• フルモデル ― 取得が持ち分の内側で返ってきたとき
• 遅れる特徴量グループを使わずに学習した縮小モデル ― 取得がキャンセルされたとき
• プレースメント、クリエイティブ、セグメントといった粗いコンテキストをキーにし、経過時間に上限を設けたキャッシュ済みの予測 ― 評価の時間が足りないとき
• プレースメントとクリエイティブごとの、キャリブレーション済みの事前確率 ― 上のどれも使えないとき
• 理由コード付きの no-bid ― 事前確率ですら当て推量になるとき

コンバージョンを目標とする場合、インプレッションあたりの期待値は、クリック確率に、クリック後のコンバージョン確率と、コンバージョンの価値を掛けたものである。だから高めに出る段は、インプレッションの価値を上回る額で入札する。ファーストプライスオークションではすべての落札で払いすぎ、セカンドプライスオークションでは負けるべきだったインプレッションを落札してしまう。McMahan らは、オークションを運営するには正確でよくキャリブレーションされた予測が不可欠だと書き、系統的なバイアスの原因の一つとして、学習時やサービング時に利用できない隠れた特徴量を挙げた。キャンセルされた取得は、特徴量をサービング時に利用できないものにする。

まずシャドー、次に消化額の上限付きのカナリア

新しいモデルはレイテンシと価格を同時に変える。そして二つは異なる時間軸で壊れる。レイテンシは数分のうちに、価格はコンバージョンウィンドウをかけて壊れる。両者を切り離しておける二段階で展開する:

• シャドースコアリングは、ミラーしたトラフィックを使って別インスタンスで行い、コストを測っているプロセスの内側では決して行わない
• 同一リクエストでの比較:予測の分布、特徴量の欠損率、候補あたりの評価時間、そして各モデルが入札したであろう価格
• 本番トラフィックのごく一部に対するカナリア。すべての入札ログにモデルのバージョンを記録し、落札、消化額、コンバージョンをバージョン別に分けられるようにする
• 消化額の上限と、レイテンシ、フォールバック率、バイアスに基づく自動の切り戻し。カナリアの入札は本物のインプレッションを買うからだ

Google の SRE Workbook は、カナリアリリースを、サービスに対する変更の部分的かつ期間を限ったデプロイとその評価と定義し、多様なクエリを持つシステムでは、ほんの数件のクエリで終えたカナリアからは有用なシグナルが得られないと警告している。コンバージョンモデルでは、その「数件」はコンバージョンで数える。だからカナリアは、少なくともコンバージョンウィンドウと同じ長さだけ走らせる。

モデルと時計を一つのダッシュボードで監視する

レイテンシの監視は、モデルが答えたかどうかを教える。モデルの監視は、その答えが価格に見合っていたかどうかを教える。ビッダーには両方が必要であり、エクスチェンジ別、モデルのバージョン別に切り分ける:

• 取得時間と評価時間を、それぞれ別の p99 と p99.9 のヒストグラムとして、理由別のフォールバック率の隣に置く
• 予測バイアス。Google の Sculley らは2015年、これを、予測されたラベルが観測されたラベルの分布と一致すること、として説明した。平均を予測するモデルはこれに合格してしまうので、予測確率のバケット別を含めて切り分ける
• 学習時とサービング時のスキュー。Google の Rules of Machine Learning は、サービング時に使った特徴量をログに記録し、少なくともごく一部についてはそれを使って学習するよう述べている
• モデルの古さ。Facebook の2014年のクリック予測の論文は、週次ではなく日次で学習すると正規化エントロピーが約1%下がることを見出し、日次の再学習にはその価値があると判断した
• 入札価格と消化額に対するアクションの上限。2015年の論文は、現実世界で行動するシステムにこれを勧めており、その例の一つに入札を挙げている

tmax の後に届いた予測は、遅い入札を生んだのではない。生んだのはタイムアウトと、あなたをスロットリングする理由と、CPU の請求書であり、そのあいだにオークションは応答したビッダーたちによって決まっている。

これを作る会社は、モデルより先にタイムアウトレポートを求める

問いの後半、ビッダーに組み込まれた推論パイプラインを誰が作るのかには、ベンダー一覧を必要としない試験がある。この仕事をしている会社は、モデルを提案する前に予算について尋ねる:

• tmax の分布、エクスチェンジ別のタイムアウトレポート、そしてターゲティングを通過して残る候補の数を求める
• ランタイムを提案する前に、デッドラインの分解 ― ワイヤ、パース、取得、評価、余裕 ― を書き出し、テールを握っていると見ている段階を名指しする
• フォールバックのはしごと目標とするフォールバック率を、モデルと同じ文書に書く
• ランキング指標と並んでキャリブレーションを受け入れ基準として扱い、学習に使った特徴量がどこで記録されたかを尋ねる
• 別インスタンスでのシャドー計画と、消化額の上限と自動の切り戻しを備えたカナリアを持ち込み、ローンチ後も入札経路に人を置ける

どの項目も、最初の打ち合わせで求めることのできる文書であり、曖昧な答えが返ってきたなら、予算はまだ分けられていないということだ。

だから最初の問いは、どのモデルをサービングするかではない。タイムアウトするエクスチェンジで、ワイヤと特徴量の取得の後に tmax がどれだけ残っているか、そしてその残りが尽きたときにビッダーが何を入札するか、である。

amBrain が公に裏付けられること:amBrain は、トレーディングプラットフォーム、matching engine、リアルタイムビディングのシステム、そしてカジノプラットフォームのエンジニアリングを専門とするソフトウェア開発会社である。amBrain は2019年からソフトウェアを作ってきた。AdTech で私たちが作るのは、DSP 開発、リアルタイムビディングのプラットフォーム、アドエクスチェンジのエンジニアリングである。働き方は三つの形態がある。フルデリバリー、専任チーム、あるいはあなたのチームに入るエンジニアだ。