这篇论文回答了一个很工程的问题：当大模型「看图」的部分跑在手机上、「思考」的部分跑在云端时，中间必须传过去的那坨数据，到底能压多小。结论是：砍掉 98%，模型的理解能力几乎不变——直到某个点，再压就整体崩掉。
问题：中间特征成了要花钱的数据
看图的多模态大模型（VLM，能同时读图和文字的模型）分两步干活：视觉编码器先把图像或视频变成一串向量，行话叫视觉 token，可以理解为「图像被拆成的信息单元」；语言模型再读这串向量去推理。整套模型太大，手机跑不动「想」的那半截；而把原图原片整个传上云，带宽、时延、隐私三头都难受。
于是出现一种端云分工的部署：设备只跑视觉编码器，云端跑语言模型。这时视觉 token 不再是网络内部的一堆数字，而是要在网络上传输的数据——论文给这类「机器消费的中间张量」起了个名字：AI 流量。
麻烦在于没人认真量过它：这部分数据究竟需要多少比特？现有做法要么裸传原始帧，要么为切分后的模型专门训练一个压缩模块，又贵又不通用。
方法：拿现成的国际标准反着用
这篇论文的转折在于：不造新压缩器。作者直接搬来 MPEG 家族里的国际标准 NNC（ISO/IEC 15938-17，神经编码——一套给神经网络数据编码的规范，原本是用来压缩网络权重的），反过来压网络中间的特征。
实验平台是 Qwen3-VL-8B（80 亿参数量级的开源视觉大模型）做视频问答：视觉接口一路输出主视觉 token，还有几路特征会在不同深度注入语言模型。论文把这些张量逐路「编码→传输→解码」，全程不训练、不动权重和提示词，只来回扫压缩强度 QP（量化参数，调得越大压得越狠）。
结果是一条「平台期—悬崖」曲线：在视频问答基准 Video-MME 上，准确率直到压掉 98% 比特都贴着不压缩的基线，之后突然崩塌；开放式问答（MLVU，让另一个大模型当裁判打分）也是同样的形状。
真正的发现：AI 不在乎精确的数值
更值钱的是后半句。解码回来的张量其实「错」得很厉害：数值被强量化、逐行相对误差不小、奇异值衰减也变陡——但任务精度照样不掉。也就是说，下游推理依赖的是粗结构和相对几何关系，不是精确的浮点值。
这把评价标准改写了：压「给 AI 看的数据」，不该追求「压得像不像」（码率-失真），而该看「压完之后任务还对不对」（码率-任务）。前者是给眼睛设计码流的老逻辑，后者才是 AI 流量自己的逻辑。
会进哪些真实工作流
- 拍摄设备：手机、相机、门禁和监控摄像头可以只跑视觉编码器，原片不出设备，上云的是一包高度压缩的「语义码流」。相册搜索、云端修图建议、随身 AI 助手都能走这条路，隐私和带宽同时受益。
- 编解码产业：继给「人眼」设计码流之后，出现了给「模型」设计的码流。码率控制的优化目标要从 PSNR 这类画质指标换成任务精度，这是标准组织绕不开的新问题。
- 模型设计：既然下游只用粗结构，视觉 token 在训练时也许就应该被设计成「天生可压缩」的表征，而不是训完再找压缩器。
局限与存疑
只测了一个模型、两类视频问答任务，「平台期—悬崖」的形状能否推广还未知；悬崖点的位置随模型和任务移动，落地时「能压多少」没有安全公式。NNC 本是为权重设计的工具，拿来压特征属于「能用」，未必高效——按「码率-任务」目标专门设计的编码器大概率能把悬崖再往外推。这也正是这篇论文真正留给后续工作的题目。