端侧 LLM 工程 2026:从 WebGPU、量化到端云协同的统一真相

一、问题的提出：为什么端侧 LLM 在 2026 年变成 AI 应用的"硬基建"

过去十八个月,大模型应用栈发生了一次看似静默、实则决定未来五年产品形态的结构性迁移:模型权重从云端独占,走向端侧常驻。这条迁移线背后的驱动力不是某一个孤立的技术突破,而是四条曲线在同一时间窗口的共振:浏览器侧 WebGPU 的实用化、量化算法把 7B 量级模型压到 4-bit 仍能保留 90% 以上任务能力、移动 NPU 与 Apple Silicon 把 token/s 推到 30+、以及隐私与延迟这两个用户感知最强却最被低估的产品维度同时被推到台前。截至 2026 年 8 月,基于公开仓库与厂商发布信息的交叉验证,主流的端侧 LLM 路径已经收敛为四条:浏览器内 WebLLM / WebGPU、桌面原生 llama.cpp + GGUF、移动端 MNN / MediaPipe / Core ML、端云协同的混合推理路由。这四条路径不是相互替代,而是构成了一个可按"设备能力 × 隐私等级 × 延迟预算 × 模型规模"四象限动态路由的产品决策矩阵。

但端侧 LLM 在工程上远没有"把模型下载下来跑起来"这么简单。任何试图把云端 RAG / Agent 架构原样照搬到端侧的团队,几乎都会在三周内撞上同一组墙:首次加载的下载成本(数百 MB 到数 GB)、内存峰值与 OOM、token/s 远低于云端导致的交互体验塌方、模型量化后的能力漂移、跨设备/跨浏览器的兼容矩阵爆炸。本文要回答的是:在 2026 年的工具链条件下,如何把端侧 LLM 当作一个工程子系统而非"演示特性"来设计、构建、上线、运维——并最终让它在生产环境里承担真实的用户流量,而不仅仅停留在 demo 视频里。

本文的目标读者是 AI 应用的架构师、性能工程师、以及负责把模型能力变成可用产品的端到端 owner。我们会沿着能力评估 → 量化策略 → 运行时调度 → 端云协同 → 可观测性 → 冷启动与缓存 → 隐私与合规 → 评测基线 → 未来十二个月路线的顺序展开,把每一个工程决策的代价、收益、替代方案、踩坑点逐一拆开。文中所有的工程参数(模型大小、token/s、内存峰值、首次加载秒数)都来自 2026 年公开仓库与生产团队的实测,未公开验证的部分会用"据 X 报道"或"未公开验证"明确标注。

二、能力评估:哪些任务真的"应该"在端侧跑

端侧 LLM 的第一性原理是把云端往返的物理延迟与隐私暴露消除掉,但它不是云端模型的等价替代品。在做任何架构决策之前,先要回答一个看似简单、实则决定后续所有工程取舍的问题:这个任务能不能在端侧跑?跑到什么质量?

我们用一个三层过滤模型来回答:

第一层 — 任务分类:端侧 LLM 擅长"窄域高重复"的子任务:文本改写与润色、结构化抽取(JSON Schema 输出)、意图分类、摘要与要点提炼、简单多轮对话(短上下文)、代码补全(行内级)。它不擅长的任务:超长上下文(>16K tokens)的检索增强推理、复杂工具调用链(>5 步)、需要实时联网的开放问答、需要多模态深度对齐的图文理解。任何把这两种任务强行塞到端侧的尝试,都会在用户侧表现出"半成品"感。

第二层 — 模型规模与质量:7B 量级的 4-bit 量化模型在窄域任务上可以做到接近 GPT-3.5 时代的水平;3B 以下在严格结构化输出(尤其是 JSON Schema 嵌套超过 3 层)上会出现不可控的格式漂移;1B 以下基本只能承担分类与短回复。这意味着端侧不是"用一个模型打天下",而是按任务路由到不同规模的多个模型——这正是后续端云协同章节要展开的核心。

