F3 Lightning：Meta如何大规模加速广告机器学习特征的生产上线
内容提要
Meta的F3框架将广告排序模型的数万特征编译为共享图执行，但整图作为发布单元，单个特征出错会阻塞全部发布。F3 Lightning将每个特征的编译、验证、部署和回滚独立化，并通过稳定计算标识符、统一执行计划、共享内存缓冲区和稠密索引映射四项优化，在启动时完成去重与排序，保持原有计算效率。特征上线速度提升约3.6倍，基础设施计算成本不增加。
延伸解读
发布粒度与执行边界分离是核心思路
F3 Lightning 的关键不是单纯把特征拆开发布，而是把“何时上线”和“如何执行”拆成两个边界。传统 F3 中合并图既是执行单元又是发布单元，因此任一特征定义出错都会拖住整批发布。拆分后，单个特征可独立验证、部署和回滚，而运行时仍在启动阶段统一整理共享计算。这一设计说明：发布灵活性与执行效率未必互斥，前提是把两者解耦。
启动时做一次性工作，请求路径只做必要计算
文章反复强调，识别共享计算、确定执行顺序、定位结果存储这三件事在每个请求中都不变，因此被移到服务启动阶段完成。稳定标识符、统一执行计划、稠密索引映射都属于这一类优化。对读者的启示是：在高并发服务中，凡是不随请求变化的结构性工作，放到初始化阶段往往比在请求路径上反复计算更划算，也能让独立发布不额外增加单次请求成本。
内存布局和副本数量同样影响 CPU 成本
一个容易被忽略的结论是：即使消除了重复计算，早期原型仍比传统 F3 更耗 CPU，原因在于每个特征各自持有请求期数据容器，中间结果分散在不同内存分配中，遍历计划时频繁缓存未命中。改为每请求一个共享缓冲区后，连续步骤访问相邻内存，且列表和映射不再复制。文章据此指出，在现代 CPU 上，结果放在哪里、存在几份，可能与计算次数同样重要。
独立发布带来的风险需要显式隔离
共享执行计划也引入新风险：某个计算失败可能波及依赖它的所有特征。F3 Lightning 的应对是，当计算失败或输入不可用时，把下游节点标记为未就绪并跳过，独立分支继续运行。同时，已被线上模型消费的特征变更要走更严格的测试，新特征则可按标准验证较快发布。这说明细粒度发布并非无条件放开，而是配合就绪传播和按影响排序的发布队列来控制风险。
Q&A
F3 Lightning 解决了 F3 的什么核心问题？
F3 将数万特征编译为单一合并图，但整图作为发布单元，单个特征出错会阻塞全部发布。F3 Lightning 将每个特征的编译、验证、部署和回滚独立化，使单个特征的问题不再影响其他特征上线。
F3 Lightning 如何在不合并图的情况下保持 F3 的计算效率？
通过四项优化：1）稳定计算标识符，基于操作、参数和输入标识符生成，使相同计算可被识别；2）启动时构建单一执行计划，用拓扑排序去重并扁平化为有序列表；3）所有特征共享一个请求级内存缓冲区，提升局部性并避免重复拷贝；4）稠密索引映射，将标识符映射为连续整数槽，实现直接数组访问。
F3 Lightning 的特征上线速度提升了多少？计算成本有增加吗？
可比特征的提取上线速度比传统 F3 快约 3.6 倍，且基础设施计算成本没有增加。更短的发布周期还允许在同一时期内进行更多模型迭代。
F3 的合并图为什么会导致发布阻塞？
因为合并图既是执行单元也是发布单元，一个格式错误或无效定义会使整个合并图构建失败，所有特征都无法发布。随着特征数量从几百增长到超过 2 万，且不同特征需要不同测试，阻塞问题愈发频繁。
F3 Lightning 如何隔离单个特征的发布？
每个特征在编译器中单独编译为独立配置，包含该特征所需的所有节点，不依赖其他特征。发布路径变为按优先级排序的队列，根据影响和风险选择发布，新特征可快速通过标准验证，而已被模型使用的特征变更需额外测试。
F3 Lightning 在启动时做了哪些原本在请求路径上的工作？
启动时完成三项原本每次请求都重复的工作：识别共享计算（通过稳定标识符去重）、决定执行顺序（拓扑排序并扁平化）、确定结果存储位置（稠密索引映射）。这些工作只做一次，因此独立发布不会给单个请求增加计算成本。
F3 Lightning 的共享内存缓冲区解决了什么问题？
早期原型中每个特征配置携带自己的请求时数据容器，中间结果分散在不同内存分配中，导致缓存未命中。F3 Lightning 改为每个请求一个共享缓冲区，启动时将引用重绑定到槽位，带来局部性提升、单一就绪向量和避免重复拷贝，从而恢复顺序访问模式并降低 CPU 使用。
