AI Inference Cluster: Yüksek Erişilebilirlik ve Düşük Gecikme
/ Sektörler

AI Inference Cluster: Yüksek Erişilebilirlik ve Düşük Gecikme

Üretim ortamında AI model çıkarımı için optimize edilmiş, SLA güvenceli inference altyapısı.

Eğitilmiş bir modeli üretime taşımak, eğitim aşamasından çok farklı mühendislik gereksinimleri doğurur. Batch işlem yerine milisaniye düzeyinde yanıt, tek bir GPU sunucusu yerine yüzlerce eş zamanlı istek, deneme ortamı yerine yüzde 99,9 çalışma süresi taahhüdü. Üretim ortamı inference’ı, yüksek erişilebilirlik ve düşük gecikme odaklı ayrı bir altyapı disiplini gerektirir.

Inference Neden Eğitimden Farklı Bir Altyapı İster?

Model eğitimi, haftalarca süren tek bir işin tamamlanmasını hedefler: hata toleransı yüksek, throughput odaklı, gecikme toleranslıdır. Inference ise tam tersidir.

  • Düşük gecikme (latency): Müşteriye bakan uygulamalar çoğunlukla 20–100 ms P99 gecikme hedefi tanımlar. Bu değerin aşılması kullanıcı deneyimini doğrudan bozar.
  • Yüksek eş zamanlılık: Aynı modele saniyede binlerce istek ulaşabilir; altyapı bunları sıraya koymadan, kaynak çakışması yaratmadan karşılamalıdır.
  • Ölçekleme esnekliği: Trafik dalgalanır. Gece minimuma düşen yük, bir kampanya veya kriz anında dakikalar içinde çarpanla büyüyebilir.
  • Yüksek erişilebilirlik: Servis kesintisi gelir kaybı ve marka hasarı demektir; SLA güvencesi zorunludur.
  • Model versiyonlama: Yeni model sürümlerinin sıfır kesinti ile devreye alınması (blue-green veya canary deployment) üretim gereksinimi haline gelmiştir.

Tipik Inference İş Yükleri

Büyük Dil Modeli (LLM) Servisi

GPT tarzı otoregressif modeller (Llama, Mistral, Falcon serisi ve kurumsal fine-tune türevleri) token başına hesaplama yoğunlukları nedeniyle en zorlu inference senaryolarını oluşturur. Yanıt süresi hem prefill hem decode aşamasına bağlıdır; her iki aşama ayrı ayrı optimize edilmelidir.

Kritik yazılım bileşenleri:

  • vLLM: PagedAttention ile KV-cache verimini dramatik biçimde artırır; OpenAI uyumlu API sunar
  • TensorRT-LLM: NVIDIA’nın LLM inference motorunun optimize edilmiş versiyonu; H100/A100 üzerinde INT8/FP8 kuantizasyon desteği
  • SGLang: Karmaşık çok-aşamalı prompt yapıları için yüksek throughput

Görüntü ve Video İşleme

Nesne tespiti, segmentasyon, optik karakter tanıma ve video analiz pipeline’ları; özellikle akış tabanlı (streaming) senaryolarda eş zamanlı GPU iş parçacığı yönetimi kritiktir.

Kullanılan çerçeveler: NVIDIA Triton Inference Server, ONNX Runtime, TensorRT, OpenVINO (Intel CPU fallback için)

Multimodal ve Gömülü Model Servisi

CLIP, LLaVA, Whisper gibi ses-görüntü-metin modellerinin aynı cluster üzerinde birlikte çalıştırılması, kaynak izolasyonu ve yük dengeleme açısından özel yapılandırma gerektirir.

Kurumsal Öneri ve Kişiselleştirme Motorları

E-ticaret, fintech ve medya sektörlerinde gerçek zamanlı öneri sistemleri; düşük gecikme (<10 ms) ve çok yüksek QPS (sorgu/saniye) kombinasyonunu hedefler. Bu senaryolarda model küçüktür ancak throughput gereksinimleri son derece yüksektir.

Referans Inference Cluster Mimarisi

Load Balancer (HAProxy / NGINX / Envoy)
│
├── Inference Node Grubu A — LLM (4 node)
│   └── 2× AMD EPYC 9654 + 8× NVIDIA H100 SXM5 80 GB
│       vLLM + TensorRT-LLM, FP8 inference
│
├── Inference Node Grubu B — Görüntü/Video (4 node)
│   └── 2× Intel Xeon + 4× NVIDIA L40S 48 GB
│       NVIDIA Triton IS, TensorRT
│
├── Küçük Model / CPU Fallback Node'ları (2 node)
│   └── 2× EPYC 9654 (ONNX Runtime, OpenVINO)
│       Düşük öncelikli veya maliyet odaklı istekler
│
├── Model Deposu (NFS / S3 uyumlu)
│   └── Model ağırlıkları, ONNX grafikleri, TensorRT motorları
│
└── İzleme ve Yönetim
    └── Prometheus + Grafana, DCGM Exporter, NVIDIA MIG yönetimi

