# F3 Lightning: Scaling Meta's Ads Machine Learning Feature Production Decoupling feature releases from shared execution to accelerate model iteration cycles at scale. - **Source:** [Engineering at Meta](https://brifing.si/source/28383801-e365-4f15-8f20-49d8c0635946) - **Published:** 2026-11-03 - **Topic:** [Software & Engineering](https://brifing.si/c/engineering) - **Original article:** - **On Brifing:** https://brifing.si/s/92de1a27-3535-4a8b-9f4e-e5b667d07880 ## The F3 Scaling Challenge Meta originally developed the Facebook Feature Framework to manage over 20,000 features for ads ranking models. By compiling features into a single merged graph, the system achieved high computational efficiency. However, this monolithic structure meant that a single malformed feature definition could block the entire release pipeline, hindering development velocity. ## Introducing F3 Lightning F3 Lightning is an infrastructure layer built atop F3 to decouple feature releases from shared execution. This design allows engineers to compile, validate, and deploy features independently. By separating the deployment boundary from the execution boundary, the team successfully eliminated the all-or-nothing release constraint that previously plagued the system. ## Maintaining Computational Efficiency Early prototypes of per-feature releases suffered from increased CPU usage because they lost the benefits of shared computation. To achieve efficiency parity, the team implemented four optimizations: stable computation identifiers, a single shared execution plan, a unified memory buffer, and dense index mapping. These ensure no redundant work occurs during requests. ## Stable Computation Identifiers The runtime must identify identical computations across independently compiled configurations to avoid redundant processing. F3 Lightning derives identifiers based on the operation, parameters, and input identifiers rather than local node numbers. This allows the system to recognize shared work even if features were compiled and released weeks apart by different teams. ## Unified Execution Planning At service startup, F3 Lightning builds a single execution plan using a topological sort. When multiple features share a node, the plan retains one copy and connects all consumers. The system flattens this graph into an ordered list, enabling a single forward pass per request instead of traversing complex graph structures. ## Shared Memory Buffers To reduce cache misses, F3 Lightning replaces per-feature data containers with one shared memory buffer per request. This ensures consecutive plan steps touch adjacent memory locations. By storing results once and using references, the system avoids expensive data copying, significantly reducing the CPU overhead associated with managing intermediate feature values. ## Direct Array Access Finding feature values was previously computationally expensive due to hashing and pointer chasing. F3 Lightning assigns every unique identifier a consecutive integer slot at startup. This allows the executor to perform direct array index lookups during the request path, completely removing the need for runtime hashing or complex lookup tables. ## Deployment Granularity Benefits Features are now selected from a priority queue based on impact and risk. New features can be deployed quickly with standard validation, while modifications to live models undergo more rigorous testing. This granular approach ensures that a failure in one feature does not block the deployment of unrelated, healthy feature updates. ## Performance and Iteration Gains Comparable extraction features now reach production approximately 3.6 times faster than under the previous F3 framework. This shortened release cycle allows Meta to perform more model iterations and retraining within the same timeframe. Crucially, these gains were achieved with no increase in infrastructure compute costs, proving the efficiency of the design. ## Separating Deployment and Execution A key lesson from the project is that deployment and execution boundaries should remain distinct. If one artifact dictates both how components run and when they ship, failures become systemic. By splitting these responsibilities, Meta removed the trade-off between operational efficiency and the speed of the software release pipeline. ## Optimizing the Request Path The team concluded that work which remains constant between requests belongs at startup, not on the request path. Tasks like identifying shared work and determining execution order are now performed once when the service starts. This architectural shift ensures that independent releases do not add computational latency to individual user requests. ## Memory Layout Matters The project demonstrated that CPU usage is heavily influenced by where results live and how many copies exist. Even after removing repeated computations, CPU usage remained high until memory was consolidated. This highlights that on modern hardware, data locality and memory layout are as critical as the total number of operations. ## Sources covering this story - https://engineering.fb.com/2026/11/03/ml-applications/f3-lightning-how-meta-accelerates-ads-ml-features-to-production/ — --- _Summary written by Brifing from the original reporting. Copyright in the original article belongs to its publisher; read the full piece at the link above._