«Yapay zekâ fabrikası» tek bir modelden veya tek bir Kubernetes kümesinden ibaret değildir; ince ayar, çıkarım çalıştırma ve değerlendirme gibi farklı amaçlarla eş zamanlı çalışan ekiplerin kullandığı ortak bir GPU işlem birimleri filosudur. CNCF blogunda yayımlanan bir makaleye göre gerçek kurumsal zorluk artık yalnızca modeli eğitmek değil, GPU birimlerinin kullanımını yüksek, maliyeti ise ölçülebilir tutarken her ekibe aynı donanıma güvenli ve yalıtılmış erişim sağlamaktır.
Makale, CNCF Ambassador ve vCluster Platform Advocate’i olan Hrittik Roy tarafından yazılmıştır ve bu ortamın Kubernetes üzerinde nasıl oluşturulabileceğine dair pratik bir değerlendirme sunar. Makalenin temel fikri, Kubernetes’in kapsayıcılar, RBAC, otomatik ölçeklendirme ve politikalar için olgun bir temel sağladığı; ancak hızlandırıcılarla ve aynı düğümlerdeki kiracılar arasındaki izolasyonla başa çıkmak için ek bir ekosisteme ihtiyaç duyduğudur.
Darboğaz yalnızca çıkarım hızı değil, kullanım oranıdır
GPU birimleri, yapay zekâ altyapısındaki en büyük sermaye harcamasını oluşturur. Bu nedenle kullanım oranı, tek bir çalışmada azami hız elde etmekten daha önemli bir ekonomik gösterge hâline gelir. Makale iki temel sorunu ortaya koyar: kaynak tahsis modeli ve izolasyon modeli.
Geleneksel device plugin modelinde iş yükü örneğin nvidia.com/gpu: 1 talep eder ve yalnızca yüzde onunu kullansa bile tam bir birimi rezerve eder. Kubernetes 1.34’te genel kullanıma sunulan Dynamic Resource Allocation veya DRA ise zamanlayıcının hızlandırıcıları özelliklere, belleğe ve topolojiye sahip cihazlar olarak ele almasını sağlar. Ancak bir GPU birimini kendiliğinden paylara bölmez; yoğunluk, konteyner düzeyinde bellek ve işlem sınırları uygulayan ve birden fazla hızlandırıcı tedarikçisini destekleyen, CNCF bünyesinde Incubating aşamasındaki bir proje olan HAMi gibi cihaz katmanından gelir.
Buna karşılık her ekip için ayrı donanım tahsis edilmesi güçlü bir izolasyon sağlayabilir, ancak kapasitenin büyük bir bölümünü kullanılmadan bırakır. Bu nedenle makale, güven sınırları katı olduğunda tam birim tahsisi ile yoğunluğu artırmak için tek bir güven alanı içinde birimin bölünmesi arasında ayrım yapar. NVIDIA MIG, donanım düzeyinde bellek ve hata izolasyonu sağlar; ancak makale, düşmanca kiracılar arasında sınır olarak kullanılmasının hâlâ tartışmalı olduğuna dikkat çeker. Bu nedenle güvenin düşük olduğu durumlarda tam GPU tahsisi ihtiyatlı seçenek olmaya devam eder.
Fabrikanın metalden iş yüküne uzanan katmanları
Sistem ham donanımın tedarikiyle başlar. Düğümler keşfedilir; GPU birimleri, ECC belleğinin durumu ve ağ kartlarının kimlikleri incelenir. Ardından GPU sürücüsü ile CUDA ve NCCL kitaplıklarını içeren işletim sistemi imajı yüklenir. Daha sonra uygun BIOS ayarları uygulanır ve düğümler, GPU birimlerinin tam bant genişliğiyle iletişim kurduğunu doğrulamak için dayanıklılık testlerine ve NCCL testlerine tabi tutulur. Sonuç, NetBox gibi bir gerçeklik kaynağına kaydedilir. Bu süreç, tedarikçiye özel bir donanım yöneticisiyle veya Metal3 ile Ironic ya da vMetal gibi açık araçlar kullanılarak oluşturulabilir.
Tahsis sonrasında KAI Scheduler ve Volcano gibi araçlar toplu ve topoloji farkındalıklı zamanlama işlemlerini yürütürken Kueue bekleme, kabul ve kotaları yönetir. İş yükü katmanında çıkarım motorları için vLLM, standart uç noktalar ve otomatik ölçeklendirme sağlamak için KServe; daha büyük ortamlarda ise ayrıştırılmış çıkarım için NVIDIA Dynamo ve llm-d kullanılabilir. Gateway API yönlendirmeyi sağlarken LiteLLM, OpenAI API’siyle uyumlu bir ağ geçidi ekler.
Platform kapsayıcılarla sınırlı değildir. Makale, eğitim ortamlarının SchedMD tarafından geliştirilen Slinky aracılığıyla Slurm kullanabileceğini belirtir. Slinky, Slurm hizmetlerini özel kaynaklar olarak temsil eder ve bunları GPU Operator ile DRA’ya entegre eder. KubeVirt de sanal makineleri Kubernetes iş yükleri olarak çalıştırabilir; böylece sanal makineler ve kapsayıcılar aynı filodan, birleşik yetkiler ve kotalarla yönetilir.
İzolasyon yalnızca ad alanlarından ibaret değildir
Makale izolasyon sorununu iki düzeye ayırır. Kontrol düzeyinde tenant cluster modeli, her ekibe tek bir temel küme üzerinde iş yükü olarak çalıştırılan API sunucusu, özel kaynaklar, bağımsız kabul kuralları ve ayrı RBAC içeren sanal bir Kubernetes arayüzü sağlar. vCluster buna bir örnektir ve kubectl ile Helm ve Argo CD gibi tanıdık araçların özel eklentiler olmadan kullanılmasına olanak tanır.
Veri düzeyi ise ağların, depolamanın, kotaların ve çalışma ortamının yalıtılmasını gerektirir. CNI ve politikalar için Cilium; hızlı yol için Multus ve SR-IOV; düğümler arasındaki GPU trafiğinin taşınması için InfiniBand veya RoCEv2 kullanılabilir. Ayrıca VXLAN ve EVPN üzerinden ayrı VPC’ler ya da InfiniBand’de bölümleme anahtarları kullanılabilir. NVIDIA BlueField veya AMD Pensando gibi DPU birimleri ise bazı izolasyon ve şifreleme işlevlerini ana makinenin işlemcisinden uzaklaştırır. Makale, gerçek bulut standardının yalnızca ad alanlarına güvenmek değil, gerektiğinde donanım tarafından zorlanan izolasyon olduğunu vurgular.
Filoyu bulut hizmetine dönüştüren nedir?
Editoryal değerlendirme: Bu yaklaşımın pratik değeri, tartışmayı «Hangi model daha hızlı?» sorusundan altyapının kendisini işletme sorusuna taşımasıdır. Platform yalnızca GPU birimlerini bir araya getirdiği için bulut hizmetine dönüşmez; kiracının kümeleri API, Terraform veya GitOps aracılığıyla oluşturup silebilmesi ve kaynakların Flux veya Argo CD tarafından yönetilen bildirimsel bir biçimde tanımlanması gerekir. Buna OIDC kimliği ve RBAC yetkileri de eklenir.
Hizmetin ayrıca anlaşılır ölçüm ve faturalandırma sunması gerekir. Makale, GPU saniyelerini hesaplamak için DCGM verilerinin kullanılmasını ve bunların OpenCost aracılığıyla kiracılara dağıtılmasını önerir. İzleme ve güvenilirlik de operasyonel bir ek değil, ürünün parçasıdır: DCGM bozulmayı izler; Node Problem Detector hata sinyallerini düğüm durumlarına dönüştürür. İşleme döngüsü ise şüpheli düğümü yalıtır ve yeni iş yükleri zamanlanmadan önce boşaltır. Güvenlik katmanında OIDC üzerinden Keycloak, External Secrets Operator ile OpenBao, kontroller için Kyverno veya OPA, çalışma zamanı ve tedarik zinciri güvenliği için Falco ve Trivy gibi araçlar yer alır.
En zor test, gösterimden geniş ölçekli üretime geçiştir. Tek bir bölünmüş GPU üzerinde iki ekip ve iki model çalıştıran örnek, tasarımın yüzlerce düğüm ve birden fazla veri merkezinde geçerli olduğunu tek başına kanıtlamaz. Makale, 1.35 sürümüyle sunulan NVIDIA AI Cluster Runtime ve Kubernetes AI Conformance programı gibi doğrulama araçlarının rolüne işaret eder; ancak patlama yarıçapı, kiracılar arasındaki izolasyon sınırları ve NVIDIA DSX OS paketi ile açık kaynak katmanlarının bir araya getirilmesi arasındaki tercih konusunda işletimsel soruları açık bırakır.
Sonuç olarak «yapay zekâ fabrikasının» başarısı; donanım topolojisini dikkate alarak yoğunluk, izolasyon ve faturalandırmayı birleştirmeye bağlıdır: GPU birimlerinin NVLink veya NVSwitch’e göre konumları, InfiniBand veya RoCE ağına bağlantıları ve GPU, NIC ve CPU’nun NUMA düğümlerindeki yerleşimi önem taşır. İş yükünün bu veriler dikkate alınmadan zamanlanması, platform yazılım düzeyinde sağlıklı görünse bile toplu iletişim işlemlerinin en yavaş bağlantıda yavaşlamasına yol açabilir.