要点
- Meta (2026-11-03) ships F3 Lightning: per-feature release on top of F3 while restoring shared execution at startup for >20,000 ads-ranking features.
- Legacy F3: merged graph = release unit; one bad definition blocks the batch; growth to 20k+ made late model tests hold everyone.
- Four efficiency steps: stable computation IDs, one execution plan, shared memory buffer, dense index mapping; deploy-only prototypes raised CPU.
- Reported: comparable extraction features ~3.6× faster to production vs prior F3 with no infra compute-cost increase.
On 3 November 2026 Meta Engineering detailed F3 Lightning, a layer on Facebook Feature Framework (F3) that lets each of the >20,000 features behind ads ranking compile, validate, ship, and roll back on its own—without giving up the shared-execution savings of the merged graph.
Thesis: when the merged execution graph is also the release unit, one bad definition blocks the fleet; separating deployment granularity from shared execution yields ~3.6× faster comparable feature production with no rise in infrastructure compute cost.
[1]What shipped
F3 (AI @ Scale 2020) authors features as DAGs and merges duplicate reads/filters/aggregations so shared work runs once per request. Efficiency came from the merge; the catch was that the graph was the release—Figure 2’s seven features with two unrelated faults need three attempt cycles before anything ships. At >20k features, model-related tests for live features land late, so everyone waits together.
Lightning changes two contracts: each feature is an independently releasable configuration; at startup the runtime rebuilds one shared execution plan over active configs instead of executing per-feature graphs that re-pay shared work.
[1]How hard is the evidence
Four steps restored efficiency (mechanisms are checkable; the multiplier is Meta-reported):
- Stable computation IDs derived from op, parameters, and input IDs—not local node numbers—so configs compiled weeks apart still recognize the same work.
- One execution plan via topological sort at startup; duplicate IDs collapse; the plan flattens to an ordered list; failures mark only downstream nodes not-ready.
- One shared memory buffer per request, killing per-feature containers’ cache misses and duplicate list/map copies; readiness lives apart from values (empty list is valid).
- Dense index mapping so request-path access is a direct array slot, not a hash probe.
Reported outcome: comparable extraction features reach production ~3.6× faster than prior F3 with no increase in infra compute cost. Early deploy-only prototypes raised CPU substantially—proof that independent release is not free without shared execution.
[1]Steelman and gaps
Steelman: at tens of thousands of features, insisting on one merged artifact trades fleet downtime for micro-optimizations; moving request-invariant work to startup is ordinary high-QPS discipline.
Gaps: 3.6× uses an internal “comparable features” denominator outsiders cannot audit; a shared plan can still make hot operators a blast radius (downstream not-ready helps, but latency tails aren’t published); portability beyond ads DAG feature stacks is analogy, not proof.
[1]Who pays, what to watch
Ads and recommendations feature platforms pay first: blocked release queues eat model iteration count. Any ML platform that fused “save CPU” with “ship together” should treat that boundary as a falsifiable design choice.
Watch for percentile latency and failure blast-radius data, and whether other large platforms copy “independent configs + startup merge” instead of another monolithic graph.
[1]Close
The defensible claim is that deployment and execution need separate boundaries—the 3.6× result and the CPU regression of deploy-only prototypes support that engineering proposition. It does not say every team must rewrite its feature framework; it says that at >20k features, keeping the merged graph as the release unit is a choice the outage pattern can falsify.
[1]