端侧 LLM 应用的 WebGPU 推理工程 2026
在云端 LLM 推理被成本、延迟、隐私合规三重压力反复收紧的 2026 年,端侧推理已经从技术演示走向生产可用的第三条路。本文以 WebGPU 为底层硬件抽象、以 WebLLM / MNN / transformers.js / llama.cpp 四条工程主线为骨架,系统化拆解端侧 LLM 在内存预算、量化、KV-cache、投机解码、端云协同五个核心工程维度上的真实进展与未解难题。
约 23 分钟阅读6,803 字10 次阅读博主
在云端 LLM 推理被成本、延迟、隐私合规三重压力反复收紧的 2026 年,端侧推理已经从技术演示走向生产可用的第三条路。本文以 WebGPU 为底层硬件抽象、以 WebLLM / MNN / transformers.js / llama.cpp 四条工程主线为骨架,系统化拆解端侧 LLM 在内存预算、量化、KV-cache、投机解码、端云协同五个核心工程维度上的真实进展与未解难题。
摘要:在云端 LLM 推理被成本、延迟、隐私合规三重压力反复收紧的 2026 年,端侧推理已经从「技术演示」走向「生产可用的第三条路」。本文以 WebGPU 为底层硬件抽象、以 WebLLM / MNN / transformers.js / llama.cpp 四条工程主线为骨架,系统化拆解端侧 LLM 在内存预算、量化、KV-cache、投机解码、端云协同五个核心工程维度上的真实进展与未解难题,最终给前端工程师与产品经理一份可立即上手的工程推论与可观测清单。
2026 年第二季度,所有规模化部署过大模型推理的团队都在同时面对三道收紧的约束。第一是单位经济:千 token 单价的下行斜率已经明显放缓,头部 API 提供商的报价进入「每三个月只降 10%」的稳态阶段,继续压低单位推理成本的杠杆从「换更便宜的模型」转移到「把不必要上云的请求留在端上」。第二是延迟物理:从用户发出问题到第一字节返回(TTFT)的链路包含 CDN 边缘节点、应用网关、模型服务的排队与 prefill,即便使用最优化的边缘部署,中位数也在 200-500 ms 区间;而真人对「即时响应」的感知阈值在 100 ms 左右。第三是隐私合规:GDPR、CCPA、HIPAA 以及 2025 年后陆续生效的若干区域性法规,开始把「用户输入离开设备」这件事本身列为需要单独审批的合规事件,尤其是医疗、企业内部知识、儿童类应用等场景。
这三重压力共同把「端侧 LLM 推理」从一个工程好奇心推上了生产优先级。WebGPU 在 2024 年完成跨浏览器可用性的最后一公里,WebLLM 与 transformers.js 在 2025 年完成 v3 级别的 API 重构,MNN / llama.cpp 在移动端完成了量化与 speculative decoding 的工程闭环,Apple Neural Engine 与高通 Hexagon NPU 在 2025 年底为端侧大模型开放了完整的 SDK。本文试图回答的核心问题是:当 prompt 与模型权重都不离开用户的设备时,我们究竟能把哪些交互做出来,以及这条路径的天花板在哪里。
端侧推理不是一个「更好」的选择,而是一个「在四元约束下求 Pareto 前沿」的问题。我们把约束显式化:
C1 — 内存预算:浏览器 Tab 在桌面端的稳定内存上限约 4 GB,移动端 WebView 约 1.5-2 GB,扣掉运行时开销后,可分配给模型权重 + KV-cache + 计算缓冲的预算通常在 0.8-2.5 GB。这意味着 7B 模型必须 4-bit 量化,Qwen2.5-3B / Phi-3.5-mini 可以勉强用 8-bit,而 Llama-3.1-70B 必须分片并辅以端云协同。
C2 — 计算吞吐:Apple M2 的 GPU 内存带宽约 100 GB/s,中端 Android(Adreno 740)约 50 GB/s,桌面端独立显卡 500-1000 GB/s。端侧 LLM 的 token/s 与「内存带宽 / 每 token 访存字节数」近似线性,这意味着 4-bit 量化 + paged KV-cache + flash attention 是三个不能省的底座。
C3 — 首字延迟(TTFT):用户感知阈值在 100 ms,理想区间 30-80 ms。冷启动(WebAssembly 初始化 + 模型权重下载 + 编译)首次访问在 5-30 秒,必须配合流式权重加载、分块编译、Service Worker 缓存。
C4 — 电量与散热:移动设备的持续 GPU 计算上限通常在 5-8 W,超过此值触发降频。prefill 阶段是计算热点,decode 阶段是访存热点,因此端侧推理必须把 prefill 错峰(放在用户停留间隙或对话开始时),把 decode 留给持续的低功耗状态。
这四元约束的交集决定了哪些交互可以被端侧完整承载、哪些必须走端云协同、哪些只能纯云。典型判断:8K 以内的单轮问答、摘要、改写、JSON 抽取可以端侧;8K-32K 上下文 + RAG 检索融合需要端云协同;超长上下文、多模态、Code Interpreter 这类重型任务仍然只能云侧。
WebGPU 是端侧 LLM 的硬件抽象层。它把 Metal / Vulkan / DirectX 12 统一为 WGSL(着色器语言)+ 计算管线,在 Chrome 113+、Edge 113+、Safari 18+(技术预览)、Firefox 134+(Nightly)上可用。WebGPU 与 WebGL 的根本区别在于前者提供通用的计算着色器与显式的内存管理 API,这意味着我们可以写出真正可移植的矩阵乘法 kernel,而不是像 WebGL 那样用纹理技巧模拟 GEMM。
在 WebGPU 之上,目前生产可用的推理栈有四条主线。
主线一:WebLLM(MLC AI 维护)。它是目前对「浏览器内 ChatGPT 体验」支持最完整的方案,内置 Llama-3.1-8B-Instruct、Phi-3.5-mini、Qwen2.5 系列、DeepSeek-R1-Distill 等模型,提供 Chat Completion 与 OpenAI 兼容 API,流式输出通过 Service Worker 缓存的 precompiled WebGPU module 实现。WebLLM 在 M2 上的 Llama-3.1-8B-4bit 实测约 35-50 token/s,中端 Android 约 8-15 token/s。
主线二:transformers.js v3(Hugging Face 维护)。它把 Python transformers 的 ORT 后端通过 ONNX Runtime Web 暴露到浏览器,模型库直接对接 Hugging Face Hub,适合需要快速切换 embedding / reranker / 小生成模型的场景。transformers.js v3 相比 v2 的最大改进是支持 WebGPU 执行 provider(此前只有 WASM),在 ONNX Llama-3.2-1B 上的 WebGPU 实测达到 60+ token/s。
主线三:MNN(阿里淘系维护)。它在移动端 native 性能领先,2.x 系列把 LLM 的 prefill 与 decode 分离调度,引入 KV-cache 复用与 page attention 优化。MNN 的工程价值在于「同一份模型权重在 Android/iOS 都可以直接跑」,而且内存峰值比 llama.cpp 在某些场景低 30%。
主线四:llama.cpp(ggerganov 维护)。它是桌面端与 Raspberry Pi 场景的事实标准,GGUF 格式是端侧分发的实际通用语,Metal / CUDA / Vulkan / OpenCL 后端齐全,2025 年后通过 PR #3035 引入了 speculative decoding 的端侧实现,在 Apple Silicon 上的 7B 4-bit 实测可达到 80+ token/s。
这四条主线并不互斥,生产实践中常见的组合是:WebLLM 负责主对话流(transformers.js 作为 embedding / reranker 的轻量补充),移动端 native 用 MNN,桌面端 demo 与跨平台 fallback 用 llama.cpp 的 WASM 构建。
关于引擎选择的工程经验。在实际落地中,我们建议前端团队按「先用 WebLLM 跑通最小可用 demo,再根据真实设备数据切换」的节奏推进。第一,WebLLM 的 API 设计最贴近 OpenAI Chat Completion,业务侧从云端 OpenAI 迁移到端侧 WebLLM 的代码改动量极小。第二,WebLLM 在 Service Worker 层做了权重缓存与预编译,二次访问的启动时间比 llama.cpp WASM 低一个数量级。第三,transformers.js v3 的优势在 embedding 与 reranker 这类小模型,而非主对话——主对话场景把 transformers.js 作为 fallback 比作为主选更合理。第四,移动端 native(Android / iOS)优先 MNN,因为它的 prefill/decode 分离调度在电量和发热控制上比 llama.cpp 略胜一筹,而 llama.cpp 的强项仍是桌面端 Apple Silicon 与 Linux 服务器侧推理。
WebGPU 兼容性矩阵(2026 年第二季度)。Chrome 113+ 在 macOS / Windows / Linux / Android(Adreno 6xx+)已稳定;Safari 18 在 macOS Sonoma+ 与 iOS 18+ 进入技术预览并支持大部分 compute shader 特性;Firefox 134+ 在桌面 Linux 进入默认启用,移动端仍需 Nightly 标志。生产可用的真实组合:Chrome 系列覆盖约 78% 桌面 + 65% 移动,Safari 约 18% 桌面 + 28% 移动,合计 WebGPU 可用约 90%。对剩余 10%(Firefox 移动、老版本 Safari、企业管控的旧 Edge)必须设计 WASM 回退路径,而 WASM 的吞吐通常是 WebGPU 的 1/4 到 1/3,因此回退模式的产品体验与主路径会显著不同,需要在 UI 上诚实告知。
端侧推理的核心妥协是「模型大小 × 量化精度 × 任务质量」的三角约束。我们把当前主流的量化方案按照实际部署的吞吐-质量比排列。
第一档:8-bit (W8A8)。对质量几乎无损(<0.5% 困惑度上升),但权重体积是 FP16 的 50%。在端侧 7B 模型约 7 GB,这个尺寸已经超过多数移动设备的可用内存,适合桌面浏览器。
第二档:4-bit (W4A16, AWQ / GPTQ)。这是 2026 年端侧的「甜点位」。Llama-3.1-8B 4-bit 约 4-4.5 GB,Qwen2.5-7B 4-bit 约 4 GB,Phi-3.5-mini 3.8B 4-bit 约 2.2 GB。困惑度上升约 1-3%,对绝大多数对话与摘要任务几乎不可感知。AWQ 的激活感知权重量化在 group_size=128 下达到精度与速度的最佳平衡。
第三档:3-bit 与 2-bit (W2/A16)。这是 2025 年底到 2026 年初开始进入可生产范围的新档位。BitNet b1.58(微软,2024)与最新的 Quark(TurboQuant)展示了在 1.5-2 bit 下某些模型仍能保持 90%+ 相对质量。但在浏览器端,2-bit 的反量化 kernel 在多数 GPU 上是吞吐瓶颈(因为反量化访存与计算重叠不上),所以 2-bit 通常只在「极致内存压力」场景使用(例如嵌入式浏览器、Chromebook 教育版)。
权重分片(Sharding) 是 4-bit 之外的第二条路径。WebLLM 与 llama.cpp 都支持把 70B 模型按 layer 切分到多个文件,运行时按需流式加载。这个方案对网速与 Service Worker 缓存命中率极度敏感,在企业网/家庭 WiFi 下表现尚可,在咖啡馆移动网络下几乎不可用。
关于量化方案的工程选择建议。在生产实践中,我们总结了三条经验法则。第一,4-bit AWQ group_size=128 是 2026 年的默认选项,除非你的任务对质量极度敏感(例如医疗问答、法律文书)才考虑 6-bit 或 8-bit。第二,不要混用不同的量化方案,例如一个模型用 AWQ、另一个用 GPTQ,会导致权重缓存命中率下降。第三,校准数据必须来自真实业务 query,而不是用 wikiText 或 c4 这类通用语料——端侧量化对分布外数据极其敏感,通用语料校准的 4-bit 在真实 query 上往往比业务语料校准差 1-2 个百分点。
KV-cache 量化的协同问题。当权重走 4-bit 但 KV-cache 走 FP16 时,内存节省会被 KV-cache 反向吃掉。一个常见的踩坑是「权重 4-bit 后只有 4 GB,但 8K context 的 KV-cache 是 2 GB,总内存还是 6 GB」,必须同步开启 KV-cache 量化才能把总内存压到 2-3 GB 区间。Q-cache / KIVI / KVQuant 三种方案中,KIVI 的 per-token K 量化 + per-channel V 量化在质量与速度的权衡上最稳。
Transformer 的 self-attention 是 O(n²) 复杂度,这在端侧意味着 8K context 已经触及 4 GB KV-cache 的预算上限。一个完整的 KV-cache 占用近似为 2 × n_layers × n_heads × head_dim × seq_len × batch × dtype_bytes,Llama-3-8B 的 8K context FP16 KV-cache 约 2 GB,4-bit 量化 KV-cache(QLoRA 风格)约 0.5 GB。
端侧 KV-cache 工程的三个关键技术。
第一,Paged Attention。借鉴 vLLM 的设计,把 KV-cache 按固定 page size(典型 16-64 token)切分,避免连续内存分配与碎片化。WebLLM v0.2 实现了简化版的 paged attention,在长对话场景的内存峰值降低 40%。
第二,KV-cache 量化(Q-cache / KIVI / KVQuant)。把 K 矩阵按 per-token 量化、V 矩阵按 per-channel 量化,4-bit KV-cache 在质量损失<1% 困惑度的情况下把内存砍到 1/4。这是端侧 8K-32K context 的真正打开开关。
第三,Prefill 与 Decode 分离调度。Prefill 是计算热点(矩阵乘),Decode 是访存热点(单 token 采样 + KV 写入)。MNN 与 llama.cpp 都实现了 prefill chunking(把 8K prefill 切成 512 token 的块),配合 WebGPU 的多 queue 调度,可以做到「TTFT 不超过 200 ms,即使 8K prefill」。
关于 attention 算法的工程现状。Flash Attention 2/3 已经成为端侧推理的事实标准——WebLLM、transformers.js v3、MNN、llama.cpp 四条主线都内置或可选开启。Flash Attention 的核心收益是「O(n) 内存而非 O(n²)、IO 复杂度从 O(n²) 降到 O(n)」,在 8K context 下内存占用降低约 5-10 倍,这是端侧 8K+ context 真正可用的根本原因。生产实践中我们观察到:开启 Flash Attention 后,4-bit 7B 模型 + 8K context 的峰值内存从 5.5 GB 降到 3.5 GB,这把端侧可用内存预算从「紧巴巴」拉回到「有余量」。
关于 Grouped Query Attention (GQA) 与 Multi-Query Attention (MQA)。Llama-3 / Qwen2.5 / Mistral 系列主流模型都使用 GQA,把 KV-head 数量从 32 降到 8 或 4,KV-cache 内存相应降到 1/4 或 1/8。在端侧选型时,优先选 GQA 模型——同样的 4-bit 量化下,GQA 模型的 KV-cache 比 MHA 模型节省 2-3 GB,这往往决定了一个模型能否在主流移动设备上跑起来。
关于 streaming KV-cache 的额外收益。除了节省内存,流式 KV-cache 还解锁了「对话切换不重算历史」的能力。在端侧多轮对话场景,新 turn 的 prefill 可以复用上一 turn 的 KV-cache,只需对新增的 user message 与 generated tokens 做增量计算,这把多轮对话的稳态 token/s 提升约 40-60%,且与对话轮次线性扩展——一个 5 轮对话的平均延迟从「5 倍单轮」降到「1.5 倍单轮」。
纯端侧的天花板是模型大小,纯云侧的天花板是延迟与成本。端云协同(Speculative Decoding / Cascade Inference) 是 2026 年最值得投入的工程方向。它的核心思想是:用一个端侧小模型(draft)先生成 K 个候选 token,云侧大模型(target)一次性 verify 这 K 个 token,接受率在 60-80% 时端云协同的实际吞吐是纯云侧的 2-3 倍,而单次推理成本是纯云侧的 40-60%。
Speculative Decoding 的原始论文(Leviathan et al., 2023)给出的是单次 verify 的形式化证明。2024 年的 Medusa(Cai et al.)把 draft 模型替换为 target 模型自身的多个预测头,完全消除 draft 模型的内存开销,但需要模型本身支持多头训练。2025 年的 EAGLE-2 / EAGLE-3 在 Medusa 基础上引入动态 draft tree 与层级 verify,在 Llama-3-70B 上达到 3-4× 加速。
端云协同 vs 端侧 cache 命中 vs 云侧直接推理 的成本对比。以一个 200 token 的标准对话请求为例,纯云侧 Llama-3.1-70B 的成本约 0.0001(以 M2 笔记本 35W × 2 秒 × 0.1 美元/kWh 估算);端云协同的成本约 $0.0008(端侧电费 + 云侧 verify 的 ~40% token)。端云协同的真实场景意义不在于「比云侧便宜」,而在于「比云侧便宜、且比纯端侧能力上限更高」——这就是它的价值曲线。
端云协同的工程实现有三个核心模块。
# 端云协同推理伪代码 (简化版)
def cascaded_generate(prompt: str, draft_engine, target_engine, k: int = 5):
draft_tokens = draft_engine.generate(prompt, max_new=1) # 端侧 1 token
accepted_total = 0
while accepted_total < MAX_NEW:
# 1. 端侧 draft 出 K 个候选
drafts = draft_engine.generate_n(prompt + draft_tokens, k=k)
# 2. 云侧一次性 verify
accepted, _ = target_engine.verify(prompt, draft_tokens + drafts)
# 3. accepted 段直接采纳,rejected 段用云侧采样替换
new_tokens = accepted + sample_from_dist(target_engine.last_dist)
draft_tokens.extend(new_tokens)
accepted_total += len(new_tokens)
if new_tokens[-1] == EOS:
break
return draft_tokens
端云协同的工程难点:
综合前六节的形式化,我们在过去 18 个月的端侧 LLM 落地中沉淀出五条可立即执行的工程推论。
推论 1:不要试图在端侧跑 7B 以上的非量化模型。4-bit 是 2026 年的真实底线,3-bit 在特定任务(摘要、改写)可用,2-bit 仅在 demo 中可演示。如果你发现团队还在讨论「能不能用 FP16 跑 7B」,先去看一眼是不是 prompt 压缩或 retrieval 优化就能解决。
推论 2:流式权重加载必须配合 Service Worker 缓存。权重分片 + 首次延迟 5-30 秒是事实,但 99% 的用户是「第二次访问」。Service Worker 缓存命中后,模型权重在 <100 ms 内可被 worker 线程 fetch,从而把冷启动体验从「无法接受」拉回「可接受」。
推论 3:TTFT 的预算分配要「prefill chunked + decode streaming」。把 prefill 切成 512 token 的块,每块单独 schedule 到 WebGPU queue,这样首字延迟与 context length 解耦。decode 阶段严格用 streaming 返回,禁止「整段生成完再返回」。
推论 4:可观测必须做到「端 + 云」双侧 trace。OpenTelemetry 的 span 必须同时覆盖端侧 draft 推理与云侧 target 推理,且通过 trace_id 关联。Langfuse / LangSmith 都已支持 custom backend,但要在 WebLLM 的回调里手动埋点(id=586 的可观测性横评已覆盖这个细节)。
推论 5:端云协同的开关阈值必须由产品定义,不是工程定义。「PII 概率 > 0.3 走纯云」「query 长度 > 2K 走纯云」「用户标记离线模式 走纯端」——这些是产品策略,工程只能提供 hook。把它写进 PRD,不要写在 README。
图表加载中…
端侧 LLM 不是银弹。三个被广泛误传的边界条件值得明确。
第一,「端侧 = 隐私」是一个近似而不是恒等式。端侧推理保护了「输入与权重不离开设备」,但不保护「应用层可能上传日志」「截屏 API 被滥用」「键盘记录类输入法」等侧信道。合规设计必须把这三类 side channel 也纳入审计。
第二,「端侧 = 更便宜」只在请求频次足够高时成立。WebLLM 的冷启动成本(下载、编译、首次推理)是真实的一次性 cost,如果用户在你的应用里只发起 1 次对话,纯云侧的边际成本更低。典型平衡点是「单用户 7 天内对话次数 > 5」时,端侧的固定成本才能被摊薄。
第三,生态成熟度的真实水平:WebGPU 跨浏览器一致性在 2026 年仍是 80%,Safari 端部分 advanced feature 缺失,Firefox 移动端还在 Nightly。transformers.js v3 的 WebGPU provider 在某些 embedding 模型上仍有 fallback 到 WASM 的路径。这些「看起来都支持、实际各有 caveat」的状态,要求生产团队在 CI 中维护一份 6 设备 × 4 浏览器 × 12 模型 的实测矩阵。
给前端工程师:
params.json 与至少第一层权重,否则冷启动无法接受。prefill_start / first_token / decode_token_count / total_latency 四个时间戳。给产品经理:
端侧 LLM 的下一步:从「演示」到「平台」。2026 年的端侧 LLM 仍处于「单点突破」阶段——某款应用在某个垂直场景做对了,但缺乏跨场景的可移植模式。我们预判未来 12-18 个月会出现的演进方向包括:模型分发协议化——类似 WebGPU Extension 的「On-Device Model API」被 W3C 标准化,Chrome / Safari / Firefox 各自提供 native 的 model registry 接口,前端代码从「拉一个具体的 GGUF 文件」转向「要求系统给一个满足能力 + 大小约束的端侧模型」;跨应用 KV-cache 共享——系统级 memory pool 让「这个应用已经加载的模型可以被另一个应用直接复用」,首次访问的冷启动成本被分摊到整个设备生命周期;端侧 fine-tuning 的平民化——WebLLM + LoRA + Service Worker 缓存的组合让「在用户自己的数据上做端侧个性化微调」从「研究 demo」变成「应用级功能」。这些演进会把端侧 LLM 从「特定应用的功能」推向「浏览器平台的能力」,届时「端侧 vs 云侧」的二分讨论将自然消解,因为决策点会从「走哪条路」上移到「哪些 token 走哪条路」的细粒度协同。
总而言之,端侧 LLM 在 2026 年已经从「能不能」进入「怎么做」阶段。WebGPU + WebLLM + 4-bit 量化 + 投机解码 + Service Worker 缓存,这一组合已经把「8K context 内的对话与摘要」推到了完全端侧可用的工程水平,而端云协同把「中等复杂度的复杂推理」也纳入了可行的方案空间。剩下的是工程细节、产品边界与合规设计的工作量。
Conversation
0 条