Ad-DS Paper Circle #1 - Speaker Deck

Slide 1

Slide 1 text

A Bag of Tricks for Scaling CPU-based Deep FFMs to more than 300m Predictions per Second 〜アドテクDS勉強会第一回〜 AI事業本部 Dynalyst 大塚皇輝

Slide 2

Slide 2 text

1. 自己紹介 2. 事前知識 3. 論文紹介 a. オンライン施策 i. Deep FFM ii. 学習高速化 b. オフライン施策 i. キャッシュ戦略 ii. 実行最適化 iii. 量子化 iv. 差分更新 4. 感想

Slide 3

Slide 3 text

大塚皇輝 ● Dynalyst 24 新卒 ● 趣味 ○ ツーリング（日本一周した） ○ 散歩 ● 好きな食べ物 ○ トムヤムクン

Slide 4

Slide 4 text

1. 自己紹介 2. 背景 3. 論文紹介 a. オンライン施策 i. Deep FFM ii. 学習高速化 b. オフライン施策 i. キャッシュ戦略 ii. 実行最適化 iii. 差分更新 iv. 量子化 4. 感想

Slide 5

Slide 5 text

背景 ● 推薦や広告といった分野で Factorizatioin Machineベース手法が未だに一般的 ○ 主にスケーラビリティ起因 ● GPU利用を前提としてモデル多いが、CPU利用前提モデル少なく、今回後者にフォーカス

Slide 6

Slide 6 text

モチベーション推しポイントそ１ CPUによる深層学習モデル実装推しポイントそ 2 推論制約突破数々手法紹介

Slide 7

Slide 7 text

Slide 8

Slide 8 text

FFM (Field-aware Factorization Machine) ● 特徴量潜在ベクトル同士組み合わせを用いる事で計算量を削減 ● 交互作用を考慮するため2つ特徴量組み合わせごと重みを使用

Slide 9

Slide 9 text

DeepFFM ● LRとFFM 入力をMLPに突っ込む ● LRで単体作用、FFMで交互作用を取得してMLPで表現力を増加

Slide 10

Slide 10 text

DiagMask 交互作用なら値一緒なで、片方不要

Slide 11

Slide 11 text

MergeNormLayer (入力 - 平均)/標準偏差 https://github.com/outbrain-inc/fwumious_wabbit/blob/b343 5aa00a92be8e8e603830c1556b2f66c2ff9c/src/block_normaliz e.rs#L133-L163 LR FFM これな気がする…… 入力スケールをあわせて結合

Slide 12

Slide 12 text

Stability Analysis ● タスク設定 CTR予測 ● 評価指標 AUC ● 期間ごとに異なるハイパラで実験期間A 期間B パフォーマンスがど期間でも安定すること確認する実験 …… 設定A 設定B ：設定A 設定B ：

Slide 13

Slide 13 text

Stability Analysis 黒線:AUC 最高値赤線:AUC 平均値灰色:性能上位、下位5% （灰色が少ないほど安定） ● 黒点線と黒トレース部分が近さ ● 灰色部分少なさ安定度見方

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Model warm-up

Slide 16

Slide 16 text

バッチ学習学習1回目 (12/1) 学習2回目 (12/2) モデル準備データ準備 (12/1 ~ 12/7) モデル準備データ準備 (12/2 ~ 12/8) ⋮ ⋮ 新しいサーバー新しいサーバー ● 学習ごとデータ取得 ● データ期間重複　　　　　　　　etc. … 効率が悪い

Slide 17

Slide 17 text

Model warm-up モデル準備新しいサーバー常時データ取得 ● 常にデータを取得し続ける事で、データ取得時間を削減 ● 学習完了後モデルに過去リクエストを流して暖気？ ● スケジューリング少々工夫する必要がある（Kubernetes Taints and Tolerations） ○ スペックが高く、最新データが入ってるサーバーに最新学習を割当学習1回目 (12/1) 学習2回目 (12/2) ⋮

Slide 18

Slide 18 text

Hogwild

Slide 19

Slide 19 text

通常並列計算 lock lock lock Memory （重み） Thread 1 Thread 2 Thread 3 ● 通常競合が起きないようにメモリ lock

Slide 20

Slide 20 text

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!

Slide 21

Slide 21 text

Hogwild ● 単純に並列化してる分早い ● メモリロック等オーバーヘッドが無いで早い ● 性能（Revenue Per Mille）に関して、ABテスト実施した結果著しい低下ない ※RPM (Revenue Per Mille) : 1000 Impressionあたり収益

Slide 22

Slide 22 text

Sparse weight update

Slide 23

Slide 23 text

