PaddleOCR on Hygon Z100

1. Final conclusion

PaddleOCR 3.7.0 completed end-to-end functional verification on Kunshan Z100 through the Transformers/PyTorch backend. The deployment uses a user-space glibc 2.28 loader, GCC 12.2, DTK 26.04, and a Hygon-adapted Torch 2.7.1 build. It does not depend on a PaddlePaddle DCU wheel.

2. Test environment and software configuration

3. Inference backend selection

4. Compatibility verification

5. Performance results

5.1 Single-image steady state

23-page Mooncake-v3 PDF

6. Same-document comparison with MinerU

Both systems processed the same 23-page, approximately 0.58 MB file, Mooncake-v3.pdf. MinerU figures are taken from its corresponding build report; PaddleOCR was measured again on that PDF for this report.

7. Quality and accuracy limits

No character-level ground truth was prepared for this test, so character-count differences are not treated as accuracy measurements. PaddleOCR's mean confidence was 0.9636, yet spot checks of the same output still found errors such as:

Mooncacke
diversifi ed
work- loads
2O24

The MinerU report separately verifies heading hierarchy, author information, table values, formulas, and extracted images. For papers, contracts, forms, and PDF-to-Markdown workflows, structured output matters more; PaddleOCR is a better fit for batch plain-text recognition, targeted re-recognition, and low-latency OCR.

8. Deployment plan

8.1 Launcher

The system glibc 2.17 cannot load the newer Torch wheel directly. Production must run through the user-space glibc 2.28 loader, with GCC 12.2, DTK 26.04, dcc/gcvm, and rocm_smi in its runtime environment.

<PADDLEOCR_ROOT>/bin/dcu-python your_worker.py

Do not invoke the system python directly. Spawned child processes must not fall back to the unwrapped sys.executable; the environment's sitecustomize.py sets multiprocessing.set_executable().

8.2 Resident worker

• Each DCU starts a resident PaddleOCR worker.
• Load the model once and serve requests only after warm-up.
• Limit concurrent requests to each worker to avoid thread-safety issues and GPU-memory contention.
• Worker health checks should cover device enumeration, model loading, single-image inference, and process exit status.
• Pin models in the local cache and set offline variables in production so requests never trigger implicit downloads.

8.3 Production acceptance

torch.cuda.device_count() == 1
torch.cuda.get_device_properties(0).gcnArchName startswith("gfx906")
PADDLEOCR_TRANSFORMERS_E2E_OK
PADDLEOCR_EXIT_RC=0
summary.json exists and chars/lines > 0

9. Reproduction entry points

The report package includes the following files:

module purge
module load compiler/gcc/12.2.0 compiler/dtk/26.04
export PADDLE_PDX_CACHE_HOME=<PADDLEOCR_ROOT>/cache
export PADDLE_PDX_MODEL_SOURCE=BOS
export HF_HUB_OFFLINE=1 TRANSFORMERS_OFFLINE=1

<PADDLEOCR_ROOT>/bin/dcu-python \
  paddleocr_z100_benchmark.py \
  <INPUT_PDF> <OUTPUT_DIR>

10. Test results and acceptance

The public report omits account, host, node, and job identifiers, as well as real absolute paths and internal service addresses. Replace the placeholders in the local launcher and Slurm templates when reproducing the test.

11. Known limitations and follow-up suggestions