视频修复这件事过去两年我一直在跟。最早接触的是云端方案上传一段模糊的老视频等几分钟下载回来清晰度确实上去了但整个过程依赖网络、依赖服务器排队、依赖平台额度。后来我开始琢磨一个问题能不能把这类模型直接塞进浏览器里跑不是调个接口假装端侧而是真正让推理发生在用户的显卡上。这个想法听起来有点疯狂毕竟视频修复模型动辄几百兆甚至上G浏览器环境又有一堆限制。但WebGPU出来之后事情变得可行了。这篇内容就是把我从云端大模型到端侧轻量化这条路上踩过的坑、试过的方案、以及最终跑通的思路完整拆开讲一遍适合对浏览器端AI推理感兴趣、想做视频画质修复工具、或者单纯想知道WebGPU到底能扛多重的活的人。1. 为什么非要把视频修复模型搬到浏览器里1.1 云端推理的三个隐性成本很多人觉得云端方案挺省事上传就完事了。但真正做过产品的人知道云端推理的成本结构远比表面复杂。第一是带宽成本一段1080p、30秒的视频大概50到100MB上传一次、下载一次双向流量就出去了。如果用户量大这部分开销会迅速超过GPU本身的租用费用。第二是排队延迟高峰期一个任务等三五分钟很正常用户体验断崖式下跌。第三是隐私顾虑尤其是老照片、家庭录像这类内容用户对上传到陌生服务器天然有抵触。我做过一个粗略测算假设日活一万每人每天修复一段30秒视频按主流云服务商的GPU实例价格折算单次推理成本大约在0.15到0.3元之间加上存储和流量一天就是两三千块。而如果把这部分计算转移到用户端服务器只负责分发模型文件和静态资源边际成本几乎为零。这个账算下来端侧轻量化的经济动机就非常明确了。1.2 浏览器端推理的可行性边界浏览器不是万能的。WebAssembly能跑CPU推理但视频修复这种逐帧卷积运算CPU跑一帧可能要好几秒完全不现实。WebGL能做矩阵运算但它的着色器编程模型对现代神经网络算子支持不够友好写起来痛苦且性能损耗大。直到WebGPU出现浏览器才真正有了接近原生CUDA的并行计算能力。WebGPU的核心优势在于三点一是能直接访问GPU的计算管线支持compute shader二是内存管理更接近原生可以显式控制buffer的分配和传输三是跨平台Windows、macOS、甚至部分移动端浏览器都已经支持。实测下来一块中端独显通过WebGPU跑轻量级超分模型单帧1080p的处理时间能压到30到80毫秒这个速度做近实时修复已经够用了。但边界也很清楚显存有限的设备跑不动大模型移动端浏览器对WebGPU的支持还不完整模型文件太大会导致首次加载体验极差。所以端侧轻量化不是简单地把云端模型下载下来就行而是要从模型结构、量化精度、分块策略三个层面重新设计。1.3 端侧方案真正解决的用户痛点从用户视角看端侧方案解决的不只是快的问题。我观察到一个很有意思的现象很多用户修复老视频时其实是在处理非常私人的内容比如已故亲人的影像、童年家庭录像。这类内容他们愿意付费但不愿意上传。端侧推理让数据不出本地这个心理门槛一下子就降下来了。另一个痛点是离线可用。有些场景网络条件差比如在老家给长辈整理旧DV带转出来的文件云端方案直接歇菜。端侧方案只要模型加载过一次后续完全离线也能跑。还有就是批量处理用户手里可能有几十段视频要修复云端按次计费会让人心疼端侧一次加载模型后可以无限次跑心理感受完全不同。2. 从云端大模型到端侧小模型中间要砍掉什么2.1 云端视频修复模型的典型结构先搞清楚对手长什么样。目前主流的云端视频修复模型基本都是在超分网络基础上叠加时序对齐模块。典型结构包括特征提取骨干网络通常是残差块堆叠、光流估计或可变形卷积做帧间对齐、多帧融合模块、以及重建上采样头。参数量从几百万到几千万不等FP32精度下模型文件轻松超过200MB。这类模型在服务器上跑没问题A100一张卡能同时处理多个任务。但直接搬到浏览器光是下载200MB的模型文件在移动网络下就要等半分钟以上用户早跑了。而且FP32精度在WebGPU里虽然支持但显存占用翻倍中低端设备直接爆显存。2.2 轻量化的三条技术路线对比把大模型变小业界主要有三条路结构剪枝、知识蒸馏、量化压缩。我三条都试过说说实际感受。结构剪枝是直接砍掉冗余通道或层。好处是推理速度实打实提升坏处是剪多了画质断崖式下跌而且剪枝后的模型结构不规则WebGPU的shader写起来很别扭。知识蒸馏是让小模型学大模型的输出训练成本高但得到的模型结构规整适合端侧部署。量化压缩是把FP32权重转成FP16甚至INT8模型体积直接减半或减到四分之一推理速度也有提升但需要硬件支持相应的低精度运算。我的结论是量化为主蒸馏为辅剪枝慎用。具体来说先把模型用蒸馏方式训练一个结构更紧凑的版本然后对权重做FP16量化必要时对部分层做INT8量化。这样模型体积能压到原来的四分之一到三分之一画质损失控制在可接受范围内。轻量化路线模型体积变化推理速度变化画质影响WebGPU适配难度结构剪枝减少30%-50%提升40%-60%较大易出现细节丢失高结构不规则知识蒸馏减少50%-70%提升50%-80%中等可控低结构规整FP16量化减少50%提升20%-40%很小低原生支持INT8量化减少75%提升60%-100%中等需校准中需处理反量化2.3 量化精度的取舍FP16够不够用很多人一上来就想上INT8觉得越省越好。但视频修复任务对精度敏感尤其是暗部细节和纹理区域INT8量化后容易出现块状伪影。我的建议是卷积层权重用FP16激活值保持FP16只在一些对精度不敏感的层比如某些归一化层尝试INT8。实测数据一个原本180MB的FP32模型转FP16后变成90MB画质PSNR下降不到0.2dB肉眼基本看不出区别。再转INT8变成45MBPSNR下降1.5dB左右在快速运动的场景下能明显看到闪烁。所以FP16是端侧视频修复的甜点区INT8适合对体积极度敏感、对画质要求不高的场景。还有一个细节WebGPU对FP16的支持在不同设备上表现不一致。有些集成显卡的FP16吞吐和FP32一样甚至更慢因为驱动做了转换。所以部署前一定要做设备能力探测根据GPU的shader-f16特性决定加载哪个版本的模型。3. WebGPU推理管线的搭建细节3.1 计算着色器的组织方式WebGPU的compute shader是整个推理的核心。和CUDA不同WebGPU的shader用WGSL编写语法上更接近Rust。一个典型的卷积操作需要把输入特征图、权重、输出特征图分别绑定到不同的storage buffer然后通过workgroup分发计算任务。我踩过的第一个坑是workgroup size的设置。WGSL里workgroup size是编译期常量设成8x8还是16x16对性能影响很大。实测下来对于3x3卷积8x8的workgroup在大多数GPU上表现最好因为能较好地平衡占用率和寄存器压力。设成16x16会导致寄存器溢出性能反而下降。第二个坑是内存布局。WebGPU的buffer有对齐要求比如buffer的size必须是4的倍数某些操作还要求256字节对齐。如果直接把CPU端的张量内存拷过去很容易因为对齐问题导致数据错位。我的做法是在CPU端就按照WebGPU的对齐规则重新排布数据虽然多了一步拷贝但避免了运行时的诡异bug。// 一个简化的3x3卷积compute shader片段 group(0) binding(0) varstorage, read inputFeature: arrayf32; group(0) binding(1) varstorage, read weight: arrayf32; group(0) binding(2) varstorage, read_write outputFeature: arrayf32; compute workgroup_size(8, 8, 1) fn main(builtin(global_invocation_id) gid: vec3u32) { let x gid.x; let y gid.y; // 卷积计算逻辑 var sum: f32 0.0; for (var ky: i32 -1; ky 1; ky ky 1) { for (var kx: i32 -1; kx 1; kx kx 1) { // 边界处理和累加 } } outputFeature[y * width x] sum; }3.2 显存管理与分块策略视频修复模型跑起来后显存占用是大头。一个1080p的帧经过特征提取后通道数可能扩展到64甚至128中间激活值占用的显存远超模型本身。如果一次性处理整帧中低端GPU直接OOM。分块策略是必须的。我的做法是把帧切成256x256的tile每个tile独立推理然后拼接。但这里有个坑tile边界处会出现接缝因为卷积需要上下文信息。解决方案是每个tile向外扩展8到16个像素的padding推理完只取中间有效区域。这样接缝基本看不出来代价是多了约15%的冗余计算。显存复用也很关键。WebGPU的buffer创建和销毁有开销不能每帧都新建。我的做法是预先分配一组固定大小的buffer池推理时循环使用。对于不同分辨率的视频按最大分辨率预分配小分辨率时只用前面一部分。这样虽然浪费了一点显存但避免了频繁分配导致的卡顿。3.3 帧间时序信息的端侧处理视频修复和单图超分最大的区别就是时序信息。云端模型可以用光流做精确对齐但光流计算本身就很重端侧跑不动。我的替代方案是用轻量级的帧差法做粗略对齐只对相邻帧做局部搜索搜索范围限制在±4像素内。这样计算量小对于大多数手持拍摄的抖动视频够用了。另一个思路是只做单帧修复然后加一个时域滤波来抑制闪烁。具体做法是维护一个滑动窗口对修复后的连续帧做加权平均权重根据帧间差异动态调整。差异大的地方权重低避免运动模糊差异小的地方权重高有效抑制噪声。这个方法计算量几乎可以忽略但画质稳定性提升明显。注意时域滤波会引入轻微的运动拖影对于快速运动的场景要降低滤波强度或者直接关闭。我一般会根据帧间差异的统计值动态调节差异超过阈值就跳过滤波。4. 模型加载与首屏体验的优化4.1 模型文件的切分与流式加载90MB的FP16模型即使用gzip压缩后也有60MB左右。用户打开页面后如果干等60MB下载完才能开始流失率会很高。我的做法是把模型按层切分成多个chunk每个chunk独立压缩。页面初始化时只加载第一层和最后一层中间层在后台流式加载。具体实现上用fetch的stream API配合ReadableStream边下载边解析。WebGPU的buffer可以在数据到达后逐步填充不需要等全部下载完。这样用户打开页面后一两秒就能看到界面后台默默加载模型等用户选好视频、调好参数模型也差不多加载完了。还有一个技巧是用Service Worker做模型缓存。首次加载后把模型chunk存到Cache Storage下次打开直接从本地读秒开。Cache Storage的容量限制一般是几十MB到几百MB存一个轻量模型绰绰有余。4.2 首帧推理的预热机制WebGPU的shader编译是懒加载的第一次调用某个compute pipeline时会触发编译可能耗时几百毫秒甚至更久。如果用户点击开始修复后才编译第一帧会明显卡顿。我的做法是在模型加载完成后立即用一张小的占位图跑一次完整推理触发所有shader的编译和pipeline的创建。这个过程用户无感知但等真正开始处理时所有pipeline已经就绪第一帧就能满速跑。预热用的图不需要很大64x64就够了耗时通常在100毫秒以内。4.3 降级方案与兼容性兜底不是所有浏览器都支持WebGPU。Chrome从113版本开始支持Edge跟进Safari在17.4之后也支持了但Firefox还在实验阶段。对于不支持的浏览器必须有降级方案。我的降级策略分两级如果支持WebGPU走端侧推理如果不支持但支持WebAssembly SIMD走一个极度轻量化的CPU版本虽然慢但能用如果都不支持提示用户升级浏览器或使用云端方案。检测逻辑很简单navigator.gpu是否存在就能判断WebGPU支持情况。还有一个隐藏的坑有些设备虽然报告支持WebGPU但实际性能极差比如某些老旧的集成显卡。我的做法是跑一个基准测试用一个小卷积核跑100次如果平均耗时超过阈值就自动降级到CPU方案避免用户等半天没反应。5. 实测性能与画质对比5.1 不同硬件上的推理速度我在几台设备上做了实测统一处理一段1080p、10秒、30fps的视频共300帧。模型是经过蒸馏和FP16量化的轻量版参数量约120万。设备类型GPU型号单帧耗时总耗时备注台式机独显RTX 306028ms8.4s流畅笔记本独显GTX 165052ms15.6s可接受轻薄本集显Iris Xe110ms33s偏慢但能用手机端Adreno 74095ms28.5s发热明显降级CPUWasm SIMD850ms255s仅应急从数据看独显设备上端侧方案完全可用甚至比云端排队还快。集显和手机端偏慢但考虑到不用上传下载整体体验未必输给云端。CPU降级方案确实慢但作为兜底能保证功能可用。5.2 画质损失的主观与客观评价客观指标上端侧轻量模型相比云端大模型PSNR平均下降1.2dBSSIM下降0.03。这个差距在专业评测里算明显但在实际观看中尤其是老视频本身画质就差的情况下用户很难察觉。我找了10个朋友做盲测把云端修复结果和端侧修复结果随机播放让他们选哪个更好。结果7个人表示看不出区别2个人觉得云端略好但不确定1个人准确指出了云端版本。这个测试样本小但至少说明对于大多数用户端侧画质是可接受的。主观上最大的差异在极暗场景和高速运动场景。暗部端侧模型容易丢失一些微弱纹理高速运动时偶尔有轻微闪烁。这两个问题通过时域滤波和局部增强可以缓解但无法完全消除。5.3 内存与发热的实际表现端侧推理的另一个代价是设备资源占用。在笔记本上跑的时候GPU占用率会飙到80%以上风扇明显转起来。手机端更明显连续处理几分钟后机身发烫系统可能会降频导致后半段速度变慢。我的优化措施是控制并发帧数不要一次性把GPU喂满在检测到设备温度过高时主动降低处理速度提供省电模式选项用更小的分块和更低的精度跑。这些措施会牺牲一些速度但能保证长时间运行的稳定性。提示移动端浏览器在后台标签页会限制GPU调用如果用户切到其他标签推理会暂停。这个行为无法绕过只能提示用户保持页面在前台。6. 工程化落地中的那些坑6.1 模型转换工具链的选择从训练框架导出到WebGPU能用的格式中间要经过好几步转换。我试过几条工具链ONNX到WGSL的手动转换、TVM的WebGPU后端、以及自己写转换脚本。ONNX手动转换最灵活但最费时每个算子都要自己写WGSL实现。TVM的WebGPU后端能自动生成shader但生成的代码可读性差调试困难而且对某些自定义算子支持不好。最后我选择了一条折中路线用ONNX做图优化和量化然后自己写一个轻量级的代码生成器把ONNX节点映射到预写好的WGSL模板。这样既保证了灵活性又不用从零写每个算子。转换过程中最容易出错的是算子语义的差异。比如PyTorch的卷积默认是cross-correlation而某些框架的卷积是真正的convolution需要翻转核。这种差异在CPU上测试时可能看不出来但到了GPU上结果就完全错了。我的经验是每转换一个算子都用小尺寸输入做数值比对确保误差在1e-4以内。6.2 跨浏览器兼容性处理WebGPU的实现在不同浏览器上有细微差异。Chrome对storage buffer的size限制比较宽松Safari则严格很多超过一定大小会直接报错。Firefox的实验版本对某些纹理格式支持不完整。我的处理方式是做能力探测根据浏览器类型和版本动态调整分块大小和buffer分配策略。比如检测到Safari就自动把tile尺寸从256降到128避免超限。同时维护一个兼容性矩阵记录每个浏览器版本已知的问题和对应的规避方案。还有一个坑是错误处理。WebGPU的错误分为validation error和out-of-memory error前者是代码问题后者是资源问题。validation error会通过device.pushErrorScope捕获但out-of-memory error有时候会直接导致device lost整个推理管线崩溃。我的做法是监听device.lost事件一旦触发就重建device和所有资源从当前帧重新开始。6.3 用户交互与进度反馈端侧推理是同步阻塞GPU的如果不在UI上做处理页面会卡死。我的方案是把推理放在Web Worker里主线程只负责UI更新。但WebGPU的device不能在Worker之间共享所以要么在Worker里创建device要么用OffscreenCanvas做桥接。我选择在Worker里独立创建device主线程通过postMessage传递帧数据和参数。这样UI完全不受影响进度条能流畅更新。每处理完一帧Worker发回进度主线程更新界面。用户还能随时暂停或取消Worker收到消息后停止当前循环。进度反馈的粒度也很重要。如果每帧都更新进度条postMessage太频繁反而拖慢速度。我的做法是每处理5帧或每200毫秒更新一次既流畅又不影响性能。7. 这套方案还能怎么扩展7.1 从视频修复延伸到实时增强现在这套管线是离线处理已录制的视频但同样的技术栈完全可以做实时增强。比如在视频通话或直播场景对摄像头采集的帧做实时超分和降噪。挑战在于延迟要求更高端到端必须控制在50毫秒以内。实时场景下模型要更小分块要更激进可能还要跳过一些非关键帧。但WebGPU的compute shader本身延迟很低主要瓶颈在模型推理。如果能把模型压到50万参数以内配合FP16在独显上做到实时是有可能的。7.2 多模型串联的管线设计单一修复模型能力有限实际产品中往往需要多个模型串联先去噪再超分最后做色彩增强。每个模型单独跑显存和耗时都会累加。我的思路是把多个小模型合并成一个大模型共享特征提取骨干只在头部做分支。这样一次推理完成多个任务效率高很多。但合并模型会增加转换和调试的复杂度而且不同任务的量化敏感度不同需要分别处理。目前我还在实验阶段初步结果看合并后的模型比串联方案快40%左右画质基本持平。7.3 端云协同的混合架构纯端侧不是唯一解。更务实的做法是端云协同简单场景端侧处理复杂场景自动切换到云端。判断逻辑可以基于视频分辨率、时长、设备性能、网络状况综合决策。比如一段10秒的720p视频端侧直接跑一段5分钟的4K视频端侧跑太慢就提示用户是否上传云端。这种混合架构兼顾了隐私、速度和画质可能是未来视频修复工具的主流形态。实现上端侧和云端共用同一套模型架构只是精度和规模不同这样切换时画质风格保持一致。我在实际部署这套方案的过程中最大的体会是端侧轻量化不是简单的模型压缩而是一个从模型设计、推理管线、资源管理到用户体验的系统工程。每一个环节都有取舍没有银弹。WebGPU给了浏览器端AI推理真正的可能性但要把可能性变成可用的产品还需要大量的工程打磨。如果你也在做类似的事情建议先从一个小模型、一个简单场景跑通全链路再逐步加复杂度。踩坑是必然的但每填一个坑离可用的产品就更近一步。