NVIDIA GRID and vGPU: current guide to enterprise GPU virtualization

NVIDIA GRID is the name many administrators still use for NVIDIA’s enterprise GPU-virtualization stack. In current NVIDIA documentation, the platform is called NVIDIA virtual GPU (vGPU) software.

The basic idea remains the same: a supported NVIDIA GPU in a server can provide accelerated graphics or compute to virtual machines. Depending on the deployment, one physical GPU can be shared by several VMs through vGPU profiles, divided through Multi-Instance GPU (MIG), or assigned whole to one VM through GPU pass-through.

This guide explains what the GRID name means today, how vGPU works, which software edition fits each VDI workload, and what to verify before deployment. It deliberately avoids fixed “users per GPU” promises because real capacity depends on the application, frame-buffer demand, display configuration, CPU, storage, network, and user behavior.

What NVIDIA GRID means today

GRID survives as a search term, a historical product name, and part of older file and service names. NVIDIA’s current product family is documented as NVIDIA vGPU software.

• NVIDIA GRID: Legacy umbrella name for NVIDIA’s virtualized graphics and workstation products.
• NVIDIA vGPU: The current software and architecture for exposing supported NVIDIA GPU resources to virtual machines.
• GPU pass-through: A whole physical GPU assigned to one VM instead of shared through vGPU profiles.
• NVIDIA vApps: Licensed product for published applications, RDSH, and session-based desktops.
• NVIDIA Virtual PC (vPC): Licensed product for knowledge-worker virtual desktops.
• NVIDIA RTX Virtual Workstation (RTX vWS): Licensed product for professional graphics, CUDA-enabled workstation, design, and visualization workloads.

The old GRID K1, K2, K100, and K200-family profile names are useful only when maintaining legacy systems. They should not be used to size a new deployment. NVIDIA’s current virtual GPU type reference lists the profiles available for supported GPUs and the license edition each profile requires.

How NVIDIA vGPU works

NVIDIA vGPU software adds a host component and a guest component to the virtualization stack:

• NVIDIA Virtual GPU Manager runs on the supported hypervisor host and manages access to the physical GPU.
• The NVIDIA guest driver runs inside each VM and exposes the assigned vGPU to the guest operating system and applications.
• A vGPU profile defines properties such as frame-buffer allocation, supported displays, resolution, and the licensed product intended for the VM.
• NVIDIA License System supplies licenses to products and deployments that require them.

A display protocol and VDI platform then deliver the remote session. NVIDIA vGPU accelerates the VM; it does not replace Citrix Virtual Apps and Desktops, Omnissa Horizon, RDSH, or another desktop-delivery and brokering layer.

GPU pass-through is different. It dedicates one physical GPU to one VM, which can simplify isolation and give that VM access to the full device. vGPU improves density and allocation flexibility when several VMs need accelerated resources. The right choice depends on the application, supported platform, and operational model rather than a universal performance rule.

Choose the software edition by workload

NVIDIA currently packages three vGPU desktop and application products. The packaging and licensing guide is the authoritative source for current entitlements.

• vApps: Best for published Windows applications, RDSH, and session-based desktops. It is built for app and session delivery rather than a personal workstation VM.
• vPC: Best for knowledge-worker VDI, browsers, office applications, video, and multiple displays. It does not include the professional graphics and CUDA entitlements of RTX vWS.
• RTX vWS: Best for CAD, CAE, 3D, visualization, creative applications, and workstation-class AI development. Its higher entitlement and licensing requirements should be justified by the workload.

NVIDIA’s edition comparison makes a practical distinction: vPC targets knowledge-worker VDI, while RTX vWS adds features such as the RTX Enterprise driver, professional application certifications, CUDA and OpenCL support, larger profiles, and higher display limits.

Understand vGPU profiles before sizing

Profile names encode more than capacity. On current products, A-series profiles are associated with virtual applications, B-series with virtual PCs, and Q-series with virtual workstations. The number in a profile generally reflects its frame-buffer allocation, but the complete profile table must be checked for the exact GPU and software release.

The old rule that every time-sliced vGPU on a physical GPU must use an identical profile is no longer generally correct. Current NVIDIA documentation says supported GPUs can mix A-, B-, and Q-series time-sliced profiles when the GPU or GPU instance is configured for mixed-size mode and the total allocated frame buffer stays within capacity. Equal-size mode remains the default. Some supported GPUs also provide MIG-backed vGPU profiles with different isolation and allocation behavior. See NVIDIA’s current configuration rules before designing around either mode.

Do not turn a profile table into a user-density guarantee. Test representative workloads and measure frame-buffer use, GPU utilization, encode load, host CPU, memory, storage latency, network latency, and session quality. A CAD engineer, a video editor, and an office user can place radically different demands on the same nominal profile.

Check the complete support combination

A GPU model being listed as vGPU-capable does not prove that every hypervisor, guest OS, VDI platform, and feature combination is supported. Validate the whole stack against the release you plan to deploy:

1. Physical GPU and certified server
2. vGPU software release branch
3. Hypervisor and exact version
4. Guest operating system
5. VDI or remote-display platform
6. vGPU profile and required license edition

