为什么你的浏览器基准测试在欺骗你关于 AI 性能的结果
Source: Dev.to
从 “Document Web” 到 “Compute Web” 的转变
多年来，我们一直通过延迟的视角来衡量网页性能：
- 这个脚本加载得有多快？
- 引擎执行这段单循环的速度有多快？
然而，Document Web 已不再活跃。我们现在正处于 Compute Web 时代——浏览器需要能够：
- 本地运行 AI 推理
- 处理海量数据流
- 同时处理复杂的 UI 状态
传统的基准测试就像通过检查单个活塞的速度来测试一台 16 缸发动机。它们并不能告诉你发动机在实际负载下的表现。
为什么现有基准测试不足
大多数基准测试（例如 JetStream、Speedometer）侧重于 顺序执行。虽然它们非常适合衡量 JavaScript 引擎的成熟度和整体浏览器性能，但却未能考虑 任务饱和度。
在现代 AI 驱动的网页应用中，峰值性能完全取决于浏览器如何高效地编排 并发、资源密集型任务，例如：
| 类别 | 示例 |
|---|---|
| CPU 密集型工作 | 在 Web Worker 中预处理大型数据集或 50 MB JSON 负载 |
| GPU 密集型工作 | 使用 WebGPU 运行本地 AI 推理模型 |
| 主线程工作 | 将 UI 响应保持在 60 fps |
真正的瓶颈往往是 这些组件之间的交接与调度，而不是任何单一组件的原始速度。仅关注孤立变量（例如原始 GPU 速度）无法捕捉在真实世界条件下应用的 终极性能。
介绍 SpeedPower.run
在 ScaleDynamics，我们观察到 CPU 与 GPU 之间的交接是 AI 驱动的网页应用的主要瓶颈。对合成的、脱节的基准测试感到沮丧，我们构建了 SpeedPower.run——现代网页上真实计算性能的权威基准。
同时负载方法论
SpeedPower.run 通过 同时将所有 CPU 和 GPU 推至极限 来确定浏览器和设备的最大性能。
- 并发任务：在进行大量 JavaScript 处理的同时运行 AI 推理。
- 使用的技术：JavaScript、WASM、WebGL、WebGPU。
确保公平得分（方法论与完整性）
- 零网络干扰——计时器仅在所有大型资源（≈ 400 MB 的 AI 模型）加载到内存后才开始。
- 热身执行阶段——在记录最终得分前，让浏览器完成内部优化（如代码编译）。
- 得分稳定性——对峰值指标进行统计回归分析，平滑系统级调度噪声，产生可靠的结果，而非单一时刻的快照。
- 用户指引——多次运行测试以获取可能的最高分，因为操作系统层面的因素会影响性能。
核心基准
1. JavaScript
衡量对 JS 对象和 JSON 进行前后处理的原始计算能力。
- 使用 Apple/WebKit JetStream 2 套件中的四个测试：
- Access Binary Trees
- Control Flow Recursive
- Regexp DNA
- String Tag Cloud
- 在多个 Web Worker 中并行运行这些基准测试，以评估最大多核 CPU 处理能力。
2. AI with TensorFlow.js
AI 识别 (TFJS)
- Model: BlazeFace
- Input: 128 × 128 张量，预热图
- Measures: 前向传播速度 + 后处理（解码最高置信度的人脸检测），在不同后端（JS、WASM、WebGL、WebGPU）上的表现。
AI 分类 (TFJS)
- Model: MobileNetV3‑Small
- Input: 224 × 224 张量，预热图
- Measures: 同上，侧重于分类吞吐量。
3. AI with Transformers.js (v3)
AI 分类 (Transformers)
- Model: MobileNetV4‑Small
- Backend: 优先使用高性能 WebGPU（回退至 WebGL）
- Input: 固定 224 × 224 张量
- Measures: 使用异步指令队列和计算着色器的并行推理能力。
AI LLM (Transformers)
- Model: SmolLM2‑135M‑Instruct（因果语言模型）
- Format: 4‑bit 量化（q4）ONNX
- Measures: GPU 运行时效率（不计模型加载开销）；多线程 LLM 执行和实时自回归解码。
AI 语音 (Transformers)
- Model: Moonshine‑Tiny（自动语音识别）
- Precision: 混合（FP32）
- Measures: 在并发负载下的语音转文字推理吞吐量。
摘要
SpeedPower.run 的构建旨在反映现代 Web 应用的 real‑world compute demands。通过同时对 CPU, GPU, and main‑thread work concurrently 进行压力测试，它提供了对浏览器处理 Compute Web 能力的整体视角——在这个时代，性能的定义不再是单一的延迟数字，而是系统一次性协调众多重任务的能力。
Encoder + Q4 Decoder
隔离 GPU 运行时效率与音频处理开销。
该分数突显了处理复杂、高并发语音转文本流水线的能力。
Exchange
由于现代应用依赖 Web Workers，“Exchange” 基准测试衡量主线程与工作线程之间的通信瓶颈。它测试以下内容的传输速度：
- IPC
- Transferables（可转移对象）
- 数组
- 缓冲区
- 对象
- OffScreen Canvas（离屏画布）
得分越高 = 主线程 ↔ 背景工作线程的通信越高效。
架构：无需安装
我们坚持认为这应该 零安装或零配置。通过利用 WebAssembly (WASM) 和 WebGPU，我们可以直接在浏览器中访问设备的底层硬件。
- 无需下载 5 GB 的套件来检查你的机器是否已准备好迎接 AI 网络。
- 点击一次，在约 30 秒内我们会占满所有可用线程，以找出你的浏览器在现代复杂应用中的极限点。
我们目前正在收集 成千上万的硬件/浏览器组合 数据，以完善对现代网络 “终极性能” 的评分。
我们已经看到一些有趣的异常，例如高端移动 ARM 芯片在任务切换效率上优于某些中端 x86 台式机，这归功于浏览器的热感知调度。
结果是否与你的 “真实” 多任务体验相符？在评论中留下你的分数和硬件规格。让我们一起讨论计算密集型网页应用的未来。