MinerU 版本演进全解读从 0.x 首次开源到 2.7 系列的后端路线图与环境变量速查【免费下载链接】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 从 2024/07/05 首次开源到 2.7 系列的能力演进主线pipeline / vlm / hybrid 三类后端的兴衰更替、推理引擎从 sglang 到 vllm/lmdeploy/MLX 的迁移、国产算力平台的适配进程以及贯穿各版本的环境变量配置项。读完后你可以按版本对照源码定位每一项能力的实现落点并在升级、回退或选型时快速判断兼容边界。一、先看清版本坐标文档覆盖范围与当前仓库状态更新日志文档记录了项目自 0.x 系列首次开源 2024/07/05至 2.7.62026/02/06的完整更新历史。需要注意一点版本事实当前仓库 版本声明 中的__version__已为3.4.4即仓库代码已经演进到更新日志最后一个条目之后的阶段因此文中涉及“当前行为”的描述一律以当前源码为准而版本条目本身忠实保留更新日志的原始表述。从 pyproject.toml 可以还原出各版本提到的命令与依赖在今天的实际形态包名为mineru关键词中仍保留magic-pdf呼应 2.0 的改名历史Python 要求3.10,3.14注册的命令行入口包括mineru主解析入口mineru.cli.client:main、mineru-apiFastAPI 服务、mineru-router多 worker 路由服务、mineru-gradioWebUI、mineru-models-download离线模型下载、mineru-vllm-server/mineru-lmdeploy-server/mineru-openai-serverVLM 推理服务端。更新日志中 2.1.1 提到的“compose.yaml 便于启动 sglang-server、mineru-api、mineru-gradio”等服务在当前仓库对应为 docker/compose.yaml 及上述入口脚本可选依赖组core vlm pipeline gradio而all core s3 平台相关加速项macOS 下装mlx、Linux 下装vllm、Windows 下装lmdeploy这正是 2.7.0 “uv pip install mineru[all]一条命令装齐所有可选后端依赖”的落地方式。二、2.7 系列hybrid 后端成为默认国产算力版图补全2.7.6 / 2.7.4 / 2.7.2国产算力平台适配持续推进2.7.62026/02/06新增昆仑芯、太初元碁的适配支持。至此官方和厂商适配并支持的国产算力平台共 11 家昇腾、平头哥、沐曦、海光、燧原、摩尔线程、天数智芯、寒武纪、昆仑芯、太初元碁、壁仞2.7.42026/01/30新增天数智芯、寒武纪的适配支持2.7.22026/01/23新增海光、燧原、摩尔线程的适配支持同时优化跨页表合并提升合并成功率与合并效果。当前仓库在 docs/zh/usage/acceleration_cards 目录下按平台放置了各加速卡的适配文档含 AMD、Ascend、Biren、Cambricon、Enflame、Hygon、IluvatarCorex、Kunlunxin、METAX、MooreThreads、THead、Tecorigin、VastAI 等文件是排查国产平台安装与运行问题的第一手资料。2.7.1安全依赖升级与 EXIF 方向校正修复缺陷issue #4300更新pdfminer.six依赖版本解决 CVE-2025-64512支持输入图像的 EXIF 方向自动校正提升 OCR 识别效果issue #4283。源码印证当前 pdf_image_tools.py 在读取图像时执行ImageOps.exif_transpose(image)依据 EXIF 的 Orientation 标记自动转正手机拍摄的倾斜照片避免 OCR 识别到旋转 90°/180° 的文字导致乱码。2.7.0hybrid 后端登场并取代 pipeline 成为默认这是更新日志中信息密度最高的一个版本简化安装流程uv pip install mineru[all]即可安装所有可选后端依赖增加全新后端hybrid结合pipeline与vlm的优势从文本 PDF 中直接抽取文本在文本 PDF 场景原生支持多语言识别并大幅减少解析幻觉通过指定 OCR 语言在扫描 PDF 场景支持 109 种语言的文本识别支持独立的行内公式识别开关在不需要时可单独关闭以改善结果视觉效果简化vlm/hybrid后端的引擎选择逻辑用户只需指定*-auto-engine即可自动选择合适的推理引擎默认解析后端从pipeline切换至hybrid-auto-engine提升新用户开箱即用时的结果一致性Gradio 应用增加 i18n 适配支持中英文切换。源码印证hybrid 后端的独立实现位于 mineru/backend/hybrid 目录hybrid_analyze.py、hybrid_magic_model.py、hybrid_model_output_to_middle_json.py与pipeline、vlm、office并列佐证了“混合抽取”是一条独立管线而非简单拼接backend_options.py 中DEFAULT_BACKEND BACKEND_HYBRID_ENGINE公开后端为pipeline、vlm-engine、hybrid-engine以及对应的*-http-client远程模式并保留LEGACY_BACKEND_ALIASES将旧名vlm-auto-engine、hybrid-auto-engine规范映射为新名——即 2.7.0 时期的*-auto-engine命名在后续版本中已演进出更简洁的*-engine名称旧写法仍向后兼容。三、2.6 系列引擎生态扩展与运行时参数系统化2.6.72025/12/12bug 修复修复缺陷issue #4168。2.6.62025/12/02Ascend 适配优化与 mineru-api 工具优化Ascend 适配优化优化命令行工具初始化流程使 Ascend 适配方案中vlm-vllm-engine后端在命令行工具中可用为 Atlas 300I Duo310p设备更新适配文档。mineru-api 工具优化为mineru-api接口参数增加描述性文本优化接口文档可读性可通过环境变量MINERU_API_ENABLE_FASTAPI_DOCS控制是否启用自动生成的接口文档页面默认为启用为vlm-vllm-async-engine、vlm-lmdeploy-engine、vlm-http-client后端增加并发数配置选项可通过环境变量MINERU_API_MAX_CONCURRENT_REQUESTS控制 api 接口的最大并发请求数默认为不限制数量。源码印证fast_api.py 与 router.py 中create_app()均以env_flag_enabled(MINERU_API_ENABLE_FASTAPI_DOCS, defaultTrue)决定是否挂载/docs、/openapi.json端点并发数的读取与校验在 config_reader.py 中实现要求正整数。演进提示当前仓库中该变量在 API worker 侧的默认值已调整为 3见 cli_tools 文档 与 api_client.py而非 2.6.6 时期的“不限制”。2.6.52025/11/26lmdeploy 引擎与三张国产卡增加新后端vlm-lmdeploy-engine支持使用方式与vlm-vllm-(async)engine类似但以lmdeploy作为推理引擎与vllm相比额外支持 Windows 平台原生推理加速新增国产算力平台昇腾/npu、平头哥/ppu、沐曦/maca的适配支持用户可在对应平台上使用pipeline与vlm模型并使用vllm/lmdeploy引擎加速 vlm 模型推理更新日志同时提醒国产平台适配不易官方已尽量确保完整性和稳定性但仍可能存在稳定性/兼容问题与精度对齐问题建议按各适配文档页面内的红绿灯情况选择环境遇到文档未提及的问题请在官方 discussions 指定帖子中反馈。源码印证pyproject.toml 中的lmdeploy可选依赖组lmdeploy0.10.2,0.12qwen-vl-utils以及all组中mineru[lmdeploy] ; sys_platform win32的平台标记与“Windows 原生推理加速”的定位一致服务端入口mineru-lmdeploy-server即为此后端的配套工具。2.6.42025/11/04两个关键的运行时保护参数为 pdf 渲染图片增加超时配置默认为 300 秒可通过环境变量MINERU_PDF_RENDER_TIMEOUT配置防止部分异常 pdf 文件导致渲染过程长时间阻塞为 onnx 模型增加 cpu 线程数配置选项默认为系统 cpu 核心数可通过环境变量MINERU_INTRA_OP_NUM_THREADS和MINERU_INTER_OP_NUM_THREADS配置减少高并发场景下对 cpu 资源的抢占冲突。源码印证os_env_config.py 中get_load_images_timeout()默认 300 秒该值被 pdf_image_tools.py 在渲染 pdf 页面为图片时消费get_op_num_threads()读取两个 ONNX 线程变量未设置或非法值时回退为-1即交由 onnxruntime 使用系统核心数。此外当前源码还带有MINERU_PDF_RENDER_THREADS渲染并发线程数默认 3属于日志未单列但实际存在的配套参数。2.6.32025/10/31MLX 引擎登陆 Apple Silicon增加新后端vlm-mlx-engine支持在 Apple Silicon 设备上使用MLX加速MinerU2.5模型推理相比vlm-transformers后端速度提升 100%~200%缺陷修复issue #3849、#3859。源码印证mlx可选依赖组mlx-vlmmlx只被all组在sys_platform darwin时装载与“仅 Apple Silicon”的适用边界吻合。2.6.22025/10/24OCR 大提速、表格合并开关与公式中文化pipeline 后端优化增加对中文公式的实验性支持配置环境变量export MINERU_FORMULA_CH_SUPPORT1开启。该功能可能导致 MFR 速率略微下降、部分长公式识别失败等问题建议仅在需要解析中文公式的场景下开启设置为0可关闭OCR 速度大幅提升 200%~300%致谢社区贡献者提供的优化方案OCR 模型优化拉丁文识别的准度和广度并将西里尔文、阿拉伯文、天城文、泰卢固语、泰米尔文语系更新至ppocr-v5版本精度相比上代模型提升 40% 以上。vlm 后端优化table_caption、table_footnote匹配逻辑优化提升页内多张连续表场景下表格标题和脚注的匹配准确率与阅读顺序合理性优化使用vllm后端时高并发下的 cpu 资源占用降低服务端压力适配vllm0.11.0 版本。通用优化跨页表格合并效果优化新增跨页续表合并支持提升多列合并场景下的表格合并效果为表格合并功能增加环境变量MINERU_TABLE_MERGE_ENABLE功能默认开启可设置为0关闭。源码印证公式开关在 model_init.py 中直接决定 MFR 模型选择——MINERU_FORMULA_CH_SUPPORT为真值时选用pp_formulanet_plus_m面向中文公式训练为假值时使用默认的unimernet_small非法值会打印警告并回退默认表格合并在 runtime_utils.py 中实现读取MINERU_TABLE_MERGE_ENABLE默认true取值为true/1/yes时执行merge_table(pdf_info)false/0/no时跳过未知值仅告警与“默认开启”的描述一致。四、2.5 系列MinerU2.5 发布与仓库结构性调整2.5.42025/09/26MinerU2.5 技术报告发布可阅读其模型架构、训练策略、数据工程和评测结果修复部分 pdf 文件被误识别成ai文件导致无法解析的问题。这一文件类型识别问题与当前 pyproject.toml 依赖列表中的文件类型识别库magika的引入方向一致从依赖结构看可推断当前版本通过专门的文件指纹识别替代了单纯的后缀判断。2.5.32025/09/20依赖版本范围调整使 Turing 及更早架构显卡可以使用 vLLM 加速推理 MinerU2.5 模型pipeline后端对 torch 2.8.0 的若干兼容性修复降低 vLLM 异步后端默认并发数降低服务端压力避免高压导致的链接关闭问题更多兼容性内容详见官方公告原链接指向外部 discussions此处不再附外链。2.5.22025/09/19MinerU2.5 正式发布官方口径MinerU2.5 仅凭 1.2B 参数在 OmniDocBench 文档解析评测中精度全面超越 Gemini2.5-Pro、GPT-4o、Qwen2.5-VL-72B 等顶级多模态大模型并显著领先于主流文档解析专用模型如 dots.ocr、MonkeyOCR、PP-StructureV3 等。模型发布于 HuggingFace 与 ModelScope 平台。核心亮点极致能效以 1.2B 的轻量化规模实现超越百亿乃至千亿级模型的 SOTA 性能重新定义文档解析的能效比先进架构“两阶段推理”解耦布局分析与内容识别与原生高分辨率架构结合在布局分析、文本识别、公式识别、表格识别及阅读顺序五大方面均达到 SOTA 水平。关键能力提升布局检测结果更完整精准覆盖页眉、页脚、页码等非正文内容并提供更精准的元素定位与更自然的格式还原如列表、参考文献表格解析大幅优化对旋转表格、无线/少线表、长难表格的解析能力公式识别显著提升中英混合公式及复杂长公式的识别准确率大幅改善数学类文档解析能力。仓库调整伴随 vlm 2.5 发布vlm 后端升级至 2.5 版本支持 MinerU2.5 模型不再兼容 MinerU2.0-2505-0.9B 模型最后一个支持 2.0 模型的版本为 mineru-2.2.2vlm 推理相关代码移至独立的mineru-vl-utils包降低与 mineru 主仓库的耦合度便于独立迭代。当前 pyproject.toml 的硬依赖中确有mineru-vl-utils1.0.5,2印证了这次拆分vlm 加速推理框架从sglang切换至vllm实现对 vllm 生态的完全兼容使用户可以在任何支持 vllm 框架的平台上使用 MinerU2.5 模型并加速推理由于 vlm 模型重大升级、支持更多 layout type解析中间文件middle.json和结果文件content_list.json的结构做出调整详见 输出文件说明各后端生成中间文件的代码分别位于 pipeline、vlm、hybrid 目录中。其他仓库优化移除对输入文件的后缀名白名单校验当输入文件为 PDF 文档或图片时对文件的后缀名不再有要求提升易用性。五、2.2–2.4 系列表格解析精度升级2.2.22025/09/10修复新的表格识别模型在部分表格解析失败时影响整体解析任务的问题。2.2.12025/09/08修复使用模型下载命令时部分新增模型未下载的问题对应mineru-models-download入口。2.2.02025/09/05主要更新重点提升表格解析精度引入新的有线表识别模型RapidTable 方向的 TableStructureRec和全新的混合表格结构解析算法显著提升pipeline后端的表格识别能力当前仓库中 mineru/model/table/rec/slanet_plus 目录即为该 SLANet 表结构模型的实现落点增加对跨页表格合并的支持同时支持pipeline和vlm后端进一步提升表格解析的完整性和准确性后续 2.6.2、2.7.2 又持续优化形成一条清晰的表格能力演进线。其他更新pipeline后端增加 270 度旋转的表格解析能力现已支持 0/90/270 度三个方向pipeline增加对泰文、希腊文的 OCR 能力支持并更新英文 OCR 模型至最新版英文识别精度提升 11%泰文识别模型精度 82.68%希腊文识别模型精度 89.28%by PPOCRv5在输出的content_list.json中增加bbox字段映射至 0-1000 范围内方便用户直接获取每个内容块的位置信息移除pipeline_old_linux安装可选项不再支持 CentOS 7 等老版本 Linux 系统以便对uv的sync/run等命令进行更好的支持。六、2.1 系列2.0 大版本后的功能补齐与快速修复2.1 系列由密集的小版本 bug 修复和依赖适配组成其中 2.1.0 是本阶段的功能里程碑。2.1.102025/08/01修复pipeline后端因 block 覆盖导致的解析结果与预期不符issue #32322.1.92025/07/30transformers4.54.1 版本适配2.1.82025/07/28sglang0.4.9.post5 版本适配2.1.72025/07/27transformers4.54.0 版本适配2.1.62025/07/26修复vlm后端解析部分手写文档时的表格异常问题修复文档旋转时可视化框位置漂移问题issue #31752.1.52025/07/24sglang0.4.9 版本适配同步升级 dockerfile 基础镜像为 sglang 0.4.9.post32.1.42025/07/23修复pipeline后端中MFR步骤在某些情况下显存消耗过大的问题issue #2771修复某些情况下image/table与caption/footnote匹配不准确的问题issue #31292.1.12025/07/16修复pipeline在某些情况可能发生的文本块内容丢失问题issue #3005修复sglang-client需要安装torch等不必要包的问题issue #2968更新 dockerfile 修复 linux 字体缺失导致的解析文本内容不完整问题issue #2915易用性方面更新compose.yaml便于直接启动sglang-server、mineru-api、mineru-gradio服务并启用在线文档站点2.1.02025/07/05MinerU 2 的第一个大版本更新。2.1.0 性能优化大幅提升某些特定分辨率长边 2000 像素左右文档的预处理速度大幅提升pipeline后端批量处理大量页数较少10文档时的后处理速度pipeline后端的 layout 分析速度提升约 20%。2.1.0 体验优化内置开箱即用的fastapi服务和gradiowebui当前仓库对应 fast_api.py、gradio_app.py 及各自的mineru-api/mineru-gradio入口sglang适配 0.4.8 版本大幅降低vlm-sglang后端的显存要求最低可在 8G 显存Turing 及以后架构的显卡上运行对所有命令增加sglang的参数透传使sglang-engine后端可以与sglang-server一致接收sglang的所有参数支持基于配置文件的功能扩展自定义公式标识符、开启标题分级功能、自定义本地模型目录。仓库根目录提供了 mineru.template.json 作为该配置模板用户可复制为个人配置使用。2.1.0 新特性pipeline后端更新 PP-OCRv5 多语种文本识别模型支持法语、西班牙语、葡萄牙语、俄语、韩语等 37 种语言的文字识别平均精度涨幅超 30%pipeline后端增加对竖排文本的有限支持。七、2.0 系列架构深度重构的起点2.0.62025/06/20修复vlm模式下某些偶发的无效块内容导致解析中断的问题修复vlm模式下某些不完整的表结构导致的解析中断问题。2.0.52025/06/17修复sglang-client模式下依然需要下载模型的问题修复sglang-client模式依赖torch等实际运行不需要的包的问题修复同一进程内尝试通过多个 url 启动多个sglang-client实例时只有第一个生效的问题。2.0.32025/06/15修复下载模型类型设置为all时配置文件出现键值更新错误的问题修复命令行模式下公式和表格功能开关不生效导致功能无法关闭的问题修复sglang-engine模式下 0.4.7 版本 sglang 的兼容性问题更新 sglang 环境下部署完整版 MinerU 的 Dockerfile 和相关安装文档当前仓库的 docker 目录按 china/global 及各家国产卡组织 Dockerfile。2.0.02025/06/13全新架构全新架构MinerU 2.0 在代码结构和交互方式上进行深度重构显著提升了易用性、可维护性与扩展能力去除第三方依赖限制彻底移除对pymupdf的依赖推动项目向更开放、合规的开源方向迈进。当前 pyproject.toml 中 PDF 渲染相关依赖为pypdfium2与pypdf印证了这一替换开箱即用配置便捷无需手动编辑 JSON 配置文件绝大多数参数已支持命令行或 API 直接设置模型自动管理新增模型自动下载与更新机制用户无需手动干预即可完成模型部署对应 models_download_utils.py 与mineru-models-download命令离线部署友好提供内置模型下载命令支持完全断网环境下的部署需求代码结构精简移除数千行冗余代码简化类继承逻辑统一中间格式输出采用标准化的middle_json格式兼容多数基于该格式的二次开发场景确保生态业务无缝迁移。全新模型小模型大能力模型参数不足 1B却在解析精度上超越传统 72B 级别的视觉语言模型VLM多功能合一单模型覆盖多语言识别、手写识别、版面分析、表格解析、公式识别、阅读顺序排序等核心任务极致推理速度在单卡 NVIDIA 4090 上通过sglang加速达到峰值吞吐量超过 10,000 token/s。不兼容变更说明Python 包名从magic-pdf更改为mineru命令行工具也由magic-pdf改为mineru请同步更新脚本与调用命令当前 pyproject.toml 的[project.scripts]段即全部mineru前缀入口出于系统模块化设计与生态一致性考虑MinerU 2.0 不再内置 LibreOffice 文档转换模块。如需处理 Office 文档建议通过独立部署的 LibreOffice 服务先行转换为 PDF再进行后续解析。注当前仓库又新增了office后端可直接解析 DOCX/PPTX/XLSX见 mineru/backend/office属于后续版本的再演进。八、1.x 系列OCR 模型迭代与安装兼容性打磨1.3.122025/05/24PP-OCRv5 与手写文档支持增加 ppocrv5 模型支持ch_server模型更新为PP-OCRv5_rec_serverch_lite更新为PP-OCRv5_rec_mobile需更新模型。测试发现 ppocrv5(server) 对手写文档效果有一定提升但其余类别文档精度略差于 v4_server_doc因此默认 ch 模型保持不变。可通过lang参数python apilangch_server或命令行--lang ch_server选择lang 取值模型适用场景chPP-OCRv4_rec_server_doc默认中英日繁混合 / 1.5w 字典ch_serverPP-OCRv5_rec_server中英日繁混合 手写场景 / 1.8w 字典ch_litePP-OCRv5_rec_mobile中英日繁混合 手写场景 / 1.8w 字典ch_server_v4PP-OCRv4_rec_server中英混合 / 6k 字典ch_lite_v4PP-OCRv4_rec_mobile中英混合 / 6k 字典同时增加手写文档支持通过优化 layout 对手写文本区域的识别现已支持手写文档解析默认开启无需额外配置手动选择 ppocrv5 模型可获得更好的手写解析效果。1.3.102025/04/291.3.72025/04/221.3.10支持使用自定义公式标识符可通过修改用户目录下magic-pdf.json的latex-delimiter-config项实现2.0 之后该能力纳入配置文件扩展体系模板见 mineru.template.json1.3.9优化公式解析功能提升公式渲染成功率1.3.8ocr默认模型ch更新为PP-OCRv4_server_rec_doc需更新模型。该模型在PP-OCRv4_server_rec基础上混合更多中文文档数据和 PP-OCR 训练数据训练而成支持 1.5 万 字符在中英日繁单语或混合场景精度均有明显提升小部分纯英文场景可能出现单词粘连此类场景可改用langch_serverPP-OCRv4_server_rec1.3.7修复表格解析模型初始化时 lang 参数失效的问题修复 cpu 模式下 OCR 和表格解析速度大幅下降的问题。1.3.42025/04/161.3.02025/04/031.3.4通过移除无用块小幅提升 ocr-det 速度修复部分情况下由 footnote 导致的页面内排序错误1.3.2修复 Windows 系统 python 3.13 环境安装时的依赖版本不兼容问题优化批量推理内存占用优化旋转 90 度表格与财报超大表格的解析效果修复未指定 OCR 语言时英文文本区域偶发单词黏连问题1.3.1支持 python 3.13为部分过时的 linux 系统如 CentOS 7做最后适配不再保证后续版本继续支持1.3.0安装与兼容性移除 layout 中layoutlmv3的使用解决detectron2兼容问题torch 兼容 2.2~2.62.5 除外cuda 兼容 11.8/12.4/12.6/12.8由 torch 决定python 兼容 3.10~3.12离线部署成功后不需要联网下载任何模型文件性能优化支持多个 pdf 文件的 batch 处理当时提供批处理脚本样例当前仓库的演示入口为 demo/demo.py相比 1.0.1 版本公式解析速度最高提升超过 1400%、整体解析速度最高提升超过 500%优化 mfr 模型加载降低显存占用整体显存最低降至 6GB优化 mps 设备运行速度解析效果mfr 模型更新到unimernet(2503)解决多行公式换行丢失问题易用性通过paddleocr2torch完全替代paddle框架与paddleocr的使用解决 paddle 与 torch 冲突及线程不安全问题解析过程增加实时进度条。1.2.12025/03/031.1.02025/01/221.2.1修复字母与数字全角转半角操作对标点符号的影响修复部分情况下 caption 匹配不准确问题修复部分情况下的公式 span 丢失问题1.2.0auto 模式下 pdf 文档分类速度提升优化含水印文档的解析逻辑显著提升解析效果改进单页内多个图像/表格与 caption 的匹配逻辑修复图片/表格 span 被填充进 textblock 的异常修复标题 block 为空的问题1.1.0布局识别模型升级到doclayout_yolo(2501)公式解析模型升级到unimernet(2501)均需重新执行模型下载流程以增量更新在显存 16GB 设备上通过资源占用优化和流水线重构整体解析速度提升 50% 以上在线 demo 新增标题分级功能测试版本默认开启。1.0.12025/01/10首个正式版本全新 API 接口数据侧引入 Dataset 类支持图像.jpg/.png、PDF、Word.doc/.docx、PowerPoint.ppt/.pptx等多种格式用户侧将处理流程设计为可组合的 Stage 阶段用户可自定义新 Stage 并自由组合出专属处理流程更广泛的兼容性适配优化依赖环境确保 ARM 架构 Linux 稳定运行深度适配华为昇腾 NPU 加速自动语言识别引入全新语言识别模型lang配置为auto时自动选择合适的 OCR 语言模型提升扫描类文档解析准确性对应当前源码中的 language.py 等语言识别模块。九、0.x 系列解析流水线的奠基0.10.02024/11/22引入混合 OCR 文本提取能力——在公式密集、span 区域不规范、部分文本以图像呈现等复杂文本分布场景下解析效果显著提升兼具文本模式内容提取准确快速、OCR 模式 span/line 区域识别更准的双重优势0.9.32024/11/15表格识别接入 RapidTable单表解析速度提升 10 倍以上准确率更高、显存占用更低0.9.22024/11/06表格识别接入StructTable-InternVL2-1B模型0.9.02024/10/31大量代码重构的全新版本重构排序模块使用 layoutreader 进行阅读顺序排序确保各种排版下的高准确率重构段落拼接模块跨栏、跨页、跨图、跨表情况下均能良好拼接重构列表和目录识别极大提升列表块和目录块识别准确率重构图、表与描述性文本的匹配逻辑大幅提升 caption 和 footnote 匹配准确率描述性文本丢失率降至接近 0OCR 多语言支持扩展到 84 种语言的检测与识别增加显存回收逻辑开启 layout/公式/OCR 加速不含表格加速的显存需求从 16GB 降至 8GB全加速从 24GB 降至 10GB优化配置开关增加独立公式检测开关无需公式检测时可大幅提升速度和效果集成 PDF-Extract-Kit 1.0加入自研doclayout_yolo模型相近解析效果下比原方案提速 10 倍以上可与layoutlmv3自由切换公式解析升级至unimernet 0.2.1因仓库更换需要重新下载模型0.8.12024/09/27修复若干 bug提供在线 demo 的本地化部署版本和前端界面0.8.02024/09/09支持 Dockerfile 快速部署上线 HuggingFace、ModelScope demo0.7.12024/08/30集成 paddle tablemaster 表格识别功能0.7.0b12024/08/09简化安装步骤提升易用性加入表格识别功能0.6.2b12024/08/01优化依赖冲突问题和安装文档首次开源2024/07/05MinerU 项目首次开源发布。十、实战速查环境变量与源码落点对照将更新日志中散落各版本的环境变量汇总如下所有源码位置均已在当前仓库中核实可直接跳转查看实现细节环境变量引入版本作用与默认值源码落点MINERU_PDF_RENDER_TIMEOUT2.6.4pdf 渲染图片超时秒默认 300防止异常 pdf 长时间阻塞os_env_config.py、pdf_image_tools.pyMINERU_INTRA_OP_NUM_THREADS/MINERU_INTER_OP_NUM_THREADS2.6.4ONNX 模型 cpu 线程数默认系统核心数os_env_config.pyMINERU_TABLE_MERGE_ENABLE2.6.2跨页表格合并开关默认开启设为0关闭runtime_utils.pyMINERU_FORMULA_CH_SUPPORT2.6.2中文公式实验性支持默认关闭开启后 MFR 切换为pp_formulanet_plus_mmodel_init.pyMINERU_API_ENABLE_FASTAPI_DOCS2.6.6控制/docs、/openapi.json自动生成文档页默认启用fast_api.py、router.pyMINERU_API_MAX_CONCURRENT_REQUESTS2.6.6api 接口最大并发请求数早期版本不限制当前默认 3 且须为正整数config_reader.py、api_client.py十一、按版本选型与升级的实用结论后端选择2.7.0 起默认后端为 hybrid 系hybrid-auto-engine现规范名为hybrid-engine文本 PDF 走原生文本抽取、扫描件走多语言 OCR兼顾速度与幻觉控制pipeline与vlm后端仍保留可选远程调用则对应*-http-client模式见 backend_options.py模型兼容边界需要运行 MinerU2.0-2505-0.9B 模型时2.2.2 是最后的可用版本MinerU2.5 模型从 2.5.2 起成为 vlm 后端的唯一支持对象且推理代码已解耦至mineru-vl-utils依赖包推理引擎按平台选择Linux 用 vllm、Windows 用 lmdeploy、Apple Silicon 用 MLXmineru[all]会依据sys_platform自动挑选对应加速依赖国产算力部署11 家平台的适配文档集中在 docs/zh/usage/acceleration_cards建议按文档内的状态说明选择平台与场景升级前必读middle.json/content_list.json在 2.5.2 发生过结构调整lang模型选择在 1.3.x 多次换代命令行包名在 2.0 从magic-pdf改为mineru——这三处是跨大版本升级时脚本最可能断裂的位置对照本文对应章节逐一检查即可。【免费下载链接】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），仅供参考