GPflow: Gaussian Process Models Built on TensorFlow 2 and TFP
Gaussian processes in TensorFlow
At a glance
- What is it?
- GPflow is a Python library for composing Gaussian process models from kernels and likelihoods, running the inference on TensorFlow 2.4+ and TensorFlow Probability. It is a research and modelling toolkit, not a turnkey regression service, and its dependency coupling is the first thing to check before adopting it.
- Who is it for?
- Adopt GPflow if you are already inside the TensorFlow 2 and TensorFlow Probability stack and need GP models assembled from composable kernels and likelihoods, including variational and MCMC inference, rather than a single closed regressor. Do not adopt it if you want a small dependency footprint, if you are pinned to TensorFlow 1.x, or if a scikit-learn GaussianProcessRegressor already fits your problem.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 37 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What GPflow is for, and who it is actually for
GPflow is a Python package for building Gaussian process models. The README states it implements modern Gaussian process inference for composable kernels and likelihoods, and that it builds on TensorFlow 2.4+ and TensorFlow Probability for running computations, which allows fast execution on GPUs. That sentence contains the whole pitch and the whole constraint: the value is composition, and the cost is a deep dependency on two large frameworks.
The audience is narrower than the topic list suggests. Someone who wants a fitted regressor with a lengthscale and a variance should not start here. GPflow is aimed at people who need to write down a model: a kernel that is a sum of a periodic term and a linear term, a likelihood that is not Gaussian, an inference scheme that is variational rather than exact. The repository topics point the same way, listing variational inference and Markov chain Monte Carlo alongside gaussian-processes. If your problem is a single scalar output with Gaussian noise and a few thousand points, the composition machinery is overhead you will pay for in setup time and in debugging surface.
The project is Apache-2.0 licensed and is not archived. The default branch is develop, which matters: the README warns that the develop branch may change regularly and that new commits may break your code. Releases are tagged, with v2.11.1 dated 2026-06-16, v2.11.0 dated 2026-06-03, and v2.10.1 dated 2026-05-21, so there is a stable line to pin against.
Kernels and likelihoods as the composition layer
The mechanism GPflow exposes is composition at the level of the model, not at the level of the optimiser. A kernel object and a likelihood object are combined into a model, and the model is what you optimise or sample from. Because kernels are ordinary Python objects that compose, a custom kernel is written by combining existing ones rather than by editing a monolith. The README's own framing is that GPflow implements inference for composable kernels and likelihoods, and the VFF project listed among downstream users is described as variational Fourier features for Gaussian processes, which is the kind of thing that only makes sense if kernels are first-class objects you can replace.
Inference is not limited to the exact Gaussian case. The topics list includes variational inference and Markov chain Monte Carlo, so the library covers both the sparse variational route and the sampling route. That is the real dividing line against simpler GP implementations: a library that only does exact inference with a Gaussian likelihood cannot express a classification model without you writing the approximation yourself.
Computation runs through TensorFlow, which is where the GPU claim comes from. The practical consequence is that autodiff, batching and device placement are TensorFlow's, not GPflow's. When something is slow or a gradient is wrong, the trace goes through TensorFlow and TensorFlow Probability, and you will need to be comfortable reading that stack. This is the strongest argument for adopting GPflow only when you are already invested in TensorFlow.
Installing GPflow and the version coupling that breaks it
The stable route is one command: pip install gpflow. That pulls the latest release from PyPI. For the bleeding edge, the README gives two options from a checkout of the develop branch: pip install -e . for an editable install, or pip install git+https://github.com/GPflow/GPflow.git@develop#egg=gpflow, which the README says will automatically install all required dependencies.
The version coupling is the part worth reading twice. GPflow requires TensorFlow 2.4 or later and TensorFlow Probability 0.12 or later, and Python 3.7 or later. The README states plainly that TensorFlow Probability releases are tightly coupled to TensorFlow, giving the examples that TFP 0.14 requires TF>=2.6, TFP 0.13 requires TF>=2.5, and TFP 0.12 requires TF>=2.4. The problem is that this constraint is not declared in TFP's own dependencies. So if you already have an older TensorFlow installed, GPflow will pull in the latest TFP, which will be incompatible. The README names the symptom: an ImportError such as This version of TensorFlow Probability requires TensorFlow version >= 2.4. The stated fix is either pip install -U tensorflow or manually installing an older tensorflow_probability.
That is a resolver gap, not a GPflow bug, but it lands on GPflow users. In a clean environment the install is uneventful. In an environment where TensorFlow was installed months ago for another project, expect to pin tensorflow_probability by hand and to spend the first hour on dependency archaeology rather than on models.
Where GPflow is the wrong tool
The clearest failure mode is the one above: an environment with a pre-existing TensorFlow install produces an import error that looks like a GPflow problem and is not. The README documents the error string and the workaround, which is a sign the maintainers see it often enough to put it in the install section.
A second boundary is TensorFlow 1.x. The README has a dedicated Version Compatibility entry for TensorFlow 1.x and GPflow 1.x, and a separate GPflow 2 upgrade guide notebook for converting code. If you are on TF1, you are on the old line, and the 2.x material here does not apply to you.
A third is scale expectation. The README claims fast execution on GPUs; it does not claim that exact inference scales to arbitrary dataset sizes. Exact Gaussian process inference has a cubic cost in the number of training points, and nothing in the supplied material suggests GPflow changes that. The sparse variational methods exist precisely because exact inference does not scale, and choosing them means accepting an approximation whose quality depends on inducing point placement, a modelling decision GPflow does not make for you.
Finally, if your need is a single Gaussian-process regressor with a standard kernel, the composition layer and the TensorFlow dependency are both pure cost. There is no configuration in the material that makes GPflow a lighter choice than a self-contained implementation.
GPy and scikit-learn as the two different alternatives
The most direct comparison in the Python GP world is GPy, which occupies the same niche of composable kernel and likelihood objects. The difference is the compute backend: GPflow runs on TensorFlow 2 and TensorFlow Probability, while GPy predates that stack and does not give you TensorFlow's autodiff, GPU placement and batching for free. If you are already training neural networks in TensorFlow, GPflow lets a GP model sit inside the same graph and the same optimiser loop. If you are not, GPy asks for a much smaller install and no framework version negotiation. The choice is really about which ecosystem you already live in, not about which model class is better supported.
scikit-learn's GaussianProcessRegressor is the other end of the spectrum. It is a closed estimator with a fit and predict interface and a fixed set of kernels. You cannot swap in a non-Gaussian likelihood or a variational inference scheme without leaving the estimator. GPflow's answer to that is the opposite design: you assemble the model, so anything expressible as a kernel plus a likelihood plus an inference method is in scope. The trade is that GPflow gives you no fit method that just works; you write the training loop.
Both alternatives are named here only to mark the boundary. Neither is a drop-in replacement for the other, and the supplied material does not contain benchmark comparisons between them.
Maintenance, releases and what the licence implies
GPflow is actively maintained by four named maintainers, with Artem Artemev, Mark van der Wilk, ST John and Vincent Dutordoir listed in the README, and it was originally created by James Hensman and Alexander G. de G. Matthews. The repository is not archived and the last push is dated 2026-08-10, so the develop branch is live. Release cadence in the supplied material is three releases across roughly a month, v2.10.1 on 2026-05-21, v2.11.0 on 2026-06-03 and v2.11.1 on 2026-06-16, with patch releases following minor ones.
The upgrade cost is concentrated at the major boundary. The README points to a GPflow 2 upgrade guide notebook for converting from GPflow 1, which tells you the 1 to 2 transition was a real migration rather than a rename. Within 2.x the releases are minor and patch versions, and nothing in the material describes breaking changes between them. Pinning to a released 2.x version rather than tracking develop is the low-effort way to avoid the breakage the README warns about for develop.
The licence is Apache-2.0. That is a permissive licence with an explicit patent grant, and it permits commercial use and modification. This is not legal advice; if you are redistributing GPflow inside a product, check the notice and attribution requirements in the licence text itself. Note that the dependency chain, TensorFlow and TensorFlow Probability, carries its own licence terms, and those are not covered by GPflow's.
Who should adopt GPflow, and what to check first
Adopt GPflow if you are building Gaussian process models that need non-standard kernels, non-Gaussian likelihoods, or inference beyond the exact Gaussian case, and you are already working inside TensorFlow 2. The composition model is the reason to be here, and the TensorFlow and TFP dependency is the price. The downstream project list in the README, which includes Trieste for Bayesian optimisation with out-of-the-box GPflow 2.x support, VFF for variational Fourier features, and BranchedGP for branching kernels, is a reasonable map of the kind of work this library is built for.
Do not adopt it if a scikit-learn GaussianProcessRegressor covers your case, if you need TensorFlow 1.x support, or if you cannot absorb a TensorFlow plus TensorFlow Probability install.
Before you commit, do three things in this order. Check your installed TensorFlow and tensorflow_probability versions against the coupling the README spells out, and pin tensorflow_probability explicitly if TensorFlow was already present. Install from a released tag rather than develop unless you need an unreleased fix, because the README states that develop may change regularly and break your code. And if you are carrying GPflow 1 code, open the GPflow 2 upgrade guide notebook before writing anything new, because the 1 to 2 change is documented as a migration.
Editorial conclusion
Adopt GPflow if you are already inside the TensorFlow 2 and TensorFlow Probability stack and need GP models assembled from composable kernels and likelihoods, including variational and MCMC inference, rather than a single closed regressor. Do not adopt it if you want a small dependency footprint, if you are pinned to TensorFlow 1.x, or if a scikit-learn GaussianProcessRegressor already fits your problem. Before committing, verify that your installed TensorFlow and tensorflow_probability versions satisfy the coupling the README describes, run pip install gpflow in a clean environment, and read the GPflow 2 upgrade guide if you are carrying over GPflow 1 code.
Community notes