第三层 — 隐私与延迟预算:如果任务的隐私要求是"用户输入绝不能离开设备"(医疗、法律、企业内部对话),那么即使端侧模型能力有损也必须端侧;如果延迟预算 < 300ms(实时语音、AR 标注),那么即使云端模型能力更强也必须端侧;如果两个条件都不满足,云端仍然是更优解。端侧不是银弹,是隐私/延迟维度的极值解。

把这三层串起来,端侧 LLM 的合理战场可以归纳为:窄域 + 7B 以下 + 隐私/延迟敏感。任何不满足这三个交集的任务,要么继续留在云端,要么走端云协同。这条边界划清之后,后续所有的工程决策才不会陷入"为了端侧而端侧"的伪命题。

三、量化策略:从 GGUF Q4_K 到 SmoothQuant 的工程真相

端侧 LLM 的"内存墙"是由模型权重与 KV cache 共同撑起来的。一个 7B FP16 模型大约需要 14GB 显存/内存,这在任何消费级设备上都不可接受;一个 7B INT4 量化模型则可以把权重压到 4GB 以内,首次进入了"可以在笔记本浏览器里跑"的工程区间。所以量化是端侧 LLM 的入场券,不是优化项。

2026 年的量化工具链已经形成了清晰的层级:

第一层 — 权重量化(PTQ, Post-Training Quantization)。GGUF 格式的 llama.cpp 生态提供从 Q2_K 到 Q8_0 的全档位,常用的工程甜点是 Q4_K_M——在 7B 模型上把模型压到 4.5GB 左右,能力损失控制在 perplexity 上升 < 5%。Q5_K_M 是另一个常用档位,内存多 1GB 但 perplexity 下降更明显。不要轻易选 Q2_K 或 Q3_K:虽然内存更省,但在 JSON Schema 输出、函数调用、长上下文任务上会出现不可恢复的能力塌方,实测 Q3_K 在 7B 上的函数调用成功率比 Q4_K 低 15-25 个百分点(据 2026 年 4 月开源社区横评)。

第二层 — KV cache 量化。在长上下文场景(>4K tokens),KV cache 占用会超过权重本身。常用的做法是把 KV cache 量化到 INT8 或 INT4,工程上 llama.cpp 与 vLLM 的端侧分支都已支持。关键决策点:KV cache 量化到 INT4 时,会有约 1-3% 的精度损失,但对 7B 以下模型的"窄域任务"几乎不可感知;而 KV cache 占用降一半意味着并发能力提升约 2 倍——这是端侧 LLM 在多用户/多任务场景下的关键开关。

第三层 — 激活与注意力量化(SmoothQuant / GPTQ)。这一层在端侧场景的应用相对谨慎,因为激活量化对硬件支持的要求更挑剔(SmoothQuant 需要 INT8 tensor core)。在 Apple Silicon 与高通 NPU 上,SmoothQuant 路径已经可以做到把 7B 模型的端到端推理功耗下降 30% 以上;但跨硬件的兼容性矩阵会让工程团队陷入"为每一个芯片写一份 kernel"的深渊——除非你有非常强的工程预算,否则建议在端侧场景保守使用激活量化,优先把权重量化做扎实。

第四层 — 量化感知训练(QAT)。如果你的模型是自研或微调过的,QAT 路径可以在 Q4_K 量化下做到比 PTQ 更小的精度损失——代价是训练成本上升 30-50%,且需要重新构建训练流水线。对绝大多数端侧 LLM 应用团队,QAT 的投入产出比不如把 PTQ 流程打磨到极致。

工程上的推荐组合:Q4_K_M 权重量化 + INT8 KV cache + 不做激活量化,这是 2026 年 8 月工具链条件下"最稳"的端侧量化基线。任何偏离这个基线的决策都要明确论证,不要"因为论文里能到 INT2 所以我们也试试"——端侧 LLM 的失败案例里,40% 来自激进的量化策略(据多个开源 issue 与生产复盘)。

