PP-StructureV3 on CPU is very slow for large PDFs with text layer + embedded images. What is the intended production path?

[MalekAchich]

Search before asking

• I searched the PaddleOCR docs
• I searched existing issues
• I searched discussions

Goal

I am building an industrial incident-analysis agent.

A single ticket can include a large PDF manual, for example:

• 699 pages
• strong embedded text layer
• also contains embedded images/figures/screenshots on some pages

The requirement is:

• read the full PDF text
• also understand the visual content inside the PDF
• persist derived evidence for later reruns/refinements

I am trying to understand the intended production usage of PP- StructureV3 for this kind of document.

---

Environment

• OS: Ubuntu Linux
• Python: 3.12
• Installed via pip in a venv
• CPU inference only
• No GPU in this runtime path
• PaddleOCR 3.x / PP-StructureV3
• Large PDF manual: 699 pages, ~18 MB

---

What I tested

I currently render PDF pages to PNG and run PP-StructureV3 page-
by-page.

Example configuration:

pipeline = PPStructureV3(
    use_doc_orientation_classify=False,
    use_doc_unwarping=False,
    use_textline_orientation=False,
    use_seal_recognition=False,
    use_table_recognition=False,
    use_formula_recognition=False,
    use_chart_recognition=False,
    use_region_detection=True,
    format_block_content=True,
    enable_mkldnn=False,
    cpu_threads=4,
)

I also reduced render resolution and OCR limits.

———

### What I observed

#### 1. Extremely slow runtime on CPU

Even after disabling table/formula/chart recognition and processing
page-by-page, the runtime is still far too slow for a large manual.

It is not practical for a 699-page PDF.

#### 2. Heavy model stack at initialization

PP-StructureV3 loads a large stack of submodels, including layout +
OCR + region-related models.

#### 3. CPU memory concerns

I also saw high memory pressure during testing.

Earlier I also hit errors like:

NotImplementedError: (Unimplemented)
ConvertPirAttribute2RuntimeAttribute not support
[pir::ArrayAttribute<pir::DoubleAttribute>]

inside Paddle inference / oneDNN path.

I also noticed related issues in the repo about CPU memory growth /
memory leak and PP-StructureV3 resource usage.

———

### Important detail about the PDF itself

This PDF already has a strong text layer.

### Questions

1. Is PP-StructureV3 intended to be run on every page of a very
   large PDF on CPU, even when the PDF already has a text layer?
2. For production, is the recommended path instead:
    - extract text from the PDF text layer first
    - detect pages/regions with real visual content
    - run PP-StructureV3 only on those pages/regions?
3. Is there a lighter / recommended configuration for large text-
   layer PDFs where I mainly need:
    - page structure
    - image/figure region detection
    - OCR only where necessary
4. Are the CPU memory-growth / slowness issues known for this use
   case in PaddleOCR 3.x / PP-StructureV3?
5. If the correct solution is not PP-StructureV3 for all pages,
   what PaddleOCR component is the intended one for:
    - large PDF triage
    - identifying visual pages
    - then parsing only those pages deeply

———

### What I need to achieve

I do not want to skip PDF visuals.

I need a production-feasible way to:

- read the full manual text
- detect and understand visual pages/regions
- keep runtime reasonable on CPU
- persist the parsed evidence for later reuse

Any guidance on the intended architecture would be very helpful.