pytorch vs tensorflow: eager tape versus a deploy-anywhere platform
PyTorch builds networks on a tape-based autograd system that is meant to be written and debugged like ordinary Python; TensorFlow is an end-to-end platform whose stable Python and C++ APIs reach servers, browsers and edge devices. Pick PyTorch for research loops that change shape every iteration, TensorFlow for a pinned release that has to ship to more than one kind of device.
At a glance
| Project | pytorch/pytorch | tensorflow/tensorflow |
|---|---|---|
| Licence | Custom licenceCustom licence: read the LICENSE file | Apache-2.0Permissive: commercial use allowed |
| Maintenance | Commits in the last dayLast push October 11, 2026 | Commits in the last dayLast push October 11, 2026 |
| Language | Python | C++ |
| GitHub stars | 104,407 | 200,868 |
| Read more | Our analysisGitHub | Our analysisGitHub |
Which one to choose
Choose pytorch if your network structure changes between iterations, if you want to write layers in plain Python next to NumPy and SciPy, and if a large GPU binary dependency is acceptable.
Choose tensorflow if you need a stable Python and C++ API with documented deployment to servers, browsers and edge devices, and you are willing to pin a release rather than track master.
Tape-based autograd against a compiled, deploy-anywhere platform
The two projects answer different questions. PyTorch is a Python package with two stated features: tensor computation with strong GPU acceleration, and deep neural networks built on a tape-based autograd system. Its README describes reverse-mode auto-differentiation that lets you change how a network behaves arbitrarily with zero lag or overhead, and contrasts this with frameworks that hold a static view of the world, where changing behaviour means starting from scratch. That is the architectural split in one sentence. A PyTorch graph is recorded as the code runs, so the structure can differ on every pass through the loop. TensorFlow's README describes an end-to-end open source platform for machine learning, with stable Python and C++ APIs plus a non-guaranteed backward compatible API for other languages. Its stated reach is servers, browsers and edge devices. Where PyTorch treats the framework as a library you call from Python, TensorFlow treats it as a platform with several front ends and several deployment targets behind one release. The practical consequence: PyTorch optimises for the cost of writing and changing model code, TensorFlow optimises for the cost of moving a trained model onto hardware you do not control.
Getting each one running: pip wheels, CUDA builds and Python versions
TensorFlow's install path is the shorter of the two on paper. Its README gives pip install tensorflow for the current release with CUDA-enabled GPU support on Ubuntu and Windows, pip install tensorflow-cpu for a smaller CPU-only package, and notes that DirectX and macOS-metal devices are supported through Device Plugins. Nightly binaries are published as tf-nightly and tf-nightly-cpu. Our analysis of tensorflow says the first thing to verify is that the pip wheel matches your Python version, because the repository ships separate requirements_lock files for 3.10 through 3.14 plus a freethreaded variant, and that you should confirm your GPU path against the install guide before promising a deadline. PyTorch's README is organised around binaries, source builds and Docker images, with separate prerequisite sections for NVIDIA CUDA, AMD ROCm and Intel GPU support, plus a section for NVIDIA Jetson platforms. Our analysis of pytorch says you should verify which CUDA build your hardware needs before committing, check the release notes for the version you plan to pin, and read the deprecation schedule in setup.py if your build scripts call it directly. The difference is where the risk sits. TensorFlow's risk is a version mismatch between wheel and interpreter; PyTorch's is a mismatch between the binary you install and the accelerator you own, and it grows if you build from source.
Training loops, graph capture and the cost of changing your mind
PyTorch's README lists the components a training loop is assembled from: torch for the tensor library, torch.autograd for tape-based differentiation, torch.nn for layers integrated with autograd, torch.utils for DataLoader and similar helpers, torch.multiprocessing for memory-shared tensors across processes, and torch.jit, a compilation stack that produces serializable and optimizable models from PyTorch code. The last item matters for operations: TorchScript is the bridge from an eager loop to something you can ship without the Python interpreter in the loop. TensorFlow's README does not present the training loop as a set of parts to assemble; it presents a platform with stable Python and C++ APIs and points to tutorials for examples. The C++ API is the part PyTorch does not offer as a stable, documented surface in the same way. If your serving path is C++ and you do not want a Python runtime next to it, that difference decides the choice before any benchmark does. If your work is a research loop where the model changes shape between iterations, the tape is the feature, and the compilation step is an extra thing to maintain.
Deployment reach and the platforms each one actually names
TensorFlow's README names its deployment surface directly: servers, browsers and edge devices, with install instructions for pip, GPU support, Docker and source builds, and Device Plugins for DirectX and macOS-metal. It also documents a patching procedure for a specific version, which is unusual to see in a README and useful if you have to carry a security fix on a pinned branch: clone the repository, switch to the branch for your version such as r2.8, cherry-pick the change, resolve conflicts, run the tests, and build the pip package from source. PyTorch's README names Docker images, including building the image yourself, and source builds with accelerator-specific prerequisites. It does not present a browser or edge-device target as part of the package's own story. That is not a defect; it is a different boundary. PyTorch's answer to deployment is TorchScript plus whatever runtime you choose, and the README stops at producing serializable and optimizable models. TensorFlow's answer is inside the project. If your release has to land on a phone, a browser and a server from one artefact, TensorFlow's documented path is shorter. If your release is a Python service or a research artefact, PyTorch's boundary is not a limitation you will feel.
Where each one falls short
PyTorch's own analysis is blunt about the limits. Do not adopt it if you need a static graph compiled ahead of time, or if you are building a project that cannot absorb a large binary dependency. The GPU-ready tensor library and the tape are the point, and both pull in weight: accelerator-specific binaries, source builds with CUDA, ROCm or Intel GPU prerequisites, and a deprecation schedule in setup.py that build scripts may have to track. Teams that want a small, predictable dependency will find PyTorch the wrong shape. TensorFlow's limits are stated with equal clarity in our analysis of tensorflow: do not adopt it if you want a single small dependency, or if your team has already standardised on another framework's training loop, because the migration cost is real and the repository offers no migration tooling. The Python version matrix compounds this. Separate requirements_lock files for 3.10 through 3.14 plus a freethreaded variant mean the wheel you need depends on the interpreter you run, and an upgrade of one is an upgrade of the other. Neither project is the cheap option. PyTorch charges in binary size and accelerator plumbing; TensorFlow charges in version pinning and migration effort.
Licence and maintenance: a custom licence against Apache-2.0
The licence difference is the one a legal review will ask about first. TensorFlow is Apache-2.0, a standard permissive licence with patent language that corporate review teams have seen many times. PyTorch is classified by GitHub as Other: a custom licence the platform cannot classify, with the terms in the LICENSE file. That does not make it non-free, but it does mean the terms have to be read rather than assumed, and that a redistribution or a bundled product may need a review that Apache-2.0 would not trigger. On maintenance, both repositories were pushed on 2026-09-27 and neither is archived, so both are under current development. The release cadence differs in shape: PyTorch's recent releases are v2.13.0 on 2026-07-08, v2.12.1 on 2026-06-18 and v2.12.0 on 2026-05-13, a steady line of minor versions. TensorFlow's recent releases are v2.21.0 on 2026-03-06, with v2.21.0-rc1 on 2026-03-02 and v2.21.0-rc0 on 2026-02-09, a longer cycle with visible release candidates. Neither cadence is better in the abstract. A faster minor line means more frequent upgrade work; a longer cycle means a fix you need may wait for the next train, which is why TensorFlow's documented cherry-pick and rebuild procedure exists.
Choosing by scenario
For a research group writing models whose structure changes between iterations, PyTorch is the direct fit: the tape records what the code does, layers can be written in Python alongside NumPy, SciPy and Cython, and torch.jit is available when a model needs to be serialized. For a product team shipping one model to a server, a browser and an edge device, TensorFlow is the direct fit: the README names those targets, the Python and C++ APIs are described as stable, and the patching procedure gives a route to carry a fix on a pinned branch. For a team that needs a C++ serving path without a Python runtime alongside it, TensorFlow's stable C++ API is the deciding factor. For a team that cannot absorb a large binary dependency, PyTorch's own analysis says to look elsewhere, and TensorFlow's Python version matrix suggests it is not the small alternative either. For a team already standardised on another framework's training loop, our analysis of tensorflow says the migration cost is real and there is no migration tooling in the repository, so the honest answer is to stay unless a deployment target forces the move. The two are complementary more often than they are competitors: PyTorch for the loop where the model is invented, TensorFlow where the resulting artefact has to travel.
Bottom line
Pick PyTorch when the model is still changing shape and the team lives in Python; pick TensorFlow when one artefact has to reach servers, browsers and edge devices from a pinned release with a stable C++ API. Before committing, verify the accelerator build against your hardware and the release notes for the version you will pin on the PyTorch side, and on the TensorFlow side verify that the pip wheel matches your interpreter version and that your GPU path follows the install guide. Read the PyTorch LICENSE file rather than assuming a standard permissive licence, because GitHub classifies it as Other.