What's New in Version 2.26

The NVIDIA Run:ai v2.26 what's new provides a detailed summary of the latest features, enhancements, and updates introduced in this version. They serve as a guide to help users, administrators, and researchers understand the new capabilities and how to leverage them for improved workload management, resource optimization, and more.

Important

For a complete list of deprecations, see Deprecation notifications. Deprecated features, APIs, and capabilities remain available for two versions from the time of the deprecation notice, after which they may be removed.

NVIDIA Run:ai MCP Server

The NVIDIA Run:ai MCP server exposes cluster and workload data to AI coding assistants (such as Claude Code, Cursor, and VS Code with GitHub Copilot) through the Model Context Protocol (MCP) open standard. Once connected, your AI assistant can access NVIDIA Run:ai directly - AI practitioners can ask why a workload is stuck or failing, while platform admins can check GPU availability, inspect GPU utilization across projects, or diagnose node-level issues. The server is read-only in this release and supports two deployment modes: local (each user runs a Docker container) and remote (an administrator deploys a shared server). See MCP server for setup instructions. From cluster v2.25 onward

AI Practitioners

Workloads

Enhanced workload structure and inspection - Supported workload types include an enhanced Structure view that visualizes workload hierarchy, workload elements, resource allocations, pod counts, and exposed endpoints, providing greater visibility into complex workloads directly from NVIDIA Run:ai. See Structure for more details. From cluster v2.26 onward
- Expanded structure view - Displays workload hierarchies in a full-screen view, making complex, multi-element workloads easier to navigate.
- Per-element inspection - Displays element-specific metrics, pods, logs, terminal access, and YAML for the selected workload element. Event history and workload details remain scoped to the top-level workload.
- Workload element YAML - Displays the live Kubernetes custom resource for a workload, workload element, or pod, including the current spec, status, and metadata. The YAML can be copied or downloaded for further investigation.
- Connection endpoints - Displays exposed workload endpoints directly within the workload structure for easier discovery and access.
- Workload details for supported workload types - Extends the workload Details experience to supported workload types, providing access to configuration, runtime information, resources, and workload structure.
Actual topology placement per workload element (API) - For multi-component workloads (such as Dynamo over Grove), the Workloads API returns the actual topology placement of each workload element, making it possible to verify where each element's pods were scheduled within the network hierarchy. Workload-level actual placement is also returned for any distributed workload whose node pool is attached to a topology, regardless of whether topology constraints were applied. See Accelerating workloads with network topology-aware scheduling for more details. From cluster v2.25 onward
Workloads v2 API enhancements - The Workloads v2 API supports PersistentVolumeClaims and user credentials as part of the workload specification, allowing these resources to be created and managed alongside workloads. See Workloads v2 API for more details. From cluster v2.26 onward
- PersistentVolumeClaims (PVCs) - Create PersistentVolumeClaims as part of the workload definition, enabling workloads to provision and use storage without requiring pre-existing PVCs.
- User credentials - Reference user credentials directly from workload definitions without exposing secret values in the workload manifest.
Private NGC repository support for AI applications - AI applications support private NGC Helm repositories. When a private repository is selected as the chart source, users are prompted to provide an NGC API key credential to authenticate with the repository before browsing and selecting charts. See AI Applications for more details. From cluster v2.26 onward
Suspend and resume workloads - NVIDIA Run:ai supports suspend and resume operations for any workload type that defines suspend behavior in its Karta description, extending workload lifecycle management beyond native NVIDIA Run:ai workloads. Users can suspend and resume supported workloads through both the UI and API, providing a consistent management experience across workload types. Supported workload types include CronJob, Job, PyTorchJob, RayJob, and TFJob. See Workloads for more details. From cluster v2.26 onward

Known Kubernetes Issue

A known Kubernetes issue can cause batch job workload types (such as Job, PyTorchJob, and RayJob) to get stuck in the Resuming state. The issue is fixed in Kubernetes v1.32.9, v1.33.6, v1.34.2, and v1.35.0 (or newer). Upgrade to a fixed Kubernetes release to resolve this.

Platform Administrators

Node Pools

NUMA-aware scheduling for node pools - Administrators can now enable NUMA-aware scheduling per node pool. When enabled, the Scheduler places workloads so that GPU, CPU, and CPU memory are allocated within the same NUMA node where possible, minimizing cross-NUMA fragmentation and improving performance on multi-NUMA servers such as DGX H100. When disabled, the Scheduler places workloads using aggregate node capacity only, without considering NUMA topology. Requires NFD deployed with the topology updater enabled and a Topology Manager policy other than none on the pool's nodes. Disabled by default. See Configuring NUMA-Aware Scheduling for more details. From cluster v2.26 onward
GPU device-level placement strategy for node pools - Node pools support a separate device placement strategy for GPU pods in addition to the node placement strategy. The device placement strategy (Bin-pack or Spread) determines how GPU workloads are distributed across GPU devices within each node. This helps fractional distributed workloads: for example, bin-pack at the node level to use fewer nodes while spreading at the device level so pods land on different GPUs within a node. See Node pools for more details. TBD From cluster v2.26 onward

Network Topologies

Grove topology integration (API) - NVIDIA Run:ai network topologies can be linked to a corresponding Grove ClusterTopology. Once linked, NVIDIA Run:ai surfaces the Grove topology name and levels through the Network Topologies API, allowing users to identify the correct topology for their target node pool without needing to understand the underlying Grove topology configuration. See Accelerating workloads with network topology-aware scheduling for more details.

