Qiskit Machine Learning: Quantum Kernels and QNNs Behind a scikit-learn-Style API
An open-source library built on Qiskit for quantum machine learning tasks at scale on quantum hardware and classical simulators
At a glance
- What is it?
- Qiskit Machine Learning packages quantum kernels, EstimatorQNN and SamplerQNN primitives, and a PyTorch connector into one Apache-2.0 library. It is a research and prototyping layer, not a drop-in replacement for classical scikit-learn pipelines.
- Who is it for?
- Adopt qiskit-machine-learning if you are prototyping quantum kernels or variational circuits and want to compare them against classical baselines inside a Python workflow you already understand. Skip it if you need production inference on tabular data today, or if your team has no Qiskit primitives experience, because the EstimatorQNN and SamplerQNN abstractions assume you can reason about circuits, observables and shot noise.
- 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 27 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
The gap Qiskit Machine Learning fills between circuits and scikit-learn
Most quantum computing toolkits stop at gates, circuits and transpilation. Getting from a circuit to something that behaves like a classifier means writing your own training loop, your own gradient computation and your own batching logic. Qiskit Machine Learning exists to remove that scaffolding. The README states it introduces "fundamental computational building blocks, such as Quantum Kernels and Quantum Neural Networks, used in various applications including classification and regression." That is the whole pitch: the library is the layer where quantum circuits acquire the shape of machine learning models.
The audience is narrower than the description suggests. The stated goal is to let users "quickly and easily prototype quantum machine learning models without the need of extensive quantum computing knowledge." Read that as a prototyping claim, not a production one. Nothing in the material describes deployment tooling, model serving, or latency guarantees. If you are a data scientist who wants to test whether a quantum kernel beats an RBF kernel on a small dataset, this library is aimed at you. If you are building a recommendation system, it is not.
Two modelling paths: kernel matrices and parametrized circuits
The library splits into two distinct approaches, and they do not share much machinery.
The first is kernel-based. FidelityQuantumKernel uses the Fidelity algorithm to compute kernel matrices for datasets. That matrix is then handed to a Quantum Support Vector Classifier (QSVC) or Quantum Support Vector Regressor (QSVR). The README also notes the kernel is "compatible with classical kernel-based machine learning algorithms," which is the more interesting detail: you can generate the kernel with quantum hardware or a simulator and feed it into a classical SVM rather than using the bundled QSVC. That keeps the quantum part isolated and testable.
The second path is neural. Qiskit Machine Learning defines a generic neural network interface with two implementations. EstimatorQNN combines parametrized quantum circuits with quantum mechanical observables, and its output is the expected value of the observable. SamplerQNN translates bit-string counts into outputs. Both sit on top of Qiskit primitives, the Estimator and Sampler interfaces respectively. Higher-level classes, NeuralNetworkClassifier and NeuralNetworkRegressor, wrap these for training. Sitting above those, VQC and VQR take a feature map and an ansatz and build the underlying QNN automatically. That layering matters: you can drop to the primitive level when you need control, or stay at the VQC level when you do not.
The TorchConnector and where gradients actually come from
The PyTorch integration is the feature most likely to decide adoption. TorchConnector embeds a QNN inside a PyTorch module. The README claims that "thanks to the gradient algorithms in Qiskit Machine Learning, this includes automatic differentiation," and that gradients computed by PyTorch during backpropagation account for the quantum neural networks too.
The mechanism is worth being precise about. PyTorch does not differentiate through the quantum circuit in the way it differentiates through a dense layer. The library supplies gradient algorithms for the QNN, and TorchConnector wires those into the surrounding autograd graph. In practice this means a hybrid model where classical layers and a quantum circuit train together. The README also says the design "allows the building of connectors to other packages or accelerated libraries," which is a forward-looking statement about extensibility rather than a shipped feature. Do not read it as a list of existing integrations.
The practical consequence is that your quantum layer participates in the same optimizer, learning rate schedule and loss function as the rest of the network. That is the real value, and it is also where debugging gets harder, because a failure in the quantum layer surfaces as a bad gradient in a classical training loop.
Installing it and what the API expects from you
Installation is a single command:
pip install qiskit-machine-learning
The README says pip will install all dependencies automatically. The library is pure Python and targets the Qiskit SDK, so the version constraint that matters is the Qiskit release it pins against. The README links to Qiskit 1.4 API documentation for the Estimator and Sampler base classes, which is the clearest signal about the expected Qiskit generation.
There is no config file, no environment variable and no CLI. Everything happens in Python. A kernel workflow means constructing FidelityQuantumKernel, calling it to produce a matrix, and passing that to QSVC or a classical SVM. A neural workflow means choosing EstimatorQNN or SamplerQNN, or letting VQC and VQR assemble one from a feature map and an ansatz. If you want PyTorch, you wrap the QNN in TorchConnector and then use ordinary PyTorch training code.
The absence of a config surface is a deliberate simplification, but it also means reproducibility depends entirely on your own code and on pinning the Qiskit and qiskit-machine-learning versions together. Nothing in the library records which backend, which primitive implementation or which transpilation settings produced a given kernel matrix.
Where the abstraction leaks: shots, simulators and dataset size
The README describes running "at scale on quantum hardware and classical simulators," but the material does not quantify what scale means, and it does not report benchmark numbers. Treat the scale claim as unverified.
The structural limitation is more concrete. EstimatorQNN outputs an expected value, and SamplerQNN outputs a distribution derived from bit-string counts. Both are estimated from finite samples, whether on hardware or a simulator. Kernel methods have the same property: FidelityQuantumKernel computes fidelities, and each entry in the kernel matrix is an estimate. A kernel matrix for n samples requires on the order of n squared fidelity evaluations. That cost grows quickly, and the README gives no guidance on dataset sizes that remain practical.
The second leak is conceptual. The library is described as usable "without the need of extensive quantum computing knowledge," but choosing between EstimatorQNN and SamplerQNN, or picking a feature map and an ansatz for VQC, requires knowing what an observable is and how measurement affects output. The high-level syntax hides circuit construction, not the modelling decisions. If your team cannot explain why one ansatz is preferable to another, the convenience API will produce results you cannot interpret.
How it compares with PennyLane's approach
The most direct alternative in this space is PennyLane. The difference is architectural rather than feature-by-feature.
PennyLane is built around differentiable quantum programming from the ground up, with its own interface to autograd, PyTorch, TensorFlow and JAX, and a device model that abstracts hardware and simulators behind a single plugin interface. Qiskit Machine Learning takes the opposite route: it sits on top of the Qiskit SDK and its primitives, and reaches classical frameworks through a connector. TorchConnector is a bridge, not the foundation.
That has a practical consequence. If you already run Qiskit for circuit construction, transpilation and execution, qiskit-machine-learning keeps everything in one ecosystem and one dependency tree. If you are starting from a classical deep learning codebase and want quantum layers to feel native, PennyLane's design assumes less about your quantum stack. The trade-off is ecosystem lock-in in both directions. Switching later means rewriting the quantum layer, not just changing an import.
A second, less obvious alternative is to skip quantum machine learning libraries entirely and use FidelityQuantumKernel's output with a classical SVM. The README explicitly supports this. For many teams it is the lowest-risk way to test whether quantum kernels help at all, because the training and evaluation code is already familiar.
Maintenance, versioning and the Apache-2.0 terms
The project is active and not archived. Recent releases listed are 0.9.1 (2026-08-19), 0.9.0 (2025-12-24) and 0.8.4 (2025-09-12). The cadence looks like a minor release roughly every few months with patch releases in between. The 0.x version number is the honest signal here: the API is not declared stable, and the README notes that co-maintenance by IBM and the Hartree Centre began at version 0.7, so governance changed partway through the project's life.
Upgrade cost is the real maintenance burden. Because the library depends on Qiskit primitives, a Qiskit release that changes the Estimator or Sampler interface can force a coordinated upgrade. There is no compatibility shim described in the material. Budget for reading release notes before bumping either package, and pin both in your requirements file.
The licence is Apache-2.0. That is a permissive licence with an explicit patent grant, which matters for a library that may touch patented quantum methods. It permits commercial use and modification provided you retain the notices. This is a description of the licence text, not legal advice; if you are shipping a product, have your own counsel review the patent clause and any third-party dependencies pulled in by pip.
Editorial conclusion
Adopt qiskit-machine-learning if you are prototyping quantum kernels or variational circuits and want to compare them against classical baselines inside a Python workflow you already understand. Skip it if you need production inference on tabular data today, or if your team has no Qiskit primitives experience, because the EstimatorQNN and SamplerQNN abstractions assume you can reason about circuits, observables and shot noise. Before committing, verify three things: that the current release is 0.9.1, that the Qiskit version it pins matches the one your stack runs, and that the arXiv paper 2505.17756 describes the specific kernel or QNN variant you intend to use.
Community notes