Jittor: a JIT deep learning framework where meta-operators compile your model

What Jittor is for, and who it is not for

Jittor is a deep learning framework whose whole stack, including the operators, is compiled just-in-time. That is the claim the README opens with, and it is the design decision everything else follows from. The front end is Python with module design and dynamic graph execution, the same interface style most people already know. The back end is CUDA and C++.

The audience is narrower than the phrase deep learning framework suggests. If you want to write a convolution with meta-operators, or you need high-performance code specialised for your model, the framework is built for you. If you want to pip install a framework and immediately run someone else's published PyTorch repository, this is the wrong tool. Jittor ships its own model libraries covering image recognition, detection, segmentation, generation, differentiable rendering, geometric learning and reinforcement learning, and the repository carries two Awesome Jittor lists, which is a sign that the ecosystem is separate rather than compatible.

The other group it fits is people on hardware that is not an Nvidia GPU. The requirements table lists AMD ROCm >= 4.0 and Hygon DCU DTK >= 22.04 alongside CUDA >= 10.0, and the CPU row covers x86, x86_64, ARM and loongson. That breadth is unusual and it comes from the JIT compiler rather than from hand-written kernels per vendor.

Meta-operators and the JIT compiler: how a model becomes a kernel

The mechanism is a two-stage compile. Jittor defines meta-operators, and the op compiler plus tuner generate high-performance code specialised for your model. Because the framework itself is compiled just-in-time as well, there is no large prebuilt binary to match against your machine.

The practical consequence is that the first run of a model is not the run you measure. Compilation and tuning happen then, and the shape of your tensors is part of what gets compiled. Change the input shape and you change the compilation unit. That is the trade the framework makes: per-model specialisation instead of one generic kernel library.

You can see the shape of the front end in the README example. A Model subclasses Module, the forward pass is a method named execute, layers are declared in __init__, and the training loop calls optim.step(loss_mean) directly with the loss instead of the zero_grad, backward, step sequence many PyTorch users expect. Data is produced as jt.float32 tensors from numpy arrays. None of this is exotic, but the execute naming and the step-with-loss signature are the details that break a copy-pasted PyTorch training loop.

Installing Jittor and running the example test

The README offers three install paths: pip, Docker, or manual. The pip path on Linux starts with the system packages the build needs, then installs the wheel, then runs a test module that ships with the package.

sudo apt install python3.7-dev libomp-dev
python3.7 -m pip install jittor
python3.7 -m jittor.test.test_example

The README also shows installing from the repository as an alternative to the released wheel: python3.7 -m pip install git+https://github.com/Jittor/jittor.git. If the test passes, the README says your Jittor is ready. If it fails, you are in the manual-install territory below rather than the pip path.

On Windows the requirements shift: Python >= 3.8, and conda users are told to run conda install pywin32. Jittor is documented as detecting and installing CUDA automatically, provided the NVIDIA driver supports CUDA 10.2 or above. If it does not, the README gives an explicit installer:

python -m jittor_utils.install_cuda

If you would rather not configure a toolchain at all, the Docker images are the shortest route. Note that the CPU-only image is the one that works on Mac and Windows, and it is run with a port mapping rather than host networking:

docker run -it --network host jittor/jittor
docker run -it --network host --gpus all jittor/jittor-cuda
docker run -it -p 8888:8888 jittor/jittor

For CUDA on a manual install, two environment variables do the work. cc_path selects the C++ compiler, and nvcc_path points at the CUDA compiler. The README's example uses clang++-8 but notes g++ and icc as alternatives. After setting nvcc_path, the CUDA test is python3.7 -m jittor.test.test_cuda, and once it passes you enable the GPU in code with jt.flags.use_cuda = 1. The README also documents python3.7 -m jittor.test.test_resnet, which it says needs 6 GB of GPU RAM.

The install path fights you on Windows and macOS

setup.py is blunt about this. Its error message states that Jittor only supports Linux and macOS currently, that using it on other systems may be risky, and that installing anyway requires export FORCE_INSTALL=1. The same message pushes Docker as the recommended route and repeats the three image commands.

