Kurumsal AI Projelerinde Doğru Model Seçimi: Boyut, Maliyet, Uyumluluk

Kurumsal AI projelerinde en pahalı hata, en büyük modeli seçmektir. "En güçlü model neyse onu kullanalım" yaklaşımı; gereksiz donanım maliyeti, yüksek gecikme ve çoğu zaman ölçülebilir bir fayda sağlamayan bir kuruluma yol açar.

Doğru soru "hangi model en iyi?" değil, "bu görev için hangi model yeterli?" sorusudur. Bu yazı, kurumsal bir AI projesinde model seçimini somut kriterlere bağlamak için bir karar çerçevesi sunuyor.

Önce Görevi Sınıflandırın

Model seçimi görevden başlar. Kurumsal kullanım senaryolarının büyük bölümü birkaç kategoriye düşer ve her kategorinin farklı bir model profili vardır.

Pratik kural: Projeyi tek bir "AI modeli" olarak değil, farklı görevlerin farklı modellere yönlendirildiği bir model yönlendirme (routing) mimarisi olarak tasarlayın. Sınıflandırmayı 3B modele, karmaşık analizi büyük modele gönderin.

Model Boyutu: Parametre Sayısı Ne Anlatır, Ne Anlatmaz

Parametre sayısı (7B, 70B, 405B) kaba bir kapasite göstergesidir ama tek başına yanıltıcıdır.

• Küçük modeller (1B–8B): Dar, iyi tanımlı görevlerde — özellikle birkaç örnekle yönlendirildiğinde veya fine-tune edildiğinde — büyük modellere yakın sonuç verir. Düşük gecikme, düşük maliyet.
• Orta modeller (8B–32B): Kurumsal RAG ve özetleme için "tatlı nokta". Tek bir modern GPU'ya sığar, kabul edilebilir gecikme sunar.
• Büyük modeller (32B–70B): Çok adımlı akıl yürütme, nüanslı talimat takibi, düşük halüsinasyon gerektiren senaryolar.
• Frontier modeller (kapalı API veya 100B+): En zor akıl yürütme, uzun bağlam üzerinde tutarlılık, ajan iş akışları.

Boyutun anlatmadıkları:

1. Eğitim kalitesi ve tarihi. İyi eğitilmiş yeni bir 8B model, iki yıl önceki bir 70B modeli birçok görevde geçer.
2. Bağlam penceresi. 8B bir model 128K token bağlamı destekleyebilirken, bağlamın ortasındaki bilgiyi kullanmakta ("lost in the middle") zorlanır. Uzun belge işleyecekseniz sadece pencere boyutuna değil, uzun bağlam başarımına bakın.
3. Dil kapsama. Türkçe başarımı model başına ciddi değişir. İngilizce benchmark skorları Türkçe kullanım için güvenilir bir gösterge değildir — kendi verinizle test edin.
4. Quantization etkisi. 70B bir modeli 4-bit quantize edip küçük donanımda çalıştırmak mümkündür; kalite kaybı görevlere göre değişir, ölçülmelidir.

Açık Model mi, Kapalı API mi?

Bu, kurumsal projede en belirleyici karardır ve teknik olduğu kadar hukuki bir karardır.

Karar rehberi:

• Kişisel veri, sağlık verisi, finansal detay, savunma/gizlilik sınıflı içerik işleniyorsa → açık model, on-premise. Tartışmasız.
• Veri hassas değil, hacim düşük-orta, en yüksek akıl yürütme kalitesi gerekiyorsa → kapalı API ile başlamak makul.
• Hacim yüksek ve öngörülebilir, görevler orta zorlukta → açık model genellikle 12–18 ayda kendini amorti eder.
• Hibrit yaklaşım çoğu kurum için doğru cevaptır: hassas veri yerelde küçük/orta modelle, hassas olmayan zor görevler API'ye.

KVKK açısından kritik nokta: Veriyi yurt dışındaki bir API'ye göndermek "yurt dışına veri aktarımı"dır ve ayrı bir hukuki dayanak gerektirir. Sağlayıcının "verinizi eğitimde kullanmıyoruz" taahhüdü aktarımı ortadan kaldırmaz.

Maliyet Modelini Doğru Kurun

İki maliyet modeli tamamen farklı davranır.

Kapalı API: token başına maliyet

Aylık maliyet ≈ (girdi_token × girdi_fiyatı) + (çıktı_token × çıktı_fiyatı)

RAG sistemlerinde girdi tarafı şişer: her soruyla birlikte 3–10 belge parçası da modele gider. Gerçekçi bir hesap:

Örnek: Kurumsal RAG asistanı
- Günlük 500 soru
- Soru başına ~4.000 girdi token (soru + RAG bağlamı + sistem promptu)
- Soru başına ~600 çıktı token
- Ayda 22 iş günü

