GPflow: A Gaussian process library using TensorFlow

2016·arXiv

Abstract

1. Existing Gaussian process libraries

There are now many publicly available Gaussian process libraries ranging in scale from personal projects to major community tools. We will therefore only consider a relevant subset of the existing libraries. The influential GPML toolbox (Rasmussen and Nickisch, 2010) uses MATLAB. It has been widely forked. A key reference for our particular contribution is the GPy library (GPy, since 2012), which is written primarily using Python and Numeric Python (NumPy). GPy has an intuitive object-oriented interface. Another relevant Gaussian process library is GPstuff (Vanhatalo et al., 2013) which is also a MATLAB library.

2. Objectives for a new library

GPflow is motivated by a set of goals. The software is designed to be fast, particularly at scale. Where approximation inference is necessary we want it to be accurate. We aim to support a variety of kernel and likelihood functions. Another goal is that the implementations are verifiably correct. The software should be made easy to use by an intuitive user interface. Finally it should be easy to extend the software. We argue that there is a way to better meet these simultaneous objectives than existing packages and that it is realised in GPflow.

3. Key features for meeting the objectives

To best meet the key goals of our library, we were led to a project that had all of the following distinguishing features:

(i) The use of variational inference as the primary approximation method to meet the twin challenges of non-conjugacy and scale.

(ii) Relatively concise code which uses automatic differentiation to remove the burden of gradient implementations.

Table 1 gives a summary of which Gaussian process libraries possess the distinguishing features we have highlighted. The GPflow interface and Python architecture are heavily influenced by GPy. An important difference between GPflow and GPy is that GPflow uses TensorFlow for its core computations rather than numeric Python. This difference significantly affects the general requirements of the architecture. The GPU functionality in GPy is currently limited to CUDA code for the GPLVM (Dai et al., 2014). By contrast the GPflow implementation is targeted at a broad variety of GPU capability.

Having established a desirable set of key design features, the question arises as how best to engineer a Gaussian process library to achieve them. A central insight here is that many of the features we highlight are well supported in neural network libraries. Neural network

Table 1: A summary of the features possessed by existing Gaussian process libraries at the time of writing. OO stands for object-oriented. In the GPU column GPLVM denotes Gaussian process latent variable model and SVI is Stochastic variational inference. N\R denotes not reported.

software has made working with neural networks easier by using automatic differentiation to reduce the coding overhead for a user. Of the available libraries we use TensorFlow (Abadi et al., 2015), as discussed in the next section.

4. Contributing GP requirements to TensorFlow

In TensorFlow (Abadi et al., 2015) a computation is described as a directed graph where the nodes represent Operations (Ops for short) and the edges represent Tensors. As a directed edge, a Tensor represents the flow of some data between computations. Ops are recognisable mathematical functions such as addition, multiplication etc. Kernels (in an unfortunate collision in terminology with the Gaussian process literature) are implementations of a given Op on a specific device such as a CPU or GPU. Like almost all modern neural network software, TensorFlow comes with the ability to automatically compute the gradient of an objective function with respect to some parameters. The TensorFlow open source implementation comes with a wealth of GPU kernels for the majority of Ops.

Although we gained significantly from using TensorFlow within GPflow, there were some capabilities that were not yet present in the software which were required for our purposes. We therefore added this functionality to TensorFlow. Gaussian process software needs the ability to solve systems of linear equations using common linear algebra algorithms. The differentiation of computational graphs that used the Cholesky decomposition required a new Op, which we contributed with the help of Rasmus Munk Larsen, who reviewed the code. The main part of the code was a C++ implementation of the blocked Cholesky algorithm proposed by Murray (2016). We also contributed code that enabled GPU solving of matrix triangular systems, which in some cases is the bottleneck for approximate inference.

5. Details of GPflow

GPflow supports exact inference where possible, as well as a variety of approximation methods. One source of intractability is non-Gaussian likelihoods, so it is helpful to categorize the available likelihood functionality on this basis. Another major source of intractability is the adverse scaling of GP methods with the number of data points. To this end we support ‘variationally sparse’ methods which ensure that the approximation is scalable and close

Table 2: A table showing the inference classes in GPflow. Relevant references are VGP (Opper and Archambeau, 2009), SGPR (Titsias, 2009), SVGP (Hensman et al., 2013, 2015b) and SGPMC (Hensman et al., 2015a).

in a Kullback-Leibler sense to the posterior (Matthews et al., 2016). Whether or not a given inference method uses variational sparsity is another useful way to categorize it. The inference options, which are implemented as classes in GPflow, are summarized in Table 2. Note that all the MCMC based inference methods support a Bayesian prior on the hyperparameters, whereas all other methods assume a point estimate. Our main MCMC method is Hamiltonian Monte Carlo (HMC) (Neal, 2010).

We now discuss some architectural considerations. The whole Python component of GPflow is intrinsically objected-oriented. The code for the various inference methods in Table 2 is structured in a class hierarchy, where common code is pulled out into a shared base class. The object-oriented paradigm, whilst very natural for the Python layer of the code, has a different emphasis to that of a computational graph which is arguably closer to a functional concept. The largely functional computational graph, and a object-oriented interface need to live cleanly together in GPflow. This is achieved through the Param class that allows parameters to be both properties of an object that can be manipulated as such and Variables in a TensorFlow graph that can be optimized.

