Meta/Recommendation Systems

5 posts

meta3 min readCurated summary

From User Sequences to Scaling Laws: A Multi-Stage Architecture for Meta’s Ads Ranking

Meta’s new sequence-learning platform improves ads recommendations by separating deep offline user modeling from fast online ranking. Combined with dense tokenization and target-aware attention, it enables richer behavioral representations, predictable compute-to-performance scaling, and major gains: 6% more Instagram conversions, 3% more Facebook conversions, and 3.5% more Facebook ad clicks. The system is also a core part of Meta’s Generative Ads Recommendation Model (GEM). ## Challenges of Earlier Sequence Models - Ads systems must rank thousands of candidates within milliseconds and process millions of candidates per second. - Hybrid architectures typically use: - One model for user event sequences. - Another for sparse feature interactions. - This design can cause: - Lossy knowledge transfer between components. - Continued dependence on manually engineered features. - Scaling limits caused by interference between sequence modeling and ranking. - Increasing sequence lengths and transformer capacity can therefore raise serving costs without delivering proportional improvements. ## Multi-Stage Sequence Modeling Meta separates sequence learning into two complementary stages: - **Offline user modeling** - Processes long user histories asynchronously. - Uses deep transformer models with thousands of events and multiple layers. - Produces cached, user-level embeddings that represent long-term behavioral patterns. - Keeps user features separate from ad and context features so embeddings remain independent of individual candidates. - **Online ranking** - Combines cached user embeddings with fresh user signals, ad features, and context. - Performs final ranking under strict latency requirements. - Uses a lightweight architecture optimized for real-time serving. This separation allows the offline model to grow in depth, width, and sequence length without proportionally increasing online serving costs. ## Dense Tokenization and Target-Aware Attention - **Dense tokenization** - Converts sparse features and sequential behavioral data into a shared dense vocabulary. - Allows the model to learn feature interactions directly instead of relying on manually engineered cross-features. - **Target-aware multi-head attention** - Combines user behavior sequences with the specific ad candidate being scored. - Lets each attention layer determine which past behaviors matter for that candidate. - Stacked attention blocks capture increasingly complex interactions and compress long histories into compact representations. - The approach is designed to be memory-efficient while preserving candidate-specific information. ## Predictable Scaling Laws - On real-world ads traffic, the architecture shows an LLM-like log-linear relationship between compute and recommendation performance. - Improvements were measured using normalized entropy across: - Model depth. - Model width. - Sequence length. - Content and semantic enrichment. - The scaling behavior suggests the architecture is well suited to continued investment in sequence learning, despite recommendation systems combining sparse IDs with temporal data rather than dense text. ## Scaling Strategies - **Balanced model shape** - Depth, width, and sequence length should grow together. - Scaling only one dimension can create bottlenecks and diminishing returns. - Meta calls this the “scaling synergy principle.” - **Multi-stage tunability** - Online models offer strong improvements per unit of compute but are constrained by request latency. - Offline models improve more gradually but can scale aggressively because inference is asynchronous. - **Sequence composition** - Longer sequences generally improve performance. - Diversity of actions is more valuable than simply adding more homogeneous events. ## Practical Conclusion Meta’s approach makes sequence learning more scalable and operationally practical by moving expensive user-history processing offline while retaining fast, target-specific ranking online. Dense tokenization and target-aware attention reduce manual feature engineering, while the observed scaling laws provide a framework for deciding where additional model capacity and compute will produce the greatest gains.

Read original(opens in new tab)
meta4 min readCurated summary

GEM Training: How Meta Doubled the Efficiency of Its LLM-Scale Ads Foundation Model

