F3 Lightning: Meta acelera em 3,6 vezes a chegada de features de ML de anúncios à produção

O F3 (Facebook Feature Framework) é o framework da Meta para criar, compilar e servir as features de ML dos modelos de ranking de anúncios. Uma única requisição pode exigir mais de 20.000 features. Ele representa a extração como um DAG: cada nó faz uma unidade de trabalho (ler entrada, filtrar, agregar) e o compilador funde os grafos de todas as features de um serviço num grafo único, colapsando operações duplicadas, como um filtro de sete dias. O problema é que esse grafo também era a unidade de release. Uma definição inválida travava todas as outras features.

O F3 Lightning separa deploy de execução. Cada feature vira uma configuração própria, validada, publicada e revertida de forma independente. Para não perder eficiência, o runtime faz quatro coisas na inicialização: IDs de computação estáveis (derivados da operação, dos parâmetros e dos IDs das entradas), um plano de execução único com ordenação topológica e achatado em lista, um buffer de memória compartilhado por requisição (melhor localidade de cache, um vetor de readiness separado, sem cópias duplicadas de listas e mapas) e mapeamento denso de índices, que troca hash e lookup por acesso direto a array. O resultado informado: features comparáveis chegam à produção cerca de 3,6 vezes mais rápido, sem aumento de custo de compute.

Em 3 de novembro de 2026, o CEVIU noticiou "Meta apresenta F3 Lightning e entrega features de ML para ads cerca de 3,6x mais rápido, sem custo extra de infraestrutura", sobre o mesmo anúncio. Esta matéria acrescenta o detalhamento técnico das quatro otimizações e do porquê de o grafo mesclado do F3 original bloquear releases.

Para quem opera plataformas de features, a leitura é que acoplar o artefato de deploy ao de execução cobra um preço que cresce com o catálogo. A própria Meta conta que o F3 original funcionava bem com algumas centenas de features e travou ao passar de 20.000. O ponto mais transferível é o da memória: remover computação repetida não bastou, e o layout dos resultados e o número de cópias pesaram no CPU. Vale medir isso antes de otimizar só o grafo lógico.