最近后台被问得最多的一个问题就是“把AI功能塞进用户浏览器里跑是不是就不用买那么贵的GPU服务器了”。这个问题看起来是个成本问题实际上是个架构问题甚至可以说是“成本幻觉”问题。我过去一年正好负责过一版端侧推理的上线全流程今天把这笔账掰开揉碎讲清楚。先说结论浏览器里跑AI确实能省下一部分服务器推理开销但省下来的钱远没有你想象得那么多且会以另一种方式转变成人力成本、兼容性成本和体验成本。这篇文章不吹不黑只讲实操层面到底怎么算这笔账、怎么选架构、怎么避坑。1. 先把“浏览器里跑AI”这件事说清楚1.1 浏览器不是AppAI在浏览器里靠什么跑很多人一听到“浏览器里跑AI”第一反应是“那不就是网页版ChatGPT吗”。这完全是两回事。网页版ChatGPT的本质是“浏览器作为输入框”模型推理发生在云端的GPU集群上浏览器只是把文本发出去、把结果收回来。真正意义上的浏览器端AI是指模型权重文件直接被下载到用户本地推理计算全程在用户的CPU或GPU上完成请求根本不出浏览器。这个能力在过去几年才真正具备落地条件。早几年大家也想过这件事但浏览器里的JavaScript性能太拉胯跑个几MB的小模型都卡成幻灯片。现在局面完全变了三条技术路径把障碍基本扫平一是WebGPU。这是浏览器释放GPU算力的标准接口类似网页版的CUDA。有了它浏览器可以把计算任务调度到用户显卡上做并行计算深度学习里的矩阵乘法正好是GPU的强项。二是WebAssemblyWASM。如果用户电脑没有独立显卡或者浏览器不支持WebGPU那就退回到CPU路线。WASM可以以接近原生的速度执行C、Rust编译出来的代码配合SIMD指令集CPU上跑一个量化后的小模型也不算太难。三是模型量化生态。这是个关键推手。原本7B参数的模型FP16精度要占用14GB显存处理到4bit量化之后只要4GB左右压缩到1~2GB甚至能塞进高端手机。模型变小了、内存需求降低了浏览器端的推理才从“理论可行”变成“用户可以接受”。我实际用的组合是Transformers.js配合ONNX Runtime Web底层走WebGPU。选这套方案的直接原因是模型生态最全Hugging Face上大量模型可以直接转成ONNX格式前端工程师不需要额外懂CUDA直接用npm包就能接上。1.2 和“前端调用API”的本质区别要理解浏览器端AI的价值必须先分清两种架构的边界。传统的前端调API模式浏览器只负责发请求服务器负责推理返回结果。整个链路是浏览器 - 网关 - 模型服务 - 推理结果 - 返回。每一次用户提问都意味着一次网络传输、一次GPU占用、一次推理计费。浏览器本地推理的链路则完全不同模型在页面初始化时加载一次之后所有推理都在本地完成。用户提问时不需要把内容上传到服务器模型在浏览器里直接输出结果。这意味着三件大事发生了改变第一是计算位置从云端挪到了客户端云端GPU不再承担推理负载或者说承担的比例大幅下降。第二是数据隐私有了本质提升用户的文本、图片不需要离开设备就能完成处理这在法律合规层面很有价值尤其是涉及医疗、金融、企业内部资料的场景。第三是服务的边际成本趋近于零。服务器推理模式下每多一个用户都在消耗GPU资源和电力浏览器推理模式下用户的设备在烧用户自己的算力服务方多服务一百万个用户也不会多付一分钱GPU账单。这三点听起来很美好但别忘了每一枚硬币的反面都有成本。后面我会专门讲哪些成本被隐藏了。2. 成本账要这么算才对2.1 真金白银省下来的部分先算看得见的钱这部分确实值得算。我以当时项目里的一个真实场景为例一个内容网站需要给每篇文章生成摘要模型不大7B量级的量化模型云端推理单次请求的平均成本大约是0.003美元。听起来不贵但日活5万用户、每天人均触发10次摘要一天就是500万次请求光推理成本就是1.5万美元一天一个月就是45万美元。这还没算GPU服务器的固定租金和运维人力。在这种量级面前把推理完全搬到浏览器端服务器GPU成本和推理计费成本直接降到几乎为零这部分的节省是真金白银。带宽成本是另一块肉眼可见的降幅。云端推理模式下每次请求都要上传用户输入、下载模型输出Token越多带宽消耗越大。浏览器推理模式下正常的业务请求不需要传整段文本给服务器只需要在页面初始化时加载一次模型文件。模型文件是一次性的之后的所有交互都在本地。我们的CDN账单在切换架构之后的三个月里下降了60%以上这还是在模型加载本身的流量也算进去的情况下。还有一块不容易察觉但很重要的节省是扩容成本。云端推理模型有个特点用户的访问往往是集束式的某个话题爆了大家同一时间涌入GPU集群压力骤增。传统方案必须按峰值流量扩容而峰值流量往往只有平峰流量的三到五倍。浏览器推理模式在理论上天然“无限扩容”用户访问越多消耗的是用户自己的设备算力而不是你的集群算力。我们那版架构上线后服务器集群从12台缩到了4台缩下来的8台机器每个月省下的成本非常可观。2.2 容易被忽略的反向成本既然有省钱的一面就一定有花钱的另一面。这里必须说清楚浏览器推理不是“一次部署永远免费”它只是把成本账从“服务器账单”挪到了别处。最直接的隐藏成本是模型下载流量。7B量化模型的文件大小普遍在3.5GB到4.5GB之间即使是2B量级的模型也有1.2GB左右。用户首次访问时浏览器需要把这个文件全部下载下来。如果网站日活是5万人每个用户一次全量下载一个月光模型文件的CDN流量就是5万乘以4GB再乘以30天算下来是600万GB折合CDN费用接近百万元。这个数字一出来很多人就清醒了原来省下的GPU推理成本有一部分被CDN流量吃回去了。要想降低这部分流量实际操作中只有两个方向。一个是把模型做小你硬把7B压缩到2BCDN流量减半但生成质量也会同步下降。另一个是提示用户“预加载”但用户到底什么时候会进入相关功能页面根本不可控。我见过的团队有一种比较务实的做法只在用户明确点击“AI功能”按钮时才触发模型下载不做全站预加载这能把模型下载量和服务器成本消耗的时间错开用户主体留存率高的场景尤其适用。第二个隐藏成本是兼容性测试的人力投入。你在自己的开发机上跑得再顺用户手里的设备五花八门Windows Chrome、macOS Safari、手机 微信内置浏览器、老款Android 国产WebView。WebGPU的支持范围在不同浏览器、不同版本、不同操作系统上参差不齐。我整理过一份兼容性矩阵光是“WebGPU可用但性能极差”和“WebGPU不可用自动降级到WASM”这两条分支就带来了几十种组合每一种都要测、要调、要出对应的降级方案。第三个隐藏成本是模型迭代和发布流程。云端模型更新只需要替换服务器上的权重文件而浏览器端模型更新意味着每个用户都要重新下载新文件这不仅是流量成本的问题还有“旧版本模型在线上残存多久”的问题。我们项目踩过这个坑模型从版本A迭代到版本B之后老用户页面还在用旧模型新旧模型生成结果不一致用户侧就出现了“同样的页面为什么回答不一样”的投诉。后来我们不得不在前端加版本号检测和强制刷新逻辑这又是一块人力成本。2.3 什么场景端侧推理真正划算讲到这里可以给一个范围性的判断了。我自己的经验是端侧推理在两类场景下特别划算在三类场景下反而得不偿失。特别划算的第一类是“高频、轻量、对延迟敏感”的任务。典型代表是文本分类、情感分析、敏感词过滤、语音活动检测。这类任务模型不大几百MB就够推理速度快用户本地跑几乎没有感知成本。一旦高频调用云端成本就积累起来了搬去端侧能省一大笔。特别划算的第二类是“数据敏感、合规要求高”的任务。比如医疗问答的初筛、企业内部文档的检索摘要、法律文书的关键词抽取。这些场景数据不能出本机端侧推理是唯一的合理方案这时候算的不是“省了多少钱”而是“这个业务不这样没法做”。三类不该做端侧的场景我对号入座一下第一是模型非常大、效果要求非常高的场景比如用70B量级模型做深度对话塞进浏览器就是不现实。第二是推理结果需要强一致性的场景比如金融利率计算、电商价格判断不同用户设备上跑出不同结果业务上接受不了。第三是低端设备用户比例很高的场景两端用户的手机或电脑太老模型都加载不动硬推端侧只会爽了服务器、坑了用户。我做一个总结性对比方便直接抄走成本项云端推理浏览器端推理GPU服务器/推理计费高按调用量线性增长几乎为零带宽与CDN流量每次请求都有量级为Token数模型文件一次性大流量下载扩容压力按峰值流量预留天然分布式无峰值瓶颈研发人力主要集中在服务端前端/客户端复杂度上升兼容性测试环境可控测试成本低设备碎片化测试矩阵庞大模型更新替换文件即可需要用户重下模型有版本残留问题数据隐私数据上云数据留在本地结论一句话端侧推理适合算力相对充足、任务相对轻量、数据敏感度高的场景那些看起来“模型很酷”的重型AI功能还是老老实实放云端。3. 性能、兼容性、体验三座大山3.1 用户设备根本不是你的开发机做端侧AI最容易犯的一个错误是用自己工作机的性能来评估用户体验。我踩过的坑让我后来养成了一个习惯性能基准测试必须在三台机器上跑——一台配备RTX 4090的旗舰机、一台集成显卡的普通笔记本、一台三年前的入门级Android手机。旗舰机上跑7B量化模型生成速度能到每秒30到50个Token体感跟云端几乎没差。普通笔记本上速度掉到每秒5到10个Token用户普遍能感觉到“在思考”但还能接受。入门级手机上跑同样一个模型速度会掉到每秒1到3个Token而且生成过程中整机发烫、内存告急后台应用被杀了一大片。这时候用户唯一的感受就是这个网页又烫又卡。我在验收阶段要求团队在测试机上跑一遍完整链路生成一段50个中文字符的回答时间超过20秒就直接判定为不合格。这个标准在开发机上可能显得苛刻但放到真实用户环境里一点都不算夸张。端侧推理的实际可用性不是看模型理论上能跑多快而是看最慢的那批用户手里的设备能不能忍受。内存是另一个隐形的性能瓶颈。7B量化模型即使压到4bit运行时的内存占用依然在4GB以上加上浏览器本身的2到3GB基础占用一台内存只有8GB的老电脑很容易被吃满。我建议在代码里做一个简单的“门槛判断”用navigator.deviceMemory属性读出设备内存低于一个阈值就直接走云端路径不启动端侧推理。这个API虽然在某些浏览器里不可用但可用的情况下判断很准值得加。3.2 加载时间和模型体积的较量模型文件下载是端侧推理的第一个用户体验节点也是劝退节点。我做过数据统计模型超过2GB时用户点击AI功能后等待完成的流失率达到60%以上。这不是模型能力的问题是加载体验的问题。技术上能做的优化是分片加载。ONNX Runtime和WebLLM都支持分片拉取模型不需要等整个文件下载完才开始推理。用户点进页面先拉第一个分片跑一个轻量的启动任务让用户感觉到页面“活”了后面的分片在后台继续加载。这套“先可用后完整”的策略实际转化率比“等全部加载完再启用”高出不少。第二个优化是浏览器缓存策略。模型文件本身的特征是不会频繁变化非常适合Cache-Control缓存头加长缓存周期。我们当时把模型文件缓存时间设成了7天配合Service Worker做版本管理老用户第二次进入页面几乎不需要重新下载启动时间从半分钟缩短到几秒。这一块的优化成本很低但收益非常直观。还有一个容易忽略的细节是CDN节点覆盖。模型文件是GB级别的大文件如果CDN节点离用户远下载速度会非常难看。选择CDN厂商时一定要看节点覆盖情况尤其是三四线城市和运营商线路的覆盖。我们都遇到过模型文件在“下载99%”卡住半天的用户这在弱网环境下是个真实存在的大坑解决办法只能是把下载逻辑写得足够健壮支持断点续传和重试机制。3.3 跨浏览器适配是硬仗端侧AI碰上浏览器兼容性属于“两个麻烦的叠加体”。不同浏览器的WebGPU实现进度不同、性能表现也完全不同。我在项目里维护了一份浏览器兼容矩阵核心信息整理如下浏览器WebGPU支持情况WASM推理可用性实测建议Chrome / Edge支持性能最好支持主力目标环境Firefox需开启功能标志默认不稳定支持建议降级到WASMSafari 17部分支持性能一般支持建议降级到WASM微信内置浏览器不支持部分支持性能较差直接走云端回退国产浏览器WebView视版本而定普遍不支持部分支持如条件允许引导用系统浏览器打开这份矩阵带来的开发工作量比想象的更大。你不能只写一套推理逻辑要写三套WebGPU路径、WASM路径、云端API路径然后根据运行时能力探测选择走哪条路。能力探测的关键是写一段“起步测试”不只看navigator.gpu是否存在还要真的初始化一个小的计算任务跑通了才认为可用。有些浏览器里WebGPU接口存在但底层驱动异常直接调用会崩溃这种坑只能靠实际跑一次才能发现。我见过不下三个项目折在兼容性上原因是只在Chrome上做了完整测试上线之后大批Safari和Firefox用户反馈功能不可用。所以如果你想做端侧AI先问自己一个问题我的团队有没有足够的精力维护一套跨浏览器、跨设备的兼容逻辑和降级矩阵如果没有那就不适合做全量端侧推理只能做成“部分用户可用的增强功能”。4. 合理架构混合推理与降级策略4.1 先做“简单任务不麻烦模型”在真正上端侧模型之前有个性价比极高的步骤把业务里不需要大模型的部分全部过滤掉。我们做内容摘要功能的时候发现用户提交的文章里有一大部分内容长度很短、结构已经接近摘要格式直接抽取前几句话就能用。这一部分请求根本不需要走大模型不需要云端更不需要端侧用正则和关键词规则就能完成。等把这些简单请求过滤光了真正需要模型参与的比例下降了40%以上。类似的做法还有“意图分级”。用户输入先走一个本地极小的分类模型只有几十MB判断这个请求是否需要大模型理解。简单指令直接规则处理复杂请求才进入推理链路。这种分层设计的思路和Java后端里“先查缓存再查数据库”的逻辑一脉相承——能便宜完成的请求绝对不调贵的资源。4.2 端侧和云端的任务划分标准真正到混合推理架构设计的时候我遵循的判断标准只有四条逐一过一遍就知道该把任务放哪边第一延迟要求。端侧模型的推理速度和设备性能强相关如果产品需求是“响应时间低于1秒”端侧未必靠谱。模型要经过用户设备下载、加载、推理整体链路的不确定性太多。云端的P95稳定在一秒内是完全做得到的端侧的P95大概率不稳定。第二数据敏感性。数据如果完全不能出浏览器那没什么好犹豫的端侧是唯一选择。如果数据脱敏后可以上云则可以从成本角度更自由地选择两端。第三模型的体量和生成质量要求。涉及长文本创作、复杂推理、需要最新知识召回的任务目前端侧模型的能力还不够硬放端侧就是在用户体验上自找麻烦。简单的分类、抽取、改写端侧模型完全够用。第四任务频率。一天的调用量如果几十万次以上端侧的价值开始显现如果一天只有几千次云端的几千次调用成本几乎可以忽略完全没必要增加端侧的研发维护成本。最终我们线上的任务分配是简单分类用正则和规则中等复杂度任务走端侧量化模型高复杂度任务走云端。这个三分法的核心思想是“成本与能力相匹配”而不是一刀切全部端侧或者全部云端。4.3 降级与兜底设计降级策略是我认为整个体系里最不能省的一环。浏览器端推理的失败率远比大部分人想象的高。WebGPU初始化失败会崩内存不足会崩模型文件损坏会崩用户设备驱动过老也会崩。你不能在用户面前只说一句“本地AI引擎启动失败”必须有一个兜底方案。我们的降级链路设计如下首先尝试WebGPU如果WebGPU不可用或者初始化失败自动降级到WASM路径。以我们实际生产数据来看WebGPU可用率在桌面端约70%手机端更低WASM路径则几乎100%兼容。这一步能兜住大部分用户。如果WASM也失败或者用户设备内存过低则自动改为请求云端API把推理任务转给服务器。云端API的调用本身我们设置了频率限制和预算控制避免在极端情况下云端成本反弹过猛。降级逻辑的测试用例要覆盖全面。我当时在验收清单里专门有一项“逐项禁用能力测试”手动在浏览器DevTools里模拟禁用WebGPU、禁用WASM、模拟内存过低验证每一步都能正确降级且用户能收到友好提示。这些测试看起来繁琐但真正上线之后几乎每一天都会有用户因为各种诡异的设备状态触发降级没有这套兜底预案就只能对着用户工单发呆。补充一点提示任何降级方案都要记录埋点和日志。不管走的是端侧还是云端路径、耗时、设备型号、模型版本这些信息必须上报。没有数据支撑你根本不知道真实用户里有多少比例能成功走完端侧推理也不知道云端的备用预算需要在哪个时间点预留。5. 实际项目中的常见坑与排查5.1 常见问题速查表整理了上线半年来用户反馈和高频工单中反复出现的问题汇总在这张表里可以直接当作排查手册用现象可能原因排查步骤解决方案模型一直在加载进度条不动CDN节点慢或模型文件缺失看Network请求确认HTTP状态码换CDN节点配置断点续传模型加载完成后页面卡死内存不足浏览器被杀查设备内存看日志有没有OOM增加内存门槛判断低内存走云端WebGPU初始化失败浏览器版本过旧或驱动问题抛错时捕获navigator.gpu自动降级到WASM推理速度极慢设备太老或模型过大打印GPU设备信息检测生成速度换更小模型或直接云端输出结果乱码INT4量化精度损失导致输出质量异常检查tokenizer是否与模型匹配重新对齐tokenizer必要时退回INT8部分用户永远走云端路径能力探测逻辑误判查看探测日志确认WebGPU初始化返回值修探测逻辑降低误判率新旧模型输出结果不一致版本残留检查Service Worker缓存强制版本失效并触发重新下载同一请求在不同浏览器结果不同量化模型的浮点计算存在微差异对比输出日志对关键业务做“云端结果为准”的修正逻辑5.2 三个让我印象深刻的线上事故第一个事故发生在刚上线时Windows用户普遍反馈AI功能无法使用。我们开发测试时用的是Chrome没问题。排查之后发现很多Windows用户在使用Edge浏览器而Edge的WebGPU初始化在某些版本上会静默失败不抛错只是功能不工作。我们后来加了“启动即跑一个小矩阵乘法”的探测任务确保功能真正可用才展示AI入口。第二个事故是模型文件更新引起的。我们在后台更新了新版本的量化模型老用户的浏览器缓存里还留着旧模型文件出现了同一个摘要请求在不同用户设备上输出不同风格内容的情况。这次之后我在模型文件URL里强制加入版本号更新版本时自动生成新的URL彻底切断缓存复用。第三个事故发生在低端Android设备上。用户反馈手机运行AI功能时发热严重甚至有两台手机因此重启。这个问题本质上是WebGPU在大规模并行计算时对移动设备的功耗冲击太大。最终的解决办法是移动端默认走WASM和更小的模型只有桌面端才启用WebGPU。这个策略虽然损失了部分移动端性能但换来了稳定性和设备安全性值得。5.3 一些让项目“不炸”的心得在踩过上面这些坑之后我给自己列了几条做事原则也一并分享出来。第一永远不要在用户路径上一开始就加载模型。先让用户看到产品本身模型下载放到后台或者用户点击AI功能之后再触发。这能把模型加载失败对留存的影响降到最低。第二给所有端侧模型相关的成本项加上监控面板。除了服务器QPS和延迟之外端侧模型还要加“模型下载成功率”“WebGPU可用率”“推理平均耗时”“降级比例”四个指标。没有这些指标任何问题排查都是盲人摸象。第三对端侧模型的能力边界要诚实。7B模型再量化也只是7B不是70B。如果业务的AI功能需要的是顶级的推理能力那就直接上云端大模型别硬塞进浏览器里做个“能做但做得不好”的版本。端侧AI的定位应该是“够用且便宜”而不是“最强且万能”。最后再分享一点基于实操的判断我个人在实际操作中的体会是浏览器里跑AI这件事的真实价值不在“省了GPU的钱”而在“逼着你把业务里的任务按复杂度重新分了一遍级”。这一遍分级做完你会发现很多请求根本不需要AI有些请求只需要小模型真正需要大模型的其实没那么多。这种架构梳理带来的长期收益往往比省下的服务器成本更大。如果你正在评估要不要做端侧推理我建议先小范围试一个功能挑一个高频、轻量、低风险的任务把端侧路径做出来跑一版灰度盯着降级比例和用户反馈。等数据给出了“端侧可用性真的能打”的信号再扩大到更多场景。这条路不是不能走但别指望零成本走通该踩的坑一个都不会少。 
长河君 · 2026/10/31 8:26:12 · 阅读 1.2k 浏览器跑AI真能省钱？端侧推理成本与混合架构深度剖析
最近后台被问得最多的一个问题就是“把AI功能塞进用户浏览器里跑是不是就不用买那么贵的GPU服务器了”。这个问题看起来是个成本问题实际上是个架构问题甚至可以说是“成本幻觉”问题。我过去一年正好负责过一版端侧推理的上线全流程今天把这笔账掰开揉碎讲清楚。先说结论浏览器里跑AI确实能省下一部分服务器推理开销但省下来的钱远没有你想象得那么多且会以另一种方式转变成人力成本、兼容性成本和体验成本。这篇文章不吹不黑只讲实操层面到底怎么算这笔账、怎么选架构、怎么避坑。1. 先把“浏览器里跑AI”这件事说清楚1.1 浏览器不是AppAI在浏览器里靠什么跑很多人一听到“浏览器里跑AI”第一反应是“那不就是网页版ChatGPT吗”。这完全是两回事。网页版ChatGPT的本质是“浏览器作为输入框”模型推理发生在云端的GPU集群上浏览器只是把文本发出去、把结果收回来。真正意义上的浏览器端AI是指模型权重文件直接被下载到用户本地推理计算全程在用户的CPU或GPU上完成请求根本不出浏览器。这个能力在过去几年才真正具备落地条件。早几年大家也想过这件事但浏览器里的JavaScript性能太拉胯跑个几MB的小模型都卡成幻灯片。现在局面完全变了三条技术路径把障碍基本扫平一是WebGPU。这是浏览器释放GPU算力的标准接口类似网页版的CUDA。有了它浏览器可以把计算任务调度到用户显卡上做并行计算深度学习里的矩阵乘法正好是GPU的强项。二是WebAssemblyWASM。如果用户电脑没有独立显卡或者浏览器不支持WebGPU那就退回到CPU路线。WASM可以以接近原生的速度执行C、Rust编译出来的代码配合SIMD指令集CPU上跑一个量化后的小模型也不算太难。三是模型量化生态。这是个关键推手。原本7B参数的模型FP16精度要占用14GB显存处理到4bit量化之后只要4GB左右压缩到1~2GB甚至能塞进高端手机。模型变小了、内存需求降低了浏览器端的推理才从“理论可行”变成“用户可以接受”。我实际用的组合是Transformers.js配合ONNX Runtime Web底层走WebGPU。选这套方案的直接原因是模型生态最全Hugging Face上大量模型可以直接转成ONNX格式前端工程师不需要额外懂CUDA直接用npm包就能接上。1.2 和“前端调用API”的本质区别要理解浏览器端AI的价值必须先分清两种架构的边界。传统的前端调API模式浏览器只负责发请求服务器负责推理返回结果。整个链路是浏览器 - 网关 - 模型服务 - 推理结果 - 返回。每一次用户提问都意味着一次网络传输、一次GPU占用、一次推理计费。浏览器本地推理的链路则完全不同模型在页面初始化时加载一次之后所有推理都在本地完成。用户提问时不需要把内容上传到服务器模型在浏览器里直接输出结果。这意味着三件大事发生了改变第一是计算位置从云端挪到了客户端云端GPU不再承担推理负载或者说承担的比例大幅下降。第二是数据隐私有了本质提升用户的文本、图片不需要离开设备就能完成处理这在法律合规层面很有价值尤其是涉及医疗、金融、企业内部资料的场景。第三是服务的边际成本趋近于零。服务器推理模式下每多一个用户都在消耗GPU资源和电力浏览器推理模式下用户的设备在烧用户自己的算力服务方多服务一百万个用户也不会多付一分钱GPU账单。这三点听起来很美好但别忘了每一枚硬币的反面都有成本。后面我会专门讲哪些成本被隐藏了。2. 成本账要这么算才对2.1 真金白银省下来的部分先算看得见的钱这部分确实值得算。我以当时项目里的一个真实场景为例一个内容网站需要给每篇文章生成摘要模型不大7B量级的量化模型云端推理单次请求的平均成本大约是0.003美元。听起来不贵但日活5万用户、每天人均触发10次摘要一天就是500万次请求光推理成本就是1.5万美元一天一个月就是45万美元。这还没算GPU服务器的固定租金和运维人力。在这种量级面前把推理完全搬到浏览器端服务器GPU成本和推理计费成本直接降到几乎为零这部分的节省是真金白银。带宽成本是另一块肉眼可见的降幅。云端推理模式下每次请求都要上传用户输入、下载模型输出Token越多带宽消耗越大。浏览器推理模式下正常的业务请求不需要传整段文本给服务器只需要在页面初始化时加载一次模型文件。模型文件是一次性的之后的所有交互都在本地。我们的CDN账单在切换架构之后的三个月里下降了60%以上这还是在模型加载本身的流量也算进去的情况下。还有一块不容易察觉但很重要的节省是扩容成本。云端推理模型有个特点用户的访问往往是集束式的某个话题爆了大家同一时间涌入GPU集群压力骤增。传统方案必须按峰值流量扩容而峰值流量往往只有平峰流量的三到五倍。浏览器推理模式在理论上天然“无限扩容”用户访问越多消耗的是用户自己的设备算力而不是你的集群算力。我们那版架构上线后服务器集群从12台缩到了4台缩下来的8台机器每个月省下的成本非常可观。2.2 容易被忽略的反向成本既然有省钱的一面就一定有花钱的另一面。这里必须说清楚浏览器推理不是“一次部署永远免费”它只是把成本账从“服务器账单”挪到了别处。最直接的隐藏成本是模型下载流量。7B量化模型的文件大小普遍在3.5GB到4.5GB之间即使是2B量级的模型也有1.2GB左右。用户首次访问时浏览器需要把这个文件全部下载下来。如果网站日活是5万人每个用户一次全量下载一个月光模型文件的CDN流量就是5万乘以4GB再乘以30天算下来是600万GB折合CDN费用接近百万元。这个数字一出来很多人就清醒了原来省下的GPU推理成本有一部分被CDN流量吃回去了。要想降低这部分流量实际操作中只有两个方向。一个是把模型做小你硬把7B压缩到2BCDN流量减半但生成质量也会同步下降。另一个是提示用户“预加载”但用户到底什么时候会进入相关功能页面根本不可控。我见过的团队有一种比较务实的做法只在用户明确点击“AI功能”按钮时才触发模型下载不做全站预加载这能把模型下载量和服务器成本消耗的时间错开用户主体留存率高的场景尤其适用。第二个隐藏成本是兼容性测试的人力投入。你在自己的开发机上跑得再顺用户手里的设备五花八门Windows Chrome、macOS Safari、手机 微信内置浏览器、老款Android 国产WebView。WebGPU的支持范围在不同浏览器、不同版本、不同操作系统上参差不齐。我整理过一份兼容性矩阵光是“WebGPU可用但性能极差”和“WebGPU不可用自动降级到WASM”这两条分支就带来了几十种组合每一种都要测、要调、要出对应的降级方案。第三个隐藏成本是模型迭代和发布流程。云端模型更新只需要替换服务器上的权重文件而浏览器端模型更新意味着每个用户都要重新下载新文件这不仅是流量成本的问题还有“旧版本模型在线上残存多久”的问题。我们项目踩过这个坑模型从版本A迭代到版本B之后老用户页面还在用旧模型新旧模型生成结果不一致用户侧就出现了“同样的页面为什么回答不一样”的投诉。后来我们不得不在前端加版本号检测和强制刷新逻辑这又是一块人力成本。2.3 什么场景端侧推理真正划算讲到这里可以给一个范围性的判断了。我自己的经验是端侧推理在两类场景下特别划算在三类场景下反而得不偿失。特别划算的第一类是“高频、轻量、对延迟敏感”的任务。典型代表是文本分类、情感分析、敏感词过滤、语音活动检测。这类任务模型不大几百MB就够推理速度快用户本地跑几乎没有感知成本。一旦高频调用云端成本就积累起来了搬去端侧能省一大笔。特别划算的第二类是“数据敏感、合规要求高”的任务。比如医疗问答的初筛、企业内部文档的检索摘要、法律文书的关键词抽取。这些场景数据不能出本机端侧推理是唯一的合理方案这时候算的不是“省了多少钱”而是“这个业务不这样没法做”。三类不该做端侧的场景我对号入座一下第一是模型非常大、效果要求非常高的场景比如用70B量级模型做深度对话塞进浏览器就是不现实。第二是推理结果需要强一致性的场景比如金融利率计算、电商价格判断不同用户设备上跑出不同结果业务上接受不了。第三是低端设备用户比例很高的场景两端用户的手机或电脑太老模型都加载不动硬推端侧只会爽了服务器、坑了用户。我做一个总结性对比方便直接抄走成本项云端推理浏览器端推理GPU服务器/推理计费高按调用量线性增长几乎为零带宽与CDN流量每次请求都有量级为Token数模型文件一次性大流量下载扩容压力按峰值流量预留天然分布式无峰值瓶颈研发人力主要集中在服务端前端/客户端复杂度上升兼容性测试环境可控测试成本低设备碎片化测试矩阵庞大模型更新替换文件即可需要用户重下模型有版本残留问题数据隐私数据上云数据留在本地结论一句话端侧推理适合算力相对充足、任务相对轻量、数据敏感度高的场景那些看起来“模型很酷”的重型AI功能还是老老实实放云端。3. 性能、兼容性、体验三座大山3.1 用户设备根本不是你的开发机做端侧AI最容易犯的一个错误是用自己工作机的性能来评估用户体验。我踩过的坑让我后来养成了一个习惯性能基准测试必须在三台机器上跑——一台配备RTX 4090的旗舰机、一台集成显卡的普通笔记本、一台三年前的入门级Android手机。旗舰机上跑7B量化模型生成速度能到每秒30到50个Token体感跟云端几乎没差。普通笔记本上速度掉到每秒5到10个Token用户普遍能感觉到“在思考”但还能接受。入门级手机上跑同样一个模型速度会掉到每秒1到3个Token而且生成过程中整机发烫、内存告急后台应用被杀了一大片。这时候用户唯一的感受就是这个网页又烫又卡。我在验收阶段要求团队在测试机上跑一遍完整链路生成一段50个中文字符的回答时间超过20秒就直接判定为不合格。这个标准在开发机上可能显得苛刻但放到真实用户环境里一点都不算夸张。端侧推理的实际可用性不是看模型理论上能跑多快而是看最慢的那批用户手里的设备能不能忍受。内存是另一个隐形的性能瓶颈。7B量化模型即使压到4bit运行时的内存占用依然在4GB以上加上浏览器本身的2到3GB基础占用一台内存只有8GB的老电脑很容易被吃满。我建议在代码里做一个简单的“门槛判断”用navigator.deviceMemory属性读出设备内存低于一个阈值就直接走云端路径不启动端侧推理。这个API虽然在某些浏览器里不可用但可用的情况下判断很准值得加。3.2 加载时间和模型体积的较量模型文件下载是端侧推理的第一个用户体验节点也是劝退节点。我做过数据统计模型超过2GB时用户点击AI功能后等待完成的流失率达到60%以上。这不是模型能力的问题是加载体验的问题。技术上能做的优化是分片加载。ONNX Runtime和WebLLM都支持分片拉取模型不需要等整个文件下载完才开始推理。用户点进页面先拉第一个分片跑一个轻量的启动任务让用户感觉到页面“活”了后面的分片在后台继续加载。这套“先可用后完整”的策略实际转化率比“等全部加载完再启用”高出不少。第二个优化是浏览器缓存策略。模型文件本身的特征是不会频繁变化非常适合Cache-Control缓存头加长缓存周期。我们当时把模型文件缓存时间设成了7天配合Service Worker做版本管理老用户第二次进入页面几乎不需要重新下载启动时间从半分钟缩短到几秒。这一块的优化成本很低但收益非常直观。还有一个容易忽略的细节是CDN节点覆盖。模型文件是GB级别的大文件如果CDN节点离用户远下载速度会非常难看。选择CDN厂商时一定要看节点覆盖情况尤其是三四线城市和运营商线路的覆盖。我们都遇到过模型文件在“下载99%”卡住半天的用户这在弱网环境下是个真实存在的大坑解决办法只能是把下载逻辑写得足够健壮支持断点续传和重试机制。3.3 跨浏览器适配是硬仗端侧AI碰上浏览器兼容性属于“两个麻烦的叠加体”。不同浏览器的WebGPU实现进度不同、性能表现也完全不同。我在项目里维护了一份浏览器兼容矩阵核心信息整理如下浏览器WebGPU支持情况WASM推理可用性实测建议Chrome / Edge支持性能最好支持主力目标环境Firefox需开启功能标志默认不稳定支持建议降级到WASMSafari 17部分支持性能一般支持建议降级到WASM微信内置浏览器不支持部分支持性能较差直接走云端回退国产浏览器WebView视版本而定普遍不支持部分支持如条件允许引导用系统浏览器打开这份矩阵带来的开发工作量比想象的更大。你不能只写一套推理逻辑要写三套WebGPU路径、WASM路径、云端API路径然后根据运行时能力探测选择走哪条路。能力探测的关键是写一段“起步测试”不只看navigator.gpu是否存在还要真的初始化一个小的计算任务跑通了才认为可用。有些浏览器里WebGPU接口存在但底层驱动异常直接调用会崩溃这种坑只能靠实际跑一次才能发现。我见过不下三个项目折在兼容性上原因是只在Chrome上做了完整测试上线之后大批Safari和Firefox用户反馈功能不可用。所以如果你想做端侧AI先问自己一个问题我的团队有没有足够的精力维护一套跨浏览器、跨设备的兼容逻辑和降级矩阵如果没有那就不适合做全量端侧推理只能做成“部分用户可用的增强功能”。4. 合理架构混合推理与降级策略4.1 先做“简单任务不麻烦模型”在真正上端侧模型之前有个性价比极高的步骤把业务里不需要大模型的部分全部过滤掉。我们做内容摘要功能的时候发现用户提交的文章里有一大部分内容长度很短、结构已经接近摘要格式直接抽取前几句话就能用。这一部分请求根本不需要走大模型不需要云端更不需要端侧用正则和关键词规则就能完成。等把这些简单请求过滤光了真正需要模型参与的比例下降了40%以上。类似的做法还有“意图分级”。用户输入先走一个本地极小的分类模型只有几十MB判断这个请求是否需要大模型理解。简单指令直接规则处理复杂请求才进入推理链路。这种分层设计的思路和Java后端里“先查缓存再查数据库”的逻辑一脉相承——能便宜完成的请求绝对不调贵的资源。4.2 端侧和云端的任务划分标准真正到混合推理架构设计的时候我遵循的判断标准只有四条逐一过一遍就知道该把任务放哪边第一延迟要求。端侧模型的推理速度和设备性能强相关如果产品需求是“响应时间低于1秒”端侧未必靠谱。模型要经过用户设备下载、加载、推理整体链路的不确定性太多。云端的P95稳定在一秒内是完全做得到的端侧的P95大概率不稳定。第二数据敏感性。数据如果完全不能出浏览器那没什么好犹豫的端侧是唯一选择。如果数据脱敏后可以上云则可以从成本角度更自由地选择两端。第三模型的体量和生成质量要求。涉及长文本创作、复杂推理、需要最新知识召回的任务目前端侧模型的能力还不够硬放端侧就是在用户体验上自找麻烦。简单的分类、抽取、改写端侧模型完全够用。第四任务频率。一天的调用量如果几十万次以上端侧的价值开始显现如果一天只有几千次云端的几千次调用成本几乎可以忽略完全没必要增加端侧的研发维护成本。最终我们线上的任务分配是简单分类用正则和规则中等复杂度任务走端侧量化模型高复杂度任务走云端。这个三分法的核心思想是“成本与能力相匹配”而不是一刀切全部端侧或者全部云端。4.3 降级与兜底设计降级策略是我认为整个体系里最不能省的一环。浏览器端推理的失败率远比大部分人想象的高。WebGPU初始化失败会崩内存不足会崩模型文件损坏会崩用户设备驱动过老也会崩。你不能在用户面前只说一句“本地AI引擎启动失败”必须有一个兜底方案。我们的降级链路设计如下首先尝试WebGPU如果WebGPU不可用或者初始化失败自动降级到WASM路径。以我们实际生产数据来看WebGPU可用率在桌面端约70%手机端更低WASM路径则几乎100%兼容。这一步能兜住大部分用户。如果WASM也失败或者用户设备内存过低则自动改为请求云端API把推理任务转给服务器。云端API的调用本身我们设置了频率限制和预算控制避免在极端情况下云端成本反弹过猛。降级逻辑的测试用例要覆盖全面。我当时在验收清单里专门有一项“逐项禁用能力测试”手动在浏览器DevTools里模拟禁用WebGPU、禁用WASM、模拟内存过低验证每一步都能正确降级且用户能收到友好提示。这些测试看起来繁琐但真正上线之后几乎每一天都会有用户因为各种诡异的设备状态触发降级没有这套兜底预案就只能对着用户工单发呆。补充一点提示任何降级方案都要记录埋点和日志。不管走的是端侧还是云端路径、耗时、设备型号、模型版本这些信息必须上报。没有数据支撑你根本不知道真实用户里有多少比例能成功走完端侧推理也不知道云端的备用预算需要在哪个时间点预留。5. 实际项目中的常见坑与排查5.1 常见问题速查表整理了上线半年来用户反馈和高频工单中反复出现的问题汇总在这张表里可以直接当作排查手册用现象可能原因排查步骤解决方案模型一直在加载进度条不动CDN节点慢或模型文件缺失看Network请求确认HTTP状态码换CDN节点配置断点续传模型加载完成后页面卡死内存不足浏览器被杀查设备内存看日志有没有OOM增加内存门槛判断低内存走云端WebGPU初始化失败浏览器版本过旧或驱动问题抛错时捕获navigator.gpu自动降级到WASM推理速度极慢设备太老或模型过大打印GPU设备信息检测生成速度换更小模型或直接云端输出结果乱码INT4量化精度损失导致输出质量异常检查tokenizer是否与模型匹配重新对齐tokenizer必要时退回INT8部分用户永远走云端路径能力探测逻辑误判查看探测日志确认WebGPU初始化返回值修探测逻辑降低误判率新旧模型输出结果不一致版本残留检查Service Worker缓存强制版本失效并触发重新下载同一请求在不同浏览器结果不同量化模型的浮点计算存在微差异对比输出日志对关键业务做“云端结果为准”的修正逻辑5.2 三个让我印象深刻的线上事故第一个事故发生在刚上线时Windows用户普遍反馈AI功能无法使用。我们开发测试时用的是Chrome没问题。排查之后发现很多Windows用户在使用Edge浏览器而Edge的WebGPU初始化在某些版本上会静默失败不抛错只是功能不工作。我们后来加了“启动即跑一个小矩阵乘法”的探测任务确保功能真正可用才展示AI入口。第二个事故是模型文件更新引起的。我们在后台更新了新版本的量化模型老用户的浏览器缓存里还留着旧模型文件出现了同一个摘要请求在不同用户设备上输出不同风格内容的情况。这次之后我在模型文件URL里强制加入版本号更新版本时自动生成新的URL彻底切断缓存复用。第三个事故发生在低端Android设备上。用户反馈手机运行AI功能时发热严重甚至有两台手机因此重启。这个问题本质上是WebGPU在大规模并行计算时对移动设备的功耗冲击太大。最终的解决办法是移动端默认走WASM和更小的模型只有桌面端才启用WebGPU。这个策略虽然损失了部分移动端性能但换来了稳定性和设备安全性值得。5.3 一些让项目“不炸”的心得在踩过上面这些坑之后我给自己列了几条做事原则也一并分享出来。第一永远不要在用户路径上一开始就加载模型。先让用户看到产品本身模型下载放到后台或者用户点击AI功能之后再触发。这能把模型加载失败对留存的影响降到最低。第二给所有端侧模型相关的成本项加上监控面板。除了服务器QPS和延迟之外端侧模型还要加“模型下载成功率”“WebGPU可用率”“推理平均耗时”“降级比例”四个指标。没有这些指标任何问题排查都是盲人摸象。第三对端侧模型的能力边界要诚实。7B模型再量化也只是7B不是70B。如果业务的AI功能需要的是顶级的推理能力那就直接上云端大模型别硬塞进浏览器里做个“能做但做得不好”的版本。端侧AI的定位应该是“够用且便宜”而不是“最强且万能”。最后再分享一点基于实操的判断我个人在实际操作中的体会是浏览器里跑AI这件事的真实价值不在“省了GPU的钱”而在“逼着你把业务里的任务按复杂度重新分了一遍级”。这一遍分级做完你会发现很多请求根本不需要AI有些请求只需要小模型真正需要大模型的其实没那么多。这种架构梳理带来的长期收益往往比省下的服务器成本更大。如果你正在评估要不要做端侧推理我建议先小范围试一个功能挑一个高频、轻量、低风险的任务把端侧路径做出来跑一版灰度盯着降级比例和用户反馈。等数据给出了“端侧可用性真的能打”的信号再扩大到更多场景。这条路不是不能走但别指望零成本走通该踩的坑一个都不会少。