MinerU 版本演进全解从 magic-pdf 重构到 hybrid 后端读懂官方 Changelog 背后的技术决策【免费下载链接】MinerUTransforms complex documents like PDFs and Office docs into LLM-ready markdown/JSON for your Agentic workflows.项目地址: https://gitcode.com/GitHub_Trending/mi/MinerU本文以 MinerU 官方变更日志 changelog 为骨架系统梳理 MinerU 从 0.x 开源到 2.7 系列的关键版本演进2.0 的架构重构、MinerU2.5 多模态模型的接入、hybrid混合后端的诞生以及 API 服务侧一组可落地的环境变量调优手段。读完本文你不仅能看懂每个大版本的“为什么”还能结合当前仓库源码版本3.4.4见 version.py验证这些设计在代码中的真实形态为升级选型与生产部署提供依据。需要说明的适用前提官方 changelog 完整记录了 2.x 系列0.x 为历史摘要当前仓库版本已推进到3.4.4本文对源码现状的引用均标注“当前源码”以区分 changelog 记载的历史事实。版本总览一条从 PDF 解析工具到文档智能引擎的演进线官方 changelog 按系列组织版本整体脉络可以归纳为四个阶段0.x 阶段2024.07 起项目首次开源2024/07/05快速补齐表格识别0.7.x 引入 TableMaster、0.9.3 集成 RapidTable、混合 OCR 文本抽取0.10.0与大规模代码重构0.9.0引入doclayout_yolo、unimernet 0.2.1公式解析1.x 阶段2025.01–2025.05首个正式发布 1.0.1 确立了新版 API 接口与自动语言识别1.1.0 升级布局模型至doclayout_yolo(2501)并加入标题分级功能1.3.0 移除detectron2依赖、支持批量小文件解析小文件批处理场景公式解析提速最高 1400%、最低 6GB 显存即可运行1.3.x 系列持续升级 OCR 模型至 PP-OCRv4/v5 并支持手写文档2.0–2.5 阶段2025.06–2025.092.0 彻底重构下文详述2.1.0 引入 PP-OCRv5 多语言模型与内置 FastAPI/Gradio 服务2.2.0 引入新表格识别模型与跨页表格合并2.5.2 发布 MinerU2.5 多模态模型vlm 后端进入 2.5 时代2.6–2.7 阶段2025.09–2026.02推理引擎生态扩展MLX、lmdeploy、并发控制、2.7.0 引入hybrid新后端并将其设为默认后端、2.7.x 系列完成 11 家国产算力平台适配。这套演进节奏对使用者的直接含义是版本号不只是 bugfix 计数而是能力边界的划分。例如hybrid后端在 2.7.0 才出现vlm 2.5 模型与 MinerU2.0-2505-0.9B 模型互不兼容最后支持 2.0 模型的版本是mineru-2.2.2跨大版本升级前必须先确认自己的模型与后端组合是否仍在支持范围。2.0架构级重构是理解 MinerU 现代形态的起点2.0.02025/06/13是 MinerU 2 系列的奠基版本changelog 将其列为“深度重构”核心变化有五条每一条都直接决定了今天的代码组织彻底移除pymupdf依赖。项目向更开放的开源合规方向演进PDF 底层读取改由pdfium系方案承接——当前源码中 pdfium_guard.py 的存在印证了这条路线。配置交互简化。不再需要手工编辑 JSON 配置文件大部分参数改为命令行或 API 直接设置同时 2.1.0 起又通过配置文件保留了“扩展开关”能力自定义公式分隔符、标题分级、本地模型目录。自动模型管理。内置模型自动下载/更新机制与离线部署用的模型下载命令当前入口为mineru-models-download见 pyproject.toml 的[project.scripts]段。统一中间格式。采用标准化middle_json格式作为各后端共同的中间产物官方输出文件说明见 output_files这保证了基于该格式的二次开发在版本间可平滑迁移。不兼容变更Python 包名与命令行工具从magic-pdf更名为mineru2.0 起不再内置 LibreOffice 文档转换模块Office 文档建议先经独立 LibreOffice 服务转为 PDF。changelog 特别提醒要同步更新脚本与命令调用——对从 1.x 迁移的用户这是最实际的行动项。2.0 同时引入了首代小于 1B 参数的多模态文档解析模型2505-0.9B单卡 NVIDIA 4090 上通过sglang加速宣称可达 10000 tokens/s 的峰值吞吐。该模型与 2.5 模型互不兼容vlm 后端最后一次支持它的版本是mineru-2.2.2。vlm 后端演进从 sglang 到 vllm再到多引擎并存vlm 后端的推理引擎演进是 changelog 中信息密度最高的主线之一版本引擎相关变化2.1.0适配sglang 0.4.8vlm-sglang显存需求降至 8GBTuring 架构及以上sglang-engine支持透传全部 sglang 参数2.5.2vlm 后端升级至 2.5加速框架从sglang切换为vllm实现与 vllm 生态全面兼容VLM 推理代码抽离至独立包降低与主仓库的耦合2.5.3调整依赖版本范围使 Turing 及更早架构 GPU 也能用 vLLM 加速vLLM async 后端默认并发下调以规避高负载断连2.5.4修复部分 PDF 被误判为 AI 文件导致的解析失败——当前源码中 pyproject.toml 引入的magika依赖正是文件类型识别的实现载体2.6.3新增vlm-mlx-engine为 Apple Silicon 提供 MLX 加速相比vlm-transformers提速 100%–200%2.6.5新增vlm-lmdeploy-engine使用 lmdeploy 推理在 Windows 平台支持原生推理加速2.7.0引擎选择简化用户只需选择*-auto-engine由 MinerU 自动挑选合适的本地推理引擎其中 2.5.2 的“代码抽离”值得展开VLM 推理相关代码被移出主仓库主仓库仅保留mineru-vl-utils依赖当前 pyproject.toml 中可见mineru-vl-utils1.0.5,2的硬约束目的是让模型侧可以独立迭代而不拖慢主仓发版。同时middle.json与content_list.json因支持更多布局类型做了结构调整依赖旧结构的二次开发方需对照 output_files 文档适配。2.7.0 的引擎简化在当前源码中留下了清晰的落地痕迹。backend_options.py 定义了公开后端选项与旧名兼容逻辑LEGACY_BACKEND_ALIASES { vlm-auto-engine: BACKEND_VLM_ENGINE, # vlm-engine hybrid-auto-engine: BACKEND_HYBRID_ENGINE, # hybrid-engine }从当前源码结构看3.x 时代后端命名进一步收敛为pipeline、vlm-engine、hybrid-engine及对应的*-http-client形态2.7 文档中的hybrid-auto-engine被保留为别名以兼容旧脚本——也就是说你按 changelog 写的旧命令在现在的代码里依然能跑通这是该兼容层设计的直接价值。2.7.0 深度解析hybrid 后端为何成为新默认2.7.02025/12/30是 changelog 中技术含量最高的单版本它一次性完成了三件事新增hybrid后端融合pipeline与vlm两类路线的长处对文本型 PDF 走直接文本抽取原生支持多语言且“幻觉”风险远低于纯视觉模型路线对扫描件在指定 OCR 语言时支持109 种语言的 OCR提供独立的行内公式开关不需要行内公式渲染时可关闭以换取效果与速度。默认后端从pipeline切换为hybrid-auto-engine目标是开箱即用的一致性。当前源码中DEFAULT_BACKEND BACKEND_HYBRID_ENGINEbackend_options.py印证了这一决策一直延续至今。安装流程简化uv pip install mineru[all]一条命令装齐所有可选后端依赖不再需要单独安装 VLM 引擎。当前 pyproject.toml 中allextra 的构成与此完全对应all [ mineru[core], mineru[s3], mineru[mlx] ; sys_platform darwin, # Apple Silicon mineru[vllm] ; sys_platform linux, # Linux mineru[lmdeploy] ; sys_platform win32,# Windows ]可以看到mlx/vllm/lmdeploy按操作系统做了条件分发这正是 2.6.3MLX、2.6.5lmdeploy两个引擎新增版本之后2.7.0 在安装层的一次收口。此外 2.7.0 还为 Gradio 应用加入了中英双语 i18n。生产部署调优changelog 里散落的环境变量全景changelog 在 2.5.x–2.6.x 期间陆续加入了一批面向高并发服务场景的环境变量散落在多个版本中。这里汇总成一张速查表并逐一给出当前源码中的实现证据方便在生产mineru-api部署时直接取用环境变量引入版本作用源码位置与默认值MINERU_PDF_RENDER_TIMEOUT2.6.4PDF 图像渲染超时防止异常 PDF 长时间阻塞渲染进程os_env_config.py默认 300 秒MINERU_PDF_RENDER_THREADS当前源码渲染线程数changelog 未单列源码新增os_env_config.py默认 3MINERU_INTRA_OP_NUM_THREADS2.6.4ONNX 模型 op 内线程数缓解高并发下 CPU 资源争抢table_structure.py 等 ONNX 表格结构模型初始化处-1 表示交给运行时按系统核数MINERU_INTER_OP_NUM_THREADS2.6.4ONNX 模型 op 间线程数同上同上MINERU_API_ENABLE_FASTAPI_DOCS2.6.6控制mineru-api自动生成接口文档页是否开启fast_api.py默认开启设为0关闭MINERU_API_MAX_CONCURRENT_REQUESTS2.6.6限制vlm-vllm-async-engine、vlm-lmdeploy-engine、vlm-http-client后端的最大并发 API 请求数客户端侧在 api_client.py 注入该环境变量默认不限MINERU_FORMULA_CH_SUPPORT2.6.2开启中文公式实验性支持1开 /0关model_init.py默认False官方提示可能轻微降低 MFR 速度并使部分长公式识别失败建议仅在解析中文公式时开启MINERU_TABLE_MERGE_ENABLE2.6.2跨页表格合并开关默认开启runtime_utils.py设为0关闭非法值会打印 warning 并按默认处理这组变量背后有一条一致的工程逻辑2.5.x 之后 MinerU 把“本地单机跑一遍”和“mineru-api常驻服务承载流量”当作了两种负载模型。2.5.3 下调 vLLM async 默认并发、2.6.4 给渲染加超时和 ONNX 线程上限、2.6.6 给 API 层加并发闸都是为第二种模型兜底。如果你的部署形态是服务化高并发这四个版本引入的变量应当作为启动参数清单的默认检查项。pipeline 后端与表格/OCR 能力的持续加固对不使用 VLM 的纯pipeline路线changelog 记录的能力演进同样密集核心节点如下2.2.02025/09/05引入新版有线表格识别模型与混合表格结构解析算法pipeline与vlm双后端支持跨页表格合并pipeline支持 270 度旋转表格解析覆盖 0/90/270 三个方向新增泰语、希腊语 OCRPP-OCRv5 口径下泰语模型准确率 82.68%、希腊语 89.28%输出content_list.json新增 0–1000 归一化的bbox字段便于直接取用内容块位置2.2.1 / 2.2.2修复模型下载命令漏下新模型、以及单表解析失败拖累整体任务的问题2.6.2OCR 速度提升 200%–300%西里尔、阿拉伯、天城文、泰卢固、泰米尔语系升级至ppocr-v5版本准确率较前代提升 40% 以上vlm 侧优化了多表格连续场景下table_caption/table_footnote的匹配逻辑2.7.22026/01/23继续改进跨页表格合并的成功率与合并质量2.7.12026/01/06升级pdfminer.six依赖以修复上游安全公告 CVE-2025-64512并为输入图像增加 EXIF 方向自动校正以提升 OCR 精度。值得留意的是表格结构解析的 ONNX 模型slanet_plus与unet_table两套是 ONNX 线程变量的实际作用对象这解释了为什么 2.6.4 的线程配置被放在表格结构识别模型初始化处读取而不是全局生效——调参时预期收益主要在高并发的表格解析场景。国产算力生态2.7 系列补齐的平台版图2.7 系列用一个季度完成了国产算力平台的规模化适配这是 changelog 中值得单独记录的工程事实2.7.22026/01/23新增海光Hygon、燧原Enflame、摩尔线程Moore Threads2.7.42026/01/30新增天数智芯IluvatarCorex、寒武纪Cambricon2.7.62026/02/06新增昆仑芯Kunlunxin、沐曦Tecorigin。至此官方口径的适配平台清单为昇腾Ascend、平头哥T-Head、沐曦METAX、海光、燧原、摩尔线程、天数智芯、寒武纪、昆仑芯、Tecorigin、壁仞Biren共 11 家。当前仓库的目录结构与之呼应docker/china/ 下按平台提供了npu.Dockerfile昇腾、dcu.Dockerfile海光、musa.Dockerfile摩尔线程、maca.Dockerfile燧原、kxpu.Dockerfile昆仑芯、corex.Dockerfile天数智芯等镜像构建文件docs/zh/usage/acceleration_cards/ 下也有逐平台的部署文档。如果你的算力环境在上述清单内官方 Docker 镜像路线通常比自装依赖更稳妥。从 1.x 到 2.7升级路径建议结合 changelog 的全部不兼容点给不同起点的读者三条落地建议从 magic-pdf 1.x 升级优先处理三件事——命令与包名替换magic-pdf→mineru、移除对内置 LibreOffice 转换流程的依赖Office 文档改为外部转 PDF、核对依赖middle_json结构的二次开发代码2.5.2 有结构调整。1.3.x 时代的magic-pdf.json配置项在 2.0 后大多被命令行/API 参数取代可按 quick usage 重新组织调用。模型与后端组合要成对选择MinerU2.0-2505-0.9B 模型在mineru-2.2.2之后不再被 vlm 后端支持MinerU2.5 模型从 2.5.2 起要求 vllm 系加速路线。选型前先确认手里的模型快照与目标版本的配套关系而不是只看版本号大小。默认后端已变行为假设要更新2.7.0 起默认后端是 hybrid 路线当前源码默认hybrid-engine如果你的脚本依赖旧的默认行为隐式pipeline请显式传入--backend参数锁定后端避免升级后结果差异。Gradio 与 API 入口的行为同样建议显式化。结语这份 changelog 呈现的是一条清晰的路线0.9–1.x 解决“跑得起来、跑得快”2.0 解决“架构可持续”2.5 解决“精度天花板”2.6–2.7 解决“生态宽度与生产化”。对照当前仓库3.4.4的代码现状——hybrid成为默认后端、mineru-vl-utils独立成包、多推理引擎按平台条件分发、服务化环境变量齐备——可以确认 changelog 中记载的方向性决策均已在代码层面固化。对于二次开发者middle_json与content_list.json的结构约定见 output_files是最需要盯住的两份契约对于运维部署者前文环境变量表与国产平台 Dockerfile 清单则是最直接的操作依据。【免费下载链接】MinerUTransforms complex documents like PDFs and Office docs into LLM-ready markdown/JSON for your Agentic workflows.项目地址: https://gitcode.com/GitHub_Trending/mi/MinerU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 MinerU 版本演进全解：从 magic-pdf 重构到 hybrid 后端，读懂官方 Changelog 背后的技术决策
MinerU 版本演进全解从 magic-pdf 重构到 hybrid 后端读懂官方 Changelog 背后的技术决策【免费下载链接】MinerUTransforms complex documents like PDFs and Office docs into LLM-ready markdown/JSON for your Agentic workflows.项目地址: https://gitcode.com/GitHub_Trending/mi/MinerU本文以 MinerU 官方变更日志 changelog 为骨架系统梳理 MinerU 从 0.x 开源到 2.7 系列的关键版本演进2.0 的架构重构、MinerU2.5 多模态模型的接入、hybrid混合后端的诞生以及 API 服务侧一组可落地的环境变量调优手段。读完本文你不仅能看懂每个大版本的“为什么”还能结合当前仓库源码版本3.4.4见 version.py验证这些设计在代码中的真实形态为升级选型与生产部署提供依据。需要说明的适用前提官方 changelog 完整记录了 2.x 系列0.x 为历史摘要当前仓库版本已推进到3.4.4本文对源码现状的引用均标注“当前源码”以区分 changelog 记载的历史事实。版本总览一条从 PDF 解析工具到文档智能引擎的演进线官方 changelog 按系列组织版本整体脉络可以归纳为四个阶段0.x 阶段2024.07 起项目首次开源2024/07/05快速补齐表格识别0.7.x 引入 TableMaster、0.9.3 集成 RapidTable、混合 OCR 文本抽取0.10.0与大规模代码重构0.9.0引入doclayout_yolo、unimernet 0.2.1公式解析1.x 阶段2025.01–2025.05首个正式发布 1.0.1 确立了新版 API 接口与自动语言识别1.1.0 升级布局模型至doclayout_yolo(2501)并加入标题分级功能1.3.0 移除detectron2依赖、支持批量小文件解析小文件批处理场景公式解析提速最高 1400%、最低 6GB 显存即可运行1.3.x 系列持续升级 OCR 模型至 PP-OCRv4/v5 并支持手写文档2.0–2.5 阶段2025.06–2025.092.0 彻底重构下文详述2.1.0 引入 PP-OCRv5 多语言模型与内置 FastAPI/Gradio 服务2.2.0 引入新表格识别模型与跨页表格合并2.5.2 发布 MinerU2.5 多模态模型vlm 后端进入 2.5 时代2.6–2.7 阶段2025.09–2026.02推理引擎生态扩展MLX、lmdeploy、并发控制、2.7.0 引入hybrid新后端并将其设为默认后端、2.7.x 系列完成 11 家国产算力平台适配。这套演进节奏对使用者的直接含义是版本号不只是 bugfix 计数而是能力边界的划分。例如hybrid后端在 2.7.0 才出现vlm 2.5 模型与 MinerU2.0-2505-0.9B 模型互不兼容最后支持 2.0 模型的版本是mineru-2.2.2跨大版本升级前必须先确认自己的模型与后端组合是否仍在支持范围。2.0架构级重构是理解 MinerU 现代形态的起点2.0.02025/06/13是 MinerU 2 系列的奠基版本changelog 将其列为“深度重构”核心变化有五条每一条都直接决定了今天的代码组织彻底移除pymupdf依赖。项目向更开放的开源合规方向演进PDF 底层读取改由pdfium系方案承接——当前源码中 pdfium_guard.py 的存在印证了这条路线。配置交互简化。不再需要手工编辑 JSON 配置文件大部分参数改为命令行或 API 直接设置同时 2.1.0 起又通过配置文件保留了“扩展开关”能力自定义公式分隔符、标题分级、本地模型目录。自动模型管理。内置模型自动下载/更新机制与离线部署用的模型下载命令当前入口为mineru-models-download见 pyproject.toml 的[project.scripts]段。统一中间格式。采用标准化middle_json格式作为各后端共同的中间产物官方输出文件说明见 output_files这保证了基于该格式的二次开发在版本间可平滑迁移。不兼容变更Python 包名与命令行工具从magic-pdf更名为mineru2.0 起不再内置 LibreOffice 文档转换模块Office 文档建议先经独立 LibreOffice 服务转为 PDF。changelog 特别提醒要同步更新脚本与命令调用——对从 1.x 迁移的用户这是最实际的行动项。2.0 同时引入了首代小于 1B 参数的多模态文档解析模型2505-0.9B单卡 NVIDIA 4090 上通过sglang加速宣称可达 10000 tokens/s 的峰值吞吐。该模型与 2.5 模型互不兼容vlm 后端最后一次支持它的版本是mineru-2.2.2。vlm 后端演进从 sglang 到 vllm再到多引擎并存vlm 后端的推理引擎演进是 changelog 中信息密度最高的主线之一版本引擎相关变化2.1.0适配sglang 0.4.8vlm-sglang显存需求降至 8GBTuring 架构及以上sglang-engine支持透传全部 sglang 参数2.5.2vlm 后端升级至 2.5加速框架从sglang切换为vllm实现与 vllm 生态全面兼容VLM 推理代码抽离至独立包降低与主仓库的耦合2.5.3调整依赖版本范围使 Turing 及更早架构 GPU 也能用 vLLM 加速vLLM async 后端默认并发下调以规避高负载断连2.5.4修复部分 PDF 被误判为 AI 文件导致的解析失败——当前源码中 pyproject.toml 引入的magika依赖正是文件类型识别的实现载体2.6.3新增vlm-mlx-engine为 Apple Silicon 提供 MLX 加速相比vlm-transformers提速 100%–200%2.6.5新增vlm-lmdeploy-engine使用 lmdeploy 推理在 Windows 平台支持原生推理加速2.7.0引擎选择简化用户只需选择*-auto-engine由 MinerU 自动挑选合适的本地推理引擎其中 2.5.2 的“代码抽离”值得展开VLM 推理相关代码被移出主仓库主仓库仅保留mineru-vl-utils依赖当前 pyproject.toml 中可见mineru-vl-utils1.0.5,2的硬约束目的是让模型侧可以独立迭代而不拖慢主仓发版。同时middle.json与content_list.json因支持更多布局类型做了结构调整依赖旧结构的二次开发方需对照 output_files 文档适配。2.7.0 的引擎简化在当前源码中留下了清晰的落地痕迹。backend_options.py 定义了公开后端选项与旧名兼容逻辑LEGACY_BACKEND_ALIASES { vlm-auto-engine: BACKEND_VLM_ENGINE, # vlm-engine hybrid-auto-engine: BACKEND_HYBRID_ENGINE, # hybrid-engine }从当前源码结构看3.x 时代后端命名进一步收敛为pipeline、vlm-engine、hybrid-engine及对应的*-http-client形态2.7 文档中的hybrid-auto-engine被保留为别名以兼容旧脚本——也就是说你按 changelog 写的旧命令在现在的代码里依然能跑通这是该兼容层设计的直接价值。2.7.0 深度解析hybrid 后端为何成为新默认2.7.02025/12/30是 changelog 中技术含量最高的单版本它一次性完成了三件事新增hybrid后端融合pipeline与vlm两类路线的长处对文本型 PDF 走直接文本抽取原生支持多语言且“幻觉”风险远低于纯视觉模型路线对扫描件在指定 OCR 语言时支持109 种语言的 OCR提供独立的行内公式开关不需要行内公式渲染时可关闭以换取效果与速度。默认后端从pipeline切换为hybrid-auto-engine目标是开箱即用的一致性。当前源码中DEFAULT_BACKEND BACKEND_HYBRID_ENGINEbackend_options.py印证了这一决策一直延续至今。安装流程简化uv pip install mineru[all]一条命令装齐所有可选后端依赖不再需要单独安装 VLM 引擎。当前 pyproject.toml 中allextra 的构成与此完全对应all [ mineru[core], mineru[s3], mineru[mlx] ; sys_platform darwin, # Apple Silicon mineru[vllm] ; sys_platform linux, # Linux mineru[lmdeploy] ; sys_platform win32,# Windows ]可以看到mlx/vllm/lmdeploy按操作系统做了条件分发这正是 2.6.3MLX、2.6.5lmdeploy两个引擎新增版本之后2.7.0 在安装层的一次收口。此外 2.7.0 还为 Gradio 应用加入了中英双语 i18n。生产部署调优changelog 里散落的环境变量全景changelog 在 2.5.x–2.6.x 期间陆续加入了一批面向高并发服务场景的环境变量散落在多个版本中。这里汇总成一张速查表并逐一给出当前源码中的实现证据方便在生产mineru-api部署时直接取用环境变量引入版本作用源码位置与默认值MINERU_PDF_RENDER_TIMEOUT2.6.4PDF 图像渲染超时防止异常 PDF 长时间阻塞渲染进程os_env_config.py默认 300 秒MINERU_PDF_RENDER_THREADS当前源码渲染线程数changelog 未单列源码新增os_env_config.py默认 3MINERU_INTRA_OP_NUM_THREADS2.6.4ONNX 模型 op 内线程数缓解高并发下 CPU 资源争抢table_structure.py 等 ONNX 表格结构模型初始化处-1 表示交给运行时按系统核数MINERU_INTER_OP_NUM_THREADS2.6.4ONNX 模型 op 间线程数同上同上MINERU_API_ENABLE_FASTAPI_DOCS2.6.6控制mineru-api自动生成接口文档页是否开启fast_api.py默认开启设为0关闭MINERU_API_MAX_CONCURRENT_REQUESTS2.6.6限制vlm-vllm-async-engine、vlm-lmdeploy-engine、vlm-http-client后端的最大并发 API 请求数客户端侧在 api_client.py 注入该环境变量默认不限MINERU_FORMULA_CH_SUPPORT2.6.2开启中文公式实验性支持1开 /0关model_init.py默认False官方提示可能轻微降低 MFR 速度并使部分长公式识别失败建议仅在解析中文公式时开启MINERU_TABLE_MERGE_ENABLE2.6.2跨页表格合并开关默认开启runtime_utils.py设为0关闭非法值会打印 warning 并按默认处理这组变量背后有一条一致的工程逻辑2.5.x 之后 MinerU 把“本地单机跑一遍”和“mineru-api常驻服务承载流量”当作了两种负载模型。2.5.3 下调 vLLM async 默认并发、2.6.4 给渲染加超时和 ONNX 线程上限、2.6.6 给 API 层加并发闸都是为第二种模型兜底。如果你的部署形态是服务化高并发这四个版本引入的变量应当作为启动参数清单的默认检查项。pipeline 后端与表格/OCR 能力的持续加固对不使用 VLM 的纯pipeline路线changelog 记录的能力演进同样密集核心节点如下2.2.02025/09/05引入新版有线表格识别模型与混合表格结构解析算法pipeline与vlm双后端支持跨页表格合并pipeline支持 270 度旋转表格解析覆盖 0/90/270 三个方向新增泰语、希腊语 OCRPP-OCRv5 口径下泰语模型准确率 82.68%、希腊语 89.28%输出content_list.json新增 0–1000 归一化的bbox字段便于直接取用内容块位置2.2.1 / 2.2.2修复模型下载命令漏下新模型、以及单表解析失败拖累整体任务的问题2.6.2OCR 速度提升 200%–300%西里尔、阿拉伯、天城文、泰卢固、泰米尔语系升级至ppocr-v5版本准确率较前代提升 40% 以上vlm 侧优化了多表格连续场景下table_caption/table_footnote的匹配逻辑2.7.22026/01/23继续改进跨页表格合并的成功率与合并质量2.7.12026/01/06升级pdfminer.six依赖以修复上游安全公告 CVE-2025-64512并为输入图像增加 EXIF 方向自动校正以提升 OCR 精度。值得留意的是表格结构解析的 ONNX 模型slanet_plus与unet_table两套是 ONNX 线程变量的实际作用对象这解释了为什么 2.6.4 的线程配置被放在表格结构识别模型初始化处读取而不是全局生效——调参时预期收益主要在高并发的表格解析场景。国产算力生态2.7 系列补齐的平台版图2.7 系列用一个季度完成了国产算力平台的规模化适配这是 changelog 中值得单独记录的工程事实2.7.22026/01/23新增海光Hygon、燧原Enflame、摩尔线程Moore Threads2.7.42026/01/30新增天数智芯IluvatarCorex、寒武纪Cambricon2.7.62026/02/06新增昆仑芯Kunlunxin、沐曦Tecorigin。至此官方口径的适配平台清单为昇腾Ascend、平头哥T-Head、沐曦METAX、海光、燧原、摩尔线程、天数智芯、寒武纪、昆仑芯、Tecorigin、壁仞Biren共 11 家。当前仓库的目录结构与之呼应docker/china/ 下按平台提供了npu.Dockerfile昇腾、dcu.Dockerfile海光、musa.Dockerfile摩尔线程、maca.Dockerfile燧原、kxpu.Dockerfile昆仑芯、corex.Dockerfile天数智芯等镜像构建文件docs/zh/usage/acceleration_cards/ 下也有逐平台的部署文档。如果你的算力环境在上述清单内官方 Docker 镜像路线通常比自装依赖更稳妥。从 1.x 到 2.7升级路径建议结合 changelog 的全部不兼容点给不同起点的读者三条落地建议从 magic-pdf 1.x 升级优先处理三件事——命令与包名替换magic-pdf→mineru、移除对内置 LibreOffice 转换流程的依赖Office 文档改为外部转 PDF、核对依赖middle_json结构的二次开发代码2.5.2 有结构调整。1.3.x 时代的magic-pdf.json配置项在 2.0 后大多被命令行/API 参数取代可按 quick usage 重新组织调用。模型与后端组合要成对选择MinerU2.0-2505-0.9B 模型在mineru-2.2.2之后不再被 vlm 后端支持MinerU2.5 模型从 2.5.2 起要求 vllm 系加速路线。选型前先确认手里的模型快照与目标版本的配套关系而不是只看版本号大小。默认后端已变行为假设要更新2.7.0 起默认后端是 hybrid 路线当前源码默认hybrid-engine如果你的脚本依赖旧的默认行为隐式pipeline请显式传入--backend参数锁定后端避免升级后结果差异。Gradio 与 API 入口的行为同样建议显式化。结语这份 changelog 呈现的是一条清晰的路线0.9–1.x 解决“跑得起来、跑得快”2.0 解决“架构可持续”2.5 解决“精度天花板”2.6–2.7 解决“生态宽度与生产化”。对照当前仓库3.4.4的代码现状——hybrid成为默认后端、mineru-vl-utils独立成包、多推理引擎按平台条件分发、服务化环境变量齐备——可以确认 changelog 中记载的方向性决策均已在代码层面固化。对于二次开发者middle_json与content_list.json的结构约定见 output_files是最需要盯住的两份契约对于运维部署者前文环境变量表与国产平台 Dockerfile 清单则是最直接的操作依据。【免费下载链接】MinerUTransforms complex documents like PDFs and Office docs into LLM-ready markdown/JSON for your Agentic workflows.项目地址: https://gitcode.com/GitHub_Trending/mi/MinerU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考