Yapay zeka sunucusu: KOBİ için API mi, kendi sunucunda model mi? KVKK, donanım ve aylık TL maliyet

Şirket belgeleriyle, müşteri yazışmalarıyla ya da ERP verisiyle yapay zeka kullanmak isteyen her KOBİ aynı soruyla karşılaşıyor: hazır bir bulut API'sine mi bağlanmalı, yoksa kendi yapay zeka sunucusu üzerinde açık ağırlıklı bir model mi çalıştırmalı? Yazı, bu kararı vermek zorunda olan işletme sahibi ve BT sorumlusu için hazırlandı. Önce verinin nereye gittiğine bakacağız, sonra iş türüne göre donanımı, yazılım yığınını ve aylık TL maliyetin nasıl hesaplanacağını ele alacağız.

Yapay zeka sunucusu nedir, kimin gerçekten ihtiyacı var

Yapay zeka sunucusu, bir dil modelini ya da başka bir yapay zeka modelini sizin kontrolünüzdeki makinede çalıştıran sunucudur. Model dosyası (ağırlıklar) sunucunun diskinde durur, istekler sizin ağınızdan geçer ve yanıt aynı makinede üretilir. Bulut API'de ise metni bir sağlayıcıya gönderirsiniz, model onların altyapısında çalışır, yanıt geri döner.

Her şirketin kendi sunucusuna ihtiyacı yoktur. Şu sorulara verdiğiniz yanıtlar işin yönünü büyük ölçüde belirler:

• Modele gidecek metinde kişisel veri, özel nitelikli kişisel veri ya da ticari sır var mı?
• Sözleşmeleriniz ya da sektör düzenlemeniz verinin belirli bir ülkede kalmasını şart koşuyor mu?
• Kullanım düzenli ve yüksek hacimli mi, yoksa ayda birkaç yüz soru mu?
• Ekipte Linux sunucu, Docker ve güncelleme yönetimini üstlenecek biri var mı?

İlk iki soruya "evet" diyorsanız kendi sunucunuz ciddi bir seçenektir. Son iki soruya "hayır" diyorsanız API daha ucuz ve daha az zahmetli olabilir.

Bulut API mi kendi sunucu mu: veri akışı ve KVKK 9. madde

KVKK açısından belirleyici olan, kişisel verinin Türkiye dışına aktarılıp aktarılmadığıdır. Yurt dışındaki bir API'ye müşteri adı, T.C. kimlik numarası, sağlık bilgisi ya da çalışan değerlendirmesi içeren bir metin gönderdiğinizde, bu bir yurt dışına aktarımdır.

6698 sayılı Kanun'un 9. maddesi 2024'te değişti. Güncel hâliyle aktarım için temelde üç yol var: Kurul'un yeterlilik kararı, uygun güvenceler (ör. Kurul'un yayımladığı standart sözleşme; imzalandıktan sonra 5 iş günü içinde Kurum'a bildirilmesi gerekir) ve sınırlı, arızi durumlar için istisnalar. Yürürlükteki metni ve yönetmeliği KVKK resmi sitesinden kontrol edin ve gerekiyorsa hukuk danışmanınızla birlikte değerlendirin.

Karşılaştırmayı veri akışı üzerinden yapın:

Dikkat edilmesi gereken bir nokta: kendi sunucunuz da yurt dışında olabilir. Sunucu Frankfurt'taysa veri yine Türkiye dışına çıkar; fark, aktarımı bir model sağlayıcısına değil kendi kontrolünüzdeki makineye yapmanızdır. KVKK değerlendirmesini bu gerçeğe göre yapın.

Kişisel veriyi modele göndermeden önce maskelemek (ad, telefon, kimlik numarası yerine yer tutucu koymak) API kullanımında riski azaltır. Ancak serbest metinde maskeleme kusursuz değildir; kontrol listesine güvenmek yerine örnek belgeler üzerinde test edin.

İş türüne göre ihtiyaç: RAG, özetleme, ajan ve ince ayar

Donanımı model adından değil işten başlayarak seçin. KOBİ'lerde en sık görülen dört iş türü farklı kaynak ister.

RAG ve kurum içi arama

