AI frameworks comparison 2026: PyTorch, TensorFlow, JAX, LangChain and more

AI frameworks compared at a glance

An AI system has five layers, and each has its own tools:

• Classic machine learning trains models on tables of numbers and categories: scikit-learn and XGBoost.
• Deep learning frameworks define and train neural networks on GPUs and TPUs: PyTorch, TensorFlow with Keras 3, and JAX.
• Model libraries hand you pretrained models, so you rarely train from scratch: Hugging Face Transformers.
• Exchange formats and inference engines take a trained model out of its training framework and run it: ONNX, ONNX Runtime, vLLM and llama.cpp.
• Application frameworks connect a model to your data, tools and users: LangChain, LlamaIndex, and the agent SDKs from OpenAI, Anthropic, Google and Microsoft.

Tools compete inside a layer and cooperate across layers. An open-model project might fine-tune with Transformers on PyTorch, serve the result with vLLM and call it from an agent built with LangGraph. Compare the rows of each layer with each other, not with the rows of another layer:

Every open-source project in the table uses a permissive licence (BSD, Apache 2.0 or MIT). The exception is the Claude Agent SDK: Anthropic's documentation says its use is governed by Anthropic's Commercial Terms of Service, except where a component's own licence file says otherwise.

What changed in AI frameworks since 2023

The December 2023 version of this page compared TensorFlow with PyTorch, TensorFlow Lite with ONNX Runtime, and a set of no-code, language, vision and cloud platforms. Since then, the changes that matter most for a framework choice are these:

This version leaves out no-code AutoML suites and managed cloud ML platforms. They are services you rent, and choosing between them is a cloud decision rather than a framework decision.

PyTorch vs TensorFlow vs JAX for deep learning

All three define neural networks as operations on tensors, compute gradients automatically and train on accelerators. They differ in programming model, governance and where the trained model can go next.

PyTorch

PyTorch is a Python package for tensor computation with strong GPU acceleration and for deep neural networks built on a tape-based autograd system. Code executes line by line, so a model is ordinary Python: when something fails, the debugger and the stack trace point at your own code. When you need speed, torch.compile compiles the same code.

PyTorch development started in 2016, with a large share of its people and funding from Meta. In September 2022 it moved to the Linux Foundation as the PyTorch Foundation, with a governing board from AMD, AWS, Google Cloud, Meta, Microsoft Azure and NVIDIA. The foundation now also hosts vLLM, DeepSpeed, Ray, Helion, Safetensors and ExecuTorch, PyTorch's runtime for phones and embedded devices.

PyTorch 2.14, released on September 2, 2026, is the current version. Its release notes cover NVIDIA kernels, AMD ROCm wheels, Intel XPU, native linear algebra on Apple silicon, and the C++ front end (LibTorch) for applications that cannot run Python.

TensorFlow and Keras 3

TensorFlow is an end-to-end open-source machine learning platform, first developed at Google Brain, with stable Python and C++ APIs. Its traditional strength is deployment: TF Serving, TF.js and TensorFlow Lite. As of September 2026 the latest release is TensorFlow 2.21, from March 6, 2026, which dropped Python 3.9 and the TensorBoard dependency.

Its footprint is getting smaller. TensorFlow Lite was renamed LiteRT in September 2024, and TensorFlow 2.20 deprecated tf.lite, moving on-device development into the separate LiteRT repository. Hugging Face Transformers v5 dropped TensorFlow in favour of PyTorch.

Keras 3 is the bridge. It is a full rewrite that runs the same model code on JAX, TensorFlow or PyTorch, plus OpenVINO for inference only, and you pick the backend with the KERAS_BACKEND environment variable. Keras 2 remains available as the tf-keras package, so existing TensorFlow code keeps working while new models are written for Keras 3.

JAX

JAX is a Python library for accelerator-oriented array computation and program transformation. You write NumPy-style functions and transform them: jax.grad differentiates them, jax.jit compiles them with XLA for GPUs and TPUs, and jax.vmap vectorizes them over a batch. The transformations compose, which is what makes JAX suited to high-performance numerical computing and large-scale training.

