干货满满丨MinerU 3.0 系列更新：一次不止于模型的全面进化

随着 MinerU2.5-Pro 模型在 OmniDocBench 1.6 上取得 SOTA 成绩的发布，大家都在询问我们：MinerU 开源项目什么时候能真正把这个超强模型接进来，跑在实际的文档解析项目里？

好消息：最新发布的 MinerU 3.1.0 开源项目已经完成了对 MinerU2.5-Pro 模型的适配，正式发布！

● MinerU 开源模型获取地址：https://github.com/opendatalab/MinerU

● HuggingFace demo 体验入口：https://huggingface.co/spaces/opendatalab/MinerU

● ModelScope demo 体验入口：https://modelscope.cn/models/OpenDataLab/MinerU2.5-Pro-2604-1.2B

* MinerU线上服务正在快马加鞭适配中，敬请期待！

这次更新并不只是简单“接入一个新模型”，而是围绕解析能力、系统架构和工程可用性，带来了一整套更底层的重构和升级。如果把这次更新说透，那便是：MinerU 3 系列开源项目，不是“多加了几个功能”，而是从一个文档解析工具，往大规模、可部署的工业化文档解析基础设施又推进了一步。

过去很多人理解 MinerU开源项目，更多还是从“PDF 转 Markdown”“公式转 LaTeX”“表格转 HTML”这样的能力层面看它；但 3系列之后，它明显不只是解决“能不能解析”的问题，而是在解决“能不能稳定跑、能不能大规模跑、能不能在真实业务里跑”的问题。我们在README 对这次升级讲的也很直白：这是围绕解析能力、系统架构和工程可用性的系统升级，而不是一次零散补丁。

目前，开源项目版本与模型版本彻底解耦。模型可以持续演进，从 2.5 Pro 走向更高版本，但 MinerU 开源项目本身作为解析系统，不需要随着模型变化反复重构，而是可以稳定承接新的能力。这种分层，使它不再只是依赖模型的工具，而开始具备基础设施的特征。

配图来源：NanaDraw流程图生成器：https://shannon.science/nanadraw

在这个前提之下，再看 MinerU 3.1.0 的其他变化，就会发现它的整体方向已经发生了明显转向：

开源协议更新，商业用途限制放宽

首先是协议从 AGPLv3 切换到了基于 Apache 2.0 的 MinerU 开源许可证。表面上看，这只是一次许可证调整，但对开源社区、开发者以及中小企业来说，它带来的实际利好非常直接——接入门槛更低了。

该开源许可证现在为开源使用、二次开发以及一般商业集成释放了更大的空间。对于绝大多数开发者、创业团队和中小企业来说，只要在合规前提下，可直接用于商业用途，无需取得我们授权，可以更放心地把 MinerU 用到自己的产品和业务里，而不需要一开始就被复杂的授权问题拦住，让更多人先用起来、接进去、跑起来。

配图来源：NanaDraw流程图生成器：https://shannon.science/nanadraw

当然，这里也需要说明，MinerU 当前采用的并不是标准 Apache 2.0，而是一个基于 Apache 2.0 并附带少量额外条款的项目许可证。它的整体方向是放宽，而不是收紧。只有在少数超大规模商业化场景下，项目方才保留了进一步的授权要求。比如，月活跃用户超过 1 亿、或月总收入超过 2000 万美元的大型商业主体，通常需要另行取得商业许可；如果是基于 MinerU 向第三方提供在线服务，也需要在产品界面或公开文档的显著位置明确标注使用了 MinerU。

向 AI 标准件进发：支持多种文档格式原生解析

与此同时，从系统视角来看，MinerU 的角色也已经发生了变化。它不再只是一个前处理工具，而是开始成为 AI 系统中的标准组件——一个可以被稳定调用、持续存在的能力节点。这种变化在“数据入口”这一层体现得尤为明显。

MinerU 3 系列开源项目正式补齐了对 DOCX、PPTX、XLSX 的原生解析能力，而且是在无幻觉前提下完成结构还原。过去，很多文档处理流程其实都绕了一大圈：Word 往往要先转成 PDF 再解析，PPT 往往要先转图片再做 OCR，表格文件也常常要经过额外格式转换后才能进入后续链路。这样做的问题并不只是精度受损，链路本身也会变长、变重，过程中还会丢失不少原始结构信息。

而原生解析把这条路径大幅缩短了。除了精度更高、结构还原更完整、能够避免大模型式“幻觉”之外，它在工程上也更轻：一方面，相比“先转 PDF / 图片再解析”的传统方案，整体处理速度可以实现数十倍提升；另一方面，这条链路本身几乎不占用 GPU 资源，资源消耗更低，也更适合高频、批量、在线化的文档处理场景。换句话说，MinerU 现在解决的已经不只是“能不能解析”的问题，而是“能不能以更低成本、更高吞吐地稳定解析”。

