pytorch-cpp: The PyTorch Tutorials, Rewritten in C++ with LibTorch

What pytorch-cpp actually is, and who it is written for

This is not a library. There is no installable package, no header to include, no link target to add to your own build. It is a repository of thirteen standalone C++ programs that reimplement the models from yunjey's Python pytorch-tutorial against LibTorch, plus a 60 Minute Blitz port and one interactive notebook. The README frames the audience narrowly: deep learning researchers who want to learn PyTorch in C++, with the Python tutorial named as the counterpart.

That framing matters because the code is teaching material first. Each tutorial lives in its own folder under tutorials/ with a main.cpp entry point, and the basics, intermediate and advanced categories map onto the Python original. If you are looking for a C++ inference wrapper to drop into a production service, this repository will not give you one. If you are a Python PyTorch user who wants to know what torch::Tensor, autograd and the module API look like on the C++ side, the mapping is the whole point.

How the CMake build downloads LibTorch and datasets

The mechanism is a configure-time fetch driven by CMake options. When you run the configure step, the build system downloads a LibTorch distribution matching the version you asked for, unless you point CMAKE_PREFIX_PATH at a local copy. The CUDA_V option selects the variant: 11.8, 12.4, 12.6, 12.8, 12.9, 13.0, 13.2, or none for the CPU build. The default is none, so a bare configure gets you CPU LibTorch.

Data arrives the same way. With DOWNLOAD_DATASETS set to ON, which is the default, the datasets required by whichever tutorials you build are fetched into pytorch-cpp/data, and only if they are not already present. Scriptmodule files for prelearned models and weights are a separate switch, CREATE_SCRIPTMODULES, defaulting to OFF, and turning it on requires an installed python3 with pytorch and torchvision, because the files are generated rather than downloaded.

The design has a consequence worth stating plainly. Two build options reach outside the C++ toolchain: one downloads binaries from the network at configure time, the other shells out to Python. Neither is unusual for a tutorial repository, but both mean the build is not hermetic, and a machine without network access or without a matching Python environment will need the options set differently.

Installing pytorch-cpp and running your first tutorial

The README lists four requirements: a C++-17 compatible compiler, CMake with a minimum version of 3.28.6, LibTorch between 1.12.0 and 2.14.0, and Conda. Conda is listed for the interactive notebooks rather than the compiled tutorials, so a plain local build does not obviously need it.

Start by cloning the repository and configuring the build. This command fetches the CPU build of LibTorch and downloads the datasets the tutorials need:

cmake -B build

On Windows you must also select a 64-bit generator, since LibTorch only supports 64-bit Windows. For Visual Studio the README appends the architecture flag:

cmake -B build -A x64

If you want the CUDA build instead, set CUDA_V to one of the supported versions, for example:

cmake -B build -D CUDA_V=11.8

To use your own LibTorch instead of downloading one, point CMAKE_PREFIX_PATH at the CMake package directory. The README's Linux example combines that with scriptmodule creation:

cmake -B build \
-D CMAKE_BUILD_TYPE=Release \
-D CMAKE_PREFIX_PATH=/path/to/libtorch/share/cmake/Torch \
-D CREATE_SCRIPTMODULES=ON

Then build. The README notes that the CMake script downloads the Release version of LibTorch, so Windows users on Visual Studio have to append the config flag:

cmake --build build

After that, the tutorial binaries are what you run. The README also documents building only one category, basics, intermediate, advanced or popular, rather than the whole tree, which is the sensible path if you only care about one model family.

The interactive notebooks run on a nightly LibTorch

This is the clearest limitation in the documentation, and the README states it without hedging: the interactive tutorials currently run on the LibTorch nightly version, and some tutorials can break when working with nightly. The setup is Conda-based, creating an environment and installing xeus-cling and notebook from conda-forge.

conda create --name pytorch-cpp
conda activate pytorch-cpp
conda install xeus-cling notebook -c conda-forge

