NVIDIA-NeMo/Nemotron: What the Developer Repo Actually Ships

What NVIDIA-NeMo/Nemotron Is, and What It Is Not

The repository describes itself as a developer asset hub: training recipes, usage cookbooks, datasets and end-to-end reference examples for building with Nemotron models. The models themselves live elsewhere. The README links model weights on Hugging Face for Nemotron 3.5 Lightning, Nemotron 3 Ultra and Nemotron 3 Nano Omni, so cloning this repository gets you the pipeline, not the parameters.

That distinction decides who the project is for. A team that wants to fine-tune, reproduce or inspect how a Nemotron checkpoint was built has something to work with here. A team that wants to call a Nemotron model over an API, or run one locally for chat, will find the repository points outward to Hugging Face and to NIM microservices rather than containing a runtime.

The README's own comparison table splits the repository into four parts. Nemotron Steps are lifecycle building blocks driven by a CLI and YAML configs. Training Recipes are Python packages that reproduce full pipelines from raw data to model. Usage Cookbooks are Jupyter notebooks for deploying and running inference. Use Case Examples are notebooks and scripts for applications such as RAG, agents and tool use. The primary language of the repository is Jupyter Notebook, which matches the cookbook and example directories taking up much of the tree.

The nemotron steps CLI and Its Artifact Graph

The central mechanism is the step. The README defines a Nemotron step as a named, reusable unit of work invoked with the `nemotron steps` CLI. Each step declares the work it performs, the artifacts it consumes, and the artifacts it produces, plus one or more named configurations that supply parameter values. Steps live under `src/nemotron/steps/`, and the CLI discovers them at startup.

That artifact declaration is what makes composition possible. Because a step names both its inputs and its outputs, the CLI can resolve a graph of steps rather than requiring a monolithic script. The README states that the published training recipes are themselves composed from these steps, and that you can run a single step in isolation or chain steps into a pipeline shape the recipes do not cover.

The step catalog is organised by lifecycle stage. Data curation and preparation appear under `curate/*` and `data_prep/*`. Synthetic data generation is under `sdg/*`. Corpus translation is under `translate/*`. Bring-your-own benchmark generation is under `byob/*`, followed by pretraining and supervised stages that the README does not fully enumerate. The breadth is the point: this is a catalog meant to cover data preparation through evaluation, not a single training script with flags.

The dependencies in `pyproject.toml` tell you what running a step entails. Ray with the default and data extras is a direct dependency, as are `pyarrow`, `fsspec`, `transformers` pinned to `>=4.57.6,<5.0`, `omegaconf`, `typer` and `pydantic`. This is a distributed data-processing stack, not a thin wrapper. Expect a heavy install and a machine that can host Ray.

Installing It and Running a First Step

The repository uses `uv`, and `pyproject.toml` requires Python `>=3.10,<3.14`. There is a `.python-version` file at the repository root, so `uv` can select the interpreter for you. Clone the repository and sync the environment from the root:

git clone https://github.com/NVIDIA-NeMo/Nemotron.git
cd Nemotron
uv sync

Optional dependency groups exist for storage and for specific data types. The `s3` group pulls `s3fs`, `gcs` pulls `gcsfs`, `sentencepiece` pulls the tokenizer library, and `xenna` pulls `cosmos-xenna`. If your data prep involves audio or video, the `pyproject.toml` mentions an extra for that work in the truncated section, so check the file before assuming the default install covers it.

Once the environment is synced, the steps CLI is the entry point. The README does not print a full invocation, but the contract is that the CLI discovers steps under `src/nemotron/steps/` and each step carries named configurations. Read the step definitions under that directory before guessing at an invocation.

For documentation work there is a `justfile` with two recipes. `docs-render` runs `uv run --group docs sphinx-build docs docs/_build/html`, and `docs-dev` runs `uv run --group docs sphinx-autobuild docs docs/_build/html --port 12345 --open-browser`. If your goal is to understand the recipes before running them, the second command serves the docs locally on port 12345 and opens a browser. The published documentation also lives at the homepage linked from the repository.

The Claude Code Plugin and Its Working Directory Constraint

The repository ships a Claude Code plugin called `nemotron-customize` that turns the step catalog into a guided pipeline builder. It is installed through the plugin marketplace rather than through `uv`:

/plugin marketplace add NVIDIA/Nemotron
/plugin install nemotron-customize@nvidia-nemotron

The README is explicit that the marketplace installs only `nemotron-customize`. The other folders under `skills/`, described as model knowledge bases and contributor add-`*` skills, stay on disk for browsing but are not loaded as plugins. That is a deliberate scoping choice and worth knowing before you wonder why a skill you can see is not available.

The plugin has a hard constraint. It resolves all file paths against the current working directory, so it must be started from the Nemotron checkout root, which must contain `pyproject.toml` and `src/nemotron/steps/`. Running it from a subdirectory causes file reads to fail. The README gives the sequence:

cd /path/to/Nemotron        # repo root: must contain pyproject.toml and src/nemotron/steps/
claude

Then invoke `/nemotron-customize` inside the session. According to the README, the skill plans the step DAG, validates artifact wiring, and emits the YAML configs needed to run the requested pipeline. The full contract is in `skills/nemotron-customize/SKILL.md`. If you are not a Claude Code user, this entire path is unavailable to you and you are back to reading step definitions and writing YAML by hand.

Where the Repository Is Thin

The most concrete problem is licence metadata that contradicts itself. The README carries an Apache 2.0 badge and links to the Apache 2.0 text, and the repository description states Apache-2.0. The `pyproject.toml` in the same repository declares `license = {text = "MIT"}`, lists the MIT classifier, and the `LICENSE` file is not reproduced in the repository listing available here. For a project whose selling point is transparent, reproducible pipelines, a mismatch between the package metadata and the README badge is the kind of thing that surfaces during procurement review rather than during development. Treat this as unresolved and check the `LICENSE` file and the model weights' own terms separately, since weights on Hugging Face carry their own licence regardless of what this repository declares.