A number of steps have been taken to ensure project quality and usability. All GPflow source code is openly available on GitHub at http://github.com/GPflow/GPflow. The web page uses continuous integration to run an automated test suite. The test code coverage for GPflow is higher than similar packages where the code coverage statistics are published, achieving a level of 99% (Table 1). A user manual can be found at http: //gpflow.readthedocs.io.

6. Timed experiments

As a scenario, we studied training a multiclass GP classifier on MNIST using stochastic variational inference (Hensman et al., 2015b,a) . We compared against GPy. None of the other libraries discussed support this algorithm. Functionally, the algorithms are nearly identical in GPflow and GPy. We did a series of trials measuring the time each package took to perform 50 iterations of the algorithm. The trials included a set of CPU experiments, where we varied the number of threads available to the two packages. For GPflow, we also measured the effect of adding a GPU on top of the maximal number of CPU threads considered. GPy does not presently have a GPU implementation of this algorithm. We

1 2 3 4 5 6 0

Figure 1: A comparison of iterations of stochastic variational inference per second on the MNIST dataset for GPflow and GPy. Error bars shown represent one standard deviation computed from five repeats of the experiment.

used a Linux workstation Intel Core I7-4930K CPU clocked at 3.40GHz an NVIDIA GM200 Geforce GTX Titan X GPU.

The results of the timing experiments are shown in Figure 1. For the CPU experiments, the speeds for GPflow and GPy are similar. It can be seen that the increase in speed from adding a GPU is considerable. These gains could make a significant difference to the work flow of a researcher on this topic. Based on the measurements we have made, training using GPflow with 6 CPU threads would take approximately 41 hours or just under 2 days. Adding a GPU would currently reduce the training time to about 5 hours.

7. Acknowledgements

We acknowledge contributions from Valentine Svensson, Dan Marthaler, David J. Harris, Rasmus Munk Larsen and Eugene Brevdo. Alexander G. de G. Matthews was supported by EPSRC grants EP/I036575/1 and EP/N014162/1. James Hensman was supported by an MRC fellowship.

References

Mart´ın Abadi, Ashish Agarwal, Paul Barham, Eugene Brevdo, Zhifeng Chen, Craig Citro, Greg S. Corrado, Andy Davis, Jeffrey Dean, Matthieu Devin, Sanjay Ghemawat, Ian Goodfellow, Andrew Harp, Geoffrey Irving, Michael Isard, Yangqing Jia, Rafal Jozefowicz, Lukasz Kaiser, Manjunath Kudlur, Josh Levenberg, Dan Man´e, Rajat Monga, Sherry Moore, Derek Murray, Chris Olah, Mike Schuster, Jonathon Shlens, Benoit Steiner, Ilya Sutskever, Kunal Talwar, Paul Tucker, Vincent Vanhoucke, Vijay Vasudevan, Fernanda Vi´egas, Oriol Vinyals, Pete Warden, Martin Wattenberg, Martin Wicke, Yuan Yu, and Xiaoqiang Zheng. TensorFlow: Large-scale machine learning on heterogeneous systems, 2015.

Zhenwen Dai, Andreas Damianou, James Hensman, and Neil Lawrence. Gaussian process models with parallelization and GPU acceleration. arXiv preprint 1410.4984, 2014.

GPy. GPy: A Gaussian process framework in Python. http://github.com/SheffieldML/ GPy, since 2012.

James Hensman, Nicolo Fusi, and Neil D Lawrence. Gaussian processes for Big Data. In UAI, July 2013.

James Hensman, Alexander G. de G. Matthews, Maurizio Filippone, and Zoubin Ghahra- mani. MCMC for variationally Sparse Gaussian Processes. In NIPS, December 2015a.

James Hensman, Alexander G. de G. Matthews, and Zoubin Ghahramani. Scalable Varia- tional Gaussian Process Classification. In AISTATS, May 2015b.

Alexander G. de G. Matthews, James Hensman, Richard E. Turner, and Zoubin Ghahra- mani. On Sparse variational methods and the Kullback-Leibler divergence between stochastic processes. In AISTATS, May 2016.

I. Murray. Differentiation of the Cholesky decomposition. arXiv preprint 1602.07527, February 2016.

Radford M. Neal. MCMC using Hamiltonian dynamics. Handbook of Markov Chain Monte Carlo, pages 113–162, 2010.

Manfred Opper and C´edric Archambeau. The variational Gaussian approximation revisited. Neural Computation, 21(3):786–792, 2009.

C. E. Rasmussen and H. Nickisch. Gaussian Processes for machine learning (GPML) tool- box. Journal of Machine Learning Research, 11:3011–3015, 11 2010.

Michalis K. Titsias. Variational learning of inducing variables in sparse Gaussian processes. In AISTATS, April 2009.

Jarno Vanhatalo, Jaakko Riihim¨aki, Jouni Hartikainen, Pasi Jyl¨anki, Ville Tolvanen, and Aki Vehtari. GPstuff: Bayesian modeling with Gaussian processes. Journal of Machine Learning Research, 14(1):1175–1179, 2013.

Designed for Accessibility and to further Open Science