Compiler Explorer 怎麼用每月 3,600 美元撐住 520 萬次線上編譯
xania.org · 2026-08-05
原本的問題
線上編譯服務 Compiler Explorer 的維護者在個人網站 xania.org 公開了 2026 年整套 AWS 部署細節。這個工具目前掛著 6,157 個編譯器版本、涵蓋 93 種語言，每一個都得隨時可被叫用，過去的做法是把每個編譯器完整的二進位檔案攤開放在共用磁碟上。結果是 EFS 儲存量一路膨脹到 3.9TB，每次啟動或擴充節點都得先同步這一大坨檔案。文章寫於 2026-08-05，補上了不少過去沒公開過的實際數字。
採用的方法
解法是把每個編譯器包成一份唯讀的 SquashFS 映像檔，一樣放在 EFS 上，但透過 loopback device 掛載，交給 autofs 在真的被呼叫時才隨選掛上。靠內容定址把重複的執行檔打包後，2,182 個獨立映像檔直接砍到 121 個。前端是 CloudFront 加 WAF 擋在 Application Load Balancer 前面，再依路徑把流量分給 production、beta、staging、Windows/MSVC、ARM/Graviton、GPU 等不同叢集。部署走 blue-green：Auto Scaling Group 先拉起新機隊、健康檢查過關才切流量，舊機隊再慢慢排空。
| 項目 | 改版前 | 改版後 |
|---|---|---|
| 編譯器映像檔數量 | 2,182 | 121 |
| EFS 使用量 | 3.9TB | 2.2TB |
| 每晚建置的 nightly 編譯器數 | 73 | 94 |
實際效果
2026 年 7 月單月跑了 520 萬次編譯，全年估計 7,870 萬次，換算下來每次編譯只花約 0.0007 美元，整體 AWS 帳單壓在每月約 3,600 美元。負載平衡器每月承接 1,400 萬次請求，尖峰出現在 4 月 21 日單日 144 萬次。負責下一代路由、走 SQS 排隊的 CE Router 還在測試階段，尚未真正接手 production 流量，新增編譯器上線也還得靠人工跑一次 discovery 流程。整套系統目前只跑在 us-east-1 一個區域，海外使用者得自行吞下跨洋延遲。
原始來源：xania.org
Nvidia Vera 白皮書被抓包：SMT 畫錯、頻寬也對不起來
Chips and Cheese · 2026-08-05
背景
Nvidia 今年 5 月底在 GTC Taipei 發表資料中心 CPU Vera，是 Vera Rubin 平台的一部分，主打「agent 專用 CPU」，預計 2026 年秋季隨系統夥伴出貨。Nvidia 官方部落格於 7 月 21 日放出技術細節，聲稱 88 核心的 Vera 用自研 Olympus 核心搭配名為 NVIDIA Spatial Multithreading 的雙執行緒技術（88 核心對 176 條 SMT 執行緒），並主打「software-first」單一 NUMA domain 設計。硬體分析媒體 Chips and Cheese 在 2026-08-05 逐條拆解這份白皮書，指出裡面至少六處論述前後矛盾或帶有誤導性，標題裡的「thread loose」正是在調侃其中的 SMT 論述。
規格細節
白皮書公布的其餘數字包括：Olympus 核心採 10-wide 解碼、Arm v9.2 指令集，每核心配 2MB 私有 L2 與 96KB L1 資料快取，六條 128-bit SVE 管線、四個 load 單元與兩個 store 單元；晶片共享 164MB 末級快取，SOCAMM2 LPDDR5X 記憶體最高提供 1.2TB/s 匯總頻寬，晶粒內部 fabric 頻寬達 3.4TB/s。Chips and Cheese 挑出的問題包括：把 x86 的 SMT 畫成資源閒置的「分時」示意圖，卻沒有同樣檢視自家 Spatial Multithreading 的實際排程行為；拿「32 個 NUMA domain」當 x86 系統的宿命，卻沒提 AMD 的 NPS4/NPS2/NPS1/NPS0 本來就可設定成單一 domain；把 SPEC CPU 2026 裡的 Python 直譯器、兩個最佳化編譯器和一個 C/C++ 靜態分析器包裝成「agentic benchmark」；跨指令集的 IPC 比較沒附 PMU 事件定義、取樣區間與時脈，「無法被覆核」。
| 項目 | Nvidia 白皮書宣稱 | Chips and Cheese 實測 |
|---|---|---|
AMD EPYC 9755 記憶體頻寬 | 約 400GB/s | 約 570GB/s |
| Vera 相對頻寬優勢 | 約 3 倍 | 約 1.9 倍 |
影響範圍
文章也點名白皮書裡 Figure 24 的 RL 訓練圖表只有示意方塊，沒有模型、環境、批次大小或耗電數字，作者直言那「根本不是一份 benchmark」。這篇拆解不影響 Vera 晶片本身的設計，但直接衝擊白皮書裡對外宣傳用的倍數說法——官方另外聲稱的「1.8 倍 agentic 效能」與這裡被質疑的「3 倍記憶體頻寬」是兩組不同數字，都建立在同一份文件的可信度上。Vera 要到今年秋天才出貨，這些效能數字正是潛在買家評估它與 AMD Epyc 之間取捨的重要依據。
rust-lang/rust 訂出 LLM 使用政策：能拿來審查，不能拿來生成
Inside Rust (blog.rust-lang.org) · 2026-08-05
背景
Rust 語言團隊成員 Jynn Nelson 在 Inside Rust 部落格公布 rust-lang/rust 主倉庫的正式 LLM 使用政策，適用對象是 PR 審查者、作者、issue 回報者與公開留言者。她列出三個促成政策成形的問題：做得漂亮的產出不再代表作者真的花了功夫，LLM 讓原本就吃緊的審查人力更緊繃（文中提到當時倉庫裡開著 1,281 個 PR），機械式複製貼上的內容既浪費審查者時間也侵蝕彼此信任。政策把過去各 reviewer 各憑感覺處理的非正式做法，整理成一份公開規則。
核心改動
政策的一句話定調：「可以用 LLM 來回答、分析、篩選、檢查、建議、審查，但不能拿來創造。」具體規則包括：
- 用 LLM 協助發現或撰寫 bug 回報，必須揭露 LLM 的參與程度
- 公開空間（文件、PR 描述、issue 留言）裡的機器生成內容，除非另有豁免，否則要清楚標示
- LLM 生成的程式碼必須事先協調、屬於非關鍵路徑、品質夠高、附完整測試並公開揭露；牽涉 soundness 的關鍵改動，除非作者本身就是該領域專家，否則不接受
- 私下使用 LLM 不需要揭露，只要沒有把輸出公開分享出去即可
- 審查者可以不附理由直接關閉不符規範的 PR，但騷擾使用 LLM 的貢獻者一樣違反行為準則
影響範圍
LWN.net 的 Jonathan Corbet 同日整理了社群討論：讀者 josh 指出政策的分界線在於「協助分析」與「直接生成」的差別；另一位讀者 bojan 則質疑這條線其實模糊——LLM 給的建議一旦被直接採納變成 patch，算不算「生成」。這份政策沒有禁止使用 LLM 工具本身，鎖定的是揭露義務與審查負擔，可能成為其他大型開源專案訂定類似規則時的參考範本。
原始來源：Inside Rust、LWN.net