上周末我把一个姿态估计模型真正塞进了一个浏览器标签页——不是跑通 demo而是做成一个可以在生产环境上线的功能。折腾完那一刻我就想写点什么网上讲浏览器跑神经网络的文章很多但绝大多数只讲到了能跑没人告诉你跑起来之后那些工程上的真相。这篇文章就是我这段实践的全部记录端侧视觉 AI 在浏览器里怎么选路线、怎么转模型、怎么处理摄像头实时视频、又是怎么在内存和 GPU 资源之间小心翼翼活下来的。适合那些正打算把模型放进浏览器标签页的工程师也适合想搞明白为什么浏览器里的 AI 又慢又容易崩的产品同学。1. 为什么非要在浏览器标签页里跑神经网络先算三笔账很多人第一反应是何必呢服务器算力那么强发回去推理不是更好。这个质疑在纯 demo 场景下完全成立但在真实产品里端侧推理不是优化项而是刚需。我习惯把它拆成三笔账每次跟团队争论技术方案时都先算这笔账。1.1 隐私账摄像头画面不出本地凡是涉及摄像头的视觉 AI第一个绕不开的就是隐私。儿童坐姿提醒、在线面试辅助、AR 试妆试戴这类产品一旦把用户面部、身体姿态画面传到服务器合规审查、用户信任、数据存储成本都会接踵而来。很多情况下用户根本不会授权你把摄像头画面传出去哪怕你承诺只处理不留存。端侧推理把这个难题直接消解掉了视频帧从摄像头到 GPU 纹理再进入神经网络全程不出浏览器标签页。我在实际项目里对接过客户的隐私需求他们看到数据链路图上写着视频流在本机完成推理无网络上传整个沟通成本瞬间下降一个量级。这不是技术选型问题是产品能不能活下去的问题。1.2 成本账服务器并发托不起每人一路实时视频算一笔粗账假设你的产品有 10 万日活高峰期同时在线 2 万人每人一路 720p 摄像头流要做实时姿态检测。按 YOLO 级别的模型、单路推理需要约 5 TFLOPs 来算服务器端要支撑这个并发量GPU 成本会直接把你拖垮。即便你用更好的集群调度每路视频流上行带宽也是实实在在的支出。端侧把算力成本转移到了用户的手机和电脑上。用户设备上的 NPU、GPU 平时大多在闲置浏览器通过 WebGL 或 WebGPU 把这些算力调动起来对产品方来说几乎是零边际成本。这在 ToC 产品里是决定性的优势也是把神经网络塞进浏览器标签页最朴素的经济学理由。1.3 体验账一次网络往返的延迟足以毁掉实时交互视觉 AI 的交互任务对延迟极其敏感。画一个虚拟眼镜如果从摄像头采集到渲染回屏幕的端到端延迟超过 100ms用户立刻觉得飘超过 200ms基本不可用。服务器推理再快也逃不过视频帧上行、排队、推理、结果下行、渲染这一整条链路上的网络 RTT。跨地域的网络抖动、弱网环境会让体验彻底失控。浏览器端推理把这条链路压缩到了摄像头→纹理→GPU→绘制在我的实测里一个轻量姿态模型跑 WebGL 后端单帧推理稳定在 10~25ms加上绘制整体延迟不到 60ms。而且没有网络依赖用户在电梯里、地铁上功能照常可用。1.4 标签页本身是产品边界不是妥协还要多说一句标签页这件事。一个浏览器标签页意味着沙箱、免安装、用完即走用户点开你的链接就能用不需要下载 App不需要注册登录。这本身就是一种产品形态上的优势。但硬币的另一面是你只能在一个标签页的资源和生命周期里做文章。后面讲的内存限制、上下文丢失、多标签页核显争抢全是因为这个边界而产生。接受这个约束工程方案才能务实。2. 浏览器里到底怎么执行神经网络四条路线与选型逻辑先说一个很多人没意识到的事实浏览器本身没有跑神经网络的标准 API它只有画图的 Canvas、跑定点指令的 WebAssembly以及近两年才逐步普及的 WebGPU。所以所有框架的本质都是想办法把张量运算映射到这些底层能力上。选哪条路线决定了你的模型能跑多快、能跑多大、在哪些机型上会翻车。2.1 路线一纯 JavaScript 矩阵运算最直白也最慢。把权重展开成数组自己写卷积、全连接、激活函数的循环。这条路只适合两件事一是教学演示让你理解反向传播到底在算什么二是在没有任何加速 API 的环境下做兜底兼容。真实项目里几乎不会有人用纯 JS 做视觉推理。我在早期原型阶段试过 320×320 输入的 MobileNet单帧推理能到 500ms 以上浏览器直接卡成幻灯片。原因很简单JavaScript 数组不是连续的二进制内存每次存取都有类型判断开销更没有 SIMD 指令集可供利用。这条路只用来验证模型输出的形状对不对别指望它在产品里干活。2.2 路线二WebAssembly SIMD 多线程WASM 把 C/Rust 写的推理引擎编译成浏览器能执行的二进制指令线性内存模型让数据存取连续且可预测。再配上 SIMD单指令多数据和多线程 WorkerCPU 推理速度能比纯 JS 快一个数量级以上。MediaPipe 的解决方案基本走的就是这条路把 TensorFlow Lite 的推理核心编译成 WASM在浏览器里用人脸网格、手掌检测这类模型效果已经相当可用。这条路线最大的优势是兼容性几乎什么浏览器都能跑不需要 GPU。适合的场景是低端安卓机、没有独立显卡的办公电脑、以及 GPU 资源被其他标签页占满时的降级方案。代价是它主要依赖 CPU功耗高、发热快帧率天花板比较低。2.3 路线三WebGL 把卷积变成纹理采样WebGL 本质是图形 API但聪明的工程实现把神经网络的全部计算映射成了渲染。具体来说张量被编码成 RGBA 纹理卷积操作通过片段着色器在每个像素上执行乘加运算矩阵乘法被组织成一次屏幕空间的渲染 Pass。TensorFlow.js 的 WebGL 后端就是这么工作的。好处是 GPU 真正参与了计算推理速度远快于 WASM CPU 路线而且几乎不需要开发者感知底层细节。坏处也很明显第一GPU 上的中间结果回读主内存极慢一旦你的数据处理逻辑导致频繁 readPixels性能会瞬间崩掉第二WebGL 纹理精度通常只有 FP16某些模型在中间层会出现精度漂移第三移动端 WebGL 实现各家驱动差异巨大同一个模型在不同手机上可能一个能跑一个直接黑屏。这条路线是目前端侧视觉 AI 的主力我绝大多数生产项目都跑在 WebGL 上但它要求你对 GPU 资源的生命周期有敬畏心。2.4 路线四WebGPU 才是正统未来WebGPU 提供了真正的通用计算能力Compute Shader 不再是伪装成绘制的计算数据可以留在 GPU 缓冲区里被灵活调度精度支持也更完整。从实测效果看同样的模型从 WebGL 迁移到 WebGPU推理耗时普遍能再降 30%~50%一些原本因为精度不足跑不了的大模型也有了机会。但兼容性是硬伤。以我写这篇文章时的情况来看Chrome 和 Edge 的桌面端、Android 端已经默认可用Firefox 还处于开发和完善阶段iOS Safari 则要再等一等。所以我的建议很直接新项目可以优先按 WebGPU 写但必须做能力检测在低版本浏览器上自动回退到 WebGL 或 WASM。2.5 框架选型别跟风按模型来源和管线复杂度选选框架其实是第二步第一步是想清楚你的模型从哪来、模型格式是什么、要不要跑完整的视觉管线。我见过太多团队因为喜欢某个框架的热度硬把 PyTorch 模型转成 TF 格式再迁到 TensorFlow.js中间踩了一堆算子兼容的坑。按下面这张表选型可以少走弯路。框架模型生态后端支持最适合的场景主要坑点TensorFlow.jsTF SavedModel / KerasWebGL / WebGPU / WASM / JS前端团队从零训练、深度定制的视觉模型TF 生态之外PyTorch模型转换成本高ONNX Runtime WebONNX可转换自 PyTorch / TF 等WebGPU / WebGL / WASMPyTorch 训练、需要统一格式的公司算子兼容性要逐个验证NMS 等动态 shape 算子要特别小心MediaPipe TasksTFLite / 内置视觉管线WASM / WebGL人脸、手势、姿态、分割等成熟方案不想自己写管线包体偏大、定制深层网络困难Transformers.jsHuggingFace / ONNXWASM / WebGPU逐步支持自然语言处理为主、附带部分视觉任务视觉模型相比专用库性能有差距我的经验和大多数项目一致如果团队主力是 PyTorch选 ONNX Runtime Web 最省心如果要跑的是成熟任务且不想自己调模型MediaPipe 开箱即用的体验是真的好只有当你需要在前端频繁改模型结构、做快速迭代实验时TensorFlow.js 的灵活性才是优势。3. 模型上线的完整链路从训练权重到浏览器可用的那段最后一公里有人以为模型训练完导出个权重文件就能丢给前端这是对最后一公里的严重低估。真实链路是训练权重秒变 Web 可用的推理格式中间要经过转换、校验、量化、压缩四道工序每一步都可能让精度损失或算子跑不起来。3.1 转换管线PyTorch 模型到 ONNX 再到 ORT Web以 PyTorch 为例最通用的中转站是 ONNX。训练好的模型先导出为 ONNX再由 ONNX Runtime Web 在浏览器里加载。导出时最容易被忽略的是dynamic_axes它标记哪些维度是动态的。我在项目里通常至少把 batch 维设为动态因为浏览器端可能要处理单张图也可能临时拼接成 batch 做批量推理固定维度会在运行时直接报错。import torch dummy_input torch.randn(1, 3, 256, 256) model.eval() torch.onnx.export( model, dummy_input, model.onnx, opset_version17, input_names[input], output_names[output], dynamic_axes{ input: {0: batch_size, 2: height, 3: width}, output: {0: batch_size}, } )opset_version也不是随便选的。版本太低很多新算子没有版本太高浏览器端解析器可能不支持。我一般选 15~17 之间并花时间把转换后的 ONNX 模型和 PyTorch 原模型在同样随机输入下的输出做一致性对比差值超过 1e-4 就要逐层排查。还有一个高频坑检测模型里的 NonMaxSuppression 在 ONNX Runtime Web 里经常因为动态输出形状而导致性能急剧下降甚至崩溃。我的做法是把它从模型里拆出去让模型只输出原始检测框和置信度NMS 交给业务端 JavaScript 实现。这样做的代价是多写几十行代码换来的是全浏览器稳定运行很划算。3.2 量化FP32、FP16 与 INT8 的真实取舍浏览器端模型体积和速度的优化核心靠量化。FP32 权重在 WebGL 里基本用不上纹理精度通常只有 FP16所以第一步是把模型压到 FP16 或 INT8。我自己用 MobileNet 类分类模型做过的对比是FP32 体积约 16MBFP16 约 8MBINT8 约 4.5MB在 WASM 后端上INT8 的推理速度比 FP32 快接近一倍。体积直接决定首次加载时长速度直接决定帧率这两个数字在浏览器标签页场景里比在服务器上金贵得多。但量化不是白吃午餐。后训练量化PTQ对分类任务还好一旦遇到目标检测的框回归、姿态估计的关键点坐标INT8 的精度抖动很容易造成画面里检测框肉眼可见的飘。解决思路是要么在训练阶段就做量化感知训练QAT让模型自己去适应低精度带来的噪声要么只用 FP16牺牲一点体积换取回归任务的稳定性。我在手部关键点项目里最终选了 QAT INT8因为 FP16 在低端安卓上仍然有部分驱动不支持半精度纹理性能反而更差。3.3 体积、压缩与缓存别让用户每次打开都下载几十兆模型文件本身可以用 Brotli 或 gzip 在服务器端压缩ONNX 和 TFLite 的压缩率通常不错被压缩后能再省十几到几十个百分点。但压缩挡不住每次打开都重新下载一次。浏览器标签页是一次性的可用户会反复打开同一个产品。我把模型文件固定版本化配合浏览器的 Cache API 把模型二进制缓存在本地。首次加载走网络之后打开直接读缓存加载时间从 3 秒降到 200ms 以内。这里有个细节模型的缓存校验不能光靠文件名哈希建议在业务接口里再带一个版本号模型升级时前端能主动清掉旧缓存避免用户长期停留在旧模型上。否则你修复了精度问题用户还拿着沉船版本排查起来相当痛苦。4. 实时视觉推理管线让摄像头画面一帧一帧喂给模型模型能在浏览器里跑只是第一步接上摄像头之后才是工程考验的开始。实时管线的核心目标很简单每一帧画面都尽可能新推理结果尽可能快地绘制回屏幕同时不卡顿主线程。4.1 采集getUserMedia 的参数不是越大越好视觉 AI 的输入并不需要 4K甚至 720p 在大多数任务里都绰绰有余。我见过不少人一上来就width: 1920结果摄像头开了画面清晰推理却从 20ms 变成 80ms因为模型输入并没有变大多出来的只是从视频帧缩放到模型输入尺寸的消耗。比较稳妥的写法是请求一个理想值让浏览器和摄像头自己协商同时读取实际生效的分辨率。const stream await navigator.mediaDevices.getUserMedia({ audio: false, video: { width: { ideal: 1280 }, height: { ideal: 720 }, facingMode: user } }); const track stream.getVideoTracks()[0]; const settings track.getSettings(); console.log(settings.width, settings.height); // 实际分辨率这里还有一个高频坑如果模型输入是正方形如 256×256、320×320摄像头画面是 16:9直接drawImage到正方形画布会把画面拉变形。正确做法是先按目标宽高比做居中裁剪再缩放进画布保证喂给模型的内容不畸变。这个细节对姿态检测、人脸对齐这类空间敏感的任务影响很大。4.2 送显与页面刷新用对回调才能拿到新鲜帧传统写法是requestAnimationFrame里不断drawImage但 rAF 的节奏和视频帧的到达节奏并不完全对齐可能出现同一帧被处理两次、或者视频已经更新但画布还停留在旧帧的情况。现代浏览器提供了requestVideoFrameCallback它在每一帧新视频真正解码完成后触发是拿新鲜帧最合适的时机。拿到视频帧后下一步是把画面画进一个尺寸等于模型输入大小的离屏 canvas。这一步在 CPU 侧完成缩放然后把 canvas 直接作为纹理上传 GPU尽量减少像素格式转换。4.3 流水线设计别让推理等待拖垮整条链路实时推理最忌讳串行等待采集一帧、推理一帧、绘制一帧、再采集下一帧。如果推理耗时 30ms串行逻辑会让每一帧的有效处理时间被拉长一倍不止。我的实现里维护一个状态标志当上一帧还在推理时新来的视频帧直接丢弃或只更新画布缓存不叠加进推理队列。推理是异步的结果返回后再拿最新帧的结果去绘制。这个一帧在飞的模式虽然简单却能大幅降低排队延迟保证画面永远显示的是最近一次推理结果。4.4 帧率控制不是所有任务都需要每帧都推理视觉 AI 任务里人脸关键点、姿态估计这类任务的连续帧之间存在强相关性没必要每帧都跑一次深度学习。我通常的做法是以 30FPS 的视频帧为采集基准每隔 2~3 帧才做一次完整推理中间帧用上一次的检测结果绘制必要时做一次简单的关键点平滑。这样推理负载直接降到原来的三分之一功耗和发热都能接受。更进一步可以做动态降级如果发现连续多帧推理耗时超过 40ms自动把输入分辨率从 480 降到 320并降低推理频率。用户对分辨率下降的感知通常远低于对卡顿的感知先把流畅保住。5. 浏览器环境的温柔陷阱那些框架文档里不会写清楚的崩溃与性能悬崖即便你的模型、管线都调好了浏览器本身还埋着好几个雷。这些坑不在框架文档里只在真实环境的摔打中出现。我花了大量时间才摸清它们的规律。5.1 WebGL Context Lost切后台再回来模型可能就废了浏览器在 GPU 资源紧张、标签页切到后台被回收、或者其他标签页霸占 GPU 时会触发webglcontextlost事件。它最大的杀伤力在于你的推理引擎持有的所有纹理、程序对象全部失效不监听这个事件的话用户切回来看到的只有白屏或者异常。必要的一步是主动监听并重建资源canvas.addEventListener(webglcontextlost, (event) { event.preventDefault(); // 通知业务层暂停推理进入重建流程 }); canvas.addEventListener(webglcontextrestored, () { // 重新加载模型、重建纹理 });重建模型意味着重新读权重所以在前面缓存章节里我坚持要把模型二进制存到 Cache API就是为了让重建过程不发网络请求用户在切回标签页后一两秒就能恢复。5.2 内存峰值与标签页卡顿纹理和张量都不是免费的浏览器里每个 GPU 纹理都占显存而且不是你用完就自动释放的。一张 1080p 的 RGBA 纹理约 8.3MB听起来不大但神经网络推理过程中会持续创建中间特征图层——一个 512×512×64 的特征图就是 64MB 显存模型一旦深一点上百 MB 很常见。如果推理循环里不断产生新张量又不释放Chrome 的 GPU 进程内存会稳定爬升最后整个标签页被系统杀后台。不同框架的释放 API 不一样但原则一致中间张量用完即释放循环推理时尤其注意。我排查过线上用户反馈的用 5 分钟后越来越卡定位到最后就是一个后端自动产生的中间张量在每次推理后没被清理。用 DevTools 的 Memory 记录堆快照能看出来但更强的监控手段是看 Chrome 任务管理器里这个标签页的 GPU 内存数值如果随时间单调上涨基本可以断定有泄漏。5.3 多标签页的 GPU 资源争抢你控制的只有自己这一亩三分地浏览器所有标签页共享同一个 GPU 进程。用户的电脑上开着视频网站、Figma、3D 游戏页再打开你的 AI 标签页推理速度会断崖式下跌。我实测过同一个模型在空载浏览器里推理 15ms在挂了一堆后台标签页的浏览器里能飙到 60ms 以上。这不是你能控制的但你能应对。做法是建立超时监控连续几帧推理超过目标耗时阈值时自动把模型切换到 WASM 后端、降低输入分辨率或者调低推理频率。把降级设计成产品功能的一部分而不是突然卡死用户容忍度会高很多。你可能无法阻止用户的其他标签页吃 GPU但至少能确保自己的产品在这一环境下仍然可用。5.4 iOS Safari 与低端安卓的隐形上限移动端浏览器是端侧视觉 AI 最容易翻车的地方。iOS Safari 的内存管理出了名的激进标签页内存占用过高时系统会直接终止网页进程表现就是切出去再切回来页面重新加载。这意味着移动端必须更克制模型尽量压缩到 10MB 以内输入分辨率宁低勿高同时保存好当前状态让页面被系统回收后能恢复。在低端安卓上则要面对设备驱动碎片化同是 WebGL2 的设备不同厂商的实现差异巨大有的不支持某些纹理格式有的精度不达标。我目前的策略是把浏览器能力检测的结果按 A/B/C 分级A 级跑 WebGPU 大模型B 级跑 WebGL 中模型C 级跑 WASM 小模型。这个分级思路让产品在不同档位的设备上都有一条活路。6. 性能验证与上线前检查我每次发布前三小时必做的事跑通功能到上线发布之间还有一段容易被忽略的性能验收期。这一段做的事情不多但每一件都能拦住一次线上事故。6.1 测量方法别用 Date.now 测性能浏览器端要测推理延迟第一件事是预热。模型第一次推理往往包含初始化、纹理预分配、算子编译耗时通常是稳定态的 3~5 倍。如果你拿第一次推理的数据去汇报性能结论必错。我习惯先丢 10~20 帧做预热然后连续跑 50 次取中位数和 P90。计时用performance.now()别用Date.now()后者受系统时间调整影响且精度只有毫秒级。WebGL/WebGPU 推理是异步的需要在 Promise resolve 之后才计时结束否则测出来的是提交到 GPU 的时间而不是推理完成的时间。测完单帧延迟还要在 DevTools Performance 里录一段真实交互过程看主线程上有没有超过 50ms 的长任务——长任务才是用户感知卡顿的元凶。6.2 精度对比转换和量化后的降级要有据可依模型从 PyTorch 转 ONNX、再从 FP32 量化到 INT8每一步都可能引入偏差。我在波次验收时固定一套 200 张有标注的测试集跑到浏览器端去推理对比原 PyTorch 模型的输出。分类任务看 top-1/top-5 准确率差多少检测任务看框的 IoU 和 关键点偏移。经验值是分类模型 INT8 掉点在 1~2 个百分点点可以接受检测和姿态回归任务INT8 的坐标抖动如果超过输入尺寸的 1%比如 320 输入下抖动超过 3 像素用户就能察觉就要考虑退回 FP16。这种量化后的降级评估不要靠感觉要把数据贴在技术方案里否则前端同事改版本号时根本不知道改了精度。6.3 降级方案矩阵每个用户都应该有能跑的路我前文反复提到降级上线前必须把它落成一张可执行的表格。核心逻辑是探测浏览器能力然后选择匹配的模型和参数。浏览器能力推荐后端输入分辨率模型档位目标帧率支持 WebGPUWebGPU640×640高精度大模型30FPS仅支持 WebGL2WebGL2FP16480×480中模型/INT830FPS仅 WASM SIMDWAsm320×320小模型/INT815FPS老旧设备JS 兜底224×224超小模型仅做静态图推理这个矩阵看起来简单但每个格子都要真实跑一遍。我在一次交付里发现支持 WebGPU 的 Chrome 跑大模型反而比 WebGL 中模型更慢原因是该设备 GPU 驱动对 Compute Shader 调度有缺陷。所以表格只是起点上线前每个档位都要用代表性设备实测。6.4 上线演练让浏览器处于最坏状态再压测发布会前我习惯打开几个 CPU 占用高的后台标签页让机器先热起来再启动自己的 AI 页面做一次完整流程接着切几次后台标签页看webglcontextlost是否触发、恢复是否正常再用 DevTools 的 CPU 节流模拟低端机性能。这些演练能暴露大多数正常情况下根本不会出现的线上问题。最后还有一个容易忽略的点摄像头权限被用户拒绝后怎么办。没有摄像头权限视觉 AI 产品不应该直接白屏。我通常会把产品降级成上传图片分析模式至少用户还能用静态图走一遍完整链路。别小看这个兜底它撑住了不少用户第一次打开就是拒绝授权的尴尬场景。整个流程走完消灭了白屏、崩溃、卡顿、精度异常这些硬伤之后把神经网络塞进浏览器标签页这件事才算真正落地。对我来说端侧视觉 AI 的工程真相其实就是真正的难点并不在网络结构设计而是如何在浏览器这个资源有限、环境复杂、随时可能被系统回收的舞台上让模型稳定地跑起来。所有框架和工具都只是帮你把这段路走得更稳一些剩下的边界条件还是要靠一个又一个标签页去踩出来。 把神经网络塞进浏览器标签页：端侧视觉AI工程实录
上周末我把一个姿态估计模型真正塞进了一个浏览器标签页——不是跑通 demo而是做成一个可以在生产环境上线的功能。折腾完那一刻我就想写点什么网上讲浏览器跑神经网络的文章很多但绝大多数只讲到了能跑没人告诉你跑起来之后那些工程上的真相。这篇文章就是我这段实践的全部记录端侧视觉 AI 在浏览器里怎么选路线、怎么转模型、怎么处理摄像头实时视频、又是怎么在内存和 GPU 资源之间小心翼翼活下来的。适合那些正打算把模型放进浏览器标签页的工程师也适合想搞明白为什么浏览器里的 AI 又慢又容易崩的产品同学。1. 为什么非要在浏览器标签页里跑神经网络先算三笔账很多人第一反应是何必呢服务器算力那么强发回去推理不是更好。这个质疑在纯 demo 场景下完全成立但在真实产品里端侧推理不是优化项而是刚需。我习惯把它拆成三笔账每次跟团队争论技术方案时都先算这笔账。1.1 隐私账摄像头画面不出本地凡是涉及摄像头的视觉 AI第一个绕不开的就是隐私。儿童坐姿提醒、在线面试辅助、AR 试妆试戴这类产品一旦把用户面部、身体姿态画面传到服务器合规审查、用户信任、数据存储成本都会接踵而来。很多情况下用户根本不会授权你把摄像头画面传出去哪怕你承诺只处理不留存。端侧推理把这个难题直接消解掉了视频帧从摄像头到 GPU 纹理再进入神经网络全程不出浏览器标签页。我在实际项目里对接过客户的隐私需求他们看到数据链路图上写着视频流在本机完成推理无网络上传整个沟通成本瞬间下降一个量级。这不是技术选型问题是产品能不能活下去的问题。1.2 成本账服务器并发托不起每人一路实时视频算一笔粗账假设你的产品有 10 万日活高峰期同时在线 2 万人每人一路 720p 摄像头流要做实时姿态检测。按 YOLO 级别的模型、单路推理需要约 5 TFLOPs 来算服务器端要支撑这个并发量GPU 成本会直接把你拖垮。即便你用更好的集群调度每路视频流上行带宽也是实实在在的支出。端侧把算力成本转移到了用户的手机和电脑上。用户设备上的 NPU、GPU 平时大多在闲置浏览器通过 WebGL 或 WebGPU 把这些算力调动起来对产品方来说几乎是零边际成本。这在 ToC 产品里是决定性的优势也是把神经网络塞进浏览器标签页最朴素的经济学理由。1.3 体验账一次网络往返的延迟足以毁掉实时交互视觉 AI 的交互任务对延迟极其敏感。画一个虚拟眼镜如果从摄像头采集到渲染回屏幕的端到端延迟超过 100ms用户立刻觉得飘超过 200ms基本不可用。服务器推理再快也逃不过视频帧上行、排队、推理、结果下行、渲染这一整条链路上的网络 RTT。跨地域的网络抖动、弱网环境会让体验彻底失控。浏览器端推理把这条链路压缩到了摄像头→纹理→GPU→绘制在我的实测里一个轻量姿态模型跑 WebGL 后端单帧推理稳定在 10~25ms加上绘制整体延迟不到 60ms。而且没有网络依赖用户在电梯里、地铁上功能照常可用。1.4 标签页本身是产品边界不是妥协还要多说一句标签页这件事。一个浏览器标签页意味着沙箱、免安装、用完即走用户点开你的链接就能用不需要下载 App不需要注册登录。这本身就是一种产品形态上的优势。但硬币的另一面是你只能在一个标签页的资源和生命周期里做文章。后面讲的内存限制、上下文丢失、多标签页核显争抢全是因为这个边界而产生。接受这个约束工程方案才能务实。2. 浏览器里到底怎么执行神经网络四条路线与选型逻辑先说一个很多人没意识到的事实浏览器本身没有跑神经网络的标准 API它只有画图的 Canvas、跑定点指令的 WebAssembly以及近两年才逐步普及的 WebGPU。所以所有框架的本质都是想办法把张量运算映射到这些底层能力上。选哪条路线决定了你的模型能跑多快、能跑多大、在哪些机型上会翻车。2.1 路线一纯 JavaScript 矩阵运算最直白也最慢。把权重展开成数组自己写卷积、全连接、激活函数的循环。这条路只适合两件事一是教学演示让你理解反向传播到底在算什么二是在没有任何加速 API 的环境下做兜底兼容。真实项目里几乎不会有人用纯 JS 做视觉推理。我在早期原型阶段试过 320×320 输入的 MobileNet单帧推理能到 500ms 以上浏览器直接卡成幻灯片。原因很简单JavaScript 数组不是连续的二进制内存每次存取都有类型判断开销更没有 SIMD 指令集可供利用。这条路只用来验证模型输出的形状对不对别指望它在产品里干活。2.2 路线二WebAssembly SIMD 多线程WASM 把 C/Rust 写的推理引擎编译成浏览器能执行的二进制指令线性内存模型让数据存取连续且可预测。再配上 SIMD单指令多数据和多线程 WorkerCPU 推理速度能比纯 JS 快一个数量级以上。MediaPipe 的解决方案基本走的就是这条路把 TensorFlow Lite 的推理核心编译成 WASM在浏览器里用人脸网格、手掌检测这类模型效果已经相当可用。这条路线最大的优势是兼容性几乎什么浏览器都能跑不需要 GPU。适合的场景是低端安卓机、没有独立显卡的办公电脑、以及 GPU 资源被其他标签页占满时的降级方案。代价是它主要依赖 CPU功耗高、发热快帧率天花板比较低。2.3 路线三WebGL 把卷积变成纹理采样WebGL 本质是图形 API但聪明的工程实现把神经网络的全部计算映射成了渲染。具体来说张量被编码成 RGBA 纹理卷积操作通过片段着色器在每个像素上执行乘加运算矩阵乘法被组织成一次屏幕空间的渲染 Pass。TensorFlow.js 的 WebGL 后端就是这么工作的。好处是 GPU 真正参与了计算推理速度远快于 WASM CPU 路线而且几乎不需要开发者感知底层细节。坏处也很明显第一GPU 上的中间结果回读主内存极慢一旦你的数据处理逻辑导致频繁 readPixels性能会瞬间崩掉第二WebGL 纹理精度通常只有 FP16某些模型在中间层会出现精度漂移第三移动端 WebGL 实现各家驱动差异巨大同一个模型在不同手机上可能一个能跑一个直接黑屏。这条路线是目前端侧视觉 AI 的主力我绝大多数生产项目都跑在 WebGL 上但它要求你对 GPU 资源的生命周期有敬畏心。2.4 路线四WebGPU 才是正统未来WebGPU 提供了真正的通用计算能力Compute Shader 不再是伪装成绘制的计算数据可以留在 GPU 缓冲区里被灵活调度精度支持也更完整。从实测效果看同样的模型从 WebGL 迁移到 WebGPU推理耗时普遍能再降 30%~50%一些原本因为精度不足跑不了的大模型也有了机会。但兼容性是硬伤。以我写这篇文章时的情况来看Chrome 和 Edge 的桌面端、Android 端已经默认可用Firefox 还处于开发和完善阶段iOS Safari 则要再等一等。所以我的建议很直接新项目可以优先按 WebGPU 写但必须做能力检测在低版本浏览器上自动回退到 WebGL 或 WASM。2.5 框架选型别跟风按模型来源和管线复杂度选选框架其实是第二步第一步是想清楚你的模型从哪来、模型格式是什么、要不要跑完整的视觉管线。我见过太多团队因为喜欢某个框架的热度硬把 PyTorch 模型转成 TF 格式再迁到 TensorFlow.js中间踩了一堆算子兼容的坑。按下面这张表选型可以少走弯路。框架模型生态后端支持最适合的场景主要坑点TensorFlow.jsTF SavedModel / KerasWebGL / WebGPU / WASM / JS前端团队从零训练、深度定制的视觉模型TF 生态之外PyTorch模型转换成本高ONNX Runtime WebONNX可转换自 PyTorch / TF 等WebGPU / WebGL / WASMPyTorch 训练、需要统一格式的公司算子兼容性要逐个验证NMS 等动态 shape 算子要特别小心MediaPipe TasksTFLite / 内置视觉管线WASM / WebGL人脸、手势、姿态、分割等成熟方案不想自己写管线包体偏大、定制深层网络困难Transformers.jsHuggingFace / ONNXWASM / WebGPU逐步支持自然语言处理为主、附带部分视觉任务视觉模型相比专用库性能有差距我的经验和大多数项目一致如果团队主力是 PyTorch选 ONNX Runtime Web 最省心如果要跑的是成熟任务且不想自己调模型MediaPipe 开箱即用的体验是真的好只有当你需要在前端频繁改模型结构、做快速迭代实验时TensorFlow.js 的灵活性才是优势。3. 模型上线的完整链路从训练权重到浏览器可用的那段最后一公里有人以为模型训练完导出个权重文件就能丢给前端这是对最后一公里的严重低估。真实链路是训练权重秒变 Web 可用的推理格式中间要经过转换、校验、量化、压缩四道工序每一步都可能让精度损失或算子跑不起来。3.1 转换管线PyTorch 模型到 ONNX 再到 ORT Web以 PyTorch 为例最通用的中转站是 ONNX。训练好的模型先导出为 ONNX再由 ONNX Runtime Web 在浏览器里加载。导出时最容易被忽略的是dynamic_axes它标记哪些维度是动态的。我在项目里通常至少把 batch 维设为动态因为浏览器端可能要处理单张图也可能临时拼接成 batch 做批量推理固定维度会在运行时直接报错。import torch dummy_input torch.randn(1, 3, 256, 256) model.eval() torch.onnx.export( model, dummy_input, model.onnx, opset_version17, input_names[input], output_names[output], dynamic_axes{ input: {0: batch_size, 2: height, 3: width}, output: {0: batch_size}, } )opset_version也不是随便选的。版本太低很多新算子没有版本太高浏览器端解析器可能不支持。我一般选 15~17 之间并花时间把转换后的 ONNX 模型和 PyTorch 原模型在同样随机输入下的输出做一致性对比差值超过 1e-4 就要逐层排查。还有一个高频坑检测模型里的 NonMaxSuppression 在 ONNX Runtime Web 里经常因为动态输出形状而导致性能急剧下降甚至崩溃。我的做法是把它从模型里拆出去让模型只输出原始检测框和置信度NMS 交给业务端 JavaScript 实现。这样做的代价是多写几十行代码换来的是全浏览器稳定运行很划算。3.2 量化FP32、FP16 与 INT8 的真实取舍浏览器端模型体积和速度的优化核心靠量化。FP32 权重在 WebGL 里基本用不上纹理精度通常只有 FP16所以第一步是把模型压到 FP16 或 INT8。我自己用 MobileNet 类分类模型做过的对比是FP32 体积约 16MBFP16 约 8MBINT8 约 4.5MB在 WASM 后端上INT8 的推理速度比 FP32 快接近一倍。体积直接决定首次加载时长速度直接决定帧率这两个数字在浏览器标签页场景里比在服务器上金贵得多。但量化不是白吃午餐。后训练量化PTQ对分类任务还好一旦遇到目标检测的框回归、姿态估计的关键点坐标INT8 的精度抖动很容易造成画面里检测框肉眼可见的飘。解决思路是要么在训练阶段就做量化感知训练QAT让模型自己去适应低精度带来的噪声要么只用 FP16牺牲一点体积换取回归任务的稳定性。我在手部关键点项目里最终选了 QAT INT8因为 FP16 在低端安卓上仍然有部分驱动不支持半精度纹理性能反而更差。3.3 体积、压缩与缓存别让用户每次打开都下载几十兆模型文件本身可以用 Brotli 或 gzip 在服务器端压缩ONNX 和 TFLite 的压缩率通常不错被压缩后能再省十几到几十个百分点。但压缩挡不住每次打开都重新下载一次。浏览器标签页是一次性的可用户会反复打开同一个产品。我把模型文件固定版本化配合浏览器的 Cache API 把模型二进制缓存在本地。首次加载走网络之后打开直接读缓存加载时间从 3 秒降到 200ms 以内。这里有个细节模型的缓存校验不能光靠文件名哈希建议在业务接口里再带一个版本号模型升级时前端能主动清掉旧缓存避免用户长期停留在旧模型上。否则你修复了精度问题用户还拿着沉船版本排查起来相当痛苦。4. 实时视觉推理管线让摄像头画面一帧一帧喂给模型模型能在浏览器里跑只是第一步接上摄像头之后才是工程考验的开始。实时管线的核心目标很简单每一帧画面都尽可能新推理结果尽可能快地绘制回屏幕同时不卡顿主线程。4.1 采集getUserMedia 的参数不是越大越好视觉 AI 的输入并不需要 4K甚至 720p 在大多数任务里都绰绰有余。我见过不少人一上来就width: 1920结果摄像头开了画面清晰推理却从 20ms 变成 80ms因为模型输入并没有变大多出来的只是从视频帧缩放到模型输入尺寸的消耗。比较稳妥的写法是请求一个理想值让浏览器和摄像头自己协商同时读取实际生效的分辨率。const stream await navigator.mediaDevices.getUserMedia({ audio: false, video: { width: { ideal: 1280 }, height: { ideal: 720 }, facingMode: user } }); const track stream.getVideoTracks()[0]; const settings track.getSettings(); console.log(settings.width, settings.height); // 实际分辨率这里还有一个高频坑如果模型输入是正方形如 256×256、320×320摄像头画面是 16:9直接drawImage到正方形画布会把画面拉变形。正确做法是先按目标宽高比做居中裁剪再缩放进画布保证喂给模型的内容不畸变。这个细节对姿态检测、人脸对齐这类空间敏感的任务影响很大。4.2 送显与页面刷新用对回调才能拿到新鲜帧传统写法是requestAnimationFrame里不断drawImage但 rAF 的节奏和视频帧的到达节奏并不完全对齐可能出现同一帧被处理两次、或者视频已经更新但画布还停留在旧帧的情况。现代浏览器提供了requestVideoFrameCallback它在每一帧新视频真正解码完成后触发是拿新鲜帧最合适的时机。拿到视频帧后下一步是把画面画进一个尺寸等于模型输入大小的离屏 canvas。这一步在 CPU 侧完成缩放然后把 canvas 直接作为纹理上传 GPU尽量减少像素格式转换。4.3 流水线设计别让推理等待拖垮整条链路实时推理最忌讳串行等待采集一帧、推理一帧、绘制一帧、再采集下一帧。如果推理耗时 30ms串行逻辑会让每一帧的有效处理时间被拉长一倍不止。我的实现里维护一个状态标志当上一帧还在推理时新来的视频帧直接丢弃或只更新画布缓存不叠加进推理队列。推理是异步的结果返回后再拿最新帧的结果去绘制。这个一帧在飞的模式虽然简单却能大幅降低排队延迟保证画面永远显示的是最近一次推理结果。4.4 帧率控制不是所有任务都需要每帧都推理视觉 AI 任务里人脸关键点、姿态估计这类任务的连续帧之间存在强相关性没必要每帧都跑一次深度学习。我通常的做法是以 30FPS 的视频帧为采集基准每隔 2~3 帧才做一次完整推理中间帧用上一次的检测结果绘制必要时做一次简单的关键点平滑。这样推理负载直接降到原来的三分之一功耗和发热都能接受。更进一步可以做动态降级如果发现连续多帧推理耗时超过 40ms自动把输入分辨率从 480 降到 320并降低推理频率。用户对分辨率下降的感知通常远低于对卡顿的感知先把流畅保住。5. 浏览器环境的温柔陷阱那些框架文档里不会写清楚的崩溃与性能悬崖即便你的模型、管线都调好了浏览器本身还埋着好几个雷。这些坑不在框架文档里只在真实环境的摔打中出现。我花了大量时间才摸清它们的规律。5.1 WebGL Context Lost切后台再回来模型可能就废了浏览器在 GPU 资源紧张、标签页切到后台被回收、或者其他标签页霸占 GPU 时会触发webglcontextlost事件。它最大的杀伤力在于你的推理引擎持有的所有纹理、程序对象全部失效不监听这个事件的话用户切回来看到的只有白屏或者异常。必要的一步是主动监听并重建资源canvas.addEventListener(webglcontextlost, (event) { event.preventDefault(); // 通知业务层暂停推理进入重建流程 }); canvas.addEventListener(webglcontextrestored, () { // 重新加载模型、重建纹理 });重建模型意味着重新读权重所以在前面缓存章节里我坚持要把模型二进制存到 Cache API就是为了让重建过程不发网络请求用户在切回标签页后一两秒就能恢复。5.2 内存峰值与标签页卡顿纹理和张量都不是免费的浏览器里每个 GPU 纹理都占显存而且不是你用完就自动释放的。一张 1080p 的 RGBA 纹理约 8.3MB听起来不大但神经网络推理过程中会持续创建中间特征图层——一个 512×512×64 的特征图就是 64MB 显存模型一旦深一点上百 MB 很常见。如果推理循环里不断产生新张量又不释放Chrome 的 GPU 进程内存会稳定爬升最后整个标签页被系统杀后台。不同框架的释放 API 不一样但原则一致中间张量用完即释放循环推理时尤其注意。我排查过线上用户反馈的用 5 分钟后越来越卡定位到最后就是一个后端自动产生的中间张量在每次推理后没被清理。用 DevTools 的 Memory 记录堆快照能看出来但更强的监控手段是看 Chrome 任务管理器里这个标签页的 GPU 内存数值如果随时间单调上涨基本可以断定有泄漏。5.3 多标签页的 GPU 资源争抢你控制的只有自己这一亩三分地浏览器所有标签页共享同一个 GPU 进程。用户的电脑上开着视频网站、Figma、3D 游戏页再打开你的 AI 标签页推理速度会断崖式下跌。我实测过同一个模型在空载浏览器里推理 15ms在挂了一堆后台标签页的浏览器里能飙到 60ms 以上。这不是你能控制的但你能应对。做法是建立超时监控连续几帧推理超过目标耗时阈值时自动把模型切换到 WASM 后端、降低输入分辨率或者调低推理频率。把降级设计成产品功能的一部分而不是突然卡死用户容忍度会高很多。你可能无法阻止用户的其他标签页吃 GPU但至少能确保自己的产品在这一环境下仍然可用。5.4 iOS Safari 与低端安卓的隐形上限移动端浏览器是端侧视觉 AI 最容易翻车的地方。iOS Safari 的内存管理出了名的激进标签页内存占用过高时系统会直接终止网页进程表现就是切出去再切回来页面重新加载。这意味着移动端必须更克制模型尽量压缩到 10MB 以内输入分辨率宁低勿高同时保存好当前状态让页面被系统回收后能恢复。在低端安卓上则要面对设备驱动碎片化同是 WebGL2 的设备不同厂商的实现差异巨大有的不支持某些纹理格式有的精度不达标。我目前的策略是把浏览器能力检测的结果按 A/B/C 分级A 级跑 WebGPU 大模型B 级跑 WebGL 中模型C 级跑 WASM 小模型。这个分级思路让产品在不同档位的设备上都有一条活路。6. 性能验证与上线前检查我每次发布前三小时必做的事跑通功能到上线发布之间还有一段容易被忽略的性能验收期。这一段做的事情不多但每一件都能拦住一次线上事故。6.1 测量方法别用 Date.now 测性能浏览器端要测推理延迟第一件事是预热。模型第一次推理往往包含初始化、纹理预分配、算子编译耗时通常是稳定态的 3~5 倍。如果你拿第一次推理的数据去汇报性能结论必错。我习惯先丢 10~20 帧做预热然后连续跑 50 次取中位数和 P90。计时用performance.now()别用Date.now()后者受系统时间调整影响且精度只有毫秒级。WebGL/WebGPU 推理是异步的需要在 Promise resolve 之后才计时结束否则测出来的是提交到 GPU 的时间而不是推理完成的时间。测完单帧延迟还要在 DevTools Performance 里录一段真实交互过程看主线程上有没有超过 50ms 的长任务——长任务才是用户感知卡顿的元凶。6.2 精度对比转换和量化后的降级要有据可依模型从 PyTorch 转 ONNX、再从 FP32 量化到 INT8每一步都可能引入偏差。我在波次验收时固定一套 200 张有标注的测试集跑到浏览器端去推理对比原 PyTorch 模型的输出。分类任务看 top-1/top-5 准确率差多少检测任务看框的 IoU 和 关键点偏移。经验值是分类模型 INT8 掉点在 1~2 个百分点点可以接受检测和姿态回归任务INT8 的坐标抖动如果超过输入尺寸的 1%比如 320 输入下抖动超过 3 像素用户就能察觉就要考虑退回 FP16。这种量化后的降级评估不要靠感觉要把数据贴在技术方案里否则前端同事改版本号时根本不知道改了精度。6.3 降级方案矩阵每个用户都应该有能跑的路我前文反复提到降级上线前必须把它落成一张可执行的表格。核心逻辑是探测浏览器能力然后选择匹配的模型和参数。浏览器能力推荐后端输入分辨率模型档位目标帧率支持 WebGPUWebGPU640×640高精度大模型30FPS仅支持 WebGL2WebGL2FP16480×480中模型/INT830FPS仅 WASM SIMDWAsm320×320小模型/INT815FPS老旧设备JS 兜底224×224超小模型仅做静态图推理这个矩阵看起来简单但每个格子都要真实跑一遍。我在一次交付里发现支持 WebGPU 的 Chrome 跑大模型反而比 WebGL 中模型更慢原因是该设备 GPU 驱动对 Compute Shader 调度有缺陷。所以表格只是起点上线前每个档位都要用代表性设备实测。6.4 上线演练让浏览器处于最坏状态再压测发布会前我习惯打开几个 CPU 占用高的后台标签页让机器先热起来再启动自己的 AI 页面做一次完整流程接着切几次后台标签页看webglcontextlost是否触发、恢复是否正常再用 DevTools 的 CPU 节流模拟低端机性能。这些演练能暴露大多数正常情况下根本不会出现的线上问题。最后还有一个容易忽略的点摄像头权限被用户拒绝后怎么办。没有摄像头权限视觉 AI 产品不应该直接白屏。我通常会把产品降级成上传图片分析模式至少用户还能用静态图走一遍完整链路。别小看这个兜底它撑住了不少用户第一次打开就是拒绝授权的尴尬场景。整个流程走完消灭了白屏、崩溃、卡顿、精度异常这些硬伤之后把神经网络塞进浏览器标签页这件事才算真正落地。对我来说端侧视觉 AI 的工程真相其实就是真正的难点并不在网络结构设计而是如何在浏览器这个资源有限、环境复杂、随时可能被系统回收的舞台上让模型稳定地跑起来。所有框架和工具都只是帮你把这段路走得更稳一些剩下的边界条件还是要靠一个又一个标签页去踩出来。