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