NVIDIA KAI Scheduler ile Ray’de Gang Scheduling ve İş Yükü Önceliklendirmesi Nasıl Etkinleştirilir?

NVIDIA KAI Scheduler, now natively integrated with KubeRay, brings high-demand scheduling capabilities directly to Ray clusters. This integration allows Ray kullanıcılarının gang scheduling, workload autoscaling, workload prioritization, hierarchical queues gibi birçok yeni özellikten faydalanmasını sağlar. Bu özelliklerin bir araya gelmesi, altyapınızı daha akıllı hale getirerek iş başlatma süreçlerini koordine eder, GPU’ları verimli bir şekilde paylaşır ve iş yüklerini önceliklendirir. Tüm bunları sadece yapılandırarak gerçekleştirebilirsiniz.

Neden Ray Kullanıcıları için Önemli?

Ray kullanıcıları için KAI Scheduler’ın sunmuş olduğu yenilikler:

Gang scheduling: kısmi başlatmalara son
Dağıtılmış Ray iş yüklerinin tüm işçileri ve aktörlerinin birlikte başlaması gerektiğinden, KAI bunu koordine eder. Böylece eğitim veya çıkarım hatlarını durduran israfla sonuçlanan kısmi tahsislerin önüne geçilmiş olur.
İş yükü ve küme otomatik ölçekleme
Özellikle çevrimiçi bir iş yükü olan toplu çıkarım için Ray kümeleri, kaynaklar mevcut oldukça veya kuyruklar izin verdiğinde otomatik olarak ölçeklenebilir. Aynı zamanda, talep azalınca da otomatik olarak küçülerek insan müdahalesi olmadan elastic compute sağlar.
İş yükü öncelikleri: farklı iş yüklerinin uyumlu çalışması
Yüksek öncelikli çıkarım işleri, kaynaklar sınırlı olduğunda, daha düşük öncelikli toplu eğitimleri otomatik olarak geçersiz kılarak uygulamalarınızın yanıt vermesini sağlar.
Hiyerarşik kuyruklama ile öncelikler: dinamik kaynak paylaşımı
Farklı proje ekipleri için açık öncelikleri olan kuyruklar oluşturarak, kapasite mevcut olduğunda yüksek öncelikli kuyrukların diğer ekiplerden boş kaynaklar almasını sağlamak mümkündür.

Uygulamalı Bir Örnekle KAI Scheduler’ı Kullanma

Bu yazıda, KAI Scheduler’ın Ray için daha akıllı kaynak tahsisi ve yanıt verebilirliğini nasıl sağladığını gösteren pratik bir örnek üzerinde duracağız. Aşağıdakiler hakkında bilgi edineceksiniz:

Dağıtılmış Ray işçilerini bir grup olarak planlayarak, koordineli başlatmayı sağlamak.
Çıkarım işlerinin, daha düşük öncelikli eğitim işlerini geçersiz kılarak, öncelik tabanlı planlamadan nasıl faydalandığını gösterme.

Teknik Kurulum

Bu örnek için gerekli ortam aşağıdaki gibidir:

Bir NVIDIA A10G GPU’ya sahip Kubernetes kümesi.
NVIDIA GPU Operator yüklü olmalıdır.
NVIDIA KAI Scheduler kurulu (kurulum kılavuzu için bakabilirsiniz).
KubeRay Operator gece yapısı veya KubeRay’ın Helm şemasından, KAI Scheduler kullanacak şekilde yapılandırılmış olarak kurulmalıdır (kurulum kılavuzu).

Kurulum için aşağıdaki komut kullanılır:

--set batchScheduler.name=kai-scheduler

KAI Scheduler Kuyruklarını Kurma Adımı

Ray iş yüklerini göndermeden önce, KAI Scheduler için kuyruklar tanımlanmalıdır. KAI Scheduler, ekiplerin ve departmanların çok seviyeli yapılar halinde organize edilmesine olanak tanıyan hiyerarşik kuyruklama desteği sunar.

Bu örnekte, “department-1” adında bir üst seviye kuyruk ve “team-a” adıyla bir alt seviye kuyruk oluşturulacaktır. Bu demodaki tüm iş yükleri “team-a” üzerinden gönderilecek, fakat gerçek bir kurulumda birden fazla departman ve ekip yapılandırılabilir.

Kuyrukları oluşturmak için aşağıdaki YAML dosyası kullanılmalıdır:

apiVersion: scheduling.run.ai/v2
kind: Queue
metadata:
  name: department-1
