On-Prem LLM Platformu: Veri Dışarı Çıkmamalıydı

Bağlam

Kurumsal müşteriler için LLM tabanlı çözümler geliştirirken belirleyici bir kısıtla karşılaştık: müşteri verisi şirket altyapısının dışına çıkamaz. Bu, OpenAI veya Anthropic gibi bulut API'larını doğrudan kullanmayı imkansız kılıyordu. Çözüm, kendi sunucularında çalışan, standart bir API arayüzü sunan ve farklı model boyutlarını destekleyen bir platform gerektiriyordu.

Problem

Sorun yalnızca "bir model kur ve çalıştır" değildi. İki çelişen gereksinim vardı: (1) farklı görevler farklı model boyutları gerektiriyor, 2B'den 27B'ye kadar aynı platformda yönetilmeli; (2) büyük modeller tek GPU'ya sığmıyor, tensor parallelism gerekiyor. Buna ek olarak müşteri tarafında teknik bilgi düzeyi düşük; sistemin standart API ile konuşması, mevcut araçlarla entegrasyonu kolaylaştıracaktı.

Neden Önemliydi?

Platformun ilk token gecikmesi kullanıcı deneyimini doğrudan etkiliyor. 5 saniyenin üzerinde gecikme, etkileşimli kullanım senaryolarında kabul edilemez. Öte yandan performans optimizasyonu ile veri güvenliği gereksinimleri birbirine kimi zaman ters düşüyordu: en hızlı seçenek her zaman en güvenli seçenek olmayabilir.

Ben Neyi Sorguladım?

İlk sorum şuydu: quantization olmadan 27B modeli 4 GPU'ya sığdırmak mümkün mü, sığdırsa bile gecikme kabul edilebilir mi? İkinci sorum: AWQ mu, GPTQ mu — hangi quantization yöntemi bu model ailesinde daha iyi kalite/hız dengesi sunuyor? Üçüncü sorum: gerçek darboğaz GPU mı, yoksa başka bir şey mi?

Teşhis

İlk yük testleri iki şeyi netleştirdi: GPU kullanımı beklentilerin altındayken gecikme hâlâ yüksekti — darboğaz GPU değil, ağ bant genişliğiydi. Müşteri altyapısındaki ağ hızı, token akışını sınırlıyordu. 27B modeli quantization olmadan 4 GPU'da çalıştırmak mümkündü ama bellek baskısı diğer süreçleri olumsuz etkiliyordu. AWQ ile GPTQ'yu karşılaştırdığımda AWQ hem daha hızlı çıkarım hem de daha az kalite kaybı sundu.

Değerlendirilen Seçenekler

• Ollama + Open WebUI: Kurulumu kolay, geliştirici odaklı ama production yük altında throughput yetersiz; OpenAI-uyumlu API desteği sınırlı.
• TGI (Text Generation Inference): Güçlü ama konfigürasyonu karmaşık; tensor parallelism kurulumu belgelenmemiş köşeler içeriyor.
• vLLM: OpenAI-uyumlu endpoint, PagedAttention ile yüksek eşzamanlılık, tensor parallelism desteği. En iyi denge.

Verdiğim Karar

vLLM'i seçtim. Temel gerekçe: PagedAttention mekanizması eşzamanlı isteklerde bellek verimliliğini ciddi ölçüde artırıyor ve OpenAI-uyumlu endpoint, müşteri entegrasyonunu minimum geliştirme maliyetiyle sağlıyor. 27B model için AWQ quantization uygulandı; kalite kaybı benchmarklarda marjinal düzeyde kaldı, bellek kullanımı yarıya indi.

Uygulama

• vLLM ile OpenAI-uyumlu API endpoint kuruldu; tensor parallelism 4 GPU'ya yayıldı
• 27B model AWQ ile quantize edildi (4-bit); bellek ayak izi ~%50 azaldı
• Prometheus + Grafana ile gecikme, throughput ve GPU kullanım metrikleri izleme altyapısı kuruldu
• API key rotasyonu ve rate limiting eklendi
• Model versiyonları ve konfigürasyonlar Git'te takip edildi

Ölçüm Yöntemi

İlk token gecikmesi (TTFT) ve tokens/saniye, her model için ayrı ayrı ölçüldü. Yük testleri eşzamanlı 10, 25, 50 istek senaryolarında çalıştırıldı. AWQ ve tam precision karşılaştırması, aynı benchmark seti üzerinde yapıldı.

Sonuç

İlk token gecikmesi 2 saniyenin altında tutuldu. Tüm veri müşteri altyapısında kaldı. Platform, 2B ile 27B arası modelleri standart OpenAI-uyumlu API üzerinden sunabiliyor.

Sınırlamalar

• Ağ bant genişliği darboğazı GPU'dan önce geliyor; müşteri altyapısının ağ kapasitesi platform performansını doğrudan sınırlıyor.
• AWQ quantization, bazı görev türlerinde (uzun bağlamlı muhakeme) tam precision'a göre ölçülebilir kalite kaybı yaratabilir.
• Model güncelleme süreci hâlâ manuel; otomatik pipeline kurulmadı.

Öğrendiklerim

GPU bant genişliği her zaman asıl darboğaz değil. Yük testleri yapmadan "GPU yeterince güçlü, gecikme düşük olmalı" demek mümkün değil. Bu projede ağ bant genişliğini darboğaz olarak teşhis etmek, GPU upgrade yerine ağ altyapısına odaklanmayı sağladı ve hem maliyet hem zaman açısından doğru kararı vermeye yol açtı. Ayrıca quantization kararını salt bellek tasarrufu için değil, kalite/maliyet dengesi üzerinde düşünerek vermek gerekiyor.