1. 把模型塞进浏览器这笔账到底怎么算第一次听到把AI功能放到用户浏览器里跑这个思路我的反应和大多数人一样这不是脱裤子放屁吗服务器上几张显卡一摆接口一开前端只管发请求收结果多省事。直到我自己接手了一个日活不算高但调用量很尴尬的项目才真正开始认真算这笔账。那个项目做的是文档辅助处理用户上传一份合同或者报告系统自动做摘要、关键信息抽取、风险点标注。最开始全部走云端推理一张A10跑着量化后的模型单次请求平均耗时1.8秒成本看起来还能接受。但问题出在流量曲线上——白天几乎没人用晚上八点到十一点集中爆发峰值QPS能冲到40多。为了扛住这个峰值我不得不常驻两张卡闲时利用率不到15%。一个月下来光GPU租用费用就够我喝一壶的。后来我尝试把其中一部分能力下沉到浏览器端。具体做法是用ONNX Runtime Web配合WebGPU后端把一个经过蒸馏和量化的小模型直接加载到用户本地执行。第一次跑通的时候我盯着控制台里那个inference time: 340ms愣了好几秒——比我云端那台机器还快。原因很简单用户的笔记本或者台式机哪怕只是核显算力也比我想象中强得多而且没有网络往返的延迟。但能跑和该跑是两码事。端侧推理不是银弹它有自己非常明确的适用边界。我踩过的第一个坑就是盲目把所有功能都往端侧搬结果用户投诉页面卡顿、风扇狂转、手机发烫。后来我才慢慢摸清楚哪些场景适合端侧哪些必须留在云端以及混合架构到底该怎么设计。这篇文章我想把这段时间的实践完整梳理一遍。如果你正在纠结要不要把AI能力放到浏览器里或者已经在做但遇到性能、兼容性、成本核算方面的困惑下面的内容应该能帮你少走一些弯路。我会从成本结构、技术选型、性能调优、兼容性处理、安全边界几个维度展开尽量把每个决策背后的为什么讲清楚。2. 端侧推理的成本账省下的和付出的2.1 云端推理的隐性成本被严重低估很多人算成本只算GPU小时单价这是最大的误区。云端推理的真实成本至少包含四块算力租用、网络带宽、冷启动开销、以及为峰值预留的冗余容量。算力租用是最直观的。以一张中端推理卡为例按需实例每小时几块钱到十几块钱不等包月能便宜些但灵活性差。如果你的服务有明显的潮汐特征按需实例在闲时就是纯浪费。我那个项目峰值集中在晚上白天两张卡基本在空转等于每天有十几个小时在烧钱。网络带宽这块容易被忽略。模型输出如果是长文本单次响应可能几KB到几十KB乘以日调用量出站流量费用累积起来并不少。尤其是做流式输出的时候连接保持时间长对网关和负载均衡的压力也更大。冷启动开销在Serverless架构下特别明显。如果你用的是按需伸缩的推理服务第一个请求往往要等模型加载几秒到几十秒都有可能。用户体验差不说为了缓解这个问题还得保活实例又回到常驻成本的老路。峰值冗余是最要命的。为了扛住晚高峰你必须按峰值配置资源但峰值可能只占全天时间的10%不到。这部分冗余容量的利用率极低却是实打实的支出。2.2 端侧推理把哪些成本转移给了用户把推理放到浏览器里最直接的变化是算力成本从你的账单转移到了用户的设备上。用户用自己的CPU、GPU、内存来跑模型你只需要提供一个静态资源包和一套加载逻辑。对于调用量波动大的服务这个转移带来的成本优化非常显著——你不再需要为峰值预留任何容量因为每个用户的设备天然就是分布式的算力节点。但这里有个关键前提转移过去的计算量必须足够小小到用户感知不到明显负担。如果模型太大、推理太慢用户会直接关掉页面你省下的钱还不够弥补流失。我做过一个粗略的对比。同一个摘要任务云端方案单次推理成本含算力、带宽、冗余摊销大约在0.003到0.008元之间取决于并发和实例类型。端侧方案的单次成本几乎为零但首次加载模型需要下载几MB到几十MB的资源包这部分流量走CDN成本大约在0.0001到0.0005元每次按缓存命中率折算。也就是说端侧方案在调用频次足够高的情况下成本优势是数量级的。不过这个账不能只算钱。端侧推理还有几个隐性收益数据不出本地隐私合规压力小没有网络往返响应延迟低且稳定服务可用性不受后端影响后端挂了端侧功能照常。这些收益在某些场景下比省钱更重要。2.3 什么情况下端侧反而更贵端侧不是永远划算。以下几种情况强行端侧会让你付出更大代价。模型体积过大导致首次加载时间过长。用户打开页面要等十几秒甚至更久才能用上功能流失率会飙升。我测试过一个未充分量化的模型压缩后还有80多MB在移动网络下加载体验极差最后不得不放弃端侧方案。推理频次极低。如果用户一个月才用一次这个功能端侧加载模型的成本流量、时间就摊不平不如直接走云端。设备性能差异极大。你的用户里如果有大量老旧设备端侧推理可能慢到不可接受甚至直接崩溃。这时候需要做能力检测和降级降级逻辑本身也是成本。需要强一致性的场景。端侧模型版本更新依赖用户刷新页面如果你需要所有用户在同一时刻使用同一版本模型端侧会带来版本碎片化问题。我的经验是端侧适合高频、轻量、隐私敏感、对延迟敏感的场景云端适合低频、重载、需要强一致性和集中管控的场景。混合架构往往是最终答案。3. 浏览器里跑模型的技术底座WebGPU、WASM和它们的边界3.1 WebGPU到底能给你多少算力WebGPU是这几年浏览器端AI最关键的变量。它让JavaScript能够直接访问GPU的计算能力不再受限于WebGL那套为图形渲染设计的接口。对于矩阵乘法、卷积这类模型推理的核心运算WebGPU的加速比是数量级的。我在一台搭载集成显卡的轻薄本上做过对比测试。同一个量化后的Transformer模型纯WASMCPU推理单次耗时约1200ms切换到WebGPU后端后降到280ms左右。如果是独立显卡差距会更大。这个提升足以让很多原本不可用的端侧场景变得可用。但WebGPU不是万能的。它的能力边界需要清楚显存容量有限。浏览器能申请的GPU缓冲区大小受设备和驱动限制大模型直接加载会失败。我遇到过在部分设备上超过1GB的缓冲区申请直接被拒绝的情况。算子支持不完整。WebGPU本身是底层图形和计算API模型推理需要的算子需要框架层实现。ONNX Runtime Web、Transformers.js这些库在持续补齐但仍有算子缺失或回退到CPU的情况。浏览器支持还在铺开。桌面端Chrome、Edge较新版本已经默认开启Firefox和Safari的进度不一。移动端支持更碎片化。3.2 WASM的角色兜底和调度WebGPU负责加速WASM负责兜底和整体调度。ONNX Runtime Web的WASM后端可以在没有WebGPU的环境下运行虽然慢但保证了功能可用。同时WASM还承担了模型加载、内存管理、算子调度这些工作WebGPU只是把其中计算密集的部分接过去。WASM的多线程支持也很关键。通过SharedArrayBuffer和Worker可以把推理任务放到后台线程避免阻塞主线程导致页面卡死。但SharedArrayBuffer的启用需要特定的响应头配置部署时容易漏掉这个后面会细说。3.3 模型格式与量化决定端侧可行性的关键一步浏览器端能跑的模型几乎都是经过量化和图优化的。原始PyTorch或TensorFlow模型直接往浏览器里塞体积和算力需求都扛不住。主流路径是导出为ONNX格式然后做量化。量化把FP32权重压缩到INT8甚至INT4模型体积能缩小到原来的四分之一到八分之一推理速度也有明显提升。代价是精度损失但对于很多任务来说INT8量化的精度下降在可接受范围内。我一般会走这个流程先在服务端用训练框架导出ONNX然后用ONNX Runtime的量化工具做动态量化或静态量化再根据目标设备做算子兼容性检查最后用ONNX Runtime Web加载测试。每一步都有坑比如某些算子量化后不支持、某些设备上INT8反而比FP32慢因为缺少对应的硬件加速指令。模型选择上端侧优先考虑小参数量的模型。蒸馏过的小模型、专门为端侧设计的轻量架构往往比强行压缩大模型效果更好。我试过把一个基础模型蒸馏到原来三分之一参数量在摘要任务上效果只掉了不到两个百分点但推理速度快了三倍多。4. 从零搭一个端侧推理Demo完整步骤与踩坑记录4.1 环境准备与依赖选择先明确目标在浏览器里加载一个量化后的文本分类模型输入一段文字输出类别和置信度。技术栈选ONNX Runtime Web因为它对WebGPU和WASM的支持都比较成熟文档也相对完整。项目初始化用Vite构建快对WASM资源处理也方便。安装依赖npm create vitelatest edge-ai-demo -- --template vanilla cd edge-ai-demo npm install onnxruntime-webONNX Runtime Web的WASM文件需要作为静态资源提供。Vite里可以把node_modules/onnxruntime-web/dist下的.wasm文件复制到public目录或者用插件处理。我一开始没注意这个运行时一直报找不到wasm文件排查了半天。4.2 模型导出与量化实操假设你有一个训练好的文本分类模型先导出ONNXimport torch from transformers import AutoModelForSequenceClassification, AutoTokenizer model AutoModelForSequenceClassification.from_pretrained(your-model) tokenizer AutoTokenizer.from_pretrained(your-model) dummy_input tokenizer(测试文本, return_tensorspt) torch.onnx.export( model, (dummy_input[input_ids], dummy_input[attention_mask]), model.onnx, input_names[input_ids, attention_mask], output_names[logits], dynamic_axes{ input_ids: {0: batch, 1: sequence}, attention_mask: {0: batch, 1: sequence}, logits: {0: batch} }, opset_version14 )然后做动态量化from onnxruntime.quantization import quantize_dynamic, QuantType quantize_dynamic( model.onnx, model_quantized.onnx, weight_typeQuantType.QUInt8 )量化后模型体积通常能降到原来的四分之一左右。但要注意动态量化对某些算子支持不好导出后需要用ONNX Runtime加载验证一遍确保推理结果和原模型差异在可接受范围。4.3 浏览器端加载与推理代码核心加载逻辑大概长这样import * as ort from onnxruntime-web; async function initModel() { ort.env.wasm.wasmPaths /ort-wasm/; ort.env.wasm.numThreads navigator.hardwareConcurrency 4 ? 4 : 2; const session await ort.InferenceSession.create(/models/model_quantized.onnx, { executionProviders: [webgpu, wasm], graphOptimizationLevel: all }); return session; } async function predict(session, inputIds, attentionMask) { const feeds { input_ids: new ort.Tensor(int64, BigInt64Array.from(inputIds), [1, inputIds.length]), attention_mask: new ort.Tensor(int64, BigInt64Array.from(attentionMask), [1, attentionMask.length]) }; const results await session.run(feeds); return results.logits.data; }这里有几个细节值得说。executionProviders数组的顺序决定了优先级WebGPU在前不支持时自动回退到WASM。numThreads不要设太大超过物理核心数反而会因为线程调度开销变慢。输入张量的类型要和模型导出时一致int64对应BigInt64Array这个类型转换容易出错。4.4 首次加载体验优化模型文件通常有几MB到几十MB首次加载是体验瓶颈。我的做法是分两步页面加载时先初始化一个轻量占位等用户真正触发功能时再异步加载模型加载过程中显示进度条。进度条可以通过fetch的ReadableStream读取Content-Length来实现async function loadModelWithProgress(url, onProgress) { const response await fetch(url); const contentLength response.headers.get(Content-Length); const reader response.body.getReader(); const chunks []; let received 0; while (true) { const { done, value } await reader.read(); if (done) break; chunks.push(value); received value.length; onProgress(received / contentLength); } const blob new Blob(chunks); return await blob.arrayBuffer(); }拿到ArrayBuffer后传给ort.InferenceSession.create避免二次请求。这个优化让用户至少知道在等什么而不是面对一个卡住的界面。5. 性能调优让端侧推理真正可用5.1 首屏加载时间的压缩策略模型加载时间是端侧体验的第一道坎。除了进度条还有几个手段可以压缩感知等待。模型分片加载。把模型按层拆成多个文件先加载前几层让用户能开始交互后续层在后台继续加载。这个方案实现复杂度较高适合对首屏时间极度敏感的场景。缓存策略。用Cache API或者IndexedDB把模型文件缓存到本地第二次访问直接读缓存。Cache API更适合大文件浏览器会自动管理存储空间。注意缓存失效策略模型更新后要能正确刷新。CDN和压缩。模型文件走CDN分发开启Brotli或Gzip压缩。ONNX文件本身是二进制压缩率有限但配合量化后的体积传输量还是能控制住。5.2 推理速度的实测调优推理速度受多个因素影响我按影响程度排序执行后端WebGPU vs WASM、模型量化程度、输入长度、线程数配置。WebGPU的加速效果最明显但要注意首次推理会有着色器编译开销可能比后续推理慢好几倍。可以在初始化后跑一次预热推理把编译开销提前消化掉。输入长度对Transformer类模型影响很大因为注意力计算是序列长度的平方级。端侧场景下要严格控制输入长度超过模型最大长度的部分截断或者用滑动窗口分段处理。滑动窗口的思路是把长文本切成有重叠的片段分别推理后合并结果虽然会增加总计算量但避免了单次推理超长序列导致的内存爆炸。线程数配置前面提过不是越多越好。我实测下来4核设备设2到3个线程比较合适8核以上设4个线程再往上收益递减。5.3 内存占用与垃圾回收端侧推理的内存管理容易被忽视。每次推理都会创建新的Tensor如果不及时释放内存会持续增长最终导致页面崩溃。ONNX Runtime Web的Tensor在JavaScript垃圾回收时释放但GC时机不确定。对于高频推理场景建议复用输入输出缓冲区减少分配次数。另外推理完成后主动把不再使用的Tensor引用置空帮助GC识别。在移动设备上内存限制更严格。我遇到过在部分手机上推理几次后页面被系统回收的情况。应对办法是控制并发推理数量同一时间只跑一个推理任务用队列串行化。6. 兼容性与降级不是所有浏览器都能跑6.1 能力检测的正确姿势不能假设用户浏览器支持WebGPU。加载模型前先做能力检测async function checkCapabilities() { const caps { webgpu: false, wasm: typeof WebAssembly object, simd: false, threads: false }; if (gpu in navigator) { try { const adapter await navigator.gpu.requestAdapter(); caps.webgpu !!adapter; } catch (e) { caps.webgpu false; } } // 检测WASM SIMD try { const simdTest new Uint8Array([ 0, 97, 115, 109, 1, 0, 0, 0, 1, 5, 1, 96, 0, 1, 123, 3, 2, 1, 0, 10, 10, 1, 8, 0, 65, 0, 253, 15, 253, 98, 11 ]); caps.simd WebAssembly.validate(simdTest); } catch (e) { caps.simd false; } caps.threads typeof SharedArrayBuffer ! undefined; return caps; }根据检测结果选择执行后端和模型版本。WebGPU可用就用WebGPU否则用WASM。WASM SIMD可用就用SIMD版本否则用普通版本。6.2 多线程的部署陷阱WASM多线程依赖SharedArrayBuffer而SharedArrayBuffer要求页面处于跨源隔离状态。这意味着响应头必须包含Cross-Origin-Opener-Policy: same-origin Cross-Origin-Embedder-Policy: require-corp这两个头一加页面里所有跨源资源都必须带CORP头或者CORS配置否则加载失败。我当初加完这两个头页面里的第三方字体和图片全挂了排查了好久才定位到原因。如果不想处理这些复杂性可以放弃多线程用单线程WASM。速度慢一些但部署简单兼容性好。6.3 降级策略的设计完整的降级链路应该是WebGPU多线程 → WebGPU单线程 → WASM多线程 → WASM单线程 → 云端推理。每一级降级都要有明确的触发条件和用户提示。比如WebGPU初始化失败自动降级到WASM同时可以给用户一个不打扰的提示当前设备使用兼容模式运行。如果所有端侧方案都不可用再回退到云端接口。降级逻辑要提前测试不能等线上出问题才发现某条路径走不通。我一般会在开发阶段用浏览器开发者工具手动禁用WebGPU、禁用SharedArrayBuffer来模拟各种降级场景。7. 安全与隐私端侧推理的另一面7.1 数据不出本地的真实含义端侧推理最大的卖点之一是数据隐私。用户的输入不离开浏览器不经过网络传输理论上服务端完全接触不到原始数据。这对于处理敏感信息的场景非常有价值。但数据不出本地不等于绝对安全。模型本身是下载到本地的如果模型包含敏感信息比如训练数据泄露端侧反而扩大了暴露面。另外浏览器环境本身的安全边界也需要考虑比如恶意扩展能否读取推理过程中的数据。我的做法是端侧只处理脱敏后的数据或者只做特征提取这类不涉及原始内容外泄的操作。真正敏感的原始数据要么在端侧完成全部处理且不上传要么走加密通道到云端处理。7.2 模型保护与防逆向端侧模型是公开可下载的任何人都能拿到模型文件。如果你的模型是核心资产端侧部署意味着放弃模型保密性。量化后的模型虽然可读性降低但逆向工程并非不可能。如果模型保密是硬需求端侧方案可能不适合或者需要配合模型加密、运行时解密等额外手段。但这些手段在浏览器环境下效果有限因为解密逻辑最终也要在客户端执行。7.3 推理结果的完整性端侧推理的结果由客户端产生服务端无法直接验证其正确性。如果业务逻辑依赖推理结果做决策需要考虑客户端篡改的风险。应对方式包括关键决策仍在服务端复核、端侧结果只作为辅助、或者对结果做签名校验。8. 混合架构端云协同的工程实践8.1 什么放端侧什么放云端经过几个项目的摸索我总结了一个简单的判断框架维度倾向端侧倾向云端调用频次高频低频模型大小小20MB大延迟要求极低可接受网络延迟隐私要求高一般一致性要求低高设备分布集中且较新分散且老旧实际项目中往往是同一个功能的不同环节分别部署。比如文档处理端侧做初步的敏感信息识别和脱敏云端做深度分析和生成。端侧先过滤掉明显不需要上传的内容减少云端调用量和数据传输量。8.2 端云之间的任务编排混合架构的难点在于任务编排。哪些步骤在端侧做哪些在云端做顺序和依赖关系怎么设计失败怎么重试这些都需要仔细规划。我的做法是用一个状态机管理整个流程。每个步骤有明确的输入输出和执行位置。端侧步骤失败可以降级到云端云端步骤失败可以重试或提示用户。状态机的好处是流程可视化排查问题方便。8.3 版本管理与灰度端侧模型更新是个麻烦事。用户不刷新页面就不会加载新模型导致版本碎片化。应对策略包括模型文件带版本号加载时检查版本服务端接口兼容多个模型版本新模型先小流量灰度观察效果后再全量。云端模型更新相对简单但也要注意端云接口的兼容性。端侧旧版本可能调用云端新接口字段增减要做好向后兼容。9. 几个真实项目的复盘9.1 文档摘要项目端侧做初筛云端做精炼这个项目最终采用的方案是端侧加载一个轻量模型做段落级的重要性打分把得分高的段落上传云端做精细摘要。端侧模型只有8MB加载快推理一次不到200ms。云端调用量因此减少了约60%成本明显下降同时摘要质量没有明显损失。踩过的坑端侧打分和云端摘要的粒度不一致导致有些重要信息在初筛阶段被漏掉。后来调整了打分策略提高了召回率宁可多传一些也不能漏。9.2 实时翻译项目纯端侧方案这个项目对延迟极度敏感要求输入后立刻出结果。云端往返哪怕只有几百毫秒也无法接受。最终选了纯端侧方案模型量化到12MBWebGPU推理单次约150ms。首次加载有等待但后续交互非常流畅。踩过的坑移动端WebGPU支持不稳定部分机型上推理结果异常。最后在移动端强制走WASM虽然慢一些但结果可靠。9.3 内容审核项目端侧预处理加云端复核审核场景对准确性要求高纯端侧不可靠。方案是端侧先做一轮快速过滤明显合规的内容直接放行可疑内容上传云端复核。端侧模型负责召回云端模型负责精确判断。踩过的坑端侧过滤的阈值很难调。太松了云端压力大太紧了漏放违规内容。最后用线上数据反复调整找到了一个平衡点。10. 我踩过的那些坑和对应的解法第一个坑是SharedArrayBuffer的跨源隔离配置。前面提过加完COOP和COEP头之后页面里所有跨源资源都要处理。我的建议是如果项目里跨源资源多慎重启用多线程或者把所有资源都收拢到同源下。第二个坑是模型量化后的精度骤降。动态量化对某些模型效果影响很大尤其是输出层。解决办法是只量化中间层保留输入输出层为FP32或者改用静态量化并做校准。第三个坑是WebGPU的显存泄漏。反复创建和销毁Session会导致显存不释放最终推理失败。解决办法是复用Session不要频繁创建。如果必须重建确保旧Session被正确销毁。第四个坑是移动端浏览器的内存限制。iOS上尤其严格页面内存超过一定阈值直接被回收。应对方式是控制模型大小、减少并发、及时释放不用的资源。第五个坑是模型加载的缓存失效。用户更新了模型文件但浏览器还在用旧缓存导致行为不一致。解决办法是模型URL带hash文件内容变化时URL变化强制刷新缓存。11. 端侧AI在浏览器里的下一步WebGPU的普及会继续扩大端侧推理的可行范围。随着浏览器厂商持续优化能跑的模型会越来越大速度会越来越快。同时专门为端侧设计的模型架构也在涌现在保持效果的前提下大幅压缩参数量和计算量。工具链方面ONNX Runtime Web、Transformers.js这些库在快速迭代算子覆盖和性能都在改善。未来端侧和云端的边界会更模糊开发者可以根据实时条件动态决定推理位置而不是在开发阶段就写死。但无论技术怎么发展核心判断逻辑不会变端侧适合高频、轻量、隐私敏感的场景云端适合重载、需要集中管控的场景。混合架构是常态关键是找到适合自己业务的分界线。我在实际项目里的体会是不要为了端侧而端侧。先算清楚成本账再评估技术可行性最后小范围验证。端侧推理能省的钱是真实的但省钱的代价是工程复杂度的上升。这个 trade-off 需要根据团队能力和业务阶段来权衡。