Discord 將語音基礎架構遷移至 Cloudflare 邊緣網路的完整歷程
Discord Engineering Blog · 2026-06-09 · 作者：David Chen（Audio/Video Infrastructure Engineering Manager）
Discord 於 2026 年 6 月 9 日發表長篇技術後記，說明其如何將語音與視訊流量從約 30 個超大規模雲端區域（hyperscaler regions）遷移至 Cloudflare 全球超過 300 個 PoP（Point of Presence）節點。截至撰文時，超過 80% 的語音及視訊流量已在新架構上運行。遷移期間歷時逾一年，期間暴露了多個深層的網路、作業系統與應用層問題。
背景
Discord 原有語音架構依賴自行管理的 SFU（Selective Forwarding Unit）叢集，分布於少數幾個雲端區域。覆蓋範圍有限導致冰島、奧克蘭、拉各斯、夏威夷等地的用戶被迫繞路至數千公里外的節點，延遲居高不下。此外，原本的服務發現機制以 etcd 支撐，隨著語音主機數量擴張至 25,000 台，etcd 叢集承受了極大壓力。
Cloudflare 邊緣網路提供了地理分佈更密集的選擇。然而，Cloudflare 的排程器獨立管理主機生命週期，傳統的「先佈署主機再推送服務」模式無法直接套用，Discord 必須改為主機主動向上游回報（inbound registration）的模式。新的服務發現機制改用 Valkey（GCP Memory Store），設定 10 分鐘 TTL，以此取代壓力過大的 etcd 基礎設施。
核心改動
容器管理策略從「重啟」改為「重建（recreate）」，滾動更新時新增五分鐘的優雅關閉視窗（graceful shutdown window），讓重連中的通話有時間轉移至替換實例。每台主機的 worker 數量經歷了多次調整：上線初期為 4 個，2025 年 5 月因 NIC 佇列競爭降至 2 個，至 2025 年 9 月底再擴展至 8 個。
服務部署的驗證流程也隨問題演進而重構。2025 年 4 月下旬在 Rotterdam 發生的 Orange ISP 問題（延遲峰值超過 1 秒，語音品質下滑 30%）揭露了轉接骨幹路徑飽和（Telia transit backbone 壅塞）的問題；解決方案需要 Cloudflare 針對 Orange 進行直接對等（direct peering）協商，並在巴黎與倫敦 PoP 增設 SFU。這一事件將上線驗證節奏從「容量驅動」徹底改為「對等分析驅動」。
影響範圍
2025 年 5 月的美國東部封包遺失事件（1.5–2% vs 基線 <0.5%）定位到NIC 佇列競爭（NIC queue contention）問題：容器執行環境當時尚未將多佇列 NIC 暴露給容器，四個 worker 共用單一傳輸佇列。Discord 暫時削減 worker 密度，Cloudflare 在 2025 年 6 月初修復 UDP 緩衝區問題後才恢復正常。
2025 年底在布加勒斯特與斯德哥爾摩部署後，出現客戶端延遲峰值超過 500ms 的問題，最終確認為兩個疊加原因：
- 應用層 futex 停頓：8 個使用 Tokio 非同步執行階段的 worker 執行緒在高流量時發生寫入飢餓（write starvation）。
recvfuture 持續就緒導致 Tokio 128 次輪詢上限在數微秒內耗盡，media_batch.latency_microseconds從約 1ms 飆升至數百毫秒。修復方案（2026 年 3 月部署）：設定 9 毫秒的強制 flush 計時器（budget forcing flush timer）。 - Softirq 競爭：每台 VM 僅有單一
virtio-net佇列，接收端 softirq 處理集中在單一 vCPU，搶占 worker 執行緒。解決方案：以taskset做 CPU 親和力綁定，將 worker 執行緒遠離 IRQ vCPU；並啟用 Receive Packet Steering（RPS）分散 softirq 負載。
修復部署後，下一個流量峰值小時未觀察到延遲尖峰，歐洲流量的 p95 延遲恢復正常。以法蘭克福為例，ping 降低 34%、封包遺失率下降 42%；歐洲多個區域封包遺失率改善幅度介於 20–60%；聖地牙哥的音訊擴展率（audio expand ratio，衡量音訊幀拉伸的品質指標）下降 40%。
目前仍有雷克雅維克（Reykjavik）與奧克蘭的覆蓋整合尚待完成，需等待更精確的通話放置邏輯（call placement logic）就緒；Cloudflare 的多佇列 virtio-net 遷移一旦完成，CPU 親和力繞路方案即可退場。
原始來源：Discord Engineering Blog — How We Moved Discord Voice to the Edge
Meta 如何在 AI 原生時代以混合式分類引擎自動化資料隱私管控
Meta Engineering Blog · 2026-06-25 · 作者：Rituraj Kirti、Vasileios Lakafosis
Meta 於 2026 年 6 月 25 日發表技術案例研究，揭示其隱私感知基礎架構（Privacy Aware Infrastructure，PAI）如何應對 AI 原生產品帶來的資料分類挑戰。核心問題在於：一個欄位名稱如 age 可能代表需要嚴格保護的個人資料，也可能只是快取 TTL，純粹仰賴人工分類已無法因應 AI 產品的迭代速度與資料多樣性。
原本的問題
Meta 的隱私政策要求對資料資產強制執行保留（retention）、存取（access）、目的（purpose）與分享（sharing）四類政策。然而 AI 原生產品引入了大量新資料模態（data modalities）、衍生特徵（derived features）以及更快的版本迭代節奏，人工分類流程的吞吐量遠低於新增資料資產的速度。既有系統在面對語意模糊的欄位名稱（如 age、location）時尤其吃力，因為正確分類往往需要結合程式碼血緣（code lineage）、所有權元資料與語意標注等多維度資訊。
另一個深層挑戰是可審計性（auditability）：若分類決策不可重現，監管合規與內部稽核都會陷入困境。純 LLM 方案雖能處理語意模糊性，但推論成本高（每次約為確定性規則的 400 倍）且決策過程難以回放。
採用的方法
Meta 採用確定性優先、LLM 兜底的雙路徑漏斗（decision funnel）架構。約 85% 的分類請求透過版本化確定性規則在單位數毫秒內完成；剩餘約 15% 的模糊案例則交由 LLM 推論（耗時數秒）。兩條路徑均輸出相同的結果 schema，並附帶版本化的決策追蹤（decision trace）以利審計。
在送入 LLM 之前，系統會為每個資產預先組裝一份「證據摘要（evidence brief）」，內容包含依可信度排序的支持信號（程式碼解析、血緣分析、所有權、語意標注）、附帶可靠度權重的矛盾信號，以及刻意遮罩（mask）的欄位——遮罩設計用以防止循環推論（circular reasoning）。被遮罩的欄位同樣被排除在後續的規則萃取之外，確保這些弱信號不會透過自動化規則重新滲入決策流程（masking invariant）。
LLM 評估採用三個獨立評審小組，各自使用不同的推論策略：直接證據分類、批判後再分類（critique-then-classify）、以及僅憑元資料分類（忽略欄位名稱與描述）。三者以多數決聚合，並以 Cohen's kappa 衡量評審者間一致性，比對基準為人工審查過的冷凍參考標籤集（frozen reference labels），絕不以模型輸出相互驗證，以防止自我強化的偏移（self-reinforcing drift）。
穩定的 LLM 決策模式會透過多階段驗證蒸餾（distillation）為確定性規則：先在類生產流量上以影子模式（shadow mode）測試，再以保留集驗證（holdout validation），凡涉及敏感資料保護的規則均需人工審查，最終以內容定址（content-addressed）方式部署以確保可重放性。
品質指標方面，系統除整體準確率外，還追蹤 Matthews 相關係數（MCC）、macro F1、各類別召回率（per-class recall）與平衡準確率（balanced accuracy），以識別整體準確率無法揭露的稀有敏感類別失效。此外系統執行反事實測試（counterfactual testing）：單一欄位遮罩時若預測結果翻轉，即標記為需人工審查的脆弱決策（fragile decision）。
實際效果
部署後規則覆蓋率提升，同時延遲下降、LLM 推論呼叫次數減少。上下文品質改善（程式碼解析、血緣分析）對準確率的貢獻遠超過提示工程（prompt optimization），驗證了「context beats prompts」的核心設計原則。確定性優先的分類架構產出了比端對端 LLM 方案更一致、更易除錯的決策，且由獨立的執行團隊進行交叉驗證後確認了此模式的穩健性。
人工判斷被集中保留在最高影響力的場景：模糊政策解釋、參考標籤審查、稀有敏感類別，以及影響保護執行的規則晉升（rule promotion）。此設計使稀缺的人工資源得以聚焦在確實需要人類判斷的決策上，而非被大量機械性分類任務所消耗。
原始來源：Meta Engineering Blog — Privacy-Aware Infrastructure in the AI-Native Era