GPU Splicing (Soft-MIG)

Soft-MIG as a first-class Accelerator Fabric feature, not as a simulated GPU backend. The objective is to turn one physical GPU into 2–16 independently allocatable, logical GPU resources, all capable of executing real CUDA workloads on the parent GPU. STRATUM calls this GPU Splicing, aka Soft-MIG.

Each slice is a separately schedulable STRATUM Accelerator Fabric lease. Each guest CUDA process has its own CUDA context, and its VRAM allocation comes out of the logical slice, as on MIG. STRATUM accounts for the slice budget by aggregating driver-reported GPU memory use across the VM's provider processes.

Up to 16 logical GPU allocations, each backed by the GPU's real CUDA compute engine. Nominal memory before driver overhead and reserves. The VRAM limit is enforced by STRATUM in software, not by a hardware GPU partition. Compute is time-sliced, not divided. Neither is perfect tenant isolation. This is resource scheduling and software containment, not a claim of MIG-equivalent physical isolation.

STRATUM owns this virtual GPU, and that is how we are able to accomplish this. The virtual PCI GPU device exposed to STRATUM VMs is under our control: this is where the GPU Firewall lives, where remote hosts connect to GPU providers through the STRATUM Continuum, and where STRATUM can limit and control memory per lease. "STRATUM GPU" is the single choke point.

STRATUM's virtual GPU enables multiple virtual machines to use a single supported physical GPU, without extra NVIDIA vGPU software subscriptions or NVIDIA vGPU entitlements, and without requiring a GPU to expose hardware MIG, GPU SR-IOV, or specialized IOMMU-based GPU partitioning capabilities for the Soft-MIG path. It uses ordinary host drivers and the STRATUM application, rather than installing a separate vGPU product inside your existing operating environment.

No separate MIG configuration. No NVIDIA vGPU software license. No replacement host OS. Keep the Linux system and GPU driver stack you already manage; STRATUM is delivered as a container application. Your datacenter as an application. This is the STRATUM way. Supported GPU devices must be configured and exposed to the container normally, and STRATUM Guest Tools are installed in the VM to provide its CUDA/NVML integration.

From the GPU provider host, identify the GPU, select 2–16 slices (or off to disable), apply the host configuration, then restart/reconcile STRATUM. Replace the BDF with your GPU's actual identifier.

If your installation runs stratum-host from the release directory rather than from PATH, use ./stratum-host. Reconciliation may restart container services and affect running workloads; perform the change in an approved maintenance window when needed.

Configure a VM to request a slice, for example stratum_gpu_type: h100_slice8. Each logical slice advertises a memory budget computed as (physical GPU memory − 1024 MiB reserve) ÷ number of slices. For a nominal 80 GB H100 divided into eight slices, that works out to about 9.19 GiB per slice after the reserve and decimal-GB-to-binary-GiB conversion. Driver overhead, software reserves, and actual allocatable memory may reduce usable VRAM.

Inside the VM, CUDA and nvidia-smi report the logical slice memory as that GPU's total memory. The VM cannot allocate more than its STRATUM-enforced lease budget: STRATUM tracks the NVIDIA driver-reported memory across all of that VM's provider-side processes, not just one process at a time. CUDA contexts remain independent, but execution shares the parent GPU and is scheduled over time.

Your physical GPUs can sit in conventional PCIe servers or large modern AI systems: GB300, SXM5 Bus, SXM6 Bus, NVLink 5 Cable Backplane topologies, and Superchip architectures for Grace Blackwell Ultra, including Arm architectures. The STRATUM model is to use the existing host operating system for NVIDIA drivers, InfiniBand and high-speed interconnects, then bring the supported GPU devices into the STRATUM Continuum. Support depends on the host driver stack, GPU model, available device interfaces and validated fabric integration.

STRATUM is Datacenter as an Application™. It does not replace the vendor OS and driver architecture that makes the physical hardware work. STRATUM uses that host infrastructure as the GPU provider for a VM even if the VM runs on a different CPU architecture, half way around the world, or up in space on a satellite datacenter—subject to a compatible guest architecture at its execution worker and to network latency, bandwidth and connectivity. This is the STRATUM way.

Mixed x86-64, Arm64 and s390x nodes → · GPU-over-IP architecture →

With NVIDIA MPS, one bad kernel can take down every VM on the affected shared GPU. A fatal GPU fault from one client is reported to the clients sharing the affected GPU, and the MPS server waits for those clients to exit before accepting new ones on that GPU. Abrupt exits are risky. Terminating an MPS client without synchronizing outstanding GPU work (Ctrl-C, segfault, signals) can leave the MPS server and other clients in an undefined state. VM shutdowns and a gateway's idle cleanup create exactly the kind of abrupt lifecycle events that must be accounted for.

With STRATUM virtual GPU, the GPU takes turns between tenants' contexts, and a crashing kernel is contained to its own context when the driver can isolate that fault. A STRATUM VM's slice may use at most N MiB of GPU memory, as reported by the NVIDIA driver, added up across all of that VM's provider processes. That is a different model from scheduling multiple tenants through one shared NVIDIA MPS server.

Software isolation is not hardware partitioning. Some device-wide faults can still affect other users of the same physical GPU. NVIDIA MPS has version-specific recovery and safe client-termination controls; the comparison here concerns ordinary MPS sharing and unsynchronized client exits, not a claim that those mechanisms do not exist. NVIDIA MPS error containment and client termination documentation →

STRATUM's model brings GPU virtualization, lease budgets, GPU Firewall policy and remote GPU-over-IP into one infrastructure control plane—not an assortment of individually licensed GPU partitioning technologies.