RAG (retrieval augmented generation), belgelerinizi parçalara bölüp vektör veritabanına koyar; soru geldiğinde ilgili parçaları bulup modele bağlam olarak verir. Kalitenin büyük kısmı arama adımından gelir. Embedding modeli küçüktür ve CPU'da makul hızda çalışabilir. Yanıtı üreten dil modeli için 7B ile 14B arası bir model çoğu iç bilgi tabanı sorusunda yeterli olabilir; kendi belgelerinizle deneyerek karar verin.

Belge özetleme ve sınıflandırma

Gelen faturaları, sözleşmeleri ya da destek taleplerini özetlemek genellikle toplu (batch) iştir. Yanıtın anında gelmesi gerekmez, gece çalışabilir. Bu tür işlerde CPU sunucuda küçük bir model bile kabul edilebilir süre verebilir. Önemli olan, bağlam penceresinin belgenizin uzunluğuna yetmesidir.

AI ajanı

Ajanlar araç çağırır, birden çok adımda düşünür ve her adımda modele yeniden gider. Bu yüzden tek bir kullanıcı işi bile çok sayıda istek üretir. Araç çağırmada (function calling) güvenilir sonuç için daha büyük modeller ve GPU gerekir. Ajan, ERP'ye ya da e-postaya yazma yetkisi alıyorsa yetkiyi en dar kapsamda tutun.

İnce ayar (fine-tuning)

Çoğu KOBİ için ince ayar ilk adım değildir; RAG ile çözülemeyen bir üslup ya da biçim sorunu yoksa gerekmez. LoRA ile ince ayar bile çıkarımdan daha fazla VRAM ister ve geçici bir iştir. Bu yüzden ince ayar için kalıcı sunucu yerine birkaç günlük GPU kiralamak çoğunlukla daha mantıklıdır.

CPU sunucu, tek GPU ve çoklu GPU: başlangıç yapılandırmaları

Bellek ihtiyacı için kaba kural: model ağırlığı yaklaşık olarak parametre sayısı çarpı parametre başına bayt kadardır. 16 bit (FP16/BF16) için parametre başına 2 bayt, 8 bit için 1 bayt, 4 bit kuantizasyon için yaklaşık 0,5 bayt. Buna eşzamanlı kullanıcı sayısı ve bağlam uzunluğuyla büyüyen KV cache eklenir. Hesabın ayrıntısını LLM VRAM hesaplama rehberinde adım adım bulabilirsiniz.

Bu kurala göre üç basamak oluşur:

CPU sunucu. 4 bit kuantize edilmiş 7B ile 8B bir model birkaç GB bellek ister ve güçlü bir CPU'da çalışır. Hız GPU'nun çok altındadır; tek kullanıcılı denemeler, gece çalışan özetleme işleri ve embedding üretimi için uygundur. Eşzamanlı kullanıcı arttıkça yanıt süresi hızla uzar. Deneme için İstanbul ya da Strasbourg lokasyonlu bir bulut sunucu yeterli başlangıç noktasıdır; RAM'i modelin ve işletim sisteminin toplamından rahatça fazla seçin.

Tek GPU. 14B ile 32B arası modeller, 4 ya da 8 bit kuantizasyonla tek bir veri merkezi GPU'suna sığar ve birkaç eşzamanlı kullanıcıya akıcı yanıt verir. Çoğu KOBİ'nin RAG ve asistan işi bu basamakta çözülür.

Çoklu GPU ya da büyük bellekli tek GPU. 70B ve üstü modeller, uzun bağlam ve çok sayıda eşzamanlı kullanıcı bu basamağı gerektirir. Örneğin 70B bir model 16 bitte yalnız ağırlıklar için yaklaşık 140 GB ister; 141 GB HBM3e belleğe sahip NVIDIA H200 bile KV cache için yer bırakmaz, bu durumda kuantizasyon ya da ikinci GPU gerekir.

Karar ölçütü: önce kendi verinizle küçük modeli deneyin. Yanıt kalitesi yetmiyorsa bir basamak büyütün. Kalite yeterli ama hız yetmiyorsa model büyütmek yerine GPU'ya geçin.

Lokasyon konusunda açık olalım: sunucu.com.tr GPU sunucu kataloğu Frankfurt'ta (AB) NVIDIA H200 ile sunulur; başka kart modelleri ve İstanbul lokasyonu için sayfadaki formla talep alınır. Verinin mutlaka Türkiye'de kalması gerekiyorsa bunu talepte belirtin ya da hassas işleri İstanbul'daki CPU sunucuda yürütün.

