MambaVision's pip package declares a non-commercial licence, one of its two releases is tagged pip, and its container pins a different timm version from the package

The package declares a non-commercial licence and the metadata declares none

The licensing picture is assembled from three places and they do not agree.

The setup script is the only one that names a licence at all:

    license="NVIDIA Source Code License-NC",
    python_requires='>=3.9',

The suffix on that identifier is the operative part. The package published to the Python index declares a non-commercial source licence, which means the code is available to read and run but the grant does not extend to commercial use.

The licence field attached to the repository holds no value at all, which in practice means it was never determined rather than that a particular one was chosen. A licence file is present in the tree, but the page never refers to it.

The readme's only licence-adjacent line points the other way: business users are told to visit a licensing form on the vendor's site. That is coherent with a non-commercial grant, and it means the commercial path runs through the vendor rather than through a permissive licence the repository forgot to update.

For a package people install with one command, the licence string in the setup script is the version most readers will see, so it is the one to read.

One of the two releases is tagged pip

There are two release entries and one of them is not a version of this software.

The current one is version 1.2.0, published in July 2025. The other is named `pip`, with a version of 1.1.0, and it is dated March 2025, the same week the news list records a new pip package being released.

A tag named after a package manager is a tag that something automated created, or a person created by hand while trying to make a release and mis-tagging it. Either way it is in the public release list, which means a script that discovers versions by listing releases will encounter a version 1.1.0 whose tag name is not the version name.

The news list tells the same story from the other side. Its entries run from July 2024 to June 2025, and its last entry is the conference poster and the semantic segmentation release, both dated 2025-06-10. The version 1.2.0 release came five weeks after the news stopped, and the default branch has been pushed to as recently as 2026-03-11 with no release and no news entry to explain it.

So there is a gap of roughly nine months between the last news item and the last commit, and the release history does not describe the current state of the branch.

The model carrying the headline accuracy number is not in either list

The one accuracy figure on the page belongs to a checkpoint that the page does not offer.

The news entry reads that the large 21K model, at 512 resolution, achieves a top-1 accuracy of 88.1 percent. It is the only number in the whole document.

Then there are two lists of available models. The Hugging Face list names six: a tiny variant, a second tiny variant, small, base, large, and a second large variant, all on the 1K pretraining set. The pip package list names the same six under their internal names, and the two correspond one to one.

There is no large third variant in either list. The model the accuracy claim is attached to is reachable only through the Hugging Face link in that news entry, while both lists of things you can install or call by name stop at the second large variant.

There is a second inconsistency in the same group of entries. The news says 21K models and code were added on 2025-03-25, and a new set of 21K models were added to the model collection on 2025-03-24, while the paper the project points at is from July 2024. So the accuracy figure comes from an addition made eight months after the paper, which means the paper is not where you would find it.

Three dependency files disagree on one library and on the CUDA version

The repository pins its dependencies three times, in the setup script, in the requirements file, and in the container image, and the three are not in agreement.

The disagreement that matters is a single library. The setup script and the requirements file both pin the image library at the same version. The container pins an earlier one:

FROM pytorch/pytorch:2.6.0-cuda12.6-cudnn9-devel

RUN pip install --no-cache-dir tensorboardX==2.6.2.2 mamba-ssm==2.2.4 timm==1.0.9 einops==0.8.1 transformers==4.50.0 requests==2.32.3 Pillow==11.1.0

So the version you get depends on whether you install the package, follow the requirements file, or run the container. Everything else in that line matches the other two files exactly, including the state-space library, which makes the one that differs look like an oversight rather than a decision.

The CUDA story is similar. The base image is a CUDA 12.6 build of a particular PyTorch version, while the requirements file asks for PyTorch with a CUDA 12.4 suffix. A requirements file that names a CUDA build will install that build whether or not the image already provides a different one.

Two more things about that container. It is built on the development variant of the base image, which carries the full toolchain rather than a runtime-only install, so it is a training and experimentation container by size. And it never installs the project: it copies the repository into the working directory and installs only the dependencies, so the package is importable from the source tree rather than installed.

