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推理的瓶頸所在。