The NVIDIA product support matrix is the starting point. It includes separate matrices for VMware vSphere, XenServer, Windows Server, Azure Local, Red Hat Enterprise Linux with KVM, Ubuntu, and vendor-supported Linux/KVM platforms. For example, the VMware vSphere matrix and Linux/KVM matrix contain different hardware, software, and support conditions.

Avoid copying a generic installation command from an old article. Package format, installation workflow, supported versions, and required host settings vary by hypervisor and release. Use the current release notes and quick-start guide for the selected platform.

How NVIDIA vGPU licensing works

vApps, vPC, and RTX vWS are licensed products. NVIDIA offers concurrent-user licensing and publishes subscription and perpetual options; available models and commercial terms can change, so procurement should use the current packaging guide rather than prices copied into an article.

For networked licensing, NVIDIA License System can serve a pool of licenses through a cloud-hosted Cloud License Service (CLS) instance or an organization-hosted Delegated License Service (DLS) instance. Licensed clients use a configuration token to locate the service and request the appropriate license. NVIDIA documents the current setup in its licensing quick start.

A vGPU that requires a license does not simply remain fully functional forever without one. NVIDIA documents reduced capability when a required license is not acquired. Licensing connectivity and failover therefore belong in the deployment design, not at the end of a pilot.

A safer NVIDIA vGPU deployment sequence

1. Classify users by actual application. Separate published apps, knowledge-worker desktops, professional graphics, and CUDA-enabled workstation workloads.
2. Select the edition. Map each group to vApps, vPC, or RTX vWS before selecting profiles.
3. Lock a supported stack. Record the GPU, certified server, hypervisor, guest OS, VDI platform, vGPU release, and profile.
4. Install matched host and guest components. Follow the release-specific instructions and compatibility rules.
5. Configure licensing. Choose CLS or DLS, deploy client configuration tokens, and test failure and recovery behavior.
6. Run a representative pilot. Include normal and peak sessions, real datasets, display layouts, peripherals, and network paths.
7. Measure before increasing density. Track the limiting resource and leave operational headroom.

Common NVIDIA GRID and vGPU mistakes

• Using a legacy K1, K2, M6, M10, or M60 table as a current recommendation. Older GPUs can remain supported in some release combinations, but new deployments need the current hardware and platform matrices.
• Assuming a fixed number of users per GPU. User density is a test result for a defined workload, not a universal hardware specification.
• Treating vGPU and pass-through as synonyms. One shares or partitions supported GPU resources; the other assigns a whole device to one VM.
• Assuming all mixed profiles are unsupported. Current mixed-size mode can support combinations that older releases could not.
• Ignoring licensing until production. A pilot that has not tested license acquisition, renewal, and failure behavior is incomplete.
• Calling every cloud GPU VM an enterprise VDI solution. A GPU-backed server and a managed multi-user desktop stack solve different problems.

NVIDIA vGPU versus a GPU virtual machine

NVIDIA vGPU is a technology and licensed software stack for exposing supported NVIDIA GPU resources to VMs. Enterprise VDI combines that GPU layer with desktop delivery, identity, policy, images, profiles, monitoring, and user support.

A GPU virtual machine is a server-shaped environment with GPU access. Compute with Hivenet provides Linux VMs and containers for AI, rendering, development, and other GPU-heavy workloads, with instance selection and SSH access documented in the Compute instance guide. It is not presented as a drop-in replacement for NVIDIA vGPU-based enterprise VDI.

Choose an enterprise vGPU stack when you need centrally managed multi-user applications, desktops, or professional workstations. Choose a general GPU VM when you need control of a compute environment for a workload and do not need the VDI delivery and brokering layer.

FAQs about NVIDIA GRID and vGPU

Is NVIDIA GRID discontinued?

The GRID name is legacy terminology. NVIDIA’s current documentation and product pages use NVIDIA vGPU software, vApps, vPC, and RTX vWS. Older deployments and file names may still contain “GRID.”

Can NVIDIA vGPU run on a consumer GeForce card?

Do not infer support from the GPU architecture or driver alone. Use the current NVIDIA product support matrix and a certified server configuration. Consumer GeForce availability in an ordinary VM does not make that VM a supported NVIDIA vGPU deployment.

Does NVIDIA vGPU support CUDA in a VM?

RTX vWS includes CUDA and OpenCL support for workstation-class workloads. vPC does not carry the same compute entitlement. For server AI, deep-learning, or HPC deployments, check NVIDIA AI Enterprise and the applicable support documentation rather than assuming a vPC profile is suitable.

Can different vGPU profiles share one physical GPU?

Current time-sliced vGPU software can support mixed A-, B-, and Q-series profiles on a physical GPU in mixed-size mode, subject to GPU, release, frame-buffer, and platform limits. Equal-size mode remains the default, and not every profile is available on every GPU.

What should be checked before buying licenses?

Confirm the workload, software edition, concurrent-user count, deployment model, support term, and the complete hardware and hypervisor combination. Then verify the current commercial terms with NVIDIA or an authorized partner.

‍