fast-vollib: High-Performance Option Pricing

• fast-vollib is an open-source Python library that offers European option pricing, implied volatility inversion, and Greeks computation using familiar py_vollib interfaces.
• It employs a vectorized Halley iteration with bisection fallback and an experimental LBR algorithm for robust and efficient implied volatility inversions.
• The library supports diverse backends including NumPy, PyTorch, and JAX, enabling GPU acceleration and integration into modern quantitative and differentiable pipelines.

Fast-vollib is an open-source Python library for European option pricing, implied-volatility inversion, and Greeks under the Black-76, Black-Scholes, and Black-Scholes-Merton models. It is presented as a high-performance, compatibility-first, drop-in alternative to the widely used py_vollib and py_vollib_vectorized packages, while adding vectorization, GPU acceleration, and pluggable execution backends based on NumPy, PyTorch, JAX, and an experimental Triton/CUDA fused-kernel path for batched implied-volatility workloads (Saqur, 29 Apr 2026). Its design centers on preserving familiar naming and input conventions while adapting the computational core to modern batched and differentiable pipelines.

1. Definition, scope, and motivation

Fast-vollib provides pricing, Greeks, and implied-volatility computation for European options under three canonical models: Black-76, Black-Scholes, and Black-Scholes-Merton. The stated motivation is not to alter the basic quantitative interface established by py_vollib, but to support workloads that require vectorized operations over entire option chains, GPU execution, differentiable pipelines, and broad backend support across NumPy, PyTorch, and JAX (Saqur, 29 Apr 2026).

The library is explicitly designed as a drop-in alternative. Its public API mirrors py_vollib naming and input conventions; option flags use "c" and "p", inputs broadcast like NumPy arrays, and outputs can be shaped into common containers including DataFrame, Series, ndarray, dict, and JSON. Compatibility is also operationalized through patch_py_vollib() and patch_py_vollib_vectorized(), which monkey-patch upstream namespaces so that existing code can dispatch to fast-vollib without source-level rewrites (Saqur, 29 Apr 2026).

The workload model emphasized by the package is contemporary quantitative computing rather than single-contract scalar evaluation. The paper identifies three principal pressures motivating the implementation: vectorized operations over large chains, GPU acceleration for high-throughput inversion, and composability with autodiff-oriented stacks used in deep hedging, calibration, and neural implied-volatility surfaces (Saqur, 29 Apr 2026). This suggests that fast-vollib is best understood not merely as a pricing utility, but as an interoperability layer between legacy quantitative APIs and tensor-native numerical runtimes.

2. Supported models and analytical quantities

Fast-vollib exposes three European pricing models. In Black-Scholes-Merton, with spot $S$, strike $K$, maturity $T$, risk-free rate $r$, continuous dividend yield $q$, and volatility $\sigma$, the quantities

$$d_1 = \frac{\ln(S/K) + (r - q + \tfrac{1}{2}\sigma^2)T}{\sigma\sqrt{T}}, \quad d_2 = d_1 - \sigma\sqrt{T}$$

define the call and put prices

$C = S\,e^{-qT}\,N(d_1) - K\,e^{-rT}\,N(d_2),$

$P = K\,e^{-rT}\,N(-d_2) - S\,e^{-qT}\,N(-d_1).$

Black-Scholes is obtained by setting $q=0$. Black-76 instead uses the forward price $K$0, with

$K$1

and discounted forward-form call and put prices

$K$2

(Saqur, 29 Apr 2026).

The library also provides vectorized Delta, Gamma, Vega, Theta, and Rho. For Black-Scholes-Merton with dividends, the documented expressions include

$K$3

$K$4

and model-consistent expressions for Theta and Rho (Saqur, 29 Apr 2026). Under Black-76, the Greeks are taken with respect to the forward $K$5, not the spot $K$6; for example,

$K$7

$K$8

(Saqur, 29 Apr 2026).

A notable implementation feature is get_all_greeks, which computes all five Greeks in one pass to avoid redundant $K$9 evaluation. In a batched environment this is significant because the dominant cost is often not arithmetic complexity per se, but repeated tensor materialization and redundant traversal of large arrays. The design therefore aligns the analytical formulas with a fused evaluation pattern.

3. Implied-volatility inversion methods

Implied volatility is defined as the unique $T$0 such that model price equals observed market price, for example $T$1 under Black-Scholes-Merton or $T$2 under Black-76. Fast-vollib’s default inversion method is a fully vectorized Halley iteration with bisection fallback. If

$T$3

the update is

$T$4

(Saqur, 29 Apr 2026).

