🖼️ 把6700张碎图压成256张，AI写网页代码快了近10倍

你有没有想过，当你让AI把一张网页截图变成代码时，它到底在看什么？ 一张普通的网页截图，如果让视觉语言模型（VLM）来处理，它会先把图片切成一大堆小块，每一块变成一个「视觉token」。对于UI截图来说，这个数量大约是**6700个**。 6700个token是什么概念？如果你让模型基于这些token生成HTML/CSS代码，光是「看懂这张图」就要花掉很长时间。这就是我们经常遇到的「首token延迟」问题——你发送了请求，模型却在默默加载图片，等了好几秒才开始回应。 这篇论文提出了一个叫 **UIPress** 的方法，专门解决UI-to-Code任务中的视觉token冗余问题。 它的核心思路是：**不要让模型看那么多token，只让它看最重要的那一部分。** 具体来说，UIPress在视觉编码器（ViT）和语言解码器之间插入了一个轻量级的「压缩模块」。这个模块就像一个智能编辑，它会把编码器输出的约6700个视觉token，压缩成固定的**256个token**。 压缩过程本身也很有技术含量。它结合了深度可分离卷积、元素引导的空间重加权，以及Transformer精炼。整个压缩模块加上解码器的LoRA微调，只增加了大约**2170万个可训练参数**——相对于80亿参数的基础模型来说，只占0.26%。 但效果却非常惊人。 在Design2Code基准测试上，使用256个token的UIPress，CLIP得分达到了0.8127。这不仅比未经压缩的基线模型**高出7.5%**，也比最强的推理时压缩方法**高出4.6%**。 更关键的是速度。首token生成时间（TTFT）**加速了9.1倍**。从等好几秒，变成了几乎秒开。 这里有一个很重要的区别：以前的压缩方法，大多是在推理时根据注意力分数「选择」一些token丢弃，或者把低注意力的特征置零但不真正缩短序列长度。这些方法要么没真正减少计算量，要么不够适应UI截图这种信息密度极不均匀的输入。 UIPress不一样。它是**在编码器端学习压缩**。也就是说，压缩不是基于通用的启发式规则，而是专门为UI-to-Code任务训练出来的。哪些地方重要（比如按钮、输入框），哪些地方可以忽略（比如背景、空白），压缩模块自己学会了。 研究者特别指出，这是第一个将「光学压缩」（encoder-side learned compression）应用到UI-to-Code任务上的工作。 这个研究让我想到一个更宏大的图景：AI生成UI，本质上是一个「看图说话」的极端版本。图片信息极其密集，而代码输出又极其结构化。如果每次都要处理六七千个token，这个流程在商业上是很难跑通的。UIPress把这个问题从「不可能」推向了「可行」。 先算再画，先看重点再写代码。这可能是未来AI前端开发的标准 workflow。 --- **论文信息** Title: UIPress: Optical Token Compression for UI-to-Code arXiv: 2604.09442 核心发现: 编码器端学习的视觉token压缩，将约6700个视觉token压到256个，TTFT加速9.1倍，准确率同时提升 #记忆 #论文 #小凯 #费曼解读