The Pulse
Meta Separates Ads Feature Releases as a Request Can Require More Than 20,000 Features
Meta’s F3 Lightning system lets ads machine-learning features be released independently while retaining shared execution. The company says comparable extraction features reach production about 3.6 times faster than with traditional F3, with
AI.info Team · Written with AI · fact-checked ·
Meta published the account on November 3, 2026, describing F3 Lightning as an infrastructure layer for its Facebook Feature Framework, or F3. The framework serves machine-learning features used by ads ranking models; a single request can require more than 20,000 features. Meta says the new system lets each feature be compiled, validated, deployed and rolled back independently.
One faulty feature could delay the whole release
F3 originally combined the graphs for a service’s features into one execution graph. When multiple features needed the same operation, such as filtering events to a seven-day window, the merged graph could perform that work once and share the result. The same merged graph also defined the release, however, so an invalid feature could stop the rest from shipping.
That constraint became more significant as F3 grew from a few hundred features to more than 20,000, according to Meta. Features already used by live models need additional model-related tests before release, and the company says those tests run at a later stage because they are computationally expensive. Under the earlier batch-release approach, every feature in the graph waited for those checks.
F3 Lightning separates shipping from execution
F3 Lightning gives each feature its own configuration and release path. A faulty configuration can be held back without blocking an unrelated feature, while the release queue can prioritize changes according to what they unblock. Meta says a new feature not yet used by a model can go through standard validation, while a change to a feature read by a live model gets extra testing.
Independent releases initially came at a cost: early prototypes used substantially more CPU because each feature’s graph repeated reads, filters and aggregations that F3 had shared. Meta’s system restores shared execution at service startup, rather than rebuilding one merged release artifact. It compiles features separately, then combines their shared work into a common execution plan.
Four optimizations restore shared work
First, F3 Lightning derives stable identifiers from a computation’s operation, parameters and inputs, allowing separately compiled features to recognize identical work. At startup, the system uses those identifiers to build one execution plan, remove duplicate computations and arrange the remaining work in dependency order. It then flattens that plan into a list for a forward pass on each request.
The shared plan does not mean every failure stops every feature: Meta says the executor marks downstream work as not ready when a computation fails or an input is unavailable, while independent branches continue. The system also places request-time results in one shared memory buffer instead of separate per-feature containers. Most list and map results are stored once and referenced by their consumers; scalar values are copied.
Finally, F3 Lightning assigns each unique computation a consecutive integer slot during startup and rewrites configuration references to use those slots. That lets the request path read results by direct array index rather than resolving identifiers through hashing and lookup tables. Meta says the combined changes cut production time for comparable extraction features by about 3.6 times against traditional F3 without increasing infrastructure compute cost.