2026.07.15 —— 今日 4 則
TODAY'S THREAD 今天的主線是「把浪費榨乾」——Google 把 397B MoE 榨進 TPU 拿到 4.7 倍加速、branchless 二分搜尋靠消滅分支誤預測快 6.5 倍，連量測 X11 與 Wayland 的輸入延遲、拆解 job queue 的邊角，都在問同一件事：時間到底浪費在哪裡。
把 397B MoE 榨進 TPU7x：Google 拿到 4.7 倍加速
Google 分享了在 Ironwood（TPU v7x）上優化 Qwen 3.5-397B MoE 推論的完整 playbook，靠 JAX/Pallas 自訂 kernel 與混合平行策略，把 prefill-heavy 工作負載做到最高 4.7 倍加速、decode-heavy 3.1 倍。關鍵是放棄傳統 8-way tensor parallelism，改用注意力層資料平行加上 MoE 層 expert parallelism，解掉原本把並行度卡在約 200 requests 的記憶體冗餘。對要在自家加速器上服務大型 MoE 的團隊，這是一份把 roofline 分析拆到 kernel 級的實作範本。
分支預測殺手：branchless 二分搜尋快 6.5 倍
一般二分搜尋在資料均勻分布時 CPU 幾乎無法預測分支走向，作者實測有 16.6% 的分支誤預測。改用 select_unpredictable() 做 branchless 版本、把迴圈次數固定成 log₂ 並用 cmov 取代 if 之後，Rust 實作從 45,981 微秒降到 7,106 微秒，快了 6.5 倍。作者一句話總結：「分支誤預測完全消失了。」
X11 對決 Wayland：輸入延遲實測差多少
有人自製了一套 RP2040 加光感測器的硬體，直接量測「滑鼠點擊到螢幕變化」的端到端延遲來比較 X11 與 Wayland。結果兩者中位數只差 0.14 ms（4.79 對 4.93 ms），作者結論是原生 Wayland 與原生 X11 不相上下，真正該避開的是多付 3.13 ms 的 XWayland；VRR 則是降延遲最有感的開關。
Job queue 看似簡單，其實處處是坑
作者拆解了 job queue 那些「看起來簡單、實作起來全是邊角」的地方：當一個工作還沒跑完下一次排程就到了，系統其實得在平行啟動、優先新的、等待、優先舊的這四種語意之間做選擇，各有不同後果。他還點出沒有上限的佇列可以悄悄堆到十萬筆，以及排程間隔與工作時長不匹配時的連鎖取消。結論是這些語意用基本原語湊不出來，得一開始就想清楚。