NVIDIA NIM vs vLLM vs Ollama: What NIM Is, API Keys, Free Tier, Licence and Pricing

NVIDIA NIM is a set of prebuilt inference containers. The current NIM for LLMs release, 2.1.5, wraps vLLM or SGLang with NVIDIA-tuned profiles behind an OpenAI-compatible API. Trying it is free: build.nvidia.com gives rate-limited hosted endpoints with an API key, and Developer Program members can self-host for testing. Production self-hosting normally needs NVIDIA AI Enterprise, listed at $4,500 per GPU per year. vLLM (Apache 2.0) and Ollama (MIT) cost nothing at any scale.

Searches for NVIDIA NIM have climbed through 2026, much of it from people who already run Ollama and want to know whether NVIDIA’s containers are a step up, a paid version of the same thing, or a free API. The honest answer is a bit of each. This guide sorts out what NIM is, what is free and what is not, and how it compares with the two servers most teams already know.

Facts below come from NVIDIA’s NIM documentation (last updated 10 November 2026), its licensing guide and terms, build.nvidia.com and the vLLM and Ollama repositories, all checked on 13 November 2026. NVIDIA renames and reshuffles these offerings often, so confirm licence terms with NVIDIA or a partner before you buy. For the wider field of open-source servers, our comparison of vLLM, Ollama, llama.cpp and SGLang is the companion piece.

What is NVIDIA NIM?

NIM stands for NVIDIA Inference Microservices. Each NIM is a container that starts a model server, picks a configuration suited to the GPUs it finds, and exposes a standard HTTP API. NVIDIA publishes NIMs for speech, vision, embeddings, biology and more; this article covers NIM for LLMs, which NVIDIA now calls NIM for LLM and VLM because it also serves vision-language models.

The architecture changed with version 2.0. The 1.x containers bundled several backends, TensorRT-LLM among them, in one image. Version 2.x follows a one-container, one-engine rule: every image carries either vLLM or SGLang, plus NVIDIA’s orchestration layer for startup, profile selection, model download, LoRA adapters, TLS and health checks. Release 2.1.5 ships vLLM 0.31.0 and SGLang 0.5.21. TensorRT-LLM still appears on NVIDIA’s general NIM marketing, but it is not the engine in the current LLM containers.

There are two container types:

• Model-specific NIMs carry a manifest for one model, with curated weights, validated quantisation profiles and tuned engine settings. Examples include llama-3.3-70b-instruct, gpt-oss-120b and glm-5.2.
• Model-free NIMs are generic vLLM or SGLang images that serve whatever you point NIM_MODEL_PATH at: a Hugging Face repository, an S3 or Google Cloud Storage bucket, NGC, or a local directory. They exist for fine-tunes, day-zero models and organisations that want one container image through security review instead of dozens.

NVIDIA also sorts NIMs into three release tracks. Plain NIM is published within about 72 hours of an upstream model release, validated on a small set of GPUs and supported only through community forums. NIM Certified Feature Branch adds broad hardware validation and CVE handling, with enterprise support if you hold a subscription. NIM Certified Production Branch gives a fixed software baseline for long-lived regulated deployments and requires an NVIDIA AI Enterprise subscription outright; designated images come in Government Ready versions.

NVIDIA NIM API key, free endpoints and base URL

The other half of “NVIDIA NIM” is the hosted API catalog at build.nvidia.com, which runs NIMs on NVIDIA’s DGX Cloud. On 13 November 2026 its model listing showed 103 models, labelled “Free Endpoint”, “Downloadable” or both.

To get a key, sign in with an NVIDIA account, open any model page and choose Get API Key. NVIDIA’s FAQ says the same key authenticates calls to the hosted endpoints and logins to the NGC container registry. Hosted language models answer at https://integrate.api.nvidia.com/v1 in the OpenAI chat completions format, so the OpenAI SDK only needs a new base URL:

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://integrate.api.nvidia.com/v1",
    api_key=os.environ["NVIDIA_API_KEY"],
)
reply = client.chat.completions.create(
    model="openai/gpt-oss-120b",
    messages=[{"role": "user", "content": "Summarise our VPN policy in three bullets."}],
)
print(reply.choices[0].message.content)

Three limits matter before anyone wires this into a product:

• Rate limits. NVIDIA calls the catalog a trial experience for evaluation and prototyping. It says limits vary by model and current load and shows yours in the account menu at the top right of the site. Developers posting on NVIDIA’s forums in 2026 consistently report a default of 40 requests per minute, and moderators there say the free tier cannot be raised.
• Credits. Guides from 2024 describe starter credit balances. NVIDIA’s current FAQ answers usage questions with rate limits instead, so treat any credit figure you find online as historical.
• Production. The free endpoints are not licensed for production traffic. For hosted production use, NVIDIA points to partner endpoints listed on each model page; for self-hosting, to NVIDIA AI Enterprise.

The other catch is data location: every prompt sent to build.nvidia.com leaves your network. For anything confidential, the hosted catalog is a way to test a model, not a way to run it.

Is NVIDIA NIM free? Licence terms and pricing

NIM containers are free to download, but whether you may run them for real work depends on which programme you use them under.

