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而是回答一个问题当前进程里加载的到底是哪个 PyTorchROCm 环境配置里最常见的事故就是渠道混装——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 环境配置避坑清单装 ROCm 版 PyTorch 前必须先卸载 CPU 版叠装后旧构建可能仍被优先导入症状和这次踩的一模一样。PyTorch 与 ROCm 大版本严格对齐rocm6.3 wheel 配 6.3.4 运行时别拿 6.2 的环境跑 6.3 的包。下GPU 不行的结论前先用 rocm-smi 确认利用率与显存搬运一半的硬件问题最后都是环境问题。不是所有模型都该上 GPU6.8M 的表格模型在 GPU 上比 CPU 慢小模型优先 ONNX CPU。换模型时配置和权重要成对更新只改配置不下载新权重会在加载阶段直接报错。跑通基准后把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），仅供参考
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而是回答一个问题当前进程里加载的到底是哪个 PyTorchROCm 环境配置里最常见的事故就是渠道混装——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 环境配置避坑清单装 ROCm 版 PyTorch 前必须先卸载 CPU 版叠装后旧构建可能仍被优先导入症状和这次踩的一模一样。PyTorch 与 ROCm 大版本严格对齐rocm6.3 wheel 配 6.3.4 运行时别拿 6.2 的环境跑 6.3 的包。下GPU 不行的结论前先用 rocm-smi 确认利用率与显存搬运一半的硬件问题最后都是环境问题。不是所有模型都该上 GPU6.8M 的表格模型在 GPU 上比 CPU 慢小模型优先 ONNX CPU。换模型时配置和权重要成对更新只改配置不下载新权重会在加载阶段直接报错。跑通基准后把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），仅供参考
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