The implementation uses elementwise array operations so that fusion can occur under torch.compile and jax.jit. A Brenner-Subrahmanyam-type initial guess is used, and if the update exits guardrails, becomes negative, becomes extremely large, or oscillates, the solver falls back to a bracketing or bisection routine intended to guarantee convergence. The paper explicitly identifies deep in-the-money and out-of-the-money strikes, near-expiry $T$5, and very small or very large volatilities as edge cases requiring guardrails, clipping, and fallback bracketing for numerical stability on the wings (Saqur, 29 Apr 2026).

In addition to the Halley solver, fast-vollib includes an experimental, fully vectorized implementation of Jäckel’s “Let’s Be Rational” (LBR) algorithm. The rationale given is robustness: LBR operates in a normalized Black coordinate system, uses a four-region rational initial guess, and refines the solution with Householder(3), typically reaching machine precision in about two iterations even in wing cases where Newton or Halley can lose accuracy (Saqur, 29 Apr 2026). Fast-vollib reimplements this in several backend-specific forms:

• NumPy + Numba: jackel_iv_black
• PyTorch + torch.compile: jackel_iv_black_torch
• JAX + jax.jit: jackel_iv_black_jax
• Triton single-pass GPU kernel: jackel_iv_triton (Saqur, 29 Apr 2026)

The Triton contribution is described as a single-pass fused GPU kernel in which the entire LBR pipeline—normalization, rational initial guess, and Householder refinement—is executed in one kernel, with intermediate state retained in registers rather than written to global memory. The stated consequence is fewer kernel launches and reduced memory traffic for large batched implied-volatility inversions (Saqur, 29 Apr 2026).

A related 2026 paper, “Imp​lying Volatility: How Fast Can We Go?” (Floc'h et al., 27 May 2026), is not part of fast-vollib itself, but it explicitly discusses integration with vollib/fast-vollib. That work proposes FlashIV, a low-latency Black-Scholes implied-volatility solver based on out-of-the-money normalization, an erfcx/log-price residual, a Li/asymptotic seed, and fixed-count Householder-3 refinement. It further recommends that a fast implied-volatility library may replace LBR inversion with FlashIV, optionally adding a final Jäckel–Newton correction when strict alignment with an LBR-like reference pricer is required (Floc'h et al., 27 May 2026). This suggests a plausible future extension path for fast-vollib’s inversion subsystem, although the fast-vollib paper itself does not claim such an integration.

4. Execution backends and computational architecture

The backend architecture is organized around a unified dispatch layer with implementations in backends/numpy.py, backends/torch.py, and backends/jax.py, each exposing a shared interface for pricing, Greeks, and implied volatility. Backend selection can be made with set_backend("numpy" | "torch" | "jax" | "auto"), queried with get_backend(), or specified through the FAST_VOLLIB_BACKEND environment variable. The "auto" policy prefers CUDA-capable PyTorch, then JAX, then NumPy (Saqur, 29 Apr 2026).

NumPy is the default CPU path if no accelerator is available. PyTorch supports CPU and GPU execution, and torch.compile can fuse both the Halley and LBR torch variants. JAX supports CPU and GPU execution via jax.jit, compiling vectorized pricing, Greeks, and implied volatility to XLA. Broadcasting follows the semantics of the underlying framework; input acceptance spans scalars, lists, NumPy arrays, and pandas Series, while output shaping is controlled via return_as or return_native (Saqur, 29 Apr 2026).

The architecture is deliberately compatibility-first rather than backend-specific. Public functions retain familiar signatures, while backend-native tensors can still be preserved when needed. This duality is important: it lets existing quantitative code continue using DataFrame-oriented workflows while also supporting tensor-resident execution for compiled or differentiable pipelines.

The paper avoids fixed benchmark tables and makes no universal speedup claims. Runtime is stated to depend on hardware, batch size, precision, and warm-up or JIT state, and the repository instead provides scripts for controlled comparisons against py_vollib and py_vollib_vectorized (Saqur, 29 Apr 2026). The stated performance expectation is therefore qualitative: CPU NumPy is adequate for small arrays, while GPU backends are advantageous on large batches and repetitive workloads, with the Triton kernel being throughput-optimized for massive implied-volatility inversions (Saqur, 29 Apr 2026). A common misconception would be to read fast-vollib as a uniformly faster scalar replacement in all settings; the text instead frames it as a vectorized and backend-adaptive library whose benefits are workload-dependent.

5. API surface, data handling, and usage model

The core API mirrors the established py_vollib family. Pricing functions include fast_black, fast_black_scholes, and fast_black_scholes_merton; implied-volatility entry points include fast_implied_volatility and fast_implied_volatility_black; the experimental LBR family is exposed through the jackel namespace; and Greeks are available through vectorized_delta, vectorized_gamma, vectorized_theta, vectorized_rho, vectorized_vega, and get_all_greeks (Saqur, 29 Apr 2026). A price_dataframe(df, backend="auto", ...) helper computes prices, implied volatilities, and Greeks row-wise over a DataFrame.

