sbi: Neural Posterior Estimation When Your Simulator Has No Likelihood

The Likelihood-Free Problem sbi Actually Solves

Most Bayesian workflows assume you can write down p(x | theta), the probability of your data given parameters. For a large class of scientific simulators you cannot. You have code that takes parameters and produces synthetic observations, often with internal randomness, and nothing more. The README frames the target directly: given a simulator that models a real-world process, sbi estimates the full posterior distribution over the simulator's parameters based on observed data, and that distribution also quantifies uncertainty and can reveal interactions between parameters. The intended users are named in the first sentence: researchers who want control and practitioners who want a working interface. That split shows up in the API, which offers low-level interfaces for fine-tuning and high-level interfaces for quick implementation. If your model is a differential equation solver, an agent-based simulation, or a neural simulator of a biological system, and you can sample parameters from a prior and run the simulator, you are the target audience. If you have a closed-form likelihood, you are not.

How the Inference Loop Works

The mechanism is density estimation on simulated pairs. You draw parameters theta from a prior, run the simulator to get corresponding observations x, and train a neural network on those pairs. The README's example is four lines: construct NPE with a prior, call append_simulations(theta, x).train(), then build_posterior(). The trained network represents the posterior, and sampling from it does not require the likelihood. The README divides the implemented algorithms into two families. Amortized methods let you reuse a posterior estimator across multiple observations without retraining, which is the payoff when you expect many datasets from the same generative process. Sequential methods focus on individual observations and try to optimize the number of simulations required, typically by proposing new parameters in regions that look promising for the observation at hand. The named implementations include NPE_A, NPE_B, NPE_C (also called APT), TSNPE, and FMPE, each tied to a specific paper listed in the README. Beyond inference, the package ships validation tools and plotting and analysis functions, which matters because a posterior from a neural density estimator is not self-certifying.

Installation, Optional Samplers and a Smoke Test

The README states Python 3.10 or higher is required and that a GPU is not necessary but can improve performance in some cases. The recommended install path is uv: uv pip install sbi. Pyro and PyMC MCMC samplers are optional extras, installed as uv pip install "sbi[pyro]" for HMC and NUTS via Pyro, uv pip install "sbi[pymc]" for HMC, NUTS and Slice via PyMC, or uv pip install "sbi[all]" for both. Those extras matter if you want to sample the learned posterior with a proper MCMC kernel rather than the default sampling path the library provides. The README's own installation test is worth running before anything else: from sbi.examples.minimal import simple, then posterior = simple() and print(posterior). If that fails, the problem is your environment, not your model. For conda, pixi and plain pip, the README points to the full installation guide rather than listing commands, so treat the uv lines as the canonical example and check the docs for the rest. The repository also offers a Codespace route: open the green Code button on GitHub and select Open with Codespaces to get a Jupyter environment with the tutorials.

Where the Method Breaks Down

The central limitation is stated by the method itself, not by the README: the posterior you get is the posterior implied by the network and the simulations you fed it. If your prior puts little mass where the true parameters live, or your simulator is misspecified, the network will still return a confident-looking distribution. The README addresses this partly by shipping validation tools and by pointing to Deistler et al. (2025), Simulation-based inference: A practical guide, which the README says covers diagnostics for every stage from setting up the simulator and prior to validating results. That pointer is a signal about where failures happen. Sequential methods also carry a subtler risk: because they concentrate simulations on one observation, a poorly calibrated proposal can starve the estimator of coverage elsewhere, which is why the README separately lists amortized methods as reusable across observations. Cost is the other boundary. Every method here consumes simulator runs, and the sequential family exists precisely because simulation count is the binding constraint. If a single simulator call takes minutes, the budget conversation happens before the modeling conversation. And if your likelihood is tractable, this whole apparatus is the wrong tool: you would be replacing a correct integral with an approximation you then have to validate.

sbi Versus Approximate Bayesian Computation

The obvious alternative for likelihood-free inference is approximate Bayesian computation, which compares simulated data to observed data through summary statistics and a tolerance, accepting parameters when the distance falls below that threshold. ABC is simpler to reason about and needs no training, but its output is an approximation controlled by the tolerance, and in high-dimensional observation spaces the acceptance rate collapses unless you hand-craft good summaries. sbi takes the opposite route: instead of rejecting simulations, it learns a conditional density from all of them. That means it uses every simulation rather than discarding most, and it can work with raw high-dimensional observations because the neural network learns the summary representation instead of you specifying it. The trade is that you now depend on optimization, architecture choices and training diagnostics, and the correctness argument moves from a tolerance parameter to a validation procedure. ABC gives you a knob you can tighten. sbi gives you a model you have to check.

Licence, Releases and Maintenance Surface

sbi is Apache-2.0 licensed, which permits commercial and academic use with the usual attribution and notice conditions; the repository ships a LICENSE.txt at the root. It is a NumFOCUS affiliated project and has a JOSS paper (DOI 10.21105/joss.07754), both of which indicate an intended long-lived project rather than a one-off research dump. The release cadence visible in the material is roughly monthly to quarterly: v0.26.0 in April 2026, v0.26.1 a week later, v0.27.0 in August 2026, with the last push to main in September 2026. The 0.x versioning is the maintenance fact that matters most for adopters. Minor releases can change APIs, and the algorithm surface is large enough (NPE_A, NPE_B, NPE_C, TSNPE, FMPE and their sequential variants) that pinning a version in your environment and reading the release notes before upgrading is the practical posture. The optional Pyro and PyMC extras add their own version constraints on top of the core PyTorch dependency, so an environment that pins sbi loosely can break through a sampler backend rather than through sbi itself.

Who Should Adopt It, and What to Check First

Adopt sbi when the simulator is the only thing you have, when you can afford thousands of runs, and when you either expect many observations from the same model (amortized NPE) or need to be economical per observation (sequential methods). Do not adopt it as a general Bayesian inference library, and do not adopt it if your simulator is so expensive that the simulation budget is the whole project. The first thing to verify is the minimal example from the README, since it exercises the install and the default path in one call. The second is the validation tooling: the package ships it, the README advertises it, and the Deistler et al. guide the README cites is the reference for using it. The third is your version pin, given the 0.x release history. The honest summary is that sbi removes the likelihood requirement and replaces it with a training and validation requirement. Whether that trade is good depends entirely on how expensive your simulator is and how much you trust your own diagnostics.

Editorial conclusion

Adopt sbi if you already have a working simulator, a prior you can sample from, and no tractable likelihood, and if you are willing to spend compute on simulations rather than on an analytic derivation. Avoid it if your likelihood is available, if your simulator is slow enough that a few thousand runs is already a budget problem, or if you need a posterior whose correctness does not depend on a neural network you have to validate yourself. Before committing, run the minimal example from the README, then check the validation tutorial and the diagnostics in the Deistler et al. practical guide against your own simulator, because the package will happily return a posterior from a network that was never trained well enough.

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. sbi-dev/sbi on GitHub