spec:
  resources:
    cpu:
      quota: -1
      limit: -1
      overQuotaWeight: 1
    gpu:
      quota: -1
      limit: -1
      overQuotaWeight: 1
    memory:
      quota: -1
      limit: -1
      overQuotaWeight: 1
---
apiVersion: scheduling.run.ai/v2
kind: Queue
metadata:
  name: team-a
spec:
  parentQueue: department-1
  resources:
    cpu:
      quota: -1
      limit: -1
      overQuotaWeight: 1
    gpu:
      quota: -1
      limit: -1
      overQuotaWeight: 1
    memory:
      quota: -1
      limit: -1
      overQuotaWeight: 1

Anahtar parametrelerin hızlı bir özeti:

Quota (kota): Kuyruğun hak ettiği kaynakların toplamı.
Limit: Bir kuyruğun tüketebileceği kaynaklar üst sınırı.
Over Quota Weight (aşan kota ağırlığı): Aynı önceliğe sahip kuyruklar arasında fazla kaynakların nasıl dağıtılacağını belirler. Daha yüksek ağırlıklara sahip kuyruklar fazladan kapasiteden daha büyük bir bölüm alır.

Bu demoda, belirli kotalar, limitler veya öncelikler uygulanmamıştır. Sadece entegrasyon süreçlerini göstermek adına basit tutmak hedeflenmiştir. Ancak, bu alanlar adalet sağlamak için güçlü araçlar sunmakta ve organizasyonel sınırlar arasındaki anlaşmazlıkları yönetmektedir.

Kuyrukları oluşturmak için aşağıdaki komutu çalıştırın:

kubectl apply -f kai-scheduler-queue.yaml

Kuyruk hiyerarşisi oluşturulduğuna göre, iş yükleri “team-a” altında gönderilip planlanabilir.

Eğitim İş Yükünü Gang Scheduling ve Çalışma Önceliği ile Gönderme

Kuyruklar oluşturulduktan sonra, KAI’nin gang scheduling özelliğini kullanarak bir eğitim iş yükü çalıştırma zamanıdır.

Bu örnekte, bir baş düğüm ve iki işçi replikasından oluşan basit bir Ray kümesi tanımlayacağız.

KAI, tüm Kubernetes Pod’larını (iki işçi ve baş düğüm) bir grup olarak planlar, yani birlikte başlar veya hiç başlamaz ve öncelik sırası durumunda birlikte durdurulurlar.

KAI planlamasını etkinleştirmek için gereken tek yapılandırma, bir KAI kuyruğuna iş atayan kai.scheduler/queue etiketidir; örneğimizde bu, “team-a”dır.

İsteğe bağlı bir ayar olan priorityClassName: train, bu işi öncelikli bir eğitim iş yükü olarak işaretler. Bu, KAI’nin iş yükü önceliklendirmesinin nasıl uygulandığını göstermek içindir. İş yükü önceliği hakkında daha fazla bilgi için resmi belgeleri inceleyebilirsiniz.

Aşağıda kullanılan manifest mevcuttur:

apiVersion: ray.io/v1
kind: RayCluster
metadata:
  name: raycluster-sample
  labels:
    kai.scheduler/queue: team-a
    priorityClassName: train
spec:
  headGroupSpec:
    template:
      spec:
        containers:
        - name: ray-head
          image: rayproject/ray:2.46.0
          resources:
            limits:
              cpu: 4
              memory: 15Gi
            requests:
              cpu: "1"
              memory: "2Gi"
 # ---- Bir İşçi GPU'ya Sahip ----
  workerGroupSpecs:
  - groupName: worker
    replicas: 1
    minReplicas: 1
    maxReplicas: 2
    template:
      spec:
        containers:
        - name: ray-worker
          image: rayproject/ray:2.46.0
          resources:
            limits:
              cpu: 4
              memory: 15Gi
            requests:
              cpu: "1"
              memory: "1Gi"
              nvidia.com/gpu: "1"

İş yükünü uygulamak için aşağıdaki komut çalıştırılmalıdır:

kubectl apply -f kai-scheduler-example.yaml

KAI, ardından Ray baş ve iki işçiyi bir grup olarak planlar.

Yüksek Öncelikli Çıkarım Servisi Kurma

Artık bir eğitim iş yükü göndermişken, KAI Scheduler’ın çıkarım iş yüklerini nasıl yönettiğini göstereceğiz. Bu iş yükleri, öncelikli olup geçersiz kılma işlemi yapabilmediğinden, hızlı model tepkileri için önemlidir.

Bu örnekte aşağıdaki adımlar gerçekleştirilecektir:

