F3 Lightning：Meta 如何加速廣告 ML 功能大規模上線

Meta 推出 F3 Lightning。這是建立在 Facebook Feature Framework (F3) 之上的基礎設施層，用來解決廣告排名模型中機器學習功能的大規模部署問題。在單一請求中，廣告排名模型可能需要超過 20,000 個功能。F3 Lightning 把功能發布與共用執行拆開，讓每個功能都能獨立編譯、驗證、部署和回滾。

從單一圖形到獨立發布的演進

傳統的 F3 架構把所有功能編譯成單一合併圖形，以降低執行的計算成本。不過，這張圖形同時也是發布單位，所以只要有一個失敗或無效的定義，整條發布管線就會被卡住。早期有人嘗試讓每個功能獨立發布，但因為功能不再共用計算，CPU 使用率因此上升。

F3 Lightning 的編譯器依據工作的性質（操作、參數、輸入識別符）而非位置，來推導每個識別符。因為每個輸入的識別符已反映其上游的所有內容，這個識別符就涵蓋了產生結果的整條工作鏈。當輸入順序不影響結果時，輸入會被放入標準順序。聚合操作包含定義其行為的屬性，例如時間視窗和分組鍵。兩個特徵只要定義相同的操作、使用相同的輸入，就會得到相同的識別符，即使它們是在數週前分別編譯和發布的。如果計算的含義改變，識別符也會跟著改變。

執行計畫與記憶體優化

服務啟動時，F3 Lightning 用拓撲排序為所有活躍特徵建立單一執行計畫，每個節點都排在它所依賴的節點之後。當多個特徵含有識別符相同的節點時，計畫只保留一份副本，並把所有使用者連到該節點，因此不論有多少特徵用到，這項計算都只執行一次。啟動過程會把執行計畫扁平化成有序列表，每個請求只需沿著列表做一次前向傳遞，不必遍歷圖形。

F3 Lightning 以每個請求一個緩衝區取代每個特徵各一個容器，並在啟動時把每個特徵的引用重新綁定到該緩衝區的槽位。連續的計畫步驟現在存取相鄰的記憶體，步驟要讀的數值通常已經在快取中，也不再需要為每個請求的每個特徵分配記憶體。單一向量取代了每個特徵的追蹤，執行器不必讀取值，就能檢查值是否就緒。共享槽位持有生產者結果的引用，所以被多個特徵使用的計算只算一次、只存一次。單一值（標量）仍會複製，因為複製小值比跟隨引用更便宜。

效能提升與發布週期影響

使用 F3 Lightning，可比較的提取特徵生產速度比傳統 F3 快約 3.6 倍，基礎設施計算成本沒有增加。發布週期縮短，代表模型能在相同時間內更頻繁地改進和重新訓練。

在失敗處理上，如果計算失敗或其輸入不可用，F3 Lightning 會把所有下游節點標記為未就緒，執行器會跳過該工作。失敗只影響依賴該節點的節點，獨立分支繼續運行。

F3 Lightning 為每個唯一識別符分配連續的整數槽位，並重寫配置中的所有引用，讓它們指向這些槽位，因此識別符只在初始化期間使用。讀取結果變成對共享緩衝區的直接陣列索引，請求路徑上沒有哈希和查找表。如果每次存取都要解析識別符，就得對鍵做哈希、探測桶並跟隨引用，在 Meta 的服務量級下計算效率不高。

F3 Lightning 的推出解決了早期每功能發布原型中 CPU 使用率增加的問題。透過把功能發布與共用執行拆開，F3 Lightning 讓每個功能都能獨立編譯、驗證、部署和回滾。這讓可比較的提取特徵生產速度比傳統 F3 快約 3.6 倍，基礎設施計算成本沒有增加。發布週期縮短，代表模型能在相同時間內更頻繁地改進和重新訓練。