0.8B 参数的小模型，凭什么跟大模型拼文档：小米 Xiaomi-OCR-0 把活儿收窄到一件事上

10 月 30 日，小米在 X 上把 Xiaomi-OCR-0 的整套东西一次放了出来：权重、推理代码、在线演示、MCP 服务、Agent Skill，Apache-2.0 协议。先说清一个容易误读的时间点：权重 9 月 30 日就已在 Hugging Face 上出现，10 月 30 日是整包公开的节点，不是权重首发的日期。模型本身只有 0.8B 参数，底子是 Qwen3.5-0.8B-Base，训练语料约 1.7 亿条 OCR 样本，干的事收得很窄：一是把一页文档解析成 Markdown，表格、公式各有格式；二是按你要的字段抽成 JSON；三是就着图里的文字回答问题。官方技术报告给的分数是：OmniDocBench v1.6 96.83、Real5-OmniDocBench 95.24、Wild-OmniDocBench 87.94，五个 OCR 问答基准平均 83.2——这些全是厂商口径，未经独立复测。

这里必须留一个口子：Real5 那个“第一”，只在小米自己选的评测代码下成立；换公开榜单的代码算，它是 92.73，排在 PaddleOCR-VL-1.6 的 93.19 之后。所以“第一”这个词要打引号：它证明的是“小模型在文档解析这件窄活上能进第一梯队”，不是“全面超过所有对手”。落到本地部署上，它的卖点才成立：社区做的 BF16 GGUF 包约 1.8GB，能塞进 Ollama 这类本地管线；小米自己也称它已跑在 Super XiaoAi 手机助手里——那是厂商说法，但至少说明 0.8B 这个量级是冲着端侧去的。

我的判断：最值得试的场景，是你手里有一堆固定格式的文档要批量结构化：发票、合同关键字段、表单、报表。先别信榜单分数，拿你最难的那 20 页去跑：扫描歪了的、表格跨页的、手写混印的，看它在第几页开始掉链子；掉链子的页数，就是你还得留人工复核的比例。跑通了，它替你省的是“每页都调大模型 API”的钱和“文档外发”的风险；跑不通，也别硬换更大的通用模型，先看是不是文档本身就超出了它的窄活范围。

什么情况下这篇结论不成立：你要的是通用看图问答——认场景、讲笑话、做推理——那 0.8B 的窄模型从一开始就选错了；或者你的文档语言、版式根本不在它的训练分布里，榜单分数再高也帮不上你，实测才是唯一的准绳。