monarch

Monarch

Monarch is a distributed programming framework for PyTorch based on scalable actor messaging. It provides:

1. Remote actors with scalable messaging: Actors are grouped into collections called meshes and messages can be broadcast to all members.
2. Fault tolerance through supervision trees: Actors and processes form a tree and failures propagate up the tree, providing good default error behavior and enabling fine-grained fault recovery.
3. Point-to-point RDMA transfers: cheap registration of any GPU or CPU memory in a process, with the one-sided transfers based on libibverbs
4. Distributed tensors: actors can work with tensor objects sharded across processes

Monarch code imperatively describes how to create processes and actors using a simple python API:

from monarch.actor import Actor, endpoint, this_host

# spawn 8 trainer processes one for each gpu
training_procs = this_host().spawn_procs({"gpus": 8})

# define the actor to run on each process
class Trainer(Actor):
    @endpoint
    def train(self, step: int): ...

# create the trainers
trainers = training_procs.spawn("trainers", Trainer)

# tell all the trainers to take a step
fut = trainers.train.call(step=0)

# wait for all trainers to complete
fut.get()

The introduction to monarch concepts provides an introduction to using these features.

Documentation

View Monarch's hosted documentation at this link.

Installation

Installing from Pre-built Wheels

Monarch provides pre-built wheels that work regardless of what version of PyTorch you have installed. You can get these with pip or uv:

• Using PIP:
  • stable: pip install torchmonarch
  • nightly: pip install --pre torchmonarch
  • specific: pip install torchmonarch==v0.7.0.dev20260713
• Using UV - note, you can also just use uv pip install ... and match the above pip commands; but the ones below add monarch to your UV project properly.
  • stable: uv add torchmonarch
  • nightly: uv add --prerelease=allow torchmonarch
  • specific: uv add torchmonarch==v0.7.0.dev20260713

Build and Install from Source

Note: Building from source requires additional system dependencies. These are needed at build time only, not at runtime.

Monarch uses uv for fast, reliable Python package management. If you don't have uv installed:

# Install uv
curl -LsSf https://astral.sh/uv/install.sh | sh
# Or on macOS
brew install uv

Configuring PyTorch Index: By default, Monarch builds with PyTorch from the pytorch-cu132 index (CUDA 13.2). To use a different CUDA version:

• Edit [tool.uv.sources] in pyproject.toml to point to a different index (e.g., pytorch-cu130, or pytorch-cpu)
• Or use --extra-index-url when running uv:
  bash复制

  uv sync --extra-index-url https://download.pytorch.org/whl/cu130

Understanding Tensor Engine

Monarch includes distributed tensor and RDMA APIs. The tensor engine builds on any platform, including CPU-only hosts and macOS; GPU-specific pieces (NCCL, RDMA, rdmaxcel) layer on top and only build on Linux with a CUDA or ROCm toolchain installed. If you want a lighter-weight version of Monarch (actors only, no torch dependency), set USE_TENSOR_ENGINE=0.

By default, Monarch builds with tensor_engine enabled. To build without it:

USE_TENSOR_ENGINE=0 uv sync

Note: Building without tensor_engine means you won't have access to the distributed tensor or RDMA APIs. Torch is required to use tensor_engine, and the latest stable torch is ABI compatible with the latest versioned torchmonarch

Selecting a GPU platform: The MONARCH_GPU_PLATFORM environment variable controls which GPU libraries the build links against. It accepts:

• cuda — build against CUDA (NCCL + RDMA).
• rocm — build against ROCm.
• none — force a CPU-only tensor engine even on a host where CUDA or ROCm is installed.

Leaving it unset auto-detects whichever toolchain is present. Setting it explicitly is required when both CUDA and ROCm are installed, and none is the explicit opt-out when you want the CPU tensor engine on a GPU-capable host.

# Force a CPU-only tensor engine (no CUDA/ROCm/RDMA libraries required)
MONARCH_GPU_PLATFORM=none uv sync

# Force CUDA on a host that also has ROCm
MONARCH_GPU_PLATFORM=cuda uv sync

Build Dependencies by Platform

On Fedora distributions

…

On Ubuntu distributions

…

On non-CUDA machines

You can also build Monarch on non-CUDA machines (e.g., macOS laptops) for CPU-only usage. The tensor engine itself works on CPU; only the GPU-specific bits (NCCL, RDMA, rdmaxcel) are skipped. Auto-detection handles hosts with no CUDA or ROCm installed. If your host does have a GPU toolchain installed but you want the CPU tensor engine anyway, set MONARCH_GPU_PLATFORM=none.

