← 上一篇 · 让 AI 只当测光表的 SDR→HDR
Lumora · Distillation & Real-time Player

Lumora 实时 HDR 播放器:
把每帧 40 秒的转换,蒸馏进 9 毫秒

我们把"AI 测光表"从 GPU 服务器上的大管线,蒸馏成一个 5.11M 的轻量模型,部署到 Mac 的神经引擎(ANE); 又围绕它构建了原生实时播放器 Lumora——载入 SDR 片源,即以 HDR 亮度实时播放。 本页讲两件事:小模型是怎么训练出来的,以及播放器是怎么设计的

8.88 ms
小模型单帧推理(M4 Max 神经引擎)
0.9423
HDRTV1K 学术基准 SSIM(反超大管线)
0 帧
增益与画面的时间错配(实测)
≤1/1024
与参考链的逐像素差(10bit 灰阶,1024 级中差 1 级)
PART 1 · 给所有人

教师–学生蒸馏:方法概述

我们已有一条经过验证的 SDR→HDR 转换管线(见上一篇): 用视频大模型 LTX 当"测光表",算出画面每个区域该提多亮。问题是它太慢——一帧要 40 秒,只能在服务器上离线跑。 实现实时化采用深度学习中成熟的模型压缩方法:知识蒸馏(knowledge distillation)

教师模型(Teacher):LTX 增益图管线

  • LTX 视频大模型 + 全套安全护栏
  • 精度高,但单帧耗时 40 秒(服务器 GPU)
  • 输出:增益图——逐区域亮度提升系数构成的低频场

学生模型(Student):轻量增益网络

  • 参数量仅 5.11M 的卷积网络
  • 训练目标单一:以教师输出为监督信号,从 SDR 帧直接预测增益图
  • 单帧 8.88 毫秒,较教师管线提速约 4600 倍
SDR 原片帧 8bit,较暗 学生网络 5.11M 参数 8.88 ms / 帧 增益图 "哪里该提多亮" 低分辨率的亮度地图 × 原片像素(一个不改) HDR 画面 高光亮起来
学生网络仅输出增益图,画面像素恒取自原片 —— 模型不生成任何像素内容(无虚构),该性质由教师管线按构造继承。

训练数据:教师管线自动标注

监督学习通常受制于标注成本。本方案无需人工标注:教师管线对一部电影与一套公开测试集批量推理, 自动产出 2078 组「SDR 帧 → 参考增益图」训练样本对;单次训练仅 33 分钟。 更换片源后,训练集可按同一流程自动扩充。

速度:三个数量级的跨越

每帧耗时(对数刻度,越短越好) 41 秒 教师管线:LTX(服务器 GPU) 88 ms 学生模型 v0(28M 参数) 8.88 ms ≈ 112 帧/秒 学生模型 v1.1(5.11M,神经引擎)
对数刻度:每短一段是 10 倍提速。41 秒 → 8.88 毫秒,约 4600 倍

值得注意的结果:学生模型在未见基准上反超教师系统

在训练未见域的学术基准 HDRTV1K 上,学生模型(SSIM 0.9423)超过了包含 LTX 的完整教师系统(0.9117)。 机制:生成式教师存在逐样本随机性,单次输出含噪;学生在大量样本上回归教师输出的条件期望,等效于对教师噪声做平均。 该现象在蒸馏文献中已有报道,本项目在增益图任务上给出了定量验证。

PART 2 · 训练迭代史

版本迭代:v0 → v1 → v1.1

每个版本解决一个明确的问题。单次训练 33 分钟,迭代成本低——主要成本在于确定正确的评测口径

v0 · 证明可行

28M 参数88ms
  • 首训即在未见域全指标反超教师推理链
  • 但太大太慢,离实时还差一个量级

v1 · 瘦身 + 提纯

