NVIDIA Run:ai Open Source: KAI Scheduler, GPU Fractioning

Pengumuman NVIDIA pada 13 Oktober 2026 menyebut seluruh platform Run:ai kini open source, dan kalimat itu menyembunyikan empat hal terpisah dengan lisensi, dependensi, dan tingkat kebaruan yang berbeda. Saya membacanya dua kali sebelum bisa menentukan bagian mana yang benar-benar akan saya coba di cluster.

Saya belum menginstal apa pun. Semua isi di bawah berasal dari post blog teknis NVIDIA, repositori dsx-ai-factory/run-ai, README dan halaman docs KAI Scheduler, serta post KubeCon NVIDIA bulan Maret, semuanya dibaca pada 17 Oktober 2026. Kalau sebuah halaman tidak menyebutkan sesuatu, saya katakan begitu dan tidak mengisinya dari asumsi, dan satu-satunya YAML yang saya susun sendiri diberi label.

Empat bagian dan apa yang dibutuhkan masing-masing

NVIDIA menggambarkan rilis ini sebagai empat komponen modular yang bisa diadopsi sendiri-sendiri. Pertanyaan yang berguna bagi tim platform bukan apakah Run:ai sudah open, tetapi bagian mana dari keempatnya yang menyelesaikan masalah yang sekarang Anda bayar atau akali.

Jadi scheduler dan operator adalah dua bagian yang bisa dicoba satu tim minggu ini, Resource Management untuk pemilik platform yang harus membagi GPU antar department, dan Workload Map adalah library untuk yang membangun tooling. Chart Helm NGC untuk stack terintegrasi juga ada, sebagai build Community Product.

Apa yang benar-benar baru di rilis Oktober

KAI Scheduler bukan beritanya. Post KubeCon NVIDIA bulan Maret menyebut ia di-onboard sebagai proyek CNCF Sandbox pada 24 Maret 2026, dan analisis DEV Community yang saya baca mencatat ia sudah Apache 2.0 sebelum Oktober. Analisis itu sekunder dan dibantu AI, jadi anggap riwayat persisnya sebagai klaim mereka, tetapi sumber primer sepakat soal arahnya: scheduler dibuka lebih dulu, sisanya menyusul.

Yang ditambahkan rilis Oktober adalah platform di sekelilingnya. Repositori dsx-ai-factory/run-ai adalah monorepo yang README-nya mencantumkan control plane, cluster services (controller dan admission webhook yang di-deploy ke tiap cluster terkelola), CLI runai-installer, runai-mcp-server yang mengekspos operasi Run:ai sebagai tool untuk asisten AI, client hasil generate, dan tool scale serta load testing. Image dan Helm chart dipublikasikan ke NVIDIA NGC di nvcr.io/nvidia/runai.

NVIDIA juga menyebut delapan partner ekosistem DSX yang mengintegrasikan platform ini: Crusoe, Mirantis, Nebius, OpenNebula Systems, Rafay, Saturn Cloud, Spectro Cloud, dan vCluster. Post yang sama membahas dua proyek terkait, Model Streamer (terhubung ke vLLM lewat flag --load-format runai_streamer) dan Grove, API Kubernetes untuk inference multi-komponen. Post itu memuat benchmark loading dari partner untuk Model Streamer; saya tidak mengulanginya karena tidak bisa memverifikasi satu pun.

Fractional GPU: dependensi CUDA 13.4 dan pod spec

Baris paling berdampak di pengumuman itu adalah implementasi fractional-GPU proprietary Run:ai sudah dipensiunkan demi fraction native di CUDA 13.4, dan GPU Fractioning Operator adalah integrasi Kubernetes untuk fitur driver tersebut. Jika Anda menginginkan fraction, soalnya bukan lagi lisensi melainkan apakah driver Anda cukup baru. Halaman gpu-sharing milik KAI Scheduler menunjukkan bentuk pod fractional.

# From KAI Scheduler's docs/gpu-sharing/README.md: a pod that asks for half a GPU.
# Two things are mandatory on every fractional pod: schedulerName and the queue label.
apiVersion: v1
kind: Pod
metadata:
  name: half-gpu
  labels:
    kai.scheduler/queue: default-queue
  annotations:
    gpu-fraction: "0.5"          # must be greater than 0 and less than 1
spec:
  schedulerName: kai-scheduler   # without this the default scheduler never sees the annotation
  containers:
    - name: gpu-workload
      image: nvidia/cuda:13.0.2-base-ubi8
      command: ["nvidia-smi"]
      args: ["--query-gpu=name,memory.total", "--format=csv,noheader"]

