端侧推理能做什么
浏览器里跑模型这件事，2026 年已经不是演示了。WebGPU 的可用性、量化技术、以及 Transformers.js 这类库的成熟，让"不发请求、本地出结果"成为某些场景的合理选择。
但它的边界很硬。判断它能不能用在你的产品上，看的不是"能不能跑起来"，而是另外四个数。
1. 四个硬约束
1.1 首次要下载权重
模型权重是要下载到用户设备上的。小模型几百 MB，稍大一点几 GB。这发生在首次使用时，且无法隐藏——用户要么等，要么你给进度条。
可行的缓解：
- 用量化版本（INT4/INT8 量化能显著减小体积）
- 后台预加载，在用户需要之前就开始下
- 缓存到 IndexedDB，第二次不用重下
- 明确告知体积，让用户选择
不能缓解的是"第一次总得下载"。所以首屏就要结果的场景不适合端侧。
1.2 WebGPU 不是到处都有
WebGPU 是当前浏览器端推理的主要加速后端。它的覆盖面已经可观（全球约八成以上，不同口径在 73%–85% 间浮动，以 caniuse 当期数据为准），但结构比数字更重要：Firefox 从 141 起（2025-07）在 Windows 上默认启用、142 起覆盖全上下文、147 起覆盖 Apple Silicon Mac，但 Linux 与 Intel Mac 仍默认关闭；Safari 要到较新版本才提供；移动端与 Linux 的覆盖明显低于桌面。也就是说降级是常态而不是例外，不能当成边缘情况处理。
所以代码里必须做能力检测，并且要有降级路径：WebGPU 不可用时怎么办——退回服务端、还是禁用这个功能。
没有降级路径的端侧功能，在那部分用户那里就是坏的。
1.3 显存/内存常驻
模型加载后要占着内存。一个 8B 级模型量化后仍需要数 GB 量级的显存。这在桌面端可行，在中低端移动端不现实。
而且它是常驻的——不像网络请求用完就释放。如果你的页面本身内存占用就高，再加载一个模型可能直接触发标签页崩溃。
1.4 设备性能差异极大
同一个模型，在 M 系列芯片的笔记本上和在一台三年前的安卓机上，速度可以差一个数量级。你的"平均延迟"没有意义，要看最慢的那批用户能不能接受。
2. 真正适合的场景
按说服力排序：
隐私敏感的小任务。 文本分类、本地嵌入、表单内容的本地校验。数据不出端是硬需求时，端侧是唯一解。
离线可用。 断网时功能不能全瘫的场景。端侧是唯一选择。
零边际成本的高频小任务。 每次调用都很小但量极大（比如逐条内容的实时打标），端侧可以完全省掉这部分 API 成本。
输入预处理。 在做向量检索之前，先在端侧做embedding 或摘要，减少上传量。
不太适合的：长上下文、复杂推理、需要最新知识的任务、以及任何"首次使用就要立刻看到结果"的场景。
3. 库怎么选
Transformers.js（Hugging Face）是最主流的选择——它把 transformers 生态的模型搬到浏览器，支持 WebGPU 后端，当前版本已经覆盖结构化输出等能力，且对 Safari 的 WebGPU 支持已跟上。
WebLLM 偏向"在浏览器里跑一个完整的 LLM 对话"，内置一批预编译模型，适合想直接要一个聊天能力的场景。
ONNX Runtime Web 更底层，适合你已经有一个 ONNX 模型要部署的情况。
选型依据通常是：你的模型来自哪里（Hugging Face 生态用 Transformers.js 最顺）、要不要开箱即用的对话能力（WebLLM）、还是只需要推理一个自有模型（ORT Web）。
4. 工程要点
4.1 不要在主线程跑
推理是重计算，在主线程会冻结 UI。必须放进 Web Worker。
这一点没有商量余地——哪怕模型很小。同时 Worker 也便于做加载进度上报和取消。
4.2 加载状态要精细化
"加载中"一个状态不够。用户需要知道：在下载（多少 MB / 百分比）、在编译（WebGPU shader 编译也要时间）、在预热（第一次推理通常更慢）。
第一次推理的额外延迟值得单独处理——可以在加载完成后先跑一次空输入预热，避免用户的第一次真实请求撞上冷启动。
4.3 能力检测与降级
async function pickBackend() {
if ('gpu' in navigator) {
const adapter = await navigator.gpu.requestAdapter()
// 有 navigator.gpu 不代表能用：驱动黑名单、无合适适配器都会返回 null
const device = await adapter?.requestDevice().catch(() => null)
if (device) return 'webgpu'
}
// WASM 是真实可用的 CPU 后端，几十 MB 的小模型完全够跑
if (typeof WebAssembly !== 'undefined') return 'wasm'
return 'none' // 兜底走服务端
}
这里值得展开的是 WASM 这一档。很多文章把"没有 WebGPU"直接等同于"不能端侧推理"，其实 WebAssembly（带 SIMD，可选多线程）是主流运行时都支持的 CPU 后端：ONNX Runtime Web、Transformers.js、WebLLM 都提供。它比 WebGPU 慢几倍，但对分类、嵌入、小参数生成这些场景足够。多线程需要 SharedArrayBuffer，也就需要站点发 Cross-Origin-Opener-Policy 与 Cross-Origin-Embedder-Policy 两个头。
另外三条 2026 年已经不能忽略的路线：MediaPipe LLM Inference API（移动端封装好）、Chrome 内置的 Prompt API（走 Gemini Nano，不需要自己下权重）、WebNN（把推理交给系统层）。选型时按"要不要自己控模型"分：要控就 Transformers.js / ORT，不控就用浏览器内置能力。
权重的缓存也别用 IndexedDB 存大 blob：主流运行时走 Cache Storage（HTTP 缓存语义、浏览器会按容量驱逐），大模型更倾向 OPFS。iOS Safari 的配额与驱逐策略最激进，必须实测——"第二次打开还要重下 2GB"在移动端是致命的。
4.4 与服务端的关系
最实用的结构是端侧做补充而不是替代：
- 轻量、高频、隐私敏感的任务走端侧
- 复杂、长上下文、需要最新知识的走服务端
- 端侧不可用（设备不支持、加载失败、超时）时回落到服务端
这个结构也天然符合降级链的设计——见《多模型接入与降级链》，端侧可以视为链条上的一档，而不是一个独立系统。
5. 一个常被忽略的收益：降级可用性
端侧推理在"服务端挂了"这件事上有独特价值：它是用户设备上的，不受你的服务可用性影响。
如果你的产品有核心的小功能（比如输入内容的实时校验、本地分类），把它们做成端侧，意味着即使后端完全不可用，这部分功能仍然工作。
这比"省了多少 API 费用"更有说服力。
6. 什么时候不该做
直说几条：
- 首屏就要出结果——下载时间无法接受
- 用户设备以中低端移动设备为主——内存和算力都不够
- 任务需要最新知识——端侧模型的知识是冻结的
- 只是因为"端侧很酷"——它会显著增加你的工程复杂度和包体积
最后一条不是玩笑。端侧推理引入的复杂度是实的：模型版本管理、加载状态、能力检测、降级路径、Worker 通信、缓存失效。没有明确收益支撑时，这些成本不值得付。
7. 清单
- 确认收益是隐私、离线、成本或可用性之一
- 测过目标用户设备的覆盖率（WebGPU 可用比例）
- 量化后的体积可接受，且有下载进度与缓存
- 推理在 Worker 里，不在主线程
- 有明确的不支持降级路径
- 第一次推理做过预热
- 模型版本可管理、可更新
- 端侧失败时能自动回落服务端
8. 与 AI 客服场景的关系
一个具体的用法：客服输入框里做输入端的本地处理——把用户输入的口语先在本地做一次规范化或分类，再决定走哪条检索路径。这类任务小、高频、且能减少一次网络往返。
而回答生成仍然必须走服务端——它需要知识库、需要大模型、需要审计（见《反馈回流与人工转接》，客服场景的每一轮都要可追溯）。
端侧负责输入侧的小任务，服务端负责需要知识与责任的部分。 这条分界在大多数 AI 产品里都成立。