Üretimde LLM entegrasyonu neden “demo”dan farklıdır?

Bir LLM’i (Large Language Model) ürüne entegre etmek, ilk prototipte genellikle “API çağır, yanıt al” kadar basit görünür. Üretimde ise bu bileşen; maliyet, gecikme (latency), güvenilirlik, veri güvenliği ve denetlenebilirlik açısından klasik mikroservislerden daha karmaşık hale gelir.

Kapsam ve varsayımlar

  • Bu kontrol listesi; hosted LLM API’leri veya self-host inference kullanan ürün/iç araç entegrasyonlarını hedefler (chat, özetleme, sınıflandırma, RAG destekli arama vb.).
  • Model eğitimi/fine-tuning detayları, kurumsal sözleşme maddeleri ve sektör-spesifik uyumluluk (sağlık/finans gibi) kapsam dışıdır.
  • Bu içerik hukuki/uyumluluk danışmanlığı değildir; regülasyonlar ülke/eyalet/sektöre göre değişebilir.

Bu yazıda üç soruya pratik yanıt arayacağız:

  • Maliyet: Token bazlı fiyatlandırma ve altyapı seçimiyle birim ekonomiyi nasıl kontrol ederim?
  • Performans: Kabul edilebilir gecikme için hangi optimizasyonlar olgun, hangileri deneysel?
  • Güvenlik ve governance: PII riski, anahtar yönetimi, loglama ve sürümleme için hangi kontroller gerekli?

1) Maliyet modelini doğru kurun: “token ekonomisi” + operasyon maliyeti

