SMT (Surrogate Modeling Toolbox): A Derivative-First Python Library for Surrogate Models

The gap SMT fills: derivatives as a deliverable, not a byproduct

Most Python regression libraries return a prediction and stop. SMT's README states the project is different from existing surrogate modeling libraries because of its emphasis on derivatives, and it names three kinds: training derivatives used for gradient-enhanced modeling, prediction derivatives, and derivatives with respect to the training data. That third kind is the unusual one. A prediction derivative tells you how the surrogate output moves when an input moves. A derivative with respect to training data tells you how the fitted surface moves when a training sample moves, which is what you need for sensitivity analysis, for data selection, or for coupling the surrogate into an outer optimization loop that also treats the sampled points as design variables. The audience is therefore narrower than "anyone doing machine learning". It is the aerodynamicist, the structural engineer, the multidisciplinary design optimization practitioner: someone whose surrounding code already computes gradients and who will lose that information if the surrogate cannot supply them. The README's associated publications point the same way, covering gradient-enhanced kriging, gradient-enhanced neural networks for airfoil shape design, and multi-fidelity co-kriging for aerodynamics.

What is actually in the box: models, sampling, benchmarks

SMT is described as containing a collection of surrogate modeling methods, sampling techniques, and benchmarking functions. The three parts serve different moments in a workflow. Sampling techniques generate the design of experiments that the surrogate will be trained on. The surrogate models are the fitted approximations themselves. The benchmarking functions give you analytic test problems where the true function and its gradient are known, so you can check whether a model recovers both before pointing it at an expensive simulator. Two models are called out in the README as not available elsewhere: kriging by partial-least-squares reduction, and energy-minimizing spline interpolation. The first is a dimensionality-reduction route for kriging hyperparameter estimation, and the README's publication list includes a 2016 paper on estimating kriging hyperparameters for high-dimensional problems through the partial least squares method. The second is a spline interpolation scheme whose construction is framed as an energy minimization. The SMT 2.0 paper title, quoted in the README, says the release has a focus on hierarchical and mixed variables Gaussian processes, so if your design space mixes continuous variables with categorical or ordered-discrete ones, that is the part of the library the maintainers highlight. Mixture-of-experts is listed among the repository topics and appears in the publication list as a 2011 paper on mixture of experts based on EM joint estimation.

Installation and the first call: what the README gives you

The dependency list is short and conventional: numpy, scipy, scikit-learn, pydoe and Cython. Cython is the one that changes your setup story, because it implies compiled extensions. The README does not spell out which models need a compiler at install time, so treat that as unverified and check on a clean environment before you plan a deployment. Installation for the latest release is a single command, pip install smt. To track the master branch instead, the README gives pip install git+https://github.com/SMTorg/smt.git@master. For usage, the README points to the tutorial notebooks under the tutorial directory and to the smt/examples folder rather than inlining a code sample, so the first working snippet you write will come from those notebooks. The documentation lives at smt.readthedocs.io, with a stable and a latest build. The README also notes that SMT is documented using custom tools that embed automatically-tested code and dynamically-generated plots, which means the user guides are executed as part of the build rather than written by hand. That matters when you are deciding whether to trust an example: a code block in the guide has been run to produce the plot next to it.

The cost of a compiled dependency and a fast release cadence

The release history shows v2.15.0 on 2026-09-08, v2.14.1 on 2026-06-22 and v2.14.0 on 2026-05-11. That is roughly a minor release every two months with patch releases in between, and the last push to the default branch is timestamped the same day as v2.15.0. For a library you embed in a validated engineering process, that cadence is a maintenance obligation: you should pin a version and read the release notes before moving, because a minor bump in a two-month cycle can carry API changes. The BSD-3-Clause licence is permissive. It allows use in closed-source products and modification, subject to the conditions in the licence text, which typically include retaining the copyright notice and disclaimer. That is a statement about what the licence permits, not legal advice; if SMT ends up inside a distributed product, have your own counsel read the licence file in the repository rather than this paragraph. The project is not archived, and the README carries badges for tests, coverage, documentation and Ruff, which tells you linting and test runs are wired into the repository's workflow. It does not tell you how much of the code those tests cover.

