# AIRS: Scaling Live Inference in Resource Constrained Environments > [!info] Talk metadata > - **会議:** [[MLSys2026]] Day 4 (May 21 / Thu)、Grand Ballroom 1、Industry Track Oral: Benchmarks and Evaluation（16:30 - 18:00 PDT、第2発表、司会 Youjie Li） > - **登壇者:** Nilesh Jagnik（Google, Search Evaluations。スライド表紙に Presenter として明記）。共著者: Xiaohao Yang, Chelsea Chen, Tuan Do, GM Harshvardhan（全員 Google, USA） > - **URL:** https://mlsys.org/virtual/2026/session/3717 > - **関連研究:** 著者所属は Google（論文 footnote: Correspondence to Nilesh Jagnik <[email protected]>） > [!warning] 本トークは文字起こしが無いため Q&A は扱わない。数値・固有名詞はスライド PDF を権威とし、論文 PDF と対照のうえ記載する（両者で表記が異なる箇所は注記）。 > [!abstract] 概要（論文 PDF アブストラクト） > 大規模言語モデル（LLM）の進歩は、従来ドメイン専門家を要した複雑な推論タスクに対して LLM をますます有用にした。そうしたタスクの一つが、検索エンジンが生成するクエリ応答の品質評価である。評価は、プロダクトの変更や機能の品質・影響・有用性を調べるために必要なメトリクスを生成する。通常、評価メトリクスを計算するには、人間の専門家が検索応答の様々な属性を評定するよう求められる。この処理は一般に非常に高コストで、完了に数日を要する。代替として、LLM がより低コスト・低レイテンシで評定タスクを実行するために用いられるようになっている。加えて、Google の新たな AI ベースの提供物を評価するために多くの新規メトリクスが開発されており、これらも評定を要する。その結果、割り当てられた TPU（Tensor Processing Unit）の予算に比べ、LLM の評定予測タスクへの需要がはるかに高まっている。会社の TPU リソースのより大きな部分は、ライブのユーザトラフィックの提供のために予約されている。本論文では AI Rater Service（AIRS）、すなわち高信頼性かつ低レイテンシで AI 評定を生成するために複数のソフトウェアエンジニアリング技術を用いる推論パイプラインを提示する。AIRS は、様々な評価ワークフローにまたがって TPU リソース利用率を最適化することで LLM 推論スループットを最大化しつつ、より優先度の高いタスクのレイテンシを最小化する。 ## 背景: Search Quality Evaluation の役割 スライド "Evaluations: Guiding Product Excellence" / "The Search Quality Evaluation Platform"。 - 評価はプロダクトの卓越性を導く実践であり、3 用途に整理される。**Tuning（Iterative Refinement）**: ローンチ承認前に評価インサイトで反復改善（Test vs. Base 比較、定性・定量の影響評価）。**Launches（Decision Validation）**: 新機能・AI ベース提供物のローンチ正当化のためユーザ影響を予測（ビジネスメトリクス予測、品質検証）。**Guardrails（Risk Mitigation）**: 想定外の挙動・回帰を検知し時間経過に対する安定性を担保（継続的 eval 追跡、zero-diff 検証）。 - Google Search Quality Evaluation pipeline（論文 Figure 1）: クエリストリーム（実トラフィックまたは合成クエリ）→ Experiment(Test) Search stack と Base Search stack の双方で検索 → 結果を構造化データへスクレイプ → 差分（Diffs）を自動検出 → その差分上で Ratings（Human or AI）・Metrics（Impact, Quality=Page Quality）を計算。 - チームの焦点は **2. Ratings Generation（AI & Human）**。スライドは「AIRS は LLM を用いて日次 **100M+** 評定を自動化し人間専門家を模倣する」と明記。 ## トップラインメトリクス Page Quality と需要 論文 Section 1–2 および Figure 1–2。 - 例示のトップラインメトリクスは **Page Quality (PQ)**。各 web 結果に PQ_r を付与し、結果重要度重み w_r で per-query PQ を集約する（論文 eq. 1: Per-query PQ = Σ_{r∈R} (w_r × PQ_r)）。Test と Base の差分を取り（eq. 2: ΔPQ = Per-query PQ_Test − Per-query PQ_Base）、サンプルクエリ Q 上で重み w_q を掛けて平均する（eq. 3: Total ΔPQ = Σ_{q∈Q} (w_q × ΔPQ_q)）。 - per-result PQ_r は Search Quality の人間 rater が **180+ ページ** の General Guidelines に基づき E-E-A-T（Experience, Expertise, Authoritativeness, Trust）を検証して評定。本質的に困難かつ高コスト。 - PQ autorater の訓練（論文 Figure 2）: Human Ratings + Search Document Index → Training Data → Gemini Foundational Model を fine-tune → Fine-tuned Model。出力は軽量な encoder-only モデル。 - トップライン PQ autorater は日次数百の大規模実験（各最大数十万クエリ）に用いられ、システム全体で **日次 1 億（100 million）件の PQ 評定リクエスト** を生成。加えて部門横断で数百の autorater を開発・保守（多くは 10B パラメータ未満）。 ## 課題: Search Quality Evaluation のスケーリング スライド "The Challenge: Scaling Search Quality Evaluation" の 3 軸。 - **Human Bottleneck:** 従来の専門家評定は金銭的に高コストで遅く、完了に数日。精度・信頼性・信用性の手作業調査、180+ ページのガイドライン習得が必要。 - **Exploding Demand:** AI Overviews・AI Mode など新しい AI ベースプロダクトが評価需要を激増させた。**日次 100M+ 評定リクエスト**、**数百のユニークな autorater とメトリクス**。 - **Resource Scarcity:** TPU クォータはライブユーザトラフィック向けに予約され強く制約される。割当が需要に届かず、ローンチサイクルの中断を招く。 ## 目的（Objectives） 論文 Section 3。AIRS の中核目的は、AI 生成評定で計算した評価メトリクスを高信頼性・低レイテンシで利用可能にすること。以下の設計原則に翻訳される。 - **3.1 Maximize TPU Utilization:** スループット最大化＝TPU 利用率最大化。指標は平均 TPU duty cycle D。論文 eq. 4: D = T_busy / (T_busy + T_idle)。いずれかのコアがアクティブなら TPU は busy。スパイキーな QPS パターンを持続的 QPS へ変換するトラフィック制御（過負荷時のバックプレッシャ）を要する。 - **3.2 Avoid Duplicate Predictions:** 多くの独立ワークフローが同一検索結果を生み重複評定を要求。ストレージ層が重複検出時の効率的な評定ルックアップ（実質キャッシュ）を支援すべき。ただしモデル更新後や世界状態変化後の古いキャッシュは無効化が必要。 - **3.3 Lifecycle Management:** 個別評定リクエストのライフサイクルだけでなく、単一評価ワークフロー起点の全リクエストの統合状態を監視。全完了時にワークフローへ完了通知し、後段（メトリクス計算）へ進ませる。設定時間超過のリクエストはタイムアウト。 - **3.4 Prioritization:** 評価は人間トリガ（一般に高優先度・低レイテンシ要求）と自動トリガ（回帰テスト・ダッシュボード・継続評価等、低優先度）に分かれる。ビジネスクリティカルなメトリクスのリクエストは高優先度を割当て、優先度順に充足すべき。 - **3.5 Maintain Shared TPU Pools:** 少量リクエストの autorater には専用 TPU プールが非効率。複数モデルをホストする共有 TPU プールを維持し、TPU 利用率に基づき動的再配分。共有プール内の全モデルサーバ間で TPU 使用を均衡化。 ## 設計概要（Design Overview） スライド "AIRS: Design Overview"、論文 Section 4・Figure 3。 - **2 つの主要コンポーネント:** (a) **Rating Fulfillment**（評価ワークフローから評定予測タスクを受領し、全体の充足ライフサイクルを管理）、(b) **Model Management**（ホスティング支援、TPU リソース利用率の追跡、ホストモデルへのリソースのスケール）。両層は協調して全体スループットを最適化。 - **Operational Modes（相互排他の機能セット）:** **Isolated Mode** — コンポーネントを個別利用、汎用の retry/back-off 戦略で QPS 制御（フル機能不要なクライアント向け）。**Integrated Mode** — 両コンポーネントが連携し、Rating Fulfillment が Model Management の追跡するクォータ割当・現利用率を覗き見（peek）して実行可否を事前判定。リソース可用性へ素早く反応し全体スループットを増やす。 - **4.1 API for Autoraters:** 多様な LLM autorater が AIRS 共通インタフェースを実装。各 rater は一意の Rater ID（R_ID）を持つ。Model Management が R_ID とモデル URL の対応を保持し TPU クォータを会計。入力は結果スクレイピング段で収集したデータ（視覚要素・テキスト）、出力はユーザ定義の protocol buffer。 ## Model Management スライド "AIRS: Model Management"、論文 Section 5・Figure 4。 - **5.1 Model Hosting:** ユーザは自前 tech-stack か AIRS ホスティングサービスを選べる。Model Config（serving 設定・checkpoint・TPU リソース）を UI で登録すると、AIRS が Model Start / Restart / Resize を提供。部分/完全ダウンしたサーバは reboot し、モデルアドレスを定期チェックして autorater が最新ライブモデルへ接続可能に保つ。 - **5.2 Resource Pooling and Model Scaling:** TPU は高価で供給が限られる。サーバ起動待ちを避けるため常時稼働。低 duty cycle での TPU 浪費を抑えるため、model hosting service がモデルサーバのフリートを動的調整（典型的に 1 サーバが複数 replica を起動し評定トラフィックを処理）。共有 TPU プールでは同一プール内の他モデルの利用率も考慮して均衡化。 - **設計原則（スライド）:** Automated Operations（障害サーバの自動再起動・TPU 使用調整）、Resource Pooling（duty cycle を上げる動的フリート調整）、Balanced Scaling（共有プール横断の利用率ベース再配分）。 ## Rating Fulfillment スライド "AIRS: Rating Fulfillment"、論文 Section 6・Figure 5–6。 - **6.1 Rating Fulfillment Server:** 評価ワークフローから評定予測リクエストを受領（Step 1）。受領時にアーカイブの有効評定有無をチェック（Step 2 = Cache check）。無ければタスクを生成し Queue へ追加（Step 3、State table に PENDING を transactional に作成）。有効評定があれば充足をスキップし COMPLETED エントリを作成。 - **6.2 Queue:** 未充足タスクを保持し、RPC で Rating Generator へ転送（Step 4 = QPS-adjusted RPC requests）。応答に基づき送出 QPS を調整。TPU 枯渇起因の RPC 失敗時は成功率に合わせて送出レートを下げる。R_ID 単位で QPS を制御。失敗タスクは指数バックオフ（上限 30 分）で再キュー。キュー可能タスク数に上限なし。 - **6.3 Rating Generator:** executor フリート上でタスクを実行。AIRS の API でカスタム rating generation ロジックを plug-in（追加データ取得、LLM プロンプト作成、model server への RPC）。**3 つのトラフィック制御:** ① **Back-pressure**（モデルごとに R_ID 単位で QPS を自動制限）、② **Retry with back-off**（RPC エラー時に事前設定バックオフで再試行）、③ **Quota check in integrated mode**（実行前に Quota Management Service へ TPU 予算可否を問い合わせ、capacity 超なら小さなバックオフで再キュー、isolated mode ではスキップ）。 - **6.4 Completion Checker:** State table を定期確認し、単一ワークフロー起点の全評定タスク完了を検知（Step 8）してワークフローへ通知（Step 9）、メトリクス計算等をトリガ。max duration やデフォルト設定で、少数の未完了に引きずられて全体が次フェーズへ進めない事態を防止。 - **6.5 Prioritization:** ワークフロー実行時に発見的ルールで priority score を付与（新モデル checkpoint リリースでの利用か、要求者の権限等を考慮）。Quota Management Service が利用可能 TPU クォータの判定に使用（高優先度を fast-track）。優先度情報はリクエストコンテキストにも符号化されホストモデルへ送られ、TPU 制約時にホストモデル側が高優先度実行を優先・低優先度をリジェクト（後で AIRS が再試行）。 - **6.6 Client Side Caching:** 多数の独立ワークフローが同一検索結果を生む。**Page Quality と Needs Met の評定の freshness window は 90 日**。窓内の既存評定を再利用し新規予測呼び出しを回避（高コストな TPU を節約し、安価で潤沢なストレージ/CPU と交換）。リクエストは冗長になりうるためハッシュスキームで一意キーを生成しインデックス化（query_text・url・html・ContextParam 等の必須フィールドを stringify して連結・hash）。モデル識別子もキーに含め、新モデルが旧モデルを置換した際に旧評定を無効化。TTL は 90 日＋バッファ。 - **6.7 Batching:** Rating Fulfillment Server がワークフロー指定の batch size で複数評定タスクを 1 単位へ集約。TPU 利用最適化のため 1 呼び出しあたり複数予測が望ましい。**デフォルト batch size は 12**（クライアントが調整可）。 - **Quota Management Service（論文 Section 5.3・Figure 5）:** 各評定リクエストは起点評価の ID を含む。AIRS は評価 ID と traffic rule の対応を保持し、Rating Generator は送出前にクォータチェック（high priority は多く許可、過負荷モデルはトラフィック削減、ユーザが過剰に評価を起動すれば当該評価を抑制）。 ## 結果（Results） 論文 Section 7、スライド "AIRS: Performance Results"。トップライン autorater AR_1（integrated mode）と AR_2 に関する観測値。 - **7.1 TPU Duty Cycle:** AR_1 対応モデルの平均 TPU duty cycle を 8 日間観測（論文 Figure 7, Oct 18–25）。一般にピーク時は **1.0 に近い（close to 1）** 値を維持。AIRS が TPU 追加割当でスケールアップする際に一時的に低下、週末は低利用。duty cycle 最大化＝推論スループット最大化。 - **7.2 Cache Hit Rate:** AR_1 のキャッシュヒット率を 8 日間観測（論文 Figure 8, Oct 2025）。平均で **40% の時間** で新規リクエスト生成の代わりに既存評定をルックアップ＝**平均 40% cache hit rate**。 - **7.3 Observed QPS:** AR_1 の QPS をピーク比 % で提示（論文 Figure 9）。バッチ後の incoming QPS はピークの 30%–100% で変動、post cache QPS はピークの 20%–40% で安定、**実際のモデルへの QPS はピークのわずか 1–4%**（キャッシュとトラフィック制御の効果）。 - **7.4 Reliability:** AR_1 の rating generation failure rate（2 時間デッドライン超で失敗とマーク）。**中央値の失敗率 0.8%**、80 パーセンタイル 2.7%、90 パーセンタイルは大規模評価により相対的に高く 23%。**80 パーセンタイルの成功率 97.8%** が高信頼性を示す。 - **7.5 Latency:** AR_1 と AR_2 の 75p 評価メトリクスレイテンシを 8 日間観測（論文 Figure 10, 2026 年 3 月）。両 autorater のデフォルト TPU 割当は **20 倍（factor of 20、AR_1 = 20X, AR_2 = X）** 異なる。高 TPU 割当の AR_1 のメトリクスレイテンシは AR_2 より桁違いに低く、**AR_1 のメトリクスはしばしば 30 分以内に生成**。AR_2 の 75p レイテンシは繁忙日に **最大 33 時間** までスパイク。共有 TPU プールのため線形ではなく、AR_2 を縮小して可視性の高い AR_1 を優先。オフピークでは AR_2 のレイテンシ低下・AR_1 上昇。 - **7.6 Prioritization:** AR_1 のクエリセット内で高優先度ユースケースが全 incoming リクエストの **約 80%–90%** を占め、受領即実行。対照的に低優先度トラフィックは **5–10 倍遅い** 顕著なレイテンシを経験し、成功まで複数回の再試行を要した。 - **7.7 Relation between Cache Hit Rate, QPS and Latency:** 低キャッシュヒットの日（10/12, Figure 8–9）は AR_1 の post cache QPS がスパイクし、高 post cache QPS は一般に高メトリクスレイテンシを招く。オフピーク（10/12 等）は共有 TPU プールの全体予測リクエストが少なく、トラフィックを持つモデルが TPU をスケールアップできレイテンシ増を相殺。 ## 結論 論文 Section 8。 - AIRS はリソース制約環境で LLM 評定予測を生成するライブ推論システム。caching・queuing・batching・quota accounting・back-pressure・prioritization により、高い評定予測スループットと信頼性を達成しつつレイテンシを最小化。 - 結果として AIRS は検索エンジン評価のトップライン評定を **数時間以内（a couple of hours）** に生成可能。model hosting・management サービスは利用容易性をクライアントに提供。 - リソース制約環境での ML 推論システムの今後の発展への寄与を期待する旨で締め。 ## 補足（論文 Appendix） - **A Training objectives:** Ordered-Pair Accuracy (OPA, eq. 5)、Pairwise MSE、Endpoint Calibration の 3 目的。PQ 評定の値域は -1 (Very Bad) から 3 (Very Good)。weighted sum of Endpoint Calibration + Pairwise MSE を採用し、両端の予測精度（+3 と -1 の弁別）を確保。 - **B Feature extraction:** SRP の on-SRP コンテンツ（クエリテキスト・UI 要素）に加え、内部 Document Index から landing page の primary text・semantic annotation を取得。YouTube は内部 Video API、image 結果は landing page title、raw HTML は Web Rendering Service で抽出。ローカル結果は専用 location table から address/ratings/user distance を補完。プロンプトは semantic feature を delimiter 付きで連結（fine-tuned のためテンプレート不要）。 - **C Rating monitoring pipeline:** Continuous monitoring（固定クエリセットで AI と人間の評定の乖離を継続検出）と、実ユーザ評価からクエリをサンプルし AI 評定分布で人間専門家へルーティングする gold-standard validation の 2 種。