microsoft/hummingbird: compiling scikit-learn, LightGBM and XGBoost models into PyTorch, ONNX and TVM
Hummingbird compiles trained ML models into tensor computation for faster inference.
At a glance
- What is it?
- Hummingbird converts trained traditional ML models into tensor computations so they run inside neural network frameworks. It keeps the sklearn-style inference API, and the README documents the tree-to-GEMM rewrite that makes it possible.
- Who is it for?
- Adopt Hummingbird if you already have trained scikit-learn, LightGBM or XGBoost models and want them executing inside PyTorch, TorchScript, ONNX or TVM without rewriting inference code. Do not adopt it if your models fall outside the supported operator list, if you need a documented rollback path, or if you are not prepared to pin onnx, onnxruntime and the skl2onnx family to the ranges setup.py declares.
- Can I use it commercially?
- Yes. MIT 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 1 day 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 problem Hummingbird targets: traditional models stuck outside tensor runtimes
A gradient-boosted tree or a random forest trained in scikit-learn has no natural path into a GPU. It runs on CPU through the library that trained it, and the framework optimizations that accumulate in PyTorch or TVM never reach it. Hummingbird's answer is to compile the trained model into tensor computations, so the same model can execute on the tensor framework and inherit whatever acceleration that framework has.
The README states the goal in four parts: benefit from current and future optimizations in neural network frameworks, get native hardware acceleration, keep one platform for both traditional and neural network models, and do it without re-engineering existing models. That last point is the constraint that shapes the API. Hummingbird does not ask you to retrain or to restructure a pipeline. It takes a fitted estimator and returns an object you call predict on.
The intended user is an engineer who already has a working traditional model and a reason to move its inference onto tensor hardware. If your model is small and CPU latency is fine, the conversion adds a dependency without buying much. The README's own framing is speedups, and the notebooks directory is where those are demonstrated.
How the tree-to-GEMM conversion works, step by step
The README walks through one of the supported strategies: translating a decision tree into tensors using GEMM, generic matrix multiplication. The example tree has four decision nodes and five leaf nodes, and takes a five-element feature vector.
Step 1 multiplies the input tensor by a tensor A derived from the tree, capturing the relationship between input features and internal nodes. The result is compared against tensor B, which holds the value at each internal node, producing an "input path" tensor representing the route from input to node. With four conditions and a five-element input, A is 5x4 and B is 1x4.
Step 2 multiplies that input path tensor by tensor C, which encodes whether an internal node is a parent of another and whether it sits in the left or right subtree (left = 1, right = -1, otherwise 0). The result is compared for equality against tensor D, which counts the left child of its parent along the path from a leaf to the root. That yields the "output path" tensor. Here C is 4x5 and D is 1x5.
Step 3 multiplies the output path by tensor E, which maps leaf nodes to the final prediction. E is 5x1 in this example. The README notes this is one of three tree conversion strategies currently supported, and points to Figure 3 of the project paper for detail. The broader principle is stated plainly: reconfigure algorithmic operators so computations become more regular and therefore amenable to vectorized and GPU execution.
Installing hummingbird-ml and converting a fitted model
The README says Hummingbird was tested on Python 3.9, 3.10 and 3.11 on Linux, Windows and macOS, with one exception: TVM only works through Python 3.10. A virtual environment is recommended. PyTorch >= 1.6.0 is required, and the README directs you to pytorch.org for platform-specific install instructions.
Once PyTorch is in place, the package comes from pip:
python -m pip install hummingbird-mlIf you need the optional LightGBM and XGBoost dependencies, the README gives the extras form:
python -m pip install hummingbird-ml[extra]The README describes the usage pattern as minimal: import hummingbird.ml and call convert(model, 'dnn_framework') on a trained model. The converted object exposes a uniform inference API that follows the sklearn API, so existing inference code can swap in a Hummingbird-generated model without changes. Note the pip package name is hummingbird-ml, not hummingbird, and the import path is hummingbird.ml.
For a from-source setup, the repository ships a Dockerfile that clones the repo and installs the full extras set:
RUN sudo python -m pip install -e .[docs,tests,extra,onnx]That line is the Dockerfile's own install step. It differs from the pip route by pulling docs, tests, extra and onnx extras together. The repository also lists TROUBLESHOOTING.md for common problems, which is the first file to check when a conversion fails.
Backends, and what the conversion actually produces
The README lists four conversion targets: PyTorch, TorchScript, ONNX and TVM. These are not interchangeable in cost. PyTorch conversion keeps you in Python and gives you a module you can call directly. TorchScript conversion produces a serializable form, and the README notes that converting to PyTorch and TorchScript makes it possible to serve the models with TorchServe. ONNX conversion routes through the onnx extras, which setup.py pins to specific ranges: onnxruntime>=1.0.0,<1.18.0, onnxmltools>=1.6.0,<=1.12.0 and skl2onnx>=1.7.0,<=1.16.0. TVM is the narrowest path, restricted to Python 3.10.
The base install_requires list is longer than a typical model-conversion library: numpy>=1.15, onnxconverter-common>=1.6.0, onnx<=1.16.1, scipy, scikit-learn, torch>1.7.0, psutil, dill and protobuf>=3.20.2. Even if you only ever target PyTorch, the ONNX stack is pulled in. That is a real cost in image size and in dependency surface, and it is the kind of thing to check before adding Hummingbird to a slim inference container.
Model coverage is defined by the supported operators wiki page rather than by the README. The README names scikit-learn decision trees and random forests, plus LightGBM and XGBoost classifiers and regressors, as the models currently convertible, and says support for other backends and models is on the roadmap. Featurizers are also listed as supported, again with the wiki as the authority.
Where Hummingbird is the wrong tool
The first limitation is coverage. The README points to a wiki page for supported operators and a roadmap for everything else, which means the boundary between what converts and what does not lives outside the README and can move. A pipeline built from an unsupported featurizer or an unusual estimator will fail at conversion time, and the repository does not document a fallback that keeps the original model in the same deployment path.
The second is version pinning. setup.py caps onnx at <=1.16.1, onnxruntime below 1.18.0, onnxmltools at <=1.12.0 and skl2onnx at <=1.16.0, and requires xgboost>=0.90,<2.0.0. XGBoost 2.x is outside that range. If your environment already moved past those ceilings, Hummingbird is not a drop-in addition; you are choosing between downgrading and not using it for the ONNX path.
The third is that conversion is a one-way door in the documentation. The README describes converting a trained model into a tensor representation and serving it through the sklearn-style API. It does not describe how to go back to the original estimator, nor does it describe a rollback procedure if a converted model produces different predictions. Anyone planning a production cutover should treat prediction parity as something to verify themselves, because the README does not claim it for every operator.
Finally, if your model is a neural network already, Hummingbird has nothing to offer. Its whole premise is that the model is traditional and the runtime is a tensor framework. When both sides are already neural, the conversion step is pure overhead.
Hummingbird versus exporting through ONNX directly
The obvious alternative is skipping Hummingbird and exporting the fitted estimator with skl2onnx, onnxmltools or the framework's own serialization, then running it under onnxruntime. That path is narrower in scope: it produces an ONNX graph and stops there. Hummingbird's difference is that ONNX is only one of four targets. It can also produce a PyTorch module, a TorchScript artifact, or a TVM computation from the same trained model.
That matters when your serving stack is PyTorch-shaped. TorchServe is the concrete case the README names: converting to PyTorch and TorchScript is what makes serving through TorchServe possible. A direct ONNX export does not get you there, and neither does it get you TVM. Conversely, if ONNX Runtime is already your serving layer and your model exports cleanly, the direct route has fewer moving parts, since Hummingbird's ONNX path itself depends on skl2onnx and onnxmltools underneath.
The second difference is the operator rewrite. A direct export tends to preserve the structure of the original model. Hummingbird deliberately restructures the computation, for example turning tree traversal into matrix multiplications, on the argument that regular computation vectorizes and runs on GPUs better. Whether that restructuring beats a straightforward export on your data is an empirical question the README does not answer for you; it points at the notebooks for speedup demonstrations.
Maintenance, licence and upgrade cost
The repository is not archived, and its last push was on 2026-09-14. The most recent tagged release is v0.4.12 from 2024-10-24, preceded by v0.4.11 in March 2024 and v0.4.10 in January 2024. So commits continue while releases are spaced roughly months apart, and the version you get from pip may lag the main branch.
The licence is MIT, declared in setup.py as "MIT License" with Microsoft Corporation as author. MIT is permissive: it allows commercial use and modification with the copyright notice retained. That is a statement about the licence text, not legal advice; if your organization has policies about dependency licences, the LICENSE and NOTICE files at the repository root are what your process should read.
Upgrade cost is dominated by the pin ranges rather than by the Hummingbird API, which the README describes as minimal. The pins on onnx, onnxruntime, onnxmltools, skl2onnx and xgboost mean that a bump in any of those libraries can put you outside Hummingbird's declared support before Hummingbird itself changes. The repository includes a pre-commit configuration, a flake8 config and a black configuration at line-length 127, so contributing or patching locally has tooling already defined. The Dockerfile pins its base image to python:3.8-buster, which does not match the Python 3.9 to 3.11 range the README states for supported use.
Editorial conclusion
Adopt Hummingbird if you already have trained scikit-learn, LightGBM or XGBoost models and want them executing inside PyTorch, TorchScript, ONNX or TVM without rewriting inference code. Do not adopt it if your models fall outside the supported operator list, if you need a documented rollback path, or if you are not prepared to pin onnx, onnxruntime and the skl2onnx family to the ranges setup.py declares.
Frequently asked questions
Which machine learning models can microsoft/hummingbird convert?
The README names scikit-learn decision trees and random forests, plus LightGBM and XGBoost classifiers and regressors, along with a variety of featurizers. The authoritative list is the supported operators wiki page, and the README says other backends and models are on the roadmap.
What tensor frameworks can microsoft/hummingbird target?
The README lists PyTorch, TorchScript, ONNX and TVM as current conversion targets. TVM only works through Python 3.10, while the other targets are tested on Python 3.9, 3.10 and 3.11.
Does microsoft/hummingbird require PyTorch to be installed first?
Yes. The README states Hummingbird requires PyTorch >= 1.6.0 and directs you to pytorch.org for install instructions before you install hummingbird-ml from pip.
Community notes