Yazılım yığını: Ollama, vLLM, vektör veritabanı ve kimlik doğrulama

Tipik bir kendi sunucu yığını dört katmandan oluşur:

1. Çıkarım motoru. Ollama kurulumu kolaydır, tek kullanıcılı ve küçük ekip senaryosu için uygundur, CPU'da da çalışır. vLLM ise GPU üzerinde eşzamanlı istekleri verimli işler, OpenAI uyumlu API sunar ve çok kullanıcılı üretim ortamı için daha uygundur.
2. Vektör veritabanı. PostgreSQL için pgvector eklentisi, zaten PostgreSQL kullanıyorsanız ek servis gerektirmez. Qdrant gibi ayrı bir vektör veritabanı da seçilebilir.
3. Arayüz ya da otomasyon. Kullanıcıların sohbet ettiği bir web arayüzü ya da n8n gibi bir iş akışı aracı.
4. Kimlik doğrulama ve ters vekil. HTTPS, kullanıcı girişi ve erişim kaydı.

En kritik ayar, çıkarım motorunun internete açık olmamasıdır. Ollama varsayılan olarak yalnız 127.0.0.1:11434 adresini dinler; ancak sık yapılan bir hata OLLAMA_HOST=0.0.0.0 ayarlayıp portu dünyaya açmaktır. Ollama'nın kendi API'sinde kimlik doğrulama yoktur.

Aşağıdaki kontrol betiği Ubuntu 24.04 ve Debian 12 için hazırlandı. Yalnız okuma yapar, hiçbir ayarı değiştirmez; bu yüzden geri alınacak bir adımı yoktur. Ollama ve vLLM'in varsayılan portlarını (11434 ve 8000) hangi adreste dinlediğini gösterir.

#!/usr/bin/env bash
# Yapay zeka servislerinin hangi adreste dinlediğini kontrol eder.
# Yalnız okuma yapar, ayar değiştirmez. Ubuntu 24.04 ve Debian 12 için hazırlandı.
set -euo pipefail

# Kontrol edilecek portlar: 11434 (Ollama), 8000 (vLLM varsayılanı)
PORTLAR="11434 8000"

for PORT in $PORTLAR; do
  # ss çıktısında ilgili portu dinleyen satırları bul
  SATIR=$(ss -ltn "( sport = :$PORT )" | tail -n +2 || true)
  if [ -z "$SATIR" ]; then
    echo "Port $PORT: dinleyen servis yok"
    continue
  fi
  # Yerel adres sütununu al
  ADRES=$(echo "$SATIR" | awk '{print $4}')
  case "$ADRES" in
    127.0.0.1:*|"[::1]":*)
      echo "Port $PORT: yalnız yerel ($ADRES), uygun" ;;
    *)
      echo "UYARI: Port $PORT dış arayüzde dinliyor ($ADRES). Ters vekil ve kimlik doğrulama arkasına alın." ;;
  esac
done

Beklenen sağlıklı çıktı şuna benzer: Port 11434: yalnız yerel (127.0.0.1:11434), uygun. "UYARI" satırı görüyorsanız servisi yerel adrese bağlayın ve dışarıya yalnız HTTPS ve kimlik doğrulama yapan ters vekil üzerinden açın. vLLM için vllm serve komutunun --host 127.0.0.1 ve --api-key seçeneklerini vLLM belgelerinden kontrol edin. Ofis dışından erişim gerekiyorsa portu internete açmak yerine VPN kullanın.

Güvenlik duvarı kuralı ekleyecekseniz önce SSH erişimine izin verin; aksi hâlde kuralı etkinleştirdiğiniz anda sunucuya erişiminizi kaybedersiniz. Bu tür değişiklikleri yaparken sağlayıcı panelindeki konsol erişimini açık tutun.

Aylık TL maliyet ve token hacmine göre başabaş

Uydurma bir rakam vermek yerine hesabın nasıl yapılacağını gösterelim; birim fiyatları kendi teklifinizden alın.