Classifiers name two Python versions the package refuses to install on

The classifier list in the setup script enumerates seven Python versions, from 3.7 through 3.13. The same file then declares a floor two versions higher:

    classifiers=[
        'Programming Language :: Python :: 3.7',
        'Programming Language :: Python :: 3.8',
        'Programming Language :: Python :: 3.9',
        'Programming Language :: Python :: 3.10',
        'Programming Language :: Python :: 3.11',
        'Programming Language :: Python :: 3.12',
        'Programming Language :: Python :: 3.13',

A floor of 3.9 means 3.7 and 3.8 are classified as supported and cannot be installed. Package index search and metadata browsers read the classifiers, so a user on an older interpreter can be told the package supports them and then be refused by pip.

The list is otherwise thorough, covering the artificial intelligence and software topics, the library and module categories, and the content type of the long description. So the two stale entries are the only inconsistency in a list that was otherwise updated as the language moved.

There is one more comment in the same file worth reporting, because it is the kind of thing that only appears after someone fixed a mistake. It sits directly above the keywords field and says that the value is a string of words separated by whitespace rather than a list. Someone wrote that to themselves, or to the next person.

The package does not declare PyTorch and the repository does

The runtime dependency list in the setup script has six entries, all pinned to exact versions: the image library, the transformers library, the state-space library, a tensor operation library, an HTTP client, and an imaging library.

PyTorch is not among them. It is in the requirements file, with a version floor and a CUDA build suffix, and it is the base image in the container. So a plain install of the package does not bring the framework it is a model implementation for.

There are defensible reasons for that choice. A vision library can reasonably assume the framework is already present, and pinning a specific build with a CUDA suffix in a published package's metadata is a good way to force a wheel choice on everyone. But the consequence for a reader is that the requirements file and the package metadata are two different dependency contracts for the same project, and only one of them is what the index will enforce.

One dependency appears in only one of the three lists as well: a tensorboard logging library is in the requirements file and in the container, and not in the package metadata. That one is a training-time concern, so its absence from the package is consistent.

Both quick start snippets move to CUDA unconditionally

The page is careful about input resolution and silent about hardware. Both worked examples start the same way:

# eval mode for inference
model.cuda().eval()

# prepare image for the model
url = 'http://images.cocodataset.org/val2017/000000020247.jpg'
image = Image.open(requests.get(url, stream=True).raw)
input_resolution = (3, 224, 224)  # MambaVision supports any input resolutions

There is no device check and no CPU branch. The model is moved to CUDA and the image is opened into a tensor on CUDA, so the documented path assumes a GPU is present and will fail without one.

That is a reasonable assumption for a research backbone, and the container is built on a CUDA base image, so it is consistent with the project's intent. It is still the first thing to know if you are evaluating the architecture on a machine without one, because the page presents itself as the quick start and shows nothing else.

The resolution comment is the other thing worth taking from that snippet. The model is described as accepting any resolution, the input shape is given as three channels by 224 by 224, and the separate test snippet passes a randomly generated tensor with two different spatial dimensions. Combined with the hierarchical design, which is what makes variable resolution workable, that is the property most worth checking against your own data.

Editorial conclusion

MambaVision is worth evaluating if you want a hierarchical backbone with multi-scale stage features already exposed, since the feature-extraction interface hands you four stages of them plus the pooled vector, which is what makes the detection and segmentation code in the repository attachable without surgery. Three things to check before you build on it. The pip package's licence metadata names a non-commercial source licence, so read it before shipping anything. The package does not declare PyTorch as a dependency even though the repository requires it with a CUDA-specific specifier, so plan the torch install yourself. And the two dependency lists in the repository disagree with the container image on one library, so decide which set of pins you are trusting.

Frequently asked questions

Official sources

1. Issues
2. NVlabs/MambaVision on GitHub
3. Project website
4. README
5. Releases