状态：草案（2026-10-16），主要基于文档。 测量在手机与浏览器中运行我们模型的结果 不存在（未实际测量）. 标准和浏览器支持情况于 2026-10-16 通过查阅 W3C 和浏览器供应商的官方文章进行确认。JPEG 大小和模型参数数量取自本系列文章中服务器的实际测量数据。 系列文章「视觉模型阅读 3」第 7 篇。用于携带模型的格式（ONNX）在 第 3 篇中。
目录
1. 直觉：在哪里进行计算
摄像头在手机上。结果（记分牌）也显示在手机屏幕上。如果中间只有模型在服务器上，每帧都会产生 手机 → 服务器 → 手机 的往返。将模型迁移到手机上就可以消除往返。但是，手机的 GPU 较小，运行时间长了会发热，并且不同机型的性能差异可达十倍。
| 在设备内 | 在服务器上 | |
|---|---|---|
| 延迟 | 无网络往返 | 网络往返 + 中继 |
| 隐私 | 视频不会离开设备 | 帧发送到服务器（即使不保存） |
| 成本 | 由用户设备计算 | 服务器 GPU 成本，并发用户数受限 |
| 模型 | 必须小（下载·内存） | 可以很大 |
| 一致性 | 不同机型的速度和结果可能不同 | 所有人的结果都相同 |
| 修复 | 必须重新下载新模型 | 只需更改服务器即可对所有人生效 |
2. 在浏览器中计算的途径
WebGL → WebGPU
TensorFlow.js（Smilkov 等人，2019）通过浏览器的图形 API（WebGL）运行神经网络。这是一种迂回的方法，将张量放入纹理中，并为每个输出元素运行一次图形着色器。尽管如此，差异依然巨大。
| MobileNet v1, 224×224 单次（论文表 1） | 时间 |
|---|---|
| 纯 JavaScript（2014 年笔记本电脑） | 3,426ms |
| WebGL，同一台笔记本电脑的集成 GPU | 49ms（71 倍） |
| WebGL，桌面级 GPU | 5ms（685 倍） |
| Node.js, 같은 데스크톱급 GPU 의 CUDA | 3ms |
WebGPU 是一项新标准，它不借用图形 API，而是直接调用 GPU 计算。其着色器语言是 WGSL。截至 2026-10-16，W3C 中的 WebGPU 和 WGSL 均处于“候选推荐标准草案（Candidate Recommendation Draft）”阶段（分别对应 2026-09-15 和 2026-09-21 版本）。通过浏览器供应商的官方文章确认的发布情况如下。
| 浏览器 | 默认启用 WebGPU |
|---|---|
| Chrome 113 | ChromeOS·macOS·Windows |
| Chrome 121 | Android 12 及以上（搭载高通·ARM GPU 的设备） |
| Safari 26.0 | macOS·iOS·iPadOS·visionOS |
| Firefox 141 | 仅限 Windows（基于 2025-07 的文章。此后未确认其他操作系统） |
MDN 仍然将其标记为“有限可用（Limited availability）”，并且只能在 HTTPS 等安全上下文中使用。16 位浮点数（f16）从 Chrome 120 开始在具有着色器功能的设备上使用。这意味着第 2 篇中的 FP16 现在也可以在浏览器中使用了。
WebAssembly(WASM)：充分发挥 CPU 性能
由于将数据发送到 GPU 存在固定开销， 对于小模型，CPU 可能会胜出。 在浏览器中加速 CPU 的途径是 WebAssembly，如果开启 SIMD（单指令多数据）和线程，情况会有所不同。这是 TensorFlow.js 官方仓库中的 WASM 后端表格（Chrome 79，由于是 2020 年左右的设备，数据较旧）。
| MobileNet V2, 2019 年笔记本电脑 | 时间 |
|---|---|
| 纯 JavaScript | 893.5ms |
| WASM | 98.4ms |
| WASM + SIMD | 30.2ms |
| WASM + SIMD + 线程 | 10.3ms |
| WebGL | 19.6ms |
同一篇文档指出，对于拥有 2000 万到 6000 万次乘加运算的轻量级模型，WASM 的性能与 WebGL 相似，而如果是 1 亿到 5 亿次，WASM 则会慢好几倍。我们在第 3 篇中看到的“调用开销与计算”的权衡在浏览器中同样适用。
WebNN：设备的神经网络加速器
如今的手机和笔记本电脑都配备了神经网络专用加速器（NPU）。无法通过 WebGPU 使用它们。 WebNN 是一项 W3C 标准，当以“卷积”、“矩阵乘法”等神经网络运算单元传递计算图时，可使浏览器在 CPU、GPU 或 NPU 中合适的地方进行运行。2026-10-10 版本为候选推荐标准草案，在当前版本中，开发者不直接选择设备，而是仅提供诸如“低功耗”、“高性能”之类的偏好。通过第一手资料未能确认各浏览器的默认发布情况。
ONNX Runtime Web：单一文件，多种后端
这是在浏览器中运行第 3 篇的 ONNX 文件的运行时。执行提供程序有 wasm（CPU）和webgpu·webgl·webnn ，由于 只有 WASM 支持所有算子，其他提供程序不支持的算子会回退到 WASM。WebGL 提供程序仅进行维护，性能方面建议使用 WebGPU（官方文档）。该文档中的浏览器支持表看起来比上述供应商的文章要旧——“运行时在该浏览器中进行了测试”与“浏览器发布了 WebGPU”是两回事。
3. 在应用中：Core ML
苹果设备的 Core ML 协同使用 CPU、GPU 和 Neural Engine。 computeUnits 如果将设为“全部”，操作系统会选择设备，而开发者可以将范围缩小到仅 CPU、CPU+GPU 或 CPU+Neural Engine。模型压缩工具（coremltools）提供权重调色板化（1、2、3、4、6、8 位查找表）、权重 INT4、INT8 与激活值 INT8 线性量化以及剪枝。文档指出，压缩确实显著缩小了体积，但 不保证延迟收益（某些后端会重新解压权重进行计算），并建议在自己的模型和设备上重新进行测量。这与第 2 篇和第 4 篇的结论相同。
4. 已经在手机上运行的模型
- BlazePose（Bazarevsky 等人，2020）: 使用 Lite 模型在 2017 年的手机 CPU 单核心上以约 30 FPS 的速度处理 33 个身体关节。检测器仅在第一帧和丢失时运行，其余时间则通过前一帧关节裁剪出的区域进行追踪（第 5 篇）。
- EfficientTAM（Xiong 等人，2024）: 在 2023 年的高端手机上，1024×1024 输入每帧耗时 261–1,011ms，512×512 输入耗时 80.6ms（论文表 1·5，未记载精度）。
- MobileNetV2(2018): 在手机 CPU 的大核上耗时 75ms（第 4 篇）。
共同点是 小模型 + 降低运行频率 。在手机上实现实时性，与其说是加速某个模型的问题，不如说是设计流水线的问题。
5. 如果将我们的模型迁移到手机：大小与带宽
| 模型 | 参数量 | FP32 | FP16 | INT8 |
|---|---|---|---|---|
| 球模型（BlurBall） | 149万 | 6.0MB | 3.0MB | 1.5MB |
| 查找球台（EfficientTAM-S） | 3,406万 | 136MB | 68MB | 34MB |
（参数量 × 4·2·1 字节。实际文件中会附加更多结构信息。）
球模型即使与网页一起下载也是一个可以接受的大小。问题在于计算。由于该模型始终保持 512×288 的分辨率，即使在服务器端的笔记本级 GPU 上，单个 FP16 窗口也大约需要 10ms（第 1 篇）。未测量是否能在手机 GPU 上达到 30fps（未实际测量）。由于查找球台只需在比赛开始时进行一次，因此在手机上耗时数百毫秒也没有问题，但需要下载 34–136MB 的数据。
相反，如果像现在这样在服务器上运行，则必须将帧上传。在本系列服务器的实际测量中，同一场比赛画面的 JPEG 大小如下。
| 发送的画面 | 质量 50 | 质量 70 | 质量 90 | 以 30fps 发送（质量 70） |
|---|---|---|---|---|
| 512×288 | 9.1KB | 12.3KB | 24.7KB | 约 2.9Mbit/s |
| 1280×720 | 37.7KB | 52.4KB | 111.5KB | 约 12.6Mbit/s |
（基于服务器 CPU 的 OpenCV 编码器。浏览器的 JPEG 编码器在相同的质量数值下大小可能会有所不同——运营设计文档中测得比赛视频为 12–18KB。）仅通过将分辨率缩减并发送至 512×288，带宽就变成了原来的四分之一。在上传较慢的乒乓球馆 Wi-Fi 环境下，这种差异决定了“能否运行”。
6. 局限性
- 不存在在手机与浏览器中运行我们模型的测量数据。本文对手机端的判断依赖于文档和其他模型的公开数据。
- 浏览器支持情况变化迅速。上表基于 2026-10-16 打开的供应商文章，未能确认 Firefox 在其他操作系统上的发布情况以及 WebNN 的默认发布情况。
- 公开的基准测试数据（TensorFlow.js 表格）是多年前的设备和浏览器的值。仅应参考其方向（根据后端不同相差数十倍），而不应直接采用其绝对值。
7. 与我们项目的联系
- 当前的分配方式: 手机（浏览器）捕获摄像头，将其缩小便居中裁剪至 512×288，以高达 30fps 的速度发送 JPEG（质量 0.7），并绘制返回的球的位置和判定结果。服务器负责解压 JPEG、球模型、边界与裁判规则以及查找球台。这是为了在一个地方修改模型和规则，并向所有人提供相同的判定结果。
- 首先从手机上迁移的候选是寻找乒乓球桌。它在比赛开始时只进行一次，对延迟的要求不高，如果成功的话，“寻找乒乓球桌期间的服务器往返”就会消失。由于球模型是每一帧都要运行，因此需要先对手机 GPU 进行实测。
- 要进行迁移，需要经过第 3 篇的 ONNX 导出和第 2 篇的精度验证（在 FP16 下球的位置是否相同）。这一实测就留作下一个任务。
接下来的文章是将本系列的所有碎片整合到 TT Score 实时路径上的实际预算表。
小贴士。 我的球模型只有 6MB，所以能轻松放入手机中。不过，它在手机里是否能一秒钟思考 30 次，目前还没有人实际测过。在测量之前，我可不会说“行”！
参考文献
- Smilkov, D. et al. (2019). TensorFlow.js: Machine Learning for the Web and Beyond. SysML 2019. https://arxiv.org/abs/1901.05350
- TensorFlow.js WASM 后端 README. https://github.com/tensorflow/tfjs/blob/master/tfjs-backend-wasm/README.md
- W3C WebGPU. https://www.w3.org/TR/webgpu/ · WGSL. https://www.w3.org/TR/WGSL/ · WebNN. https://www.w3.org/TR/webnn/
- Chrome 开发者博客 — WebGPU 发布 (113)、Android (121)、f16 (120). https://developer.chrome.com/blog/webgpu-release
- WebKit 博客 — Safari 26.0. https://webkit.org/blog/17333/webkit-features-in-safari-26-0/
- Mozilla Gfx 博客 — Firefox 141 WebGPU. https://mozillagfx.wordpress.com/2025/07/15/shipping-webgpu-on-windows-in-firefox-141/
- MDN WebGPU API. https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API
- ONNX Runtime Web. https://onnxruntime.ai/docs/tutorials/web/
- Apple Core ML (MLComputeUnits), coremltools 压缩指南. https://developer.apple.com/documentation/coreml · https://apple.github.io/coremltools/docs-guides/source/opt-overview.html
- Bazarevsky, V. et al. (2020). BlazePose. CVPR Workshop. https://arxiv.org/abs/2006.10204
- Xiong, Y. et al. (2024). Efficient Track Anything. arXiv. https://arxiv.org/abs/2411.18933