Three and a half years into the PyTorch 2.x era is a good moment to take stock. This is our annual read on where the framework and its ecosystem stand, written for teams planning builds in the coming year rather than for framework developers. We will refresh it each year.
The 2.x era, in brief
PyTorch 2.0 arrived in March 2023 with one promise: keep eager mode as the developer experience and add a compiler underneath. By 2026 that promise has been kept. torch.compile is the default answer to "how do I make this faster," it covers training as well as inference, and the stable releases in the 2.11+ range have spent most of their effort on making compilation more robust (fewer graph breaks, faster cold starts, caching) rather than on new surface area. The practical consequence is that compile-by-default is now a reasonable workflow for production models, with eager one flag away for debugging. Our torch.compile in practice tutorial covers how to measure it.
Three other pieces of 2.x have matured from announcement to default:
torch.exportis the deployment artifact. It produces a standalone graph that serving runtimes, AOTInductor and ExecuTorch consume, and it has quietly displaced TorchScript, which remains available but in maintenance mode.- ExecuTorch is the official edge runtime. On-device PyTorch used to mean a fragile
torch.jitpath through PyTorch Mobile; now it is an export-and-delegate pipeline targeting Core ML, XNNPACK, Vulkan and vendor backends, with LLM runners for small models on phones. - FSDP2 and DTensor are the distributed story. The per-parameter sharding design composes with tensor parallelism, compile and distributed checkpointing in a way the first FSDP never did, and it is what new multi-GPU code should use.
What died
Ecosystem consolidation is the other theme. Several pieces teams still carry in requirements files are gone:
- TorchServe was archived in August 2025 with no further releases or security patches. Serving moved to Triton, LitServe, ONNX Runtime and, for LLMs, vLLM and SGLang. If you are still on it, read Migrating off TorchServe.
- TorchText was deprecated in 2024. Text preprocessing now lives in the Hugging Face
tokenizersanddatasetslibraries. - TorchScript as a deployment target has been superseded by
torch.export. - Apex mixed precision and fused layers have been absorbed into core (
torch.autocast, fused optimizers, compile). - PyTorch Mobile was replaced by ExecuTorch.
What won
The Hugging Face stack is the de facto application layer for anything involving pretrained models: transformers for models, peft for parameter-efficient fine-tuning, trl for instruction and preference tuning, datasets for data. For LLM inference, vLLM became the default server and SGLang the main alternative, both built on PyTorch. torchao consolidated quantization and low-precision training (INT8, INT4, FP8) into one PyTorch-native library. And sentence-transformers remains the workhorse for embedding models in retrieval systems.
The hardware story settled too: BF16 is the universal training precision, FP8 is routine for large-model training and serving on Hopper-class and newer GPUs, and INT4 weight-only quantization is the normal way to serve open-weight LLMs economically. See Choosing precision in 2026.
What it means for teams planning builds
Upgrade. Codebases pinned to 1.x are now three years behind a toolchain (CUDA, Python, companion libraries) that has moved on, and the longer they wait the bigger the jump. Our migration checklist is the place to start.
Plan serving with the model, not after it. The serving landscape is stable enough to choose up front: vLLM for LLMs, Triton or LitServe for everything else, ExecuTorch for on-device. Retrofitting serving onto a finished model is where projects stall.
Own your weights. Open-weight models in the 1-70B range, fine-tuned on your data and served on your infrastructure, are now a mainstream engineering pattern rather than a research exercise. For many enterprise workloads that is cheaper, more private and more controllable than an API, and it is squarely PyTorch work.
Do not chase every release. The framework is stable. Upgrade quarterly, keep a regression harness, and spend the saved effort on data and evaluation, which remain where most of the real gains are.
If you want a second opinion on a PyTorch build or modernization plan for the year ahead, our AI consulting and strategy practice exists for exactly that. Contact us.