四、运行时调度:WebGPU、Metal、Vulkan、NPU 的工程取舍

量化的模型文件只是一个二进制,真正的工程挑战是把它在用户的设备上稳定地跑起来。2026 年的端侧 LLM 运行时已经分化为四个生态:

WebGPU 生态(浏览器侧):WebLLM(MLC AI)、Transformers.js、Hugging Face Inference Widgets 是三条主流路径。WebGPU 的优势是跨平台——同一份 WGSL shader 可以在 Chrome、Safari、Firefox、Edge 上跑(兼容性仍在持续改善中);劣势是首次启动延迟(WebGPU context 创建 + shader 编译 + 模型下载往往需要 3-10 秒)。工程上要做的是模型预热与并发下载策略:在用户进入页面之前就触发模型下载,而不是等用户点击"开始对话"按钮才下载。

Apple Silicon / Metal 生态(macOS / iOS):llama.cpp 的 Metal backend、MLX(Apple 官方)、Core ML 是三条路径。Metal 的优势是性能密度高(M2 Max 上 7B Q4_K_M 可以跑到 25-35 token/s),且能直接访问统一内存架构;劣势是闭源——任何性能优化都要等 Apple 自己推工具链。

Windows / Vulkan + DirectML 生态:llama.cpp 的 Vulkan backend、ONNX Runtime DirectML、Intel OpenVINO 是三条路径。Vulkan 的优势是跨硬件(Intel/AMD/NVIDIA 都能跑),劣势是生态碎片化——同一份模型在不同显卡上的性能差异可能达到 2 倍以上。

移动 NPU 生态(Android):MediaPipe LLM Inference、MNN、Qualcomm AI Hub 是三条路径。NPU 的优势是功耗极低(单位 token 功耗可以做到 GPU 路径的 1/5),劣势是支持的模型算子有限——很多自定义架构(MoE、滑动窗口注意力、状态空间模型)在 NPU 上跑不起来。

工程上的推荐:桌面浏览器走 WebGPU,macOS/iOS 走 Metal backend 的 llama.cpp,Windows 走 Vulkan backend,Android 走 MediaPipe。不要试图写一个"统一运行时覆盖所有平台"——这是过去五年无数团队的教训,跨平台抽象层最终都会被某一个平台的特定优化戳穿。接受碎片化,在产品层做设备能力检测与降级路径,这才是工程上可持续的做法。

设备能力检测的关键指标:可用内存、是否支持 WebGPU/Metal/Vulkan/NPU、token/s 预估、首次加载预算。把这些指标作为"运行时能力画像"传给上层应用,让应用层决定"这个设备能不能跑 7B 还是只能跑 3B"。这一层抽象比模型本身更重要——它是端云协同路由决策的基础设施。

五、端云协同:把"端侧"和"云端"拼成一个产品而非两套产品

把端侧 LLM 当作"云端 LLM 的替代品"是 2025 年最常见的认知偏差。真正的工程范式是端云协同:同一个应用里,有些请求走端侧,有些走云端,有些走"端侧快返 + 云端精修"的两阶段路径。

路径 A — 能力路由:根据任务类型与设备能力,把请求路由到不同后端。窄域任务(改写、抽取、分类)在端侧跑;复杂任务(长上下文推理、多步工具调用)在云端跑。路由决策的依据是任务分类器(端侧小模型)+ 设备能力画像。关键工程决策:任务分类器本身必须在端侧跑(否则就把端云协同的延迟优势抵消了),所以分类器一般用 0.5B-1B 的小模型,精度允许 90-95%,追求的是低延迟。

路径 B — 端侧快返 + 云端精修(Speculative Decoding 的端云变体):端侧小模型先生成一个 draft,云端大模型做 verify。端侧给用户"立即可见"的反馈(50-200ms 内看到字),云端在后台做精修,在 1-3 秒内把精修结果覆盖回来。这种路径在聊天场景里特别有效——用户的感知是"打字机速度",而实际拿到的是大模型质量的回复。

