PaddleX: 33 model pipelines, one dependency list, and hardware limits you have to check

Pipelines bundle single-function modules into 33 named flows

The unit of work in PaddleX is called a pipeline, and the project defines it as a predefined development flow for a specific AI task that contains a combination of single models able to finish that task on their own. The counting works at two levels. The feature list claims 200 or more Paddle models reorganized into 33 pipelines, plus 39 single-function modules available for developers who want to assemble things themselves. Pipeline coverage spans text and image intelligent analysis, OCR, object detection, and time series prediction. The repository layout matches that split: the paddlex/ directory holds the implementation, api_examples/ holds runnable examples, deploy/ holds deployment assets, docs/ holds the documentation set that mkdocs.yml builds, and tests/ holds the checks. The top level also carries install_pdx.py and main.py, so installation and the entry point are separate scripts at the root.

Static graph weights renamed from xxx.pdmodel to xxx.json

Version 3.0 changed where a trained model lands on disk. Adaptation to PaddlePaddle 3.0 brought the intermediate representation technology, PIR, and with it a file naming change: a static graph model file moved from xxx.pdmodel to xxx.json. Anyone holding checkpoints from the 2.x line, or scripts that glob for the old extension, has to be checked against this. The same release also added full support for the ONNX format through the Paddle2ONNX plugin, so a conversion path exists in the other direction. Multi-model combination was promoted in the same release, letting a task be assembled from several models rather than one, and deployment moved to a unified command that handles multi-card inference and multi-card multi-instance serving. These are the kinds of changes that make an upgrade a porting job rather than a version bump.

Compiler training stays off until Global.dy2st is appended

Compiler based training is not the default. The training command has to have one option appended to turn it on:

-o Global.dy2st=True

The claimed effect is scoped by hardware. On GPU, the README states training speed improves by more than 10 percent for most models and by more than 30 percent for a smaller number of models. No figure is given for CPU or for any vendor accelerator, so the gain is not something to plan around outside the case it was measured for. This option belongs to the training side only. Inference adaptation for 3.0 is described separately as work done through the intermediate representation, and version 3.2.0 later reported full support for PaddlePaddle framework versions 3.1.0 and 3.1.1, which means the framework version you must line up with is a moving target of its own.

On-device deployment is still marked in progress for document pipelines

The capability table is a grid of pipelines against deployment modes, and the marks are not uniform. General OCR carries a check for online experience, fast inference, high performance inference, serving deployment, on-device deployment, secondary development, and the AI Studio zero-code pipeline. General object detection is the same. Document scene information extraction v3 and v4, and general table recognition, carry a check everywhere except on-device deployment, where the table shows a construction marker instead. So the row that says these three pipelines can be fine-tuned and served does not say they can run on a device. The table draws this distinction with single characters, which is easy to skim past when you are reading the feature list above it.

Hand-built HTTP requests open serving to any client language

Serving has two documented entry paths, and the second one is the interesting one. From version 3.2.0 the high stability serving deployment scheme was fully open sourced, with support for customizing the Docker image and the SDK according to need. The same release added the ability to call that scheme by manually constructing HTTP requests, and the stated effect is that client code can then be written in any programming language. That frees the calling side from any one language. Version 3.2.0 also gave high performance inference support for CUDA 12, with Paddle Inference and ONNX Runtime available as backends, so backend choice is part of the deployment decision rather than a fixed detail.

The installer pins decord off macOS and modelscope below 1.29.2 on Python 3.8

The packaging metadata is where the honest limits live. The build requires a modern setuptools plus setuptools_scm, and the version comes from tags on the release branch rather than a hardcoded string:

[build-system]
requires = ["setuptools>=64", "wheel", "setuptools_scm>=8"]
build-backend = "setuptools.build_meta"

[tool.setuptools_scm]
version_scheme = "release-branch-semver"
local_scheme = "node-and-date"
tag_regex = "^v(?P<version>\\d+\\.\\d+\\.\\d+(?:\\.dev\\d+)?)$"
fallback_version = "0.0.0"

The default branch is release/3.7 and the fallback version is 0.0.0, so a checkout with no reachable tag reports a meaningless version. The base dependency table in setup.py carries the sharper constraints:

BASE_DEP_SPECS = {
    "aiohttp": ">= 3.9",
    "aistudio-sdk": ">=0.3.5",
    "bce-python-sdk": ">= 0.9",
    "decord": "== 0.6.0; (platform_machine == 'x86_64' or platform_machine == 'AMD64') and sys_platform != 'darwin'",
    "GPUtil": ">= 1.4",
    "langchain": ">= 0.2, < 1.0",
    "langchain-openai": ">= 0.1, < 1.0",
}

Read that decord line carefully: it installs only on x86_64 or AMD64 machines and is excluded on darwin, so a video decoding dependency is simply absent on Apple hardware. The modelscope entry carries a comment explaining its own ceiling: versions from 1.29.2 onward import zoneinfo unconditionally, which is Python 3.9 and later standard library, so on Python 3.8 the pin is held below 1.29.2 even though 1.29.0 and 1.29.1 import cleanly.

Vendor coverage is counted in aggregate, not per model

The hardware claims are totals, and the totals have different shapes per vendor. NVIDIA, Intel, Apple M series, Kunlunxin, Ascend, Cambricon, Hygon, and Enflame are all listed as supported for training and inference. Then the numbers narrow it. On Ascend, 200 models are described as fully adapted and 21 as supporting OM high performance inference, with PP-OCRv5 and PP-StructureV3 called out as important supported solutions. On Kunlunxin the claim is narrower still: important classification, detection, and OCR models including PP-OCRv5. So the headline vendor list and the per-vendor model counts describe different things, and a count of 200 on one chip does not tell you whether the pipeline you want is among them. The per-model detail is delegated to a model list page hosted on the documentation site rather than kept in the repository file.

Accuracy gains arrive without the evaluation sets behind them

Several figures in the file are stated without the conditions needed to judge them. The PP-OCRv5 English model is said to improve 11 percent over the main PP-OCRv5 model in English scenarios, and the Thai and Greek recognition models are given accuracies of 82.68 percent and 89.28 percent with no dataset named. The multilingual text recognition addition covering 37 languages reports an average accuracy gain above 30 percent without a per language breakdown. One figure does carry its condition: the PP-Chart2Table upgrade inside PP-StructureV3 reports RMS-F1 moving from 71.24 to 80.60 percent, a 9.36 point rise, measured on an internally built evaluation set. PP-StructureV3 is described as reaching a state of the art level on the OmniDocBench leaderboard without a number attached, and PP-ChatOCRv4 reports key information extraction accuracy 15.7 points above the previous generation. Fine-grained per pipeline benchmark data exists and covers end to end inference time plus per layer and per module timing, but those numbers live in the documentation, not in this file.

Editorial conclusion

Use PaddleX when you want a PaddlePaddle based pipeline with several pretrained models already wired together, and when you can accept the platform constraints written into its packaging files. Do not adopt it expecting every pipeline to deploy on device or to run on every vendor chip, since the capability table marks several document pipelines as still in progress and the vendor notes count models in aggregate. Before committing, check three things yourself: whether your operating system is excluded by a dependency pin, whether the specific pipeline you need has the deployment mode you require, and whether the accuracy figures quoted for a model come with an evaluation set you can reproduce.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. PaddlePaddle/PaddleX on GitHub
3. Project website
4. README
5. Releases