Çok kiracılı (multi-tenant) bir yapay zeka platformu tasarlarken karşılaşılan temel ikilem, kaynak kullanım verimliliği ile güvenlik izolasyonu arasındaki hassas dengedir. Donanım kaynaklarını maksimum yoğunlukta kullanmak maliyetleri düşürürken, kiracılar arasında sıkı sınırlar çizmek veri sızıntısı ve çapraz etkileşim risklerini minimize eder. Bu yazıda, GPU kaynaklarının paylaştırılmasından API ağ geçidinde yetkilendirme stratejilerine, model çıkarım katmanındaki izolasyon mekanizmalarından güvenlik olaylarına müdahale süreçlerine kadar mimari bir yol haritası sunuyoruz. Her bölümde, mühendislik kararlarınızı şekillendirecek somut kurallar, gerçek dünya senaryoları ve genellikle göz ardı edilen kritik güvenlik riskleri yer almaktadır.

1. İzolasyon Modeli: Namespace ve Konteyner Sanallaştırma Dengesi

Çok kiracılı bir mimaride ilk adım, izolasyonun hangi katmanda uygulanacağına karar vermektir. Paylaşımlı namespace kullanımı en düşük ek yükü sunsa da, kernel seviyesindeki bir açık tüm kiracıları savunmasız bırakır. Konteyner bazlı izolasyon, cgroup ve seccomp profilleriyle süreç düzeyinde koruma sağlar ancak paylaşımlı kernel riski devam eder. Sanal makine (VM) tabanlı bölmelendirme ise en güçlü sınırı çizer, fakat başlatma süresi ve bellek tüketimi açısından maliyetlidir. Uygulamada en sık yapılan hata, "güvenlik" gerekçesiyle her kiracıya VM atamaktır; bu, özellikle GPU paylaşımında VFIO passthrough kısıtlamaları nedeniyle verimliliği öldürür.

Uzman Bakışı: Konteyner içinde NVIDIA MIG (Multi-Instance GPU) kullanmak, VM'lerin sunduğu donanım seviyesinde izolasyonu, konteynerlerin esnekliğiyle birleştirir. Bu yaklaşım, GPU'yu fiziksel olarak dilimleyerek kiracıların birbirinin bellek alanına erişmesini engeller.

Örnek: Sahte tespit modeli sunan bir platform, 40 kiracıyı tek bir A100 GPU üzerinde MIG ile 7 dilime bölmüştür. Her kiracı grubu kendi MIG diliminde çalışarak, VM tabanlı yapıya kıyasla %60 daha yüksek kaynak yoğunluğu elde etmiştir.

Karar Kuralı: Finans veya sağlık gibi regülasyona tabi sektörlerde VM veya MIG bazlı izolasyon tercih edin. Diğer durumlarda, kiracı başına ayrı bir Kubernetes namespace ve sıkı NetworkPolicy tanımları yeterli korumayı sağlar.

2. Hesaplama Kaynaklarında Adil Paylaşım ve Throttling

Paylaşımlı bir GPU havuzunda, bir kiracının yoğun çıkarım talepleri diğerlerinin yanıt sürelerini (latency) dramatik şekilde artırabilir. Kubernetes'teki standart ResourceQuota mekanizmaları, GPU'nun zaman dilimi paylaşımını yönetmekte yetersiz kalır. Burada NVIDIA MPS (Multi-Process Service) ve Triton Inference Server gibi araçlarla kuyruk yönetimi kritik hale gelir. Sadece "istek başına süre" metriğine odaklanmak yanıltıcıdır; asıl tehlike, batch boyutunun artmasıyla P99 gecikme sürelerinde yaşanan patlamalardır.

Uzman Bakışı: Bir kiracı batch boyutunu 1'den 32'ye çıkardığında ortalama süre değişmeyebilir ancak P99 gecikmesi katlanarak artar. Bu "gürültülü komşu" (noisy neighbor) etkisini engellemek için her kiracıya özel batch üst sınırı ve eşzamanlılık (concurrency) limiti tanımlanmalıdır.

Örnek: Bir metin üretme API'sinde, büyük bir müşterinin dakikada 2000 istek göndermesi, küçük müşterilerin yanıt süresini 300 ms'den 8 saniyeye fırlatmıştır. Çözüm olarak kiracı başına eşzamanlılık sınırı 50'ye, batch boyutu 16'ya sabitlenmiş ve Triton kuyruk derinliği 100 ile kısıtlanmıştır.

Karar Kuralı: Her kiracı için hem eşzamanlı istek sayısını hem de batch boyutunu ayrı ayrı kısıtlayın. Sadece istek sayısını sınırlamak, büyük batch gönderen bir kiracının GPU belleğini tamamen doldurmasını engellemez.

3. Model Çıkarım Katmanında Veri İzolasyonu

Model çıkarım katmanında veri sızıntısı, genellikle paylaşımlı bellek alanları veya yanlış yapılandırılmış önbellek (cache) mekanizmaları üzerinden gerçekleşir. Kiracıların modelleri aynı bellek alanında (VRAM) tutuluyorsa, bellek temizleme süreçlerinin (garbage collection) atomik olması gerekir. Ayrıca, model ağırlıklarının yüklenmesi sırasında kiracı kimliğinin (tenant ID) her zaman bağlam (context) olarak iletilmesi ve çıkarım sonucunun sadece ilgili kiracıya dönen bir "isolation proxy" üzerinden geçmesi şarttır.