Aylık girdi:  500 × 4.000 × 22 = 44.000.000 token
Aylık çıktı:  500 × 600  × 22 =  6.600.000 token

Bu hacimde frontier model ile aylık maliyet ciddi tutarlara ulaşır; orta seviye bir API modeli ile önemli ölçüde düşer. Rakamlar sağlayıcı ve tarihe göre değiştiği için projeye özel hesap yapılmalıdır — ama girdi token'ının RAG'de baskın kalem olduğu her senaryoda geçerlidir.

Self-hosted: donanım + işletme maliyeti

Toplam sahip olma maliyeti (TCO) =
    GPU donanımı (amortisman)
  + elektrik + soğutma
  + rack / colocation veya bulut GPU kirası
  + operasyon (izleme, güncelleme, on-call)

Tek seferlik donanım yatırımı yüksektir ama kullanım arttıkça marjinal maliyet sıfıra yakındır. Kırılım noktası tipik olarak: sürekli ve yüksek hacimli kullanım → self-hosted; değişken ve düşük hacim → API.

Sık yapılan hata: Sadece GPU fiyatına bakıp operasyon maliyetini yok saymak. Bir inference kümesini 7/24 çalışır, izlenir ve güncel tutmak gerçek bir işletme yüküdür.

Gecikme (Latency) ve Verim (Throughput)

Kullanıcı deneyimini belirleyen iki metrik:

• TTFT (Time To First Token): İlk token'a kadar geçen süre. Sohbet arayüzünde 1 saniyenin altı hedeflenir.
• TPS (Tokens Per Second): Token üretim hızı. İnsan okuma hızının (~10 token/sn) belirgin üstünde olmalı.

Ajan iş akışlarında dikkat: 6 adımlı bir görev, adım başına 3 saniyeyle 18 saniye eder. Burada model hızı doğrudan kullanılabilirlik sorunudur.

Fine-Tuning mi, RAG mi, Prompt mühendisliği mi?

Model seçmeden önce "modeli nasıl özelleştireceğiz?" sorusunun cevabı, hangi modele ihtiyaç olduğunu değiştirir.

En sık kaçırılan fırsat: İyi tanımlı, tekrarlayan bir görevde küçük bir modeli (3B–8B) birkaç bin örnekle LoRA ile fine-tune etmek, çoğu zaman frontier API'yi hem kalite hem maliyet açısından geçer. Genel zeka gerekmez; görevde ustalık gerekir.

Karar Çerçevesi: Adım Adım

1. Görevleri listeleyin ve sınıflandırın. Her kullanım senaryosunu yukarıdaki görev tablosuna oturtun.
2. Veri hassasiyetini belirleyin. Kişisel/özel nitelikli veri var mı? Varsa on-premise açık model zorunlu — burada durun, API'yi eleyin.
3. En zor görevi baz alın, ama tek modele mahkûm olmayın. En karmaşık senaryo hangi model sınıfını gerektiriyor? Diğer görevler için daha küçük model + routing planlayın.
4. Hacmi tahmin edin. Günlük istek, istek başına token. Bu, API maliyeti ile self-hosted TCO'yu karşılaştırmanızı sağlar.
5. Gecikme bütçesi koyun. Canlı mı, batch mi? Ajan zinciri var mı?
6. Özelleştirme stratejisini seçin. RAG çoğu durumda ilk adım. Fine-tuning küçük modeli yeterli kılabiliyorsa maliyet tablosu değişir.
7. Pilotta iki-üç modeli kendi verinizle kıyaslayın. Benchmark skorları değil, sizin görevinizdeki doğruluk, Türkçe kalitesi ve gecikme belirleyicidir.
8. Çıkış stratejisi düşünün. Kapalı API seçtiyseniz, sağlayıcı modeli emekliye ayırırsa veya fiyat değişirse planınız ne? Soyutlama katmanı (model-agnostik API) kurun.

Tipik Kurumsal Senaryolar ve Önerilen Profil

Özet

Model seçiminde doğru zihniyet, "en güçlüyü al" değil "her görev için yeterli olanı seç ve akıllıca yönlendir"dir:

• Görevden başlayın, modelden değil.
• Veri hassasiyeti açık model / on-premise kararını tek başına belirleyebilir.
• Maliyet API'de token hacmiyle, self-hosted'da işletme yüküyle şekillenir — ikisini aynı tabloda karşılaştırın.
• Küçük + fine-tune, dar görevlerde büyük modeli sıklıkla geçer.
• Hibrit mimari (yerel küçük model + gerektiğinde büyük model/API) çoğu kurum için en dengeli çözümdür.
• Kendi verinizle pilot yapın; İngilizce benchmark'lar Türkçe kurumsal kullanımı yansıtmaz.

Kurumunuzun AI kullanım senaryoları için model seçimi, maliyet modellemesi veya on-premise pilot planlaması konusunda değerlendirme yapmak isterseniz, teknik görüşme talep edebilirsiniz.