API tarafı: aylık maliyet yaklaşık olarak (aylık giriş token sayısı x giriş birim fiyatı) + (aylık çıkış token sayısı x çıkış birim fiyatı) olur. API fiyatları çoğunlukla dolar cinsindendir; bu yüzden TL karşılığına kur ve banka masrafını ekleyin. RAG'de her soruya bağlam eklendiği için giriş token'ı, kullanıcının yazdığından çok daha fazladır.

Kendi sunucu tarafı: aylık sunucu bedeli + yedek ve izleme + bakım için harcanan personel saati. Bu kalem sabittir ve kullanım arttıkça değişmez, ta ki sunucu kapasitesi dolana kadar.

Token hacminizi tahmin etmek için şunu yapın: bir hafta boyunca gerçek soruları ve kullanılan bağlamı kaydedin, ortalama soru başına token sayısını bulun ve aylık soru sayısıyla çarpın. Aşağıdaki küçük betik bu hesabı yapar. Ubuntu 24.04 ve Debian 12 için hazırlandı, yalnız awk kullanır ve sistemde değişiklik yapmaz. Büyük harfli değerleri kendi rakamlarınızla değiştirin.

#!/usr/bin/env bash
# API ile kendi sunucu arasında aylık başabaş karşılaştırması.
# Sistemde değişiklik yapmaz. Değerleri kendi teklif ve ölçümlerinizle doldurun.
set -euo pipefail

AYLIK_SORU=ORNEK_AYLIK_SORU            # ör. ölçtüğünüz aylık soru sayısı
GIRIS_TOKEN_SORU=ORNEK_GIRIS_TOKEN     # soru başına ortalama giriş token (bağlam dahil)
CIKIS_TOKEN_SORU=ORNEK_CIKIS_TOKEN     # soru başına ortalama çıkış token
GIRIS_FIYAT_1M_TL=ORNEK_GIRIS_FIYAT    # 1 milyon giriş token'ın TL karşılığı
CIKIS_FIYAT_1M_TL=ORNEK_CIKIS_FIYAT    # 1 milyon çıkış token'ın TL karşılığı
SUNUCU_AYLIK_TL=ORNEK_SUNUCU_BEDELI    # sunucu + yedek + izleme, KDV dahil
BAKIM_AYLIK_TL=ORNEK_BAKIM_BEDELI      # bakım için ayrılan personel maliyeti

awk -v s="$AYLIK_SORU" -v gi="$GIRIS_TOKEN_SORU" -v ci="$CIKIS_TOKEN_SORU" \
    -v gf="$GIRIS_FIYAT_1M_TL" -v cf="$CIKIS_FIYAT_1M_TL" \
    -v sb="$SUNUCU_AYLIK_TL" -v bb="$BAKIM_AYLIK_TL" 'BEGIN {
  api = (s*gi/1000000)*gf + (s*ci/1000000)*cf
  kendi = sb + bb
  soru_maliyet = api / s
  printf "API aylık tahmini: %.0f TL\n", api
  printf "Kendi sunucu aylık: %.0f TL\n", kendi
  printf "Başabaş soru sayısı: %.0f soru/ay\n", kendi / soru_maliyet
}'

Çıktıdaki "başabaş soru sayısı", kendi sunucunun API'den ucuza gelmeye başladığı aylık hacimdir. Ancak tek ölçüt maliyet olmamalı. KVKK riski yüzünden API'ye gönderemeyeceğiniz bir veri varsa, hacim düşük olsa bile kendi sunucu tek seçenek olabilir. Tersine, kapalı bir modelin kalitesine gerçekten ihtiyaç duyuyorsanız ucuz ama yetersiz bir model sizi daha pahalıya getirir.

Hibrit yapı: hassas veri yerelde, genel işler API'de

Çoğu KOBİ için en dengeli çözüm hibrittir. Mantık basittir: isteği veri sınıfına göre yönlendirin.

1. Veriyi sınıflandırın: kişisel veri ve ticari sır içerenler "yerel", pazarlama metni ve genel kod yardımı gibi işler "API".
2. Uygulamada tek bir giriş noktası kurun; istek bu noktada sınıfına göre yerel modele ya da API'ye gider. vLLM ve Ollama'nın OpenAI uyumlu uç noktaları sayesinde uygulama kodu aynı kalır, yalnız adres değişir.
3. Yönlendirme kararını kayda geçirin; denetimde hangi verinin nereye gittiğini gösterebilmelisiniz.
4. Belge deposunu ve vektör veritabanını her durumda kendi tarafınızda tutun; API'ye yalnız sorunun gerektirdiği minimum metni gönderin.