Policies

Workload policies for any supported workload type - Workload policies support any supported workload type, extending policy governance beyond native NVIDIA Run:ai workloads. NVIDIA Run:ai provides built-in policy mappings for a wide range of supported workload types, so administrators can create policies immediately without additional configuration. Policies can define workload requirements, constraints, defaults, and enforcement actions. See Supported workload types policies for more details. To extend policy support to additional workload types introduced to the platform, administrators can define mappings using the Policy Mappings API. See Workload types policy mapping for more details. Experimental From cluster v2.26 onward

Authentication and Authorization

Access rule transition for legacy roles - Due to the deprecation of some roles, referred to as legacy roles, access rules using them should be transitioned to supported roles. The Access rules page surfaces a banner when rules still use legacy roles, and a new dialog lets admins map each legacy role to its replacement. Selected rules are recreated under the new role with the same subject and scope, and the legacy rules are deleted. See Access rules for more details. From cluster v2.25 onward
Full name display for users - Users now appear by their full name next to their email, in the format Full Name (email), wherever they show up in the platform. First and last names can be set for local users when they are created or edited; names for SSO users are sourced from the identity provider, and the email is shown on its own when no name is available. A new User Minimal Read Access permission (users-minimal) provides the minimal access needed to display user names. It is included by default in some predefined roles and can be added to custom roles. See Users and Roles for more details.

General Enhancements

Permission-aware General settings - The General settings reflects the user's settings permissions. The page is visible only when the user has at least one settings permission with CRUD (Create, Read, Update, Delete) access; if all of the user's settings permissions are read-only, the page is not visible (matching the existing behavior). See General settings and Roles for more details.

Infrastructure Administrators

System Requirements

NVIDIA Run:ai supports Kubernetes version 1.36.

Transition Notices

NVIDIA Run:ai is transitioning GPU fractions from its current proprietary sharing engine to technology built directly into NVIDIA CUDA. This moves GPU sharing onto the standard NVIDIA stack for broader industry compatibility and long-term NVIDIA maintenance. The NVIDIA Run:ai experience, APIs, YAML definitions, and workload management workflows are not changing.

Current release (v2.26) - Uses the existing GPU fractions engine. No changes, no action required.
Future releases - CUDA-based fractions will replace the legacy engine. This upgrade will require updated CUDA driver and GPU Operator versions on all GPU nodes. GPU fractions will be disabled until both requirements are in place; all other workloads will continue to run normally. Once the stack requirements are met, fractions re-enable automatically with no further Run:ai upgrade needed.

What to do now

No action is required today; v2.26 is fully supported.
Review your current CUDA driver and GPU Operator versions to prepare for upcoming stack requirements.
Plan a maintenance window for the future stack upgrade - GPU fractions will need to be suspended during the upgrade.

For questions, contact your NVIDIA Run:ai account team.

Deprecation Notifications

Note

Deprecated features, APIs, and capabilities remain available for two versions from the time of the deprecation notice, after which they may be removed.

GPU Memory SWAP

GPU Memory SWAP will be deprecated and removed from future releases. GPU Memory SWAP is being replaced by Snapshot, an improved NVIDIA-native capability built on CUDA Checkpoint / Restore. Snapshot captures the full state of a Kubernetes Pod, releases idle GPU and CPU memory, and reduces cold-start time when workloads resume. No immediate action is required as part of this release. GPU Memory SWAP remains fully supported in NVIDIA Run:ai v2.26.

TensorFlow, XG Boost, and JAX

The TensorFlow, XG Boost, and JAX distributed frameworks are deprecated and will be removed in a future release. These frameworks are based on Kubeflow Training Operator v1 CRDs, which are deprecated upstream. As a result, submitting workloads using these frameworks as native NVIDIA Run:ai distributed workload types is also deprecated. See Distributed training for supported frameworks.

Resource Interfaces to Kartas

The Resource Interface feature has been renamed to Karta across NVIDIA Run:ai. The resourceInterfaces API field is deprecated and will be removed in a future release. See Extending workload support with Karta for more details.

Node Type

The Node Type feature is deprecated and will be removed in a future release. To control workload placement on specific nodes, use workload policies with node affinity instead of the nodeType field in organization unit or workload definitions. See NVIDIA Run:ai native workload policies for more details.

Legacy Workload Submission

The legacy workload submission form is deprecated and will be removed in a future release. Submitting workloads through the legacy form is being replaced by flexible workload submission, which lets you select an existing setup or start from scratch, review existing setups, and understand policy definitions. We recommend transitioning to flexible workload submission, which is enabled by default. If it has been disabled, re-enable it under General settings → Workloads → Flexible workload submission.

API Deprecation Notifications

Deprecated Endpoints

Deprecated Endpoint

Replacement Endpoint

/api/v1/logo

/api/v1/branding/settings/logo

/api/v1/org-unit/node-type

N/A

Deprecated Parameters

Endpoint

Deprecated Parameter

Replacement Parameter

/api/v2/workloads

resourceInterfaces

kartas

/api/v1/node-pools

schedulingConfiguration.placementStrategy

gpuPodsPlacementStrategy + cpuPodsPlacementStrategy