Deployment

How PyTorch the project gets released, and how PyTorch the runtime gets deployed.

The project's release cycle

Major releases ship roughly every three months. The cadence and process is documented in RELEASE.md. Headlines:

• Release cut. A release/X.Y branch is created from main; only cherry-picks land on it after that.
• Bug-fix patches. X.Y.Z releases ship for ~3-6 months after the major.
• Nightlies. 2.X.0.dev<DATE> wheels are built from main every night by nightly.yml.
• Stable wheels. Built on the release/X.Y branch by binary*.yml workflows when a release is tagged.

Wheel build matrix

Every release builds wheels for:

Axis	Values
OS	Linux x86_64, Linux aarch64, macOS arm64, Windows x86_64
Python	3.10, 3.11, 3.12, 3.13 (rolling over time)
CUDA	None (CPU), 12.x, 12.6+, 12.8+, sometimes 11.x
ROCm	rocm6.x
XPU	One SKU

That's a few dozen wheels per release. The workflows under .github/workflows/binary-*.yml orchestrate this.

CI architecture

graph LR
    PR[Pull request] --> Pull[pull.yml]
    Pull -->|sharded| Runners[GHA runners]
    Pull -->|GPU| LinuxFoundation[Linux Foundation H100/A100]
    Pull -->|ROCm| AMD[AMD MI300 farm]
    Trunk[Trunk push] --> TrunkW[trunk.yml]
    TrunkW --> Nightly[nightly.yml]
    Nightly --> S3[Nightly S3 bucket]
    Release[Release tag] --> Binaries[binary-*.yml]
    Binaries --> Pypi[PyPI / download.pytorch.org]

PyTorch CI runs on a mix of:

• GitHub-hosted runners (lint, CPU jobs).
• Linux Foundation–donated GPU farms (CUDA jobs).
• AMD-donated ROCm farms.
• Intel-donated XPU runners.
• Self-hosted ARM, MPS, Windows runners.

The orchestrating logic is mostly in .github/workflows/_*-test.yml reusable templates.

Channels for users

Channel	Purpose
https://download.pytorch.org/whl/cu126	Stable CUDA 12.6 wheels
https://download.pytorch.org/whl/nightly/cu128	Nightly CUDA 12.8 wheels
https://download.pytorch.org/whl/test/cu126	Release-candidate wheels
PyPI torch	CPU + CUDA 12.x default
Conda (via pytorch channel)	Maintained but de-emphasized
Docker Hub pytorch/pytorch	Stable & nightly CUDA images

Deploying a model

Users have several options for non-Python deployment, in roughly modern → legacy order:

1. AOTInductor. Compile an ExportedProgram to a self-contained .so plus .json metadata. Load from C++ via torch::inductor::AOTIModelContainerRunner (~few thousand lines in torch/csrc/inductor/aoti_runtime/). No Python at runtime.
2. torch.export + custom backend. Hand the ExportedProgram to a third-party runtime (TensorRT, ONNX Runtime, ExecuTorch).
3. TorchScript. Save with torch.jit.save; load with torch::jit::load from C++. The legacy path; still supported but no new features.
4. ONNX. Export with torch.onnx.export (or the dynamo-backed torch.onnx.dynamo_export); run with any ONNX-compatible runtime.
5. ExecuTorch. The "PyTorch on edge" runtime. Compiles ExportedProgram to an .pte file; runs on iOS, Android, microcontrollers.

Observability in production

• Profiler / Kineto. The on-the-fly torch.profiler.profile + tensorboard view; supports CUPTI on CUDA and MPS Metal counters on macOS.
• CUDA memory snapshots. torch.cuda.memory._dump_snapshot() produces an HTML you can drag into https://pytorch.org/memory_viz.
• Flight recorder. TORCH_NCCL_DUMP_ON_TIMEOUT=1 dumps every recent NCCL collective when a timeout fires; invaluable for diagnosing distributed hangs.
• Structured tracing. TORCH_TRACE=/path/to/trace.json + tlparse for compile-stack diagnostics.

Where to look

File	Purpose
RELEASE.md	Release process docs
.github/workflows/binary-*.yml	Wheel build workflows
.github/workflows/nightly.yml	Nightly orchestration
.github/workflows/trunk.yml	Post-merge CI
torch/csrc/inductor/aoti_runtime/	AOTInductor C runtime
torch/csrc/jit/serialization/	TorchScript loading