DLRM
Jak działa
Forward pass DLRM ma cztery etapy: (1) cechy dense → bottom MLP (kilka warstw FC z ReLU) generujący gęsty wektor o ustalonej wymiarowości D; (2) cechy sparse → embedding lookup w odpowiednich tabelach, każda zwracająca wektor o tej samej wymiarowości D; (3) feature interaction layer — wszystkie wektory (bottom MLP output + embeddings) traktowane jako wiersze macierzy, obliczane są pairwise dot products dające macierz NxN, z której bierze się trójkąt górny (N(N-1)/2 wartości); (4) top MLP — konkatenacja interaction output + bottom MLP output → kilka warstw FC z sigmoid na końcu dla predykcji CTR. Trening: cross-entropy loss vs faktyczne kliknięcia, SGD/Adagrad ze sharded gradient sync.
Rozwiązany problem
Klasyczne podejścia do rekomendacji (np. czyste matrix factorization) nie radzą sobie z wysokowymiarowymi danymi z setkami cech (zarówno dense numerycznych jak i sparse kategorycznych) w środowiskach produkcyjnych Big Tech. Wczesne sieci neuronowe do rekomendacji (Wide & Deep, NeuralCF, DeepFM) różniły się detalami architektury, ale brakowało jednolitej, otwartej implementacji referencyjnej z dedykowaną strategią równoległą dla embedding tables o rozmiarach terabajtów. DLRM rozwiązuje to przez ujednolicony wzorzec architektoniczny + reference implementation + co-design system/algorithm.
Kluczowe mechanizmy
Mocne strony i ograniczenia
Komponenty
Wielowarstwowy perceptron przetwarzający cechy dense (numeryczne, ciągłe). Typowo 2–4 warstwy FC z ReLU, kończące się wektorem o ustalonej wymiarowości D — tej samej, którą mają embeddingi. Lekki obliczeniowo i replikowany między urządzeniami (data parallel).
Oficjalna
Wielkie tabele uczone (E_i: V_i × D, gdzie V_i to liczba kategorii cechy i-tej, D to wymiar embedding) z indeksowanym lookup. W produkcji każda tabela może mieć miliardy wpisów. Sharded model-parallel między urządzenia: różne urządzenia trzymają różne kolumny (wymiary D) lub różne segmenty wierszy.
Warstwa jawnie modelująca cross-feature interactions przez pairwise dot products. Dla N wektorów (bottom MLP output + N-1 embeddings) generuje N(N-1)/2 skalarnych wartości — interakcje drugiego rzędu inspirowane factorization machines. Wynik jest konkatenowany z bottom MLP output i podawany do top MLP.
Oficjalna
Wielowarstwowy perceptron przyjmujący konkatenację bottom MLP output + pairwise interaction values. Kilka warstw FC z ReLU + sigmoid output dla predykcji CTR (lub innej miary score). Również replikowany data-parallel między urządzeniami.
Oficjalna
Schemat parallelizacji łączący data parallel (dla MLP) z model parallel (dla embedding tables sharded między urządzenia). Krytyczna operacja all-to-all przenosi wyniki embedding lookup między urządzeniami przed warstwą interakcji. Ten wzorzec stał się standardem dla skalowalnego treningu rekomendacji.
Implementacja
W production rozmiar embedding tables szybko rośnie do terabajtów (miliardy wpisów × dziesiątki/setki kolumn). Bez shardingu model parallel trening jest niemożliwy na pojedynczym GPU.
Hybrid parallelism wymaga all-to-all komunikacji embedding outputs między wszystkimi urządzeniami w każdej iteracji — w skali setek/tysięcy GPU staje się głównym wąskim gardłem.
Embeddingi nowych itemów są zaczynane od losowej inicjalizacji — model nie ma żadnej semantycznej priorytety o czym jest nowy item, więc jakość rekomendacji dla nowych itemów jest bardzo niska na początku.
Oryginalne DLRM modeluje tylko interakcje drugiego rzędu (pairwise dot products). Wyższe rzędy interakcji (cross 3rd order, np. user×item×context) wymagają explicite dodanych mechanizmów.
Ewolucja
Matrix factorization (np. SVD++) jako dominująca technika rekomendacji — bazowa intuicja dla feature interaction w późniejszych modelach deep learning.
Pierwsze produkcyjne sieci neuronowe rekomendacji: Wide & Deep łączy zapamiętywanie (wide) z generalizacją (deep); YouTube Deep NN wprowadza dwustopniowy candidate generation + ranking.
DeepFM łączy factorization machines (drugi rząd) i deep neural network (wyższe rzędy) w jednym end-to-end modelu — ważny prekursor DLRM.
Naumov et al. publikują DLRM jako ujednolicony wzorzec architektoniczny + open source implementację w PyTorch i Caffe2 + dedykowaną parallelizację hybrydową. Ustanawia standard MLPerf.
TorchRec (PyTorch) — biblioteka rozwijająca pattern DLRM w productionizable framework z modularnymi komponentami sharded embeddings, model parallel, hybrydy dla industrial-scale recommendation.
Rajput et al. (Google, NeurIPS 2023) wprowadzają Semantic IDs i Generative Retrieval — paradygmatyczne odejście od DLRM-stylu dot-product retrieval w stronę autoregresyjnej generacji SIDs. DLRM pozostaje silnym baseline'em do porównań.
Paradygmat RaG (Kuaishou, arXiv 2606.25496) explicitly porównuje swoje wyniki produkcyjne (400M+ DAU) do DLRM baseline'u: +5,46% przychodu reklamowego dla RaG vs DLRM, co potwierdza rolę DLRM jako standardu, względem którego mierzy się postęp.
Paradygmat wykonania
Hybryda dense (MLP) + conditional (embedding lookup) — dlatego DLRM wymaga specjalnej infrastruktury treningowej.
Embedding lookup jest formą rutowania input-dependent: dla każdej próbki tylko niewielki podzbiór wierszy tabel embedding (odpowiadający aktywnym kategoriom) jest faktycznie odczytywany. To kontrastuje z dense MLP, w których aktywne są wszystkie wagi.
Równoległość
Trening DLRM jest jednym z najbardziej zrównoleglonych workloadów w deep learning: setki/tysiące GPU pracują jednocześnie. Inferencja może być replikowana data-parallel, ale wymaga utrzymywania ogromnych tabel embeddingów w pamięci.
Wymagania sprzętowe
MLP w DLRM to typowe GEMM-y na tensor cores; embedding lookup z dużą przepustowością pamięci HBM. Standardowy target dla NVIDIA A100/H100 i AMD MI250.
Google używa wariantów DLRM na TPU dla swoich systemów rekomendacyjnych. SparseCore w TPU v5e/v5p został zaprojektowany specjalnie pod rekomendację typu DLRM.
Inferencja DLRM może być serwowana na CPU (np. Intel AVX-512) — Meta historycznie używała CPU dla części inferencji rekomendacyjnej dzięki przewadze pojemności pamięci nad GPU dla embedding tables.