Meta’s Generative Ads Recommendation Model (GEM), which powers ad recommendations across Instagram and Facebook, now trains at LLM scale across several thousand GPUs. By co-designing kernels, numerical precision, parallelism, networking, and memory management, Meta doubled end-to-end training efficiency to 20–25% Model FLOPs Utilization (MFU) while increasing training compute fourfold in 12 months. The work shows that recommendation models require infrastructure specifically adapted to their hybrid architecture and data patterns rather than a direct reuse of LLM techniques. ## GEM’s Architecture and Training Challenges - GEM combines: - Trillions of sparse embedding parameters. - Billions of dense parameters. - Sequence features, such as user activity history. - Non-sequence features, such as user location and ad representations. - Different feature groups use customized attention mechanisms while still supporting cross-feature learning. - Recommendation workloads differ substantially from typical LLMs: - User histories have highly variable lengths, making padding inefficient and potentially wasting up to 50% of computation. - Attention patterns are asymmetric, including long sequences with short windows and long queries with short key/value sets. - Small embedding dimensions and normalization layers create memory-bound operations. - CTR and CVR optimization are numerically sensitive, so aggressive low-precision training can harm model quality. ## Scaling Across Thousands of GPUs - GEM’s distributed training latency is determined by the slowest rank and the larger of its local computation or communication time. - Efficient scaling requires: - Computation to dominate communication. - Communication to overlap with computation without resource contention. - Minimal activation recomputation. - Balanced workloads across GPU ranks. - GEM makes these requirements difficult because: - Trillion-scale sparse parameters generate substantial communication. - Different layer types provide uneven opportunities for communication overlap. - Long sequences and large activations pressure GPU memory. - Jagged inputs create changing load imbalance and stragglers. ## Separating Compute and Scaling Efficiency - Meta measures end-to-end efficiency with: - **E2E MFU = Local MFU × Scaling Ratio** - **Local MFU** measures how effectively one GPU uses its compute hardware, including Tensor Cores and memory hierarchies. - **Scaling Ratio** measures how much single-GPU performance is retained across thousands of GPUs. - This framework separates: - Kernel design and numerical precision issues affecting individual GPUs. - Parallelism, networking, memory, and load-balancing issues affecting distributed training. ## Compute-Efficiency Optimizations - Meta developed recommendation-specific GPU kernels, including: - Jagged Flash Attention (JFA) for variable-length sequences. - Generalized Dot-Product Attention (GDPA). - BlockAttention. - These kernels are designed around GEM’s irregular shapes and asymmetric attention patterns rather than conventional LLM assumptions. - Mixed ultra-low-precision training, including MXFP8 for attention and MLP layers, improves throughput while accounting for recommendation models’ numerical sensitivity. - The kernels and precision recipes are customized to exploit the architecture of the latest-generation GPUs. ## Scaling-Efficiency Optimizations - Meta uses topology-aware five-dimensional parallelism to distribute GEM efficiently. - Dense parameters use: - Two-dimensional Fully Sharded Data Parallelism (FSDP). - Expert Parallelism. - Sparse parameters use fully sharded two-dimensional model parallelism. - These strategies are co-designed with Meta’s multi-tier network hierarchy to reduce communication overhead. - Streaming Multiprocessor (SM)-free collectives help communication run with less interference from GPU computation. - The overall design targets communication overlap, memory constraints, load balance, and the differing behavior of dense and sparse parameters. ## Results - GEM’s end-to-end training efficiency increased to 20–25% MFU. - Efficiency doubled over a 12-month period. - Total training FLOPs increased fourfold. - The results demonstrate that recommendation foundation models can reach LLM-scale training, but only through coordinated hardware and software optimization across kernels, precision, parallelism, networking, and memory. For large recommendation models, LLM infrastructure provides a starting point but is not sufficient. The practical recommendation is to optimize compute and distributed scaling as separate but connected problems, using workload-specific kernels, carefully validated low precision, topology-aware parallelism, and communication strategies tailored to sparse and dense model components.

Read original(opens in new tab)
meta4 min readCurated summary

SilverTorch: Index as Model — A New Retrieval Paradigm for Recommendation Systems