Relu関数 0 1 2 -1 -2 1 2 3 X < 0なら0になるで計算不要 ● 活性化関数計算負荷小さいもを選択 ● 0未満 0に丸め込まれる

Slide 24

Slide 24 text

Sparse weight update … X ・W 活性化関数 … … 0 ReLU: 0 if x < 0 ReLU関数によって0未満入力 0になるで、予め0未満入力となってるノードから分岐している重み計算不要

Slide 25

Slide 25 text

Slide 26

Slide 26 text

前提 ● 著者環境ミニバッチ学習想定 ● モデル更新間隔が極端に短い（5分とか） ○ 転送帯域問題等が発生 http://papers.adkdd.org/2024/paper-presentations/slides-adkdd24-skrlj-bag.pdf

Slide 27

Slide 27 text

キャッシュ戦略

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

推論時間変化 32ms → 24ms →

Slide 30

Slide 30 text

実行最適化

Slide 31

Slide 31 text

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で実行される→

Slide 32

Slide 32 text

SIMD (Single Instruction Multiple Data) SIMD化と何か / Basics of SIMD ~ SIMD化簡単な説明 ~ 詳しくこちらスライドを参照

Slide 33

Slide 33 text

推論時間変化これって何msから何msになった？徐々に推論時間上がってる、なんでだ？

Slide 34

Slide 34 text

差分更新

Slide 35

Slide 35 text

バッチ学習新しいサーバー常時データ取得学習1回目 (12/1 15:00:00) ⋮ 学習1回目 (12/1 15:05:00) モデル1号モデル2号更新頻度が高けれ学習データ差分小さい　　　↓ モデル差分も小さいで？　　　↓ モデル全部を切り替える必要無いで？

Slide 36

Slide 36 text

Patch update http://papers.adkdd.org/2024/paper-presentations/slides-adkdd24-skrlj-bag.pdf 重み差分だけ判定し、新しいモデルにするというより、モデルインスタンスを更新し続ける感じ

Slide 37

Slide 37 text

重み差分判定どうやってるかと思ったら重み byte列をひたすら比較してた結構こ処理に時間かかる（数十秒）が帯域削減ほうが重要度とインパクトが大きいらしい https://github.com/outbrain-inc/fwumious_wabbit/blob/b3435aa00a92be8e8e60 3830c1556b2f66c2ff9c/weight_patcher/src/main.rs#L82-L119

Slide 38

Slide 38 text

量子化

Slide 39

Slide 39 text

Quantization 1(整数) 符号付き32bit 0|0000001 0|0000000 00000000 00000000 00000001 符号付き8bit ● 重みメモリ使用量を削減できる ● 8bitまでならそこまで性能低下しないらしい ● 考慮事項 ○ 量子化と逆量子化高速 ○ 丸め込み幅を動的に決定 ■ 時系列的なデータ量変化に起因 3時 ~ 5時データ量少ない→重み更新幅も小さい 19時 ~ 21時データ量多い→重み更新幅も大きい

Slide 40

Slide 40 text

バケット割当量子化を行う場合、重みをいくつかバケットに割り当てて丸め込む : バケットサイズ、各バケット幅 : 可能なバケット数最大数各重みを上記式にそって量子化を行う

Slide 41

Slide 41 text

具体例こ場合各バケット 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 複合する場合

Slide 42

Slide 42 text

性能評価量子化とモデルパッチ更新を使うと、転送ファイルサイズと載せ替え時間が削減できた

Slide 43

Slide 43 text

Feature work + 自分所感

Slide 44

Slide 44 text

Feature work MLC: Multi-Label Classification MCC: Multi-Class Classification 推論時中間計算数値を量子化？

Slide 45

Slide 45 text

自分所感 ● アイデア論文内で理解できなくないが、「どうやる？」に関して実装見ないとわからない ● 運用に乗せる難しそう ○ 事故った時切り戻しとか ○ 原因となったモデルとか

Slide 46

Slide 46 text

Appendix

Slide 47

Slide 47 text

AdKDD と ● KDD（Knowledge Discovery and Data Mining） Workshop 一つ ● あんまりLLMに侵食されてなさそう？ ● TODO: 情報書き足し（社内ブログとか）

Slide 48

Slide 48 text

著者情報 ● Outbrain ML researcher ● NLP専門っぽい？ ● Auto ML に興味があるっぽいネイティブアドパイオニア（これどサービス？）

Slide 49

Slide 49 text

手法一覧 ● モデル量子化 ● モデルパッチ更新 etc. … ● サーバー事前暖気 ● メモリ unsafe許容による重み更新 ● 不要な重み更新枝刈り　　　　　　　　　etc. … ● キャッシュ ● 単一命令複数実行 etc. …