JAX is still versioned 0.x. Its compatibility policy says a new Y in 0.X.Y may bring minor breaking changes and a new X major ones, after a three-month deprecation period. The README calls JAX a research project, not an official Google product, and warns of sharp edges. Pin the version and budget for upgrades, or reach JAX's compiler through Keras 3 without adopting its functional style.

PyTorch vs TensorFlow in 2026

For new deep learning work, PyTorch is the lower-risk default. It is governed by a vendor-neutral foundation, and the tools around it assume it: Transformers v5 supports only PyTorch, vLLM is built on it, and ExecuTorch takes its models to devices. TensorFlow remains reasonable for systems already built on its serving tools. Plan new on-device work on LiteRT, and write new models in Keras 3 so they no longer depend on one backend.

scikit-learn and XGBoost for tabular data

Predicting churn, demand or a risk score from rows and columns of business data is classic machine learning, and these two libraries are built for it.

scikit-learn offers classification, regression, clustering, dimensionality reduction, model selection and preprocessing, built on NumPy, SciPy and matplotlib, under a BSD licence. Version 1.9 is current. Its strength is one consistent API, with pipelines and grid search tying the steps together, maintained as a meritocratic, consensus-based community project.

Its limits are deliberate. Its FAQ puts deep learning and reinforcement learning out of scope and points to PyTorch, TensorFlow and Keras instead. GPU support is narrow: since 2023, a limited but growing list of estimators can run on GPUs through experimental Array API support when you pass PyTorch or CuPy arrays, and the tree-based models are not among them.

XGBoost is an optimized, distributed gradient boosting library: it builds an ensemble of decision trees, each correcting the errors of the trees before it. The same code runs on one machine or on Kubernetes, Hadoop, Dask, Spark and PySpark, it trains on GPUs, and it ships packages for Python, R, the JVM, Ruby, Swift, Julia, C and C++. XGBoost 3.4 is current. It began as a research project at the University of Washington and is maintained by its community under Apache 2.0. How gradient boosting and other algorithms scale to large datasets is covered in machine learning algorithms for big data.

Start with a scikit-learn pipeline and its built-in gradient boosting as the baseline. Move to XGBoost when the data outgrows one machine, when you need GPU training, or when the model must run inside a JVM or R service. When you only need predictions, scikit-learn's model persistence guide points to ONNX, which serves the model without Python, though not every model converts.

A tabular model is only as good as the tables it learns from. Our data platform service builds the governed warehouse or lakehouse behind it and delivers features and datasets for ML and AI.

Hugging Face Transformers: start from a pretrained model

Transformers describes itself as the "model-definition framework" for text, vision, audio, video and multimodal models, for inference and training. Its value is that one definition is shared across the ecosystem: training tools such as Axolotl, Unsloth and DeepSpeed, inference engines such as vLLM, SGLang and TGI, and libraries such as llama.cpp and MLX reuse it. Its README counts more than a million Transformers checkpoints on the Hugging Face Hub.

Version 5.0.0, released on January 26, 2026, was the first major release in five years. It moved to weekly minor releases instead of one every five weeks. Current releases need Python 3.10 or later and PyTorch 2.5 or later. Hugging Face's v5 announcement explains the two decisions that matter for a comparison:

• PyTorch is the only backend. TensorFlow and Flax support was sunset, while Hugging Face works with JAX projects on compatibility.
• Speed is left to inference engines. Transformers does not aim for the specialized optimizations of dedicated inference engines such as vLLM, SGLang and TensorRT-LLM. Load and fine-tune with Transformers; serve with an engine.

For the weights themselves, use Safetensors, a format that stores tensors safely, as opposed to pickle. Safetensors is now a PyTorch Foundation project.

ONNX and ONNX Runtime: train in one framework, run in another

ONNX (Open Neural Network Exchange) is an open format for trained models. It defines a computation graph, a common set of operators and standard data types, covers deep learning and traditional ML, and focuses on what inference needs. It was created by Facebook and Microsoft and is a graduated LF AI & Data project with open governance.

