要点
- Meta（2026-11-03）发布 F3 Lightning：在 F3 合并图之上拆开「每特征独立发布」与「启动期共享执行」，服务广告排序 >20,000 特征。
- 旧 F3：合并图=发布单元；一个坏定义卡住整包；规模从数百涨到两万后，模型重测阶段拖住所有人。
- 四步效率：稳定计算标识、单一执行计划、共享内存缓冲、稠密下标直取；仅拆发布的原型曾抬高 CPU。
- 自报结果：可比抽取特征进生产约 3.6× 于旧 F3，基础设施算力成本不升。
Meta 工程博客在 2026 年 11 月 3 日介绍 F3 Lightning：叠在 Facebook Feature Framework（F3）之上的一层，目标是让广告排序里动辄超过 20,000 个特征各自独立编译、校验、发布与回滚，同时保住当年合并图带来的共享计算效率。
命题：当合并执行图同时也是发布单元时，一个坏定义会卡住整舰队；把「发布粒度」与「执行共享」拆成两份契约后，可比特征上线可快约 3.6×，且基础设施算力成本不升。
[1]发生了什么
F3（AI @ Scale 2020）把特征写成 DAG，编译期合并重复读、过滤与聚合，一次请求只算共享子图一次。效率来自合并，代价是：图即发布——文中图 2 里七个特征中两个无关错误会逼你连修三次才能整包过线。特征从几百涨到两万后，不同类型特征的校验条不同，模型相关重测只能放在更晚阶段，于是所有人一起等。
Lightning 改了两份契约：部署上每个特征是独立可发布配置，互不借用邻居节点；效率上并不在发布时再合并，而是在服务启动时把现行配置收成一份共享执行计划。作者强调：早期只拆发布、执行仍各算各的原型，CPU 明显高于传统 F3——独立发布本身不是免费午餐。
[1]证据有多硬
四步把效率找回来（机制可复核，倍率来自 Meta 自报）：
- 稳定计算标识：由算子、参数与输入标识派生，而非局部节点号；输入顺序无关时做规范化；聚合带上时间窗与分组键。跨周独立编译的配置仍能认出「同一份工作」。
- 单一执行计划：启动拓扑排序，同标识只留一份，并压成有序列表做一次前向；某计算失败或输入不可用时，只把下游标为未就绪。
- 共享内存缓冲：去掉每特征容器的缓存未命中与 list/map 重复拷贝；就绪向量与值分离——因为空列表是合法结果，不能拿「空」兼表「未算」。
- 稠密下标：启动把标识映成连续槽位，请求路径数组直取，去掉哈希探测。
结果表述：可比抽取特征进生产约 3.6× 于旧 F3，算力成本不增加。三条课：部署与执行边界要拆开；请求间不变的工作放启动期；算完仍可能因内存布局多付钱。
[1]钢人与缺口
钢人：在万级特征下，坚持「一份合并工件」是在用舰队停机换微优化；把不变工作挪到启动期，是高 QPS 服务的常规纪律。
缺口：3.6× 是 Meta 内部「可比特征」口径，外部无法审计分母；共享计划仍可能让热点算子成为爆炸半径（文中用下游未就绪隔离，但尾部延迟分布未给）；对非广告、非 DAG 特征栈的可迁移性是类比而非证明。
[1]谁付钱、下一步看什么
付钱的是广告与推荐特征平台：发布队列阻塞直接吃掉模型迭代次数。也提醒所有「为了省 CPU 而绑死发布」的 ML 平台——边界选错，省下的周期会被等待吃回。对外部读者，更可迁移的不是 F3 这个品牌，而是「配置独立发布 + 启动期识别共享计算」这一对约束。
六个月看：是否补充分位数延迟与失败爆炸半径数据；其他大厂是否复制同一拆分，而不是再造巨型单体图。
[1]收束
F3 Lightning 可辩护的句子是：发布边界与执行边界必须拆开——3.6× 与「原型期 CPU 回升再被四步打平」支撑这一工程命题。它不证明每个团队都应重写特征框架，只证明在 >20k 特征尺度上，继续用合并图当发布单元是可被证伪的选择。
[1]