Çoğu hosted LLM yaklaşımında maliyetin ana sürücüsü, input/output token miktarıdır. Bu nedenle maliyet yönetimi, “kaç istek atıyoruz?” sorusundan önce “her istekte kaç token harcıyoruz?” sorusuyla başlar. OpenAI’nin fiyat sayfası model bazında token ücretlerini listeler; fiyatlar değişebileceği için yayın öncesi canlı kontrol iyi bir pratiktir (https://openai.com/api/pricing/). Fiyat sayfası son kontrol: 2026-03-10.

Maliyeti ölçmeden optimize etmeyin: temel metrikler

İlk aşamada aşağıdaki metrikleri ürün analitiğine eklemek, sonraki optimizasyonların ROI’sini görünür kılar:

  • İstek başına input token (p50/p95)
  • İstek başına output token (p50/p95)
  • Başarılı yanıt oranı ve yeniden deneme oranı (retries maliyeti büyütür)
  • Cache hit rate (varsa prompt/response caching)
  • Model başına maliyet (model A/B; farklı modeller farklı token fiyatlarına sahip olabilir)

Maliyet düşürmenin pratik yolları (token odaklı)

  • Prompt’u kısaltın: Sistem mesajlarını tekrar etmek yerine uygulama tarafında şablonlayın; gereksiz “kural metni”ni kısaltın.
  • Yanıtı sınırlayın: Çıktı token üst sınırı ve format zorlaması (ör. maddeler halinde kısa) maliyeti ve gecikmeyi birlikte azaltır.
  • RAG ile hedefli bağlam: Uzun dokümanı olduğu gibi context’e koymak yerine, arama ile sadece ilgili parçaları ekleyin. Google Cloud’un üretim rehberi, generative uygulamalarda veri yönetimi/RAG ve operasyonel kontrollerin birlikte ele alınmasını önerir (https://docs.cloud.google.com/architecture/deploy-operate-generative-ai-applications).
  • Önbellekleme (uygunsa): Sık tekrar eden prompt parçaları (talimatlar, politika metinleri, ürün açıklamaları) uygulama katmanında yeniden kullanılarak toplam token tüketimi azaltılabilir.
  • Batch işleme: Gerçek zamanlı olmayan işlerde (özetleme kuyruğu gibi) batch, altyapı verimliliğini artırabilir.

API mi self-host mu? Karar vermeyi kolaylaştıran tablo

Hızlı ürünleşme için API caziptir; yüksek hacim ve çok düşük gecikme hedeflerinde self-host seçenekleri TCO açısından avantajlı hale gelebilir. Ancak bu karar, güvenlik/uyumluluk ve operasyon ek yüküyle birlikte değerlendirilmelidir.

Kriter Hosted API Self-host (GPU/özel donanım)
İlk kurulum süresi Genelde hızlı Daha yavaş (serving, ölçekleme, gözlemlenebilirlik)
Birim maliyet kontrolü Token fiyatına bağlı Donanım kullanımına bağlı; optimizasyonla düşebilir
Gecikme hedefleri İnternet ve sağlayıcı gecikmesine bağlı İyi tasarımla daha düşük ve öngörülebilir olabilir
Güvenlik ve veri yerleşimi Sağlayıcı kontrollerine bağlı; sözleşme/konfig önemli Daha fazla kontrol; daha fazla sorumluluk
Operasyon yükü Düşük-orta Orta-yüksek (MLOps/serving)

2) Performans: gecikme bütçesiyle başlayın, sonra teknik seçin

“Model yavaş” demek çoğu zaman belirsizdir. Üretim için önce uçtan uca gecikme bütçesi çıkarın:

  • İstemci → uygulama sunucusu
  • Uygulama sunucusu → LLM (ağ + kuyruk)
  • LLM inference (ilk token ve toplam üretim süresi)
  • Post-processing (format, guardrail kontrolü, kaynak gösterimi)

Bu bütçe olmadan yapılan optimizasyon, yanlış katmanı hedefleyebilir.

Olgun optimizasyonlar: çoğu ekip için ilk sırada

  • Streaming: Kullanıcı algısını iyileştirir (ilk token süresini düşürmez ama bekleme hissini azaltır).
  • Batching: Uygunsa throughput’u artırır; ancak eş zamanlama gecikmesi ekleyebilir.
  • KV-cache kullanımı: Tekrarlı token üretiminde verimi artırır; uzun context’te bellek baskısı yaratabilir.
  • Context’i küçültme: RAG ile hedefli bağlam, hem maliyet hem gecikmeye doğrudan etki eder.

Quantization (AWQ/GPTQ): maliyet ve gecikmede güçlü kaldıraç

Post-training quantization, model ağırlıklarını daha düşük hassasiyette temsil ederek bellek ve hız kazancı hedefler. AWS’nin SageMaker odaklı teknik yazısı AWQ/GPTQ gibi yöntemlerin LLM inference’ını hızlandırmaya yönelik uygulanabilir adımlarını ve ölçüm yaklaşımını anlatır (https://aws.amazon.com/blogs/machine-learning/accelerating-llm-inference-with-post-training-weight-and-activation-using-awq-and-gptq-on-amazon-sagemaker-ai/).

Performans kazancı notu: Bazı kaynaklarda ve pratik ölçümlerde quantization için yaklaşık 2×–4× verim (throughput/latency veya bellek başına kapasite) iyileşmesi aralıkları raporlanabilir; bu aralıklar belirli model-donanım-kurulum deneylerine aittir ve tipik ya da garantili değildir. Yanına mutlaka kendi iş yükünüzde benchmark (p50/p95, OOM, kalite regresyonu) ekleyin.

Quantization’ı üretime alırken kontrol listesi

  • Görev bazlı kalite metrikleri (örn. sınıflandırma doğruluğu, retrieval answer rate, insan değerlendirmesi)
  • p95 gecikme ve hata oranı (OOM dahil)
  • Rollback planı (aynı endpoint altında model versiyonlama)
  • Regresyon test seti ve periyodik yeniden ölçüm

Speculative decoding ve batch varyantları: hız var, bedeli de var

Speculative decoding, küçük bir “draft” modelle aday token’ları üretip, daha büyük modelle doğrulama yaklaşımıyla hız kazanmayı hedefler. Batch senaryolarını ele alan çalışma özetleri, hız/kalite dengesinde senkronizasyon ve doğrulama maliyetlerinin kritik olduğunu vurgular (https://scixplorer.org/abs/2025arXiv251022876H/abstract).

Performans kazancı notu: Bazı deney raporlarında speculative decoding ailesi için yaklaşık 1.8×–3× hızlanma aralıkları görülebilir; bu değerler senaryo ve kurulum bağımlıdır, genellenemez. Üretime almadan önce aynı veri seti ve aynı SLO’larla kendi ortamınızda ölçüm yapın.

  • Kalite eşdeğerliği her görevde korunmayabilir.
  • Ek model çalıştırma maliyeti (draft + verify) toplam TCO’yu değiştirebilir.
  • Batch senkronizasyonu p95 gecikmeyi yükseltebilir.

Uzun context ve streaming optimizasyonları: “deneysel” etiketiyle ilerleyin

Uzun bağlam ve streaming için kernel/algoritma optimizasyonları üzerine güncel araştırmalar bulunuyor (ör. StreamingLLM; https://proceedings.iclr.cc/paper_files/paper/2025/file/043f0503c4f652c737add3690aa5d12c-Paper-Conference.pdf). Bu tür yöntemler, özellikle uzun context maliyetini azaltma veya token üretim verimini artırma açısından umut verici olabilir; ancak stabilite ve taşınabilirlik her altyapıda aynı olmayabilir. Üretimde kademeli rollout ve geri dönüş mekanizması şarttır.

3) Güvenlik: “model” kadar entegrasyon yüzeyi de risk taşır

Üretimde risk, sadece modelin yanlış yanıt üretmesi değildir. LLM entegrasyonu; anahtar yönetimi, loglama, veri işleme ve kötüye kullanım (ör. aşırı istek, beklenmedik token tüketimi) gibi operasyonel riskler taşır. Google Cloud’un rehberi, generative uygulamalarda güvenlik ve operasyon adımlarının (izleme, içerik kontrolleri, veri yönetimi) birlikte tasarlanmasını önerir (https://docs.cloud.google.com/architecture/deploy-operate-generative-ai-applications).

Tehdit modeli: en sık karşılaşılan sınıflar

  • API anahtarı sızıntısı: Ele geçirilen anahtar, doğrudan faturalama riskine dönüşebilir. Bu nedenle maliyet alarmları ve rate limit sadece “maliyet optimizasyonu” değil, güvenlik kontrolüdür.
  • Prompt injection: Dış içerik (web sayfası, e-posta, doküman) modele “talimat” gibi görünebilir; sistem talimatlarını gölgelemeye çalışabilir.
  • PII / hassas veri sızıntısı: Loglara veya üçüncü taraflara istemeden taşınabilir.
  • RAG kaynak zehirleme: Bilgi tabanına kötü niyetli içerik girerse yanıtlar etkilenebilir.

Minimum güvenlik kontrolleri (üretime çıkış için)

  • Secrets yönetimi: Anahtarları kodda tutmayın; kısa ömürlü token/rotasyon ve erişim ilkesi uygulayın.
  • RBAC ve ayrıştırma: Prod anahtarına erişimi sınırlayın; ortam bazlı ayrıştırma (dev/stage/prod).
  • Network kontrolleri: Egress kısıtları, allowlist, özel bağlantı seçenekleri (mümkünse).
  • Girdi/çıktı filtreleri: PII maskeleme (uygun ise), zararlı içerik sınıfları için politika kontrolleri.
  • Rate limit + bütçe alarmları: Anomali durumunda otomatik fren (ör. geçici kapatma, daha küçük modele düşme).
  • Loglama ama ölçülü: Debug için gerekli minimum alanları tutun; hassas veri saklama politikanızı yazılı hale getirin.

Prompt injection’a karşı pratik savunma

  • Talimat hiyerarşisi: Sistem talimatlarını sabitleyin; kullanıcı içeriğini “veri” olarak etiketleyin.
  • RAG güvenlik sınırları: Retrieval sonuçlarını “komut” değil “kaynak” olarak ele alın; gerekirse kaynak metni kısaltın ve normalize edin.
  • İzinli araçlar: Tool calling kullanıyorsanız araçlara erişimi en az ayrıcalıkla sınırlandırın; parametre doğrulaması yapın.

4) Governance ve denetlenebilirlik: NIST yaklaşımıyla üretim standardı oluşturun

NIST’in Generative AI Profile dokümanı, risk yönetimi ve governance için; loglama, sürüm kontrolü, insan gözetimi, risk profilleme gibi alanlarda öneriler sunar. Bu tür çerçeveler yasal zorunlulukların yerine geçmez; ancak iyi bir referans noktasıdır (https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf).

Üretimde “governance artefaktları” neler olmalı?

  • Model envanteri: Hangi model(ler), hangi endpoint’te, hangi sürümle çalışıyor?
  • Prompt/şablon sürümleme: Prompt değişikliği, çoğu zaman model değişikliği kadar etki eder.
  • RAG provenance: Yanıtın hangi kaynak(lar)a dayandığını (ID/URL/versiyon) kaydedin.
  • Değerlendirme paketi: Golden set + periyodik ölçüm; regresyonları yakalamak için.
  • Olay yönetimi: Yanlış/zararlı çıktılar için triage ve düzeltme döngüsü.

Loglama stratejisi: “her şeyi tut” yerine amaç odaklı

LLM logları hızla hassas veriye dönüşebilir. Bu nedenle iki seviyeli yaklaşım iş görür:

  • Varsayılan: Token sayıları, gecikme, model adı/sürümü, hata kodu, cache durumu gibi metrikler.
  • İnceleme gerektiren olaylarda: Sınırlı süreli ve erişimi kısıtlı örnekleme ile prompt/yanıt metni (gerekirse maskeleme).

Veri saklama süresi, erişim rolleri ve silme politikaları mutlaka yazılı olmalıdır. Sektörünüz (sağlık, finans vb.) özel yükümlülükler getirebilir; uyumluluk ekibiyle birlikte değerlendirin.

5) Uygulanabilir “üretime çıkış” kontrol listesi

A. Maliyet ve kapasite

  • İstek başına input/output token p50/p95 raporlanıyor.
  • Max output token ve format hedefleri tanımlandı.
  • Cache/batch stratejisi belgelendi (uygun işlerde).
  • Bütçe alarmı ve anomali uyarıları aktif.

B. Performans ve güvenilirlik

  • Uçtan uca gecikme bütçesi ve SLO tanımlı.
  • p95 gecikme ve hata oranı için dashboard var.
  • Fallback planı hazır (daha küçük model, sınırlı özellik modu, manuel yönlendirme).
  • Model/prompt sürüm değişiklikleri kademeli rollout ile yapılıyor.

C. Güvenlik ve governance

  • Anahtarlar secrets yöneticisinde; rotasyon planı var.
  • RBAC ve ortam ayrımı (dev/stage/prod) uygulanıyor.
  • PII ve hassas veri politikası yazılı; log erişimi kısıtlı.
  • RAG kaynak yönetimi ve provenance kaydı var.
  • Olay yönetimi runbook’u ve sorumluluklar net.

6) Pilot tasarımı: küçük başlatın, doğru metrikle büyütün

Birçok ekip için en düşük riskli yaklaşım:

  1. Tek use-case seçin: Örn. destek yanıt taslağı, doküman özetleme, içerik sınıflandırma.
  2. Golden set oluşturun: 100–500 örnekle başlayın; insan değerlendirmesi ekleyin.
  3. A/B kıyaslayın: Prompt versiyonu, model boyutu, RAG açık/kapalı, quantization açık/kapalı.
  4. Önce güvenlik: Anahtar yönetimi, bütçe alarmları ve log politikası pilotta bile hazır olsun.
  5. Kademeli rollout: %1 → %10 → %50 → %100; her aşamada p95 ve maliyet metriği kontrolü.

Performans tarafında AWQ/GPTQ gibi teknikleri deniyorsanız, üretime geçmeden önce kalite regresyonunu ve edge-case’leri yakalamak için görev-spesifik testler şarttır (https://aws.amazon.com/blogs/machine-learning/accelerating-llm-inference-with-post-training-weight-and-activation-using-awq-and-gptq-on-amazon-sagemaker-ai/).

Sonuç: Kazanç, “model seçimi” kadar mühendislik disiplininde

Üretimde LLM entegrasyonu, tek bir model kararından ibaret değildir. Token ekonomisiyle maliyeti görünür kılmak, gecikme bütçesiyle performansı yönetmek ve NIST benzeri governance referanslarıyla denetlenebilirliği kurmak; ölçek büyüdükçe sistemi daha öngörülebilir hale getirir. Fiyatlar ve teknik seçenekler hızlı değiştiği için, özellikle fiyatlama gibi konuları yayın öncesinde sağlayıcının güncel dokümanlarından doğrulamak iyi bir pratiktir (https://openai.com/api/pricing/). Fiyat sayfası son kontrol: 2026-03-10.