NVIDIA Workload Map, AI iş yüklerini tek YAML tanımıyla anlatıyor

NVIDIA Workload Map, Kubernetes’teki dağıtık iş yüklerinin yapısını framework’ten bağımsız bir YAML tanımıyla anlatan bir CRD ve Go kütüphanesi olarak Apache 2.0 lisansıyla kullanılabiliyor. Eski adı Karta olan proje; JobSet, RayJob, KServe ve NVIDIA Dynamo gibi tipler için hazır tanımlardan oluşan bir katalogla geliyor. KAI Scheduler ve NVIDIA Run:ai aynı tanımları okuyor.

JobSet nedir, ne işe yarar?

JobSet, birden fazla Kubernetes Job’ını tek bir birim olarak tanımlayıp yönetmek için geliştirilmiş, Kubernetes topluluğunun açık kaynak bir API’sidir. Dağıtık model eğitimi ve HPC gibi leader ve worker rolleri olan iş yüklerinde kullanılır. Kubeflow’un eğitim operator’leri ve LeaderWorkerSet benzer ihtiyaçlara yönelen alternatiflerdir.

KAI Scheduler nedir, ne işe yarar?

KAI Scheduler, NVIDIA’nın Kubernetes için geliştirdiği açık kaynak bir scheduler’dır. GPU ağırlıklı AI iş yüklerinde gang scheduling, kota ve önceliklendirme gibi ihtiyaçlara odaklanır. Run:ai platformunun scheduler’ından türemiştir. Volcano ve Kueue benzer sorunlara çözüm arayan alternatiflerdir.

NVIDIA Workload Map hangi sorunu çözüyor?

Kubernetes’te çok framework’lü bir GPU cluster’ı işletiyorsanız sorun tanıdık. JobSet, LeaderWorkerSet, RayJob ve PyTorchJob durumlarını farklı alanlarda tutuyor. Scheduler, dashboard ya da maliyet aracı yazan ekip her CRD için ayrı bir adapter yazıp bakımını üstleniyor.

NVIDIA Workload Map bu bilgiyi derlenmiş koddan çıkarıp YAML’a taşıyor. Bir tanım, pod template’in nerede durduğunu, replica sayısının nasıl hesaplandığını ve durumun hangi faza denk geldiğini söylüyor. Eski adı Karta. CRD’nin kind alanı hâlâ Karta, cluster’da kaynak ararken bu adı kullanacaksınız.

Yaklaşımın ana parçaları:

• Bir CRD ve tanımları canlı nesnelere uygulayan bir Go kütüphanesi.
• jq ifadeleriyle status eşlemesi. JobSet’in raporlamadığı “Running” durumu replicatedJobsStatus üzerinden türetiliyor.
• Hazır katalog: JobSet, PyTorchJob, Ray ailesi, KServe, Knative, MPIJob, LeaderWorkerSet, NVIDIA NIM, NVIDIA Dynamo ve birkaç tip daha.
• Aynı tanımı okuyan üç tüketici: kli CLI, KAI Scheduler ve NVIDIA Run:ai.

Cluster’a dokunmadan deneme

En düşük riskli başlangıç CLI. kli, kubeconfig ile cluster’a bağlanıyor ve içindeki hazır tanımlarla çalışıyor. Sadece inceleme için Workload Map’i cluster’a kurmanız gerekmiyor. Kurulum kaynakta Homebrew üzerinden anlatılıyor:

brew tap dsx-ai-factory/kli https://github.com/dsx-ai-factory/workload-map
brew install dsx-ai-factory/kli/kli
kli --version
kli describe jobset/demo -n <namespace>

kubectl get jobset,jobs,pods aynı işi üç ayrı liste olarak döküyor. kli ise bunları leader ve worker rollerine ayrılmış tek bir ağaçta gösteriyor. Rol başına hazır pod sayısı, GPU toplamı ve node yerleşimi aynı ekranda. Örnekteki JobSet için toplam 12 GPU.

İşe yarar bir ilk test: kendi GPU kota ya da maliyet script’inizin hesapladığı toplamı kli’nin rol bazlı toplamıyla karşılaştırın. Fark çıkarsa ya script’iniz ya da tanım bir alanı kaçırıyor demektir.

KAI Scheduler kullananlar için

Tanıma eklenen optimizationInstructions bloğu gang scheduling için gruplama bilgisini taşıyor. Gang scheduling, bir işin bütün pod’larını ya birlikte yerleştirmek ya da hiç başlatmamak demek. Dağıtık eğitimde yarım başlayan bir işin GPU’ları boşa tutmasını bu engelliyor.

KAI Scheduler, Workload Map’i pod grouper içinde fallback olarak kullanıyor. Yani native plugin’i olan tiplerde davranış değişmiyor, native plugin önceliğini koruyor. Kazanç plugin’i olmayan tiplerde: yeni bir framework için plugin beklemek yerine bir tanım yazmak yetiyor.

Kendi CRD’niz için tanım yazarken

İç ekiplerin yazdığı operator’ler bu modelin asıl hedefi. Tanım düz bir YAML dosyası. Git’te tutulabiliyor, pull request ile incelenebiliyor, diğer manifest’ler gibi cluster’a uygulanabiliyor. Yazarken şunlara dikkat edin:

• statusMappings’teki jq ifadesi, bütün tüketicilerin göreceği fazı belirliyor. Hatalı bir ifade scheduler’ı, dashboard’u ve Run:ai’yi aynı anda yanıltır. Tek tanımın getirdiği tutarlılık hatayı da her yere taşıyor.
• JobSet tanımı pod sayısını replicas çarpı parallelism olarak hesaplıyor. Kaynaktaki örnek manifest bu yüzden parallelism alanını açıkça yazıyor. Kendi JobSet’lerinizde bu alanı boş bırakmayın.
• instanceIdPath rollerin adını belirliyor. Yanlış ayarlanırsa leader ve worker yerine isimsiz Job’lar görürsünüz.
• API sürümü run.ai/v1alpha1. Kubernetes geleneğinde alpha sürüm, alanların ileride değişebileceği anlamına gelir. Kendi araçlarınızı bu şemaya bağlamadan önce bunu hesaba katın.

Kimin işine yarar, kim bekleyebilir?

Birden fazla AI framework’ünü aynı GPU havuzunda çalıştıran platform ekipleri en çok kazananlar. Kendi scheduler eklentisini, maliyet raporunu ya da iç portalını yazan ekipler, CRD başına adapter bakımını tanım bakımına çevirebilir. NVIDIA Run:ai kullanıyorsanız katalogdaki bir tipi tek bir API çağrısıyla, ek kod yazmadan kaydedebiliyorsunuz.

Tek framework kullanan ve operator’ünün kendi araçlarından memnun olan ekip için acele yok. KAI Scheduler ya da Run:ai kullanmıyorsanız bugünkü değer büyük ölçüde CLI ile görünürlükte kalıyor. NVIDIA dışındaki scheduler ve platformlarla entegrasyonun ne durumda olduğu bu duyurudan anlaşılmıyor. Benimseme kararı vermeden önce orijinal yazının o bölümünü okuyun.