Ağ: 100 Gbit Ethernet (inference node’lar arası düşük gecikmeli ağ); yük dengeleyiciden node’lara LACP bağlantı.

Performans Optimizasyonu: Katmanlı Yaklaşım

Inference altyapısında gecikme ve throughput optimizasyonu tek bir ayarla sağlanmaz; katmanlar halinde ele alınır.

1. Model Katmanı

TeknikEtkiUygun Model Tipi
TensorRT dönüşümü2–5× hızlanma, düşük bellekCNN, ViT, küçük encoder’lar
INT8 / FP8 kuantizasyon1,5–3× throughput artışıLLM, özellikle H100 FP8
Model budama (pruning)Değişken; %20–50 gecikme iyileşmesiİnce ayarlı LLM, ResNet türevleri
Speculative decodingLLM decode hızında 2–3× artışBüyük otoregressif modeller
Continuous batchingGPU boşta kalma süresini minimuma indirirTüm LLM senaryoları

2. Sistem Katmanı

  • NVIDIA MIG (Multi-Instance GPU): Tek fiziksel GPU’yu birden fazla izole bölüme ayırır; küçük model iş yükleri için GPU kullanım verimliliğini artırır.
  • CUDA Stream paralelleştirme: Birden fazla model çıkarımının aynı anda GPU’da yürütülmesi.
  • Huge pages ve NUMA hizalama: CPU–GPU veri transferinde gecikmeyi azaltır.
  • NVLink / NVSwitch: Çok-GPU LLM senaryolarında tensor paralelliğinin düşük gecikmeli iletişimi.

3. Altyapı Katmanı

  • Önceden ısıtılmış model önbelleği: Model yükleme gecikmesini sıfıra indirmek için tüm modeller GPU belleğinde hazır tutulur.
  • Ağırlık paylaşımı: Aynı modelin birden fazla worker’da bellek kopyası yerine paylaşılan model ağırlığı (Triton IS model ensemble ile).
  • Bağlantı havuzu: İstemci–sunucu arasında TCP bağlantı kurulum maliyetini ortadan kaldıran kalıcı bağlantı yönetimi.

Yüksek Erişilebilirlik: Sıfır Kesinti Hedefi

Inference servislerinde erişilebilirliği tehdit eden başlıca senaryolar: donanım arızası, yazılım kilitleri, model güncelleme ve planlı bakım. Her biri için farklı önlemler gerekir.

Donanım Arızası Koruması

  • N+1 node yapılandırması: Bir node devre dışı kaldığında trafik kalan node’lara aktarılır
  • GPU hata tespiti: NVIDIA DCGM ile sürekli sağlık izlemesi; sorunlu GPU otomatik olarak devre dışı bırakılır
  • Güç yedekliliği: Çift PSU, kesintisiz güç kaynağı (UPS), jeneratör desteği

Model Güncelleme — Sıfır Kesinti Dağıtım

Mevcut model v1.0 → tüm trafik alıyor
  │
  ├── Yeni model v1.1 yükleniyor (ayrı slot)
  ├── Sağlık kontrolü geçildi
  ├── Canary: %5 trafik → v1.1
  ├── Canary: %20 trafik → v1.1
  ├── Tam geçiş: %100 trafik → v1.1
  └── v1.0 boşaltılıyor (draining)

NVIDIA Triton Inference Server, model versiyonlama ve A/B test desteğini doğrudan API üzerinden sunar.

SLA Seviyeleri

HedefParametreTipik Değer
ErişilebilirlikAylık çalışma süresi≥ 99,9% (≤ 43 dakika/ay kesinti)
Gecikme (P50)Median yanıt süresi< 50 ms (küçük modeller)
Gecikme (P99)Kuyruk gecikmesi< 200 ms (LLM tok/san yüklü)
ThroughputSaniyedeki istek sayısıİş yüküne göre tanımlanır
Model güncellemeKesinti süresiSıfır (canary/blue-green)

Güvenlik ve Veri Egemenliği

Kurumsal inference altyapılarında model ağırlıkları, inference girdileri ve çıktıları hassas ticari veri kapsamındadır.

  • KVKK uyumu: Kullanıcı verisi içeren inference isteği ve yanıtlarının Türkiye sınırları dışına çıkmaması yasal yükümlülük doğurabilir. Mevasis altyapısı Türkiye lokasyonludur.
  • Model ağırlığı koruması: Özel ince ayarlı (fine-tuned) modeller; erişim denetimi, ağ izolasyonu ve şifreli depolama ile korunur.
  • Ağ izolasyonu: Inference API’si yalnızca yetkili kaynaklardan erişilebilir; iç network segmentasyonu ile model deposu ve hesaplama katmanı dış ağdan izole edilir.
  • Denetim kaydı (audit log): Hangi modelin ne zaman, kim tarafından çağrıldığının kayıt altına alınması — özellikle fintech ve sağlık uygulamaları için zorunlu.

