大模型影像这两年一直在学同一件事：把没拍到的细节"生成"出来。这篇论文反着来——让语言大模型把一张图一比特不差地"存"回去，而且顺手拆掉了这条路线里最别扭的一步。
先说无损压缩在做什么。JPEG 这类有损编码把像素"大意"掉换体积；医疗影像、遥感底片、相册原图走的是另一条路，解出来必须和原来逐比特一致。无损压缩的骨架其实只有两件东西：一个预测器，加一台"算术编码器"——把预测概率变成比特的机器，越料得到的值花越少的比特。所以压缩率的胜负手全在预测器准不准。
过去两年确实有人把预测器换成语言大模型（LLM），思路很直接：把像素值当文字，“255"按字符切开喂进去。毛病也一样直接。LLM 的正门是 tokenizer（把文字切成 token 的分词器），它是为自然语言设计的，不是为数字设计的：同一个像素值在不同家族的模型里会被切成不同的 token，接口互不通用；连"一个数占几个 token"都不确定。压缩器要在这种地基上算概率，先天吃亏。
LUMI 的转折就一句话：不进正门，走侧门。它把每个像素值写成七个数的短描述——中心化亮度、平方项、一组正弦与余弦、通道身份——用一个小 MLP 直接映射进 LLM 的 embedding 层，也就是模型读入文字之前那个连续向量入口。像素被拉平成一维序列会丢掉二维位置，就给每行每列配可训练的位置编码补回来；序列前面再拼一段"软前缀”（一段不供人阅读、只帮模型对齐任务的可训练向量）。骨干模型整个冻结、一个参数不动，只训练这几个小零件；出口处把词表换成一个 256 路预测头，输出"下一个像素值是 0–255 里哪一个"的分布，交给算术编码变成比特。
解码端不需要额外存任何东西：用同一个冻结模型、同一套小零件，确定性地算出同样的分布序列，逐像素按顺序还原。这也是它敢叫"无损"的底气——预测不需要完美，只需要解码方算出的概率和编码方一模一样。
成没成？在自然图像（Kodak）、病理切片、遥感三个领域上，同一套接口接 LLaMA、Qwen、Gemma 三个家族，码率都低于 JPEG-XL，也追平或超过"像素当文字"的 LLM 前辈。更值得注意的是换到训练时没见过的领域：它自己的码率几乎不掉，“像素当文字"的基线却明显退化——赢在跨域稳，不是单点更高。骨干从 0.6B 换到 14B、训练数据加量，码率单调变好——这是基础模型该有的曲线，不是专用编码器的。
对影像行业，这套东西的落点大概率不在你手机里，在档案室。相册原图库、医疗 PACS、遥感底片这类"一次写入、长期保存、绝不能变"的存储，长期被 JPEG-XL 这类为图像特制的编码器把持。LUMI 给出另一种分工：一个冻结的通用大模型当共享概率引擎，每个领域只训一小套适配器——编码器厂商卖适配器，而不是卖整台编码器。再往远一步想，压缩和生成本是一体两面：模型要能一比特不差地还原，前提是它能极其准确地预测下一块像素，而预测下一块像素正是生成能力的另一半。同一份权重白天当生成引擎、夜里当归档引擎，不是科幻结构，是同一套概率的两种用法。
冷静的部分也得说。LUMI 按 16×16 的小块独立编码，块与块之间的长程相关没吃到，所以论文里的绝对码率（Kodak 上 8.56 对 JPEG-XL 的 8.95）只有在同一套小块协议下比较才有意义，离工程级无损编码的真实水平还有距离。吞吐是另一道现实门槛：解码要跑同等的 LLM 前向、逐像素自回归，批量归档的耗时和电费都得在云端算账。短期内这是档案室的技术，不是相册 App 的——但"通用模型借来的预测器"能不能追平"为图像特制的预测器”，这条线现在才刚开始往上走。