onnx/models: A Deprecated Model Zoo and What Its LFS Cutoff Means
A collection of pre-trained, state-of-the-art models in the ONNX format
At a glance
- What is it?
- The ONNX Model Zoo is a curated collection of pre-trained models in ONNX format, now marked for historical preservation. Its LFS downloads end July 1st, 2025, and the project points users to Hugging Face instead.
- Who is it for?
- Adopt onnx/models only if you need a specific legacy ONNX file that is already mirrored at huggingface.co/onnxmodelzoo, or if you are reproducing results from a paper that references these exact artifacts. Do not adopt it for new model discovery or for anything requiring ongoing maintenance, because the repository is preserved for historical purposes and LFS downloads end July 1st, 2025.
- 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 15 days ago.
- What is it written in?
- Mainly Jupyter Notebook, 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 the ONNX Model Zoo was built to solve
Getting a model into a runtime has historically meant exporting it yourself. You clone a training repository, match the framework version, write an export script, and hope the resulting graph has the operator set your inference engine expects. The ONNX Model Zoo short-circuits that by publishing models that are already in ONNX format, sourced from timm, torchvision, torch_hub, and transformers, and exported through the TurnkeyML toolchain. The stated aim in the README is to "facilitate the spread and usage of machine learning models among a wider audience of developers, researchers, and enthusiasts."
The audience is narrower than that sentence suggests. This is a repository for people who need a known-good ONNX artifact with a reference implementation attached, not for people shopping for the best model in a category. The README organizes content into Computer Vision, Natural Language Processing, Generative AI, and Graph Machine Learning, with a separate validated models section for entries that passed accuracy checks. That split matters: presence in the repository does not mean a model was validated, and the README says so directly, noting that new models are being rigorously validated while readers should refer to the validated list for those that have been.
If you are choosing a model for a new product, this is the wrong starting point. If you need ResNet, SqueezeNet, VGG, AlexNet, GoogleNet, CaffeNet, or MobileNet as an ONNX file with a documented top-5 error from the original paper, the repository was built for exactly that.
How the repository is laid out and how models reach you
The mechanics are file-hosting mechanics, not framework mechanics. Model weights live in Git LFS, and the README describes the formats you will encounter as .onnx, .pb, and .npz. The .onnx file is the graph. The .pb file is protobuf, used in this context for test data. The .npz file is a NumPy archive holding the inputs and expected outputs that let you check a model without hunting down the original dataset.
That three-file convention is the most useful design decision in the repository. A model directory that ships input tensors and expected outputs alongside the graph turns validation into a local operation: load the .onnx, feed the .pb-derived input, compare against the .npz reference. The README points to a Usage section for starter Python code that does this. Without those fixtures you would be re-deriving preprocessing from a paper, which is where most ONNX deployments actually break.
The validated models are grouped under a directory tree that mirrors the taxonomy: validated/vision/classification/mobilenet, validated/vision/classification/resnet, validated/vision/classification/squeezenet, validated/vision/classification/vgg, validated/vision/classification/alexnet, validated/vision/classification/inception_and_googlenet/googlenet, validated/vision/classification/caffenet, and validated/vision/classification/rcnn_ilsvrc13 among others. Language models are split into machine comprehension, machine translation, and language modelling. Other categories cover visual question answering and dialog, speech and audio, and a catch-all group.
Quantized variants exist. The README states that INT8 models are generated by Intel Neural Compressor, an open-source Python library that performs dynamic and static quantization for ONNX models and can represent quantized graphs in operator-oriented or tensor-oriented QDQ form. If you need an INT8 model, that pipeline is the documented origin, not an ad-hoc conversion.
Getting a model onto disk with Git LFS
Because the weights are large, a plain git clone gives you pointer files rather than tensors. The README's Usage section is the authority here, and it covers downloading multiple ONNX models through the Git LFS command line. The sequence is the standard LFS flow: install git-lfs, run git lfs install, clone the repository, then git lfs pull to materialize the objects. Skipping the pull step is the most common failure, and it fails quietly, leaving small text files where the .onnx should be.
After the pull, the per-model directories contain the .onnx graph, the .pb test data, and the .npz expected outputs. The README's starter Python code is the intended way to validate the model against those fixtures before wiring it into anything. There is no configuration file, no service to start, and no CLI beyond git and git-lfs. The repository is a distribution channel, not a runtime.
This is worth stating plainly because the absence of tooling is a design choice with consequences. There is no version pinning mechanism beyond the git commit, no manifest that maps a model name to an opset version, and no checksum file described in the README. If you need reproducible model resolution in a build pipeline, you are building that layer yourself on top of a git ref.
The deprecation notice changes the calculus
The README opens with a deprecation notice, and it is not a soft one. It states that the repository is preserved for historical purposes only, that models will no longer be available for LFS download starting July 1st, 2025, and that the models originally available here can be reached at huggingface.co/onnxmodelzoo. The notice frames the transition as the ecosystem moving model sharing to Hugging Face, which the text describes as maintaining a healthy state.
Read the dates carefully. The repository is not archived and the last push recorded is 2026-09-01, so commits can still land. But the LFS download path is scheduled to stop working. Anyone whose CI pipeline clones this repository and runs git lfs pull is building on a dependency with a stated end date. That is the single most important fact about this project for anyone evaluating it now.
The practical consequence is that the repository's value has shifted from distribution to provenance. The directory structure, the paper references, the top-5 error figures quoted from the original publications, and the validated/unvalidated split remain useful as documentation of which models were checked and how. The weights themselves are being relocated.
Where the repository stops being the right tool
The failure mode is not corruption. It is staleness plus the download cutoff. A model zoo is only as current as its last contribution, and the deprecation notice is an explicit statement that novel model sharing has moved elsewhere. If you need a recent architecture, this is not where it will appear. The validated list is dominated by vision classification networks whose papers date to the mid-2010s: AlexNet, CaffeNet, VGG, GoogleNet, ResNet, SqueezeNet, MobileNet.
Accuracy claims need careful reading too. The top-5 error figures in the tables are attributed to the source papers, not to measurements taken on the ONNX exports in this repository. The README labels them as such, for example "Top-5 error from paper - ~3.6%" for ResNet and "~10%" for MobileNet. That distinction matters when you are deciding whether an export preserved the original model's behavior. The .npz fixtures let you check output agreement on a fixed input, which is a weaker guarantee than a full evaluation on the source dataset, but it is the check the repository actually supports.
There is also no release history retrieved for this repository, so there is no versioned artifact stream to pin against. Your pin is a commit hash. When the LFS endpoint goes away, that commit hash stops resolving to weights.
Hugging Face as the replacement, and how the approach differs
The README names the successor directly: huggingface.co/onnxmodelzoo. That is not a competitor in the market sense, it is the same collection relocated to a platform built around model hosting rather than git plus LFS.
The difference in approach is structural. Here, a model is a directory in a monorepo, and discovery means reading a README table and browsing a path. On Hugging Face, a model is a repository of its own with its own revision history, and the platform provides the hosting, the download client, and the browsing interface. The opset version, the input signature, and the preprocessing expectations are not standardized across the two, so a migration is not a URL swap. If your code constructs a path like validated/vision/classification/resnet, that path does not exist on the other side.
A second alternative is to skip the zoo entirely and export the model yourself from the upstream source named in the README: timm, torchvision, torch_hub, or transformers. That gives you control over the opset and the input shape at the cost of owning the export pipeline and its version drift. The zoo's value was that someone else already did that work and attached test fixtures. Once the LFS downloads end, that value is largely transferred to the Hugging Face mirror.
Licence, maintenance, and what you are actually taking on
The repository is Apache-2.0, and the README carries an SPDX-License-Identifier: Apache-2.0 header. That covers the repository contents. It does not automatically cover the upstream models, which are sourced from timm, torchvision, torch_hub, and transformers and carry their own terms, and it does not cover the source papers. The README's tables cite publications for each architecture, and those citations are the pointer to the original licensing context. This is not legal advice; check the upstream project for each model you ship.
Maintenance cost after the cutoff is close to zero in one sense and unbounded in another. There is nothing to upgrade, because the project is not shipping new versions. There is also nothing to upgrade to when a runtime drops support for an old opset, and the repository will not publish a refreshed export. The INT8 path compounds this: quantized models are generated by Intel Neural Compressor, so regenerating them means adopting that toolchain rather than waiting for an update here.
The concrete next step for anyone still depending on this repository is to check whether the specific model you use is present at huggingface.co/onnxmodelzoo and to switch your fetch step before July 1st, 2025. If it is not mirrored, pull the .onnx, .pb, and .npz files now and store them under your own version control, because after that date the git history will still be there but the weights will not.
Editorial conclusion
Adopt onnx/models only if you need a specific legacy ONNX file that is already mirrored at huggingface.co/onnxmodelzoo, or if you are reproducing results from a paper that references these exact artifacts. Do not adopt it for new model discovery or for anything requiring ongoing maintenance, because the repository is preserved for historical purposes and LFS downloads end July 1st, 2025. Before committing, verify that the model you need is present in the Hugging Face mirror and that your runtime supports the opset version recorded in the model's own directory.
Community notes