Qwen2.5-7B-Instruct’i vLLM kullanarak Ray Serve ve RayService ile dağıtım.
İş yükü, eğitim iş yükü ile aynı kuyruğa (team-a) gönderilecektir.
KAI planlaması için kai.scheduler/queue etiketinin kullanılması sağlanacaktır.
Bu iş yükünün yüksek öncelikli olduğunu belirtmek için priorityClassName: inference olarak işaretlenmesi sağlanacaktır.

Not: KAI ile planlama için gereken tek etiket, kai.scheduler/queue etiketidir. Burada kullanılan priorityClassName: inference, sadece bu demoda öncelik geçersiz kılmayı göstermek amacıyla kullanılmaktadır. Ayrıca, YAML’ı uygulamadan önce hf-token adında bir Kubernetes sırrı oluşturarak Hugging Face belirtecini yerleştirdiğinizden emin olun.

Aşağıdaki manifest ile dağıtım yapılacaktır (sırrı eklemeyi unutmayın):

apiVersion: ray.io/v1
kind: RayService
metadata:
  name: ray-kai-scheduler-serve-llm
  labels:
    kai.scheduler/queue: team-a      
    priorityClassName: inference     

spec:
  serveConfigV2: |
    applications:
    - name: llms
      import_path: ray.serve.llm:build_openai_app
      route_prefix: "/"
      args:
        llm_configs:
        - model_loading_config:
            model_id: qwen2.5-7b-instruct
            model_source: Qwen/Qwen2.5-7B-Instruct
          engine_kwargs:
            dtype: bfloat16
            max_model_len: 1024
            device: auto
            gpu_memory_utilization: 0.75
          deployment_config:
            autoscaling_config:
              min_replicas: 1
              max_replicas: 1
              target_ongoing_requests: 64
            max_ongoing_requests: 128
  rayClusterConfig:
    rayVersion: "2.46.0"
    headGroupSpec:
      rayStartParams:
        num-cpus: "0"
        num-gpus: "0"
      template:
        spec:
          containers:
          - name: ray-head
            image: rayproject/ray-llm:2.46.0-py311-cu124
            ports:
            - containerPort: 8000
              name: serve
              protocol: TCP
            - containerPort: 8080
              name: metrics
              protocol: TCP
            - containerPort: 6379
              name: gcs
              protocol: TCP
            - containerPort: 8265
              name: dashboard
              protocol: TCP
            - containerPort: 10001
              name: client
              protocol: TCP
            resources:
              limits:
                cpu: 4
                memory: 16Gi
              requests:
                cpu: 1
                memory: 4Gi
    workerGroupSpecs:
    - replicas: 1
      minReplicas: 1
      maxReplicas: 1
      numOfHosts: 1
      groupName: gpu-group
      rayStartParams:
        num-gpus: "1"
      template:
        spec:
          containers:
          - name: ray-worker
            image: rayproject/ray-llm:2.46.0-py311-cu124
            env:
            - name: HUGGING_FACE_HUB_TOKEN
              valueFrom:
                secretKeyRef:
                  name: hf-token
                  key: hf_token
            resources:
              limits:
                cpu: 4
                memory: 15Gi
                nvidia.com/gpu: "1"
              requests:
                cpu: 1
                memory: 15Gi
                nvidia.com/gpu: "1"

---
apiVersion: v1
kind: Secret
metadata:
  name: hf-token
type: Opaque
stringData:
  hf_token: $HF_TOKEN

İş yükünü uygulamak için:

kubectl apply -f ray-service.kai-scheduler.llm-serve.yaml

Modeli yükleme ve vLLM motorunu başlatma süreci biraz zaman alacaktır.

Geçersiz Kılma Davranışını Gözlemleme

Uygulandıktan sonra, KAI Scheduler’ın, çıkan iş yükü ile çıkarım iş yükü arasında GPU kaynakları için geçersiz kılma sağladığını göreceksiniz. Bu iki iş yükü aynı kaynağı bekler.

Pod’ları listelemek için kullanılacak örnek komut:

$ kubectl get pods
NAME                                                   READY   STATUS    RESTARTS   AGE
ray-kai-scheduler-serve-llm-xxxx-gpu-group-worker-xxxx 1/1     Running   0          21m
ray-kai-scheduler-serve-llm-xxxx-head-xxxx             1/1     Running   0          21m
raycluster-sample-head-xxxx                            0/1     Running   0          21m
raycluster-sample-worker-worker-xxxx                   0/1     Running   0          21m

Basitlik açısından, bu demoda Hugging Face modelini konteynerin içinde kullandık. Bu, KAI Scheduler’ın mantığını ve geçersiz kılma davranışını göstermek için iş görürken, gerçek üretim ortamlarında model yükleme süresi kritik bir faktör olabilir.

