Paylaşımlı Yapay Zeka Platform Mimarisi: On-Premises Altyapıyla Birden Fazla Ekibe Hizmet Vermek

Paylaşımlı altyapı sorunu

On-premises yapay zeka altyapısına yatırım yapan çoğu kurum öngörülebilir bir evrim yaşar. Her şey tek bir ekiple başlar; çoğu zaman veri bilimi ya da mühendislik ekibi belirli bir proje için GPU tedarik eder. Başarı yeni talep yaratır ve diğer departmanlar da erişim ister. Çok geçmeden kurum ya birbirinden kopuk GPU kümeleri yığınına sahip olur; bu yapı pahalıdır ve çoğu zaman düşük kullanımlıdır. Ya da yeterli izolasyondan yoksun, paylaşımlı bir platform ortaya çıkar; bu da riskli ve çatışmalı bir ortam yaratır.

Paylaşımlı yapay zeka platform mimarisi, on-premises GPU altyapınızı doğru izolasyon, kaynak yönetişimi ve self-servis yetenekleri ile ortak kullanılan bir hizmet gibi ele alarak bu sorunu çözer. İyi tasarlandığında donanım kullanımını en üst düzeye çıkarırken her ekibe ihtiyaç duyduğu özerkliği ve güvenliği sağlar. Kötü tasarlandığında ise en yüksek sesle talep eden ekibin en fazla GPU'yu aldığı politik bir mücadele alanına dönüşür.

Bu yazı, paylaşımlı on-premises yapay zeka platformlarını pratikte işler hale getiren mimari kalıpları, izolasyon stratejilerini ve yönetişim modellerini ele alır.

İzolasyon modelleri: doğru sınırı seçmek

Paylaşımlı yapay zeka platformlarında temel tasarım kararı, izolasyon sınırlarını nereye çizeceğinizdir. Üç yaygın model vardır ve her biri farklı ödünleşmeler içerir:

Namespace izolasyonu (hafif ayrıştırma). Tüm ekipler aynı Kubernetes kümesini paylaşır; kaynak kotaları ve ağ politikalarıyla namespace bazında ayrıştırılır. Bu model en yüksek donanım kullanımını sağlar çünkü bir ekibin boşta kalan kaynakları diğerleri tarafından kullanılabilir. Bedeli ise daha zayıf güvenlik sınırlarıdır; örneğin bir container escape ya da çekirdek seviyesindeki bir güvenlik açığı namespace sınırlarını aşabilir. Bu model, benzer güven düzeyine sahip iç ekipler için uygundur.

Node pool izolasyonu (orta düzey ayrıştırma). Her ekip, paylaşımlı küme içinde kendisine ayrılmış node pool'lara sahip olur. GPU node'ları taint ve toleration mekanizmalarıyla belirli ekiplere atanır; ayrıca özel kapasite tükendiğinde herhangi bir ekibin kullanabileceği burst node'lar tanımlanabilir. Ekipler farklı fiziksel makinelerde çalıştığı için daha güçlü izolasyon sağlanır; buna rağmen küme yönetim yükü ortak kalır. Bu yaklaşım çoğu kurumsal dağıtım için iyi bir varsayılandır.

Küme izolasyonu (sert ayrıştırma). Her ekip tamamen ayrı bir Kubernetes kümesi kullanır. Bu en güçlü izolasyonu sağlar ve özellikle ekipler farklı uyumluluk gereksinimlerine sahipse anlamlıdır. Bunun karşılığında yönetim yükü artar ve kaynaklar kümeler arasında paylaşılamadığı için toplam kullanım oranı düşer.

Pratikte birçok kurum hibrit bir yaklaşım benimser: sıkı uyumluluk gereksinimi olan ekipler için sert izolasyon, diğer ekipler için ise node pool izolasyonu kullanılır.

Kaynak tahsisi ve adil zamanlama

On-premises GPU kaynakları sınırlı ve pahalıdır. Doğru tahsis yapılmadığında ya tek bir ekip donanımı fiilen tekelleştirir ya da işler kuyrukta beklerken kaynaklar boşta kalır. Etkili paylaşımlı kaynak yönetimi için üç mekanizma gerekir:

