SilverTorch：Meta 將推薦系統索引整合進單一 PyTorch 模型，吞吐量提升 23.7 倍
Meta Engineering Blog · 2026-05-26
Meta 在其工程部落格揭露 SilverTorch，一套將推薦系統所有檢索元件——ANN 索引、資格過濾、多任務排序、合成評分——統一整合進單一 PyTorch 模型的架構。與傳統分散式微服務相比，SilverTorch 實現 23.7 倍吞吐量提升與 20.9 倍運算成本效率，同時改善推薦準確度。
原本的問題
傳統推薦系統檢索管道由多個獨立服務組成：C++ ANN 搜尋服務、CPU 端資格過濾器、GPU 排序模型各自執行，透過 RPC 串接。每個服務邊界都帶來序列化、網路延遲與記憶體複製開銷。更根本的問題是，這些元件無法共用計算圖：ANN 搜尋完畢後才能傳給過濾器，過濾後才能進入排序，中間的等待時間無法被 GPU pipeline 掩蓋。
採用的方法
SilverTorch 的核心思想是「Index as Model」：物品索引不再是 ANN 資料庫，而是模型的一部分——一個存放 embedding 的大型 tensor。資格過濾器以 GPU 最佳化的 Bloom filter 實作，平行處理候選集。多任務排序層與合成評分層則是一般的神經網路層，與前述元件共享同一個 PyTorch 執行圖。
與簡單將舊 C++ 服務包裹在 PyTorch 外層不同，SilverTorch 重新設計了底層 primitive。ANN 搜尋採用 fused Int8 格式，將 embedding 記憶體用量降低約 50%；Bloom filter 以向量化操作取代標量迴圈，充分利用 GPU 平行度。所有元件在同一個 CUDA stream 中流水線執行，消除跨服務等待。
實際效果
在 Meta 的生產環境（規模未揭露，但涵蓋 Instagram、Facebook 主要推薦場景）：
- 吞吐量：23.7× vs 傳統方案
- 運算成本效率：20.9× vs CPU 方案
- 記憶體：Int8 ANN 使 embedding 儲存減半
- 推薦準確度同步提升（具體指標未公開）
此架構的可移植性依賴 PyTorch 生態，需要足夠大的 GPU 記憶體容納整個物品索引 tensor，在超大規模場景（數十億物品）下的分片策略論文中未詳述。
Cloudflare 帳單管道突然變慢：ClickHouse 查詢規劃器的隱藏鎖競爭
Cloudflare Blog · 2026-05-14
Cloudflare 的帳單管道在無任何程式碼變更的情況下，效能突然下降。工程師追查後發現根源不在查詢本身，而在 ClickHouse 查詢規劃器中一個全域鎖的競爭（lock contention），在高並發寫入下導致查詢等待時間以非線性方式增長。
原本的問題
帳單管道每秒對多個 ClickHouse 表執行大量並發查詢。問題在於 ClickHouse 的查詢規劃器（query planner）維護一個全域的 schema metadata 快取，在每次查詢規劃時都需要取得一把鎖來讀取或更新這個快取。當並發查詢數超過某個閾值，等待這把鎖的時間開始主導整體查詢延遲，而非實際的 I/O 或計算。
診斷過程依賴 ClickHouse 的 system.query_log 與 system.trace_log 表，工程師在 flame graph 中觀察到查詢時間大量集中在 schema lock 的 acquire 呼叫上，而非 I/O 等待或函數計算。
採用的方法與實際效果
解決方案分兩個層次：短期上，減少並發查詢數，透過批次合併降低競爭壓力；長期上，重新設計管道在 ClickHouse 層外部維護 schema metadata 快取，讓規劃器不再每次都觸及全域鎖。Cloudflare 亦向 ClickHouse 上游提交了問題報告，促使其在後續版本細化鎖的粒度。修復後帳單查詢延遲回復正常，且在相同並發下保持穩定。
原始來源：Cloudflare Blog