表征四个 GPU 供应商、三个后端和三个浏览器中 LLM 推理的 WebGPU 调度开销
Characterizing WebGPU Dispatch Overhead for LLM Inference Across Four GPU Vendors, Three Backends, and Three Browsers
摘要
WebGPU 以安全为中心的设计强制执行每个操作的验证，该验证在神经网络推理中的许多小型调度中进行复合，但这种开销的真实成本却很难描述。我们提出了批量大小为 1 时 LLM 推理的 WebGPU 调度开销的系统特征，涵盖四个 GPU 供应商（NVIDIA、AMD、Apple、Intel）、两个本机实现（Dawn、wgpu-native）和三个浏览器（Chrome、Safari、Firefox）以及两个模型大小（Qwen2.5-0.5B 和 1.5B）。我们的主要贡献是一种顺序调度方法，该方法揭示了简单的单操作基准将调度成本高估了 ${\sim}20\times$。仅 WebGPU API 开销的真实每次调度成本在 Vulkan 上为 24-36 $μ$s，在 Metal 上为 32-71 $μ$s，而包括 Python 成本在内的每次操作总开销为 ${\sim}95$~$μ$s，这对于优化至关重要。在 Vulkan 上，内核融合将吞吐量提高了 53%，而 CUDA 融合没有带来任何好处，这证实了每次操作的开销是主要的区别因素。 LLM 推理在三个主要操作系统（Linux、Windows、macOS）上进行了测试。我们构建了 $\texttt{torch-webgpu}$，一个基于 PrivateUse1 的树外 PyTorch 后端和一个 FX-to-WebGPU 编译器，它在我们的参考平台上实现了 11--12% 的 CUDA 性能。在数据类型匹配的 float32 下，RTX PRO 2000 实现了 1.4$\times$ WebGPU 吞吐量，尽管计算量比 RTX 5090 少 ${\sim}6\times$。对于调度开销，后端选择是主要因素，尽管实现选择在后端内也很重要（Metal 为 2.2$\times$）。就调度与内核计算效率而言，我们得出的结论是，在当前调度繁重的管道中，当批次 = 1 时，无论内核质量如何，每个操作的开销都占主导地位。所有代码、基准测试和原始数据都是开源的。