Garanti edilen minimum kapasite. Her ekibe her zaman erişebileceği temel bir tahsis verilir. Bu tahsisi her ekibin sürekli çalışan iş yüküne göre boyutlandırın. Örneğin inference iş yükleri için bu 2 GPU olabilir; fine-tuning yapan bir ekip için 8 GPU gerekebilir. Tüm garanti edilen minimumların toplamı, toplam kapasitenizi aşmamalıdır; bu sizin taahhüt edilmiş tahsisinizdir.

Burst kapasitesi. Garanti edilen minimumların üzerindeki kaynaklar ortak bir burst havuzunu oluşturur. Ekipler, uygun olduğunda bu havuzu kullanabilir; ancak başka bir ekibin garanti edilen kapasitesine ihtiyacı olduğunda bu kaynaklar geri alınabilir. Buradaki preemption mantığını dikkatle ayarlayın: gecikmeye duyarlı inference iş yüklerinin, checkpoint alıp devam edebilen eğitim işlerinden daha yüksek önceliğe sahip olması gerekir.

Kota uygulaması. Tek bir ekibin tüm burst kapasitesini tüketmesini önlemek için sert sınırlar koyun. Yaygın bir kalıp şudur: garanti edilen minimum + en fazla 2 kat burst, ayrıca küme genelinde bir üst sınır. Bu sayede kontrolden çıkan bir eğitim işi diğer tüm ekipleri aç bırakmaz.

Kubernetes Resource Quotas ile özel zamanlayıcıların birleşimi ya da Run:ai ve Volcano gibi platformlar bu mekanizmaları sağlayabilir. Eğer doğrudan Kubernetes üzerinde ilerliyorsanız, Kubernetes yerel iş kuyruğu sistemi olan Kueue artık yeterince olgun ve paylaşımlı GPU zamanlamasını iyi yönetebiliyor.

Self-servis model dağıtımı

Her model dağıtımı için altyapı ekibine bağımlı olan paylaşımlı bir platform kısa sürede darboğaza dönüşür. Bunun yerine, ekiplerin kendi tahsis edilmiş kaynakları içinde kendi modellerini dağıtıp yönetebileceği bir self-servis katman tasarlayın.

Model registry. Ekiplerin sürümlü modellerini yayınladığı ortak bir model registry işletin. Bunun için MLflow, container image'lar için Harbor ya da Seldon benzeri özel bir çözüm kullanılabilir. Registry; adlandırma kurallarını ve zorunlu metadata alanlarını dayatmalıdır. Her modelin bir sahibi, bir lisans etiketi ve bir kaynak profili bulunmalıdır; örneğin beklenen GPU belleği ve beklenen gecikme gibi bilgiler eksiksiz olmalıdır.

Dağıtım şablonları. Ekiplerin özelleştirebileceği standart deployment şablonları sağlayın. Böyle bir şablon; inference sunucusu tipini (vLLM, Triton, TGI), ölçeklendirme parametrelerini, kaynak istek ve limitlerini, sağlık kontrolü uç noktalarını ve loglama yapılandırmasını tanımlayabilir. Ekipler modele özgü alanları doldurur; platform ise ağ, TLS, kimlik doğrulama ve gözlemlenebilirlik tarafını yönetir.

API gateway. Tüm inference isteklerini; kimlik doğrulama, rate limiting, istek loglama ve ekip bazlı ölçüm yapan ortak bir API gateway üzerinden geçirin. Kong, Envoy ya da NGINX tabanlı özel bir gateway bu rolü üstlenebilir. Ayrıca model erişim politikalarını da burada uygularsınız; her ekibin her modeli çağırabiliyor olması gerekmez.

Sandbox ortamları. Her ekibe sınırlı kaynaklara sahip bir sandbox namespace verin. Bu alan, üretim iş yüklerini veya diğer ekipleri etkilemeden yeni modelleri denemelerini sağlar. Kaynakları geri kazanmak için sandbox ortamlarını yapılandırılabilir bir boşta kalma süresinin ardından otomatik olarak temizleyin.

Yönetişim ve maliyet görünürlüğü

Maliyet görünürlüğü olmayan paylaşımlı altyapı aşırı tüketime yol açar. Yönetişim olmayan bir ortam ise uyumluluk ihlallerine davetiye çıkarır. Olgun bir paylaşımlı platform her ikisine de ihtiyaç duyar.

