低光增强LLIELow-Light Image Enhancement这两年突然被各方提上日程原因其实不复杂——处理器再强也架不住用户喜欢在晚上拍视频、打视频电话、深夜扫码买单。很多团队第一反应是上大模型但一到端侧实测延迟、内存、发热三个问题直接把人劝退。我去年在一台骁龙平台的开发板上试跑过某个以GAN为主的增强方案640×480输入推理一次要接近80ms别说插进视频预览连做静态图片处理都有点悬。后来换了一条思路用只有180个浮点参数的 UltraFast-LiNET 走端侧实时LLIE推理效果反而出人意料地稳。这篇文章把我复现、训练、部署这套方案的完整过程写出来包括网络结构怎么理解、导出量化时有哪些坑、真机延迟功耗是什么水平希望对正在做端侧AI硬件部署、或者对轻量化图像增强感兴趣的朋友有参考价值。本文不会堆一堆没有上下文的技术名词目标是把每个决策背后的原因讲透让你能直接拿去用。1. 项目背景与需求拆解1.1 LLIE 到底在解决什么问题低光增强不是简单的“把图片调亮”。我平时处理这个任务时会习惯性地把它拆成三个子问题亮度重建、噪声抑制、色彩恢复。夜间拍摄的素材普遍整体欠曝如果只是把亮度拉伸起来暗部噪声会同步放大色彩饱和度也会失真最终出来的图要么发灰要么发黄。传统算法比如直方图均衡化HE和 CLAHE本质上是统计灰度分布再做重映射在很多夜景场景下都会出现区域性过曝、伪影和奇怪的色偏。深度学习模型这两年之所以能在 LLIE 上表现更好核心原因是它有能力学习从低光图到正常光照图之间更复杂的映射关系。但这里我要强调一个容易忽略的事实LLIE 的要害是“把亮度和对比度映射做对”它和语义分割、目标检测这类需要“理解场景内容”的任务在本质上有很大区别。模型不需要知道画面里是人还是车只需要把像素从暗区映射到亮区同时保持色彩和纹理自然。这个差异决定了低光增强完全可以做得很轻而不是必须依赖大规模网络。1.2 为什么“端侧实时”是刚需而非加分项端侧实时不是噱头而是大量产品场景里的硬约束。我举几个实际遇到过的例子夜间视频通话如果要加增强每帧留给算法的预算通常只有30ms左右否则画面就会掉帧安防摄像头用的是嵌入式NPU内存按MB计算塞不进一个几百MB的大模型手机拍照预览则对功耗极其敏感不能让后盖在十分钟内变成暖手宝。所以我们做端侧LLIE部署时本质上是在同时和三个预算较劲延迟预算、内存预算、功耗预算。这些年端侧AI硬件部署发展速度很快手机SoC上不仅有CPU、GPU还集成了专门的NPU和DSP算力并不是完全不够用。真正的瓶颈往往在算法侧——模型结构如果不考虑端侧约束层数一多、算子一杂再强的硬件也跑不出实时效果。换句话说端侧实时不是一个“能不能做”的问题而是一个“算法愿不愿意为硬件妥协”的问题。1.3 180个参数的构思来源查表法与全局映射的启示我第一次看到180这个数字时反应很直接这怕不是蒸馏后的极简网络后来仔细看了思路发现它其实从传统图像处理里的 LUT查找表方法借鉴了很多。LUT的做法是把输入像素亮度值映射到新的亮度值整张表就是几百个数字虽然效率极高但由于缺乏自适应性复杂场景下效果不够好。UltraFast-LiNET 用180个可学习参数去拟合一种“更聪明的映射”相当于同时保留了查找表的高效率和神经网络非线性表达的能力。低光增强核心是亮度重建这个映射本质上是一个全局函数和像素在画面里的位置关系不大因此并不需要一堆3×3卷积去提取空间特征。用极小的全连接结构加上少量1×1卷积就足够完成从“暗像素值”到“亮像素值”的拟合。这个想法和很多轻量超分方案在哲学上是一致的先分析任务特点再设计网络结构而不是拿一个通用骨架硬套。2. UltraFast-LiNET 的网络结构与训练策略2.1 180个参数都用在了哪里为了做部署我自己复现过一版网络结构这里说明一下不同资料里对细节的描述会有些差异但参数数量级和整体思路是一致的。我用的结构是 3→8→7→7→3 的逐点卷积骨架第一层用1×1卷积把RGB三通道升维到8通道参数是 3×8832中间两层用1×1卷积做非线性映射8×77 和 7×77 加起来是119最后一层用1×1卷积把7通道映射回3通道参数是 7×3324。三部分相加是175剩下5个参数我用在了全局亮度仿射变换上用来根据输入帧的亮度统计做自适应增益调整凑在一起正好180。这个结构里最关键的一点是整个网络没有任何普通卷积全部是1×1卷积和逐点操作。有人会问1×1卷积不就是在通道维度上做全连接吗确实如此。这也是这个模型能保持极端轻量的根本原因——没有空间卷积意味着没有空间感受野参数自然少得可怜。那局部信息怎么办答案是降噪和纹理重建都交给前后处理和损失函数去兜底模型本身专注做好逐点亮度映射这一件事。2.2 蒸馏数据与训练细节低光增强的公开数据集其实不少比如 LOL、VE-LOL 这类成对数据但真正难搞的是暗部区域的细节能不能在训练中被有效约束到。我实际采用的做法是先用一个大模型来当 teacher我用的是 MIRNet 的轻量版在低光图像上先生成高质量的增强结果然后把它当作软标签去训练 UltraFast-LiNET。蒸馏的好处是大模型已经学会了复杂的增强映射和去噪策略学生模型只需要模仿它的行为不需要自己从零摸索收敛速度和最终效果都会好很多。损失函数我搭配了三部分。第一部分是 L1 重建损失保证输出和参考图在像素级别上接近第二部分是感知损失LPIPS让模型学到的纹理分布更接近人类的主观感知单靠 L1 出来的图容易偏平滑加上感知损失之后细节会更自然第三部分是颜色一致性损失用 RGB 三个通道的均值差来衡量色偏这个Loss在低光增强里特别重要因为夜间灯光色温复杂模型很容易整体偏黄或偏蓝。训练时我会做随机裁剪、仿射变换和亮度抖动学习率先用 1e-3 跑5个epoch热身再余弦退火到 1e-5总共训60个epoch左右稳定性和收敛速度都不错。2.3 为什么少了空间卷积反而能跑出好效果很多人看到没有3×3卷积的模型第一反应就是它能做得好吗我在初期也有同样的疑问所以专门做过一组消融实验。加一层3×3卷积确实能让 PSNR 往上走约 0.4dB但参数量直接从180跳到两万多在端侧硬件上延迟增加非常明显而且主观画质的提升很有限。低光增强这个任务里有价值的信息主要是全局亮度分布和逐像素的响应曲线模型要学的本质是一个“亮度重映射函数”更像回归任务而不是感知任务。空间感受野的主要价值在于去噪和纹理重建但去噪完全可以在前端用传统滤波解决纹理感知则靠损失函数去牵引。这两个模块被拆出去之后模型本身只剩下最刚需的逐点映射参数自然可以压到极致。所以180参数不是硬凑出来的而是把任务重新解构之后得到的合理结果。3. 端侧部署全过程从模型导出到真机运行3.1 导出 ONNX 时最容易踩的坑PyTorch 模型训练好之后第一步是把权重转到 ONNX。torch.onnx.export 本身不复杂但低光增强模型要部署到端侧固定输入分辨率比动态分辨率省心得多。我建议直接固定导出尺寸为 640×480后面再根据产品需求调整不要让动态输入成为部署链路里的不确定性因素。这一步我踩过几个实打实的坑。第一个是 torch.chunk 和 torch.split 这类操作PyTorch里写起来很方便但转成 ONNX 后会插入 Unsqueeze、Slice、Concat 等一系列算子很多端侧推理框架都不支持这些组合导致模型加载直接报错。第二个是 BatchNorm 的折叠问题如果模型里留了 BN 层且没有在导出时正确切换到 eval 模式并融合参数部署端的输出会和训练时差很多夜间画面可能整体偏绿或者亮度完全不对。第三个是 clamp 操作不同框架对 ONNX 标准 Clip 的支持程度不一致我后来直接把网络内部的 clamp 去掉把范围限制挪到后处理阶段这样导出和部署都省事。3.2 INT8 量化校准集怎么选精度掉多少180 参数的模型本身很小在 CPU 上跑 float32 其实也不慢但真正要利用 NPU 算力INT8 量化是绕不开的。量化这一步我最开始犯的错误是把训练集的增强结果拿来做校准集结果量化后的模型在真实夜间场景下画面偏色非常严重。后来才反应过来校准集必须和部署场景分布匹配于是我从夜间视频里单独抽了500帧先做直方图裁剪再作为量化校准集。PTQ训练后量化之后模型 PSNR 大约掉了0.2到0.5dB主观画质基本看不出区别。如果对效果有更高要求可以补几步 QAT量化感知训练把伪量化算子的误差代入训练过程这对模型的鲁棒性帮助很大。整个 INT8 模型文件加起来连1KB都不到实际就这么夸张——权重只有180字节算上图结构和元信息也很小。把它放在端侧工程里相当于多了几KB的占用完全可以忽略不计。3.3 推理 Runtime 选型对比端侧推理框架我先后试过 TFLite、NCNN、MNN还有厂商自研的 Runtime。这种轻量模型在哪个框架里都能跑真正影响选型的是目标平台和接入成本。TFLite 对 Android 生态的支持最完善NPU delegate 成熟度高NCNN 文档丰富配合 Vulkan 后端在 GPU 上表现也不错MNN 对 ARM CPU 的优化比较深入适合纯 CPU 场景。我自己的经验是先看目标平台有没有成熟的 NPU 接入方式高通平台走 QNNAndroid 上层走 NNAPI 或 NPU delegate。UltraFast-LiNET 的算子图特别简单——1×1卷积、全连接、激活几乎不存在“NPU不支持某个算子”的问题这使得它在端侧异构计算上非常受欢迎。如果换一个带3×3卷积的小模型算子复杂度上去了NPU 的适配难度就会明显增加所以这180参数的模型在部署层面也有很多隐藏优势。3.4 接入摄像头预览管线的实操端侧实时 LLIE 和离线图片增强最大的区别在数据链路。以 Android 为例Camera2 拿到的帧是 YUV_420_888 格式不能直接送进模型需要先转成 RGB而且这一步必须控制在几毫秒内。我用的是在 ImageReader 回调里把 YUV 转 RGB 放到 OpenGL shader 里去做转出的640×480 RGB图喂给模型模型输出后再做一个轻量的色调映射最后用 SurfaceView 渲染。这条链路在骁龙平台上全流程大概占用 8 到 12ms其中模型推理在 NPU 上只要 4 到 6ms剩下的时间主要是格式转换和渲染开销。这里有一个特别容易爆的坑回调线程里不能做任何阻塞操作而且单帧的 YUV 转 RGB 缓冲区必须提前分配好并复用否则一旦频繁触发 GC帧率会直接掉一半观感就是画面卡成PPT。4. 性能实测画质、延迟与功耗4.1 在几款常见端侧平台上的推理数据我在三款不同定位的设备上做了统一测试输入固定 640×480INT8 量化单帧推理。旗舰级骁龙平台上NPU 推理大约 4 到 6msCPU 单线程在 15 到 20ms中端海思平台 NPU 大约 8 到 10ms树莓派 4B 这种 Linux 开发板上只能跑 CPUfloat32 推理约30msINT8 约15ms。这个速度放在实时视频场景里基本都能满足30fps的要求。真正的优势不在于跑得多快而在于资源占用有多低。整个模型装载到内存里的资源占用在KB级别比起动辄几十MB的视觉模型来说几乎可以忽略不计。功耗方面旗舰手机连续跑增强预览半小时机身温度只上升了2到3度发热控制明显比跑大模型时好得多。这也是这类轻量方案在端侧最重要的竞争力。4.2 画质对比180参数 vs 传统算法 vs 大模型为了验证这180个参数不只是“跑得快但画质拉胯”我做了三组对比输入是一张典型的夜间城市街景。直方图均衡化处理完之后整体亮度上去了但天空部分过曝严重噪点被一起放大色彩发灰大模型处理结果画面干净、细节丰富但单帧推理时延接近70ms完全跑不动视频预览UltraFast-LiNET 的结果介于两者之间亮度重建比较自然墙面细节保留得不错暗部树丛区域还是有一些轻微涂抹感不过主观接受度已经很高。定量指标上我用50张夜间测试图对比了PSNR和SSIMUltraFast-LiNET 比大模型低了大约 1.2dB但比 CLAHE 算法高了 4.1dB。对于一个180参数的模型来说这个成绩非常划算。我常说端侧方案的画质目标不是“超过所有大模型”而是在延迟、功耗、内存都受限的条件下交出“可用且稳定”的结果。4.3 实际视频预览场景的主观体验跑分归跑分实际效果还得看动态场景。我拿着手机在夜晚小路上走了一圈开着增强预览最大的感受是动态稳定性比静态画质重要得多。很多模型在处理单帧时效果不错一变成视频就出现亮度抖动、色彩闪烁原因是相邻帧之间的增强曲线不一致。UltraFast-LiNET 由于参数少、映射函数平滑天然不容易出现剧烈的帧间跳变这是轻量模型被忽略的隐藏优势。为了进一步抑制闪烁我在后处理里对模型输出的亮度增益做了一段 5 帧的指数滑动平均让增强强度缓慢变化而不是突变。这段后处理逻辑只有几行代码但对主观体验的提升非常大。如果你也在做视频类的增强任务强烈建议把这个技巧加进去。5. 常见问题与排查技巧实录5.1 INT8 量化后色偏怎么办低光增强模型最容易翻车的环节就是量化后色偏。校准集选对之后一般能缓解但要彻底解决我建议做量化敏感层分析。做法是用 Netron 查看模型每个中间层的输出对比 float32 和 INT8 推理的结果找出偏差最大的层对个别敏感层保持浮点不强制 INT8。对于这种只有几层的轻量模型保持一到两层浮点运算对整体性能影响很小但能规避大部分偏色问题。我在实际项目中遇到过夜灯下的街景图量化后整体发绿排查到最后发现是中间层的一个激活输出分布特别窄量化后有效比特位太少。把那层单独拎出来保持浮点之后颜色立即恢复正常。5.2 噪声被放大、天空出现 banding 怎么办低光增强必然面对噪声问题。增强之后暗部噪点被放大或者天空区域出现色带banding这是最常见的两个画质问题。UltraFast-LiNET 本身没有去噪能力我在工程上的做法是在模型前面串联一个轻量级的非深度学习降噪模块比如引导滤波或双边滤波。这里要特别注意顺序先降噪再做亮度增强如果发现有banding可以在最后加一个轻微的抖动处理能有效打断色带。我试过在增强之后再去降噪结果彩色噪声已经被放大到很难处理的程度效果非常差所以顺序一定不能反。5.3 部分 GPU/NPU 算子不支持或驱动掉链子现在厂商的 NPU SDK 对网络结构都有一定的限制。遇到算子不支持先看算子类型——1×1卷积、全连接、激活函数这些底层算子一般都没问题问题通常出在自定义的 resize、split 以及动态 shape 操作上。我的建议是模型固定到完全静态的输入输出尺寸导出 ONNX 时把 dynamic_axes 参数全部去掉让框架做图优化时最省心。另外驱动版本也可能有坑。某些芯片平台的NPU对通道数有限制或者某个SDK版本对1×1卷积的实现有bug排查到之后最省事的办法是升级SDK或者把这个卷积拆成两个硬件支持的算子组合。遇到这种问题不要硬调模型结构先确认是不是工具的锅。5.4 夜间视频时序闪烁最后再补充说一下时序闪烁问题。前面提到了滑动平均后处理这里给一个通用的排查思路验证阶段对每一帧单独记录模型的增益曲线如果相邻帧的亮度曲线波动很大先确认输入数据是否一致排除格式转换或内存复用的错误再检查量化误差是不是在逐帧累积。如果确定是模型本身导致的帧间不稳定可以在训练时加入一个时序一致损失把连续三帧放进同一个batch在帧间输出上施加一个小约束。这个方案对参数量很小的模型效果非常显著而且训练并不需要大量视频数据几十个短片段就足够。对我来讲这属于“花小钱办大事”的典型技巧。最后再分享一个个人体会。最开始看到 UltraFast-LiNET 这种180参数方案时我也觉得“这么少参数能行吗”但真正把训练数据、损失函数、部署链路整通之后我发现低光增强这个任务天生适合小而美的设计思路。不要一上来就堆参数先分析任务的核心瓶颈是什么、端侧最缺的约束是什么往往就能找到像180参数这样极端的解法。如果你也在做端侧 LLIE 或类似的实时图像增强项目建议从固定分辨率、INT8量化、灰度预览这三个点开始卡指标跑通之后再逐步叠加功能。踩过几次坑之后你会意识到真正拖后腿的往往不是模型不够大而是部署细节没扣干净。