在过去半年里，前端圈关于“把大模型搬进浏览器”的讨论铺天盖地。从 WebLLM、Transformers.js 到各大自研推理框架，几乎都在宣扬端侧 AI 的免服务器成本、绝对数据隐私和零网络延迟。然而，作为需要对线上性能与转化率负责的技术手艺人，我们最反感脱离真实硬件数据的纸上谈兵。
浏览器端跑模型到底能不能用于生产？在用户的真实设备上究竟能跑到几 Token 每秒？移动端 GPU 跑大模型会不会导致手机发烫降频、电池断崖式下跌，甚至直接触发 Chrome 的 OOM 闪退？
为了彻底摸清端侧 WebGPU 的算力底线与工业化可用边界，我们在国庆前夕组织了一次覆盖主流桌面端、轻薄本以及移动端旗舰设备的基准压测（Benchmark）。测试统一基于最新的 WebLLM 运行内核与自定义 WGSL 算子管线，对 1.5B 到 7B 参数规模的主流开源端侧模型展开实测。本文将完整的压测数据、瓶颈归因与选型建议全盘公开。
评测基准与测试矩阵设计
本次基准测试主要考核三个反映真实交互体验的核心指标：
- GEMM 浮点吞吐（TFLOPS）：基于标准 $4096 \times 4096$ 矩阵乘法计算着色器（WGSL Compute Shader），衡量设备在浏览器环境下的纯算力释放效率。
- TTFT（Time To First Token，首 Token 延迟）：以 512 Tokens 为 Prompt 上下文输入，评估模型 Prefill 阶段的算力承载力。
- Decode Throughput（解码吞吐）：持续自回归生成 256 Tokens 的平均速度（Tokens/s），决定了打字机输出是否丝滑。
测试设备与硬件梯队
我们挑选了 5 档极具代表性的硬件设备：
- 梯队 A（桌面高性能）：PC 平台，AMD Ryzen 7 7800X3D + NVIDIA RTX 4070 (12GB 显存)，Windows 11，Chrome 129。
- 梯队 B（统一内存架构标杆）：Apple MacBook Pro 14 (M3 Pro, 18GB 统一内存)，macOS 15.0，Chrome 129。
- 梯队 C（主流办公轻薄本）：Intel Core Ultra 7 155H (Arc 集显，分配 4GB 共享显存)，Windows 11，Edge 129。
- 梯队 D（移动端旗舰）：某主流品牌旗舰机 (骁龙 8 Gen 3，Adreno 750)，Android 14，Chrome Mobile 129。
- 梯队 E（移动端次旗舰）：某中端机型 (联发科天玑 8300，Mali-G615)，Android 14，Chrome Mobile 129。
核心基准数据实测盘点
所有模型均采用业界成熟的 AWQ / GPTQ INT4 量化格式，权重直接通过 Cache API 缓存到浏览器本地。
1. Qwen-2.5-1.5B-Instruct-q4f16_1 实测表现
1.5B 级别模型是目前端侧最推荐的“任务型助手”（如输入建议、格式补全、前端组件审查）模型：
| 硬件梯队 / 设备型号 | 显存/内存占用 | 首 Token 延迟 (TTFT) | 解码吞吐 (Tokens/s) | 5分钟持续发热与掉电评估 |
|---|---|---|---|---|
| RTX 4070 (桌面) | 1.15 GB | 38 ms | 112.5 tok/s | 核心温度 42℃，无感知 |
| Apple M3 Pro | 1.18 GB | 62 ms | 58.3 tok/s | 冰凉无风扇声，掉电约 1% |
| Intel Arc 集成显卡 | 1.22 GB | 145 ms | 24.1 tok/s | 略有发热，风扇轻微转动 |
| 骁龙 8 Gen 3 | 1.25 GB | 185 ms | 18.6 tok/s | 机身温热，掉电约 3% |
| 天玑 8300 | 1.28 GB | 310 ms | 11.2 tok/s | 明显发热，触发降频后掉至 8 tok/s |
2. Llama-3.2-3B-Instruct-q4f16_1 实测表现
3B 级别模型在复杂上下文遵循和工具调用（Tool Use）上有质的提升，但对端侧硬件是一道分水岭：
| 硬件梯队 / 设备型号 | 显存/内存占用 | 首 Token 延迟 (TTFT) | 解码吞吐 (Tokens/s) | 生产可用性评估 |
|---|---|---|---|---|
| RTX 4070 (桌面) | 2.15 GB | 72 ms | 68.4 tok/s | 极致丝滑，完全超预期 |
| Apple M3 Pro | 2.19 GB | 118 ms | 34.2 tok/s | 表现稳定，阅读速度匹配良好 |
| Intel Arc 集成显卡 | 2.24 GB | 290 ms | 13.5 tok/s | 勉强可用，偶尔有轻微卡顿感 |
| 骁龙 8 Gen 3 | 2.31 GB | 420 ms | 9.8 tok/s | 仅能作为长流程后台任务，体验临界 |
| 天玑 8300 | 2.36 GB | 850 ms | 4.6 tok/s | 不可用，打字机明显迟钝，容易闪退 |
3. 7B 级别大模型端侧生存现状（Qwen-2.5-7B-Instruct-q4f16_1）
实测结果表明：在没有独立大显存的普通用户设备上，在浏览器中强跑 7B 模型目前仍然属于技术自嗨。
- RTX 4070 依然能跑到 32 tok/s；
- M3 Pro 统一内存下能稳定在 16 tok/s；
- 但在 Intel 集显和所有移动端设备上，模型权重下载（近 4GB）耗时极长，加载完成后直接逼近移动端浏览器的单个 Tab 内存红线（多数手机浏览器 Tab 内存上限为 2GB~3GB）。骁龙 8 Gen 3 在跑第二轮对话时直接被 Android 系统的 Low Memory Killer 强制干掉，页面瞬间白屏崩溃。
影响端侧 WebGPU 性能的底层技术深水区
为什么同样的 INT4 模型，在不同架构上的表现天差地别？我们通过 Chrome WebGPU Profiler 与底层着色器反编译发现两个核心根因：
1. 内存带宽决定了自回归的生死
在 Transformer 的 Decode 阶段，生成每个 Token 都需要把数十亿参数从内存读取到计算单元中。计算量其实并不大，纯粹是内存带宽瓶颈（Memory-Bound）。
- Apple M 系列芯片拥有 150GB/s 甚至更高的统一内存带宽，GPU 与 CPU 零拷贝共享内存，因此即便没有独显，Decode 吞吐依然非常可观；
- 移动端 SoC 虽然峰值带宽可达 77GB/s（LPDDR5X），但受到散热与功耗墙（TDP 通常限制在 5W~8W）约束，一旦连续跑 30 秒以上，温控系统就会强行压低 GPU 核心频率，导致生成速率暴跌 40% 以上。
2. WGSL 子组操作（Subgroups）支持不均
在现代 GPU 编程中，Subgroup（或 Warp / Wavefront）级别的通信洗牌（Shuffle）指令是优化矩阵乘法和 Softmax Reduction 的利器。桌面端 NV 显卡和 Apple Silicon 早已完全支持enable chromium_experimental_subgroups;，算子执行效率极高。而很多 Android 设备的 Vulkan 驱动由于厂商定制阉割，在浏览器中无法暴露完整的 Subgroup 特性，只能退回到全局内存反复读写，性能大打折扣。
前端架构师的生产落地决策树
基于本次基准评测的冷酷数据，我们建议前端团队在规划端侧 AI 功能时遵循以下原则：
业务需求：需要端侧 AI 能力 │ ├─► 是否必须支持移动端 H5 / 小程序环境？ │ ├─► 是 ──► 坚决不上 >2B 模型！选型收敛至 0.5B ~ 1.5B 模型（如 Qwen-1.5B） │ │ 且仅用于特定无状态任务（敏感词过滤、拼写纠错、本地搜索排序） │ └─► 否 ──► 进入桌面端决策 │ └─► 桌面端 Web 应用（SaaS / 企业内部后台）： ├─► 目标用户多为 Mac / 独显 PC ──► 大胆使用 3B 模型，体验完全可比拟云端 API └─► 目标用户配置杂乱（老旧轻薄本为主） ──► 实施端云协同（Hybrid-Fallback）架构结语
端侧 WebGPU 绝不是未来遥不可及的概念，它已经在 1.5B 级别的小模型上展现出了惊人的生产可用性。但前端工程师必须清醒地认识到物理世界的限制：算力有功耗墙，带宽有物理极限，内存有系统安全红线。不盲目追求在浏览器跑 7B 大参数，精选 1B 级别的垂直任务小模型，做好降级与显存治理，才是真正务实且具有商业价值的技术落地之路。
