我一直在琢磨一个问题现在做网站的人谁还没被“AI功能”折磨过。想给产品加个智能搜索、图像识别或者自动回复第一反应是接大模型API结果一看账单稍微有点用户量一个月几千块钱打底。于是不少人脑子里冒出一个念头既然用户自己的手机电脑也挺能打的为什么不把AI模型直接塞到用户“浏览器”里跑服务器不就省了这个思路听着很诱人但“真能省钱吗”这个问题答案远没有想象中那么简单。我过去大半年在两个项目里把端侧推理这条路从零趟了一遍踩了不少坑也拿到了真实数据。这篇就讲讲我的测算逻辑、踩坑记录和最终落地结论给同样在纠结“客户端AI”的你一个参考。1. 这个想法是怎么冒出来的服务器推理的账单到底有多肉疼1.1 云GPU的真实花销不是买不起是用不满先说个很现实的事很多中小团队一开始自建AI服务都是从租云GPU开始的。以我熟悉的图像类任务为例用一张NVIDIA T4显卡做推理按常规定价大概每小时0.3到0.5美元如果包月跑满一个月就是200到350美元。这个价格贵吗单看数字不算离谱但问题在于业务波动。大多数网站的AI调用量有明显的峰谷白天多、凌晨少工作日多、周末少。我做的一个电商图片分类功能高峰时段每秒并发能冲到几十次凌晨可能整个小时都没有一个请求。为了应对高峰你只能按峰值预留GPU实例而剩下的十几个小时这张卡基本在闲置。算下来GPU的实际利用率能到30%就算不错了剩下的70%全是白烧的钱。这就好比你为了每天早晚高峰两班通勤专门买了一辆大巴停在那儿剩下的时间它在停车场吃灰——成本自然高。1.2 按量计费和外部API的重重算计有经验的人可能会说那我不包GPU用Serverless GPU行不行像Modal、Replicate这类平台按秒计费没有流量时不花钱听起来很完美。但单价会翻上去——T4这类卡折算成每秒计费往往比包月贵一倍还多。用外部大模型API呢比如接入一个多模态或文本生成接口按Token收钱。单看一次调用的几分钱似乎不贵可一旦每日调用量上到几万次每次处理几千Token月账单算下来两三万元人民币的团队我都见过。更要命的是这种成本完全不可控你没法精准预估用户会触发多少次调用也没法限制用户输入的复杂度账单像开盲盒。这两种方案各有各的痛但共同点是只要AI逻辑放在你的服务器上你就得为一套“重资产”买单不管这套资产是不是时刻被用到。于是把计算推给用户设备的念头自然就冒出来了——用户手里的手机电脑GPU性能很多时候比云端的入门卡还强却完全免费。2. 浏览器里跑AI到底是什么原理2.1 三个关键通道WASM、WebGPU、WebNN先说结论浏览器里跑AI完全可行而且技术上成熟度比很多人想象中要高。核心是三条通道。第一条是WebAssembly也就是WASM。它是一套可以运行在浏览器里的“接近原生”的二进制指令CPU密集型的计算丢给它比纯JavaScript快一个量级。很多经典模型比如BERT家族的文本分类模型在WASM下跑速度可以达到能用但不算流畅的水平。第二条是WebGPU。这是浏览器近年最重要的硬件加速接口允许网页直接调用GPU做通用计算。别看它名字和WebGL像实际上它是一套现代GPU API类似Vulkan、Metal不但能做图形渲染更重要的是支持Compute Shader也就是通用并行计算。大模型的矩阵乘法、卷积操作在GPU上面跑效率远超CPU。WebGPU在主流Chrome和Edge里已经默认支持Safari近两年也跟进了覆盖率在逐步攀升。第三条叫WebNN是浏览器底层神经网络加速接口的探索现在还比较早期但从方向和设计思路上看未来可能让浏览器更高效地调用各平台的NPU神经网络处理单元。目前实践中用得最多的还是WebGPU和WASM这对组合。WebGPU负责把重计算扛下来WASM负责兜底兼容不支持WebGPU的老浏览器。2.2 真正落地能用的工具链有哪些原理归原理工程上你不可能从零去写一个矩阵乘法库再在GPU上做优化必须用现成工具链。我实测下来常用有四套Transformers.jsHugging Face推出的JavaScript版Transformers可以直接在浏览器加载GPT、BERT、CLIP等各类模型API风格跟Python版几乎一样对新手最友好文档也全。ONNX Runtime Web微软出品的跨平台推理引擎把模型转成ONNX格式就可以同时在WASM和WebGPU后端上跑性能调节空间大适合对性能有强迫症的人。WebLLMMLC AI团队做的浏览器端大语言模型框架能在网页里直接跑Llama、Qwen这类几十亿参数级别的模型主打聊天和生成式AI。首次加载模型很大但效果已经很接近App体验。TensorFlow.js老牌的JavaScript深度学习库生态成熟但近年新模型的适配速度不如前面几个快。我在实际项目里的选择是文本分类这种轻量任务用Transformers.js一条命令加载ONNX量化模型图像类计算密集的任务用ONNX Runtime Web手动指定WebGPU后端性能能比WASM快很多。2.3 模型量化决定成败的预处理浏览器端AI能跑起来靠的其实是“压缩”。一个BERT-base模型有大约1.1亿个参数用FP32精度存储文件大小约440MB——让用户为了一个功能下载半G的模型转化率直接就崩了。所以端侧模型必须要做量化。量化就是把模型的浮点权重从32位压缩到8位甚至4位整数。以我的经验把BERT量化到INT8大小能降到约110MB推理速度反而更快精度下降通常控制在2%以内很多场景完全无感。对于更大的LLM现在流行的INT4量化甚至能把7B模型压到4GB左右加上流式加载浏览器里跑大模型的体验已经接近原生App。关键提醒量化不是“模型转一下格式”就完事你需要对验证集做精度回测。我见过有的团队把INT8量化后的意图识别模型直接上线结果因为精度波动太大分类错误率翻了近一倍用户投诉暴涨。量化后的模型一定要拿足够多的真实样例跑一遍确认关键指标没跳水再上线。3. 真金白银算一笔账省多少、怎么算3.1 先算一个轻量功能文本意图识别光讲原理没有用我给一个具体案例。假设你的网站需要一个“智能搜索意图识别”功能用户输入一段话前端判断他是想查订单、问售后还是走人工客服。模型用BERT-base量化后约15MB注意这里说的是Tiny版不是完整版每次推理在普通手机CPU上大约50毫秒完全可接受。如果放在服务器端比较合理的方案是租一台入门级GPU或者用Serverless GPU。我们按日均1万次调用、单次推理30毫秒、预留50%并发余量来算包月GPU实例成本约300美元/月即使利用率不高也得付Serverless GPU按量成本1万次 × 0.03秒 × 0.0002美元/秒 ≈ 0.6美元/天约18美元/月。听上去便宜但这只是纯算力还没算服务器、网关、日志、监控这些配套。如果放浏览器端你的成本主要变成CDN流量和模型存储。15MB的模型假设每个新设备首次使用时要下载一次日活用户1万里有20%当天是首次触发这个功能也就是2000次下载每天流量2000 × 15MB 30GB一个月约900GB。按CDN单价每GB 0.08美元算流量费约72美元/月。如果用户留存好很多人加载过一次后浏览器就缓存了实际费用可能再砍一半。这个案例里客户端推理的成本大概只有服务器方案的五分之一到三分之一确实省钱。但注意这里的前提是模型小、任务适合本地跑。一旦模型变大账本会变得完全不同。3.2 换一个重功能智能抠图再看一个反面案例。一个图片处理网站核心功能是“一键抠图”模型用MODNet这类分割网络转成ONNX INT8后大概还有80MB上下。服务器端如果走Serverless GPU单次推理约100毫秒按A10实例折算单次成本约0.0005美元。每天1万次调用一个月就是150美元。如果是纯客户端方案80MB模型意味着用户下载一次就要花费80MB流量。同样按每天2000次首次加载算每天流量160GB一个月4.8TBCDN流量费就到了240美元以上反而比服务器端贵了60%。更麻烦的是抠图这类计算密集任务在低端手机上跑经常要2到3秒才能出结果用户很容易以为页面卡死了。我在这个项目上最终的结论是对于超过50MB、计算量大的模型端侧直接跑的性价比很不稳定必须谨慎测算。3.3 算钱的正确姿势别只看单次成本从上面两个案例能提炼出一个判断公式服务器端每月成本 GPU时长/API调用总量折算客户端每月成本 月新增设备下载次数 × 模型大小 × CDN单价再加上发版更新带来的重复下载模型每次更新老用户要重新拉取。关键变量有两个一是你的模型文件多大二是你的用户有多少“新设备”。前者不要只看模型原始大小要看你压缩量化后的大小后者要评估用户是否频繁清缓存、是否有大量一次性访客。一次性访客占比过高时客户端推理的流量费会吃掉所有服务器节省下来的钱。说句大实话在我看过的项目里端侧AI真正省钱成功的有两类一类是日活很低、调用量也低的小工具站本地推理把服务器的GPU预算直接砍成零另一类是用户非常高频使用、留存极好的产品模型下载一次能用很久摊薄到每次调用成本几乎为零。反过来那种靠买量引流的营销型网站用户来一次就再也不来端侧推理就是灾难——每一次都要重新下载模型CDN费用高得让人肉疼。4. 容易忽略的隐形账单浏览器推理的五个坑4.1 兼容性不是一句“禁用就提示”能解决的WebGPU这几年普及度确实上来了但仍然有不小的盲区。根据我统计到的线上数据完整支持WebGPU的设备比例大约是六到七成剩下三成多是老版本浏览器、不支持GPU加速的Safari版本还有一些企业设备锁了硬件加速。这就意味着你做不了“只有WebGPU一条路径”的冒进方案。我当时处理的办法是做了三层降级支持WebGPU的走GPU不支持但有WASM的走CPU什么都没有的给一个功能模块降级提示。这套降级逻辑写起来简单但测试量是几何级上涨的特别是要真机覆盖iOS Safari、Windows Chrome、国产浏览器内核这些适配工作都是实打实的时间成本。4.2 模型文件大小和加载体验的平衡浏览器端模型再小也是要用户花钱下流量的。明面上流量费算得清隐性代价是用户会在你模型加载的几秒钟内流失。我测过一个数据页面模型加载超过3秒功能使用率下降约30%。为了这个我做过好几个版本文件名加哈希配合强缓存、加载时先展示不带AI能力的降级版、利用空闲时间在后台悄悄预热模型。每一次优化都涉及前端架构调整不是简单改个配置就行。这里面的教训是端侧AI不只是算法问题更是一个性能和体验工程问题你得把它当成“移动端弱网环境下的加载优化”来对待。4.3 端侧设备差异你在开发机上跑得飞起用户手机上卡成PPT做端侧AI最容易犯的错是只在开发机上调优。你的MacBook配着满血GPU跑模型几十毫秒出结果到了三年前的千元安卓机上同一段代码可能慢五倍以上内存还动不动就爆。设备差异是端侧推理区别于服务器推理的核心难点。服务器上所有用户拿到的算力是一样的你只要调一次浏览器世界里你的用户相当于用着几百款配置天差地别的“免费云主机”你得同时面对最强者和最弱者。我现在做性能测试时会把低端机真机作为必测项如果最低端设备上推理耗时超过用户心理预期我就得再压一版量化精度或者考虑把重活交给服务器。4.4 模型“裸奔”的安全风险把模型放进用户浏览器意味着模型文件完全暴露在客户端别人可以任意外观、提取、复制。如果你的模型是花了大代价训练的、有商业壁垒的端侧部署几乎等于把核心资产送人。我见过有公司把自己调优过的推荐模型放到前端三个月后发现有人把模型权重扒走做成了一个接口专门薅他们家的推荐能力。这件事在技术圈讨论得不多但真实发生。所以商业模型落地前一定要想清楚模型被复制对你是不是致命的如果是宁可多花钱放服务器也别赌用户不会扒。反过来用开源预训练模型微调的、模型本身不是核心资产的产品端侧部署完全没问题。4.5 版本迭代的运维成本服务端模型更新改个接口版本就完事端侧模型更新你得推新版本文件然后面对一大群老用户浏览器里缓存的旧模型直到他们重新访问触发校验。如果你的模型需要快速迭代比如垃圾内容识别模型每周都要更新端侧模式会拖慢你的迭代节奏。模型下发策略和灰度发布机制是端侧AI工程必做的肌肉记忆。我当时用一个简单的做法模型文件编号加版本号前端启动时异步拉取一个版本清单发现版本不一致才重新下载。这个机制把更新成本压了下来但每次发版前测试要覆盖“旧模型新代码”“新模型旧代码”的各种组合情况工作量并不比服务端小。5. 实际工程里我更愿意用的方案混合架构5.1 什么任务适合放端侧什么任务必须留服务器踩了一堆坑后我的最终结论很明确别二选一把任务拆开该端侧端侧该服务器服务器。适合端侧的任务有三个特征模型足够小最好50MB以内、对隐私敏感数据不出本地是卖点、决策响应要求快比如输入框里的实时联想。典型代表关键词抽取、情感倾向快速判断、离线翻译、人脸关键点检测、简单的物品分类。必须留服务器的任务也有三个特征模型规模大亿级参数起步、需要不断更新模型一周一版、涉及高价值决策金融风控、医疗建议、付费内容推荐。典型代表大语言模型对话、复杂图像生成、风控反欺诈。5.2 一个真实项目的混合路由决策给一个我实际落地过的场景一个内容社区要做“评论合规辅助”既要帮用户检测评论中的不友善内容又不想把每条评论都传到服务器上分析用户隐私敏感。最终架构是前端先用一个几MB的轻量分类模型跑第一道筛子只有被标记为“疑似不友善”的评论才发给服务器做一个更重的二阶段复核。这个设计的精妙之处在于绝大多数正常评论在本地就被放行了流量里只有大约20%的“问题评论”才会进服务器做深度分析服务器成本直接降了好几倍。当初在设计两阶段阈值时我调了好几版切分点核心逻辑是“宁可在本地放过几条漏网之鱼也不要把正常评论送进服务器白花钱”——因为服务器复核本身是按量付费的每一分钱都要花在刀刃上。5.3 落地切分的三个实用经验第一做一个功能负载评估表。把每个AI能力拆开列出模型大小、端侧推理预期耗时、端侧支持比例、更新频率四个维度用这四个维度给每个能力打分分数高的才允许走端侧。第二强烈建议做端侧“功能降级开关”。在后台配置一个比例端侧推理失败、超时或者浏览器不支持时请求自动转回服务器兜底保证功能不可用率保持在很小范围。这个开关既能在端侧模型出问题时快速止损也能在服务器预算紧张时反向把流量切回端侧非常实用。第三做缓存预载但别一上来就强制所有用户下载模型。我的做法是首次访问只提示功能可用真正点击使用才开始异步加载同时放在空闲时段用requestIdleCallback在后台悄悄拉取模型。这样既不伤害首屏速度又能把“等待加载”的感知减到最低。6. 常见问题与排查经验速查最后把我实际调试其他同学代码时经常遇到的坑整理成一张速查表按问题、原因、排查方向三个维度来说问题现象常见原因排查方向浏览器端推理速度很慢走了WASM CPU后端没启用WebGPU在用户机器上检查navigator.gpu是否存在确认ONNX Runtime Web的后端选择逻辑页面在模型加载时报内存不足模型未量化或者输入尺寸处理不当核对模型是否INT8/INT4量化限制输入图片/文本的最大长度必要时启用分片加载模型文件一直加载失败CDN跨域配置不正确或缺少COOP/COEP响应头确认CDN支持CORS且跨源隔离头正确设置否则WASM多线程和某些特性会被安全策略拦截部分用户进入功能白屏或崩溃浏览器版本过低WebGPU不可用且降级逻辑没触发检查降级路由是否正确用技术雷达统计用户浏览器版本分布端侧推理结果和服务器对不上量化后精度漂移或端侧与服务器模型版本不一致准备精度回归测试集端侧和服务器建议发布同一个模型签名版本页面主页因为后台加载模型而卡顿模型加载和推理霸占了主线程用Web Worker跑模型推理主线程只负责UI渲染和交互iOS上有用户反馈“网页一用AI功能就闪退”苹果Safari对网页内存使用有严格上限优先用更小的量化模型且及时释放中间变量考虑对低内存设备降级到服务器推理模型更新后用户还在用旧版本缓存策略太强索引文件没有更新对模型文件加版本哈希每次启动用轻量清单文件做版本比对表里的每一条我几乎都真金白银踩过。其中最坑的是跨源隔离和COOP/COEP头这个问题如果不在项目初期把CDN配置好后期再改非常痛苦而且排查起来隐蔽。再分享一个排查工具层面的心得调试浏览器端模型时别光看报错信息。打开DevTools的性能面板截取一段推理过程的录制你能清楚看到主线程、动画帧率、GPU调用情况。很多时候“卡”不是模型本身的问题而是你让推理任务和DOM渲染抢了同一个线程用Web Worker把推理丢到后台线程后很多“卡顿”问题自己就消失了。另外模型预热也是个容易被忽略的细节。不要等到用户真正触发AI功能时才去加载模型你可以在页面进入空闲状态后用requestIdleCallback“偷偷”把模型拉下来。这个技巧在实测中能把功能的首步耗时从几秒降到几百毫秒体验提升非常明显。最后一些写在项目结项之后的话我自己的切身体会是网站AI功能放浏览器里跑确实能省钱但省的是“显性”的服务器账单代价是把大量“隐性”的工程成本转移到了自己头上。它不是一个无脑的选择题而是一个需要精密测算的工程判断题。如果你正准备走这条路我建议你开工前先做三件事第一把模型压到最小可接受精度复测效果第二用至少20个不同种类的真实设备做性能基线测试第三写清楚降级和兜底方案再想省钱的事。这三件事做完心里那本账才真正算得明白。