The operating system controls how much of each GPU your workloads use, and it's the layer I rarely see teams tune. The kernel turns the devices on, configures them, and controls how data streams from storage to the accelerator. I've asked people which OS their inference runs on and been told "Kubernetes."
TorchVision has one flag that decides whether vision work runs on the GPU or the CPU. I keep finding it set to CPU, and we did it once ourselves, by accident, in a build. Everything works, and that process never uses the GPU you bought for it.
Rocky Linux from CIQ Pro AI (RLC Pro AI) is Enterprise Linux with a current kernel, tested GPU drivers, and AI frameworks already working together, backed by a support SLA. This post follows the second part of my session at AI Infrastructure Field Day.
Deploy a GPU node in minutes with a stack that's already assembled
On other distributions, setting up a new GPU node means finding the right driver, downloading and compiling kernel modules, adjusting boot parameters, and rebooting before you install a framework that matches. If a package is missing or a version doesn't match when you compile, you fix it and go through the cycle again.
RLC Pro AI ships CUDA, the NVIDIA drivers, and frameworks such as PyTorch and Ollama tested together. Happy-path node deployment takes 3 minutes 44 seconds, with nothing to assemble first. When we did the same setup by hand on community Rocky Linux and on Ubuntu, the best case was about 30 minutes [VERIFY: the 30-minute manual baseline has no claim file; Brian ruled it sourced on 2026-09-21].
A delegate asked what "validated" means.
"Validated" means we took specific versions of the kernel, driver, CUDA toolkit, and framework, tuned and pinned them, tested them together, and benchmarked for regressions.
RLC Pro AI is the first Enterprise Linux-compatible distribution authorized to ship the full NVIDIA AI stack, so the drivers and CUDA come inside the OS.
Run a current kernel without maintaining one
Fixed enterprise kernels trail new GPU generations and CUDA releases, by as much as 18 months [VERIFY: the kernel-lag claim is pending]. Enterprise distributions backport some hardware support into an older kernel, but you can't count on a given improvement coming along.
The CIQ Linux Kernel (CLK) in RLC Pro AI is built from the current upstream long-term release, 6.18. A newer kernel is easy to find. One with security patches and a team to call is not.
The speed of a newer kernel comes from upstream work, and I don't want to overstate our part. When I benchmarked storage against an older enterprise kernel, reads from NVMe were faster on the newer kernel because the upstream scheduler had improved. Our part is building the CLK, patching it, and supporting it.
We also publish a result that includes our tuning. It's on the RLC Pro AI page: with the tuned kernel profile on the host, RLC Pro AI had 18% more model-loading throughput than Ubuntu 24.04 with the HWE kernel, on a cold 8 GiB read from NVMe.
Some trading firms hire engineers specifically to tune kernels, and they don't want systems taken down to patch them. Firms like that have started coming to us for a supported kernel. In RLC Pro AI, they get it the way they'd get any other kernel package: it's in the repository, and when a CVE or a bug advisory affects it, we patch it and the repository updates.
If you'd rather watch than read, you can watch the full segment.
Know what configuration management can't change
One delegate played devil's advocate: can't you do all of this with Ansible, Puppet, or Chef? You can. We're open about the settings, and anyone can change them. We tune memory allocation and transparent huge pages, and RLC Pro AI includes a kernel profile tuned for model loading and inference.
Tuning that ships in the OS does more than automation you run after install. Some parameters are set when the kernel, the drivers, and CUDA are compiled, so automation that runs after install can't change them. And running automation against a node several times to configure it is a different job from installing an OS that's already tuned.
The same goes for golden images. A skilled engineer can build one. But the kernel, the drivers, CUDA, and the frameworks all release on their own schedules, so that engineer rebuilds the image again and again. Engineers who can do this work are hard to hire, and I'd rather they spent their time higher in the stack.
Keep containers and hosts on the same versions
AI workloads are distributed as containers, so RLC Pro AI includes a container family in four tiers: base, runtime, devel, and workload. The devel image is free to use.
The containers and the host OS come from one vendor and are versioned together. A host driver upgrade doesn't mean rebuilding the container, and the container you pull onto a laptop runs the same validated environment in production.
You can mix. An RLC Pro AI container runs on another Linux distribution, and other containers run on an RLC Pro AI host [VERIFY: this is from the talk; the runs-anywhere claim file is an empty draft and the live page doesn't say whether CIQ supports an RLC Pro AI container on another distribution]. The kernel gains come only with the RLC Pro AI host.
A container brings its own user space and runs on the host kernel, so kernel tuning has to come from the host OS.
Measure the gain on your own workload
In one test, RLC Pro AI ran image segmentation 32% faster than Ubuntu on identical NVIDIA A30 hardware (COCO dataset, 138 runs, 95% confidence interval) [VERIFY: the per-workload claim segmentation-32pct-ubuntu was retired on 2026-09-21; its replacement, "up to 32% for image inference," is pending]. That's one of our best results under one set of conditions. Your bus, memory, processors, and usage patterns will differ, so treat it as what's possible and measure your own workload.
RLC Pro AI stops at the operating system and the validated frameworks. Tuning your application is your work. We can help by showing you how that application interacts with the OS.
In regulated environments, some required security controls reduce GPU performance. The teams I work with harden their GPU nodes as far as the workload allows and run Rocky Linux from CIQ Pro Hardened (RLC Pro Hardened) on the other nodes.
You'll get the most from this if you're counting GPU time. At NVIDIA GTC I talked with someone who processes satellite images. If a transform doesn't finish in time, the captured signal is gone for good. He told me a few percent more throughput would be material for his team.
Get the free developer license and try RLC Pro AI on your own hardware. It's free for individuals on up to 25 nodes, for non-production use.
