端侧大模型推理：WebGPU 与 Transformers.js 的浏览器落地实践

一、模型在端上跑，本地节省的 8 万 GPU 账单

去年有个做合同摘要的产品，把 1.5B 的小模型搬进浏览器端做推理。第一个月，节省的云端 GPU 账单折算下来有 8 万块。更关键的是，跨国律师上传合同摘要时不再担心数据出境——摘要直接在用户电脑里完成。这事让我意识到，端侧推理的价值远超"省成本"三个字。

但端侧落地并不轻松。某医疗团队曾把同样的方案套到自己的产品上，结果在低配安卓机里模型加载 5 分钟才完成。复盘发现是 WebGPU 初始化失败后没回退 WASM，直接抛错挂起。还有一次是某个 4-bit 量化模型在 iPhone 12 上推理一首诗要 30 秒，体验比云端还糟。这事我见过太多团队栽进去。

更深的挑战是设备碎片化。同一个 WebGPU 适配器，在 macOS 桌面 Chrome 上吞吐 50 token/s，在 Windows 笔记本的集显上只有 10 token/s。前端不能假设设备算力，必须做"分级回退"。

本文聚焦 Transformers.js 结合 WebGPU 的端侧推理方案，拆解模型加载、设备回退、推理调度三个核心环节，并给出生产可用的封装。

二、端侧推理的设备能力协商

端侧推理的第一步是能力探测。WebGPU 是新标准，但并非所有浏览器都支持；即便支持，某些低端 GPU 也会因显存不足而失败。因此需要一个"分级回退"策略：优先 WebGPU，其次 WASM，最后提示设备不支持。

flowchart TD
    A[页面初始化] --> B{支持WebGPU?}
    B -- 是 --> C[尝试创建GPU适配器]
    C -- 成功 --> D[WebGPU推理:高吞吐]
    C -- 失败 --> E[回退WASM:CPU执行]
    B -- 否 --> E
    E --> F{内存是否充足?}
    F -- 否 --> G[提示设备不支持/降级模型]
    F -- 是 --> H[加载量化权重推理]

这套协商逻辑要尽早执行，最好在首屏就探明能力，避免用户点下按钮才发现自己设备跑不了。同时要把模型权重的加载进度展示出来，因为首次下载往往耗时数秒到数十秒，没有进度反馈极易被误判为卡死。

三、生产级端侧推理封装

下面给出基于 Transformers.js 的推理封装。重点在于：用单例避免重复加载；用 progress_callback 驱动进度条；用 device 与 dtype 控制精度与回退；用 AbortSignal 支持取消；用 Worker 隔离推理线程防止阻塞 UI。

// 端侧推理封装：WebGPU 优先，WASM 回退
// 为什么放 Worker：推理是 CPU/GPU 密集，主线程会卡顿
import { pipeline, env } from '@huggingface/transformers';

env.allowLocalModels = false;   // 从 CDN 拉取社区权重，免去自托管

let task: any = null;
let loading = false;

// 在 Worker 内调用：避免大矩阵运算冻结主线程
export async function loadModel(
  onProgress: (p: number) => void,
  signal: AbortSignal
): Promise<void> {
  if (task || loading) return;
  loading = true;
  try {
    // dtype 选 q4：4-bit 量化，体积与显存大幅压缩，精度损失可接受
    task = await pipeline('text-generation', 'Xenova/...-q4', {
      device: 'webgpu',          // 优先 GPU；失败由库自动尝试回退
      dtype: 'q4',
      progress_callback: (e: any) => {
        if (e.status === 'progress') onProgress(e.progress);
      },
    });
  } catch (err) {
    // WebGPU 不可用则显式降级到 wasm
    task = await pipeline('text-generation', 'Xenova/...-q4', {
      device: 'wasm',
      dtype: 'q4',
    });
  } finally {
    loading = false;
  }
  signal.addEventListener('abort', () => { task = null; });
}

export async function infer(prompt: string, maxNew: number): Promise<string> {
  if (!task) throw new Error('模型尚未就绪，请先等待加载');
  const out = await task(prompt, {
    max_new_tokens: maxNew,
    // 温度与采样保证生成多样性，同时限制长度防 OOM
    do_sample: true, temperature: 0.7, top_p: 0.9,
  });
  return out[0].generated_text;
}

主线程与 Worker 之间用 postMessage 传递 prompt 与结果，权重仅加载一次并驻留 Worker 内存。对于多轮对话，还需在 Worker 内维护 kv_cache（键值缓存），避免每轮重算历史，否则延迟会随对话长度线性膨胀。某团队做过多轮对话 benchmark，没启用 kv_cache 时第 10 轮要 8 秒，启用后稳定在 1.2 秒。

四、隐私、性能与兼容的三角权衡

端侧推理最大的优势是隐私与零边际成本，代价则是设备碎片化带来的兼容性噩梦。WebGPU 在桌面 Chrome 覆盖率已较高，但在老旧 Safari、部分安卓 WebView 上完全缺席，这时只能回退 WASM，速度可能慢一个数量级，长文本几乎不可用。

其次是精度与体积的矛盾。4-bit 量化能把模型压到原来的四分之一，但复杂推理任务会出现明显质量下滑。对简单分类、摘要尚可，对多步推理则需 8-bit 甚至更高，代价是显存与下载体积。某团队做过对比：同样 7B 模型，4-bit 量化后通过率 71%，8-bit 升到 84%，但体积从 4GB 涨到 7GB，移动端直接放弃。

最后是首次加载体验。即便做了进度条，几百兆权重的冷启动在移动网络下仍需耐心。工程上常用"预取 + 缓存到 Cache Storage"策略，在用户空闲时提前下载，命中后秒开。

graph TD
    Q[设备能力] -->|WebGPU+充足显存| R[全量或8bit模型]
    Q -->|仅WASM| S[4bit小模型/限制长度]
    Q -->|都不支持| T[引导服务端方案]
    R --> U[质量高,体验好]
    S --> V[可用但慢]

适用边界：隐私敏感（医疗、合同）、离线优先、高频短文本场景最适合端侧；长文档深度推理、需要最新知识的场景，仍应交由云端大模型。

五、总结

端侧大模型推理把算力下沉到浏览器，主要价值在于隐私可控与零推理账单。落地关键有三：一是基于 WebGPU 探测做分级回退，保证异构设备都有可用路径。二是把模型加载与推理放入 Worker，用单例与量化权重控制体积，用 kv_cache 优化多轮延迟。三是用进度反馈与 Cache Storage 预取改善冷启动。权衡上需直面兼容性碎片、量化精度损失与首次加载成本。对于隐私敏感、离线、短文本场景，端侧推理是优选；复杂长程推理仍应依赖云端。这条路的回报是值得的。