PERSIA is a hybrid recommendation trainer the README calls unmaintained

A not-maintained warning sits above a last push from four days ago

The first line of the README is a warning in capitals: this project is currently not maintained, due to company reorganization. Nothing later in the document softens it or dates it.

Set against that, the repository metadata shows a last push on 2026-09-28 and an unarchived repository under an MIT licence in the root LICENSE file. There are no GitHub releases, so there is no version series and nothing to pin a dependency to.

Those two facts are not contradictory but they are not the same thing. A recent commit date tells you the tree is not abandoned as a file, while the warning tells you nobody is answering issues or merging outside contributions. Plan on reading code from here, not on filing a ticket.

Three environment variables decide what gets compiled at install time

The build is a Python package that compiles Rust. setup.py reads three environment variables before it does anything: USE_CUDA, defaulting to 0, USE_K8S, defaulting to 1, and NATIVE, defaulting to 0.

Each one changes the artifact list. USE_CUDA decides whether the persia_core extension is built with the cuda feature. USE_K8S adds a further set of extensions, including gencrd from persia.gencrd and operator from persia.operator. NATIVE is passed straight through to setuptools-rust.

Two RustExtension blocks are always present. One is built from rust/persia-embedding-server/Cargo.toml with Binding.Exec and produces two executables, persia-embedding-worker and persia-embedding-parameter-server. The other is built from rust/persia-core/Cargo.toml with Binding.PyO3 and produces persia_core. A console script, persia-launcher, points at persia.launcher:cli.

The pinned toolchain is CUDA 11.2, Python 3.8 and PyTorch 1.8

The container is not built against current releases. The Dockerfile takes a base image argument defaulting to nvidia/cuda:11.2.0-devel-ubuntu20.04, a Python version argument of 3.8 and a PyTorch version argument of 1.8, with a MAGMA_CUDA_VERSION of magma-cuda110.

Miniconda is installed into /opt/conda, and the environment gets numpy, scipy, mkl, ninja, cython and typing from conda, then mpi4py from conda-forge. The CUDA branch adds magma-cuda110 with pytorch 1.8 and torchvision from the pytorch and conda-forge channels, followed by pip3 install bagua-cuda113. The CPU branch takes pytorch with torchvision cpuonly and scikit-learn instead. Both branches end by installing torchserve, torch-model-archiver and torch-workflow-archiver.

Read those three version numbers as the compatibility floor for anything you build next to it.

The build target is a torchserve stack on a runtime image, not a wheel

The Makefile builds three images rather than a distributable package. build_ci_image targets a stage called builder with DEVICE=cuda. build_cuda_runtime_image targets runtime with the same device. build_cpu_runtime_image targets runtime with DEVICE=cpu and a different base image:

build_cpu_runtime_image:
	DOCKER_BUILDKIT=1 docker build --build-arg DEVICE=cpu --build-arg BASE_IMAGE="ubuntu:20.04" \
	-t persia-cpu-runtime:$(IMAGE_TAG) --target runtime .

The torchserve trio in the image, together with torch-model-archiver and torch-workflow-archiver, is the clue about the intended deployment shape: models are packaged and served rather than imported into a notebook.

There is also a plain development install:

build_dev_pip:
	USE_CUDA=1 pip3 install -e . --prefix=~/.local/

One trap is worth flagging before you trust a tag. build_dev_image forwards IMAGE_TAG=dev to make, but the file assigns IMAGE_TAG with := rather than ?=, and a makefile assignment outranks an environment variable, so the dev image comes out tagged test.

The version number is generated into persia/version.py at build time

Versioning is handled by setuptools_scm rather than by a hardcoded string. pyproject.toml requires setuptools-scm 6.0 or newer, sets local_scheme to no-local-version, and points write_to at persia/version.py with a template that emits a single __version__ assignment.

The build backend is setuptools.build_meta, and the build requirements pull in setuptools-rust, colorama and tqdm alongside setuptools 43 and wheel. Formatting is configured in the same file with black at a line length of 88, targeting py37 and py38.

Because the version is derived from git rather than declared, an installed copy from a dirty checkout will not carry a meaningful version string, which is one more reason to treat a build from this tree as something you pin by commit.

The English documentation is described in the README as raw and unfinished

There is a disclaimer before the news section, and it is unusually candid. The program is described as usable and as having served several important businesses, while the official English documentation and tutorials are said to be under heavy construction and a bit raw, with readers invited to try it and contribute.

The links back that up. The API documentation at persiaml.pages.dev is marked under construction. The tutorials live on a separate site, persiaml-tutorials.pages.dev. Distribution is pointed at by badges rather than prose, one for the persia package on PyPI and one for the persiaml Docker Hub user.

For a system this size that gap matters, since the paper covers the design and the code covers the mechanics, and the layer in between is where you would normally find how to actually run it.

The 100 trillion parameter claim comes from a 2021 paper and a talk

The headline number has two sources in the repository and neither is a benchmark you can rerun. The first reference is the 2021 paper Persia: A Hybrid System Scaling Deep Learning Based Recommenders up to 100 Trillion Parameters, published on arXiv as 2111.05897. The second is Distributed Learning Systems with First-order Methods, arXiv 2104.05245, by the same group.

The README claims capability up to 100 trillion parameters, calls that the largest model size in recommendation systems to the best of the authors' knowledge, and says empirical study on public datasets showed a significant advantage over several other existing training systems. It also states that efficiency and robustness were validated by applications with 100 million level daily active users at Kuaishou, and the news section links a 2021 Facebook invited talk on the same theme.

Note the provenance: a company that employs the authors, and a conference talk. Neither is independent verification, and the numbers are five years old.

The layout splits Python, Rust, Kubernetes manifests and tests into five directories

The top level is small enough to read in one pass: .buildkite/, .github/, .gitignore, .gitmodules, CITATION.cff, Dockerfile, LICENSE, Makefile, README.md, docs/, examples/, k8s/, persia/, pyproject.toml, resources/, rust/, setup.cfg, setup.py and test/.

persia/ is the Python package and the target of the three lint commands in the Makefile, pytype, flake8 and black. rust/ holds two Cargo projects, persia-core and persia-embedding-server, which is why setup.py reaches into two separate Cargo.toml files. k8s/ carries the deployment side to match the operator and gencrd extensions. examples/ has its own README and a src/ directory. docs/, resources/ and test/ fill out the rest, and .gitmodules means at least one dependency arrives as a submodule rather than a package.

A git submodule in a tree with no releases is the detail most likely to complicate a fresh clone.

Editorial conclusion

Read PERSIA as a reference implementation rather than as infrastructure you can adopt this year. The design is worth studying, since the Rust embedding server, the PyO3 core and the operator and gencrd entry points are a working answer to a specific scale problem, but the repository states plainly that it is not maintained because of a company reorganization, the English docs are described as raw and under construction, and there are no tagged releases to pin. If you do intend to build on it, verify three things first: that the CUDA 11.2, Python 3.8 and PyTorch 1.8 baseline in the image is compatible with your cluster, that the 2021 paper's claims still describe the code as it stands, and that you are willing to own the fork, since the last push was 2026-09-28 and that appears to be archival rather than ongoing.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. PersiaML/PERSIA on GitHub
4. README