要点
- Meta says ads ranking models are growing toward LLM scale faster than the hardware that serves them, and that an extra unit of compute helps some requests, models, and chips more than others.
- Intelligent Delivery is described as an ML-driven allocation layer that has added about 10% incremental ranking performance on top of model and system advancements from 2017 through the first half of 2026.
- A Resource Core Model with 6 billion sparse parameters and 20 million dense parameters runs once before candidate retrieval. Meta says reframing allocation as two ML problems improved identification of the highest-impact ad requests by about 20% in offline benchmarks, relative to the previous production model.
- Allocation is split across regions, hardware types including Intel, AMD, and Arm CPUs and NVIDIA, AMD, and MTIA accelerators, and per-host budgets under a tail-latency target.
- In the first half of 2026, agents contributed to about 20% of Intelligent Delivery optimizations, and to about 80% of the engineering effort on the most automated mechanism. Engineers review and approve the final change. Meta says this shortens the loop from months to weeks.
Meta Engineering published a post on 11 November 2026 about Intelligent Delivery, the company's system for deciding where each unit of ads-serving compute should go. The timing is not casual. Ranking models are growing toward the scale of large language models, while the fleet that has to run them in a few hundred milliseconds is finite and mixed. Meta's claim is that the next increment in ranking quality can come from a better decision about which request, on which chip, at which stage of the funnel, should receive the next unit of compute.
[1]What Meta says it built
Intelligent Delivery is presented as a machine-learning layer that sits on top of the serving stack and keeps redirecting resources toward the requests, models, hardware fleets, and ranking stages with the highest marginal utility. The company says this layer has contributed an additional approximately 10% improvement in ads ranking performance, on top of model and system advancements, across major surfaces, from 2017 through the first half of 2026.
Three difficulties, in Meta's telling, make that job hard. The return on an extra unit of compute depends on the product surface, user intent, candidate quality, and system state, and has to be estimated in milliseconds. A locally good choice in one region or at one ranking stage can be a bad choice for the system as a whole. The target keeps moving when models, hardware, and architecture change.
The first capability is a shared request-understanding layer. Meta used to group requests into coarse segments and write policies by hand. It says that approach stopped scaling as new signals multiplied, and that independent segments could not capture nonlinear interactions among thousands of signals. It then framed two questions as ML problems: which ad requests are most likely to benefit from more compute, and how will different resource settings change outcomes and serving performance. The Resource Core Model, a deep network with 6 billion sparse parameters and 20 million dense parameters, runs once before candidate retrieval and is shared across the delivery funnel. Specialized models are fine-tuned from it to predict incremental effects on outcomes, compute use, and latency. Meta says this improved identification of the highest-impact ad requests by about 20% in offline benchmarks on major surfaces, relative to the previous production model.
[1]How a request is steered
The second capability is a hierarchy of allocators, because a single controller cannot move resources cleanly across data centers, hardware generations, and a multi-stage stack. Meta walks through one request. First, which region should serve it? Traffic and capacity are not in the same place, and hardware mix and headroom differ by region. The company built infrastructure to shift traffic between regions on a cycle of minutes, aiming for each region to reach the same efficiency on its last unit of capacity.
Second, which hardware should the request land on? The fleet includes CPUs from Intel, AMD, and Arm, and accelerators from NVIDIA, AMD, and Meta's own MTIA, across several generations. Capacity is not interchangeable. Retrieval is often bound by memory, ranking by compute, inference by accelerator throughput. Meta says it benchmarks efficiency for each workload and chip pair, then assigns scarce hardware to the workloads that turn it into the most useful work.
Third, inside a host, how much of the machine does this request get? Concurrent requests have different latency budgets and different expected impact, under a hard tail-latency target. Models predict the likely outcome and the compute and latency cost in real time. A constrained optimizer then spends the host's budget on higher-impact work and trims low-impact, expensive work as load rises. The controls run from the kernel scheduler up to application thread pools. Later decisions include how many ads to rank at each stage and which candidates enter the pool.
These choices are coupled. Moving traffic between regions changes per-host load, which changes how much work each request is allowed. Meta says it validates changes in a hardware test environment that runs the full serving path and feeds results back, so that it is optimizing for a system-wide result rather than a local one.
[1]Agents in the optimization loop, and the limits of the evidence
The third capability is the optimization loop itself. Meta says it cannot brute-force every configuration across millions of tunable dimensions when a new model, mechanism, or hardware generation arrives. Hand-picked search by engineers did not keep up. A later constrained optimizer helped but covered only a few knobs and did not absorb prior human judgment well.
The current approach uses AI agents that read mechanism source code, design documents, and a decade of experiment logs, then propose a short list of changes worth testing. Engineers review and approve what ships. Meta says that in the first half of 2026, agents contributed to about 20% of Intelligent Delivery optimizations, and that on the most automated mechanism they now contribute to about 80% of the engineering effort, from forming a hypothesis to running experiments. The company says this shortens the loop from months to weeks, while leaving people in control.
All of these figures, the 10% since 2017, the 20% offline lift, and the 20% and 80% agent shares, come from Meta. There is no independent audit, no public definition of "ranking performance," and no breakdown that separates this allocation layer from nine years of other serving work. The 10% number is cumulative across a long window. It is a company-reported increment, not a third-party measurement.
[1]The fair objection
A fair reading is that large advertising systems have been doing traffic steering, hardware placement, and latency-aware scheduling for years, and that Intelligent Delivery is a more statistical version of that practice, now with a large request model and some agent-written experiment proposals. On that view, "about 10% since 2017" is a long enough window that almost any persistent serving program could claim a similar increment, and the agent percentages measure internal workflow, not ad quality.
The objection is fair. It does not erase the narrower point. If ranking models are moving onto GPUs in fixed blocks, as Meta says is happening with its Generative Ads Model, GEM, then the old CPU habit of shaving time slices off a request starts to fail. The interesting claim is not that Meta invented allocation. It is that, at LLM-like ranker scale, the binding constraint is the assignment of heterogeneous capacity, and that this assignment now has to be predicted per request rather than written as static rules.
[1]What this changes for people who run models, beyond advertising
For Meta, the stake is whether it can keep serving larger ranking models to more people under the same capacity and the same latency target. For everyone else running expensive inference, the transferable idea is smaller. When the model is already large, the next unit of quality may come from deciding which traffic deserves the expensive path.
Meta says two frontiers are still open. One is to fuse request understanding and serving decisions into a single model that acts in real time, without months of experiments. The other is to rebuild the levers for GPUs, where capacity arrives in whole blocks and batching and memory behave differently from CPU time. Those are research directions, not results already on the board.
[1]What to watch in the next six months
The checkable tests are whether Meta publishes a clearer definition of the 10% ranking metric, whether the agent-proposed changes keep a measurable share of production wins, and whether the GPU allocation work for GEM-scale models is described with numbers rather than as a future plan. Until then, treat Intelligent Delivery as a serious account of a serving problem that other large inference stacks will also hit, and treat the percentages as Meta's own scorekeeping.
[1]