5.11M(↓5.5×)8.88ms
  • 结构全面改为神经引擎友好(静态形状等)
  • 修数据泄漏(按镜头分组切分训练/验证)
  • 质量与 v0 持平——瘦身零损

v1.1 · 高光修复

峰值比 0.60→0.863
  • 问题:模型对最亮高光的增益预测偏保守(绿管、手术灯等区域提升不足)
  • 解法:损失函数里加"峰值分位项",专盯最亮的 0.5% 像素
方法论记录:v1.1 调参时,我们一度被自己定的验收规则误导——按"验证集 RMSE 必须 ≤0.11"的硬线, 修好高光的那一档(w_peak=0.15)会被否决,因为它 RMSE 涨到 0.137。但把误差按增益高低分桶一看:涨幅几乎全在高增益桶 (正是我们想让它大胆的地方),低增益桶几乎不动。RMSE 由约 77% 的低增益像素主导,作为验收硬线并不代表部署质量; 改以最终评测指标(学术基准 SSIM + 专业母版亮度对标)重新判定,该档全部通过、当选。 教训:代理指标不能当硬线,验收规则要盯部署时真正在乎的量
模型参数量HDRTV1K SSIM ↑高光峰值比 ↑单帧耗时(M4 Max)
LTX 完整系统(教师推理链)~2B(大模型)0.91171.00(基准)~41 s(服务器 GPU)
学生模型 v028M0.94190.6088 ms
学生模型 v1.1(现役)5.11M0.94230.8638.88 ms(神经引擎)
教师 GT 上界 0.9507;母版亮度校准漂移 2.1%(≤5% 线)。全部数字为实测,平台已标注。
PART 3 · 实时播放器 LUMORA

Lumora 播放器设计:两条流水线,一次乘法

有了 9 毫秒的学生网络,还需要一个边解码边转换的实时播放器。核心设计:逐像素运算全部由 GPU 承担,网络推理置于异步支路—— 增益在解码时刻提前算好,画面在显示时刻逐帧渲染,两者只在「×增益」一步汇合。

硬件解码 VideoToolbox · 零拷贝 出帧当刻,先送去算增益 ↗ ↘ 经帧队列排队,等待显示 增益支路 · 解码时刻提前算(异步,不占帧预算) GPU 下采样 1080p → 512×288 学生网络推理 神经引擎 CoreML · ≈9 ms 增益环形表 按帧时间戳(PTS)存入 显示哪帧,就查哪帧的增益 —— PTS 精确配对 像素支路 · 显示时刻逐帧渲染(Metal 单遍 shader,纯点运算) 线性化 sRGB → 线性 × 增益 增益纹理上采样 色域转换 709 → 2020 F_APC 色度 自适应提饱和 EDR 输出 线性 >1.0 = HDR EDR 直显 HDR 亮度上屏
全程 GPU 常驻:解码帧零拷贝进 Metal,增益支路不占帧预算,1080p60 实测零掉帧。

关键设计 ①:PTS 精确配对——增益和画面必须"同一帧"

早期版本用"最新可用增益"策略:渲染时拿手头最新算完的增益凑合用。结果切镜头/亮度突变时, 增益比画面慢 200–400 毫秒,肉眼可见"亮度跟不上画面"。重构后:解码器一出帧就为它算增益、 按时间戳(PTS)存表;显示哪帧,就查表取哪帧的增益——错配按构造归零。频闪测试片互相关实测:滞后 0 帧。

旧 · 最新可用 —— 增益与画面错位 画面帧 应用的增益 帧 N 帧 N+1 帧 N+2 增益 N−3 增益 N−2 增益 N−1 渲染时抓手头最新算完的增益 → 落后 3–10 帧; 切镜头/亮度突变时肉眼可见"亮度追画面"(慢 200–400 ms)。 新 · PTS 精确配对 —— 增益与画面同一帧 画面帧 应用的增益 帧 N 帧 N+1 帧 N+2 增益 N 增益 N+1 增益 N+2 === 解码领先 ≥5 帧,增益提前算好、按 PTS 存表; 显示哪帧查哪帧 → 滞后 0 帧(频闪测试片互相关实测)。 可行性依据:网络推理约 9 ms,而解码领先显示至少 1 帧(实测 16–40 ms)——增益总能在显示之前就绪。