Örnek Yapılandırma: LLM Servisi (Llama Serisi)

# Triton model config örneği
name: "llama-70b-fp8"
backend: "tensorrtllm"
max_batch_size: 128

instance_group:
  - kind: KIND_GPU
    count: 1
    gpus: [0, 1, 2, 3]   # 4× H100, tensor paralel

dynamic_batching:
  preferred_batch_size: [1, 4, 8, 16, 32]
  max_queue_delay_microseconds: 5000

parameters:
  max_tokens_in_paged_kv_cache: 131072
  kv_cache_free_gpu_mem_fraction: 0.9
  enable_chunked_context: true
  executor_worker_path: "/opt/tritonserver/backends/tensorrtllm"

Bu yapılandırma, 70B parametreli bir modeli 4× H100 üzerinde FP8 ile çalıştırır; continuous batching ile token başına gecikmeyi minimize ederken GPU kullanımını maksimuma çıkarır.

İzleme: Inference Altyapısına Özel Metrikler

Genel sistem izlemenin ötesinde, inference servisleri için kritik metrikler şunlardır:

  • İstek gecikme dağılımı (P50/P95/P99): Ortalama değil, kuyruk metrikleri izlenmeli
  • GPU bellekte model oranı: Model ağırlıklarının ne kadarının GPU’da sıcak tutulduğu
  • KV-cache doluluk oranı: LLM senaryolarında önbellek dolduğunda throughput düşer
  • Token üretim hızı (tokens/saniye): LLM performansının birincil göstergesi
  • Kuyruk derinliği: İşlenmeyi bekleyen istek sayısı; ölçekleme kararı için tetikleyici
  • Batch doluluk oranı: Kapasite verimliliği; düşük değer GPU israfına işaret eder

Mevasis, inference cluster izlemesini Prometheus + Grafana ve NVIDIA DCGM Exporter kombinasyonu ile yapılandırır; kritik metrikler için otomatik uyarı ve esnek ölçekleme tetikleyicileri kurulur.

Mevasis Inference Cluster Hizmetleri

Mevasis, üretim ortamı AI inference altyapısını uçtan uca tasarlar, kurar ve yönetir:

Üretim ortamı inference ihtiyaçlarınız için bizimle iletişime geçin — iş yükü analizi ve boyutlandırma danışmanlığı ücretsiz sunulmaktadır.


Sıkça Sorulan Sorular

vLLM mi yoksa Triton TRT-LLM mi kullanmalıyım? İkisi farklı güçlü yönlere sahiptir. vLLM kurulumu hızlıdır, geniş model desteği sunar ve OpenAI API uyumluluğu ile mevcut uygulamalara kolayca entegre olur. TensorRT-LLM, NVIDIA donanımında maksimum performans hedeflendiğinde —özellikle H100 FP8 ile— açık ara öne geçer ancak derleme süreci gerektirir. Mevasis her iki senaryoyu da deneyimle yönetmektedir.

Kaç GPU ile hangi LLM boyutu çalıştırılabilir? Model boyutu ve hassasiyete bağlıdır. 7B model tek A100 80 GB üzerinde FP16 ile çalışır. 70B model 4× H100 ile tensor paralel; 405B+ modeller için 8+ GPU ve model parallelism zorunludur. Doğru boyutlandırma için iş yükü gereksinimleri (istek/saniye, max bağlam uzunluğu, gecikme hedefi) birlikte değerlendirilmelidir.

Inference clusterım KVKK’ya uygun olması için ne gerekiyor? Kullanıcı verisi içeren (prompt, kişisel bilgi) her inference isteği ve yanıtı Türkiye’de işlenmeli ve depolanmalıdır. Mevasis altyapısı Türkiye lokasyonludur; erişim denetimi, şifreli iletişim (TLS) ve denetim kaydı standart olarak sağlanır. Fintech ve sağlık uygulamaları için ek BDDK/KVKK gereksinimleri değerlendirmeye dahil edilir.

Model güncellemesi sırasında kesinti yaşanır mı? Doğru yapılandırıldığında sıfır kesinti sağlanır. NVIDIA Triton’un model versiyon yönetimi ve canary deployment pipeline’ı ile yeni model versiyonu, mevcut servis kesintisiz aktif haldeyken kademeli olarak devreye alınır.

Küçük modellerimiz için GPU şart mı, CPU yeterli olur mu? BERT tabanlı encoder modelleri, küçük sınıflandırma ve NER modelleri, distilled modeller — bunlar yüksek hacimli ve gecikme toleranslı senaryolarda Intel Xeon veya AMD EPYC ile ONNX Runtime üzerinde verimli biçimde çalışır. GPU’nun maliyet avantajı yalnızca büyük modeller veya çok yüksek QPS senaryolarında belirginleşir. Mevasis, CPU ve GPU iş yükü dengesini maliyet odaklı analiz ederek önerir.

← Tüm Sektörler