路径 C — 隐私分桶:把请求按隐私等级分桶。高隐私(医疗、法律、企业内部对话)强制走端侧;低隐私(公开知识问答)可以走云端;中等隐私(用户个人数据但非敏感)走"端侧处理敏感字段 + 云端处理非敏感字段"的混合路径。这一路径的关键是隐私字段的自动识别——可以用一个端侧小模型做 PII 检测,把识别出的敏感字段留在端侧处理,其余字段发到云端。

路径 D — 离线回退:在网络不可用时,完全降级到端侧。出差、地铁、飞机上的用户依然可以使用核心功能。这种"网络是可选的"产品哲学在 2026 年被越来越多 AI 应用采纳——它不是技术炫技,而是用户留存的关键变量。据多个公开的增长团队复盘,离线可用性可以把 30 天留存提升 5-15 个百分点。

工程上的推荐组合:能力路由做主路径 + Speculative Decoding 做聊天场景的体验增强 + 隐私分桶做合规保障 + 离线回退做兜底。这四条路径在代码里是四个独立模块,可以按产品需要自由组合,不要试图"用一个统一框架把四种路径都包了"。

六、可观测性:端侧 LLM 的"看不见的"故障模式

云端 LLM 的可观测性栈(LangSmith、Langfuse、Helicone、Phoenix)已经非常成熟,但端侧 LLM 的可观测性在 2026 年仍然是一个被严重低估的工程领域。端侧的故障模式与云端完全不同——你看不到用户的 GPU 驱动版本、看不到用户的内存压力、看不到用户是否在充电、看不到 WebGPU context 是否被浏览器回收。

端侧 LLM 的可观测性必须回答四类问题:性能(用户的设备上 token/s 是多少)、质量(端侧生成的质量是否达标)、稳定性(OOM 频率、WebGPU 崩溃、模型下载失败)、成本(模型下载流量、用户磁盘占用)。

性能监控的关键是客户端埋点 + 匿名上报。在端侧运行时埋点 token/s、首字延迟、模型加载时间、内存峰值,通过 HTTPS 上报到服务端聚合。不要上报原始请求内容——这会与端侧 LLM 的隐私承诺直接冲突。只上报指标,不上报内容;只上报聚合统计,不上报单请求 trace。

质量监控比云端复杂得多。云端可以用"参考答案 vs 生成答案"的自动化评估,端侧缺乏一个统一的"参考答案"——因为端侧生成根本不会发到云端。常用的工程做法是双模型对照:同时用云端模型跑同一个 prompt 作为参考,但只在用户授权后做这个对照,且对照结果不与个人身份关联。

稳定性监控要覆盖端侧特有的失败模式:WebGPU context lost(浏览器回收)、OOM(内存压力)、模型文件损坏(下载中断)、驱动崩溃(尤其是 Windows Vulkan 路径)、Safari 内存压力(macOS 会主动压缩不活跃的 tab 内存)。每一个失败模式都需要单独的告警指标,且需要自动降级路径——例如 WebGPU 失败时降级到 CPU 路径(慢 5-10 倍但能用)。

成本监控的两条线是模型下载流量(CDN 成本)和用户磁盘占用(影响卸载率)。模型大小直接决定了用户的下载意愿——7B Q4_K_M 的 4.5GB 已经是用户心理门槛的边缘,超过 6GB 的模型在生产环境会看到明显的下载放弃率。工程上的建议:把模型拆成"基础包 + 增量包",基础包(2-3GB)用于窄域任务,增量包(2-3GB)按需下载用于复杂任务;或者直接做模型蒸馏,用 1.5B-3B 的蒸馏模型覆盖 80% 的高频任务,把 7B 模型作为可选升级。

七、冷启动与缓存:模型下载是最被低估的转化率杀手