Bu yapıda yerel model küçük kalabilir, çünkü en zor genel işler API'ye gider. Böylece hem donanım maliyeti hem de KVKK riski sınırlanır.

Sık yapılan hatalar

• API'yi internete açmak. Kimlik doğrulamasız bir Ollama ya da vLLM portu, başkalarının sunucunuzu ücretsiz kullanmasına ve modele erişmesine yol açar. Yukarıdaki betikle düzenli kontrol edin.
• Yedeksiz model ve veri. Model ağırlıkları yeniden indirilebilir ama ince ayar dosyaları, vektör veritabanı, sistem istemleri ve yapılandırma indirilemez. Bunları sunucudan ayrı bir depoya yedekleyin ve geri yüklemeyi deneyin.
• Yetkisiz erişim. RAG, belgelere erişim yetkisini bilmez. Muhasebe klasörünü dizine eklediyseniz her kullanıcı muhasebe verisi hakkında soru sorabilir. Dizini yetki gruplarına göre ayırın ya da arama adımında kullanıcı yetkisine göre süzün.
• Model lisansını okumamak. Açık ağırlıklı her model ticari kullanıma açık değildir. Lisansı model sayfasından kontrol edin.
• Ölçmeden büyük sunucu almak. Önce küçük modelle kendi verinizi deneyin, gerçek soru hacmini ölçün, sonra boyutlandırın.

Sık sorulan sorular

Yapay zeka sunucusu için mutlaka GPU gerekir mi?

Hayır. Küçük kuantize modeller, embedding üretimi ve gece çalışan özetleme işleri CPU'da çalışabilir. Birden çok kullanıcının aynı anda akıcı yanıt beklediği asistanlarda, büyük modellerde ve ajanlarda GPU gerekir.

Kendi sunucumda model çalıştırırsam KVKK sorununu tamamen çözmüş olur muyum?

Hayır. Model sağlayıcısına aktarımı kaldırırsınız ama sunucu Türkiye dışındaysa aktarım yine vardır. Ayrıca aydınlatma, erişim yetkisi, kayıt tutma ve saklama süresi gibi yükümlülükler kendi sunucunuzda da devam eder.

Açık ağırlıklı modeller kapalı API modelleri kadar iyi mi?

İşe göre değişir. Belge özetleme, sınıflandırma ve iç bilgi tabanında açık modeller çoğu zaman yeterli olabilir; karmaşık akıl yürütme ve uzun ajan zincirlerinde en güçlü kapalı modeller önde olabilir. Kendi örnek sorularınızla kör test yapın.

İnce ayar için ayrı sunucu almalı mıyım?

Genellikle hayır. İnce ayar geçici bir iştir; birkaç günlük GPU kiralayıp sonucu çıkarım sunucusuna taşımak sabit bir eğitim sunucusundan çoğunlukla daha ekonomiktir.

Başlamak için en düşük riskli yol hangisi?

Kişisel veri içermeyen bir iş seçin, küçük bir modeli CPU'lu bir sunucuda deneyin, soru hacmini ve kaliteyi bir ay ölçün. Sonra başabaş hesabıyla GPU'ya, API'ye ya da hibrit yapıya karar verin.

Bu işi hazır yapmak isterseniz

Model seçimi, Ollama ya da vLLM kurulumu, vektör veritabanı ve erişim kontrolünü kendiniz kurmak yerine hazır bir yapı tercih ederseniz yapay zeka sunucusu sayfasından ihtiyacınızı iletebilirsiniz; lokasyon ve donanım seçeneklerini iş yükünüze göre birlikte netleştiririz.

Sonuç

API ile kendi sunucu arasındaki karar üç soruya dayanır: veri nereye gidebilir, aylık hacim ne kadar ve bakımı kim yapacak. Hassas veri için yerel model, genel işler için API kullanan hibrit yapı çoğu KOBİ'de iyi bir başlangıçtır. Donanımı model adına göre değil ölçtüğünüz iş yüküne göre seçin, çıkarım portunu internete kapalı tutun ve yedeği unutmayın.