2026.10.26 —— 今日 10 則
TODAY'S THREAD 今天的共同問題是「數字在哪個條件下才成立」：Apple 上的推論加速、Cerebras 的晶圓配置與 uGDS 的頻寬倍數，都得連同硬體與負載一起讀；未定義行為與 wordexp 則提醒，工具表面上的保證，往往比你以為的少。Wide Events、GeoKey Manager 與 uv check，講的是同一件事換個層次：把該記的上下文留在系統裡。
Apple Silicon 上，伺服器端的 LLM 推論最佳化不一定有效
一篇論文在四台 Apple 機器上，以單一請求解碼的負載測試 KV cache 剪枝、推測解碼、移植的 GPU kernel 與訓練後量化。KV cache 剪枝最高讓端到端吞吐量達 1.75 倍，但在桌機 NVIDIA GPU 上可能反而降低；所有受測的推測解碼方法在 Apple 上都讓吞吐量下降，儘管伺服器 GPU 上的回報是 2 到 6 倍。作者的結論是，加速倍數取決於技巧、執行環境、硬體與負載的組合，不是技巧本身的屬性。
Cerebras 如何把 3 兆參數的 Kimi K3 排進 59 片晶圓
Cerebras 的文章說明如何把約 3 兆參數、共 93 層的 Kimi K3 放上 WSE-3T：dense 層每片晶圓放一層，把剩下的 SRAM 留給 KV cache；線性注意力層每片放兩層，合計 35 加 24 共 59 片。晶圓之間傳的是 activation 而非權重，文章稱每跳約 2 微秒。每秒 1000 到 2000 以上個 token 的速度是廠商自己的說法，且文章註明比較依賴第三方或內部測試。
MiniMax-M3.1-Flash：全程稀疏注意力與隨附的 DSpark 草稿頭
MiniMax-M3.1-Flash 的模型卡稱它是原生多模態的 MoE 模型，約 428B 總參數、每個 token 啟用 23B，上下文最長 1,000,000 個 token；卡片同時列出的 Safetensors 中繼資料是 220B，與 428B 對不上。注意力全程採用 MiniMax Sparse Attention，並隨附 DSpark 草稿頭供推測解碼。卡片的評測表顯示它在 Automation-Bench 與 LOCA-Bench 居首，多數其他列落後，這些都是廠商自己的數字。
uGDS：把 GPU Direct Storage 的控制路徑搬到使用者空間
uGDS 是開源的使用者空間 GPU Direct Storage 函式庫：主機 CPU 在使用者空間管理完整的 NVMe 命令生命週期，資料仍以 P2P DMA 直達 GPU，只有一個極小的核心模組負責一次性的特權設定。作者在 A100 加 Samsung 990 PRO 上報告批次讀取頻寬最高為 GDS 的 12.12 倍、批次寫入最高 30.69 倍；整合 LMCache 後，time-to-first-token 中位數最多降低 62.7%。
未定義行為不只會 segfault：沒人呼叫的 explode() 照樣執行
Thomas Habets 用一段帶 volatile 變數的小程式示範：在 GCC 16.2 的 -O1 下，以 std::unreachable() 結尾的函式會讓從未被呼叫的 explode() 照樣被執行。把它換成空指標寫入，GCC 反而輸出寫入 0 再執行 ud2，Clang 則同樣執行 explode()。作者的重點是編譯器沒有義務偵測未定義行為，結果可以是任何一種。
wordexp(3) 在不可信輸入上並不安全，連 WRDE_NOCMD 也不夠
wordexp(3) 常被拿來做波浪號展開，但旗標傳 0 時命令替換預設開啟，$(whoami)/foo 之類的輸入會被執行。作者指出 WRDE_NOCMD 在部分 libc 實作上很脆弱：musl 先做一次命令替換檢查再交給 shell，部分 Bash 仍視為有效的寫法能繞過；macOS 的 libc 做法類似，2023 年曾有人回報同類繞過。建議是別對不可信輸入呼叫 wordexp(3)，即使加上 WRDE_NOCMD 也一樣。
Wide Events：為何 trace、metric、log 只是同一種資料的特例
Ivan Burmistrov 以他在 Meta 使用 Scuba 的經驗主張，trace、metric 與 log 都是 Wide Event 的特例：一筆事件就是一組彈性的具名欄位，每筆帶 samplingRate，查詢用 SUM(samplingRate) 取代 COUNT(*)。因為 Scuba 存原始事件、不預先聚合，欄位基數不成問題。這是作者的立場，文章寫於 2024 年 2 月，不是今天的新聞，但仍值得拿來對照三支柱的說法。
Cloudflare 讓地理圍欄的金鑰管理抵抗量子攻擊
Cloudflare One 路徑上的 GeoKey Manager 現在用 HPKE，搭配 ML-KEM-768 加 X25519 的混合 KEM，防範先存後解的攻擊。包裝過的金鑰經 Quicksilver 全球散佈，但只有授權區域的邊緣伺服器拿得到區域根金鑰；任一檢查失敗就拒絕請求。目前是封閉 beta，預計 2027 年第一季全面開放。
UTS #39：Unicode 如何定義混淆字元與限制層級
Unicode 安全機制規範 UTS #39 目前為 18.0.0 版（2026 年 8 月 27 日，Revision 34）。它以 skeleton 判定兩個字串是否為混淆字元，並定義從 ASCII-Only 到 Minimally Restrictive 的五個限制層級，再加上僅供偵測用的 Unrestricted。需要擋同形異字網址、帳號名稱的人，實作前值得讀一遍。
uv 與 ty 整合：uv check 一次備好環境並做型別檢查
Astral 宣布 uv 與 ty 的實驗性整合預覽：uv check 會準備環境、安裝相依套件並執行 ty，並使用 lockfile 中記錄的 ty 版本，讓開發者與 CI 共用同一版本。PEP 723 單檔腳本也會依各自宣告的相依套件與 Python 版本檢查。需要 uv 0.12.3 以上與 ty 0.0.76 以上，自動建環境為選用，因為安裝相依套件可能執行第三方程式碼。