## Granular Control of Your EKS Auto Mode Managed Nodes with Custom Node Classes and Node Pools

With a couple of releases back, we added [EKS Auto Mode](https://aws.amazon.com/eks/auto-mode/) support in our platform for doing either quick configuration or custom configuration. In this blog, we will explore how you can create an EKS cluster using quick configuration and then dive deep into creating custom node classes and node pools using addons to deploy them on EKS Auto Mode enabled clusters.

## Self-Service Fractional GPU Memory with Rafay GPU PaaS

In [**Part-1**](https://docs.rafay.co/blog/2025/11/01/self-service-fractional-gpus-with-rafay-gpu-paas/), we explored how Rafay GPU PaaS empowers developers to use fractional GPUs, allowing multiple workloads to share GPU compute efficiently. This enabled better utilization and cost control — without compromising isolation or performance.

In **Part-2**, we will show how you can enhance this by provide users the means to select **fractional GPU memory**. While fractional GPUs provide a share of the GPU’s compute cores, different workloads have dramatically different GPU memory needs. With this update, developers can now choose exactly how much GPU memory they want for their pods — bringing fine-grained control, better scheduling, and cost efficiency.

## Self-Service Fractional GPUs with Rafay GPU PaaS

Enterprises and GPU Cloud providers are rapidly evolving toward a self-service model for developers and data scientists. They want to provide instant access to high-performance compute — especially GPUs — while keeping utilization high and costs under control.

Rafay GPU PaaS enables enterprises and GPU Clouds to achieve exactly that: developers and data scientists can spin up resources such as Developer Pods or Jupyter Notebooks backed by fractional GPUs, directly from an intuitive self-service interface.

This is **Part-1** in a multi-part series on end user, self service access to **Fractional GPU** based AI/ML resources.

## GPU Resource Management in Kubernetes: From Extended Resource to DRA

This blog is part of our DRA series, continuing from our earlier posts: [Introduction to DRA](https://docs.rafay.co/blog/2025/08/23/introduction-to-dynamic-resource-allocation-dra-in-kubernetes/), [Enabling DRA with Kind](https://docs.rafay.co/blog/2025/08/28/enable-dynamic-resource-allocation-dra-in-kubernetes/), and MIG with DRA . This post focuses on pre-DRA vs post-DRA GPU management on Rafay upstream Kubernetes clusters.

## NVIDIA NIM Operator: Bringing AI Model Deployment to the Kubernetes Era

In the [previous blog](https://docs.rafay.co/blog/2025/10/20/nvidia-nim-why-it-mattersand-how-it-stacks-up/), we learnt the basics about NIM (NVIDIA Inference Microservices). In this follow-on blog, we will do a deep dive into the **NIM Kubernetes Operator**, a Kubernetes-native extension that automates the deployment and management of NVIDIA’s NIM containers. By combining the strengths of Kubernetes orchestration with NVIDIA’s optimized inference stack, the NIM Operator makes it dramatically easier to deliver production-grade generative AI at scale.

## NVIDIA NIM: Why It Matters—and How It Stacks Up

Generative AI is moving from experiments to production, and the bottleneck is no longer training—it’s serving: getting high-quality model inference running reliably, efficiently, and securely across clouds, data centers, and the edge.

NVIDIA’s answer is [NIM (NVIDIA Inference Microservices)](https://www.nvidia.com/en-us/ai-data-science/products/nim-microservices/). NIM a set of prebuilt, performance-tuned containers that expose industry-standard APIs for popular model families (LLMs, vision, speech) and run anywhere there’s an NVIDIA GPU. Think of NIM as a “batteries-included” model-serving layer that blends TensorRT-LLM optimizations, Triton runtimes, security hardening, and OpenAI-compatible APIs into one deployable unit.

## Dynamic Resource Allocation for GPU Allocation on Rafay's MKS (Kubernetes 1.34)

This blog demonstrates how to leverage **Dynamic Resource Allocation (DRA)** for efficient GPU allocation using **Multi-Instance GPU (MIG)** strategy on Rafay's Managed Kubernetes Service (MKS) running Kubernetes 1.34.

In our previous blog series, we covered various aspects of Dynamic Resource Allocation (DRA) in Kubernetes:

- **[Introduction to Dynamic Resource Allocation (DRA) in Kubernetes](https://docs.rafay.co/blog/2025/08/23/introduction-to-dynamic-resource-allocation-dra-in-kubernetes/)** — what it is and why it matters
- **[Enable Dynamic Resource Allocation (DRA) in Kubernetes](https://docs.rafay.co/blog/2025/08/28/enable-dynamic-resource-allocation-dra-in-kubernetes/)** — configuring DRA on a Kubernetes 1.34 cluster using kind
- **[Deploy Workload using DRA ResourceClaim/ResourceClaimTemplate in Kubernetes](https://docs.rafay.co/blog/2025/09/16/deploy-workload-using-dra-resourceclaim-in-kubernetes/)** — deploying and managing DRA workloads natively on Kubernetes

DRA is GA in Kubernetes 1.34

With Kubernetes 1.34, Dynamic Resource Allocation (DRA) is **Generally Available (GA)** and **enabled by default** on MKS clusters. This means you can immediately start using DRA features without additional configuration.

### [Prerequisites](https://docs.rafay.co/blog/2025/10/06/dynamic-resource-allocation-for-gpu-allocation-on-rafays-mks-kubernetes-134/#prerequisites)

Before we begin, ensure you have:

- A Rafay MKS cluster running Kubernetes 1.34 (see [MKS v1.34 Blog](https://docs.rafay.co/blog/2025/10/06/kubernetes-v134-for-rafay-mks/))
- GPU nodes with compatible NVIDIA GPUs (A100, H100, or similar MIG-capable GPUs)
- Container Device Interface (CDI) enabled (automatically enabled in MKS for Kubernetes 1.34)
- Basic understanding of Dynamic Resource Allocation concepts (covered in our [previous blog series](https://docs.rafay.co/blog/2025/08/23/introduction-to-dynamic-resource-allocation-dra-in-kubernetes/))
- Active Rafay account with appropriate permissions to manage MKS clusters and addons

## Kubernetes v1.34 for Rafay MKS

As part of our continuous effort to bring the latest Kubernetes versions to our users, support for [Kubernetes v1.34](https://kubernetes.io/blog/2025/08/27/kubernetes-v1-34-release/) will be added soon to the Rafay Operations Platform for MKS cluster types.

Both new cluster provisioning and in-place upgrades of existing clusters are supported. As with most Kubernetes releases, this version also deprecates and removes a number of features. To ensure there is zero impact to our customers, we have made sure that **every feature** in the Rafay Kubernetes Operations Platform has been validated on this Kubernetes version. This will be promoted from Preview to Production in a few days and will be made available to all customers.

## Deploy Workload using DRA ResourceClaim in Kubernetes

In the [**first blog**](https://docs.rafay.co/blog/2025/08/23/introduction-to-dynamic-resource-allocation-dra-in-kubernetes/) in the DRA series, we introduced the concept of Dynamic Resource Allocation (DRA) that recently went GA in [Kubernetes v1.34](https://kubernetes.io/blog/2025/08/27/kubernetes-v1-34-release/) which was released end of August 2025.

In the [**second blog**](https://docs.rafay.co/blog/2025/08/28/enable-dynamic-resource-allocation-dra-in-kubernetes/), we installed a Kuberneres v1.34 cluster and deployed an example DRA driver on it with "simulated GPUs". In **this blog**, we’ll will deploy a few workloads on the DRA enabled Kubernetes cluster to understand how "Resource Claim" and "ResourceClaimTemplates" work.

Info

We have optimized the steps for users to experience this on their laptops in less than 5 minutes. The steps in this blog are optimized for macOS users.

## GPU/Neo Cloud Billing using Rafay’s Usage Metering APIs

Cloud providers offering GPU or Neo Cloud services need accurate and automated mechanisms to track resource consumption. Usage data becomes the foundation for billing, showback, or chargeback models that customers expect. The Rafay Platform provides usage metering APIs that can be easily integrated into a provider’s billing system.

In this blog, we’ll walk through how to use these APIs with a **sample Python script** to generate detailed usage reports.