ONNX Runtime is Microsoft's cross-platform accelerator for running those models, and for training them. It takes models from PyTorch and TensorFlow/Keras as well as from classical libraries such as scikit-learn, LightGBM and XGBoost. It has APIs for Python, C#, C, C++, Java and JavaScript, and Microsoft uses it in Office, Azure and Bing. A common pattern in its documentation is training in Python and deploying into a C#, C++ or Java application.

The hardware side is handled by execution providers: CUDA and TensorRT on NVIDIA GPUs, OpenVINO on Intel, DirectML on Windows, Core ML on Apple devices, QNN on Qualcomm chips, and WebGPU and XNNPACK among others. The same API calls work across all of them, so moving a model from a GPU server to a laptop's NPU is a configuration change rather than a rewrite. Not every model converts cleanly, so compare the exported model's predictions with the original on real inputs before you switch.

vLLM vs llama.cpp: running large language models

Both run open-weight LLMs and both expose an OpenAI-compatible HTTP API, so application code can move between them. They are built for different hardware and different load.

vLLM for GPU servers with many users

vLLM is a library for LLM inference and serving that started in the Sky Computing Lab at UC Berkeley. It batches incoming requests continuously, caches shared prompt prefixes, supports quantized weights (FP8, INT4, GPTQ, AWQ, GGUF and others) and speculative decoding, and splits large models across GPUs with tensor, pipeline and expert parallelism. It serves an OpenAI-compatible API and the Anthropic Messages API, runs on NVIDIA and AMD GPUs and on x86, ARM and PowerPC CPUs, and reaches TPUs, Intel Gaudi, Huawei Ascend and Apple silicon through plugins.

Its core idea is memory. Every request keeps a KV cache that grows and shrinks as tokens arrive, and allocating it carelessly wastes GPU memory and caps the batch size. PagedAttention manages that cache the way an operating system manages virtual memory, in pages. The SOSP 2023 paper reports near-zero waste, cache sharing within and across requests, and 2 to 4 times the throughput of FasterTransformer and Orca at the same latency.

vLLM became a PyTorch Foundation-hosted project in May 2025 and is deeply integrated into PyTorch, which it uses as its interface to different hardware. It is Apache 2.0 licensed and still versioned 0.x: v0.30.0 shipped on September 22, 2026. Pin the version in production and upgrade deliberately.

llama.cpp for laptops, CPUs and edge devices

llama.cpp aims at LLM inference with minimal setup on a wide range of hardware. It is plain C and C++ without dependencies, treats Apple silicon as a first-class target through Metal, uses AVX, AVX2 and AVX-512 on x86, and runs on NVIDIA (CUDA), AMD (HIP), Vulkan and SYCL back ends. It can split a model between CPU and GPU when the model is larger than the GPU's memory, and it ships an OpenAI-compatible server. It is MIT licensed and built on the ggml library.

Models for llama.cpp use GGUF, a binary format built for quick loading. Unlike tensor-only formats such as Safetensors, also recommended on the Hugging Face Hub, GGUF stores the tensors together with a standardized set of metadata. Models built in PyTorch can be converted to GGUF, and Transformers v5 can load GGUF files for further fine-tuning. llama.cpp supports 1.5-bit to 8-bit integer quantization for faster inference and lower memory use; test answer quality on your own prompts at the level you pick.

In February 2026 the ggml team joined Hugging Face. Hugging Face says the project stays 100% open source and community-driven, and that the team keeps full autonomy over its technical direction.

Choose vLLM when many users share data-centre GPUs and throughput per GPU drives the cost. Choose llama.cpp when the model must run on one machine you control: a CPU-only server, an Apple silicon laptop or a small device.

Phones and embedded devices

Three runtimes do this job. LiteRT, formerly TensorFlow Lite, runs models on Android, iOS and embedded devices, including models authored in PyTorch, JAX and Keras. ExecuTorch is PyTorch's own runtime for phones and embedded systems. ONNX Runtime reaches the same devices through its Core ML, NNAPI, QNN and XNNPACK execution providers. Pick the one your training framework exports to most directly.

LangChain, LlamaIndex and agent SDKs for LLM applications

These frameworks do not train models. They wrap calls to a model, hosted or self-hosted, in what an application needs: prompts, retrieval over your documents (retrieval-augmented generation, RAG), tool calls, memory between turns and tracing. They overlap heavily, and several are young: LangChain reached 1.0 in October 2025, Microsoft Agent Framework in April 2026, and the OpenAI Agents SDK is still 0.x.

