GitHub Copilot 從訂閱制轉向 AI Credits 用量計費，2026 年 6 月 1 日生效
GitHub Blog · 2026-04-27
GitHub 宣布 Copilot 將於 2026 年 6 月 1 日從固定訂閱制（Premium Request Units, PRUs）切換至以 GitHub AI Credits 為計量單位的用量計費模型。
新計費結構
用量以 Token 消耗計算，涵蓋輸入、輸出與快取 Token，依各模型的 API 定價比率換算為 AI Credits：
| 方案 | 月費 | 含月額 AI Credits |
|---|---|---|
| Copilot Pro（個人） | $10 | $10 |
| Copilot Pro+（個人） | $39 | $39 |
| Copilot Business（組織） | $19/人 | $19/人 |
| Copilot Enterprise（組織） | $39/人 | $39/人 |
促銷期間（至 2026 年 8 月），Business 與 Enterprise 方案分別獲得 $30 與 $70 的額外月額 Credits。已購年約的用戶保留 PRU 計費至約期屆滿。
哪些功能消耗 Credits
對話互動與自主程式碼生成（Copilot Workspace、程式碼審查）消耗 AI Credits；程式碼補全（Completions）與 Next Edit Suggestions 仍為無額外費用功能。Copilot 程式碼審查同時消耗 AI Credits 與 GitHub Actions 分鐘數。
企業預算控制
新增三層級預算控制：企業層級（全組織上限）、Cost Center 層級（部門或計費單位），以及個人用戶層級。組織間的 Credits 池化（pooled credits）消除了舊有 PRU 系統中「某些席位 PRU 用盡但其他席位有餘」的資源滯留問題。
對開發者的影響
使用大型推理模型（如以 Claude 或 GPT-4o 驅動的 Copilot Chat）的複雜對話現在將按 Token 計費，長上下文對話的費用與 API 直接呼叫模型趨於一致。這對大量使用 Copilot Chat 進行程式碼審計或架構討論的場景有顯著成本影響。
Microsoft 終止與 OpenAI 的獨家協議與收益分成，AI 基礎設施合作繼續
Bloomberg · 2026-04-27
Bloomberg 報導，Microsoft 與 OpenAI 已達成協議，終止自 2019 年起生效的排他性合作條款與收益分成機制，雙方的 Azure 基礎設施合作關係維持。
協議結構的歷史背景
自 2019 年 Microsoft 首次注資 10 億美元起，雙方協議的核心條款包含：OpenAI 的所有商業模型需部署於 Azure；Microsoft 以 Azure 算力換取 OpenAI 的商業授權（Microsoft 365 Copilot、Azure OpenAI Service），並根據 OpenAI 商業收入提取一定比例的分成。截至 2025 年 Microsoft 的累計投資已超過 130 億美元，獲得 OpenAI 的少數股權。
協議變更內容
根據 Bloomberg 報導，終止的條款包含：收益分成機制（Microsoft 不再從 OpenAI API 及 ChatGPT 訂閱收入中獲取比例提成）；以及排他性部署限制（OpenAI 將可在 Azure 以外部署其模型或向其他雲端服務商授權）。
維持的合作：Microsoft 繼續作為 OpenAI 的優先算力供應商；Azure OpenAI Service 繼續提供 OpenAI 模型的 API 存取；Microsoft 365 Copilot 的 OpenAI 模型整合維持。
產業意涵
此調整發生在 OpenAI 正式轉型為公益公司（Public Benefit Corporation）的過程中，脫離原有的「上限利潤」（capped profit）結構。收益分成的終止為 OpenAI 在未來 IPO 或進一步融資中清理了財務結構的複雜性，同時讓 Microsoft 得以在不支付授權成本的情況下繼續以算力换取模型存取。
原始來源：Bloomberg — Microsoft and OpenAI end exclusive and revenue-sharing deal
Meta Facebook Groups 搜尋現代化：混合擷取架構、稠密向量與 LLM 評估框架
Meta Engineering · 2026-04-21
Meta 揭示了 Facebook Groups 搜尋系統的架構現代化歷程，從純關鍵字倒排索引演進至結合稠密向量擷取的混合系統，並引入 LLM 作為離線評估裁判。
混合擷取架構
新系統以兩條路徑並行執行：
詞彙路徑（Unicorn 倒排索引）：Facebook 的大規模倒排索引，對專有名詞與精確匹配有高精準度，但無法處理語意相近但詞彙不同的查詢。
語意路徑（SSR，Semantic Search Retrieval）：以 12 層、2 億參數的雙塔編碼器模型將查詢與貼文分別編碼為稠密向量，使用 Faiss 進行近似最近鄰搜尋（ANN search）。貼文嵌入預先計算並建索引，查詢嵌入在線上即時計算。此路徑可找到語意相近但詞彙不重疊的結果（如「有糖霜的小蛋糕」對應「杯子蛋糕」貼文）。
多任務多標籤排序模型（MTML）
合併階段使用 Multi-Task Multi-Label 架構：稀疏詞彙特徵（TF-IDF、BM25 分數）與稠密語意特徵（餘弦相似度）共同作為輸入，模型聯合優化點擊、分享、留言三個參與訊號。多目標聯合訓練相比各別訓練可減少各目標間的特徵衝突。
LLM 離線評估
Meta 以 Llama 3 多模態版本作為評估裁判（judge model）進行自動化離線評估。評估框架識別細緻的相關性類別，包含「部分相關」（如不同運動項目出現在運動相關查詢中），以提高評估顆粒度。此框架取代了部分人工標注流程，加速了模型迭代週期。
Meta 脫離 WebRTC Fork：Shim 層設計解決符號衝突，從落後數年追上 M145
Meta Engineering · 2026-04-09
Meta 工程部落格記錄了其 WebRTC 現代化歷程——從維護一個落後上游數年的 internal fork，到在 50+ 個服務（Messenger 視訊通話、Instagram、Cloud Gaming、Meta Quest VR casting）中追上 Chromium M145 穩定版。
Fork 問題的技術根源
Meta 的 WebRTC fork 隨時間累積了大量內部特性（加密層、自訂 codec 配置、效能調整），使得合入上游 commit 的成本隨 delta 增長而趨於不可行——典型的 fork divergence 債務問題。
A/B 測試的符號衝突挑戰
同時運行舊版與新版 WebRTC 以進行 A/B 測試在靜態連結環境下違反了 C++ One Definition Rule：兩個版本的 webrtc::PeerConnection、webrtc::RtpTransceiver 等型別具有相同的符號名稱，產生數千個重複符號連結錯誤。
Shim 層與自動重新命名空間
解決方案是建立一個版本不可知的 proxy 函式庫（shim），暴露統一 API 並在運行時依配置分派至 legacy 或 latest WebRTC 實作。二進位體積僅增加 ~5 MB，相對於全量複製 WebRTC 的 38 MB 節省約 87%。
自動重新命名空間工具（automated renamespacing）將 webrtc:: 命名空間分別轉換為 webrtc_latest:: 與 webrtc_legacy::，同時處理全域 C 函式的 flavor 識別符和巨集重定義衝突（透過策略性的 include 移除與命名空間導入）。
Feature Branch 管理
Meta 在獨立 Git 倉庫中維護特性分支，每個 Chromium 上游版本（如 M143）建立對應分支（如 debug-tools/7499），升版時向前合并（merge forward），使上游貢獻提交更為便利。
結果
CPU 用量降低達 10%；崩潰率改善 3%；二進位體積縮減 100–200 KB（壓縮後）；移除了已廢棄的函式庫並修補了安全漏洞；WebRTC 版本從落後多年追平至 M145（當前穩定版）。