关键设计 ②:golden parity——"和参考答案逐位对"

播放器里的整条数学链(线性化、增益、色域、色度增强、PQ/EDR)是用 Metal 重写的,怎么保证和服务器上验证过的 Python 参考链一模一样?我们不靠眼睛:让播放器把一帧的处理结果按 10bit 码值原样吐出来,与参考链对同一帧的输出 逐像素做差。验收线:99% 的像素差异不超过 2 个码值(10bit 每通道共 1024 级)。现役 12 组配置(色度开/关 × 多档位 × 多片源)实测 99% 像素差异均 ≤1 个码值——即 1024 级中仅差 1 级,远低于肉眼可辨阈值。 shader 里的每个常量都由脚本从 Python 源码自动生成,禁止手抄——两边永远同源。

问题排查案例:零拷贝纹理的生命周期缺陷

现象:播放中画面剧烈抖动,抖动帧看起来是"画面被放大"。排查发现是零拷贝纹理的生命周期问题: 解码帧的显存(IOSurface)在还在屏幕上显示时,就被解码器的缓冲池回收去写未来帧了——推镜头里领先几帧的未来帧, 恰好就是当前画面的"放大版",于是抖动看起来像缩放。修复:显示路径持有像素缓冲直到 GPU 用完(双持有 + 一帧宽限)。 结论:零拷贝资源的所有权边界必须显式管理;异常的具体表现形态(此处为"放大")本身即是定位根因的关键线索。

正在收尾

吞吐打磨增益命中率从 97.4% 向 99.5% 收口(去 CPU 转置/回读)
色度三档播放器对齐生产的 off / F_APC / B 三档色度增强(F_APC 已有,补 B)
A/B 分屏SDR|HDR 左右分屏对比 + 30 分钟连播浸泡测试
电视芯片L3 路线启动:模型正在向 MTK Pentonic 700(MT9655)NPU 移植——输入位深实验进行中

PART 4 · 给技术同事

技术优势清单

维度我们的做法为什么这是优势
无虚构保证AI 只输出低频增益场,像素 = 原片 × 增益按构造不产生新内容(chromaErr≡0),过审风险为零;蒸馏后该性质原样继承
蒸馏目标只学增益图,不学像素输出空间低频、低维 → 5.11M 就够;学生回归教师输出的条件期望、平均掉逐样本噪声,未见域反超
训练数据生成教师管线自动标注,2078 对零人工护栏烘进标签;换片源即扩容;33min/次的迭代速度
部署形态CoreML/ANE fp16 静态形状,全算子神经引擎常驻8.88ms,GPU 全留给像素链;架构从 v1 起就为 NPU 设计(静态上采样、ReLU)
实时架构双速率解耦 + PTS 精确配对 + 全 GPU 常驻增益不占帧预算;错配按构造为 0(互相关实测);1080p60 零掉帧
质量体系golden parity(逐位)+ 学术基准 + 专业母版对标 + 频闪互相关每次改动都有客观回归线,不靠眼睛;验收规则盯"真裁判"
可扩展性同一教师可蒸馏不同档位/输入域(桌面 CoreML 版与电视 NPU 版并行)L2 工作站已落地,L3 电视端(MT9655/NeuroPilot)推进中

本页数字均为实测:训练/评测在 H20 服务器,推理耗时在 M4 Max;学术基准 HDRTV1K 117 帧为训练未见域; 母版对标以 ASC StEM2 专业 HDR 母版为参照。撰写日期 2026-07,后续里程碑(gainMiss 收口、B 档、A/B 分屏、MT9655 移植)完成后本页会更新。