上一代的部署脚本直接搬去新版这份“搬家清单”告诉你哪些能留、哪些非改不可【免费下载链接】Unlimited-OCR-2项目地址: https://ai.gitcode.com/hf_mirrors/baidu/Unlimited-OCR-2上周有个读者给我发消息说他把自己跑了大半年的 Unlimited-OCR 部署脚本原封不动复制到新版 Unlimited-OCR-2 上结果三分钟里经历了三重暴击服务起不来、接口返回 404、好不容易跑通了输出还是一坨糊在一起的乱码。他问我“不就是换了个模型吗怎么跟换了台车似的”还真就是换了台车。新版 Unlimited-OCR-2 是 10 月 27 日刚开源的主打“无限长文档解析”上一代是靠“一次读几十页”封神的这一代直接把“页数”这个限制给拆了。功能是真猛但部署这一层官方几乎是把发动机舱重新排了一遍线。所以这篇不聊玄学就聊一件事你手里那套旧脚本哪些能打包带走哪些必须当场换掉。一、先搞清楚这回搬的是个什么新家用大白话讲OCR 这活儿过去的难处在于“抄书抄到后面就忘了前面”。AI 抄一页文档脑子里要留一张“草稿纸”记着前面看过什么。文档越长草稿纸越厚最后厚到桌子放不下——这就是大家常说的显存爆掉、越生成越慢。上一代的解法是草稿纸只留最近一小段前面看过的画面永久保留。效果不错但终究有个上限。这一代换了个更狠的思路不管文档多长AI 手边永远只用一小叠固定大小的“工作参考”看完就翻页边看边忘但该记的画面一个不丢。官方叫 SR-SWA说白了就是“抄书的人学会了只盯着原书草稿纸永远只用那几张”。带来的直接结果几十页、上百页的文档一次请求丢进去速度不掉、显存不涨。官方还顺手放了个叫 MarathonDocBench 的“百页级超长文档”考卷顺便在几十页级的 MPDocBench 上也拿了 SOTA。模型本身不大总参数 30 亿干活时只激活五亿多权重文件大概 6.7GB。每一页纸进模型后会被压成 273 个视觉 token相当于把一整页密密麻麻的字先浓缩成一张便利贴大小再喂进去。这也是为什么它一发布就被刷屏上一代开源 5 天 GitHub 星标破万后来冲到了近两万Hugging Face 下载量两百多万还跟 Kimi K3 一起包揽过全球趋势榜前二。社区里有人拿 5060 Ti 16G 硬啃了 600 页技术书也有人做出了 4bit、6bit 量化版和 8GB 显存就能跑的便携包。热度是真的但迁移的坑也是真的。二、这三样可以原样打包带走先说好消息你的旧家当不是全都要扔。第一样硬件和驱动的大方向。新老两代都是 NVIDIA GPU 路线CUDA 12.x 这一档不用动。官方这代是在 A800 80G 上验证的但社区实测 8G、16G 的消费级卡也能跑——因为它这代最擅长的就是“不让显存随页数涨”。所以你原来那台机器大概率不用换。第二样模型缓存目录。就是那个存了几个 G 权重的文件夹。目录结构没变还是老地方新版只是往里多放了一个 6.7GB 的“新房客”。旧的千万别删后面回滚全靠它。第三样业务侧的外壳。这部分几乎零改动PDF 转图片还是 PyMuPDF还是 300dpi 那套、任务队列、并发控制、结果落盘、失败重试、鉴权、监控告警、前端的进度条。还有你那个“把每页结果拼成一本 Markdown”的合并脚本——思路能留但细节得改这个后面单独说。一句话总结外壳能搬内脏得换。三、这四件事非改不可这部分是重点照着对一遍能省你两个通宵。① 模型标识别只改一半模型名从 Unlimited-OCR 变成了 Unlimited-OCR-2这个大多数人会改。但坑在于要改的地方不止一处启动服务时的模型路径要改服务对外暴露的名字要改客户端请求里那个 model 字段也要改。很多人只改了服务端客户端还在喊旧名字于是请求要么被拒要么被路由到一个根本不存在的模型上报错信息还特别含蓄让你以为是自己环境装坏了。② 环境不能原地升级必须新开一个这条最容易翻车。上一代的参考环境是 Python 3.12这一代官方给的测试环境是Python 3.10——是往回退的。配套的 transformers 也从 4.57 回到 4.52torch 则从 2.10 升到 2.13。一升一降你原地 pip 升级大概率会把旧环境搞成半身不遂。而且新版还多了一个硬需求稀疏注意力的加速内核要用到 Triton另外服务端多了一个分词加速组件。你在旧环境里往往压根没装 Triton一启动就报模块找不到。所以正确姿势是新开一个虚拟环境两套并存。旧的那套一个字都别动它是你的退路。③ 显存和服务参数老的几个开关直接消失了这是迁移里最“迷惑”的部分——你会发现旧脚本里好几个参数新版根本不认了。上一代常用的那套固定 32768 的上下文长度、指定注意力后端、页大小设成 1、关掉重叠调度、跳过预热——这一代基本都不在台面上了。取而代之的是一套新逻辑不再靠“上下文长度”卡住而是按页开窗。默认一个窗口塞 10 页跑完下一个窗口还能借用上一窗末尾的“余温”跨页的表格、跨页的段落才不会断成两截。显存那边也有变化老版建议的显存占比是 0.8新版明确说 0.75 在 32 路以上并发时都会翻车0.7 才稳。预填充的 token 上限也从 4096 砍到 2048因为那块临时显存是随它线性涨的。新版还多了几个专门治“大图显存炸”的开关把注意力偏置切成 64MB 一份、让大张量走共享内存而不是塞进进程间通信、关掉视觉缓存、打开显存碎片整理。这些不是优化项是保命项。老的启动脚本里没有它们迁移时基本等于裸奔。④ 接口字段改名字了而且改了语义老版给图片传的是“模式”字段值是 gundam 或 base一个代表切块、一个代表整页。新版换成了布尔值真就是切块假就是整页。字段名和取值全变了旧客户端发过去新服务要么不认、要么按默认值走——最坑的是它可能不报错你看着服务在跑实际跑的压根不是你以为的那个模式。另外几处也得跟着改提示词里现在要带分页标记多页文档每一页前面都得有一个模型靠它数页、靠它在输出里分页请求里新增了三个关键小参数分页标记的编号、结束符编号、以及单页输出上限默认两万 token防止某一页啰嗦到把整篇预算吃光输出总预算从“每页多少”变成了整篇总账得自己乘页数而且必须大于零超时时间要往死里拉长一篇百页文档跑十几分钟很正常老的几十秒超时必挂。四、几个“看着一样、其实不一样”的细节多页的图片尺寸参数其实已经不听使唤了。老版多页要显式指定 1024新版多页走的是整页模式页面统一补到 1024 的方图你那个 640 只对单页切块生效。传了不报错但你已经误解它了。多页的提示词不用手写了。新版会自动给你拼好“分页标记 图片”重复 N 遍再加一句“多页解析”。你手写反而可能因为占位符数量对不上直接被拦下。官方有个环境变量名是拼错的。就是那个控制“按页开窗”的总开关名字里的 ENABLE 被写成了 EANABLE。看着像 bug但照抄别手抖帮它改对改了就不生效。输出里的分页标记必须按页切开。新版的输出会在每页开头打一个分页标记顺序跟输入一致。你老的合并脚本如果不认这个标记还按老办法猜分页就会出现“标题序号错乱、表格跨页断开”的经典事故。五、迁完别急着上线先做这份“逐字段对照”我的建议是**同一批文档两版各跑一遍逐字段比。**别只看整体“感觉对不对”那玩意儿骗人。挑三类样本排版规整的比如印刷体报告、排版复杂的多栏、公式、合并单元格表格、以及一篇百页级的超长文档。然后对照这几项页数对不对输出里的分页标记数量必须等于你喂进去的页数。少一个说明中间有页被吞了标题层级一级二级三级有没有乱尤其是跨页之后表格行列数、合并单元格、有没有被拆成两张表公式是不是还老老实实待在公式符号里有没有变成一堆乱码字符阅读顺序多栏文档最容易翻车看看有没有左栏读一半跳右栏关键数字金额、编号、日期抽查二十处一處不对就得回头看性能首字延迟、每秒 token 数、显存峰值尤其是第 1 页和第 50 页的差别——这一代最大的卖点就是这两者应该差不多如果差很多说明你的开窗参数没配对。给个粗暴的及格线关键字段准确率不低于旧版页数零丢失超长文档的尾部质量不明显掉档。达不到就别急着切流量。六、回滚这件事最好在迁移之前就想好老工程师都有个习惯上线前先想好怎么退。新版最大的好处是——它跟旧版几乎不抢资源所以共存特别容易两个环境旧的 Python 3.12 那套原封不动新的 Python 3.10 单独一套互不干扰。两个模型目录旧模型别删多占几 G 硬盘而已比出事时重新下 6.7GB 强一万倍。两个端口旧的继续躺在 10000 上新的换个口前面挂个网关。一个版本字段结果表里加一列记下这份文档是哪个版本解析的。以后发现某批数据有问题能精准定位是哪次上线引入的。然后灰度先拿 10% 的流量试重点盯那篇百页文档和那批表格最多的合同稳了再放到一半一周没问题再全量。真要回滚就是网关改个指向的事不用重装、不用重下、不用重训。写在最后这一代 Unlimited-OCR-2 的意义其实不在“又破了个榜”。它真正的价值是长文档这件事从“能不能跑完”变成了“跑多长都一样快”。以前做文档数字化的团队最怕客户丢来一本三百页的扫描书现在这个恐惧正在消失。对企业知识库、合同归档、论文批注这些场景来说这是质变。但技术越猛迁移越不能图省事。搬家从来不是把东西一股脑塞进箱子而是知道哪件家具进新门会卡住。最后问一句如果你手上有一套跑得正稳的旧流水线你会选择一次性全量切换还是老老实实灰度一周评论区聊聊你的踩坑史。【免费下载链接】Unlimited-OCR-2项目地址: https://ai.gitcode.com/hf_mirrors/baidu/Unlimited-OCR-2创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考