这篇论文把「要压缩的东西」从像素换成了大模型眼里的画面：设备传给云端的不再是照片，而是模型自己的中间特征——并且用一套现成的国际标准证明，这东西压掉 98% 也照样能用。
手机拍一段视频想让云端大模型帮忙答疑，现在只有两条老路：要么把整个语言模型塞进设备——塞不下；要么把视频用 H.265 这类像素码流传上云，云端再从头跑一遍视觉编码器——带宽和算力都花了两遍。
论文押注的是第三条路：设备端只跑视觉编码器，云端只跑语言模型，中间传的不是像素，而是编码器吐出的那排「视觉 token」——把画面切成小块后，每块的内容概括成一个高维向量，一排向量就是模型眼里的这张图。问题在于这排向量又密又长：它们原本是模型内部的激活值，一旦要在设备之间传输，就从「免费的中间结果」变成了网络上实打实的负载，而没人管它的码率该是多少。作者给这类在 AI 模块之间流动的张量起了个名字：AI 流量（AI traffic）。
转折一：不发明新压缩器，直接借用 MPEG 为「搬运神经网络数据」制定的国际标准 ISO/IEC 15938-17（NNC，神经网络编码；参考实现叫 NNCodec，熵编码用的是与 H.26x 同族的 CABAC 算术编码）。整个流程不动模型权重、不动提示词、不动生成过程：Qwen3-VL-8B 的视觉模块产出 4 路张量——主视觉 token 加 3 路辅助特征——各自独立编码、传输、解码，再原位塞回语言模型，只旋一个控制压缩强度的量化参数 QP——数字越大压得越狠。
结果是一条「平台—断崖」曲线：比特压掉 87%，视频问答准确率纹丝不动；压掉 98%，准确率从 0.74 掉到 0.72，几乎可以忽略；再往回收几档，就直接跳崖到 0.49。把 token 全部置零则只剩 0.21——说明模型确实在认真读这排向量，不是对输入麻木。
更有意思的是第二个转折：掉点少，不是因为「重建得准」。解码出来的张量数值被砸成一级一级的离散台阶，逐行相对误差不小，奇异值衰减也更陡（信息的有效维度更低）。换句话说，语言模型读的从来不是精确浮点值，而是这排向量的粗结构和彼此的相对关系。所以作者主张：AI 流量的编码目标不该是「重建误差小」（码率—失真），而该是「任务不掉点」（码率—任务）。
对影像行业，这条链路可能比论文本身更有分量。AR 眼镜和手机拍摄助手一旦走「端上理解、云端生成」的拆分架构，上行传的就是语义码流而不是像素码流，带宽省一个数量级；云侧影像服务的计费与体验保障也得从「按张图」改成「按 token 比特」。更进一步，码率—任务意味着码率跟着任务走：问答类任务能压到 98%，但云端精修、重绘这类要吃精确数值的生成任务未必扛得住——未来的拍摄系统里可能同时存在好几档「特征画质」，就像今天相机里选存储格式。
存疑的地方也要说清：这是一篇 4 页短文，只测了一个模型、两个视频问答基准（Video-MME 与 MLVU 的摘要子集）、每个 100 条样本；全部结论落在「理解」任务上，而生成与编辑类任务对数值精度敏感得多，98% 的压缩率未必迁移得过去。「码率—任务」目前也只是被论证了必要性，论文并没有给出按任务优化编码的方法；曲线又是断崖式的，工程落地时该留多少安全余量、换一代模型要不要重新标定，都还是问号。但「AI 流量需要自己的编码标准」这个判断，大概率会被反复引用。