这篇论文有意思的地方，不是又造了一个更快的压缩算法，而是把压缩这件事的「收件人」换掉了：被压的东西不给人看，只给模型看。
先看今天大模型「看视频」的真实跑法。模型分两步：第一步由视觉编码器把画面折成一串「视觉 token」——可以理解为模型内部对画面内容的数学摘要，每段画面变成一长串浮点数；第二步语言模型拿着这串摘要和你的问题组织出答案。第一步轻、第二步重，所以端云分工顺理成章：手机在镜头旁边负责「看」，云端的大模型负责「想」，中间传的是 token 而不是视频。这条路线叫拆分推理（split inference），诱人之处在于甚至可以完全不传视频本身。
卡点是：这串 token 从没被当成「要上网传输的东西」设计过。它是模型内部激活——一大块 16 位浮点数组成的矩阵，要同时装下空间内容、时间变化和事件顺序，体量不小；人看的视频有几十年积累的压缩标准兜底，机器看的中间特征却只能裸传。于是要么吃带宽，要么把整个大模型塞进手机。
作者的招式朴素得近乎大胆：直接套现成的国际标准。ISO/IEC 15938-17，俗称神经网络编码（NNC），是 MPEG 为压缩神经网络参数与特征制定的工具，不需要任何训练，只留一个量化参数（QP，控制压得多狠的旋钮）可调。他们把 Qwen3-VL 的完整视觉接口——主视觉 token 加三路注入语言模型的辅助特征流——原样插进「编码→解码」往返，权重、提示词、生成过程一个字不动，再把 QP 从松到紧扫一遍。
结果是一条「平台期—悬崖」曲线。视频问答基准 Video-MME 上，准确率贴着未压缩基线一路走到码率砍掉约 98% 才开始跳水；换开放式的视频总结任务、用 GPT-4 当裁判打分，曲线形状不变。两个对照把侥幸解释堵死了：把 token 直接清零，准确率从 0.74 崩到 0.21，说明模型真的在读这堆信息，不是瞎蒙；平台期里输出格式完好，掉分也不是解析失败造成的。
更有意思的是那记反问：压到 98% 时，解码出来的 token 早已面目全非——量化痕迹很重、逐行相对误差不小、奇异值衰减明显变陡。所以这不是「压得够准所以没事」，而是模型推理本来就不依赖精确浮点值，依赖的是粗结构和向量之间的相对几何关系。论文据此提出一个主张：评价这类流量的压缩，别再问「重建得多像」（率-失真），要直接问「下游任务掉几分」（率-任务）。
往真实工作流推一步：AI 相册搜索、视频摘要、监控问答这类产品，可以在端侧只跑视觉编码器，把压缩后的 token 发上去，通信成本降一两个数量级，云端照样答题。再往大里看，「AI 流量」可能成为网络里新的一类载荷：今天的码率控制、CDN 和上行带宽都为「人看的内容」设计，而机器看的内容正在爬满上行链路。这次用的是现成标准，端侧芯片可以做统一硬件编解码，不必每家模型自带私有 codec——对不同厂商模块要互相拼装尤其要紧。
存疑处也要说清。实验只覆盖一个模型、两个视频问答基准的子集，开放式打分还依赖另一个大模型当裁判，「98%」别当成普适常数；换成细粒度计数或画面文字识别这类任务，平台期多半窄得多。论文也没测真实网络的丢包与延迟，更没和「在端上直接剪 token」这类替代方案比带宽-精度曲线。而平台期紧贴悬崖，作者自己建议部署时配得保守些——实际能省多少带宽，取决于你的任务肯让掉几分。