HAMi Becomes a CNCF Incubating Project: What Fractional GPU Sharing Actually Buys a Fleet With a Handful of Cards

On July 15, 2026, the CNCF Technical Oversight Committee voted HAMi — Heterogeneous AI Computing Virtualization Middleware — into Incubating status, its second of three CNCF maturity levels. That's a governance milestone, but the number that actually matters for anyone running GPUs sits in HAMi's own case studies: DaoCloud pushed average GPU utilization past 80% and cut GPU operating costs roughly 50% after adopting it, while SF Technology saved up to 57% of its GPU footprint across production and test clusters.

Here's what that translates to on hardware a self-hosted fleet can actually buy. Take Hetzner's two current GPU dedicated servers — a €184/month card with 20GB of VRAM and an €889/month card with 96GB — and size them for AI-agent sandboxes that each need 4-8GB of VRAM. Kubernetes' default device-plugin model, which hands out a whole GPU per pod, gets you exactly one tenant per card no matter which one you buy. HAMi's fractional slicing gets you 2 to 23 tenants on the same hardware, depending on card and workload size, cutting the per-tenant monthly cost by 50-96%. That math holds up across the full range, not just at one convenient data point — the table below shows all four combinations.

The All-Or-Nothing Problem​

Kubernetes has always scheduled GPUs the same way it schedules any other extended resource: a pod requests nvidia.com/gpu: 1, the device plugin hands over an entire physical card, and that's that. There's no built-in concept of "half a GPU" or "4GB of this GPU" — the smallest unit Kubernetes' native device-plugin model understands is one whole device.

That's a fine model for training jobs that saturate a card for hours. It's a bad model for the workload a self-hosted PaaS actually runs at the tenant edge: AI-agent sandboxes and small inference services that each need a few gigabytes of VRAM and then sit mostly idle between requests. Put one of those sandboxes on a 20GB card via the stock device plugin and the other 16GB — 80% of what you paid for — sits reserved and unusable by anyone else, because Kubernetes has no way to tell the scheduler "this pod only needs a slice."

A Cluster API fleet that can't justify a dedicated GPU per tenant runs straight into this. Buying one GPU server per tenant sandbox doesn't scale past a handful of paying customers; the unit economics only work if multiple tenants can share a card without stepping on each other's memory or being able to see each other's data.

What HAMi Actually Does​

HAMi solves the slicing problem at the scheduler and driver layer, not the application layer — no code changes, no special base image, no rewritten Kubernetes manifests beyond requesting a fractional resource instead of a whole GPU. Under the hood it does three things:

• Allocates by memory, core percentage, or device count. A pod can request 4Gi of GPU memory and 25% of GPU compute instead of a whole card, and HAMi's scheduler binpacks, spreads, or applies topology-aware placement across the fleet's GPUs to fit it in.
• Enforces hard isolation, not just a request. HAMi-core, a CUDA-API interception library, sits between the tenant's process and the driver and tracks and caps actual memory and compute usage per container — one tenant's workload can't blow past its slice and starve or crash a neighbor.
• Works across vendors and GPU generations. NVIDIA, AMD, Huawei Ascend, Cambricon, Hygon, and Kunlun accelerators are all supported through the same scheduling API, so a fleet isn't locked into one silicon vendor's own sharing mechanism.

That third point matters against the alternatives NVIDIA ships itself. Time-slicing, built into the NVIDIA GPU Operator, lets multiple pods share a card by round-robin scheduling compute time — but it provides no memory isolation at all. One tenant's out-of-memory event can crash every other tenant sharing that card, which is disqualifying for a multi-tenant platform the moment two tenants don't trust each other. MIG (Multi-Instance GPU) does the opposite: it partitions a supported card into hardware-isolated instances with real fault boundaries, no interception layer required. But MIG only runs on a specific list of NVIDIA SKUs — datacenter and select professional-visualization cards with compute capability 8.0 or newer — and it partitions statically, in fixed sizes, up to a hard-capped instance count set by the silicon.

That list of MIG-capable cards is narrower than it looks. Hetzner's cheaper GPU server, the GEX44 with an RTX 4000 SFF Ada, doesn't support MIG at all — it's an Ada Lovelace workstation part, not one of the datacenter or MIG-enabled professional SKUs NVIDIA ships the feature on. Hetzner's other card, the GEX131 with an RTX PRO 6000 Blackwell Max-Q, does support MIG — but caps out at 4 static instances, not the 7 that A100 and H100 buyers get. On the cheaper of the two cards a self-hosted fleet is actually likely to buy, MIG isn't an option; HAMi or the whole-GPU device plugin are the only two choices.

The Sizing Math: Two Cards, Two Workload Sizes​

