NVIDIA Dynamo için Kubernetes runtime’ı AICR recipe’leriyle kurmak

NVIDIA, NVIDIA Dynamo’yu Kubernetes üzerinde inference (çıkarım) endpoint’ine kadar götürmek için gereken runtime katmanını AI Cluster Runtime (AICR) recipe’leriyle kurup doğrulamayı anlatan bir rehber yayımladı. AICR’ın paketlediği dynamo-platform chart’ının 1.4.2 sürümünde DynamoGraphDeployment CRD’si nvidia.com/v1beta1 API’sine geçiyor ve NATS artık varsayılan olarak kurulmuyor. Rehber, Dynamo Frontend router ile Gateway API ve Endpoint Picker (EPP) olmak üzere iki routing yolunu karşılaştırıyor.

NVIDIA Dynamo nedir, ne işe yarar?

NVIDIA Dynamo, büyük dil modellerinin inference işini birden çok GPU worker’a dağıtan açık kaynak bir framework’tür. vLLM, SGLang ve TensorRT LLM gibi motorları arka uç olarak kullanır, istekleri KV cache durumuna göre yönlendirir ve prefill ile decode aşamalarını ayrı havuzlarda çalıştırabilir. Kubernetes üzerinde model servis eden platform ekipleri kullanır; benzer işi gören projeler arasında llm-d ve KServe sayılabilir.

NVIDIA Dynamo’yu Kubernetes’e kuran ekiplerin asıl derdi DynamoGraphDeployment manifest’i değil, altındaki katman. GPU Operator’ün driver stack’i node’lara uymuyorsa model ayağa kalkmıyor. DRA (Dynamic Resource Allocation) driver’ı GPU’ları beklenen şekilde açmıyorsa ya da scheduler gang scheduling yapamıyorsa worker’lar Pending’de bekliyor.

AICR bu bağımlılıkları sürümü sabitlenmiş bir recipe’ye bağlıyor ve kurulumdan sonra doğrulama çalıştırıyor. Yaklaşım bir lock dosyasına benziyor: bileşenleri tek tek seçmek yerine birlikte test edilmiş bir kombinasyonu alıyorsunuz. Bedeli de aynı. Recipe dışına çıkardığınız her bileşen sürümü doğrulamanın kapsamından da çıkıyor.

NVIDIA Dynamo 1.4.2’ye geçmeden önce

İki değişiklik var olan kurulumları doğrudan etkiliyor.

• DynamoGraphDeployment CRD’si artık nvidia.com/v1beta1. Eski v1alpha1 manifest’lerini Git repository’nizde ve kendi Helm chart’larınızda arayın. apiVersion alanını güncellemeden yükseltmeye girmeyin.
• Dynamo 1.4’te Frontend, worker ve EPP bileşenleri birbirini Kubernetes kaynakları üzerinden buluyor. Bu yüzden dynamo-platform chart’ı NATS’i varsayılan olarak kurmuyor. NATS’e bağlı bir akışınız varsa opt-in olarak açmanız gerekiyor.

Küçük bir envanter işinizi görür:

kubectl api-resources | grep -i dynamo
grep -rn "v1alpha1" ./manifests

Frontend router mı, Gateway API ve EPP mi?

Karar tek bir soruya iniyor: timeout, retry ve fallback kararını kim verecek? Dynamo Frontend mi, yoksa platform ekibinin yönettiği gateway mi?

Frontend router yolu Service arkasında tek bir Dynamo Frontend çalıştırıyor. DYN_ROUTER_MODE=kv ile istekleri prefix örtüşmesine ve worker yüküne göre dağıtıyor. En küçük topoloji bu ve production’da en çok denenmiş seçenek. Modele özel endpoint’in sahibi uygulama ekibiyse ya da önünüzdeki edge proxy yalnızca trafiği iletiyorsa buradan başlayın.

Gateway API yolu paylaşılan ingress’i yöneten platform ekipleri için. Örnekte agentgateway bir HTTPRoute’u InferencePool’a çözüyor, Dynamo EPP endpoint’i seçiyor. Ama her worker pod’una bir Frontend sidecar (yardımcı container) ekleniyor ve bu sidecar –router-mode direct ile çalışıyor. Yani izlemeniz gereken bileşen sayısı artıyor: gateway, EPP, InferencePool ve pod başına bir sidecar.

İki yol da worker’ların yayımladığı KV cache event’leriyle karar veriyor. Dynamo’yu event yerine tahminle çalışacak şekilde de yapılandırabilirsiniz. Ama tahmin eviction’ları göremiyor ve router’ın tablosu gerçeklikten kayıyor. GPU belleği sıkışık cluster’larda ve uzun prefix taşıyan agent iş yüklerinde bu kayma doğrudan yeniden prefill maliyeti demek. Live event’leri açık tutun.

NetworkPolicy kullanıyorsanız request plane ile KV event plane’in ayrı akışlar olduğunu hesaba katın. 1.4.2’de istekler TCP, KV event’leri ZMQ üzerinden gidiyor. İkisinin de router’a ya da EPP’ye ulaştığını doğrulayın.

AICR akışını sırayla çalıştırmak

AICR runtime kurulumunu uygulama deployment’ından ayırıyor: önce snapshot, sonra recipe, ardından bundle ve doğrulama. Snapshot, placement flag’i verilmezse nvidia.com/gpu.present=true etiketli node’ları hedefliyor. Etiketi eksik bir GPU node’u varsa snapshot’a hiç girmiyor. İlk iş etiketleri kontrol etmek:

kubectl get nodes -l nvidia.com/gpu.present=true
aicr snapshot --namespace aicr-validation --output snapshot.yaml
aicr recipe --snapshot snapshot.yaml --intent inference --platform dynamo --output recipe.yaml

Offline validate (–no-cluster) aynı snapshot’la çalıştırıldığında pek bir şey katmıyor. Asıl kullanım yeri farklı cluster’ları kıyaslamak: staging’den çıkan recipe’yi production snapshot’ına karşı denemek gibi. Bu modda yalnızca bildirimsel kısıtlar değerlendiriliyor, davranışsal kontroller skipped olarak raporlanıyor. Yani dry-run’dan geçen bir recipe canlı doğrulamadan geçmiş sayılmaz.

Rehberdeki örnek recipe Amazon EKS üzerinde GB200 NVL72 ve GB300 NVL72 sistemleri için AICR v1.0.0 ile seçilmiş. Farklı bir dağıtım ya da GPU kullanıyorsanız kendi ortamınız için bir recipe üretilip üretilmediğine ilk adımda bakın.

Dynamo 1.5’te EPP değişiyor

Dynamo 1.4’teki EPP, GAIE’nin (Gateway API Inference Extension) Go framework’ü içine CGO ile gömülü Rust KV router’ı kullanıyor ve eppConfig ile ayarlanıyor. 1.5 ile bunun yerine native bir Rust EPP geliyor. Yapılandırma eppConfig ve scheduling profile’larından DYN_* environment variable’larına taşınıyor. HTTPRoute ve InferencePool topolojisi değişmiyor, istek başına EPP yükü azalıyor.

Bugün Gateway API yolunu seçiyorsanız eppConfig’e yazdığınız her özelleştirme 1.5’te yeniden yapılacak iş demek. Ayarları şimdiden bir tabloda toplayın ki geçişte DYN_* karşılıklarıyla tek tek eşleştirebilesiniz.