From the NVIDIA edition of September 15, 2026
NIM LLM 2.0.12 release notes document profile-specific correctness and OOM constraints
NVIDIA · AI platform vendor documentation · Global
- Publisher
- NVIDIA NIM for Large Language Models release notes
- Original publication
- NIM LLM/VLM 2.0.12 documentation (retrieved 2026-09-15)
- Source retrieved
- 2026-09-15
What happened
NIM 2.0.12 adds models and moves to vLLM 0.27.1, but known issues include NVFP4 nemotron-3-nano semantic incorrectness (no workaround—use BF16/FP8), Responses API correctness limits, LoRA rank <=128 on some MoE kernels, KV-cache OOM at default 131k context on several profiles, and GB10 completion timeouts under specific large-request settings.
Why it matters
SLED engineering teams must treat support-matrix profiles as operational controls: precision, context length, and GPU SKU choices can change correctness and availability, not only speed.
Evidence and measured results
Opened release notes list Highlights, Bug Fixes, and Known Issues with explicit workarounds (NIM_MAX_MODEL_LEN, NIM_KVCACHE_PERCENT, LoRA rank caps) and statements that some issues have no workaround in 2.0.12.
Limitations and uncertainty
Vendor documentation of known issues; does not quantify incidence in customer fleets. Version-specific—verify against the deployed tag.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-09-15; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Buyers assume container tags are universally production-safe across GPUs and precisions.
- Stakeholders
- platform owner
- app owner
- security QA
- Discovery questions
- Which profiles are approved for production?
- What correctness tests exist per precision?
- What is the upgrade cadence?
- Value hypothesis
- Explicit profile governance reduces failed demos and silent quality regressions.
- Potential engagement
- Profile selection workshop using the 2.0.12 known-issues matrix.
- Unsupported claims
- All listed models are equally correct on all GPUs
- Default 131k context fits every SKU
Pre-sales engineering
Role takeaway
- Fit
- Fit as the inference microservice layer when profiles are pinned and known issues mitigated.
- Architecture and integration
- Deploy via NIM containers/Operator with env for max model len, KV cache percent, and LoRA rank limits.
- Prerequisites
- Support-matrix review
- NGC auth
- GPU memory headroom
- Regression eval set
- Constraints
- Profile-specific OOM
- Precision-specific incorrect output
- Endpoint timeouts on slower GPUs
- Security
- Keep exploration and production endpoints separated to limit blast radius of buggy profiles.
- Proof of value
- Startup success on target GPU
- Eval suite pass on chosen precision
- Documented workarounds applied
Delivery
Role takeaway
- Work
- Upgrade planning, profile pinning, and acceptance testing against known issues.
- Dependencies
- ML platform
- app teams
- NVIDIA support entitlement
- Ownership
- Platform team owns base NIM; app teams own eval gates.
- Skills and adoption
- Operators need to read release notes and map issues to configs.
- Governance checkpoints
- Pre-prod soak
- Correctness sign-off
- Rollback tag ready
- Acceptance criteria
- No critical known-issue unmitigated
- SLOs met on pinned profile
- Runbook updated
- Risks
- Blind tag bumps
- Using NVFP4 where correctness required
- Ignoring context-length OOM
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
Pin approved profiles per environment; separate exploration profiles from production; encode context-length and KV-cache percent into Helm/NIMService defaults.
Governance
Who approves, reviews and stays accountable for outcomes?
Change control should require release-note review before upgrading NIM in production branches used by agencies or campuses.
Security and privacy
What data, permissions and controls need testing?
Incorrect outputs on certain precisions are a safety/quality risk for decision-support agents; treat precision choice as a trust-boundary decision.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Broken or slow profiles disproportionately harm student/staff-facing assistants if defaults are left unpinned.
Procurement
What should contracts, pricing and exit terms secure?
Subscriptions should include obligation to track lifecycle/known issues and support matrix changes.
Operating model
Which teams own the service once it runs?
Establish a standing NIM release-review ritual across platform and application owners.
Publication history
- 2026-09-15NVIDIA · Issue 1010 resources
Stable resource ID: nvidia-nim-llm-2012-known-issues-correctness-2026