Show HN: Headroom —— 測量本地AI的GPU真實頻寬上限

Headroom是一款創新的瀏覽器內基準測試工具，旨在幫助使用者瞭解其裝置在本地AI推理時的真實記憶體頻寬上限。整個測試僅需約30秒，無需下載任何模型——它使用合成權重，僅需獲取約0.4 MB的公共張量後設資料即可精確計算每個token的位元組數。測試要求WebGPU支援（Chrome/Edge桌面版或最新Android Chrome），無需賬號、無廣告、無遙測，資料僅在瀏覽器內處理，除非使用者主動分享。

Headroom的核心原理基於LLM解碼的記憶體頻寬瓶頸。對於批次大小為1的解碼，每個生成的token必須從GPU記憶體中流式載入一次權重，因此token/s的上限等於記憶體頻寬除以每個token涉及的位元組數。Headroom透過三種獨立方式測量頻寬：緩衝複製、三讀一寫以及純讀歸約（類似GEMV形狀），然後使用確定性合成權重執行從零開始的GEMV階梯測試，展示真實核心在裝置上能達到的頻寬百分比。合成權重之所以有效，是因為流式時間不依賴於值本身——僅正確性檢查依賴值，而雜湊派生的填充允許FP64 CPU參考驗證每個核心。

為了消除模型引數大小猜測的誤差，Headroom會遠端獲取模型safetensors檔案的頭部資訊（約0.4 MB，來自固定版本，非動態更新），並分類每個張量在文本解碼中的作用。例如，對於Gemma 4 E2B QAT模型（2.46 GB，2780個張量），只有0.81 GB的權重在每次token生成時流式傳輸（transformer層0.68 GB + lm_head 0.10 GB + 每層投影0.03 GB），而1.31 GB的嵌入表是每token查一行，0.34 GB的視覺/音訊塔在文本解碼中從不訪問。所有頻寬上限均在空上下文中給出——KV快取讀取會隨上下文長度增長而降低實際上限。

Headroom已針對真實引擎進行驗證。在一臺RTX 5070上，它測得577 GB/s的頻寬，達到672 GB/s GDDR7規格的86%，透過瀏覽器標籤頁實現。對應的E2B ceiling約為717 tok/s；而Xenova引擎在該機器上解碼約217 tok/s（佔ceiling的30%）。這意味著流式權重僅需每個token 4.6 ms中的1.4 ms，約70%的預算被髮射開銷和非GEMV工作消耗。在Apple M1上，Headroom測得51–56 GB/s（規格的74–82%），ceiling約為63–69 tok/s，同一引擎可達30–40 tok/s（約50%）。兩臺機器得出相同結論：當今的瀏覽器內引擎受發射開銷限制，而非頻寬——硬體仍有2-3倍潛力，這正是Headroom的測量價值。此外，測試還發現非合併訪問在Apple統一記憶體上保持約50%的ceiling，但在離散GDDR7上驟降至27%——對於Blackwell架構，合併訪問價值3.7倍。

Headroom還包含一個“Canary v2”測試，專門檢測一個特定子組bug：某些瀏覽器在使用subgroupAdd時可能出現確定性錯誤，導致LLM生成垃圾輸出。該測試在32位最小子組下執行，與一個使用subgroupShuffleXor的正確控制對比。已驗證在RTX 5070上的穩定Chrome 150中，Canary v2全部失敗，相對誤差高達1.7×10⁻¹，而控制全部透過。這個bug是靜態分析無法發現的靜默正確性錯誤。

Headroom團隊還回答了常見質疑，包括：GEMV無法達到100%的ceiling（但三種獨立測量互相驗證）；不使用timestamp-query而採用牆鍾計時是可靠的（透過大塊自動校準和時間中位數）；權重緩衝區大小足以避免快取（128 MiB vs 48 MB L2）；合成權重不影響效能測量；Canary v2測試的是真正的誤編譯而不是語義差異；等等。

總之，Headroom提供了一個精確、透明且可驗證的工具，幫助開發者和愛好者瞭解其GPU的真實頻寬上限，並揭示瀏覽器內AI推理的瓶頸所在。