SilverTorch is a unified, GPU-based recommendation retrieval system designed to replace fragmented microservices with one integrated neural network. Its “Index as Model” architecture represents retrieval components—including item indices, filtering, reranking, and user modeling—as PyTorch modules. The system reportedly delivers up to 23.7× higher throughput and 20.9× better compute-cost efficiency than comparable CPU-based or traditional multi-service systems, while improving recommendation quality. ## Limits of Microservice-Based Retrieval - Traditional retrieval pipelines use separate services for: - Computing user embeddings - Finding similar content - Applying eligibility rules - Scoring and reranking candidates - An orchestrator coordinates these services before passing thousands of candidates to downstream ranking, all within roughly 100 milliseconds. - This architecture creates several structural problems: - **Data movement:** Network calls, serialization, and service coordination consume latency that could otherwise support more computation. - **Version inconsistency:** User models, item indices, and filtering rules may be updated independently, causing mismatches between user and item representations. - **Siloed engineering:** ML teams typically work in PyTorch while infrastructure teams work in C++, making improvements difficult to translate, test, and deploy. - GPU optimizations such as Faiss-GPU can accelerate individual services but do not eliminate the architectural overhead or enable deep coordination between components. ## Index as Model - SilverTorch replaces the service mesh with a single neural network. - Its central design principle, **Index as Model**, turns traditional retrieval artifacts into model components: - Item indices become tensors. - Eligibility filters become operators. - User towers, scoring layers, and rerankers become modules. - A single request passes through the integrated model, which: - Finds content relevant to the user’s interests - Applies language, geography, and policy constraints - Predicts multiple engagement outcomes - Produces a combined score for the final candidate set - This integration enables more complex models and larger candidate evaluations without exceeding the sub-100-millisecond latency target. ## Unified Retrieval Components - SilverTorch incorporates multiple functional regions within one model: - Approximate nearest-neighbor search identifies relevant items efficiently. - Eligibility filtering removes content that cannot be shown to a user. - Multi-task reranking predicts actions such as likes, shares, and comments. - Composite scoring combines these predictions into a final ranking signal. - Some components are hand-engineered, while others can be trained end-to-end through backpropagation. - From the runtime’s perspective, every component is a standard PyTorch `nn.Module`, regardless of whether it performs search, filtering, or learned prediction. ## Pure PyTorch Implementation - SilverTorch reimplements ANN search, Bloom-filter indexing, eligibility checks, neural reranking, and composite scoring as pure PyTorch modules. - The unified design requires: - Tensor-based data representation - Tensor-in, tensor-out operations - A consistent `nn.Module` interface - This allows modules to share memory, execution graphs, and compilation steps. - Engineers can co-design stages—for example, selecting promising clusters, filtering within them, and scoring only surviving candidates—instead of treating each operation as an isolated service. - The approach reduces the separation between ML and infrastructure engineering, allowing both groups to work within the same programmable layer. ## Performance and Scale - In an 80-million-item end-to-end evaluation, SilverTorch achieved: - **23.7× higher requests per second** than a strong traditional multi-service baseline using the same model architecture. - **20.9× better estimated total-cost-of-ownership efficiency** than a CPU-based solution. - The system is intended to support retrieval across multiple applications and large-scale feeds and video products. - Its increased efficiency makes neural reranking and multi-task engagement scoring practical within strict production latency budgets. SilverTorch’s main recommendation is architectural: consolidate retrieval into a single, composable model rather than optimizing disconnected services. Representing every retrieval stage as a PyTorch module can reduce overhead, improve consistency, enable deeper cross-stage optimization, and make more sophisticated recommendations feasible at scale.

Read original(opens in new tab)
meta3 min readCurated summary

Friend Bubbles: Enhancing Social Discovery on Facebook Reels