Bu durumda, NVIDIA Run:ai Model Streamer öneriyoruz; bu, vLLM ile yerel olarak entegre olup Ray ile sorunsuz bir şekilde kullanılabilir.

Dağıtılan Model ile Etkileşim Kurma

Ray kontrol paneline veya çıkarım uç noktasına erişim sağlamak için bağlantı noktasını yönlendirmeden önce mevcut hizmetleri listeleyelim:

$ kubectl get svc
NAME                                         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                                         AGE
ray-kai-scheduler-serve-llm-head-svc         ClusterIP   None            xxxxxx        10001/TCP,8265/TCP,6379/TCP,8080/TCP,8000/TCP   17m
ray-kai-scheduler-serve-llm-xxxxx-head-svc   ClusterIP   None            xxxxxx        10001/TCP,8265/TCP,6379/TCP,8080/TCP,8000/TCP   24m
ray-kai-scheduler-serve-llm-serve-svc        ClusterIP   xx.xxx.xx.xxx   xxxxxx        8000/TCP                                        17m
raycluster-sample-head-svc                   ClusterIP   None            xxxxxx        10001/TCP,8265/TCP,6379/TCP,8080/TCP,8000/TCP   32m

Şimdi hizmet isimlerini gördüğümüze göre, aşağıdaki şekilde port yönlendirme yapılacaktır:

ray-kai-scheduler-serve-llm-xxxxx-head-svc ile Ray kontrol panelini yönlendireceğiz.
ray-kai-scheduler-serve-llm-serve-svc ile modelin uç noktasını yönlendireceğiz.

Ray kontrol panelini yönlendirmek için:

kubectl port-forward svc/ray-kai-scheduler-serve-llm-xxxxx-head-svc 8265:8265

Ardından, Ray kontrol paneline erişmek için http://127.0.0.1:8265 adresini açın.

A screenshot of Ray dashboard, where users can see the status of their workloads. — *Şekil 1. Ray kontrol panelinin genel görünümü*

Daha sonra, LLM uç noktasını yönlendirmek için:

kubectl port-forward svc/ray-kai-scheduler-serve-llm-serve-svc 8000:8000

Son olarak, OpenAI uyumlu bir API çağrısı ile modeli sorgulayabilirsiniz:

curl http://localhost:8000/v1/completions -H "Content-Type: application/json" -d '{
        "model": "qwen2.5-7b-instruct",
        "prompt": "San Francisco bir",
        "max_tokens": 13,
        "temperature": 0}'

Örnek yanıt:

{
  "id": "qwen2.5-7b-instruct-xxxxxx",
  "object": "text_completion",
  "created": 1753172931,
  "model": "qwen2.5-7b-instruct",
  "choices": [
    {
      "index": 0,
      "text": " mahalledir, her biri kendi karakteri ve cazibesi ile özgün.",
      "finish_reason": "length"
    }
  ],
  "usage": {
    "prompt_tokens": 4,
    "completion_tokens": 13,
    "total_tokens": 17
  }
}

Sonuç

Bu blog yazısında, KAI Scheduler’ın Ray iş yüklerini nasıl geliştirdiğini, özellikle gang scheduling ve hierarchical queuing ile birlikte iş yüklerinin nasıl verimli bir şekilde önceliklendirilerek yönetildiğini inceledik. Çıkarım iş yüklerinin, eğitim işlerini geçersiz kılabilmesi sayesinde kaynakların daha akıllıca kullanıldığını gösterdik.

Bu demo, basit bir açık ağırlık modeli ve Hugging Face kullanarak hazırlandı. Ancak, NVIDIA Run:ai Model Streamer gibi üretim sınıfı bir çözüm, model başlatma sürelerini azaltabilir. Bu stream yapısı, S3 veya yüksek bant genişliğine sahip depolama alanlarından doğrudan GPU belleğine model ağırlıklarını akıtarak çalışır. Bizimle birlikte bu altyapıyla neler inşa edeceğinizi merak ediyoruz! İyi planlamalar!

KAI Scheduler ekibi, bu Kasım Atlanta’daki KubeCon North America etkinliğinde yer alacak. Gang scheduling, iş yükü otomatik ölçekleme veya AI iş yükü optimizasyonu hakkında sorularınız mı var? Bizi standımızda veya oturumlarımızda bulabilirsiniz.

KAI Scheduler ile başlamaya hazır mısınız? Daha fazla bilgi için resmi kaynağımıza göz atabilirsiniz.