# The same page also documents these alternatives (metadata only):
#   gpu-memory: "4096"                                         # memory in MiB
#   nvidia.com/container.gpu-workload.gpu-memory.request: 4096Mi   # NvFractions
#   nvidia.com/container.gpu-workload.gpu-memory.limit: 8192Mi
#   gpu-fraction-num-devices: "2"                              # spread over two devices

Annotation itu bukan satu mekanisme. Halaman tersebut mendokumentasikan beberapa mode, dan annotation mana yang berlaku bergantung pada mode yang dijalankan cluster Anda.

Docs tidak menyatakan secara eksplisit bahwa NvFractions adalah wajah Kubernetes dari fraction CUDA 13.4, jadi saya menyimpulkannya dari penamaan dan pengumuman NVIDIA. Pastikan lewat dokumentasi instalasi operator sebelum Anda merencanakan sesuatu di atasnya.

Queue dan quota: pengganti spreadsheet

KAI Scheduler memodelkan sharing lewat custom resource Queue di API scheduling.run.ai/v2. Sebuah queue mendeklarasikan quota yang dijamin, limit keras, dan overQuotaWeight untuk membagi kapasitas sisa, dan queue bisa bersarang lewat parentQueue.

# Field names and units are from KAI Scheduler's docs/queues/README.md.
# Units: CPU in millicores, memory in MB, GPU in whole units.
# Only leaf queues (no children) can run jobs.
apiVersion: scheduling.run.ai/v2
kind: Queue
metadata:
  name: research-team
spec:
  displayName: "Research Team"
  resources:
    gpu:
      quota: 1       # guaranteed
      limit: 2       # hard cap
---
apiVersion: scheduling.run.ai/v2
kind: Queue
metadata:
  name: ml-team
spec:
  displayName: "ML Team"
  parentQueue: "research-team"   # makes research-team a non-leaf, so it can no longer run jobs
  priority: 200                  # higher goes first when spare capacity is shared out
  resources:
    gpu:
      quota: 1
      overQuotaWeight: 1         # share of the spare GPUs among queues at the same priority

Dua detail dari docs lebih penting daripada sintaksnya. Hanya leaf queue yang bisa menjalankan job, jadi mengubah queue tim menjadi parent diam-diam menghentikannya sebagai tempat submit pekerjaan. Dan quota -1 berarti tanpa batas sementara 0 atau tidak diisi berarti tanpa jaminan, jadi burst queue hasil copy-paste bisa jauh lebih longgar dari niat Anda. Halaman queues tidak menyebut bagaimana pod menamai queue-nya; halaman gpu-sharing menyebutnya lewat label kai.scheduler/queue.

Gang scheduling: seluruh job atau tidak sama sekali

Secara default KAI menjadwalkan pod satu per satu. Untuk penempatan all-or-nothing, Anda menambahkan annotation kai.scheduler/batch-min-member pada Job atau JobSet, dan tidak ada pod yang mulai sebelum jumlah minimum itu bisa ditempatkan bersama. Untuk JobSet, scheduler membuat satu PodGroup dengan SubGroup per replicatedJob dan per replica, dan untuk PyTorchJob dibutuhkan Kubeflow training operator v1.

# My composition from the annotation semantics in docs/batch/README.md.
# The docs name the example files but I did not read their text, and I have not run this.
# Six pods are requested; none starts unless at least two can be placed together.
apiVersion: batch/v1
kind: Job
metadata:
  name: train-gang
  annotations:
    kai.scheduler/batch-min-member: "2"
spec:
  parallelism: 6
  completions: 6
  template:
    metadata:
      labels:
        kai.scheduler/queue: ml-team
    spec:
      schedulerName: kai-scheduler
      restartPolicy: Never
      containers:
        - name: worker
          image: nvidia/cuda:13.0.2-base-ubi8
          command: ["nvidia-smi", "-L"]
          resources:
            limits:
              nvidia.com/gpu: 1

Docs juga memungkinkan Anda membuat PodGroup sendiri lalu membuat pod bergabung lewat pod-group-name, dengan kai.scheduler/skip-podgrouper diisi true agar podgrouper tidak mengubah keanggotaan. Itu jalan keluar untuk controller yang tidak dikenali KAI, sekaligus kasus yang dibidik Workload Map.

Fine print lisensi, lapis demi lapis

Open source berlaku untuk kodenya dan hanya sebagian untuk cara mendapatkannya. Ada empat lapis, dan masing-masing berkata hal berbeda.

