3B参数吊打大模型？百度Unlimited OCR开源登顶的真相

讲真我也在琢磨这个路由决策的开销问题，MoE在低算力设备上要是路由本身就得占不少算力，那稀疏激活的红利可能就被吃掉了。不过话说回来，它能在OmniDocBench上刷到93%说明至少对主流文档场景是够用的，就是不知道那些复杂表格和手写体到底测没测过？要是能开源个针对手写体的测试集跑跑就更清楚了。

这个帖子信息量挺大的，我正好在关注OCR轻量化方向，有几个点想追问一下。

关于MoE路由决策开销的问题，我直觉上觉得在低算力设备上确实可能是个坑。比如树莓派或者手机端，路由模块本身如果设计得不够轻量，判断哪条路径激活可能比直接跑一个完整的小模型还费劲。不知道Unlimited OCR的专家数量是多少？如果只有4-8个专家，那路由成本可能还好，要是搞个16个以上，我觉得推理延迟可能会翻倍。另外，它这个路由是基于token级别还是图像块级别？如果是token级，那对长文档来说，路由的调用次数会爆炸，实际效率可能要打个问号。

其次，关于benchmark覆盖范围，我查过OmniDocBench的paper，它里面确实包含了一些表格和手写体，但比例可能不高，而且手写体样本大多是英文或者数字，中文草书、带涂抹的笔记、发票那种压线文字应该没怎么测。百度强调“Unlimited”我觉得更可能是指支持任意长宽比文档，比如A3、A0那种超大图纸，而不是指文字类型全覆盖。如果真的想验证通用性，建议拿ICDAR 2019的ReCTS（中文街景文字）或者HDRC（手写文档）跑一下，看看是不是还能维持90%以上。

最后，我好奇它的训练数据是怎么构造的？3B参数用MoE，理论上数据多样性要够高才能让不同的专家学到差异化特征。如果只是用合成数据或者有限真实场景，那泛化能力大概率会被高估。楼主有没有扒到他们的数据配比？

刚好最近在折腾端侧OCR部署，看到这个帖子必须说几句。3B参数做到这个效果确实有两把刷子，但那个“吊打大模型”的标题党味儿太冲了，实际落地坑估计不少。

先说MoE路由开销的问题，我直接给结论：在手机或者树莓派这类设备上，路由网络本身大概会占10%-15%的额外计算量，如果是连续密集的文档页，这个比例还能接受，但遇到那种一页好几张表格、票据混排的，路由决策次数指数级上升，实测延迟能翻倍。他们官方demo里估计都是理想场景，真要跑到低端芯片上，建议直接砍掉一些路由分支，或者改成静态路由+动态微调的结合方案，不然用户感知到的就是转圈圈。

至于你担心的复杂表格和手写体，我倒是觉得MoE天然适合处理这个问题——不同expert专门负责不同区域，但前提是训练数据得覆盖足够多的极端case。如果benchmark里印刷体占比超过80%，那93%的水分就大了。我自己在医疗单据上测过类似思路的模型，手写数字和印刷体混排时，路由经常误判，导致部分区域直接没人管，最后还得靠后处理硬拉。

另外“Unlimited”这个说法，我猜更多是指对文本行数的支持没上限，而不是真正无限制场景。实际部署时显存瓶颈摆在那，3B参数全量加载大概要6-8GB，动态路由只能省计算不能省显存，这点小模型玩家得掂量掂量。要是能把这套蒸馏到1B以下，同时保持对旋转、模糊文字的鲁棒性，那才是真能普惠的利器。

MoE动态路由在OCR这种对延迟敏感的场景里，路由决策的额外开销确实是个坑，尤其低算力设备上，如果路由表设计不够轻量，可能省下的计算量全被调度吃掉了。至于benchmark，OmniDocBench的表格和手写体覆盖率我印象里不算高，建议拿ICDAR的混排和手写集跑下消融实验，否则Unlimited这个说法容易被打脸。

刚好在搞文档OCR落地，这帖子说到点子上了。我对Unlimited OCR最感兴趣的就是它那个动态路由，之前试过不少大模型OCR，参数上去了，但边缘场景反而卡死，文档里混个表格或者印章就直接崩。3B参数量能控在500M激活，这对我们这种要在低功耗设备上跑的团队来说太香了。

不过你说的benchmark覆盖问题，我深有同感。OmniDocBench我翻过，确实印刷体占大头，手写体样本少得可怜。我们之前测过竞品，印刷体拉满95%，换成手写发票直接掉到70%。Unlimited OCR要是只刷印刷体，那通用性就得打折扣。我倒是好奇它那个稀疏激活对手写体连笔、形变这种非结构化区域的处理逻辑，是按文本块路由还是按像素特征？如果是前者，那手写体这种边界模糊的肯定吃亏。

至于低算力设备上的路由决策开销，我直接说，别太乐观。MoE在推理时虽然只激活部分专家，但路由网络本身是个小模型，每次都要跑一次前向计算，我在Jetson Orin上试过类似的稀疏模型，单帧延迟多了8-10ms。如果Unlimited OCR的路由决策没做量化或硬件优化，那在移动端或嵌入式设备上，这个开销可能直接吃掉参数节省的红利。建议百度公开下不同设备上的延迟对比，特别是A53这种低端ARM核，别光刷benchmark。

另外，它这个‘Unlimited’到底指支持任意长文本还是任意复杂版式？如果只是指分辨率无限，那对我们处理A0工程图的人来说意义有限。希望后续能有更多实战场景的评测，别光在学术benchmark上卷。

刚跑完这个模型的推理测试，说几点真实感受。MoE动态路由这块确实有意思，我拿了几份扫描版合同和带水印的PDF试了下，普通印刷体识别率几乎没翻车，速度和PaddleOCR老版本比快了将近一倍，显存占用也低。但你说的复杂表格问题我遇到了，有个带合并单元格的报销单，它把表头里的“部门/姓名”拆成了两行单独识别，逻辑上没理解成层级关系，这可能还是路由策略对结构化布局的感知不够细。

至于手写体，我专门找了几张潦草的病历单，效果只能说及格——工整的连笔字能认，但那种带涂改、笔画黏连严重的就崩了，感觉模型对非规范字形的容错还是靠数据量硬怼，不是结构上的突破。部署成本这块，我试了在Jetson Orin上跑，路由决策确实有额外延迟，批处理场景下大概多了15%的推理时间，但换来的是整体参数量的节省，算总账还是划算的，尤其对文档密集的RPA场景。不过如果设备内存小于4G，建议还是得做层数裁剪，不然路由模块的缓存会卡住。

你质疑benchmark覆盖度我觉得很对，OmniDocBench里表格和手写样本占比偏低，而且样本清晰度都偏高，实际脏数据场景可能没这么好看。百度说“Unlimited”是支持任意长宽比和排版，这点我实测验证了，旋转、倾斜的发票也能正常框出文本，比之前需要预矫正的模型强不少。但要说吊打所有大模型，我觉得还得看他们什么时候把数学公式和化学结构式的识别补上，目前这个版本对符号类支持还是偏弱。