Note: This page does not support English, using the default language version
这件事单看很小：9 月 21 日，苹果在 Hugging Face 上放了一个叫 LensVLM-9B 的模型权重，配一份 arXiv 论文（2605.07019）和一个 GitHub 仓库。发布四天后，下载量四百多次、点赞一百来个——在模型天天刷屏的 2026 年，这个数字连水花都算不上。
但模型卡里有一栏，让它在 Reddit 的 LocalLLaMA 板块炸了：Base model，写的是 Qwen3.5-9B-Base。
一边是全球最会筑墙的硬件公司，一边是阿里的开源基座。这两个词出现在同一行，本身就值得聊。
现在很多人喜欢把上百页的 PDF 财报、技术白皮书、扫描合同直接丢给大模型，让它”看看第三十页的条款写了啥”。
传统视觉大模型的做法很笨：为了不漏细节，它会把每一页都渲染成高分辨率大图，一页一页吞进去。论文里给了一份 100 页文档的账本——直接把全文喂进去，要 51,273 个 token，KV 缓存大约 1.6GB。为了回答一个问题，你得为一个大概率用不到的第 87 页付电费。
这就是 LensVLM 要解决的那个”不划算”。
打个比方。你手里有一份 100 页合同，客户打电话问”第 42 条违约金怎么算”。正常人的做法不是从头朗读一遍，而是快速翻页，凭版式和标题定位到大概第 35 到 38 页，然后只把那几页抽出来放大看。
LensVLM 就是这套动作：先把整份文档压成 5 倍、10 倍、15 倍的低清页面图，用极低的成本扫一遍；定位到相关页面后，再调用训练时学会的工具 read_page，只把那几页展开成原始文字或高清大图。
结果很直观：那份 100 页文档，LensVLM 只用了 8,090 个 token，KV 缓存从约 1.6GB 降到 253MB，省掉 84.2%。准确率也没崩——7 项文档问答测试里，直接读全文的平均准确率是 72.4%，LensVLM 在约 4.3 倍压缩下是 68.9%。而如果只是简单地把文字缩成图片硬识别，同样约 5 倍压缩时准确率只有 31.3%。差距几乎是两倍。
论文里还有两个我挺喜欢的细节。一是展开方式分两种：渲染出来的文本用文本展开，原生文档（版式本身就带信息，比如表格位置、图注）用高清图展开。二是压缩率越高，模型越倾向于”承认自己看不清”，转而去调工具——这不是失败，是被训练出来的自觉。
代价也有：因为要跑两轮推理，一次回答约 17 秒，而直接拿整份文档喂给 Qwen3.5-9B 是 8 秒左右。省钱，但费时间。
苹果过去的形象是自研加闭源，连根线材都要搞认证。这次不但主动往开源社区放权重，还站在别人的基座上——这个画面本身就够魔幻。
但选型逻辑其实很实在。9B 这个尺寸是当下的”黄金区间”：一张消费级显卡就能跑，量化后更轻松。既然通用能力可以直接站在现成的肩膀上，就没必要重造一遍轮子，把精力集中在”长文档压缩 + 工具调用”这个具体问题上，才是划算的做法。何况在中国市场，Apple Intelligence 的底层本来就是跟阿里合作的——这件事我们七月写过。研究团队再做一次同样的选择，说明它经过权衡，而不是客套。
License 是 Apple Machine Learning Research Model License，白纸黑字：仅限非商业研究，不许商用。它也不是一个聊天模型，没有做通用指令微调，上下文 262K，Q4_K_M 量化后大概 6GB 显存能跑起来。
所以正确的用法是把它当成一份公开的技术方案来读。真正值钱的是思路：上下文预算是可以分级的——看不清的地方先便宜地扫，看得清的地方再贵一点。对手机、眼镜这类算力有限的端侧设备，这可能是比硬堆上下文窗口更现实的一条路。
今年整个行业都在比谁的窗口大、谁吞的图多，LensVLM 的方向是反的：少花点。9.4B 的模型，用”看两遍”换来 84% 的显存节省，准确率只掉三个半点——这笔账，比参数榜上多几个零好看得多。
另一层意义在基座。当国际一线公司在做真实选型时主动挑千问，比任何发布会上”领先多少”的说法都更硬。当然也不必上头，它只能说明在 9B 这个尺寸上，Qwen 是当下最省事的选择——而这已经是很高的评价了。
Loading comments...