gpulayer 0.7.0

Train PyTorch on every GPU you can reach.
One Trainer, from your laptop to many machines, faster than Lightning.
Install · Quickstart · Performance · Why GPUlayer · AI agents · Architecture · Docs · Examples · Changelog

GPUlayer trains PyTorch models with one Trainer that runs the same script in your process, on several GPUs of one machine, or across many machines: your laptop, workstations, servers, clusters and cloud VMs. It picks machines and GPUs that can run the job, keeps a distributed group on the best-connected GPUs and in one zone, starts every process, and brings back logs, checkpoints and metrics. Against PyTorch Lightning, with the same model, data and optimizer, it was faster in 10 of 11 GPU benchmarks (NVIDIA and Apple) and in every CPU benchmark.

NVIDIA CUDA, Apple Metal (MPS) and CPU are validated; AMD ROCm is implemented and awaiting validation on AMD hardware. Under the Trainer is a general job engine, so commands and Python functions in any language or library run the same way. Documentation: gpulayer.dev/docs.

v0.7.0. Tested on CPU, Apple Silicon (PyTorch MPS and MLX) and an NVIDIA Tesla T4, on machines with several GPUs (4× RTX 3070, 2× A100 with NVLink: NCCL across all GPUs of a machine), and on up to 30 machines on Google Cloud. NCCL across machines is implemented but not validated yet; cloud provisioning covers Google Cloud. See Status and roadmap.

Install

pip install gpulayer

That's it. Check what this machine can run:

gpulayer resources detect

To train with PyTorch, install it too: pip install "gpulayer[torch]".

Quickstart

import gpulayer.pytorch as glt

trainer = glt.Trainer(max_epochs=5, accelerator="cuda", devices=4, num_nodes=2)
trainer.fit(model, train_loader)          # 2 machines x 4 GPUs, DDP over NCCL

# The same script in this process, as 2-process DDP, or on 2 nodes: only the flags change
python examples/trainer_regression/train.py
python examples/trainer_regression/train.py --accelerator cpu --devices 2
python examples/trainer_regression/train.py --accelerator cpu --nodes 2 --devices 2

# More machines: run this on one of them, then paste the printed `gpulayer join` line on the others
gpulayer up

# See what ran
gpulayer dashboard

Not only PyTorch: any command or Python function runs the same way.

gpulayer submit --accelerator cuda --source ./app -- ./render.sh

The full quickstart walks through each step with its output.

Performance and comparison

Measured on NVIDIA GPUs against PyTorch Lightning, with the same model, data and optimizer and each trainer's defaults:

• One Tesla T4: GPUlayer's Trainer is 1.25 to 1.39x faster per step on small models and 1.14x on a compute-bound CNN, and starts 0.1 to 0.7 s sooner.
• 1, 2 and 4 RTX 3070s (DDP over NCCL): GPUlayer is faster in 5 of 6 cases, by 1.11 to 1.76x, with the lead growing with the number of GPUs; the 1-GPU CNN was 1.14x faster with Lightning on that host.
• NCCL across 4 GPUs and over NVLink (2x A100), and the best-connected GPU choice, validated on rented machines.
• One training job across machines on CPUs (gloo): GPUlayer trains 11.9% faster than Lightning under torchrun on 8 machines (50.5 s vs 57.3 s; 5.3% on 4, 1.6% on 2), and it starts every machine from one Trainer(num_nodes=N) call.
• Placement: the same 4-machine job took 42.5 s when GPUlayer kept it in one zone and 58.8 s when it was spread across two GCP regions (median of five, placed by the scheduler).
• Distributed jobs start 1.1 to 2.3 s faster than through torchrun; tested on up to 16 machines (32 processes) and 30 workers across two GCP regions.
• Across two machines: a distributed job spanning both, fail-fast in 2.7 s, and 55.6 small jobs per second.

Method, all charts and raw logs: Performance and comparison. Reproduce them with benchmarks/.

Why GPUlayer

Most GPU code assumes the GPU is on the machine where you run it. With GPUlayer you describe what a workload needs (an accelerator, GPU memory, frameworks) and it runs on a machine that has it, wherever that machine is.

On one machine with one GPU, running your code directly is simpler. GPUlayer runs services without a load balancer in front of them, and is not a sandbox for untrusted code. More in Why GPUlayer.

For AI and coding agents

gpulayer mcp is an MCP server, so Claude Code, Claude Desktop, Cursor, Codex and VS Code agents can list GPUs, submit jobs, wait, read logs and download outputs. An Agent Skill covers agents that use the CLI.

claude mcp add gpulayer -- gpulayer mcp

See AI and coding agents.

Architecture

GPUlayer has three parts:

• Clients submit work: the gpulayer CLI, the Python SDK (@gl.remote, gl.Client), the PyTorch Trainer and launch(), and the MCP server for AI agents. A job states what it needs (accelerator, GPU count and memory, frameworks), not which machine to use.
• The control plane keeps the job queue, picks a worker for each job and records the reason when no worker fits. Distributed groups stay in one network group, zone or region when possible, and multi-GPU jobs get the best-connected GPUs on a machine. It stores code bundles, inputs, outputs and logs, and checks tokens. For work on one machine it runs inside your process; for several machines it runs as a server (gpulayer up).
• Workers, one per machine, report their GPUs and installed frameworks, ask the control plane for tasks, run them as normal processes (one per rank for distributed jobs), stream logs back and upload outputs. Workers open every connection themselves, so they can sit behind NAT. A cloud VM is a worker that joined with gpulayer join.

A job goes from queued to scheduled when a worker fits, then running, and ends as succeeded, failed, cancelled or timed_out. Frameworks such as PyTorch, JAX, MLX and CuPy still decide how the computation uses the GPU; GPUlayer decides which GPU runs it. More in Architecture overview.

Development

uv pip install -e '.[dev,examples]'
.venv/bin/pytest && .venv/bin/ruff check src tests && .venv/bin/mypy src

See Contributing.

License

Apache License 2.0, see LICENSE.