8GB 显存能跑，但跑到第几页会崩：长文档显存曲线的实测

8GB 显存能跑，但跑到第几页会崩：长文档显存曲线的实测

最近技术圈最火的开源项目之一，是百度放出来的 Unlimited-OCR 2。

火到什么程度？上线几天 GitHub 星标破万，Hugging Face 和 GitHub 四个榜单同时登顶，连图灵奖得主都转发推荐。朋友圈里一片"OCR 3.0 来了""一次读完几百页"的欢呼。

但真正把模型下载到本地的人，很快撞上了另一堵墙：

能跑，和能跑完，完全是两件事。

一张 8GB 显存的显卡，加载模型没问题，扫一页合同也很快。可一旦你把 30 页 PDF 一次性丢进去，大概率会在某一页突然黑屏式报错——显存爆了。

那到底是第几页崩？8GB、12GB、16GB、24GB 各能撑多少页？这篇文章不聊架构、不贴代码，只聊所有普通人最关心的一件事：显存这条曲线，到底长什么样。

一、先搞明白：它凭什么"8GB 也能跑"

Unlimited-OCR 2 是个"看着大、其实很省"的模型。

它总共有 30 亿参数，听着挺唬人，但采用了 MoE 结构——可以理解成一家大公司有 64 个部门，每处理一个字只需要叫醒其中 6 个，其余在工位上睡觉。真正干活的算力大约只有 5 亿参数的量级。

再加上它把一整页 1024×1024 的扫描图，硬压缩成两百多个"视觉 token"。这就像把一张高清照片先做成一张极简线稿，信息该留的留着，冗余全砍掉。

所以模型权重本身只有 6.7GB 左右。一张 8GB 的卡，装得下。

第一代最惊艳的地方，是把"已经抄过的内容"从记忆里移出去：模型始终看着原始页面，只保留最近一小段输出，所以输出越长，显存不再跟着一路狂飙。

到了 2 代，连"看页面"这件事也做了稀疏化，官方说法是从"长文档"走向"无限长文档"。

听起来完美。那为什么还会崩？

二、显存曲线实测：不是慢慢涨，是"台阶式"上涨

我们在同一台机器上反复跑了同一份排版规整的说明书，每页 300 DPI，记录显存占用。真实的曲线不是一条平滑上升的斜线，而是三个阶段：

第一阶段：平躺期（第 1～3 页）

曲线几乎是一条水平线。8GB 卡上，模型加载吃 6.7GB 左右，单页推理峰值再加 1GB 出头，总占用在 7.5GB 上下晃。这时候你会产生一种错觉："这么轻松？我能扫完整本书。"

第二阶段：爬坡期（第 4～10 页）

每多塞一页，曲线就抬一小格。原因很简单：模型虽然不记住"抄过的字"，但输入端的页面图像是全都要塞进上下文的。一页两百多个视觉 token，十页就是两千多个，再加上每页都要生成几千字的输出缓冲，显存开始一阶一阶往上跳。

这一段最危险，因为它"看起来还能跑"。很多人就是在这里放松警惕，一口气拖进去 40 页。

第三阶段：断崖（某个临界页）

不是渐变，是骤崩。前一步还显示 92%，下一步直接报错退出。

根据社区里不同显卡的反馈，8GB 卡的临界点普遍落在第 3～5 页，12GB 卡在 8～12 页，16GB 卡在 15～25 页，24GB 卡能摸到 30～40 页。官方多页接口标称支持 40 页一批，但那基本是给 80GB 显卡准备的数字。

再看时间维度。有用户在 RTX 4060 上实测，单页大约 6.6 秒；扫完 600 页书，纯推理时间约一小时出头。也就是说，慢不是问题，崩才是问题——一旦第 200 页崩了，前面全白跑。

三、崩之前的三个征兆，比日志更有用

不用看懂报错，盯住这三件事就够了。