NVIDIA Developer Program. Membership is free and covers hosted endpoints plus self-hosted NIM containers for research, development and experimentation. NVIDIA’s NIM FAQ sets the self-hosted allowance at up to 16 GPUs, with more on request. Its Product-Specific Terms for AI Products (October 2025 edition) say software in the developer programme is not for use, distribution or deployment in production. The FAQ defines production broadly: business transactions and any activity serving real end users.

NVIDIA AI Enterprise. Production self-hosting is licensed per GPU. NVIDIA’s licensing guide, updated 2 September 2026, publishes these list prices:

The five-year term is priced as four years, and NVIDIA says some H100, H200 NVL and A800 cards ship with a subscription included. A free 90-day evaluation licence is available. Final prices come from NVIDIA partners, so use these as budgeting figures, not quotes.

RTX exception. NIMs that NVIDIA designates for RTX and GeForce RTX GPUs are free without a subscription when they run on one PC or workstation that does not serve multiple users. That covers a developer’s desk, not a shared server.

A wrinkle in the 2026 docs. The NIM documentation now describes plain NIM and NIM Certified Feature Branch as available “at no charge under the applicable license terms”, while the Production Branch requires a subscription. It does not say that no-charge availability equals a production licence, and the developer-programme terms above still bar production. If you plan to serve employees from a free container, get NVIDIA’s answer in writing. Our open-weight licensing checklist covers the model licences, which apply on top of NVIDIA’s terms; none of this is legal advice.

vLLM and Ollama have no such split: vLLM is Apache 2.0 and Ollama is MIT, so cost is hardware and staff time. Only the model weights carry their own licences.

NVIDIA NIM models: what you can self-host

The hosted catalog and the downloadable containers are not the same list. Release 2.1.5, documented on 10 November 2026, shipped these model-specific NIMs:

Kimi K3.1 Pro arrived in the same release, but only through an experimental model-free vLLM container with a separate serving recipe; our Kimi K3.1 Pro local deployment guide covers its hardware needs. Newer open releases such as Qwen 4 had no model-specific NIM in the 2.1.5 list. A model-free container can serve them once the bundled engine supports the architecture.

The hosted catalog moves faster. On 13 November it listed free endpoints for models including Kimi K3.1 Pro, DeepSeek V4.1 Flash, GLM-5.3 Flash, MiniMax M3.1 Flash, Mistral Large 4 and a Step 5 preview, several of which had no downloadable NIM.

Do NIMs lag new releases? Two lags apply. NVIDIA targets about 72 hours from a model’s upstream release to a plain NIM, and Certified builds take longer. The engines lag too: 2.1.5 bundles vLLM 0.31.0 (released 5 October) and SGLang 0.5.21 (2 October), while upstream had reached vLLM 0.32.0 on 18 October and SGLang 0.5.23 on 2 November. Running vLLM directly gets you new model support weeks sooner; NIM trades that for validation.

Supported GPUs and system requirements

NIM for LLMs runs on Linux only. NVIDIA’s prerequisites list an AMD64 or ARM64 host, any supported NVIDIA GPU, Ubuntu 22.04 or later (other distributions untested), GPU driver 580 or later, CUDA 12.9 or later, Docker 24.0 and NVIDIA Container Toolkit 1.14. Validated architectures run from Ampere and Ada through Hopper to Blackwell, including B200, B300, GB200 and GB300, data-centre cards such as L40S and RTX PRO 6000 Blackwell Server Edition, and the GB10 chip in DGX Spark. On unified-memory systems like DGX Spark, 2.1.5 lets the engine use up to 75% of system memory.

Validation is per model and profile, not per architecture. NVIDIA’s support matrix lists which quantisation and parallelism profiles were tested on which GPU, and 2.1.5 dropped several combinations that earlier releases listed. Check the matrix for your exact card before you size a server; even Llama 3.1 8B needs at least 24 GB of GPU memory under NIM’s profiles.

The other two servers reach further:

• vLLM supports NVIDIA CUDA, AMD ROCm and Intel XPU GPUs, CPUs on x86, ARM and IBM Z, Apple silicon through vLLM-Metal, and further accelerators through hardware plugins.
• Ollama runs on NVIDIA GPUs from compute capability 5.0, AMD GPUs with ROCm 7, Apple silicon through Metal and other GPUs through Vulkan, on Linux, macOS and Windows.

For sizing, our VRAM calculator estimates weights plus cache by model and quantisation, the tokens-per-second calculator estimates decode speed by GPU, and the on-premise AI server guide covers chassis, power and cost.

NVIDIA NIM vs vLLM vs Ollama side by side

NIM vs vLLM: what the container adds

Because a vLLM-based NIM runs vLLM, the useful question is what NVIDIA puts around it and whether that is worth a per-GPU subscription.

What NIM adds. Hardware-aware profile selection, so the container picks tensor parallelism and quantisation for the GPUs it finds. Curated, signature-verified weights. Images scanned and patched for CVEs on a schedule; release 2.1.5 alone fixed 81 security issues across the two engine images. Production branches that freeze a software baseline for a long support window. Health and readiness probes, a metadata API and an NVIDIA support contract.

