Open Weights, Open Data, Open Recipes
NVIDIA's open models open more than most: the weights, the training data, and the recipes that produced them. Major portions of both the pre-training and post-training corpora are published as datasets you can inspect, alongside the end-to-end training procedure — which makes these the rare models you can reproduce rather than only consume. They are built for agents specifically, with a hybrid architecture interleaving Mamba-2 and mixture-of-experts layers to raise throughput on high-volume workloads. On DEVUP AI they are reachable through the standard OpenAI-compatible endpoint, billed in Algerian Dinar.
Most open models release their weights. NVIDIA releases the weights, major portions of the training data, and the end-to-end recipe that combined them — publishing the pre-training corpus and the post-training corpus as separate dataset collections, alongside the training procedure and the evaluation tooling needed to reproduce the published numbers.
That distinction matters more than it sounds. Open weights let you run and fine-tune a model. Open data and recipes let you understand why it behaves as it does, audit what went into it, and build a specialised model from the same foundation rather than from someone's finished product. For regulated work, for research, and for anyone whose organisation asks what a model was trained on, that is a different category of answer.
The architecture is unusual in the current landscape. Rather than a conventional transformer stack, these models interleave Mamba-2 layers with mixture-of-experts layers and a selection of attention layers. Mamba-2 carries sequence state at constant cost instead of a growing key-value cache, which is what makes high-throughput and long-context work affordable; attention layers are placed where exact retrieval matters. Larger models add a latent routing scheme that projects tokens into a smaller dimension before expert selection, and multi-token prediction layers for faster generation.
The stated target is agents. Not chat that happens to call tools, but collaborative agent systems and high-volume automation — the shape of workload where the same operation runs constantly and throughput decides whether a design is viable. These models generate a reasoning trace before their final answer, and that reasoning is configurable rather than fixed.
On DEVUP AI, NVIDIA models are called through the same OpenAI-compatible endpoint as the rest of the catalogue: one API key, one base URL, one model identifier. Context limits and capabilities differ between models, so check the individual model page before switching a production path.
Available Nemotron Models
Deploy and access all published models in this family with unified DZD pricing and zero foreign card requirement.
| Model | Context | DZD in / 1M tokens | Cached in / 1M tokens | DZD out / 1M tokens | Actions |
|---|---|---|---|---|---|
| Nemotron-3-Embed-8Bnvidia/Nemotron-3-Embed-8B | 32K Tokens | 12.25 | — | — | View model |
| Nemotron-3-Embed-1B-NVFP4nvidia/Nemotron-3-Embed-1B-NVFP4 | 32K Tokens | 3.5 | — | — | View model |
| Nemotron-3-Embed-1B-BF16nvidia/Nemotron-3-Embed-1B-BF16 | 32K Tokens | 5.25 | — | — | View model |
| Nemotron-Content-Safety-3.5nvidia/Nemotron-Content-Safety-3.5 | 131K Tokens | 70 DZD/ 1M tokens | View model | ||
| Nemotron-3.5-ASR-Streaming-Multilingual-0.6bnvidia/Nemotron-3.5-ASR-Streaming-Multilingual-0.6b | — | 0.07 DZD / minute | View model | ||
| NVIDIA-Nemotron-3-Super-120B-A12Bnvidia/NVIDIA-Nemotron-3-Super-120B-A12B | 262K Tokens | 35 | — | 175 | View model |
| Nemotron-3-Nano-30B-A3Bnvidia/Nemotron-3-Nano-30B-A3B | 262K Tokens | 17.5 | — | 70 | View model |
| llama-nemotron-embed-vl-1b-v2nvidia/llama-nemotron-embed-vl-1b-v2 | 10K Tokens | 3.5 | — | — | View model |
| NVIDIA-Nemotron-3-Ultra-550B-A55Bnvidia/NVIDIA-Nemotron-3-Ultra-550B-A55B | 262K Tokens | 175 | 52.5 | 875 | View model |
| llama-nemotron-rerank-vl-1b-v2nvidia/llama-nemotron-rerank-vl-1b-v2 | 10K Tokens | 3.5 | — | — | View model |
Call any Nemotron model
Every model on this page uses the same API key and standard OpenAI-compatible endpoint. The example below uses the featured model nvidia/NVIDIA-Nemotron-3-Super-120B-A12B.
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["DEVUP_API_KEY"],
base_url="https://api.devupai.com/v1",
)
response = client.chat.completions.create(
model="nvidia/NVIDIA-Nemotron-3-Super-120B-A12B",
messages=[
{"role": "user", "content": "Hello world!"}
],
max_tokens=1024,
)
print(response.choices[0].message.content)import DevupAI from "devupai";
const client = new DevupAI({
apiKey: process.env.DEVUP_API_KEY,
});
async function main() {
const response = await client.chat.completions.create({
model: "nvidia/NVIDIA-Nemotron-3-Super-120B-A12B",
messages: [{ role: "user", content: "Hello world!" }],
max_tokens: 1024,
});
console.log(response.choices[0].message.content);
}
main();curl -X POST "https://api.devupai.com/v1/chat/completions" \
-H "Authorization: Bearer $DEVUP_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "nvidia/NVIDIA-Nemotron-3-Super-120B-A12B",
"messages": [
{ "role": "user", "content": "Hello world!" }
],
"max_tokens": 1024
}'Frequently Asked Questions
The training data and recipes are published alongside the weights. Major portions of both the pre-training and post-training corpora are released as separate dataset collections, plus the end-to-end training procedure and the evaluation tooling. Most open models let you run and fine-tune them; these let you audit what went into them and reproduce the result. If nobody in your organisation asks what a model was trained on, that is a nice property. If somebody does, it is the deciding one.
These models interleave Mamba-2 layers with mixture-of-experts layers rather than stacking transformer blocks throughout. Mamba-2 carries sequence state at constant cost instead of a key-value cache that grows with the input, so long inputs and high request volume cost less than a conventional architecture at the same size. Attention layers are kept where exact retrieval matters. The practical result is throughput — the constraint that decides whether a high-volume agent pipeline ships.
Yes. These models produce a reasoning trace before the final answer, and that behaviour is configurable through the chat template rather than fixed. Enable it for multi-step work, analysis, and code. Leave it off for classification, routing, and extraction, where deliberation adds latency and nothing else. Check the individual model page for how the flag is passed on a given model.
Collaborative agent systems and high-volume automation — NVIDIA names IT ticket automation as an example. That shape of workload runs the same operation constantly, which makes cost and latency per call the binding constraint rather than peak capability. They also suit chatbots, retrieval-augmented systems, complex instruction following, and long-context reasoning.
Match the size to the task rather than starting at the top. Smaller models handle high-volume mechanical work; larger ones add capacity for reasoning and longer context. Because they share an interface, testing a smaller model on your own workload costs one changed field — and that result is better evidence than any benchmark table.
Those suffixes are numerical precisions, not different models. The same model is published at several precisions so you can match it to your hardware and memory budget — lower precision means a smaller memory footprint and faster inference, at some cost in exactness. When calling through an API the precision is handled for you; the suffix matters when you are self-hosting, and it is part of the model identifier.