Uzman Bakışı: En büyük risk, "model caching" mekanizmasıdır. Bir kiracının yüklediği modelin, başka bir kiracının isteğiyle tetiklenmesi veya önbellekten okunması ciddi bir veri ihlalidir. Modelleri, kiracı ID'si ile etiketlenmiş ayrı namespace'lerde veya şifrelenmiş volume'larda tutun.

Örnek: Bir görüntü işleme platformu, her kiracının modelini ayrı bir "model-server" konteynerinde çalıştırarak, modellerin bellekte birbirine karışmasını engellemiştir. Bu, bellek izolasyonunu garanti altına alsa da, model yükleme süresini artırdığı için "warm-start" havuzları ile optimize edilmiştir.

Karar Kuralı: Model çıkarım katmanında "stateless" (durumsuz) bir yapı kurun. Her isteğin, kiracı kimliğini içeren bir JWT token ile doğrulanması ve modelin bu kimliğe göre dinamik olarak yüklenmesi, sızıntı riskini sıfıra indirir.

4. API Ağ Geçidinde Yetkilendirme ve Güvenlik

API ağ geçidi (API Gateway), çok kiracılı mimarinin giriş kapısıdır ve burada yapılacak bir hata tüm platformu savunmasız bırakır. Kiracı bazlı yetkilendirme, sadece "geçerli token" kontrolü ile sınırlı kalmamalıdır. İsteklerin hangi kiracıya ait olduğu, JWT içerisindeki `tenant_id` alanı ile doğrulanmalı ve bu ID, arka uçtaki tüm mikroservislere "header" olarak iletilmelidir. Ayrıca, her kiracı için ayrı API anahtarları (API Keys) oluşturulmalı ve bu anahtarların kullanım limitleri (rate limiting) merkezi bir veritabanında gerçek zamanlı izlenmelidir.

Uzman Bakışı: API Gateway katmanında "Request Transformation" kullanarak, gelen isteklere kiracı kimliğini eklemek, arka uç servislerinin kiracı ayrımını yapmasını kolaylaştırır. Ancak, Gateway'in kendisinin bir darboğaz (bottleneck) haline gelmemesi için bu kontrollerin dağıtık bir cache (Redis gibi) üzerinde yapılması gerekir.

Örnek: Bir finansal analiz platformu, API Gateway üzerinde "Opa" (Open Policy Agent) kullanarak, kiracıların sadece kendi verilerine erişebileceği dinamik politikalar uygulamıştır. Bu sayede, kod seviyesinde yetkilendirme hatası yapma riski ortadan kaldırılmıştır.

Karar Kuralı: API Gateway'de her zaman "Zero Trust" prensibini uygulayın. İstek, platforma girdiği anda kiracı kimliği ile etiketlenmeli ve bu etiket, sistemin en uç noktasındaki veritabanı sorgusuna kadar taşınmalıdır.

5. Güvenlik Olayı Anında İzolasyon ve Müdahale

Bir güvenlik ihlali veya anormal trafik artışı yaşandığında, tüm platformun çökmesini engellemek için "kill-switch" mekanizmalarına sahip olmalısınız. İzolasyon adımları, etkilenen kiracının kaynaklarını anında kısıtlamayı veya trafiğini tamamen kesmeyi içermelidir. Bu süreç, manuel müdahale yerine, sistemin otomatik olarak tetiklediği "circuit breaker" (devre kesici) desenleri ile yönetilmelidir. Bir kiracının diğerlerini etkilediği anlaşıldığında, o kiracının konteynerleri izole bir ağ segmentine (quarantine) taşınmalıdır.

Uzman Bakışı: Güvenlik olaylarında en büyük hata, tüm platformu durdurmaktır. Bunun yerine, "graceful degradation" (kademeli hizmet düşüşü) uygulayarak, sadece şüpheli kiracının trafiğini kısıtlayın. İhlal anında kiracının tüm veritabanı bağlantılarını "read-only" moduna almak, veri kaybını önlemek için en hızlı aksiyondur.

Örnek: Bir AI platformu, bir kiracının "prompt injection" saldırısı yaptığını tespit ettiğinde, o kiracının API anahtarını otomatik olarak devre dışı bırakmış ve ilgili konteynerleri karantinaya almıştır. Bu süreç, sistemin geri kalanını etkilemeden 2 saniye içinde gerçekleşmiştir.

Karar Kuralı: Otomatik izolasyon prosedürlerini (quarantine) mutlaka test edin. Bir kiracının sistem kaynaklarını tüketmesi durumunda, sistemin diğer kiracıları korumak için hangi kiracıyı "feda edeceğini" belirleyen bir önceliklendirme matrisi oluşturun.

Conclusion

Çok kiracılı bir AI platformunda güvenlik ve kaynak paylaşımı, statik bir yapı değil, sürekli evrilen bir denge oyunudur. İzolasyon modelinizi seçerken donanım kısıtlamalarını (MIG gibi) göz önünde bulundurmak, kaynak paylaşımında P99 gecikme sürelerini merkeze almak ve API katmanında "Zero Trust" mimarisini benimsemek, platformunuzun ölçeklenebilirliğini ve güvenliğini garanti altına alır. Unutmayın ki, en güvenli sistem bile yanlış yapılandırılmış bir "batch" boyutu veya yetersiz bir "circuit breaker" mekanizması nedeniyle kolayca zafiyet gösterebilir. Bu yazıda ele alınan stratejileri, platformunuzun özgün ihtiyaçlarına göre uyarlayarak hem maliyet verimliliğini artırabilir hem de kiracılarınız için sarsılmaz bir güven ortamı inşa edebilirsiniz. Mimari kararlarınızda daima "en kötü durum senaryosunu" (worst-case scenario) temel alarak tasarlamak, uzun vadede en büyük kazancınız olacaktır.