Meta F3 Lightning 使广告机器学习特征发布速度提升约 3.6 倍

Meta 于 2026/11/03 推出 F3 Lightning，以便独立发布广告机器学习特征。它解决了 F3 中发布非此即彼的问题，同时保留共享执行的效率。可比的特征提取功能如今进入生产环境的速度比传统 F3 快约 3.6 倍，基础设施计算成本没有增加。

Meta F3 使用共享图提供广告特征

Facebook Feature Framework（F3）是 Meta 用于编写、编译和提供广告排序模型所需机器学习特征的框架。单个请求可能需要超过 20,000 个特征。Meta 首次在 AI @ Scale 2020 上介绍了 F3。

F3 将特征提取表示为有向无环图（DAG）。工程师用高级语言独立编写特征，编译器将每个定义转换为一个小型图。随后，编译器会合并服务所用特征对应的图。当多个特征共享某项操作（例如应用相同的时间窗口筛选）时，F3 会将这项工作整合到单个节点中，每个请求只运行一次。

F3 Lightning 将特征发布与执行分离

在传统 F3 中，合并后的图也是发布单元。因此，格式错误的特征定义可能会阻止图中所有其他特征的发布。随着 F3 从数百个特征增长到超过 20,000 个，这个问题变得更加突出。不同类型的特征需要各自的检查，而模型已经使用的特征在发布前还需要进行与模型相关的测试。这些计算成本高昂的测试会在后续发布阶段运行，从而拖延合并图中其他特征的发布。

F3 Lightning 将每个特征作为可独立发布的配置。每个配置都可以单独验证、发布和回滚，而不会影响其他特征。特征会从有序队列中逐个选出，而非作为一个批次一起发布：模型尚未使用的新特征可以通过标准验证后发布；而被在线模型读取的特征发生变更时，则会先接受额外测试。

F3 Lightning 在启动时恢复共享计算

最初，独立发布特征增加了 CPU 使用量，因为每个配置都以独立图的形式到达，并重复执行读取、筛选和聚合。F3 Lightning 通过在服务启动时整合共享工作来解决这一问题，无需重建 F3 的合并图。

编译器根据操作、其参数以及输入的标识符生成稳定的计算标识符。聚合还会纳入时间窗口和分组键等属性。这样一来，即使独立编译的配置相隔数周才编译和发布，也能识别出相同的计算。如果计算含义发生变化，其标识符也会随之改变。

启动时，F3 Lightning 会为所有启用的特征构建一份执行计划。它通过拓扑排序将每个节点安排在其依赖项之后，保留相同标识符节点的一个副本，并将每个使用方连接到该副本。执行计划会被展平为一个有序列表，使每个请求都只需执行一次正向遍历，而不必遍历图。如果某项计算失败或其输入不可用，下游节点会被标记为未就绪并跳过，同时独立分支会继续运行。

F3 Lightning 使用共享缓冲区和密集索引

F3 Lightning 用每个请求一个缓冲区取代了按特征设置的请求时数据容器。启动时，每个特征的引用都会重新绑定到共享缓冲区中的槽位。这样，相邻的执行计划步骤便可访问相邻内存，系统也无需在每个请求中为每个特征分配内存。

一个与值分开存储的就绪状态向量取代了按特征进行的状态跟踪。将标记单独存放很重要，因为空列表是有效结果，不能同时表示“尚未计算”。对于大多数以列表和映射形式存储的特征值，使用方会共享对生产方结果的引用，而不是接收副本。一个被 20 个特征使用的计算只需计算和存储一次。单值（标量）仍会被复制，因为复制一个小值比跟随指针更省成本。每个缓冲区只在单个请求期间存在，执行顺序则确保每个结果的生命周期长于其最后一次读取。

系统还会为每个唯一标识符分配一个连续的整数槽位，并重写每个配置中的引用，使其指向这些槽位。标识符只在初始化期间使用；读取结果时，会直接通过数组索引访问共享缓冲区，请求处理路径上不需要哈希或查找表。

F3 Lightning 让功能进入生产环境的速度提升约 3.6 倍

可比的特征提取功能如今进入生产环境的速度比传统 F3 快约 3.6 倍，基础设施计算成本没有增加。更短的发布周期使模型能够在同一时期内更频繁地改进和重新训练。Meta 还指出，将部署边界与执行边界分离、把请求之间不会变化的工作移至启动阶段，以及将共享结果整合为单个副本，都有助于缩小其与传统 F3 在 CPU 使用量上的差距。