An AI stack has two layers people are budgeting and tooling for, and a third they inherit. The frameworks and the model are the layer on top, and the accelerators and hardware the layer underneath, with the kernel in between owning memory management, storage, the network path, and every driver that touches the hardware you bought.
AI workloads lean on that layer harder than most applications you would run on the same box. Loading a model is a large sequential read. Serving a token depends on a scheduling decision. Sharing a GPU node across teams comes down to a cgroup boundary. Those are kernel behaviors that decide how much of the accelerator capacity you paid for reaches the workload.
AI also moves faster than the operating system underneath it. NVIDIA advances the hardware, CUDA advances the toolkit, and PyTorch advances the framework, while Enterprise Linux moves at a different pace by design, because its value is reliability, stability, and a vendor standing behind every package.
The consequence is a kernel frozen at general availability while the hardware and frameworks above it keep moving forward on an enterprise release that, on average, runs twelve to eighteen months behind before it catches up. With that combination, you are running last year's stack on this year's GPU, leaving performance on the table along with the budget that bought the hardware.
If you run RLC Pro AI you don’t make that trade. Linux 6.18, the latest production and long-term GPU drivers, and the CUDA toolkit ship together and are validated together.
Route around the kernel? You are still using it.
Many believe modern AI infrastructure routes around the operating system. Direct device-to-device access, GPU peer-to-peer transfers, RDMA. All of it gets described as bypassing the operating system.
None of it does.
Those are kernel features. The kernel manages the resources and data path. If hardware is to bypass it, the kernel has to enable that.
A new accelerator driver needs use the Application Binary Interface, exposed by the kernel. It has to retain compatibility with the ABI of a given kernel version. Some features are only exposed by a recent kernel. This can determine if the hardware runs at all, even before how fast it runs.
Model weights load at the speed the device can deliver
The memory and filesystem work in 6.18 targets large sequential reads, which is the access pattern that dominates loading model weights. In CIQ benchmarks, against the same workload on a kernel frozen at general availability, model loading ran 33.8 percent faster.
vLLM issue #40988 shows what that same bottleneck looks like without a readahead window sized for the workload. Three of eight workers stalled for more than an hour on a 102 GiB shard, reading 30 to 50 MB/s off NVMe that could deliver far more, because each rank was issuing roughly 13,000 scattered reads that the default readahead never coalesced. vLLM fixed it with an application-side prefetch strategy. A kernel that sizes readahead for large model files fixes it once per node, for every serving engine running on it.
Platform teams size capacity against cold start time, autoscalers make decisions on it, and every minute of it is GPU time you purchased and didn't use.
Hand your inference server a scheduler that knows its job
vLLM’s own tuning documentation notes that the engine core process "runs a busy loop and is particularly sensitive to CPU starvation." A published trace measured that process descheduled for two and a half seconds in the worst case. A busy loop starved for two and a half seconds is a tail-latency event your users feel and your dashboard reports as a mystery.
Agentic pipelines are where this hits hardest. They hammer the CPU with orchestration, tool calls, and retrieval, and then still need a fast first token on a cold path. General-purpose scheduling suits general-purpose work. An inference server has one job, and 6.18 lets load a customer scheduler tuned for the job. A 5.14 kernel keeps the general-purpose default, and that comes at a cost.
Storage is in the critical path for your weights
Three changes in 6.18 fit the I/O accelerated workloads that generate.
Atomic writes land at the filesystem level, so a database drops its double-write buffer and commits once.
Block sizes match the 16K-native geometry of current NVMe drives.
Buffered I/O preserves the page cache, which matters the moment a training job streams a dataset past everything else on the node.
Training checkpoints drain at 50 to 200 GB/s in exactly the large sequential pattern this work targets, and checkpoint frequency is a reliability decision teams make against how long a checkpoint takes.
Long-context serving is the other place this shows up. Spilling KV cache out of GPU memory into host DRAM and onto NVMe depends on filesystem and I/O behavior the kernel provides. LMCache documents that its direct I/O alignment is determined by the filesystem block size. NIXL exposes an io_uring switch.
6.18 also compiles in the dmem cgroup controller that caps device memory per container, so a platform team can cap device memory per container with an enforced ceiling on what each workload can hold on a shared GPU node. That turns multi-tenancy on shared GPU nodes into something a platform team can defend and a finance team can measure and charge back.
Three checks you can run this week
- When a new accelerator generation ships, does your operating system support it, or does it require someone on your team to build kernel modules?
- Can you name the kernel version running your production inference fleet, and do you know the date its upstream maintenance ends?
- Can you swap CPU scheduling behavior for one inference service without taking down the node?
Your answers to this can show that you are paying for its kernel in GPU time. Most teams I talk to find challenges on at least two of these questions, and almost none of them deliberately chose this path. It arrived with the distribution and has been setting the ceiling on accelerator throughput.
Run a current kernel that upstream still maintains
The CIQ Linux Kernel (CLK) 6.18 tracks the upstream 6.18 series instead of a frozen snapshot kept alive by backports. That series is the newest branch on the kernel.org long-term list, with upstream maintenance projected through December 2028.
The long-term designation is the part most version comparisons skip. Long-term branches receive a substantial, validated stream of patches from the whole kernel community: security fixes, hardware enablement, performance work, driver updates.
As of September 2026, the list is 6.18, 6.12, 6.6, 6.1, 5.15 and 5.10. Several kernels carrying higher version numbers have already reached end of life upstream and were never designated long-term. A higher number on a spec sheet does not verify the same commitment.
Because CLK tracks one upstream long-term branch, our engineers validate each update against the Enterprise Linux userspace along a shorter dependency chain than a multi-year backport tree allows.
CIQ patches CLK directly and ships it between distribution releases, so support for new accelerators reaches customers without waiting for the next minor release. On a fixed enterprise kernel, the backport work itself is rarely the long pole. Merged enablement waits in a development stream until the next minor opens, and minors open roughly twice a year.
Where to start
RLC Pro AI is available through CIQ Portal and the AWS, Microsoft Azure and Google Cloud marketplaces, as installer ISOs, cloud images and OCI container images.
I will be at the AI Infra Summit, September 15 -17, at the Santa Clara Convention Center. Come argue with me about the operating system.