Friend bubbles in Facebook Reels surface videos that friends have liked or interacted with, combining content discovery with opportunities for conversation. The system uses machine-learning models to estimate viewer-friend closeness, retrieve relevant friend-interacted videos, and rank them alongside conventional recommendation signals. Its goal is not to show the most bubbles possible, but to identify meaningful connections and content that can drive both engagement and social interaction. ## System Architecture - The recommendation system combines: - **Viewer-friend closeness**, determining whose interactions matter most. - **Video relevance**, determining which friend-interacted videos best fit the viewer. - Multiple friends interacting with the same video can indicate stronger shared interest. - Social discovery and engagement reinforce one another: relevant friend content encourages interaction, which improves the system’s understanding of the social graph. ## Modeling Viewer-Friend Closeness - Facebook uses two complementary models: - A survey-based model estimating real-world relationship strength. - An activity-based model estimating closeness from on-platform behavior. - The survey model considers: - Mutual friends and interaction patterns. - User-provided attributes such as location. - Number of friends and posts shared. - Communication frequency and other survey proxies for offline closeness. - Users are periodically asked whether they feel close to a randomly selected connection. - The model is refreshed regularly and performs weekly inference across trillions of friend relationships. - The activity-based model learns from likes, comments, reshares, and interactions occurring after bubbles are shown. - Facebook prioritizes connection quality over quantity: larger friend networks may create more opportunities, but the system aims to surface only relationships likely to make recommendations meaningful. ## Retrieving and Ranking Friend Content ### Expanding Candidate Retrieval - The retrieval stage explicitly sources videos interacted with by close friends. - This expands the recommendation funnel so high-quality friend content can reach downstream ranking systems. - Without dedicated retrieval, relevant friend videos might never become candidates. ### Adding Social Context to Ranking Models - Friend-interacted videos could rank poorly when models lacked viewer-friend closeness information. - The system added bubble interaction signals and relationship-strength features to early- and late-stage multi-task, multi-label ranking models. - These features help models distinguish social relevance from ordinary content-interest signals. - Feedback from bubble impressions and resulting interactions continuously flows back into model training. - Ranking objectives consider: - Watch time. - Likes and comments. - The probability of engagement after a bubble impression: `P(video engagement | bubble impression)`. - Tunable weights balance entertainment and video quality against social goals such as discovering friends’ interests and encouraging conversation. ## Client Infrastructure and Reels Performance - Friend-bubble metadata had to be integrated without harming Reels’ core experience. - The implementation targeted: - Smooth scrolling. - No additional loading latency. - Low CPU usage during metadata retrieval and processing. - Facebook aligned bubble metadata retrieval with the existing video prefetch window, which already loads metadata, thumbnails, and buffered content before playback. - This allows the system to reuse cached results and avoid adding unnecessary work during scrolling. Friend bubbles work best when social relevance and content quality are optimized together. By combining relationship models, friend-aware retrieval and ranking, feedback-driven learning, and performance-conscious client infrastructure, Facebook turns shared video interests into lightweight opportunities for discovery and conversation.

Read original(opens in new tab)
metaOriginal article

Adapting the Facebook Reels RecSys AI Model Based on User Feedback (opens in new tab)

Meta has enhanced the Facebook Reels recommendation engine by shifting focus from traditional engagement signals, like watch time and likes, to direct user feedback. By implementing the User True Interest Survey (UTIS) model, the system now prioritizes content that aligns with genuine user preferences rather than just short-term interactions. This shift has resulted in significant improvements in recommendation relevance, high-quality content delivery, and long-term user retention. **Limitations of Engagement-Based Metrics** * Traditional signals like "likes" and "watch time" are often noisy and may not reflect a user’s actual long-term interests. * Models optimized solely for engagement tend to favor short-term value over the long-term utility of the product. * Internal research found that previous heuristic-based interest models only achieved 48.3% precision in identifying what users truly care about. * Effective interest matching requires understanding nuanced factors such as production style, mood, audio, and motivation, which implicit signals often miss. **The User True Interest Survey (UTIS) Model** * Meta collects direct feedback via randomized, single-question surveys asking users to rate video interest on a 1–5 scale. * The raw survey data is binarized to denoise responses and weighted to correct for sampling and nonresponse bias. * The UTIS model functions as a lightweight "alignment model layer" built on top of the main multi-task ranking system. * The architecture uses existing model predictions as input features, supplemented by engineered features that capture content attributes and user behavior. **Integration into the Ranking Funnel** * **Late Stage Ranking (LSR):** The UTIS score is used as an additional input feature in the final value formula, allowing the system to boost high-interest videos and demote low-interest ones. * **Early Stage Ranking (Retrieval):** The model aggregates survey data to reconstruct user interest profiles, helping the system source more relevant candidates during the initial retrieval phase. * **Knowledge Distillation:** Large sequence-based retrieval models are aligned using UTIS predictions as labels through distillation objectives. **Performance and Impact** * The deployment of UTIS has led to a measurable increase in the delivery of niche, high-quality content. * Generic, popularity-based recommendations that often lack depth have been reduced. * Meta observed robust improvements across core metrics, including higher follow rates, more shares, and increased user retention. * The system now offers better interpretability, allowing engineers to understand which specific factors contribute to a user’s sense of "interest match." To continue improving the Reels ecosystem, Meta is focusing on doubling down on personalization by tackling challenges related to sparse data and sampling bias while exploring more advanced AI architectures to further diversify recommendations.