Meta's Intelligent Delivery: a shared request-value model steers ad compute, with gains reported loosely

What we checked

• What allocation mechanism and measured ranking or compute gains does Meta report for Intelligent Delivery? partly confirmed. The mechanism is described in reasonable detail: a shared 6B-sparse/20M-dense request model, then region, hardware-matching and in-host constrained-optimization engines, with an agent-assisted tuning loop. The gains are a cumulative ~10% ranking improvement since 2017 and an offline 20% improvement at identifying high-impact requests. Meta reports no compute, cost or latency savings figure. [1]

What we found

• Meta frames the problem as compute scarcity, not model quality. The core of the system is a 'Resource Core Model' that runs once per request before candidate retrieval and is shared across the whole delivery funnel. Specialized models fine-tuned from it predict a request's outcome value, compute cost and latency impact. Earlier versions relied on coarse rule-based segments by surface, context and creative type, which Meta says did not scale. [1]
• Allocation is split into a hierarchy of decision engines. Region routing moves traffic between data centers every few minutes. Hardware matching benchmarks each workload on each hardware type and assigns scarce hardware where it is used best: per the post, retrieval is memory-bound, ranking is compute-bound, and model inference is limited by accelerator throughput. An in-host optimizer then maximizes predicted impact within the host's latency budget and cuts expensive, low-value work first when the host is under load. [1]
• The headline gains are coarse. Meta credits Intelligent Delivery with about 10% incremental ranking performance, on top of model and system improvements, accumulated from 2017 through the first half of 2026. The newest model shows about a 20% improvement at identifying the highest-impact requests, but only in offline benchmarks against the previous production model. The post gives no compute, cost or latency savings figure and no online A/B result for that model. [1]
• The tuning loop is increasingly run by agents. They monitor the system, read code, design documents and experiment logs, and propose changes to test. In the first half of 2026, agents contributed to about 20% of Intelligent Delivery optimizations, and Meta says they do about 80% of the engineering effort on its most automated mechanism. Humans still approve every shipped change. Meta says this shortened the optimization loop from months to weeks but gives no detail on how that was measured. [1]
• Meta flags that the design is under strain. Its Generative Ads Model (GEM) is growing toward LLM scale and increasingly runs on GPUs. GPU capacity comes in whole, fixed blocks rather than divisible CPU time, so the per-request levers built for the CPU era have to be redesigned. Meta's stated next goal is a single real-time model that makes allocation decisions jointly across all serving stages. [1]
• The post builds on earlier public work on request-level routing. Social Media Today reported in March 2026 that Meta's Adaptive Ranking Model on Instagram uses intelligent request routing to match model complexity to user context. Meta's own conversion and click-through gains for that model are separate from Intelligent Delivery's numbers and should not be combined with them. [2]

What it means

The reusable idea is the architecture, not the numbers. Meta runs one model per request, before retrieval, to estimate the marginal value, cost and latency of spending more compute on that request. That shared estimate then drives separate allocators at the region, hardware and host levels, so local fixes don't fight the system-wide goal. Teams running multi-stage retrieval or LLM inference under capacity limits can copy this pattern at smaller scale: predict which requests benefit from deeper ranking or bigger models, and cut low-value, expensive work first under load. Meta's emphasis on testing changes in an end-to-end, closed-loop hardware environment is a warning that these levers interact.

Don't treat the figures as a benchmark. The ~10% is a nine-year cumulative ranking gain mixed with other improvements, the 20% is offline only, and there is no compute-savings number. The agent result, about a fifth of optimizations in H1 2026 with humans approving every shipped change, is a useful data point for agent-assisted performance tuning, but it is self-reported and not independently checked. Meta also says its own CPU-era levers need redesign for GPU serving in fixed blocks, so GPU-first stacks should expect to rethink, not port, per-request allocation.

Competing readings

• Intelligent Delivery is a real, mature production layer: a shared request-value model feeding stacked allocators across regions, hardware and hosts. Its main lesson for builders is architectural, not a benchmark to copy (likely, about 65%). What would tell it apart: Meta names a specific shared model (6B sparse, 20M dense parameters) run once before retrieval, plus distinct region, hardware and in-host engines [1]; Meta reports the impact as a cumulative ~10% ranking gain since 2017, which is consistent with long-lived infrastructure [1].
• The post is mainly a showcase of agentic engineering and GPU-era positioning. The allocation stack is old work repackaged, and the new story is that agents are doing the tuning (unlikely, about 30%). What would tell it apart: The newest numbers concern agent contributions in H1 2026, while the ranking gain is spread over nine years [1]; The 'next frontier' section is about GEM moving onto GPUs, where CPU-era levers break [1].
• The reported gains are overstated or not attributable, because there is no compute-savings figure and the 20% gain is offline only (very unlikely, about 5%). What would tell it apart: The 20% request-identification gain is from offline benchmarks against the previous production model, with no online or compute figure [1].

Base rate

Of 32 earlier research stories about companies or projects in the New Runtime archive over the last 12 months that are at least 3 months old, 22 (69%) were followed within 3 months by a release story on the same company or product line. In 22 of 32 earlier research stories in New Runtime's archive, a release story on the same company or product line followed within 3 months. Meta's ads-infrastructure blog series is busy, so more posts or launches are plausible. Intelligent Delivery is internal, though, so a 'release' would probably be another engineering post or ads-product update, not something builders can use.

What would change this view

• Meta publishes a paper or follow-up post with online A/B results and compute or cost savings attributed to Intelligent Delivery specifically (signal): The gains would be attributable and measurable, which would strengthen the case that this is a reusable recipe with known payoff.
• Meta open-sources components of the allocation stack or the agent tuning loop (open-source signal): Builders could test the approach directly, so it would stop being a design description only.
• A later Meta post says GEM's GPU serving has replaced the per-request CPU-era levers described here (model-listing signal): The architecture described would be transitional, and its lessons would apply less to GPU-first stacks.

Still open

• How much compute, cost or latency does Intelligent Delivery save, separately from its ranking gains?
• Does the 20% offline improvement in identifying high-impact requests carry over to online results?
• How is the ~10% gain since 2017 attributed, given that models and hardware changed at the same time?
• How will per-request allocation work once GEM serving is GPU-first and capacity comes in fixed blocks?