Meta 廣告服務架構升級：導入 Open-Source Kernel Scheduler 效能優化
文章摘要
Meta 廣告服務架構透過導入開源的 BPF 擴展排程框架 `sched_ext`，進行了重大效能升級。此更新旨在解決現有通用排程器（CFS、EEVDF）無法有效處理廣告遞送高吞吐量（每秒超過 500 萬次請求）的工作負載，導致 p99 延遲增加及廣告排序效率下降的問題。
`sched_ext` 透過將廣告工作負載的特定知識編碼到排程策略中，實現了對 CPU 的軟性分區，優先處理延遲關鍵的請求路徑。這項技術優化是與 Google ghOSt 團隊合作開發，已部署於 Meta 多項服務，並在最大廣告服務伺服器類型上，從 Linux kernel v6.4 遷移至 v6.9 搭配 `sched_ext` 後，觀察到 p99 延遲大幅降低 7%，排名延遲降低 15%，並在後續的兩次使用者空間排程策略更新中，進一步實現了成本降低。
該更新不僅解決了先前因 EEVDF 引入的延遲回歸問題，避免了技術債與操作碎片化，更提供了一個獨立於核心版本發佈的快速迭代優化平台。其使用者空間部署模式，使迭代週期從數月縮短至數天，極大地提升了廣告服務的靈活性與效率，目標使用者為開發者與廣告商。然而，目前 `sched_ext` 仍處於持續優化階段，未來還有更多潛力可待發掘。
`sched_ext` 透過將廣告工作負載的特定知識編碼到排程策略中，實現了對 CPU 的軟性分區，優先處理延遲關鍵的請求路徑。這項技術優化是與 Google ghOSt 團隊合作開發，已部署於 Meta 多項服務，並在最大廣告服務伺服器類型上，從 Linux kernel v6.4 遷移至 v6.9 搭配 `sched_ext` 後，觀察到 p99 延遲大幅降低 7%，排名延遲降低 15%，並在後續的兩次使用者空間排程策略更新中，進一步實現了成本降低。
該更新不僅解決了先前因 EEVDF 引入的延遲回歸問題，避免了技術債與操作碎片化，更提供了一個獨立於核心版本發佈的快速迭代優化平台。其使用者空間部署模式，使迭代週期從數月縮短至數天，極大地提升了廣告服務的靈活性與效率，目標使用者為開發者與廣告商。然而，目前 `sched_ext` 仍處於持續優化階段，未來還有更多潛力可待發掘。
AI 大叔解析
【新聞懶人包】
Meta這次是針對旗下每天處理超過四千億次請求的廣告投放系統，導入一個叫 `sched_ext` 的開源核心排程器框架。簡單講，就是把原本Linux核心那個什麼都不懂的通用型排程器，換成一個可以讓Meta自己寫策略、教它廣告哪些工作比較急的智慧型排程器。這樣一搞，初期就讓廣告請求的99%延遲（p99 latency）降低了3.5%，CPU利用率也提升了3.5%，結果就是能排到名的廣告多了8%。最屌的是，這個框架把排程策略拉到用戶空間，以後更新策略只要幾天，不用像以前動輒好幾個月，還解決了核心版本碎片化的技術債。
【主戰場】算力與基礎設施
【真正主訊號】核心排程器可客製化，讓超大規模服務的算力利用更精準有效。
證據等級：高
原因：Meta透過`sched_ext`將廣告業務的「領域知識」直接編碼進核心排程策略，實現CPU資源的軟分割與動態調整，讓延遲敏感型工作優先執行，改善了L3快取命中率，減少了DRAM存取次數，這直接改變了底層算力的調度方式，也提升了算力的利用效率。
【以前卡哪？現在卡哪？】
以前卡在：通用型Linux核心排程器（如CFS、EEVDF）無法識別特定工作負載的優先級，甚至新的EEVDF還導致延遲退化，造成部分廣告伺服器卡在舊版核心（v6.4），產生技術債與營運碎片化。
現在換卡哪：限制轉換為如何更精確地從應用程式層定義、量化，並即時回饋不同工作負載的「重要性」給客製化排程器，以及維護這套複雜 BPF 策略的專業人才成本。新聞提到未來可由應用程式發出hint，這就是新的優化重點。
【真正關鍵】開放擴充的核心排程框架突破通用排程器的效能瓶頸。
原因：`sched_ext` 將排程策略開發從核心（kernel）剝離到用戶空間的BPF程式，允許Meta針對其高併發、延遲敏感的廣告工作負載，客製化資源調度邏輯，從底層優化CPU及記憶體資源分配。這樣做可以繞過Linux核心版本迭代的限制，快速部署並驗證專屬的排程策略。
【另外兩個重點】
1. **彈性部署與迭代速度革命**：排程策略更新從「數月」大幅縮短到「數天」，極大化實驗彈性並降低了新策略的導入成本和風險，解決了原本需等待核心版本釋出才能進行優化的痛點。
2. **生態系共享的基礎設施突破**：`sched_ext` 已被Linux核心v6.12採納並上游化，等於Meta的這項成果變成一個通用的基礎機制，讓其他超大規模業者、雲端服務商也能依樣畫葫蘆，免去fork核心的麻煩。
【重要程度】★★★★☆
【毒舌吐槽】
說真的，Meta這種等級的公司，搞到自家廣告服務的排程器還在用跟一般家用電腦差不多的通用型Linux排程，然後因為核心版本更新還搞出延遲退化，導致一堆伺服器卡在舊版核心，這技術債累積起來，要不是這次搞出個`sched_ext`，還不知道要拖多久。這成果說穿了，就是把「應用程式知道什麼最重要」這個最基本的領域知識，終於塞到核心排程器裡面去了。什麼「開源、BPF、客製化排程」，講白了就是「我終於可以自己寫規則，不用再看Linux核心的臉色」啦。這種優化，效益看起來驚人，但其實只是把過去沒做好的、不夠彈性的地方，用新工具給補起來而已。
【為什麼重要？】
- **系統影響**
這個改動對Meta的核心廣告服務來說，是直接且巨大的。以前通用排程器對廣告這種毫秒必爭的工作負載根本是「瞎子摸象」，一更新還會搞砸。現在有了客製化排程，至少能讓系統知道哪些請求是「衣食父母」、要優先處理。這不僅直接提升了廣告系統的反應速度與精準度，也解決了因為排程器問題，讓部分伺服器被綁死在舊版核心v6.4、無法升級的「技術債」和「營運碎片化」問題。以後 Meta 的廣告系統可以更順暢地升級核心，減少內部維運的負擔。
- **成本或能力變化**
從新聞數字來看，光是第一次切換到`sched_ext`，最大的廣告伺服器類型就實現了**p99延遲降低3.5%**、**CPU利用率提升3.5%**，以及最重要的**廣告排名數量增加8%**。後續兩次純用戶空間的策略更新，又分別額外降低了0.5%和0.25%的p99延遲、提升0.5%和0.25%的CPU利用率，並增加1%和0.5%的廣告排名數量。這些累積起來的效能提升，對Meta這種規模的廣告平台，直接轉化成更多的廣告營收與更低的基礎設施成本。更關鍵的是，排程策略的更新週期從「數月」縮短到「數天」，這大幅降低了新想法的實驗與部署成本，也加速了優化迭代的效率。
- **苦主與爽主**
苦主是以前的**通用型Linux排程器**（EEVDF直接背鍋，拖累效能）、**Meta內部處理核心版本碎片化的維運團隊**，以及可能因為廣告系統反應不夠快而**ROI沒那麼高的廣告客戶**。爽主則明顯是**Meta的廣告業務部門**（直接體現在營收增長上）、**Meta的基礎設施與核心工程師團隊**（終於能快速迭代排程策略），以及整個**Linux生態系**（因為`sched_ext`開源並上游化，大家都能用了）。
【實戰建議】大型雲端服務商或有高併發、低延遲需求的關鍵系統業者，應該開始研究 `sched_ext` 的可行性，評估其在自家特定工作負載上的客製化效益。
【一句話總結】Meta藉由客製化核心排程器，大幅提升廣告效能，同時解決技術債並開源造福業界，一舉數得。
【逆風觀點】
新聞只強調了`sched_ext`在開發與部署上的靈活性，但沒有提到導入與維護這種核心級BPF程式的技術門檻。不是所有團隊都有能力寫出高效且穩定的核心排程策略，更別說偵錯或優化，這可能會讓維運複雜度從「等待上游」變成「內部自行承擔」，人力成本反而可能提升。
Meta這次是針對旗下每天處理超過四千億次請求的廣告投放系統，導入一個叫 `sched_ext` 的開源核心排程器框架。簡單講，就是把原本Linux核心那個什麼都不懂的通用型排程器，換成一個可以讓Meta自己寫策略、教它廣告哪些工作比較急的智慧型排程器。這樣一搞，初期就讓廣告請求的99%延遲（p99 latency）降低了3.5%，CPU利用率也提升了3.5%，結果就是能排到名的廣告多了8%。最屌的是，這個框架把排程策略拉到用戶空間，以後更新策略只要幾天，不用像以前動輒好幾個月，還解決了核心版本碎片化的技術債。
【主戰場】算力與基礎設施
【真正主訊號】核心排程器可客製化，讓超大規模服務的算力利用更精準有效。
證據等級：高
原因：Meta透過`sched_ext`將廣告業務的「領域知識」直接編碼進核心排程策略，實現CPU資源的軟分割與動態調整，讓延遲敏感型工作優先執行，改善了L3快取命中率，減少了DRAM存取次數，這直接改變了底層算力的調度方式，也提升了算力的利用效率。
【以前卡哪？現在卡哪？】
以前卡在：通用型Linux核心排程器（如CFS、EEVDF）無法識別特定工作負載的優先級，甚至新的EEVDF還導致延遲退化，造成部分廣告伺服器卡在舊版核心（v6.4），產生技術債與營運碎片化。
現在換卡哪：限制轉換為如何更精確地從應用程式層定義、量化，並即時回饋不同工作負載的「重要性」給客製化排程器，以及維護這套複雜 BPF 策略的專業人才成本。新聞提到未來可由應用程式發出hint，這就是新的優化重點。
【真正關鍵】開放擴充的核心排程框架突破通用排程器的效能瓶頸。
原因：`sched_ext` 將排程策略開發從核心（kernel）剝離到用戶空間的BPF程式，允許Meta針對其高併發、延遲敏感的廣告工作負載，客製化資源調度邏輯，從底層優化CPU及記憶體資源分配。這樣做可以繞過Linux核心版本迭代的限制，快速部署並驗證專屬的排程策略。
【另外兩個重點】
1. **彈性部署與迭代速度革命**：排程策略更新從「數月」大幅縮短到「數天」，極大化實驗彈性並降低了新策略的導入成本和風險，解決了原本需等待核心版本釋出才能進行優化的痛點。
2. **生態系共享的基礎設施突破**：`sched_ext` 已被Linux核心v6.12採納並上游化，等於Meta的這項成果變成一個通用的基礎機制，讓其他超大規模業者、雲端服務商也能依樣畫葫蘆，免去fork核心的麻煩。
【重要程度】★★★★☆
【毒舌吐槽】
說真的，Meta這種等級的公司，搞到自家廣告服務的排程器還在用跟一般家用電腦差不多的通用型Linux排程，然後因為核心版本更新還搞出延遲退化，導致一堆伺服器卡在舊版核心，這技術債累積起來，要不是這次搞出個`sched_ext`，還不知道要拖多久。這成果說穿了，就是把「應用程式知道什麼最重要」這個最基本的領域知識，終於塞到核心排程器裡面去了。什麼「開源、BPF、客製化排程」，講白了就是「我終於可以自己寫規則，不用再看Linux核心的臉色」啦。這種優化，效益看起來驚人，但其實只是把過去沒做好的、不夠彈性的地方，用新工具給補起來而已。
【為什麼重要？】
- **系統影響**
這個改動對Meta的核心廣告服務來說，是直接且巨大的。以前通用排程器對廣告這種毫秒必爭的工作負載根本是「瞎子摸象」，一更新還會搞砸。現在有了客製化排程，至少能讓系統知道哪些請求是「衣食父母」、要優先處理。這不僅直接提升了廣告系統的反應速度與精準度，也解決了因為排程器問題，讓部分伺服器被綁死在舊版核心v6.4、無法升級的「技術債」和「營運碎片化」問題。以後 Meta 的廣告系統可以更順暢地升級核心，減少內部維運的負擔。
- **成本或能力變化**
從新聞數字來看，光是第一次切換到`sched_ext`，最大的廣告伺服器類型就實現了**p99延遲降低3.5%**、**CPU利用率提升3.5%**，以及最重要的**廣告排名數量增加8%**。後續兩次純用戶空間的策略更新，又分別額外降低了0.5%和0.25%的p99延遲、提升0.5%和0.25%的CPU利用率，並增加1%和0.5%的廣告排名數量。這些累積起來的效能提升，對Meta這種規模的廣告平台，直接轉化成更多的廣告營收與更低的基礎設施成本。更關鍵的是，排程策略的更新週期從「數月」縮短到「數天」，這大幅降低了新想法的實驗與部署成本，也加速了優化迭代的效率。
- **苦主與爽主**
苦主是以前的**通用型Linux排程器**（EEVDF直接背鍋，拖累效能）、**Meta內部處理核心版本碎片化的維運團隊**，以及可能因為廣告系統反應不夠快而**ROI沒那麼高的廣告客戶**。爽主則明顯是**Meta的廣告業務部門**（直接體現在營收增長上）、**Meta的基礎設施與核心工程師團隊**（終於能快速迭代排程策略），以及整個**Linux生態系**（因為`sched_ext`開源並上游化，大家都能用了）。
【實戰建議】大型雲端服務商或有高併發、低延遲需求的關鍵系統業者，應該開始研究 `sched_ext` 的可行性，評估其在自家特定工作負載上的客製化效益。
【一句話總結】Meta藉由客製化核心排程器，大幅提升廣告效能，同時解決技術債並開源造福業界，一舉數得。
【逆風觀點】
新聞只強調了`sched_ext`在開發與部署上的靈活性，但沒有提到導入與維護這種核心級BPF程式的技術門檻。不是所有團隊都有能力寫出高效且穩定的核心排程策略，更別說偵錯或優化，這可能會讓維運複雜度從「等待上游」變成「內部自行承擔」，人力成本反而可能提升。