F3 Lightning: How Meta Accelerates Ads ML Features to Production at Scale
Nov 3, 2026, 9:00 AM · Meta Engineering

Meta untangled when its ads features ship from how they run, and the lesson about memory layout and release boundaries reaches well beyond advertising.
Why it matters
Meta's ads ranking models can pull more than 20,000 features on a single request. Its feature framework, F3, saved compute by compiling all of them into one merged graph, but that graph was also the release. One bad definition held back every other feature behind it.
F3 Lightning breaks that link. Each feature now compiles, validates, ships and rolls back on its own, while the serving side rebuilds shared execution at startup. Meta says comparable features now reach production about 3.6 times faster, with no increase in infrastructure compute cost.
Faster feature releases mean more model iterations in the same window. At Meta's scale, that is a direct lever on how quickly the ads system learns.
From the desk
We think this is one of the more useful engineering posts of the week, and not because of ads. The core idea is clean: the thing that decides how code runs should not also decide when it ships. When one artifact does both, a single failure blocks everyone. Plenty of teams outside Meta are living with that exact trap in monorepos, model registries and config systems.
The honest part is the middle of the story. Meta's first per-feature prototypes used substantially more CPU because features stopped sharing work. Even after deduplicating every computation, CPU stayed above the old system. The gap closed only when they consolidated scattered copies of intermediate results into one shared buffer per request and swapped hash lookups for direct array indexes. That is a reminder that on modern hardware, where data lives can matter as much as how much math you do.
The content-derived identifiers are the clever bit. Two features that define the same operation on the same inputs get the same ID, even if they were released weeks apart. That's what lets independent releases still share work.
Now the other side. This is infrastructure for making an ads machine iterate faster. Faster iteration on targeting and ranking is good for Meta's revenue and arguably for advertisers, but the post says nothing about how faster feature churn interacts with review, privacy checks or user-facing effects. Speed in the release path is only as good as the gates on it. Meta does describe a priority queue that gives extra testing to features a live model already reads, which is the right instinct. We'd like to see that discipline talked about as loudly as the speedup.
Context
Meta first presented F3 at AI @ Scale 2020. The framework lets engineers author features in a high-level language, compiles each into a small graph, and originally merged them into one graph so shared steps, like a seven-day time-window filter, run once per request. F3 began with a few hundred features and now serves more than 20,000. Lightning keeps a single execution plan across active features, and if one computation fails, only its downstream nodes are skipped.
Who feels it
- ML platform teams
- A concrete pattern for separating release units from execution units without paying a compute penalty.
- Advertisers on Meta
- Faster feature releases likely mean ranking models change more often; expect more frequent shifts in delivery behavior.
- Systems engineers
- A well-documented case that cache locality and copy elimination can close gaps that deduplication alone does not.
What to watch
- Whether Meta open-sources any part of F3 or F3 Lightning.
- Similar decoupling of release and execution in other feature stores and serving systems.
- Any Meta disclosure on how feature-level review and privacy checks scale with faster release cycles.
Companies: Meta