Aturan praktisnya: tentukan dulu lapisan mana yang Anda pakai sebelum ada yang mengucapkan kata gratis. Build dari source dan menjalankan Helm chart dari NGC adalah dua hubungan hukum yang berbeda dengan NVIDIA.

Di mana ia bisa menyakitkan: empat trade-off yang saya sebut di muka

Tidak satu pun dari ini alasan untuk melewatkan rilis tersebut. Masing-masing adalah titik di mana pilot yang tampak mulus saat demo bisa macet.

• Batas bawah driver. Fraction bergantung pada CUDA 13.4 dan driver yang kompatibel, dan NVIDIA menyebut implementasi proprietary sudah dipensiunkan. Cluster yang dikunci pada driver lama demi stabilitas punya upgrade nyata yang harus dijadwalkan dulu.
• Aturan pod yang ketat. Pod fractional tidak boleh sekaligus meminta nvidia.com/gpu utuh, hanya satu container yang boleh meminta fraction, dan pengguna tidak bisa mengisi annotation devices yang dicadangkan karena ditulis oleh KAI Binder.
• Isolasi memori yang belum jelas. Docs menyebut mode bernama NonMemoryEnforced dan menyatakan NvFractions butuh CDI dan NRI untuk enforcement memori saat runtime. Saya membaca nama pertama sebagai tanpa enforcement memori, yang tidak saya verifikasi, jadi uji dulu apa yang bisa dilakukan tetangga rakus sebelum berbagi GPU antar tim.
• Kematangan dan support. KAI adalah proyek CNCF Sandbox, build NGC tidak punya enterprise support, dan analisis DEV Community menyebut belum ada angka adopsi publik. Pengumuman vendor bukan rekam jejak produksi.

Konsekuensi kelima mengikuti pod spec: setiap pod harus mengisi schedulerName dengan kai-scheduler, jadi tim yang lupa akan diam-diam memakai default scheduler tanpa perilaku queue maupun fraction. Perlakukan ini sebagai kebijakan yang ditegakkan lewat admission rule, bukan kebiasaan yang diharapkan.

Yang dilakukan hari Senin

Saya akan menjalankan pilot sempit hanya untuk scheduler, di satu GPU pool non-produksi, dan menunda platform penuh.

1. Catat versi driver dan CUDA di setiap GPU node lalu bandingkan dengan syarat CUDA 13.4 untuk fraction.
2. Instal KAI Scheduler dengan perintah Helm di README-nya, dipin ke satu release, di namespace sendiri.
3. Buat Queue leaf dengan quota GPU kecil dan limit, lalu jalankan pod half-gpu di namespace terpisah, jangan pernah di kai-scheduler.
4. Jalankan Job dengan annotation batch-min-member lebih besar dari GPU yang kosong dan pastikan ia menunggu, bukan mulai sebagian.
5. Tanyakan ke legal soal syarat NGC dan tanyakan ke diri sendiri apakah Anda butuh enterprise support yang tidak ada di Community Product.

# 1. Which driver and CUDA version do the GPU nodes report? Fractions need CUDA 13.4
#    and a compatible driver, so read this before reading anything else.
nvidia-smi --query-gpu=name,driver_version --format=csv,noheader
nvidia-smi | grep "CUDA Version"

# 2. Install only the scheduler, from the KAI README. Replace VERSION with a release
#    from https://github.com/kai-scheduler/KAI-scheduler/releases
helm upgrade -i kai-scheduler \
  oci://ghcr.io/kai-scheduler/kai-scheduler/kai-scheduler \
  -n kai-scheduler --create-namespace --version VERSION

# 3. Never submit workloads into the kai-scheduler namespace. Use your own.
kubectl create namespace gpu-trial

# 4. Apply a leaf Queue (see the queue section), then the half-gpu pod with
#    metadata.namespace set to gpu-trial, and confirm which scheduler placed it.
kubectl -n gpu-trial get pod half-gpu -o jsonpath='{.spec.schedulerName}{"\n"}'
kubectl -n gpu-trial get events --field-selector involvedObject.name=half-gpu

Perintah instalasi berasal dari README KAI dan pengecekannya kubectl standar. YAML Queue dan pod di atas adalah contoh dari docs, jadi sesuaikan nama dengan namespace Anda.

Baca rilis ini sebagai empat keputusan, bukan satu: scheduler cukup matang untuk dicoba sekarang, operator dibatasi CUDA 13.4, lapisan platform adalah kode baru tanpa rekam jejak adopsi publik, dan lisensi yang Anda terima bergantung pada apakah Anda build dari source atau menarik dari NGC. Pilih lapisannya dulu, sisanya mengikuti.