Where SMT is the wrong tool

The derivative emphasis is a contract, and contracts cost something. If your problem has no usable gradients, if your simulator is a black box you can only call, or if you are fitting tabular data where nobody will ever ask for a Jacobian, you are paying for machinery you will not use. The README's own framing makes this explicit: the differentiator is derivatives, so a user who does not need them is choosing SMT for its model list alone, and that is a weaker reason. The second limitation is scale. The publication list includes work on sparse Gaussian processes for aerodynamic modeling and on sparse co-kriging for multi-fidelity data fusion, which suggests the maintainers are aware that dense Gaussian process training does not scale to large sample sets. That is a signal about where the library's own research effort has gone, not a benchmark, and the README does not state a sample-size ceiling for any model. The third limitation is documentation shape. The README delegates usage to notebooks and an examples folder. That is fine for exploration and awkward for reference: if you need to know the exact signature of a prediction derivative for one specific model, you will be reading the API documentation or the source, not the README. Anyone expecting a single prose manual that covers every model uniformly will be disappointed.

SMT against scikit-learn Gaussian processes

The obvious alternative is scikit-learn, which SMT already depends on. scikit-learn's GaussianProcessRegressor gives you a fitted posterior and a predict method that can return a standard deviation alongside the mean. What it does not give you, as a general contract across its regressors, is the derivative of the prediction with respect to the input, nor the derivative with respect to the training targets. You can derive those analytically for a kernel, and people do, but you write that code yourself and you own it. SMT's stated purpose is to make those derivatives part of the library's surface, including gradient-enhanced training, where observed gradients are fed into the fit rather than only queried afterwards. The second difference is scope. scikit-learn is a general machine learning library where regression is one chapter among many; SMT is a surrogate modeling library where sampling, models and analytic benchmark functions sit next to each other so that a design-of-experiments to surrogate to gradient-check loop stays in one package. The third difference is the model roster: partial-least-squares kriging and energy-minimizing spline interpolation are named in the README as not available elsewhere, so a scikit-learn-only stack cannot reproduce them without reimplementation. If you already run scikit-learn, SMT is additive rather than a replacement, and the shared dependency on numpy and scipy keeps the environment cost low.

Who should adopt it, and what to check first

Adopt SMT when the surrounding workflow consumes gradients and you want the surrogate to speak the same language: gradient-enhanced kriging, a neural surrogate whose Jacobian feeds an optimizer, or a multi-fidelity setup where co-kriging fuses a cheap model with an expensive one. Adopt it when your design space is mixed or hierarchical, since the SMT 2.0 paper title names that as a focus of the release. Do not adopt it when a plain regressor suffices, when you cannot compile Cython extensions, or when you need a single uniform prose manual covering every model. Before you commit, do three concrete things. Open the tutorial notebooks in the repository's tutorial directory and find the model closest to your problem, so you can see the call signature before you design around it. Confirm which version pip resolves to and pin it, given the roughly two-month minor release cadence visible in the tags. And check the licence file in the repository against your distribution plan, since BSD-3-Clause permits commercial use but carries notice and disclaimer conditions that your own counsel should read.

Editorial conclusion

Adopt SMT if your surrogate has to hand back derivatives (gradient-enhanced training, prediction Jacobians, or sensitivities with respect to training data) and you work in Python with numpy, scipy and scikit-learn already installed. Do not adopt it if you only need a plain regressor with no gradient contract, or if you cannot install Cython and a compiler, since the README lists Cython among the required packages. Before committing, verify three things on your own data: that the specific model you plan to use appears in the tutorial notebooks or the examples folder, that pip install smt resolves to v2.15.0 or later, and that your prediction derivative needs match what the chosen model's documentation states it returns.

Official sources

1. License: BSD-3-Clause
2. Project website
3. README
4. Releases
5. SMTorg/smt on GitHub