配图来源：NanaDraw流程图生成器：https://shannon.science/nanadraw

这背后带来的变化，其实是数据进入 AI 系统方式的改变。文档不再需要经过多轮中转和格式牺牲，才能勉强变成可处理对象；现在，它可以直接进入解析系统，并直接输出结构化、可用的数据结果。这种变化正在把文档从静态文件重新变回系统里的数据源，正在重塑 AI 系统的数据入口。

大规模任务问题，逐个击破：降显存、多机多卡、高并发

如果说前面的变化更多体现在解析能力上，那么 MinerU 3 系列开源项目更深一层的升级，其实发生在工程侧。这次更新明显在回应一个长期存在、但过去常被忽视的问题：一个开源解析系统，怎样才能真正跑进生产环境，并且稳定地跑下去。

围绕这一点，MinerU 3.0 在部署形态和运行链路上都做了系统性增强。它不仅支持单机多卡，也进一步具备了面向多机多卡场景的扩展能力，配合自动负载均衡，可以更从容地应对高并发请求和大规模任务处理，把整体吞吐能力拉到一个新的水平。与此同时，通过对推理链路的持续优化，系统整体速度也获得了数量级提升。这样的变化不只是“更快了”，而是意味着 MinerU 开始具备了承接真实业务流量的工程基础。

另一个关键变化发生在长文档处理上。相比 MinerU 2 系列主要依赖高内存机器来支撑超长文档解析，例如在 128GB 内存环境下完成约 3000 页长文档处理， MinerU 3 系列更核心的突破是把问题转向了内存使用方式本身的优化。通过滑动窗口机制与流式落盘配合，长文档解析不再需要一次性将全部中间状态压进内存，而是以更平滑的方式持续推进任务执行。部署后，单个 worker 在 8GB 内存条件下，也可以稳定处理上万页级别的长文档。这不仅显著降低了部署门槛，也让系统在长时间运行时更稳定、更可控。

配图来源：NanaDraw流程图生成器：https://shannon.science/nanadraw

这些能力组合在一起，使得 MinerU 开源项目已经具备了承载大规模文档处理任务的工程基础。它不再只是一个“解析工具”，而是在向“Agent 时代的数据解析基础设施”演进。一方面，它提供了更轻量的调用方式，使解析能力可以更自然地嵌入到 Agent 和 workflow 中；另一方面，它的稳定性和扩展能力，使其可以作为系统中的长期组件存在。当模型能力与系统能力叠加之后，文档不再只是被读取，而是可以被结构化、被计算，并直接参与到 AI 系统的运行中。

总结

如果需要对这次 MinerU 3 系列开源项目的升级做一个总结，可以说它完成的不是一次简单的版本升级，而是一次从工具到工业级方案的跨越。它不仅提升了解析能力的上限，也解决了规模化运行的下限问题，使文档解析从“能用”走向“可用且可规模化使用”。在这样的基础之上，企业级系统的RAG 的效果会更加稳定，Agent 的执行会更加可靠，而数据处理的成本也会被重新压缩。更重要的是，数据终于开始以正确的结构进入系统，成为真正可以被模型理解和调用的资源。

目前，MinerU 的生态边界正在被快速拉宽。它不再局限于“文档解析”这一单点能力，而是开始完整覆盖 skills、RAG、workflow 以及 OpenAPI 的整条应用链路。这意味着解析结果可以更自然地进入后续的数据处理、调用和应用流程中，而不需要额外的适配层。与此同时，基于开源项目演进的 MinerU 在线产品，也正在持续跟进这些最新能力，并加快完成相关适配与产品化落地。如果大家希望感受 MinerU2.5-Pro 模型的强悍转化能力，欢迎访问在线demo进行体验：

● MinerU 开源模型获取地址：https://github.com/opendatalab/MinerU

● HuggingFace demo 体验入口：https://huggingface.co/spaces/opendatalab/MinerU

● ModelScope demo 体验入口：https://modelscope.cn/models/OpenDataLab/MinerU2.5-Pro-2604-1.2B

* MinerU线上服务正在快马加鞭适配中，敬请期待！

在大模型持续演进的当下，很多人把注意力放在参数规模和推理能力上，但真正决定系统效果的，往往是数据链路是否完整。MinerU 3.0 开源项目所做的，正是补上这条链路中最容易被忽略、却最关键的一环。