OpenBMB 首次在 PyPI 发布了 MiniCPM-OCR SDK 1.0.2。开发者可通过命令行或 Python API 串联处理流程，读取 PDF 或图像，将正文、表格、公式等整理为 Markdown。版面分析与识别服务相互独立，可接入现有的推理后端，即负责运行模型的组件，也可选择受支持的后端之一。
1. 从文档输入到 Markdown 输出
SDK 结合版面检测与视觉语言模型识别，按阅读顺序整理文档元素。版面检测用于查找文档区域及其布局，视觉语言模型则同时理解图像和文本。多页 PDF 可合并导出，表格以 HTML 表示，公式以用于书写数学公式的 LaTeX 格式表示。发布说明还列出了图表和印章识别支持。
公式后处理会修整识别结果，帮助恢复行内公式和独立成行的公式的 LaTeX 表达。发布说明称，它也能处理部分括号不匹配或缺少公式分隔标记的情况。
2. 从命令行开始并调整配置
使用内置的快速启动配置，无需单独的配置文件即可运行。以下示例来自原始 API 文档。
minicpmvocr parse doc.pdf -o doc.md --device cuda:0 \
--server-url http://127.0.0.1:18499 --model minicpm-ocr可通过命令行参数或 YAML 这种便于人类阅读的配置文件格式调整解析行为，默认配置最多同时处理 32 个识别请求。还支持版面检测与识别重叠执行，即同时推进两项任务，以及连接多个识别服务实例，即多个运行中的程序单元。
默认版面模型会先在当前工作目录中查找，若不存在或不完整，则自动下载。
3. SDK 与识别后端的分工
在该流水线中，SDK 负责检测版面、裁切文档块并重新组装识别结果。实际的模型识别由独立服务负责，两部分可在不同的 Python 环境中运行。
可通过 vLLM 或 OpenAI 兼容接口连接识别服务，也支持 llama.cpp 和 Ollama。
本地部署指南说明，文档处理和推理均在本地进行，无需将原始文档或结果发送至云端 OCR。
4. 页面并行处理带来的吞吐量变化
根据公司公布的数据，下表展示了在 NVIDIA GeForce RTX 5090 上，使用 OmniDocBench v1.6 全部 1,651 张图像测得的 MiniCPM-OCR 1.0 吞吐量，即单位时间内的处理量。测试调整的是同时处理的图像数，与面向文档块的 SDK 默认识别请求并发数 32 的调整单位不同。
表：不同图像级并发数下的 MiniCPM-OCR 1.0 吞吐量
条件：NVIDIA GeForce RTX 5090、MiniCPM-OCR 1.0、OmniDocBench v1.6 全部 1,651 张图像，调整图像级并发数
单位：pages/s
| 图像级并发数 | 吞吐量 |
|---|---|
| 1 | 1.217 |
| 2 | 1.613 |
| 4 | 1.888 |
| 6 | 2.031 |
| 8 | 2.133 |
不同图像级并发数下的吞吐量 (pages/s, 以 0 为基准)
1 | ████████████ 1.217
2 | ████████████████ 1.613
4 | ███████████████████ 1.888
6 | ████████████████████ 2.031
8 | █████████████████████ 2.133根据公司公布的数据，在测试范围内，并发数 8 的吞吐量最高，为并发数 1 时的 1.75倍。不过，随着并发数增加，吞吐量的增幅逐渐缩小，并未按并发数等比例增长。这体现了逐页处理与多页同时处理的差异；对于批量文档任务，页面级并行处理也是可调整的环节。
DSpark 通过主模型与配套辅助模型协作来加速输出生成，用于缩短批量文档解析时间。公司称，DSpark 解码加速使端到端处理效率，即从输入到结果的处理性能提升了 55%。参见 README。复现指南注明，此项对比的详细运行命令与记录有待后续补充。
5. 减少集成代码，关注运行环境
对于希望将输出的 Markdown 交给后续检索或文档处理流程的开发者，该 SDK 可减轻分别实现页面转换、元素提取和结果组装的负担。
运行前需单独配置与 SDK 兼容的识别服务。若在 vLLM 中选择 DSpark 加速，还需准备与主模型匹配的草稿模型。教程中的 vLLM 安装示例需要约 8GB 的 vLLM 环境，以及约 6GB 的源码和构建产物，即构建过程中生成的文件，并建议预留至少 40GB 磁盘空间。
安装依赖和首次下载模型还需要网络连接。能否接入已运行的识别服务，以及能否承担独立推理环境的成本，是决定是否采用的关键。
SDK 1.0.2 适合希望保留识别后端选择权，同时将文档解析中的组装步骤打包整合的开发者。