征兆一：出字速度明显变慢。前几页哗哗地出，到某一页开始一个字一个字往外挤，中间还卡顿。这说明显存已经贴着天花板，系统在疯狂整理碎片。

征兆二：输出开始"复读"。同一句话反复出现，或者页码标记丢了、表格断了。这不是模型变笨，是它在资源极限下开始"神志不清"。看到复读，立刻停，别硬撑。

征兆三：报错文案里出现"out of memory"或者"显存不足"。这是最后的宣判。更坑的一种是"非法内存访问"，看起来像程序 bug，八成也是显存挤爆导致的。

还有一个隐蔽的坑：你在提示词里多加一句话，崩得更早。

社区里有人做过对比，本来只让它"照着抄"，单页 5 秒、显存 10GB；一旦加上"请顺手改正错别字"，单页变 30 秒，显存冲到 15.8GB，第三页就趴下了。原因很朴素：多一项任务就多一段输出，多一段输出就多占一份显存。

OCR 就让它老老实实抄写。总结、纠错、翻译，交给后面的模型。

四、四种缓解手段，收益从高到低排个序

网上教程一堆，真正有效的其实就四条，按性价比排序：

第一名：分页跑，别贪心。收益最大、零成本、立竿见影。把 PDF 拆成一页一页喂，每页跑完清一次缓存，显存曲线立刻从"爬坡"变成"全程平躺"。代价是丢掉跨页上下文——跨页表格、跨页标题会断。解决办法很土但很好用：跑完之后人工或脚本把碎片拼起来，重新编号标题、接上被切断的表格。

第二名：降分辨率、关掉切块。扫描件本来就很清晰的话，没必要开高分辨率切块模式。这一步通常能省下 20%～30% 的显存峰值，代价是极小字号和密集公式可能识别得糙一点。看你的文档类型决定。

第三名：量化。把 6.7GB 的权重压到 2～4GB。社区已经有 4bit、6bit 的版本，苹果 M 系列芯片上 4bit 只有 2.29GB，效果肉眼几乎看不出差别。对 8GB 卡来说，这是从"只能扫三页"变成"能扫十页"的关键一招。缺点是要多折腾一步转换，且极细的小字偶尔会掉。

第四名：CPU offload，也就是把部分计算挪到内存里。收益有，但速度会掉到让你怀疑人生，通常慢三五倍。只适合"我就这一份重要合同，慢点无所谓"的场景。

另外有两个免费的小技巧：一是启动时加一个减少显存碎片的开关，连续跑几百页不容易中途暴毙；二是把"预留显存比例"调低一点点，给系统留出呼吸空间，反而更稳。

五、按显存档位给的安全页数表

下面这张表是综合官方说明和社区实测给的经验值，以排版规整、300 DPI 的普通文档为基准。排版越花、图片越多、公式越密，页数要往下打折。

还有个容易被忽略的点：并发比页数更吃显存。有人为了快，起两个服务实例同时跑，结果 12GB 卡上两个模型各占 6.7GB，谁也跑不动。要并发，先算清楚权重是不是要加载两份。

六、所以，它到底值不值得普通人折腾？

说句实在话：Unlimited-OCR 2 是目前单页效果最能打的开源文档解析工具之一，标题分层、表格转 Markdown、公式转 LaTeX、多栏不串行，输出质量确实能让整理资料的人省下大把时间。

但它不是"点一下就好"的消费级软件。它更像一台专业设备：参数调对了，效率惊人；参数调错了，第一页就给你脸色看。

如果你手上有一堆合同、论文、旧书要数字化，一张 12GB 以上的显卡 + 分页策略，是目前最舒服的组合。

如果你只有 8GB 卡，也别灰心——逐页跑虽然土，但稳。有人就是这么一页一页啃完了 600 页的技术书。

最后留个问题给大家聊聊：

你手上那张显卡，扫到第几页开始"喘"的？评论区报个配置和页数，咱们凑一份更真实的中国玩家显存地图。