Iñigo GonzálezIT Operations · Infra

Blog · 15

Repartir GPU entre equipos con Kueue y KAI SchedulerSharing GPUs between teams with Kueue and KAI Scheduler

Un acuerdo de cuotas en un fichero TOML, traducido a los dos planificadores y probado en kind.One quota agreement in a TOML file, rendered into both schedulers and tested on kind.

Laboratorio GPUGPU lab · 5 oct 20265 Oct 2026 · 2 min2 min read

Por qué este laboratorio

Se apoya en la gestión de capacidad y en los acuerdos de SLA y OLA entre equipos que comparten la misma infraestructura. Cuando varios equipos comparten un clúster de GPU, la clave es el acuerdo: quién tiene qué garantizado, quién puede pedir prestado y qué pasa cuando el dueño lo quiere de vuelta.

Qué he hecho

  • tenancy.toml con tres equipos: training (16 garantizadas, 8 prestables), research (8 + 8) e inference (8 que nunca presta).
  • python -m tenancy render lo convierte en ClusterQueues de Kueue dentro de una cohort y en Queues de KAI Scheduler. La CI falla si los manifiestos no coinciden con el fichero.
  • Un clúster kind con 4 workers × 8 GPU simuladas por el fake-gpu-operator de Run:ai, más KubeVirt.

Cómo se prueba

Kueue, 22 comprobaciones: préstamo, recuperación, prioridad dentro del equipo y admisión todo o nada. KAI, 19: dos pods compartiendo una GPU a 0,5 cada uno, exceso de cuota, recuperación y gang scheduling. KubeVirt, 5: una VM arranca con emulación QEMU y la ResourceQuota del equipo rechaza una segunda.

Qué aprendí

Tres rondas de arreglos tras la primera CI, explicadas en docs/decisions.md: el uso de las colas se informa con retraso, el motivo de la preemption está en una condición y las GPU fraccionarias se pasan como texto.

Siguientes pasos

  • Describir tus equipos y cuotas en tenancy.toml y generar los manifiestos para Kueue o KAI Scheduler.
  • Añadir fair sharing y planificación según topología a medida que crece el clúster.
  • Revisar el acuerdo con los equipos cada trimestre.

¿Quieres llevarlo a tu entorno o adaptarlo a tu caso? Escríbeme y lo vemos.

Why this lab

Builds on capacity management and on SLA and OLA agreements between teams that share the same infrastructure. When several teams share a GPU cluster, the key is the agreement: who is guaranteed what, who can borrow, and what happens when the owner wants it back.

What I built

  • tenancy.toml with three teams: training (16 guaranteed, 8 can be borrowed), research (8 + 8) and inference (8, never lent).
  • python -m tenancy render turns it into Kueue ClusterQueues in a cohort and KAI Scheduler Queues. CI fails if the manifests drift from the file.
  • A kind cluster with 4 workers × 8 GPUs simulated by Run:ai's fake-gpu-operator, plus KubeVirt.

How it is tested

Kueue, 22 checks: borrowing, reclaim, priority within a team and all-or-nothing admission. KAI, 19 checks: two pods sharing one GPU at 0.5 each, over-quota, reclaim and gang scheduling. KubeVirt, 5 checks: a VM boots with QEMU emulation and the team's ResourceQuota rejects a second one.

What I learned

Three rounds of fixes after the first CI run, written up in docs/decisions.md: queue usage is reported with a delay, the preemption reason is in a condition, and fractional GPUs are passed as text.

Next steps

  • Describe your teams and quotas in tenancy.toml and render the manifests for Kueue or KAI Scheduler.
  • Add fair sharing and topology-aware scheduling as the cluster grows.
  • Review the agreement with the teams every quarter.

Want to bring it to your environment or adapt it to your case? Get in touch and we can look at it together.

Tech Career Lab · newsletter

¿Te ha servido? Cada dos semanas envío una idea práctica para perfiles IT: LinkedIn, proyectos, networking y procesos de selección.Found this useful? Every two weeks I send one practical idea for IT professionals: LinkedIn, projects, networking and hiring processes.

Apúntate y llévate las 33 ideasSign up and get the 33 ideas →