Starting from the kernel, not the framework

Most new infrastructure for AI workloads gets built the same way: as a layer on top of the existing stack. A scheduler that wraps Kubernetes. A serving framework that sits above PyTorch. A proxy that sits in front of an inference API. That's usually the right call — it ships faster and it doesn't ask anyone to trust something unproven at the bottom of their stack.

We're doing the opposite, and it's worth explaining why.

The overhead we kept running into

The problems we kept hitting — context-switch overhead between tenants sharing a GPU, allocators stalling under bursty parallel workloads, IPC paths that assume the processes on either end trust each other — don't originate in the framework layer. They originate below it, in the scheduler, the allocator, and the boundary between processes. A layer built on top of the stack can hide those costs or work around them for a specific case. It can't remove them.

So the mechanism has to live where the cost actually is: in kernel modules and the C/C++ middleware sitting between the device driver and everything above it.

What this trades off

Working at this layer is slower to build and harder to validate — kernel-adjacent code has a much smaller margin for error than an application-layer wrapper, and we're not going to publish a benchmark we can't reproduce on real hardware under real contention. That's the trade we're making deliberately: less surface area shipped early, more confidence in what does ship.

What's next

Right now that means R&D — prototyping against real multi-tenant GPU contention, not synthetic single-tenant benchmarks. As pieces of that become reproducible, we'll write them up here, with the methodology alongside the numbers.