小米开源 0.8B 文档模型：1.8GB 一条命令拉下来，把按页付费的 OCR 搬回本地

按页买 OCR 这件事，第一次有了真正能替代的本地选项。

它是什么

0.8B 的视觉语言模型，不是”检测框 + 识别”那套老流水线。三类任务共用一套权重：

任务	输入	输出
整页解析	扫描件、拍照、截图	Markdown，表格转 OTSL（转成 HTML 表格）、公式转 LaTeX，按阅读顺序
关键信息抽取	发票、收据、卡证、业务表单	按你给的 JSON Schema 输出 JSON
文档问答	文档图片 + 问题	跨区域检索、数值计算

许可证是 Apache 2.0，权重在 Hugging Face 和 ModelScope，代码在 GitHub，论文是 arXiv:2609.36136。

数字

怎么上手（三条路，从省事到可控）

最省事：ollama pull longwayxu/xiaomi-ocr-0:bf16，然后跑仓库里的 MCP 服务或浏览器 Demo。注意——单独 pull 模型没用，仓库明确写了必须走它自带的 MCP 或 Demo，因为图像预处理、非思考提示词、解码参数都封装在那一层里。
让 agent 自己装：把 Read and execute https://raw.githubusercontent.com/SeerRay-Lab/Xiaomi-OCR-0/main/SKILL.md 这句丢给你的编程 agent。它会建 Python 环境、装依赖（SGLang / vLLM / Ollama 三选一）、下权重、注册 MCP server。仓库也直说了：模型和布局模型的下载量很大。
手动：Python 3.10+，clone 仓库，起 SGLang 或 vLLM 在 127.0.0.1:8000，再跑 demo/server.py --port 8787 打开浏览器界面。要走”区域模式”（对大版面文档分块并行）还得额外装 PaddlePaddle、PaddleX 和 PP-DocLayoutV3，CPU 版要设 XIAOMI_OCR_LAYOUT_DEVICE=cpu。

对你有什么用

如果你是那种每月要处理几百上千张票据、扫描件、研报的独立开发者，按页买 OCR 的成本是可以算出来的：一张几分钱，一千张就是几十块，一年几百到几千。这个模型一次性下载 1.8GB，之后每页零边际成本，还不用把客户发票传出去。

更实际的一点是它输出结构化结果。以前用 OCR API，你拿到的是文字，还得自己写规则把表格还原、把字段抠出来。现在直接给 Markdown 表格和 JSON，省掉的是那段最烦的解析代码。

泼冷水

官方基准是自报的，没第三方复现。 而且模型卡内部就有一处不一致：正文写 Real5 是 95.24，评测结果区又写 Overall 92.73（Scanning 93.73、Warping 92.76）。两个口径差 2.5 分，用之前至少自己压一遍。
社区量化版明确”未经官方评测”。 仓库写得很老实：Apple Silicon + Ollama 0.35.0 上，7 个样例的输入 token 数全部对齐，5 个原始输出逐字一致，另外 2 个公式有差异。它也补了一句：这不构成准确率对等的证明。你要拿它跑生产，这 1.8GB 版本只能当”先试试”，不能当”就它了”。
它不会聊天，也不做创意。 强项是印刷文档、票据、表格；重度模糊、大面积潦草手写、超长多页会打折。别指望一个模型干完所有事。
区域模式的依赖链很重。 PaddlePaddle + PaddleX + PP-DocLayoutV3，装一遍能劝退一半人。整页解析不需要它们，先跑整页，别一上来就啃区域模式。

具体建议

先挑 20 张你自己的真实文档（发票 10 张、表格 5 张、截图 5 张），用千问或豆包那种按页计费的 API 跑一遍，记下每张的字段准确率和耗时，做成基线。
再跑 Xiaomi-OCR-0，同一批文件、同一个字段 Schema，对比。字段级准确率差 3 个点以内，就值得迁——省下的钱和隐私收益都在这 3 个点里。
迁移只迁”量大、容错高”的那部分（票据录入、台账整理、合同字段抽取）。最终对外交付的关键文档还是留给人看一眼。
接进工作流时走 MCP，别自己包一层 HTTP。它自带的预处理和提示词是分数的一部分，自己重写等于把一个调好的模型调坏。