Ad-DS Paper Circle #1

広告輪読会第一回スライド

Transcript

1. A Bag of Tricks for Scaling CPU-based Deep FFMs to more than 300m Predictions per Second 〜 アドテクDS勉強会第一回 〜 AI事業本部 Dynalyst 大塚皇輝
2. 1. 自己紹介 2. 事前知識 3. 論文紹介 a. オンライン施策 i. Deep FFM ii. 学習高速化 b. オフライン施策 i. キャッシュ戦略 ii. 実行最適化 iii. 量子化 iv. 差分更新 4. 感想
3. 大塚 皇輝 • Dynalyst 24 新卒 • 趣味 ◦ ツーリング（日本一周した） ◦ 散歩 • 好きな食べ物 ◦ トムヤムクン
4. 1. 自己紹介 2. 背景 3. 論文紹介 a. オンライン施策 i. Deep FFM ii. 学習高速化 b. オフライン施策 i. キャッシュ戦略 ii. 実行最適化 iii. 差分更新 iv. 量子化 4. 感想
5. 背景 • 推薦や広告といった分野で Factorizatioin Machineベース 手法が未だに 一般的 ◦ 主にスケーラビリティ起因 • GPU利用を前提としてモデル 多いが、CPU利用前提 モデル 少なく、今 回 後者にフォーカス
6. モチベーション 推しポイントそ １ CPUによる深層学習モデル 実装 推しポイントそ 2 推論制約 突破 数々 手法紹介
7. 1. 自己紹介 2. 背景 3. 論文紹介 a. オンライン施策 i. Deep FFM ii. 学習高速化 b. オフライン施策 i. キャッシュ戦略 ii. 実行最適化 iii. 差分更新 iv. 量子化 4. 感想
8. FFM (Field-aware Factorization Machine) • 特徴量 潜在ベクトル同士 組み合わせを用いる事で計算量を削減 • 交互作用を考慮するため2つ 特徴量 組み合わせごと 重みを使用
9. DeepFFM • LRとFFM 入力をMLPに突っ込む • LRで単体作用、FFMで交互作用を取 得してMLPで表現力を増加
10. DiagMask 交互作用なら値一緒な で、片方不要
11. MergeNormLayer (入力 - 平均)/標準偏差 https://github.com/outbrain-inc/fwumious_wabbit/blob/b343 5aa00a92be8e8e603830c1556b2f66c2ff9c/src/block_normaliz e.rs#L133-L163 LR FFM これな気がする…… 入力 スケールをあわせて結合
12. Stability Analysis • タスク設定 CTR予測 • 評価指標 AUC • 期間ごとに異なるハイパラで実験 期間A 期間B パフォーマンスがど 期間でも 安定すること確認する実験 …… 設定A 設定B ： 設定A 設定B ：
13. Stability Analysis 黒線:AUC 最高値 赤線:AUC 平均値 灰色:性能 上位、下位5% （灰色が少ないほど安定） • 黒 点線と黒トレー ス部分が近さ • 灰色部分 少なさ 安定度 見方
14. 1. 自己紹介 2. 背景 3. 論文紹介 a. オンライン施策 i. Deep FFM ii. 学習高速化 b. オフライン施策 i. キャッシュ戦略 ii. 実行最適化 iii. 差分更新 iv. 量子化 4. 感想
15. Model warm-up
16. バッチ学習 学習1回目 (12/1) 学習2回目 (12/2) モデル準備 データ準備 (12/1 ~ 12/7) モデル準備 データ準備 (12/2 ~ 12/8) ⋮ ⋮ 新しいサーバー 新しいサーバー • 学習ごと データ取得 • データ 期間重複 　　　　　　　　etc. … 効率が悪い
17. Model warm-up モデル準備 新しいサーバー 常時データ取得 • 常にデータを取得し続ける事で、データ取得 時間を削減 • 学習完了後 モデルに過去 リクエストを 流して暖気？ • スケジューリング 少々工夫する必要があ る（Kubernetes Taints and Tolerations） ◦ スペックが高く、最新データが入ってる サーバーに最新 学習を割当 学習1回目 (12/1) 学習2回目 (12/2) ⋮
18. Hogwild
19. 通常 並列計算 lock lock lock Memory （重み） Thread 1 Thread 2 Thread 3 • 通常競合が起きな いようにメモリ lock
20. Hogwild Memory （重み） Thread 1 Thread 2 Thread 3 競合を許容し、 メモリをロックしない Rust unsafe (Pythonだと言語仕様的に無理) https://doc.rust-jp.rs/book-ja/ch19-0 1-unsafe-rust.html conflict!
21. Hogwild • 単純に並列化してる分早い • メモリロック等 オーバーヘッドが無い で早い • 性能（Revenue Per Mille）に関して 、ABテスト実施した結果著しい低下 ない ※RPM (Revenue Per Mille) : 1000 Impressionあたり 収益
22. Sparse weight update
23. Relu関数 0 1 2 -1 -2 1 2 3 X < 0なら0になる で計算不要 • 活性化関数 計算負荷 小さい も を選択 • 0未満 0に丸め込まれる
24. Sparse weight update … X ・W 活性化関数 … … 0 ReLU: 0 if x < 0 ReLU関数によって0未満 入力 0になる で、 予め0未満 入力となってるノードから分岐している重 み 計算不要
25. 1. 自己紹介 2. 背景 3. 論文紹介 a. オンライン施策 i. Deep FFM ii. 学習高速化 b. オフライン施策 i. キャッシュ戦略 ii. 実行最適化 iii. 差分更新 iv. 量子化 4. 感想
26. 前提 • 著者 環境 ミニバッチ学習想定 • モデル 更新間隔が極端に短い（5分とか） ◦ 転送帯域問題等が発生 http://papers.adkdd.org/2024/paper-presentations/slides-adkdd24-skrlj-bag.pdf
27. キャッシュ戦略
28. Context cache • Requestからくる内容 うち、不変なも をキャッシュ ◦ ユーザー情報、ブラウザ情報等 • 恐らくfield情報 潜在ベクトルをキャッシュしておき、ユーザー情報分 計算が不 要になる？ predict_with_cache関数 https://github.com/outbrain-inc/fwumious_wabbit/blob/b3435aa00a92be8e8e603830c1556b2f66c2ff9c/src/lib.rs#L110 Fields キャッシュ https://github.com/outbrain-inc/fwumious_wabbit/blob/b3435aa00a92be8e8e603830c1556b2f66c2ff9c/src/block_ffm.rs#L475
29. 推論時間 変化 32ms → 24ms →
30. 実行最適化
31. SIMD (Single Instruction Multiple Data) • 単一 命令で複数 データを一括処理できるコンパイラ 機能 • 低レベル言語(Rust, C++とか)だと実行できるがPythonだとできない • Rust 場合 ビルド時 feature flagによって使用有無を決定 • CPU バージョンによって演算器 設定が異なる で、設定時 要注意 ↓実行時引数 SIMD設定 https://github.com/outbrain-inc/fwumious_wabbit/blob /b3435aa00a92be8e8e603830c1556b2f66c2ff9c/buil d.sh#L13 個別 関数に み設定する場合 デコレータ的なも で設定すると for文がSIMDで実行される→
32. SIMD (Single Instruction Multiple Data) SIMD化と 何か / Basics of SIMD ~ SIMD化 簡単な説明 ~ 詳しく こちら スライドを参照
33. 推論時間 変化 これって何msから何msになった？ 徐々に推論時間上がってる 、な んでだ？
34. 差分更新
35. バッチ学習 新しいサーバー 常時データ取得 学習1回目 (12/1 15:00:00) ⋮ 学習1回目 (12/1 15:05:00) モデル1号 モデル2号 更新頻度が高けれ 学習データ 差分 小さい 　　　↓ モデル 差分も小さい で ？ 　　　↓ モデル全部を切り替える必要 無い で ？
36. Patch update http://papers.adkdd.org/2024/paper-presentations/slides-adkdd24-skrlj-bag.pdf 重み 差分だけ判定し、新しいモデルにするというより、 モデルインスタンスを更新し続ける感じ
37. 重み 差分判定 どうやってる かと思ったら 重み byte列をひたすら比較してた 結構こ 処理に時間かかる（数十秒）が 帯域削減 ほうが重要度とインパクトが大きいらし い https://github.com/outbrain-inc/fwumious_wabbit/blob/b3435aa00a92be8e8e60 3830c1556b2f66c2ff9c/weight_patcher/src/main.rs#L82-L119
38. 量子化
39. Quantization 1(整数) 符号付き32bit 0|0000001 0|0000000 00000000 00000000 00000001 符号付き8bit • 重み メモリ使用量を削減できる • 8bitまでならそこまで性能低下しないらしい • 考慮事項 ◦ 量子化と逆量子化 高速 ◦ 丸め込み 幅を動的に決定 ▪ 時系列的なデータ量 変化に起因 3時 ~ 5時 データ量少ない→重み 更新幅も小さい 19時 ~ 21時 データ量多い→重み 更新幅も大きい
40. バケット割当 量子化を行う場合、重みをいくつか バケットに割り当てて丸め込む : バケットサイズ、各バケット 幅 : 可能なバケット数 最大数 各重みを上記 式にそって量子化を行う
41. 具体例 こ 場合各バケット 0: 1.2 ~ 3.4 1: 3.4 ~ 5.6 2: 5.6 ~ 7.8 3: 7.8 ~ 10.0 となる 例え 3.8 バケット1に割り当て ≒3.8 量子化されると1 複合する場合
42. 性能評価 量子化とモデル パッチ更新を使うと、転送ファイルサイズと載せ替え時間が削減で きた
43. Feature work + 自分 所感
44. Feature work MLC: Multi-Label Classification MCC: Multi-Class Classification 推論時 中間計算数値を量子化？
45. 自分 所感 • アイデア 論文内で理解できなく ないが、「どうやる ？」に関して 実装見ないとわか らない • 運用に乗せる 難しそう ◦ 事故った時 切り戻しとか ◦ 原因となったモデルとか
46. Appendix
47. AdKDD と • KDD（Knowledge Discovery and Data Mining） Workshop 一つ • あんまりLLMに侵食されてなさそう？ • TODO: 情報書き足し（社内ブログとか）
48. 著者情報 • Outbrain ML researcher • NLP専門っぽい？ • Auto ML に興味があるっぽい ネイティブアド パイオニア （これど サービス？）
49. 手法一覧 • モデル 量子化 • モデル パッチ更 新 etc. … • サーバー 事前暖気 • メモリ unsafe許容による重み更新 • 不要な重み更新 枝刈り 　　　　　　　　　etc. … • キャッシュ • 単一命令複数実 行 etc. …