LangChain and LangGraph

LangChain is a framework for building agents and LLM-powered applications from interoperable components and third-party integrations. In its current documentation, the core is create_agent, a configurable harness of model, tools, prompt and middleware that works with OpenAI, Anthropic, Google and other providers. Underneath sits LangGraph, a lower-level orchestration framework for workflows that mix fixed steps with agent decisions, and LangSmith traces and evaluates what runs.

LangChain 1.0 and LangGraph 1.0, released on October 22, 2025, committed to no breaking changes until 2.0, so code written against 1.x should keep working until then. Both ship for Python and JavaScript, and LangChain is MIT licensed.

LlamaIndex

LlamaIndex is an open-source framework for building agentic applications over your own data. Its building blocks are data connectors that ingest documents from their source, indexes, retrievers, query engines and rerankers, plus event-driven workflows that combine agents and data sources. It is available in Python and TypeScript, and the same company offers managed services: LlamaParse for document parsing, and LlamaCloud.

LangChain and LlamaIndex overlap. Choose by where the hard part of your application is: LlamaIndex when it is getting the right passages out of messy documents, LangChain when it is the agent's control flow and the number of systems it talks to.

Agent SDKs from the model providers

An agent is an application that plans its own steps and calls tools to complete a task. At its core is a loop, which LangChain's 1.0 announcement spells out: send the conversation to the model; if the model asks for a tool, run it, add the result and ask again; stop when the model gives a final answer. The SDKs add what production needs around that loop: permissions or human approval before a tool runs, guardrails on inputs and outputs, sessions and tracing.

Maturity differs. The OpenAI Agents SDK is still versioned 0.x (v0.22.3 in September 2026). Microsoft Agent Framework's core Python packages reached 1.0, marked production/stable on April 2, 2026, while many integration packages stayed in beta. Google's ADK documentation covers ADK 2.0, and the TypeScript edition of 2.0 is generally available.

What they share is the Model Context Protocol. LangChain and all four SDKs can call tools exposed as MCP servers, and MCP has been a project of the Linux Foundation's Agentic AI Foundation since December 2025. Tools you build as MCP servers therefore survive a change of framework, which makes the framework choice itself easier to reverse.

Which AI framework should you choose?

Match the tool to the job and to the team that will run it:

Then decide in this order:

1. Decide whether you need to train at all. A pretrained model from the Hub, or a hosted model behind an API, removes the training layer entirely, and with it most of the framework choice. If a model must keep learning after release, see AI continuous learning.
2. Choose by the team's language and the target hardware. A .NET shop, a JVM data platform and a Python research team each narrow the table differently.
3. Check governance and version status. Foundation-hosted projects (PyTorch, vLLM, ONNX) do not depend on one company's roadmap; 0.x projects need pinned versions and an upgrade budget.
4. Prototype the riskiest step with real data before you standardize: a demo that works on ten examples says little about the thousandth.

If the choice is part of automating a real workflow, our AI automation service starts with a review of one workflow with the people who run it, before anything is built: where AI helps, where it does not, and a risk class and approval rule for each action.

Check security, licences and governance before you commit

A framework comparison stops at features; production also depends on what the tools let into your systems.

• Licences. The frameworks here are permissively licensed, apart from the Claude Agent SDK's commercial terms. The licence of a model's weights is separate from the framework's, so check it on the model itself.
• Governance. A foundation-hosted project (PyTorch, vLLM, Safetensors, ONNX, MCP) is governed in the open; a company-led one follows that company's priorities. Neither is wrong, but know which one you depend on.
• Versions. Pin every 0.x dependency (JAX, vLLM, the OpenAI Agents SDK) and upgrade on purpose, with your own evaluation run before and after.
• Supply chain. Model files, tokenizers and agent tools are dependencies like any other package, and the habits in our secure coding checklist apply to them.

Our AI automation work pins model and prompt versions, tests every change against an evaluation set from real cases, and gives agents only the tools and access they need. More on these topics is under AI and automation.