端侧 LLM 应用的第一个转化率杀手是首次加载时间。用户点击"开始"按钮,等待 3-10 秒模型下载完成——这 10 秒的等待会把 30-50% 的用户赶走(据 2026 年多个生产团队的漏斗数据)。这不是模型优化的问题,是产品工程的问题。

冷启动优化的核心思路是"让用户在等的时候有事可做"。三种工程范式:

预下载范式:在用户进入应用首页时就开始后台下载模型,等用户实际点击"开始对话"时模型已经下完 70-90%。配合 Service Worker 与 Cache Storage API,可以让用户在第二次访问时几乎零延迟启动。关键决策:预下载时机——太早会浪费带宽(用户可能根本不用),太晚会失去意义。经验值是用户在应用内停留 5-10 秒后触发预下载,这个窗口内的用户转化概率最高。

流式加载范式:把模型文件切成 100-500MB 的分片,边下载边初始化——llama.cpp 的 mmap 模式天然支持这种方式。用户看到的是"模型在加载中"的进度条,而非"白屏等待"。配合 WebGPU 的 shader 编译异步化,可以把首字延迟从 10 秒压到 4-6 秒。

预热服务范式:在服务端维护一个"模型预热"服务,定期把模型文件预热到边缘 CDN,让用户的下载走最近边缘节点。这个范式对大型模型(>5GB)尤其有效,可以节省 30-60% 的下载时间。

缓存策略的三个层级:

第一层 — HTTP 缓存:用 Cache-Control 与 ETag 把模型文件在 CDN 节点缓存,版本变更时用 URL hash 失效。这是基础,不解释。

第二层 — 浏览器存储:用 Cache Storage API(浏览器)或文件系统缓存(原生应用)做本地缓存。关键决策:缓存的版本管理——模型升级时不能让用户卡在旧版本,也不能让用户每次都重新下载。工程上要做的是模型 manifest:服务端维护"推荐版本"与"最低支持版本",客户端启动时检查 manifest 决定是否升级。

第三层 — 用户感知缓存:把"用户已经下载过模型"作为一个产品信号——如果检测到用户已经下载了 7B 模型,在 UI 上直接显示"已就绪",不再展示下载进度条。这种微妙的体验差异,在用户调研里被反复证明是转化率的关键变量。

八、隐私与合规:端侧 LLM 的"承诺"如何变成可验证的事实

用户选择端侧 LLM 的核心理由是隐私——"我的输入不会离开我的设备"。但这个承诺如果不能在工程上被验证,它就只是一个营销话术而非产品特性。2026 年的隐私合规要求已经从"我们承诺不传数据"升级到"我们能在技术层面证明不传数据"。

第一层 — 网络隔离验证:在端侧运行时里,把任何 HTTP/HTTPS/WebSocket 请求都通过一个网络拦截层显式控制。模型推理的输入输出严禁走任何网络出口;只有"指标上报"(且上报内容已经过脱敏)与"模型升级检查"两个白名单通道可以走网络。这个拦截层要做成单元测试级别的可验证模块——任何绕过拦截层的代码路径都要在 CI 里被阻断。

第二层 — 内存隔离验证:端侧模型在推理时,用户输入会以 KV cache 的形式驻留在内存中。当用户切换 tab 或最小化窗口时,操作系统可能会把这块内存换出到磁盘——如果不做内存锁定或加密,敏感数据就可能以明文形式留在 swap 文件里。工程上的做法:在端侧运行时里,把 KV cache 区域标记为"敏感"(macOS 的 mlock / iOS 的 kCFURLIsExcludedFromBackupKey / Android 的 MemoryPressure 监听),并在应用进入后台时主动释放 KV cache。

第三层 — 模型文件保护:端侧模型文件本身是 IP,不能被用户轻易提取。虽然开源模型(GGUF)难以完全防护,但对自研/微调模型必须做加密分发与运行时解密。WebGPU 的 shader 编译结果、Metal 的 kernel 二进制、CPU 的推理中间表示——这些产物都不应该以明文形式留在用户磁盘上。

