Allocations¶

What an allocation is¶

An allocation is a small record (a Kubernetes Allocation custom resource) that URCF staff create when your request for access is approved.

It has three important fields:

Here's an example allocation that grants 2 GH200s to vision-lab through the end of 2026"

apiVersion: urcf.drexel.edu/v1alpha1
kind: Allocation
metadata:
  name: vision-lab-2026
spec:
  group: vision-lab
  resources:
    nvidia.com/gpu:
      gh200: 2
  expiresAt: "2026-12-31T23:59:59Z"

The resources map is the heart of it.

The resource (nvidia.com/gpu) is a standard Kubernetes extended resource — the same key you put in a pod's resource limit specification to ask for a GPU. On its own it just means "a GPU"; it says nothing about which kind of GPU.

The flavor (gh200) is what supplies that missing detail. A flavor (a Kueue ResourceFlavor) is a named type of node in the cluster. FLAME labels each GPU node with the type of GPU it contains, and the gh200 flavor is specifies the nodes carrying GH200 GPUS. So naming the gh200 flavor specifies exactly what type of GPU we're talking about.

The resource says what you're allocated (GPUs), the flavor says which nodes you get that resource on (which implicitly determines what kind of GPUs you get), and the count says how many.

You might wonder, why do we have to specify the resource at all? The only thing we're allocating is GPUs, right? The reason for this is that the GPUs in FLAME support an NVIDIA technology called Multi-Instance GPU, or MIG, that enables them to be reconfigured to present a single large GPU as multiple smaller "slices" with memory isolation at the hardware level.

When MIG is enabled, those slices are exposed as a differently named resource — not nvidia.com/gpu. For example, the GH200's 96 GB of GPU memory can be carved into four equal 1g.24gb slices. each one compute unit with 24 GB of memory. The slices shows up as nvidia.com/mig-1g.24gb, which you'd request using that key rather than nvidia.com/gpu. So the resource field exists to name which kind of GPU resource (an entire GPU or a particular MIG slice) and the flavor then pins that down to specific hardware (i.e. do you want that resource on a GH200 machine or an A100 machine).

FLAME doesn't use MIG right now; every GPU is allocated in it's entirely as nvidia.com/gpu. But allocations are set up so that if we split GPUs into MIG slices in the future, allocations can assign those slices without any change to the data model.

Standard vs. borrowing-only, precisely¶

The two allocation types aren't separate kinds of object. The difference is entirely in the count:

• Count ≥ 1 → standard. Those GPUs are guaranteed: reserved for the group and reclaimable on demand.
• Count = 0 → borrowing-only. Listing a type with a count of zero grants the group the ability to borrow that type when others aren't using it, but guarantees nothing.
• Type not listed at all → no access. If a group has no active allocation that mentions a GPU type, it can't run on that type — not even by borrowing.

In other words, borrowing eligibility comes from having an allocation that lists the type; guaranteed capacity comes from a non-zero count. A borrowing-only allocation looks just like the example above, but with gh200: 0.

See also¶

• Kueue → Cohorts and fair sharing
• Designing GPU workloads for preemption