[Managed inference] Add explicit Linux amd64 profiles for Muse Glimmer and Nemotron 3.5 Lightning

[prekshivyas]

Outcome

NemoClaw can resolve Muse Glimmer 30B NVFP4 W4A4 and Nemotron 3.5 Lightning 30B NVFP4 for an explicitly requested managed vLLM installation on a compatible Linux amd64 NVIDIA GPU host.

The catalog must retain device-specific recipes as the more specific choices. This issue does not change an automatic model default.

Product decision

This issue is accepted for experimental implementation.

The implementation may add explicit-only Linux amd64 presets and recipes for these models. Catalog availability establishes technical compatibility only. It does not activate a supported platform or model combination.

The implementation must use the accepted managed-inference catalog design from Discussion #7636. It must not add a second model registry or runtime-selection authority.

Scope

• Add one Linux amd64 preset and recipe for Muse Glimmer 30B NVFP4 W4A4.
• Add one Linux amd64 preset and recipe for Nemotron 3.5 Lightning 30B NVFP4.
• Resolve an explicit NEMOCLAW_VLLM_MODEL or profile selection to the compatible Linux recipe.
• Preserve exact Spark and other device-specific selection over a general Linux match.
• Report compatibility, validation state, and rejection reasons through nemoclaw profiles list.
• Reject incompatible architecture, compute capability, GPU memory, authentication, or immutable-artifact requirements before acquisition or launch.
• Reuse the existing managed vLLM materializer, lifecycle, recovery, policy, and fixed endpoint contracts.
• Keep shipped catalog recipes free of remote model code.

Excluded scope

• No automatic default change.
• No Linux arm64 profile for either model.
• No new vLLM or llama.cpp port contract.
• No llama.cpp lifecycle, policy, receipt, or recovery change.
• No new runtime image build or custom image.
• No support activation or platform-matrix promotion.
• No unrelated Spark, Station, N1x, or model migration.

Port configuration remains separate in PR #9655. The managed llama.cpp port decision remains in issue #9644.

Ownership and lifecycle

• Product and implementation owner: Prekshi Vyas.
• Catalog and managed vLLM lifecycle: existing NemoClaw managed-inference owners and CODEOWNERS.
• Runtime lifecycle: reuse the existing managed vLLM install, status, recovery, cleanup, and resume contracts.
• Compatibility policy: each profile pins an immutable model revision and runtime image. A material artifact or serving-argument change requires a new recipe revision.
• Security review: repository review must cover authentication, immutable artifacts, GPU admission, loopback binding, and remote-code behavior.
• Validation owner: the contributor supplies exact-commit automated evidence and Linux amd64 hardware evidence. An independent operator repeats the Brev scenario before support activation.

Acceptance criteria

• Discussion RFC: Managed inference serving specifications #7636 remains the only catalog and selection architecture authority.
• PR refactor(inference): make catalog own vLLM profiles and refresh llama.cpp pins #9660 lands the declarative catalog foundation before this profile change.
• The profile change contains only the two Linux amd64 presets, two recipes, and their direct tests or documentation.
• Explicit model selection resolves each model on a compatible Linux amd64 NVIDIA GPU host.
• Exact device-specific recipes take precedence over the general Linux recipes.
• Linux arm64 and incompatible GPUs fail before model or image acquisition.
• The selected recipe enforces its compute-capability and GPU-memory requirements.
• The materialized server requires bearer authentication, uses immutable artifacts, binds through the existing loopback contract, and does not enable remote model code.
• nemoclaw profiles list reports the profile state and a concrete incompatibility reason.
• Catalog compiler, resolver, host-local materialization, and package-contract tests pass.
• Exact-commit Brev validation passes for model discovery, authenticated chat, tool calling, streaming, restart, recovery, loopback binding, policy rendering, and cleanup.
• A maintainer records a separate decision before any support claim or platform-matrix promotion.

Evidence available

Earlier development on PR #9537 completed both model flows on an x86_64 Brev RTX PRO Server 6000. That evidence guides the bounded implementation but must be repeated against the final commit under review.

Dependencies and related work

• Accepted architecture: Discussion RFC: Managed inference serving specifications #7636
• Declarative catalog foundation: PR refactor(inference): make catalog own vLLM profiles and refresh llama.cpp pins #9660
• Original combined implementation: PR feat(inference): add Linux amd64 Muse and Lightning profiles #9537
• Separate vLLM port change: PR fix(inference): honor configured managed vLLM ports #9655
• Separate managed llama.cpp port decision: issue [Managed inference] Decide whether managed llama.cpp may use a configured host port #9644

Signed-off-by: Prekshi Vyas prekshiv@nvidia.com