https://github.com/xiaomi-research/Xiaomi-OCR-0分析一下这个项目，和百度最近开源的项目进行一个对比

回复 贝尔 我把两个仓库都读了一遍，先说结论：这两个项目根本不是同一道题。Xiaomi-OCR-0 解决的是“单页或区域解析得准不准”，Unlimited-OCR 2 解决的是“几百页能不能塞进一个上下文一口气读完”。用 OmniDocBench 的分数去对比两者，是错位比较。 先说几个事实前提。你贴的链接我打不开（仓库实际在 SeerRay-Lab/Xiaomi-OCR-0，开源组织迁过），现在能读到的是小米这份。百度那个也不是一个库里的一代模型，2026 年 6 月发的是 Unlimited-OCR（DeepSeek-OCR 系的改进版），10 月 27 日又发了 Unlimited-OCR 2，加了 SR-SWA，并顺手发了 MarathonDocBench 这个超长文档基准。两边都是 0.8B～3B 级别的小模型，这倒是共同点。 小米这边，路线是“把一个小模型在垂直数据上磨到极致”。底座 Qwen3.5-0.8B，约 1.7 亿条 OCR 为主的语料做继续预训练，还加了 Q-Mask 文本锚定和 Mix-RL 混合任务强化学习。效果上看它给的表：OmniDocBench v1.6 是 96.83、Real5 是 95.24、Wild 是 87.94，整体卡在 TeleOCR 1.2B 那一档，Wild 略低于 TeleOCR 的 88.53、略高于 OvisOCR2 的 87.91。真正有区分度的是两件事：OCR 类 VQA 五个基准均值 83.2，超过 Qwen3.5-2B 的 80.9，一个 0.8B 打 2B 还能赢；还有古籍手写唐楷这类 Chronicles 73 分，跟 Seed 2.0 Pro 的 72 打平。它把 Agent 侧也铺了，skills/xiaomi-ocr 里有 MCP 服务和 Skill，能跑 SGLang、vLLM、Ollama，定位是“给 agent 用的本地文档解析零件”。 百度这边，押注的完全在另一个维度。SR-SWA 的做法是把超长序列的文本-视觉注意力压缩到一个固定大小的工作参考集（比如 512 token），这样每步解码的延迟和显存基本与文档长度脱钩，本质上把注意力的平方级增长砍掉了。再配页面窗口调度、KV 尾部复用、无重复 n-gram 采样这些工程手段，才能在有限上下文里做“无界解析”。代价也很明显：仓库 README 里大半篇幅在讲显存调参，mem-fraction-static 0.7 才稳、max-prefill-tokens 砍半才能不 OOM、CUDA graph bucket 要调对齐，这不是开箱即用的东西，它面向的是有机器、有运维要自己搭服务的团队。而且小页窗能省显存但会伤跨页合并——窗口边界切断的段落会丢上下文，这是这类滑窗路线的固有毛病。 所以怎么选，看你的场景： 第一，输入是单页扫描、发票、表格、公式、古籍手写，要的是结构与 LaTeX、OTSL 表格回填准，那就用小米这个。它在少参数下把弱项补得比较好，而且能塞进 Ollama、跑在本地，配 agent 的 MCP 也现成。 第二，输入是几百页的书、年报、合订本，要求一次请求里跨页连贯，那就只能看 Unlimited-OCR 2。这是它独占的场景，别的模型不是不准，是根本放不进去。 第三，别被 star 数带偏。百度那个 29.8k star、3.2k fork，小米 131 star，但百度是 6 月首发时五天破万攒下来的热度，两者的社区基数差着量级，跟技术优劣是两件事。同样，百度 MIT 许可比小米的 Apache-2.0 更宽松，但小米的 Apache-2.0 对企业使用其实也没障碍。 第四，两边都有自报基准的问题。小米全部数据出自自己的技术报告，百度的 MarathonDocBench 也是自家新发的基准，赛场上自己定规则是常事。真要选型，拿你手上真实的 50 页样本各跑一遍，比看任何榜单都准，尤其看两处：跨页的表格和段落有没有断裂，以及重复输出（小模型 OCR 的老毛病，两边都在 postprocess 里单独处理了这一点，说明都踩过）。 最后一句判断：小米这份工作的价值不在数字，在于证明了 0.8B 做 OCR 专用模型仍然有意义——它比让通用 VLM 顺手做 OCR 更省、更准，而且能本地跑。百度则在回答另一个问题：当文档长度不再受上下文限制时，OCR 的瓶颈从“识别准”转移到“调度与显存”。这两条路不冲突，一个做精度纵深，一个做长度纵深。