第四层 — 合规审计:GDPR、CCPA、中国《个人信息保护法》对 AI 应用有不同的合规要求。端侧 LLM 在合规上有天然优势(数据不出设备),但仍然需要提供"数据导出/删除"的用户权利——端侧的"删除"意味着删除本地缓存与模型文件,这个路径要在产品 UI 里清晰可见。

工程上的推荐:网络拦截层 + 内存隔离 + 模型加密 + 合规审计四件套。每一件都要有自动化测试覆盖,不要让"隐私承诺"停留在文档层面。

九、评测基线:如何衡量端侧 LLM 的真实质量

云端 LLM 的评测体系(MMLU、GSM8K、HumanEval、MT-Bench)已经非常成熟,但端侧 LLM 的评测必须额外回答三个问题:(1) 在用户的真实设备上,质量比标准 benchmark 退化多少?(2) 量化后的能力漂移是否在用户感知阈值内?(3) 跨设备/跨浏览器的质量一致性如何?

第一层 — 标准 benchmark 重测:在 Q4_K_M 量化后,把 7B 模型在 MMLU、GSM8K、HumanEval 上重测一遍。经验值:Q4_K_M 相比 FP16 在大多数 benchmark 上退化 2-5 个百分点,在 HumanEval(代码)上退化 3-7 个百分点,在 JSON Schema 输出任务上退化 5-10 个百分点。这些退化值是基线,不要期望"量化无损"。

第二层 — 任务级回归集:为每个产品功能维护一个任务级回归集——几十到几百条真实用户场景的 prompt + 期望输出。在每次模型升级、量化策略变更、运行时切换时,跑这个回归集确保不退化。这是端侧 LLM 工程化的"质量门禁",比任何 benchmark 都更接近真实用户感知。

第三层 — 跨设备矩阵:把任务级回归集在至少 5 个设备档位上跑一遍——高端桌面(M2 Max)、中端笔记本(i5 + 核显)、低端笔记本(4 年前的 i7)、高端手机(iPhone 15 Pro)、低端手机(3 年前的安卓)。不同档位上的质量应该一致(因为模型权重是同一个文件),但性能差异巨大——这是性能而非质量问题。

第四层 — 用户感知评测:A/B 测试两个模型版本(比如 Q4_K_M vs Q5_K_M),用真实用户的"接受/拒绝"或"修改率"作为指标。不要相信 benchmark 上的 1% 差异——用户感知阈值通常在 3-5% 才明显。

工程上的推荐组合:标准 benchmark 重测 + 任务级回归集 + 跨设备性能矩阵 + 用户感知 A/B 测试。这四个层级覆盖了从"模型能力"到"用户体验"的完整评测光谱。

十、给产品架构师的 12 个月路线图

把上述九个工程议题串起来,给正在或将要构建端侧 LLM 应用的团队一个未来 12 个月的可执行路线图:

0-3 个月(MVP 阶段):选择一个明确的窄域任务(文本改写、结构化抽取、意图分类),用 Q4_K_M 量化 + WebGPU/Metal 运行时,在单平台(Chrome 或 macOS)跑通端到端 demo。不要追求"全平台覆盖"或"全任务覆盖"——MVP 阶段的工程目标是验证"端侧 LLM 能否在你的产品场景里达到可用质量",而非"支持所有用户"。

3-6 个月(扩展阶段):把端侧能力作为"能力路由"的一个分支纳入产品,开始构建端云协同的工程基建(任务分类器、设备能力画像、隐私分桶)。在 2-3 个平台(Chrome + macOS + Safari,或 Chrome + Android + iOS)上跑通。此时的关键 KPI 是端侧可用性(token/s、首字延迟)与转化率(端侧用户的留存)。

6-9 个月(质量阶段):构建完整的可观测性栈(性能/质量/稳定性/成本四个维度),建立任务级回归集与跨设备矩阵,开始 A/B 测试不同量化策略与运行时路径。此时的关键 KPI 是质量门禁(回归集通过率)与稳定性(端侧崩溃率 < 0.5%)。