The version policy is the problem. The compiled tutorials pin LibTorch between 1.12.0 and 2.14.0, and the badge in the README advertises 2.14.0. The notebook path tracks nightly instead, so the two halves of the repository are not tested against the same build. If you want a reproducible C++ notebook environment for a class or a workshop, that divergence is a real risk, and the README does not document a supported way to pin the notebook kernel to a release build. The single notebook, tensor_slicing.ipynb, is also the only interactive content, so the interactive path is thin relative to the compiled one.

Where pytorch-cpp is the wrong tool

Anyone who wants to link PyTorch into an existing C++ application should look past this repository. There is no installed artifact, no exported CMake target for downstream projects, and no stable API surface promised across releases. The version tags track PyTorch versions rather than the repository's own interface, which is a reasonable choice for tutorials and a poor one for a dependency.

A second mismatch is the dataset-downloading default. DOWNLOAD_DATASETS is ON, so a fresh configure pulls data into pytorch-cpp/data. In a sandboxed CI runner or an offline machine, that default has to be turned off explicitly, and the README does not describe what happens to the tutorials that need the missing data. The same applies to the Docker path: the Dockerfile builds on ubuntu:18.04 with Python 3.8 and installs pytorch 2.14.0 and torchvision 0.29.0 from the pytorch channel with cpuonly, so the container is a CPU-only environment by construction. The compose file mounts the repository into the container, which is convenient for editing and means the build output lands on the host.

How this compares with the Python pytorch-tutorial and the C++ frontend docs

The obvious alternative is the repository this one mirrors: yunjey's pytorch-tutorial. The difference is not the models, which are the same set, but the API being taught. The Python original shows you idiomatic PyTorch as most people write it, with dynamic typing and the full ecosystem of Python tooling around it. pytorch-cpp shows the same architectures through the C++ frontend, where tensors are torch::Tensor, the module API is used through C++ classes, and the build is a CMake project rather than a script. If your goal is to ship a model into a C++ program, the C++ version is the relevant one. If your goal is to understand the models, the Python version is faster to iterate on.

The other reference point is the official LibTorch C++ API documentation, which the README links as the install source. That documentation is the authority on the API itself; pytorch-cpp is a worked example set built on top of it. Neither replaces the other, and the README treats the docs as the place to get LibTorch rather than duplicating install instructions for every platform.

Maintenance, versioning and the MIT licence

The repository is not archived, and the last push was on 2026-09-13, the same day as the v2.14.0 release, which is tagged as PyTorch 2.14.0. Earlier releases in the list are v2.8.0 and v2.6.0, both dated 2025-08-25. The release naming makes the upgrade story legible: a new tag appears when the project moves to a new PyTorch version, so the cost of upgrading is the cost of adapting to LibTorch API changes between those versions. The README's supported range, 1.12.0 through 2.14.0, is wide, but the CI matrix only covers the current version, with macOS on clang 16, Linux on gcc 14 and 16, and Windows on msvc 2025.

The licence is MIT, which is permissive and imposes no source-disclosure obligation on code you write yourself. That matters here because the repository is teaching material you are expected to copy from. The MIT terms do require the copyright notice and permission notice to be included in copies or substantial portions of the software. This is a description of the licence text, not legal advice; if you are redistributing the tutorial code inside a product, read LICENSE and AUTHORS yourself.

Editorial conclusion

Adopt pytorch-cpp if you already write PyTorch in Python and need to see the same models expressed against the LibTorch C++ API, or if you want a working CMake setup that downloads LibTorch and datasets for you. Skip it if you want a stable interactive notebook environment, since the README states those run on the LibTorch nightly build and that some tutorials can break there, or if you need a library to link against rather than code to read. Before committing, verify that your compiler and CMake versions clear the stated minimums, that your LibTorch version sits between 1.12.0 and 2.14.0, and whether you want CREATE_SCRIPTMODULES on, which pulls in a python3 install with pytorch and torchvision.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. prabhuomkar/pytorch-cpp on GitHub
4. README
5. Releases