LensVLM：把长上下文压成图像，只展开相关页面

长上下文的两笔开销

处理长文档，模型要付两笔开销。token 数量直接决定注意力的计算量和显存占用，上下文越长，代价涨得越快。另一笔更隐蔽：很多文档本来就是版面化的——PDF、扫描件、幻灯片、带表格的报告。先把它转成纯文本再喂给模型，等于先做一次有损转换，然后再让模型在丢掉版式信息的文本上推理。

视觉编码是个折中方案。一页文档渲染成图片，交给视觉编码器压成数量有限的视觉 token，通常远少于同一页的完整文本 token 数。代价是细节被压掉，小字号、公式、密集表格最先受损。

把整份文档压着，只让少数页面“显影”

模型名里的 Lens 对应“用图像压上下文”，副标题的 expand only relevant pages 说明它并不打算让所有页面都停在压缩状态。整份文档先以低成本的图像形式存在，系统再根据当前问题，把少数相关页面还原成更完整的信息，交给模型细读。

这等于把检索和阅读压进一次前向流程：先用廉价表示扫全局，判断哪几页值得花算力，再对这几页付高分辨率或高 token 的代价。对比常见的两段式做法——先切块、再用向量检索挑片段——它试图保住版面本身的线索：标题层级、表格对齐、图表位置。这些在纯文本切块时经常被切断，而它们往往正是理解一份文档的入口。

公开信息里没说的部分

可核对的内容很少：发布方是 Apple，模型名 LensVLM-9B，命名里的 9B 通常指向参数量级，另有 Hacker News 上 76 分、7 条评论的讨论。至于相关页面怎么判定、展开后是重新编码成视觉 token 还是走 OCR 转成文本、在哪些长文档基准上验证过，从标题和链接里都看不出来。

这些细节决定了方法能否成立。页面级的相关性判断一旦出错，错误会直接传导到最终答案，而这种错误比检索错段落更难被发现——压缩后的图像本身就是不透明的表示，人很难回头检查模型究竟“看”到了什么。另一个取舍在渲染分辨率：分辨率提高，视觉 token 变多，压缩省下来的算力又被吃掉一部分。

上下文以什么形态存在

Hacker News 上这条发布拿到 76 分、7 条评论，讨论规模不大，更像有人在模型页上发现一个值得琢磨的方向。它提出的问题比它给出的答案具体：长文档进入模型之前，应该以什么形态存在？纯文本、页面图像，还是两者的混合，取决于任务对细节的敏感度。

把整份文档压成图像、只让少数页面显影，是顺着这个问题的工程选择。它省下的是那些“暂时不用细看”的页面的成本，赌的是模型有能力在低分辨率表示上做出足够好的取舍判断。这个赌注是否成立，要看后续公开的评测、消融实验，以及它在真实 PDF 和扫描件上的表现。