The following table summarizes the principal function groups.

Function group	Representative entries	Role
Pricing	fast_black, fast_black_scholes, fast_black_scholes_merton	European option valuation
Implied volatility	fast_implied_volatility, fast_implied_volatility_black	Default Halley-based IV inversion
Experimental LBR	jackel_iv_black, jackel_iv_black_torch, jackel_iv_black_jax, jackel_iv_triton	Vectorized Jäckel-style Black IV inversion
Greeks	vectorized_delta, vectorized_gamma, vectorized_theta, vectorized_rho, vectorized_vega, get_all_greeks	Batched sensitivity computation
Compatibility and backend control	patch_py_vollib(), patch_py_vollib_vectorized(), set_backend(), get_backend()	Drop-in replacement and execution control

Inputs accept scalars, lists, NumPy arrays, and pandas Series. Option flags are encoded as "c" and "p". Broadcasting follows NumPy rules, while dtype semantics are inherited from the selected backend. Outputs default to "dataframe" through return_as, but return_native=True preserves backend-native tensors such as torch.Tensor or jax.Array (Saqur, 29 Apr 2026).

The paper gives concrete usage patterns for NumPy, PyTorch, JAX, and Triton-backed batched inversion. In NumPy, fast_black_scholes prices a small batch, fast_implied_volatility inverts those prices, and get_all_greeks computes the sensitivities in one batched call. In PyTorch, the backend can be switched globally, tensors can be placed on CPU or CUDA devices, and both the default Halley solver and the torch-compiled LBR variant can be applied. In JAX, jax.numpy arrays are supported together with jitted LBR evaluation. For large GPU batches, the paper illustrates a Black-76 example with K = np.linspace(50, 150, 50000) and inversion through jackel_iv_triton (Saqur, 29 Apr 2026).

The package also exposes implied_volatility_autograd when PyTorch is installed. This is significant because it locates fast-vollib within a differentiable-computation workflow rather than a purely imperative pricing toolkit. A plausible implication is that the library is intended to be useful in end-to-end optimization loops where implied volatility is not merely reported but differentiated through.

6. Installation, limitations, and adjacent developments

Fast-vollib is distributed on PyPI and licensed under MIT. Installation variants include the core NumPy package, optional extras for PyTorch and JAX, and combined installs for both. PyTorch with CUDA is required for the Triton LBR kernel. The project documentation identifies GitHub, hosted docs, and PyPI as the canonical distribution points, and versioning is VCS-derived via hatch-vcs, with stable releases tag-driven and development snapshots published to TestPyPI (Saqur, 29 Apr 2026).

The library’s scope is limited to European options under Black-76, Black-Scholes, and Black-Scholes-Merton. American options, exotic derivatives, and stochastic-volatility models are out of scope; the paper explicitly directs such use cases to QuantLib or model-specific libraries. Python $T$6 is required. PyTorch and JAX remain optional dependencies unless their respective backends are needed (Saqur, 29 Apr 2026).

Several numerical caveats are documented. Near-expiry and wing cases are acknowledged as difficult for naïve Newton or Halley iterations; accordingly, the default solver employs guardrails, clipping, and bisection fallback, and LBR is recommended for highly robust inversions on wings. Precision choice is treated as consequential: float64 is recommended for accuracy-sensitive tasks, especially implied volatility and Greeks, while float32 may improve throughput but can lose a digit on extreme strikes. The vectorized LBR implementations—NumPy/Numba, torch.compile, jax.jit, and Triton—are all described as experimental (Saqur, 29 Apr 2026).

A related misconception is that fast-vollib attempts to be a general option-pricing framework. The paper does not support that reading. Its purpose is narrower and more technical: to preserve the familiar py_vollib interface while adding vectorization, backend modularity, and accelerated implied-volatility inversion for modern AI and quantitative workloads. In that sense, its significance lies less in introducing new financial models than in recasting standard Black/BS/BSM analytics into a backend-pluggable computational substrate (Saqur, 29 Apr 2026).

The broader 2026 literature on implied-volatility solvers indicates that this substrate is open to further specialization. FlashIV, for example, presents a low-latency Black-Scholes inversion path based on normalized out-of-the-money coordinates, an erfcx/log-price residual, and fixed-count Householder refinement, and it explicitly describes integration points for vollib/fast-vollib (Floc'h et al., 27 May 2026). This does not change fast-vollib’s documented feature set, but it situates the library within an active line of work on production-grade implied-volatility inversion where normalization, branch-light iteration, and hardware-conscious implementation are treated as first-class design parameters.