In the high-stakes world of hyperscale computing, efficiency is the ultimate currency. Meta, the parent company of Facebook, Instagram, and WhatsApp, operates one of the most complex AI inference infrastructures on the planet. Yet, even within this colossal architecture, engineers face a persistent "Inference Capacity Paradox": global fleets may be under extreme strain, yet significant pockets of computing power sit idle in specific regions or across niche accelerator hardware.
To bridge this gap, Meta has engineered a sophisticated system that aggregates these fragmented, opportunistic capacity pockets into a unified, shared pool. By dynamically deploying this "otherwise idle" silicon, Meta is enhancing the relevance of advertisements and improving outcomes for its massive base of global advertisers—all without the need for additional hardware procurement.
The Anatomy of the Inference Capacity Paradox
At the heart of the challenge is the misalignment between demand and resource allocation. Inference fleets are designed to meet strict latency and reliability targets, necessitating a buffer of reserved capacity. However, demand is rarely uniform. It fluctuates based on geography, user behavior, time of day, and the specific architecture of the accelerators (such as GPUs or specialized ASICs) being utilized.
Why Capacity Remains Idle
Even with world-class planning, structural mismatches are inevitable. Factors contributing to this paradox include:
- Regional Demand Imbalance: Traffic spikes in one region leave another region’s capacity underutilized.
- Accelerator Heterogeneity: Different generations of hardware may be optimized for specific tasks, leaving older but capable hardware with unused cycles.
- Provisioning Buffers: To guarantee reliability, teams often over-provision to handle worst-case traffic, resulting in idle headroom during standard operations.
At Meta’s scale, these "pockets" of idle capacity are not trivial; they represent a significant reservoir of compute power. The challenge, however, lies in safely harvesting this power. Because this capacity is "opportunistic," it is preemptible—meaning it can be reclaimed by high-priority tasks with little to no notice.
Chronology: Building the Elastic Infrastructure
The journey toward a shared, opportunistic capacity pool did not happen overnight. It was the result of a multi-year evolution in how Meta approaches resource management.
Phase 1: Identifying the Fragmentation
Initial efforts focused on mapping the "fragmented reservations." Engineers realized that dedicated, team-owned allocations were creating silos. By breaking down these silos, the team sought to create a "common pool" that could be tapped into, provided that the workload was elastic enough to handle the volatility of that pool.
Phase 2: Developing Elasticity Levers
Once the pool was identified, the engineering team needed a way to consume that capacity without jeopardizing the core "baseline" workload. This led to the creation of two distinct, complementary levers: Rank More Ads (RMA) and Serve Better Models (SBM).

Phase 3: Implementing Guardrails
With the levers in place, the focus shifted to safety. The team integrated sophisticated feedback loops and load-shedding mechanisms, ensuring that if capacity was suddenly reclaimed, the system would degrade gracefully rather than collapsing under the weight of the optional work.
Supporting Data and Technical Architecture
The system relies on two primary mechanisms that allow Meta to toggle its computational intensity based on the real-time availability of resources.
Rank More Ads (RMA)
The ads ranking system is a multi-stage funnel. Millions of potential ads are winnowed down to a small selection for the user. RMA increases the "width" of this funnel. When opportunistic capacity is detected, the system ranks more candidates. This requires both CPU and accelerator power, as the system must perform feature processing and ranking for a larger volume of candidates.
Serve Better Models (SBM)
SBM takes a different approach. Instead of ranking more ads, it improves the quality of the prediction for the existing set. When accelerator capacity is available, the system routes a higher percentage of requests to more powerful, computationally expensive AI models. Because SBM keeps the number of candidates constant, it minimizes the strain on CPU-bound upstream services, making it an ideal consumer of accelerator-only surplus.
Performance Calibration
The system uses an optimization-based approach to balance these two levers. By measuring the incremental performance gains of ranking more candidates versus using a smarter model, Meta’s controller continuously updates the allocation strategy to maximize the return on every available watt of power.
Official Perspective: Safety and Reliability
The core mandate for the engineering team was clear: "Optional work must never endanger baseline traffic." To enforce this, the architecture employs a rigorous separation strategy.
For SBM, Meta uses physical isolation. The baseline model and the more powerful model reside on different routing targets. If capacity is reclaimed, the router simply shifts the traffic back to the baseline model, which is already provisioned and ready.
For RMA, the isolation is logical. The system enforces a global budget for additional candidate ranking. If the total capacity drops, the global budget is reduced, forcing the system to automatically throttle back the number of ads being ranked.

Multi-Layer Load Shedding
The system operates with a dual-defense mechanism:
- Centralized Control: A PID controller manages the flow of work based on latency trends over several minutes.
- Local Load Shedding: If a sudden surge in demand or a rapid reclamation of capacity occurs, individual servers and clients perform "value-aware" shedding. By dropping the lowest-value tasks first, the system maintains the integrity of high-value, baseline requests in milliseconds, bridging the gap before the central controller can adjust.
Implications and The Future of Inference
This shift toward an elastic, opportunistic model has profound implications for the future of large-scale AI infrastructure. By turning idle hardware into a performance asset, Meta is effectively increasing its total fleet utility without the capital expenditure associated with adding new server racks.
Moving Toward "Precomputation"
Looking ahead, Meta is exploring "precomputation elasticity." By performing inference tasks ahead of the actual user request, the company hopes to decouple workload from the immediate constraints of live traffic timing. This would allow the system to soak up idle capacity at any time of day, regardless of current user volume.
Democratizing Capacity
Furthermore, the company is actively working to improve model portability and cross-region inference. By making models more "portable," Meta can move tasks from a congested region to one that has an excess of opportunistic capacity, effectively flattening the global supply-demand curve.
Automation of Value
The ultimate goal is a fully automated, optimization-based system that manages capacity allocation based on the expected business value of the inference task. This would move away from manual tuning toward an autonomous infrastructure that treats compute as a liquid, highly fluid resource.
As Meta’s cross-functional team—comprising dozens of engineers and researchers—continues to refine these systems, the broader industry may find a blueprint for addressing its own capacity paradoxes. In an era where AI demand is outpacing hardware supply, the most significant innovation may not be building faster chips, but rather finding the hidden potential in the ones we already have.
Acknowledgments: This achievement was made possible by the dedicated efforts of the Meta engineering team, including David Amsallem, Mohit Bharti, and dozens of others who contributed to the architecture, alongside the strategic guidance of leaders like Neeraj Agrawal and Justin Charlap.