Here's the same comparison worked out in real numbers, using Hetzner's two current GPU dedicated servers and two representative AI-agent sandbox sizes — a small one at 4GB of VRAM and a larger one at 8GB. Each card reserves roughly 2GB for driver and scheduler overhead, a standard HAMi deployment assumption, leaving 18GB usable on the GEX44 and 94GB usable on the GEX131.

Two things are worth sitting with in that table. First, the win isn't a one-time trick that only shows up at a favorable size — HAMi cuts the per-tenant cost by 50% in the worst case shown (8GB sandboxes on the small card) and by 96% in the best case (4GB sandboxes on the large card), and every combination in between lands in that range. Second, MIG doesn't close the gap even where it's available: on the GEX131, MIG's four fixed ~23.5GB partitions are wildly oversized for a 4-8GB sandbox, so a MIG tenant still pays €222.25/month for capacity it isn't using — nearly 3-6x what the same sandbox costs under HAMi's finer-grained slicing. MIG buys hardware fault isolation that HAMi's software-enforced limits don't fully match, but for workloads this small, that isolation costs a lot more than the risk it's insuring against.

This Isn't a Lab Result — It's Running in Production​

The numbers above are a sizing exercise; HAMi's own adoption track record is what makes the exercise worth trusting. Per the CNCF's incubation announcement, DaoCloud alone runs HAMi across more than 10,000 GPUs spanning over 10 data centers, and China Merchants Bank runs it at production scale in a regulated environment. Beyond the two headline efficiency numbers already cited — DaoCloud's 80%+ utilization and SF Technology's 57% GPU footprint reduction — PREP EDU reports optimizing 90% of its GPU infrastructure with HAMi in place.

The project's contributor graph backs up "production, not pet project": 550-plus contributing organizations, 2,687 total contributors (a 43% year-over-year increase), 16 releases on the way to the current v2.9.0, and maintainers drawn from both dynamia.ai and NVIDIA alongside independent developers — not a single-vendor project wearing a CNCF badge for marketing purposes.

What Incubating — Not Graduated — Still Leaves Open​

CNCF has three maturity tiers: Sandbox, Incubating, Graduated. HAMi entered Sandbox in August 2024 and reached Incubating in roughly 23 months — a normal timeline for a project with real adopters — but Incubating is not the top tier, and the gap to Graduated is exactly where a platform betting its GPU economics on HAMi today should be paying attention. Per the CNCF announcement's own stated roadmap, four things are explicitly still in progress, not shipped:

1. Advanced scheduling is still maturing. Gang-scheduling, preemption, and autoscaling for GPU workloads are roadmap items, not GA features — a fleet leaning on HAMi for anything beyond straightforward fractional allocation should expect some of that to still be rough.
2. DRA consumption monitoring isn't shipped yet. Kubernetes' newer Dynamic Resource Allocation API is where GPU scheduling is headed long-term, and HAMi's DRA-side observability is explicitly called out as still being built.
3. Non-NVIDIA device support is expanding, not complete. AMD Mi-series and PPU support are listed as in-progress — the "heterogeneous" in HAMi's name is a direction the project is actively growing into, not a finished checklist.
4. Ecosystem integration is ongoing. Collaboration with Volcano, Koordinator, and Kueue — the other CNCF scheduling and batch-workload projects a GPU-heavy platform is likely to also run — is active work, not a done deal.

None of that is a reason to wait. It's a reason to pin a specific HAMi version, watch the release notes for the specific gaps above closing, and not assume feature parity with a fully Graduated project like Kubernetes itself.

The Verdict for a Self-Hosted Fleet​

For a Cluster API fleet that can't justify buying a dedicated GPU per tenant, HAMi is the CNCF-vetted way to close that gap today — not a future promise. The sizing math above isn't a best-case scenario cherry-picked to make the number look good: at the worst combination in the table, HAMi still halves the per-tenant cost against buying whole GPUs, and production deployments at DaoCloud's 10,000-GPU scale confirm the utilization gains hold outside a spreadsheet. Incubating status, and the specific roadmap gaps that come with it, means treating HAMi as infrastructure to adopt deliberately and version-pin — not a feature to enable once and forget about, at least until the gang-scheduling and DRA-monitoring items above cross off the roadmap.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with Cluster API managing the fleet those services actually run on. Star the repo on GitHub or deploy your first app today.

Sources​

• CNCF — HAMi becomes a CNCF incubating project
• HAMi — Heterogeneous GPU Sharing on Kubernetes
• GitHub — Project-HAMi/HAMi
• HAMi — GPU Virtualization Principles
• NVIDIA — Time-Slicing GPUs in Kubernetes (GPU Operator docs)
• NVIDIA — Multi-Instance GPU (MIG) Supported GPUs
• Hetzner — GEX44 dedicated GPU server
• Hetzner — GPU dedicated server matrix
• Dynamia AI — HAMi Becomes a CNCF Incubating Project