1. 从云端到端侧视频修复模型轻量化的核心思路拆解视频修复这件事过去几年一直是云端大模型的专属领地。像 Wink 这类云端视频修复服务背后跑的是动辄几十亿参数的超分重建网络一张 1080P 的帧要经过多尺度特征提取、光流对齐、时序融合、细节生成好几个阶段单帧推理就得占用可观的显存和算力。用户上传视频排队等云端 GPU 跑完再下载回来整个链路依赖网络带宽和服务端资源调度。这套模式效果确实好但问题也很明显上传下载耗时、隐私数据离开本地、免费额度有限、批量处理成本高。灵狐视频画质修复工具走的是另一条路——把修复模型直接塞进浏览器在用户自己的设备上完成推理。这件事听起来像是“把大象装进冰箱”但拆开看核心就三件事模型压缩、推理引擎适配、浏览器端工程化。我实际折腾过一轮之后发现真正难的不是把模型跑起来而是让它在普通笔记本的核显上也能跑到可接受的帧率同时画质不能崩得太厉害。先说说为什么选浏览器作为端侧载体。浏览器天然跨平台Windows、macOS、Linux 甚至移动端都能跑同一套代码不用为每个系统单独打包。WebGPU 的成熟让浏览器第一次有了接近原生 CUDA 的并行计算能力计算着色器可以直接操作 GPU 缓冲区矩阵乘、卷积这些操作不再需要绕道 WebGL 的纹理渲染管线。再加上 WebAssembly 做 CPU 侧的兜底和调度整个技术栈就齐了。端侧轻量化的核心矛盾在于模型要小到能在浏览器里加载和推理但修复效果又不能比云端差太多。我的思路是分三步走。第一步把云端大模型的知识蒸馏到一个中等规模的学生网络里保留多尺度结构和时序模块但通道数砍到原来的四分之一到三分之一。第二步对卷积层做结构化剪枝把冗余的通道整条去掉再用少量数据做微调恢复精度。第三步量化到 FP16 甚至 INT8权重体积直接减半到四分之一推理速度也能提升不少。这里有个关键取舍时序模块要不要保留。视频修复和单图超分最大的区别就是时序一致性如果只做逐帧处理画面会闪烁运动区域会出现果冻效应。但时序模块比如光流对齐或者可变形卷积计算量很大端侧很难扛住。我的做法是保留一个轻量级的时序融合模块用相邻帧的特征做加权平均不做显式光流估计牺牲一点运动补偿精度换取推理速度。实测下来在大多数场景下画面稳定性够用只有快速运动和大面积遮挡时会有轻微瑕疵。另一个取舍是分辨率处理策略。云端模型通常直接处理整帧端侧如果也这么干显存和算力都吃不消。我采用分块推理加重叠融合的方案把一帧切成 256x256 的块块之间留 32 像素的重叠区每块单独推理后再用加权平均拼回去。这样显存占用可控而且可以并行处理多个块。重叠区的存在是为了消除块边缘的接缝权重用余弦窗或者高斯窗中间高两边低融合后过渡自然。注意分块推理时块的尺寸和重叠区大小需要根据模型感受野来定。如果感受野大于块尺寸块边缘的特征提取会不完整导致接缝明显。一般建议块尺寸至少是感受野的两倍重叠区至少等于感受野。这套方案的整体流程是视频解码用 WebCodecs 拿到 VideoFrame转成纹理上传到 GPU推理在 WebGPU 的计算管线里跑分块处理每一帧修复完的帧再通过 WebCodecs 编码回视频文件。整个链路都在浏览器内完成不上传任何数据。下面我会把每个环节拆开讲包括模型怎么改、WebGPU 管线怎么搭、性能怎么调。2. 模型轻量化实操从云端大模型到浏览器可跑的版本2.1 知识蒸馏让小学生网络学会老师的本事云端大模型之所以强是因为它在海量数据上训练过特征提取能力非常强。直接拿一个小网络从头训练很难达到同样的效果。知识蒸馏的思路是让大模型当老师小模型当学生学生不仅学真实标签还学老师的中间特征和输出分布。具体到视频修复任务我设计了两个蒸馏损失。一个是输出蒸馏用老师的修复结果作为软标签学生网络的输出和软标签做 L1 损失。另一个是特征蒸馏在网络的中间层加一个适配层把学生的特征图映射到和老师同样的通道数然后做均方误差。特征蒸馏的权重不用太大0.1 到 0.2 就够了太大反而会限制学生网络自己的表达能力。蒸馏的训练数据我用的是公开的视频超分数据集加上一些自己收集的压缩视频片段。每段视频取连续 7 帧作为一个样本输入是低质帧输出是中间帧的高质版本。训练时老师网络冻结只更新学生网络。学习率用余弦退火从 1e-4 降到 1e-6大概跑 20 万步左右收敛。这里有个坑蒸馏后的学生网络虽然比从头训练的好但和老师比还是有差距尤其是高频细节的恢复能力。我的补救措施是在蒸馏之后再加一个对抗训练阶段用一个轻量级的判别器判断修复结果是否真实生成器也就是学生网络尽量骗过判别器。对抗损失权重设小一点0.01 左右不然会引入伪影。2.2 结构化剪枝砍掉冗余通道但不伤筋动骨蒸馏完的学生网络还是有点胖通道数虽然砍了但卷积层里有很多通道的权重接近零对输出贡献很小。结构化剪枝就是把这些通道整条去掉连带后面的 BN 层和激活函数一起删网络结构直接变窄。剪枝的流程分三步。第一步用 L1 范数衡量每个通道的重要性把重要性低的通道标记出来。第二步按比例剪枝我一般从 20% 开始逐步增加到 50%每次剪完都做一轮微调。第三步微调时用原来的训练数据学习率调小到 1e-5跑几万步让网络适应新的结构。剪枝比例不能一刀切。浅层卷积的感受野小通道冗余度高可以多剪一些深层卷积的通道承载了更多语义信息剪多了精度掉得厉害。我的经验是浅层剪 40%中间层剪 30%深层剪 20%。另外残差连接两端的通道数必须一致剪枝时要同步处理不然加法操作会报错。剪枝后的模型体积大概能降到原来的三分之一推理速度提升 40% 左右。精度方面PSNR 掉 0.2 到 0.3 dB肉眼基本看不出来。如果对精度要求高可以少剪一点用速度换质量。2.3 量化FP16 和 INT8 的选择与实操量化是端侧轻量化的最后一步也是收益最明显的一步。FP32 的权重占 4 字节FP16 占 2 字节INT8 占 1 字节。模型体积直接按比例缩小推理时的内存带宽压力也小很多。WebGPU 目前对 FP16 的支持比较好计算着色器里可以直接用 f16 类型。我把卷积层的权重和激活都转成 FP16推理速度大概提升 30% 到 50%精度损失很小PSNR 掉 0.1 dB 以内。转换方法很简单用 ONNX 导出模型后用工具把权重转成 FP16再重新导出。注意有些操作对 FP16 敏感比如 softmax 和 layer norm这些地方保持 FP32 计算避免数值溢出。INT8 量化更激进但需要校准数据来确定每一层的缩放因子。我用 100 张左右的低质帧做校准统计每层激活的分布用 KL 散度找最优的截断阈值。INT8 推理在 WebGPU 上需要手动实现反量化把 INT8 乘加结果转回 FP32稍微麻烦一点。实测下来INT8 模型体积是 FP16 的一半速度再提升 20% 左右但 PSNR 掉 0.5 dB 以上快速运动场景会有轻微色带。我的建议是如果设备性能足够优先用 FP16如果显存紧张或者要跑在移动端再考虑 INT8。精度模型体积推理速度PSNR 损失适用场景FP32基准基准0云端或高端桌面FP1650%30%~50%0.1 dB主流笔记本、核显INT825%50%~70%0.5~1.0 dB移动端、低端设备提示量化后的模型一定要做端到端测试不能只看 PSNR。有些伪影在指标上不明显但肉眼很敏感比如天空区域的色带、人脸区域的涂抹感。测试时多准备几种场景动画、实拍、夜景、快速运动。3. WebGPU 推理管线搭建从纹理上传到结果回读3.1 WebGPU 初始化与计算管线配置WebGPU 的初始化从请求适配器和设备开始。适配器代表物理 GPU设备是逻辑接口。请求设备时可以指定需要的特性比如 shader-f16 用于 FP16 计算timestamp-query 用于性能分析。const adapter await navigator.gpu.requestAdapter({ powerPreference: high-performance }); const device await adapter.requestDevice({ requiredFeatures: [shader-f16], requiredLimits: { maxComputeWorkgroupStorageSize: 32768, maxStorageBufferBindingSize: 256 * 1024 * 1024 } });计算管线的配置包括着色器模块、绑定组布局、管线布局。着色器用 WGSL 编写卷积操作可以用循环展开加共享内存优化。绑定组里放输入纹理、输出纹理、权重缓冲区、偏置缓冲区。权重缓冲区用 storage buffer 存储因为卷积核的访问模式是随机的用纹理采样反而慢。管线创建时要注意 workgroup 大小的选择。太小了并行度不够太大了寄存器压力大。我的经验是 8x8 或者 16x16 比较合适具体看卷积核大小和通道数。对于 3x3 卷积8x8 的 workgroup 每个线程处理一个输出像素共享内存里缓存输入块的 10x10 区域减少全局内存访问。3.2 视频帧的解码、上传与预处理浏览器里解码视频用 WebCodecs 的 VideoDecoder。配置好编解码器、分辨率、帧率后把压缩数据喂进去就能拿到 VideoFrame 对象。VideoFrame 可以直接作为纹理源用 copyExternalImageToTexture 上传到 GPU 纹理。const decoder new VideoDecoder({ output: (frame) { const texture device.createTexture({ size: [frame.displayWidth, frame.displayHeight], format: rgba8unorm, usage: GPUTextureUsage.TEXTURE_BINDING | GPUTextureUsage.COPY_DST | GPUTextureUsage.RENDER_ATTACHMENT }); device.queue.copyExternalImageToTexture( { source: frame }, { texture: texture }, [frame.displayWidth, frame.displayHeight] ); frame.close(); }, error: (e) console.error(e) });预处理包括归一化和通道重排。视频帧是 RGBA8修复模型需要的是 FP16 的 RGB 三通道数值范围 0 到 1。这一步可以在着色器里做也可以单独跑一个预处理管线。我倾向于在着色器里做省一次纹理读写。归一化就是除以 255通道重排就是把 RGBA 的 A 通道丢掉只保留 RGB。3.3 分块推理与重叠融合的实现细节分块推理的核心是把大帧切成小块每块单独跑模型再把结果拼回去。切块时要注意边界处理块与块之间要有重叠重叠区的大小取决于模型的感受野。我的模型感受野大概是 60 像素左右所以重叠区设 32 像素块尺寸设 256x256。推理时每个块作为一个 workgroup 或者一组 workgroup 来调度。WebGPU 的 dispatchWorkgroups 可以指定三维的 workgroup 数量我把块索引映射到 x 和 y 维度通道映射到 z 维度。每个块推理完后结果写到输出纹理的对应位置。重叠区的像素会被多个块写入需要做加权平均。加权平均的权重用余弦窗块中心权重为 1边缘权重为 0过渡平滑。实现时可以在着色器里根据像素在块内的位置计算权重也可以预计算一个权重纹理。我用的方法是预计算因为余弦窗的计算涉及三角函数放在着色器里每帧算太浪费。// 融合着色器片段 let weight weightTextureSample(uv); let newValue textureSample(blockTexture, uv); let oldValue textureLoad(outputTexture, coord); let blended oldValue * (1.0 - weight) newValue * weight; textureStore(outputTexture, coord, blended);注意重叠融合时如果多个块的权重之和不为 1需要做归一化。我的做法是维护一个权重累加纹理每次融合时把权重加进去最后统一除以权重和。这样即使块与块之间重叠不规则也能保证结果正确。3.4 结果回读与视频编码推理完的帧在 GPU 纹理里要编码回视频需要先回读到 CPU。WebGPU 提供了 mapAsync 方法可以把缓冲区映射到内存。但纹理不能直接映射需要先拷贝到缓冲区。拷贝时用 copyTextureToBuffer格式要匹配RGBA8 纹理对应 4 字节每像素的缓冲区。回读是异步操作需要等待 mapAsync 的 Promise resolve。回读后的数据是 ArrayBuffer可以构造 ImageData再创建 VideoFrame最后喂给 VideoEncoder 编码。编码器配置要和输入视频一致码率可以适当调高因为修复后的画面细节更多压缩太狠会浪费修复效果。const buffer device.createBuffer({ size: bytesPerRow * height, usage: GPUBufferUsage.COPY_DST | GPUBufferUsage.MAP_READ }); commandEncoder.copyTextureToBuffer( { texture: outputTexture }, { buffer: buffer, bytesPerRow: bytesPerRow }, [width, height] ); await buffer.mapAsync(GPUMapMode.READ); const data new Uint8ClampedArray(buffer.getMappedRange()); const imageData new ImageData(data, width, height); const frame new VideoFrame(imageData, { timestamp: ts }); encoder.encode(frame);整个管线跑起来后瓶颈通常在回读和编码阶段因为这两步涉及 CPU 和 GPU 之间的数据搬运。优化方法是双缓冲或者三缓冲推理完一帧就开始回读同时推理下一帧让 GPU 和 CPU 并行工作。4. 性能调优与常见问题排查实录4.1 性能瓶颈定位用 timestamp-query 找热点WebGPU 的 timestamp-query 特性可以给每个计算通道打时间戳精确到纳秒。开启后在管线里插入 timestampWrites跑完后读回时间戳缓冲区就能知道每个阶段花了多少时间。我实测下来一个 1080P 视频的修复管线各阶段耗时大概是解码 5ms上传 3ms推理 40ms回读 8ms编码 10ms。推理是大头占了 60% 以上。推理里面卷积层又占 70%时序融合占 20%激活函数和归一化占 10%。所以优化重点在卷积。卷积优化的手段有几个。一是用 Winograd 算法减少乘法次数3x3 卷积用 F(2x2, 3x3) 可以省 2.25 倍乘法。二是用共享内存缓存输入块减少全局内存访问。三是把多个卷积层融合成一个着色器减少中间结果的读写。我试过融合两层卷积速度提升 15% 左右但着色器复杂度上去了调试麻烦。4.2 显存不足与纹理分配策略浏览器里显存是有限的尤其是核显共享系统内存可用显存可能只有几百 MB。1080P 的 RGBA8 纹理一张就是 8MB如果同时存在输入、输出、中间特征、权重很容易爆显存。我的策略是复用纹理。输入纹理和输出纹理可以共用一块内存因为推理完输入就不需要了。中间特征图用纹理池管理用完就还回去下次分配时优先复用。权重缓冲区是常驻的不参与复用。另外分块推理时块纹理可以设小一点256x256 的 RGBA8 纹理只有 256KB几十个块同时存在也才几 MB。如果显存还是不够可以降低分块尺寸或者把 FP16 换成 INT8。再不行就减少时序融合的帧数从 7 帧降到 3 帧显存占用能降一半。4.3 常见问题速查表问题现象可能原因排查方法解决方案画面闪烁时序融合未生效检查时序模块是否被剪枝保留时序融合层降低剪枝比例块边缘接缝重叠区太小增大重叠区测试重叠区至少等于感受野推理速度慢卷积未优化用 timestamp-query 定位启用 Winograd优化共享内存显存溢出纹理未复用监控显存分配复用输入输出纹理缩小分块颜色偏差归一化错误检查预处理着色器确认除以 255RGB 顺序正确编码后画质下降码率太低对比修复帧和编码帧提高编码码率用高质量预设WebGPU 初始化失败浏览器不支持检查 navigator.gpu降级到 WebGL 或提示用户升级4.4 实操心得与避坑技巧第一个坑是着色器的循环展开。WGSL 里写 for 循环编译器不一定会展开导致性能差。我的做法是手动展开把 3x3 卷积的 9 次乘加写成 9 条语句编译器就能更好地优化。但展开太多会导致着色器编译时间变长甚至编译失败需要平衡。第二个坑是 FP16 的精度问题。有些 GPU 对 FP16 的除法支持不好会丢精度。我的做法是除法用 FP32 算算完再转回 FP16。另外累加操作最好用 FP32避免多次累加后误差累积。第三个坑是视频帧的时间戳。WebCodecs 的 VideoFrame 需要正确的时间戳不然编码出来的视频会音画不同步。时间戳从解码器输出里拿单位是微秒直接传给编码器就行。如果自己构造 VideoFrame时间戳要按帧率递增。第四个坑是浏览器的后台标签页限制。当标签页切到后台时requestAnimationFrame 会暂停但 WebGPU 的计算不受影响。如果推理是在 rAF 回调里触发的切后台后就会停。我的做法是用 Web Worker 跑推理Worker 不受标签页可见性影响可以持续处理。提示Web Worker 里不能直接访问 DOM 和 WebCodecs 的部分 API需要用 postMessage 和主线程通信。VideoFrame 是 Transferable 对象可以直接转移给 Worker避免拷贝。5. 端侧轻量化的边界与后续扩展方向端侧视频修复不是要完全替代云端而是提供一个隐私友好、零延迟、零成本的选项。它的边界在于模型规模有限极端场景比如严重压缩、大面积损坏的修复效果不如云端大模型设备性能参差不齐低端设备可能跑不动 1080P只能降到 720P 甚至 480P。后续可以扩展的方向有几个。一是自适应分辨率根据设备性能动态调整处理分辨率高端设备跑 4K低端设备跑 720P用户体验一致。二是多模型切换内置轻量、标准、高质量三个模型用户根据需求选择。三是利用 WebNN 做硬件加速WebNN 可以直接调用 NPU比 WebGPU 更省电适合移动端。我在实际使用中发现端侧修复最适合的场景是老视频翻新、监控录像增强、UGC 内容上传前的预处理。这些场景对隐私敏感或者对延迟要求高云端方案不合适。而电影级修复、专业调色这些场景还是云端大模型更合适。最后分享一个小技巧如果视频很长可以只修复关键帧中间帧用插帧算法生成。这样推理量能降一半以上画质损失也不大。插帧可以用光流法也可以用简单的帧混合看你对运动平滑度的要求。