Second, the repository is at an early stage by its own metadata. `pyproject.toml` classifies it as `Development Status :: 3 - Alpha`, and the only release listed is v0.1.0 from 2026-03-24. The last push was on 2026-09-11, so the repository is being worked on, but the version number and the alpha classifier mean interfaces can move. A recipe that runs today may not run after a step signature changes.

Third, the README's step category list stops mid-sentence at pretraining and supervised stages. That points at a real reading habit: the categories you need may be documented only inside `src/nemotron/steps/` rather than in the top-level README, so the README alone is not a complete map of the catalog.

Finally, the dependency on `nemo-run` is a git dependency pinned to `main` rather than a released version. That means an upstream commit can change your environment between two installs. `uv.lock` exists in the repository, which mitigates this for anyone who uses the lock, but it is worth naming as the reason to use the lock rather than a bare install.

How It Differs from NeMo Framework and from Plain Hugging Face

The natural comparison is NVIDIA NeMo, the broader framework. NeMo is a training and customization toolkit; this repository is a catalog of recipes and steps built to be run through its own CLI, with `nemo-run` as a dependency rather than as the interface. If you already have a NeMo training stack, the recipes here are a source of pipeline definitions you can read and adapt, but the entry point the README documents is `nemotron steps`, not a NeMo launcher. The two are adjacent, not interchangeable.

The other comparison is the Hugging Face ecosystem, where the Nemotron weights are published. Hugging Face gives you `transformers`, `datasets` and a model card. This repository gives you the pipeline that produced the checkpoint: data curation, synthetic data generation, translation, benchmark generation, pretraining and evaluation, each as a named step with declared artifacts. If you want to fine-tune a Nemotron model on your own data and you are comfortable assembling a Ray-based data pipeline, the steps catalog is the more direct route. If you want to load a model and generate text in twenty lines, `transformers` plus the Hugging Face weights is the shorter path, and this repository will mostly be reading material.

A third option the README names is NIM microservices for deployment, alongside TensorRT-LLM, vLLM and SGLang. Those are serving paths, not training paths, and they are referenced from the usage cookbooks rather than implemented in this repository. The cookbooks are notebooks that walk through deployment and inference; they document how to use a model you already have.

Maintenance Cost and Upgrade Risk

The upgrade surface here is wider than the version number suggests. The project is at v0.1.0 and labelled alpha, so step configurations and CLI behaviour are not yet stable contracts. The dependency list includes Ray with the default and data extras at `>=2.54`, `transformers` bounded below 5.0, and `nemo-run` from git `main`. Ray and `transformers` both move quickly, and the `nemo-run` git dependency means the upstream default branch is part of your build. The `uv.lock` file is the practical answer: sync from the lock, and treat any deliberate refresh of that lock as a change worth testing against the recipe you depend on.

The documentation build is cheap to maintain. `just docs-render` and `just docs-dev` are two lines in the `justfile`, and the docs group is optional, so documentation work does not pollute a training environment. The Claude Code plugin adds a second, unrelated update channel through the plugin marketplace, which is worth remembering if your team tracks changes by watching the repository's releases only.

On licensing, the repository description and README say Apache-2.0 while `pyproject.toml` says MIT. Both are permissive, but they are not identical in their patent and attribution terms, and neither necessarily covers the model weights, which are hosted separately on Hugging Face under their own terms. Resolve which licence applies to the code you redistribute before you ship anything derived from it. This is a factual gap in the repository, not a legal opinion.

Which Nemotron Tier the Recipes Target

The README describes four model tiers. Nano is positioned for edge and PC deployments. Lightning is for fast, high-volume task execution in long-running agents, and the release note describes Nemotron 3.5 Lightning as a 30B-A3B hybrid Mamba-Transformer MoE with Multi-Token Prediction. Super is described as single-GPU deployment with the highest throughput. Ultra is for multi-GPU datacenter applications, and Nemotron 3 Ultra is listed as a 550B-A55B model on Hugging Face.

Recipes exist for several of these. The README links training recipes for Lightning 3.5 at `docs/nemotron/lightning35/README.md`, for Ultra 3 at `docs/nemotron/ultra3/README.md`, and for Nano Omni at `docs/nemotron/omni3/README.md`. A usage guide for Ultra 3 sits at `usage-cookbook/Nemotron-3-Ultra/README.md`. The practical consequence is that the recipe you can actually run depends on which tier you care about. If you are targeting a tier without a published recipe, the steps catalog is still available, but you are composing a pipeline rather than reproducing one, and the README's claim that recipes are composed from steps means you are working at a lower level of guarantee.

Nano Omni is the outlier in scope. The README describes it as a hybrid Mamba-Transformer MoE with native text, image, video and audio support, positioned as a multimodal perception sub-agent. That is why the `pyproject.toml` carries an audio and video data prep extra for the omni3 supervised fine-tuning path. If your work is text-only, that extra is dead weight; if it is multimodal, the default install is not enough.

Editorial conclusion

Adopt it if you need the reproducible pipeline behind a Nemotron checkpoint, or a documented way to deploy one you already have. Skip it if you only want to chat with a Nemotron model, because the repository ships no serving stack and no weights of its own. Verify two things before you build on it: which licence actually governs your use, since the README says Apache-2.0 and pyproject.toml declares MIT, and whether the published training recipe matches the checkpoint you intend to reproduce. Start from src/nemotron/recipes/ and read the recipe README before running anything.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. NVIDIA-NeMo/Nemotron on GitHub
3. Project website
4. README
5. Releases