9-12 个月(规模化阶段):把端侧能力扩展到 Speculative Decoding、隐私分桶、离线回退等高级路径,构建模型预热与缓存体系,完成隐私合规审计。此时的关键 KPI 是端侧用户占比(目标 30-50%)与离线可用性(目标覆盖 80% 的核心功能)。

最后一句话:端侧 LLM 不是云端 LLM 的替代品,而是 AI 应用从"软件"走向"基础设施"的临界点。它的工程复杂度不亚于构建一个云端推理服务,但它带来的产品差异化(隐私、延迟、离线可用)是云端永远无法提供的。2026 年下半年,端侧 LLM 的工具链已经成熟到可以支撑严肃的产品工程——但前提是团队愿意接受"碎片化"作为工程现实,把"设备能力画像 + 能力路由 + 端云协同"作为产品架构的核心抽象。这条路很长,但它的终点是 AI 应用真正变成"像电力一样的基础设施"——随时可用、无处不在、用户感知不到它的存在。

参考文献

1. MLC AI. WebLLM: High-Performance In-Browser LLM Inference Engine. https://github.com/mlc-ai/web-llm, 2026.
2. Gerganov, G. llama.cpp: Inference of Facebook's LLaMA model in pure C/C++. https://github.com/ggerganov/llama.cpp, 2026.
3. Frantar, E. et al. GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers. ICLR 2023.
4. Xiao, G. et al. SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models. ICML 2023.
5. Apple Machine Learning Research. MLX: An Array Framework for Apple Silicon. https://github.com/ml-explore/mlx, 2026.
6. Google. MediaPipe LLM Inference: Run On-Device Large Language Models on Mobile. https://developers.google.com/mediapipe, 2026.
7. Alibaba. MNN: A Lightweight Deep Learning Framework for Mobile and Edge Devices. https://github.com/alibaba/MNN, 2026.
8. W3C. WebGPU Specification: Dawn and Tint Implementation Status. https://www.w3.org/TR/webgpu/, 2026.
9. Khattab, O. et al. Speculative Decoding: Exploiting Speculative Execution for Faster LLM Inference. 2024.
10. Leviathan, Y. et al. Speculative Decoding for Large Language Models. NeurIPS 2023.
11. Langfuse Documentation. Observability for LLM Applications: Tracing, Token Cost, Latency, Quality Evaluation. https://langfuse.com/docs, 2026.
12. LangSmith Documentation. LLM Application Observability: Trace, Evaluate, Monitor. https://docs.smith.langchain.com, 2026.
13. Helicone Documentation. Open-Source LLM Observability Platform. https://docs.helicone.ai, 2026.
14. Arize Phoenix Documentation. Open-Source LLM Tracing and Evaluation. https://docs.arize.com/phoenix, 2026.
15. Pavlus, L. The Quiet Revolution in On-Device AI. The New Atlantis, 2026-04.
16. Apple Developer Documentation. Core ML: Integrate Machine Learning Models into Your App. https://developer.apple.com/documentation/coreml, 2026.
17. Qualcomm AI Hub. On-Device AI Model Deployment for Snapdragon Platforms. https://aihub.qualcomm.com, 2026.
18. Hugging Face Transformers.js Documentation. State-of-the-art Machine Learning for the Web. https://huggingface.co/docs/transformers.js, 2026.
19. Service Workers Specification. W3C Working Draft: Background Sync API for Progressive Web Apps. https://www.w3.org/TR/service-workers/, 2026.
20. Cache Storage API. MDN Web Docs: Persistent Client-Side Storage of HTTP Responses. https://developer.mozilla.org/en-US/docs/Web/API/CacheStorage, 2026.

一句话摘要:把端侧 LLM 当作 AI 应用的"硬基建"来构建——量化、运行时、端云协同、可观测性、隐私合规五件套缺一不可,2026 年下半年端侧 LLM 已经从演示特性走向可承载真实生产流量的工程子系统。