# Install nightly rust toolchain
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
rustup toolchain install nightly
rustup default nightly

# Clone and sync dependencies
git clone https://github.com/meta-pytorch/monarch.git
cd monarch

# Build the CPU tensor engine (auto-detects no GPU)
uv sync

# Or, to skip the tensor engine entirely (actors only, no torch required)
USE_TENSOR_ENGINE=0 uv sync

# Verify installation
uv run python -c "from monarch import actor; print('Monarch installed successfully')"

Alternative: Using pip

If you prefer to use pip instead of uv:

# After installing system dependencies (see above)

# Install build dependencies

# Build and install Monarch
pip install .

# Or for development
pip install -e .

# Without tensor_engine
USE_TENSOR_ENGINE=0 pip install -e .

Building a Docker Image from Source

To build a Docker image that bundles your from-source build of Monarch — for example, to run Monarch on a Kubernetes cluster — first build a wheel, then build the image from that wheel. This picks up changes to both the Rust and Python code.

…

Then point your deployment at the new image. Make sure to prepend the registry you used for docker login, like ghcr.io or docker.io, and that you have pushed the image first.

Running examples

Check out the examples/ directory for demonstrations of how to use Monarch's APIs.

We'll be adding more examples as we stabilize and polish functionality!

Running tests

We have both Rust and Python unit tests. Rust tests are run with cargo-nextest and Python tests are run with pytest.

Rust tests

Important: Monarch's Rust code uses PyO3 to interface with Python, which means the Rust binaries need to link against Python libraries. Before running Rust tests, you need to have a Python environment activated (conda, venv, or uv):

# If using uv (recommended)
uv sync  # This creates and activates a virtual environment
uv run cargo nextest run  # Run tests within the uv environment

# Or if using conda
conda activate monarchenv
cargo nextest run

# Or if using venv
source .venv/bin/activate
cargo nextest run

Without an active Python environment, you'll get Python linking errors like:

error: could not find native static library `python3.12`, perhaps an -L flag is missing?

Installing cargo-nextest:

# We use cargo-nextest to run our tests, as they provide strong process isolation
# between every test.
# Here we install it from source, but you can instead use a pre-built binary described
# here: https://nexte.st/docs/installation/pre-built-binaries/
cargo install cargo-nextest --locked

cargo-nextest supports all of the filtering flags of "cargo test".

Python tests

# Install test dependencies (if not already installed via uv sync)
uv sync --extra test

# Run unit tests with uv
uv run pytest python/tests/ -v -m "not oss_skip"

# Or if using pip
pip install -e '.[test]'
pytest python/tests/ -v -m "not oss_skip"

Disabling flaky CI tests

If a test is consistently failing in OSS CI and needs to be temporarily disabled without a code change, open a GitHub issue on this repo with a title of the form:

DISABLED 

At the start of each CI run, scripts/fetch_disabled_tests.py fetches all open issues whose titles start with DISABLED and skips the named tests. Closing the issue re-enables the test on the next run.

Naming format:

• Rust (cargo nextest): use the test name exactly as it appears in nextest output: , e.g. DISABLED hyperactor proc::tests::test_child_lifecycle
• Python (pytest): use a test function name, full node ID, or structural node-ID prefix. For example, DISABLED test_my_function skips that function (including all parameterizations), while DISABLED python/tests/test_example.py skips the entire file.

Overriding skips locally

To run a test that is currently disabled via a GitHub issue, you can override the fetched skip lists by creating the files before running scripts/fetch_disabled_tests.py. The script will not overwrite files that already exist:

• disabled_tests.txt — controls which Python tests are skipped. Create this file with only the tests you want to skip (or leave it empty to skip none).
• .config/nextest-filter.txt — controls which Rust tests are skipped. Write a nextest filter expression here (e.g. all() to run all tests, or not (test(some_test)) to skip only specific ones).

For example, to run all tests locally regardless of open issues:

echo -n "" > disabled_tests.txt
echo "all()" > .config/nextest-filter.txt
uv run python scripts/fetch_disabled_tests.py   # will skip both writes
uv run pytest python/tests/ -v -m "not oss_skip"

License

Monarch is BSD-3 licensed, as found in the LICENSE file.