Performance. NVIDIA says it benchmarks NIM for “parity-or-better” performance against the upstream engines. That is NVIDIA’s claim, and we know of no independent benchmark of 2.1.5 against the same vLLM version. The gains come from tuned engine arguments and validated quantisation profiles, which a capable team can reproduce on plain vLLM with enough testing. Measure both on your own prompts and concurrency, as our inference server comparison suggests for any engine.

What plain vLLM keeps. No licence cost at any GPU count, the newest engine release and model support, AMD and Intel hardware, and every engine flag. The price is that your team owns version pinning, CVE scanning, profile tuning and on-call support. Our resource on where vLLM fits in enterprise LLM infrastructure describes that operating model.

As a rough rule, the licence starts to look cheap when an organisation has few platform engineers, many GPUs on a long hardware life, and auditors who ask who patches the inference layer. It looks expensive on a two-GPU pilot that a capable engineer can run on plain vLLM.

NIM vs Ollama: different jobs

Ollama and NIM rarely compete for the same server. Ollama is built for one machine: one installer, a model library of quantised GGUF builds, and a background service on 127.0.0.1:11434 with no authentication. Its defaults process one request per model at a time and queue up to 512 more; OLLAMA_NUM_PARALLEL raises that, but each slot costs context memory. It runs well on a MacBook, an AMD workstation or a modest NVIDIA card.

NIM assumes data-centre or workstation-class NVIDIA GPUs, higher-precision or FP8 and NVFP4 profiles, and many concurrent users batched by the engine. It needs Docker, the NVIDIA Container Toolkit and a recent driver, and it will not run on a Mac.

A common path is to prototype on Ollama, then move shared traffic to vLLM or NIM once more than a handful of people use it. Our guide to running Ollama for multiple users shows how far tuning can stretch Ollama first. Because all three speak the OpenAI format, application code mostly needs a new base URL and model name when you switch.

Air-gapped deployment and telemetry

All three can run with no internet connection, with different amounts of help.

• NIM documents a two-phase workflow: on a connected machine, download the model into the cache with download-to-cache and optionally build a model store; move it across by archive, rsync or physical media; then start the same image on the isolated host with no NGC_API_KEY or HF_TOKEN. Model-free NIMs serve straight from a local directory. NVIDIA’s product terms note that NIM containers which collect telemetry can be switched off with NIM_TELEMETRY_MODE=0; set it explicitly.
• vLLM loads weights from a local path. It collects anonymous usage statistics by default, which VLLM_NO_USAGE_STATS=1 or DO_NOT_TRACK=1 disables.
• Ollama reads models from its models directory, which OLLAMA_MODELS relocates, so you can pull on a connected machine and copy the files. A local-only mode turns off its cloud models and web search.

Container images, driver packages and patches still have to cross the gap. Our guide to AI in air-gapped and restricted networks covers mirrors, registries and update cadence.

Kubernetes and observability

NIM Operator. NVIDIA’s Kubernetes operator, at v3.1.3 since 28 October 2026 and Apache 2.0 licensed, adds two custom resources: NIMCache downloads model artifacts to a persistent volume once, and NIMService runs the deployment with probes, scaling and GPU scheduling. The NIM docs require Kubernetes 1.26 or later, the GPU Operator and NIM Operator 3.0.2 or later, and also document Helm, KServe, OpenShift and Run:ai. Our guide to hosting an LLM on Kubernetes sets the operator beside vLLM’s Helm chart, KServe and llm-d.

Metrics and logs. NIM passes the engine’s native Prometheus metrics through at /v1/metrics without renaming them, so vLLM dashboards work on vLLM-based NIMs and SGLang dashboards on SGLang ones, but they do not carry across engines. NIM_JSONL_LOGGING=true emits NIM and engine logs as JSON Lines for collectors such as Fluentd, and tracing headers pass through to the engine. Plain vLLM exposes the same metric family. Ollama’s documentation describes no Prometheus endpoint, so teams usually watch it through a proxy.

Which should an on-premises team choose?

Mixed estates are normal. Nothing stops a team running Ollama on developer machines, plain vLLM for internal tools and NIM where a support contract is required, as long as something above them decides which endpoint each request goes to.

How VDF AI fits

VDF AI does not serve models, and it does not ship, bundle or certify NVIDIA NIM. It is an on-premises and private-cloud platform for governed AI agents and multi-agent workflows, called VDF AI Networks, with private RAG over company documents, role-based access control on every plan and audit logs. Production self-hosting runs on Linux, with macOS for evaluation, as the infrastructure requirements describe.

The serving layer underneath stays your choice. VDF AI Router registers Ollama and custom on-premises deployments next to the cloud models your policy approves, prefers the local ones when they are available, and has an air-gap mode that keeps every call inside your network. It accepts OpenAI-compatible endpoints as model sources, which is how vLLM servers connect. NIM exposes an OpenAI-compatible endpoint too, but VDF AI documents no NIM integration, so treat that pairing as something to prove in a pilot rather than a supported combination.

For the licensing and layer split between the two vendors, see our VDF AI and NVIDIA AI Enterprise comparison.