Kullanım ölçümü. Ekip bazında GPU-saatlerini, inference isteklerini, depolamayı ve ağ çıkışını izleyin. Bu verileri ekip liderlerinin erişebileceği panolarda görünür hale getirin. İç maliyet yansıtma modeli kurmasanız bile görünürlük tek başına davranışı değiştirir; tüketimini diğer ekiplerle kıyaslayabilen ekipler genellikle kendi kendini optimize etmeye başlar.

Veri yönetişimi. Paylaşımlı bir ortamda verinin ekipler arasında sızmamasını garanti altına alın. Bunun anlamı şudur: ekip başına ayrı depolama birimleri, namespace'ler arası trafiği engelleyen ağ politikaları, ekip iş yükleri arasında GPU belleğini paylaşmayan model serving yapılandırmaları ve her veri erişimini izleyen denetim logları.

Model yönetişimi. Platformda hangi modellerin dağıtılabileceğini tanımlayan açık bir politika oluşturun. Bu politika; onaylı model kaynaklarını, üretim dağıtımı öncesi zorunlu güvenlik değerlendirmelerini, zorunlu metadata alanlarını ve dağıtıma alınmış modeller için periyodik yeniden değerlendirme gereksinimlerini kapsamalıdır. Örneğin veri kökeni, değerlendirme sonuçları ve bilinen sınırlamalar her model için belgelenmelidir.

Erişim kontrolü. Birden fazla seviyede rol tabanlı erişim uygulayın. Platform yöneticileri küme yapılandırmasını ve ekiplerin platforma alınma sürecini yönetir. Ekip yöneticileri kendi ekiplerinin kaynak tahsisini, model dağıtımlarını ve kullanıcı erişimlerini yönetir. Geliştiriciler kendi alanları içinde modelleri dağıtır ve inference uç noktalarına erişir. Son kullanıcılar ise uygun hız limitleri altında gateway üzerinden inference API'lerini tüketir.

Yaygın tuzaklar ve bunlardan kaçınmak

Bazı kalıplar, paylaşımlı yapay zeka platformlarında düzenli olarak sorun yaratır:

Garanti edilen tahsisleri fazla vermek. Platform ilk kurulduğunda ekipler "ne olur ne olmaz" diye ihtiyaçlarından fazla garanti edilmiş kapasite isteme eğilimindedir. Bu da burst havuzuna gidebilecek kaynakları kilitler. Gerçek kullanım ölçümlerine dayalı, muhafazakar garanti tahsisleriyle başlayın ve veriye bakarak çeyreklik dönemlerde ayarlama yapın.

Noisy neighbor etkisini görmezden gelmek. Kaynak izolasyonu sağlansa bile depolama I/O, ağ bant genişliği ve tokenizasyon için CPU gibi paylaşımlı bileşenler çekişme yaratabilir. Bu nedenle yalnızca GPU'yu değil, paylaşılan diğer kaynakları da izleyin ve onlar için de adil kullanım politikaları oluşturun.

Her şeyi aşırı merkezileştirmek. Her dağıtımı kontrol eden bir platform ekibi darboğaz yaratır. Hiçbir şeyi kontrol etmeyen bir platform ekibi ise kaos üretir. Dengeyi bulun: platform ekibi altyapının, şablonların ve politikaların sahibi olsun; ekipler ise bu korkuluklar içinde kendi modellerini, yapılandırmalarını ve dağıtım zamanlamalarını yönetsin.

Onboarding deneyimini ihmal etmek. Yeni bir ekibi platforma almak haftalarca bilet, toplantı ve manuel işlem gerektiriyorsa ekipler mutlaka etrafından dolaşmanın yolunu bulur; gölge BT ile GPU satın alımları yapar, buluta kaçar ya da mevcut ekip alanlarında paylaşımlı kimlik bilgileri kullanır. Bu yüzden akıcı bir onboarding sürecine yatırım yapın: self-servis bir form, otomatik namespace hazırlama, varsayılan kotalar ve bir ekibi sıfırdan ilk inference çağrısına bir günden kısa sürede ulaştıran başlangıç rehberi sağlayın.

Öne çıkan görsel: Lightsaber Collection tarafından Unsplash'ta paylaşılmıştır.