Read that together with the README's Windows section and you get a contradiction in emphasis, not in fact. Windows instructions exist and are specific, down to the CUDA 10.2 driver requirement and the pywin32 note for conda, while the packaging layer treats a non-Linux, non-Darwin system as a warning case. The honest reading is that Windows is supported through a path the maintainers consider second-class. If your team is on Windows, plan on Docker or plan on surprises.

There is a second, quieter constraint. The pip instructions and every test command in the README are written as python3.7, and setup.py enforces Python >= 3.7 on Linux and >= 3.8 on Windows, raising a RuntimeError otherwise. If your environment is pinned to a different interpreter, the commands need translating before they will run, and the manual-install steps assume a distribution where python3.7-dev is a package you can apt install. That is Ubuntu 16.04 in the README's walkthrough, and the bundled Dockerfile still starts from ubuntu:18.04 with the Tsinghua mirror.

Jittor compared with PyTorch: the difference is where compilation happens

The comparison people search for is Jittor versus PyTorch, and the README supports one concrete difference rather than a general verdict. In PyTorch the operator library is prebuilt and your model selects from it; eager execution runs those kernels as written. In Jittor the operators themselves are compiled just-in-time, and the README describes a powerful op compiler and tuner generating code specialised for your model. Specialisation is the product, not a side effect.

That changes what you can do with the framework. The README points to a notebook on implementing your own convolution with a meta-operator, which is a task that in a prebuilt-operator framework means writing a CUDA extension and building it against the installed version. Here it is part of the operator model.

It also changes what you inherit. PyTorch's advantage is not a kernel; it is the volume of code, pretrained weights and third-party packages written against its API. Jittor's answer to that is its own model libraries across recognition, detection, segmentation, generation, differentiable rendering, geometric learning and reinforcement learning, plus the two Awesome Jittor lists. If your work sits inside those areas, the gap is smaller than it looks. If it sits outside them, no amount of compiler quality closes it.

Maintenance, releases and what the licence leaves you to decide

The repository is not archived, and the last push was on 2026-09-10, so the codebase is receiving changes. Release cadence is a different question. The recent releases are 1.3.10.0 on 2025-07-28, 1.3.9.10 on 2024-07-02 and 1.3.9.9 on 2024-06-25. Between the two most recent releases there is a gap of roughly thirteen months, and the two before that landed a week apart. Treat tagged releases as occasional rather than frequent, and treat the master branch as where current work lives.

That matters for upgrade planning because Jittor compiles at runtime. A new release can change the generated code for a model that did not change. The README's test modules are the only verification procedure the project documents: jittor.test.test_example for a basic install, jittor.test.test_cuda for the GPU path, jittor.test.test_resnet for end-to-end training. Running those after an upgrade is the documented way to check that an environment still works, and the ResNet test is the one that tells you whether a 6 GB GPU budget is still enough.

Jittor is Apache-2.0, with the licence text in LICENSE.txt. That is a permissive licence with an explicit patent grant, and it is the same licence family as several other frameworks, so it is unlikely to be the deciding factor between Jittor and an alternative. What the licence does not settle is the dependency situation: the Dockerfile pins ubuntu:18.04 as the default build image, installs python3.7, and points pip at the Tsinghua mirror, which is a build configuration tuned for networks in China. If you build from that Dockerfile elsewhere, expect to change the mirror lines. This is a description of the file, not legal advice.

Editorial conclusion

Adopt Jittor if you write your own operators, work on non-Nvidia accelerators, or need to read and modify the compiler that generates your kernels, and start by running python3.7 -m jittor.test.test_example on the exact Python and CUDA combination you plan to ship. Do not adopt it if your team depends on the PyTorch operator set, third-party packages or pretrained weights, because Jittor's own model libraries are the substitute and there is no compatibility layer in the README. Verify first that your Python version satisfies the setup.py check (3.7 on Linux, 3.8 on Windows), that your GPU stack matches the CUDA 10.0, ROCm 4.0 or DTK 22.04 rows in the requirements table, and whether the 6 GB GPU memory that jittor.test.test_resnet needs is actually available to you.

Frequently asked questions

Official sources

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