news 2026/8/24 3:51:41

MinerU GPU 加速排障实录:AMD ROCm 从比 CPU 慢到 27 页/秒

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
MinerU GPU 加速排障实录:AMD ROCm 从比 CPU 慢到 27 页/秒

MinerU GPU 加速排障实录:AMD ROCm 从比 CPU 慢到 27 页/秒

【免费下载链接】MinerUA high-quality tool for convert PDF to Markdown and JSON.一站式开源高质量数据提取工具,将PDF转换成Markdown和JSON格式。项目地址: https://gitcode.com/OpenDataLab/MinerU

我在一台 AMD MI 210 机器上做 MinerU GPU 加速实测,跑出来一组反常识的数字:同一份 7 页文档,GPU 路线用了 142.36 秒,CPU 路线只要 68.14 秒。GPU 不但不加速,反而慢了一倍。下面是完整的排查与修复过程,按时间顺序还原。

排查动线:三个问题层层递进

30 秒确认 PyTorch 是否装错源

我做的第一件事不是查 GPU,而是回答一个问题:当前进程里加载的到底是哪个 PyTorch?ROCm 环境配置里最常见的事故就是渠道混装——pip 默认源给的是 CPU 构建,ROCm 构建必须走 PyTorch 官方的 rocm index。如果 import 出来的 torch 没有 rocm/hip 后缀,那后面查什么硬件都是白查。我的机器上就残留了一份旧 CPU 构建,被新版包叠装后仍会被优先导入。

核对 ROCm 运行时与驱动版本

确认 PyTorch 渠道没问题后,用rocm-smi核对两件事:卡是否被识别、运行时版本是多少。结论是:6.3.4 是可用的基线版本,6.4 对部分 kernel 覆盖更完整。同时 PyTorch 与 ROCm 的主版本必须对齐,rocm6.3 的 wheel 配 ROCm 6.3.x 运行时,跨大版本混搭基本等于把问题从"性能差"换成"直接报错"。

用 rocm-smi 盯出慢在哪个模型文件

前两步排除后,我挂着 rocm-smi 后台跑完整 pipeline:利用率有波动但吞吐停在 0.05 页/秒,说明不是没用到卡,而是有 kernel 走了慢路径。逐段对比耗时后锁定 layout 环节,再回头看模型配置文件model_configs.yaml,默认的doclayout_yolo_docstructbench_imgsz1280_2501.pt在 ROCm 环境下的表现明显不如基础版yolov10l_ft.pt——这就是那次 GPU 比 CPU 慢的根因。

修复操作:两步改完

重装 ROCm 渠道的 PyTorch

先彻底卸载,再从 rocm index 装回,装完确认 import 能报出 rocm 构建再继续:

pip uninstall torch torchvision torchaudio pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/rocm6.3

把默认 Layout 模型换成轻量版

模型替换提速这一步只动一处配置:在 MinerU 1.3.0 的模型配置目录(magic_pdf/resources/model_config/model_configs.yaml)里,将 layout 模型指向基础版的yolov10l_ft.pt,权重与配置文件保持同一版本。改完重跑,layout 阶段吞吐立刻回到正常量级,整条 pipeline 不再被这一站拖住。

优化前后的性能账单

整体吞吐对比(修复后,7900XTX + ROCm 6.3.4):

文档规模优化前优化后
小文档(14 页)14 页/秒15.42 页/秒
大文档(200 页)7 秒跑完,27.03 页/秒

分环节吞吐账单(同环境):

环节吞吐备注
Layout(模型替换后)27.03 页/秒换用 yolov10l_ft 后恢复
MFD 公式检测21.07 页/秒
MFR 公式识别83.57 页/秒
OCR 检测35.21 页/秒
表格结构建议 ONNX CPU6.8M 小模型上 GPU 反而更慢
OCR 识别291.43 页/秒 🚀全程最快环节

数据说明两件事:瓶颈从来不是某个环节,而是被一个跑慢的模型文件拖住整条链路;另外表格这种 6.8M 参数的小模型,GPU 调度开销比计算本身还大,交给 ONNX Runtime 的 CPU 路径反而更快。

ROCm 环境配置避坑清单

  1. 装 ROCm 版 PyTorch 前必须先卸载 CPU 版,叠装后旧构建可能仍被优先导入,症状和这次踩的一模一样。
  2. PyTorch 与 ROCm 大版本严格对齐,rocm6.3 wheel 配 6.3.4+ 运行时,别拿 6.2 的环境跑 6.3 的包。
  3. 下"GPU 不行"的结论前,先用 rocm-smi 确认利用率与显存搬运,一半的"硬件问题"最后都是环境问题。
  4. 不是所有模型都该上 GPU:6.8M 的表格模型在 GPU 上比 CPU 慢,小模型优先 ONNX CPU。
  5. 换模型时配置和权重要成对更新,只改配置不下载新权重,会在加载阶段直接报错。
  6. 跑通基准后把"ROCm + torch + MinerU + 模型文件"版本组合固化记录,否则下次升级失去回归基线。

下一步

把 MinerU、PyTorch、ROCm 升到当前官方发布的版本,并跟进各 release 中针对 AMD GPU 的 kernel 优化;再遇到吞吐回退,按"PyTorch 源 → 运行时版本 → 模型文件"这条动线复查一遍即可。

【免费下载链接】MinerUA high-quality tool for convert PDF to Markdown and JSON.一站式开源高质量数据提取工具,将PDF转换成Markdown和JSON格式。项目地址: https://gitcode.com/OpenDataLab/MinerU

创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/8/24 3:51:13

MultiHeadAttention原理与工程实践:从QKV计算到生产部署

1. 这不是“黑箱”,是工程师能亲手拧紧的齿轮MultiHeadAttention——这个词现在几乎成了AI工程师简历上的标配,但很多人把它当成一个必须背诵的术语,就像当年背三角函数公式一样,知道它重要,却说不清它到底在模型里干了…

作者头像 李华
网站建设 2026/8/24 3:51:01

多智能体协同与组合融合算法:破解大模型价值对齐难题

1. 项目概述:当大模型学会“开会”,价值对齐的难题如何破解? 最近在折腾大语言模型(LLMs)的应用落地时,我反复被一个问题困扰:单个模型能力再强,也总有力不从心的时候,尤…

作者头像 李华
网站建设 2026/8/24 3:49:01

281.常用代码块逻辑级数汇总

昨天看到大佬的新书《FPGA匠人手记》,随手买了一本,但书还没到,今天大佬又发了一篇新文章,关于逻辑级数的,虽然自己做FPGA已有一段时间,逻辑级数肯定在接触,但也是第一次这么认真的去了解这个概…

作者头像 李华
网站建设 2026/8/24 3:48:43

10-四层/七层代理实战:适配安卓工控设备长连接、心跳上报场景

10-四层/七层代理实战:适配安卓工控设备长连接、心跳上报场景 一、四层代理 vs 七层代理:OSI模型视角 网络分层这块,七层模型(OSI)大家应该都背过:物理层、数据链路层、网络层、传输层、会话层、表示层、应…

作者头像 李华
网站建设 2026/8/24 3:47:14

Python玫瑰花代码:从数学曲线到可调参数的工程化实现

1. 这不是“花里胡哨”的装饰代码,而是一次对数学美与编程控制力的双重验证你搜“python玫瑰花代码”,页面上铺天盖地是那种复制粘贴就能跑、但跑完只看到一朵静态红花、连花瓣数都调不了的“示例”。我写这篇,不是为了再给你塞一个“能动的爱…

作者头像 李华