Model Servis Etme: Sunum Katmanı Seçenekleri ve Kriterleri

Model servis etme nedir? Model servis etme, eğitilmiş bir yapay zeka modelini gerçek kullanıcı isteklerine düşük gecikme ve yüksek verimle yanıt üreten dayanıklı bir üretim servisine dönüştürme işidir. Bir modeli bir kez çalıştırmak kolaydır; onu binlerce eşzamanlı istek altında hızlı, ucuz ve güvenilir tutmak ise ayrı bir mühendislik disiplinidir. İşte bu disiplinin adı model servis etmedir ve kalbinde bir sunum katmanı (serving layer) bulunur.

Bu rehberde model servis etme kararının tüm boyutlarını bir danışman titizliğiyle ele alıyoruz: modeli çalıştırmak ile servis etmek arasındaki fark nedir; sunum katmanı hangi bileşenlerden oluşur; yönetilen API mi yoksa kendi altyapında self-host mu seçmelisin; vLLM, TGI ve Ollama gibi inference sunucu seçenekleri neyle ayrışır; verim throughput ile gecikme arasındaki denge nasıl kurulur; toplu işleme (batching) ve streaming neyi değiştirir; eşzamanlı istek yükü nasıl karşılanır; GPU tahsisi, KV cache ve kuantizasyon maliyeti nasıl belirler; izleme ve sağlık kontrolü neden zorunludur; ve KVKK ile veri ikametgahı bu kararı nasıl şekillendirir. Dil modellerinin temelini LLM nedir ve çıkarım donanımını GPU nedir yazılarında ele alıyoruz.

Tanım

Model Servis Etme (Model Serving)

Eğitilmiş bir yapay zeka modelini, gerçek kullanıcı isteklerine düşük gecikme, yüksek verim ve güvenilirlikle yanıt üreten bir üretim servisine dönüştürme işi. Bir sunum katmanı gerektirir: isteği karşılayan bir inference sunucu, eşzamanlı istekleri toplu işleyen (batching) bir zamanlayıcı, GPU belleğini ve KV cache'i yöneten bir mekanizma, yanıtı token token ileten streaming ve izleme/sağlık kontrolü. Seçim iki eksende yapılır: yönetilen API mi self-host mu; ve verim ile gecikme arasında hangi denge.

Ayrıca: Model serving, inference servisi, model sunumu, sunum katmanı, serving layer

Model servis etme, en yalın haliyle, "modeli üretime almak" işidir: eğitilmiş bir modeli alıp, bir ağ arayüzü (genellikle bir API) arkasında, çok sayıda kullanıcının aynı anda kullanabileceği bir hizmete dönüştürmek. Bu tanımdaki üç kelime kritiktir. "Servis" kelimesi, tek seferlik bir hesaplamayı değil, sürekli ayakta duran bir hizmeti anlatır. "Üretim" kelimesi, laboratuvar koşullarını değil, gerçek yük, gerçek hata ve gerçek gecikme baskısını ima eder. "Model" ise burada yalnızca ağırlıklar dosyası değil; onu çalıştıran tüm sunum katmanıdır.

Bir benzetme yardımcı olur. Bir modeli eğitmek, bir yemeğin tarifini mükemmelleştirmek gibidir; modeli servis etmek ise o tarifi, akşam yüz masanın aynı anda sipariş verdiği işleyen bir restorana dönüştürmektir. Tarif aynı olsa bile, mutfağın düzeni, aşçıların koordinasyonu, siparişlerin sıraya konması ve tabakların zamanında çıkması bambaşka bir uzmanlık ister. Model servis etme, işte bu "mutfak işletmeciliği"dir: modelin kalitesini korurken, onu ölçekte, hızda ve maliyette ayakta tutmak.

Bu ayrım pratikte şu anlama gelir: en iyi modeli seçmek, iyi bir servisin yalnızca yarısıdır. Diğer yarısı, o modeli hangi inference sunucu üzerinde, hangi batching stratejisiyle, hangi GPU tahsisiyle ve hangi izleme disipliniyle çalıştırdığındır. Bu rehber boyunca defalarca göreceğimiz gibi, model servis etme kalitesi çoğu zaman modelden değil, sunum katmanının tasarımından gelir. Bir başka deyişle, aynı model iki farklı kurumda bambaşka bir kullanıcı deneyimi sunabilir; farkı yaratan, modelin ağırlıkları değil, onu saran servis mimarisinin olgunluğudur. Bu nedenle model servis etme, bir yapay zeka ürününün gizli rekabet avantajı olabilir: kullanıcı yalnızca hızı ve güvenilirliği görür, ama bunların ardında iyi tasarlanmış bir sunum katmanı vardır.

Kurumların en sık yaptığı düşünce hatası, "model çalışıyor, o zaman iş bitti" varsayımıdır. Bir dizüstü bilgisayarda bir komutla modeli çalıştırıp bir yanıt almak, model servis etmenin yalnızca en ilkel biçimidir. Aradaki fark, tek bir arabayı çalıştırmakla bir toplu taşıma ağı işletmek arasındaki fark kadar büyüktür.

Modeli çalıştırmak tek bir isteği tek bir kez işler; kaynak paylaşımı, sıra yönetimi veya arıza dayanıklılığı düşünülmez. Model servis etme ise aynı anda gelen yüzlerce isteği yönetmek zorundadır: bunları toplu işleme (batching) ile birleştirmeli, GPU belleğini paylaştırmalı, biri yavaşladığında diğerlerini bekletmemeli, bir kopya çöktüğünde trafiği sağlam kopyalara yönlendirmeli ve tüm bunları yaparken gecikmeyi hedef sınırların altında tutmalıdır. Bu, bir çıkarım (inference) probleminden çok, bir dağıtık sistem problemidir.

Modeli çalıştırmak ile model servis etmek arasındaki temel farklar

Boyut	Modeli çalıştırmak	Model servis etme
Amaç	Tek bir yanıt almak	Sürekli, çok kullanıcılı hizmet
Yük	Tek istek	Yüzlerce eşzamanlı istek
Öncelik	Çalışması yeter	Gecikme + verim + maliyet dengesi
Bellek	Önemsiz	KV cache ve GPU tahsisi kritik
Hata	Yeniden çalıştır	Otomatik kurtarma, sağlık kontrolü
İzleme	Gerekmez	p50/p95/p99, verim, GPU kullanımı

Bu tablo, neden bir prototipin üretime taşınmasının çoğu zaman göründüğünden zor olduğunu açıklar. Bir gösteri (demo) tek kullanıcıyla mükemmel çalışabilir; ama aynı sistem elli eşzamanlı istek altında ya çok yavaşlar ya belleği taşar ya da maliyeti sürdürülemez hale gelir. Model servis etme, tam olarak bu "demo ile üretim arasındaki uçurumu" kapatma işidir. Bu uçurumu daha geniş bir çerçevede LLMOps nedir yazısında ele alıyoruz.

Model servis etmenin kalbinde sunum katmanı bulunur. Sunum katmanı, ham modeli bir üretim servisine dönüştüren yazılım ve altyapı bileşenlerinin toplamıdır. Bu bileşenleri bir arada görmek, "model servis etme" sorusunu somut bir mimari resme dönüştürür.

Tipik bir sunum katmanı şu bileşenlerden oluşur. Birincisi inference sunucu: isteği alıp modeli çalıştıran ve token üreten çekirdek yazılım (vLLM, TGI, TensorRT-LLM, Ollama gibi). İkincisi zamanlayıcı ve batching mantığı: eşzamanlı istekleri GPU'yu boş bırakmayacak biçimde birleştiren katman. Üçüncüsü bellek yöneticisi: model ağırlıkları ve özellikle KV cache için GPU belleğini paylaştıran mekanizma. Dördüncüsü streaming katmanı: yanıtı token token kullanıcıya ileten arayüz. Beşincisi API geçidi ve yük dengeleyici: istekleri kabul eden, kimlik doğrulayan ve birden çok model kopyasına dağıtan katman. Altıncısı gözlemlenebilirlik: gecikme, verim, hata ve GPU kullanımını ölçen izleme.

Sunum katmanının bileşenleri, görevleri ve kötü kurgulanırsa etkisi

Bileşen	Görevi	Kötü kurgulanırsa
Inference sunucu	Modeli çalıştırır, token üretir	Düşük verim, yüksek gecikme
Batching zamanlayıcı	Eşzamanlı istekleri birleştirir	GPU boşta kalır, maliyet artar
KV cache / bellek	GPU belleğini paylaştırır	Bellek taşar, eşzamanlılık düşer
Streaming	Yanıtı token token iletir	Kullanıcı uzun süre boş ekran görür
API geçidi / yük dengeleyici	İstekleri dağıtır, doğrular	Tek nokta darboğaz olur
İzleme	Metrikleri sürekli ölçer	Bozulmalar fark edilmeden büyür

Bu bileşenlerin çoğu, yönetilen bir API kullandığında sağlayıcının sorumluluğundadır; self-host ettiğinde ise senin kurman gereken katmanlardır. Kritik nokta şudur: sunum katmanı bir zincirdir ve en zayıf halka tüm sistemin kalitesini belirler. En güçlü GPU bile kötü bir batching stratejisiyle boşa harcanır; en iyi inference sunucu bile izleme olmadan sessizce bozulur. Bu yüzden model servis etme, tek bir bileşeni değil, tüm sunum katmanını dengeli kurma işidir.

Model servis etme kararının en temel çatalı budur: modeli bir sağlayıcının yönetilen API'si üzerinden mi tüketeceksin, yoksa kendi altyapında (bulut GPU veya şirket içi sunucu) bir inference sunucu ile self-host mu edeceksin? Bu karar, maliyet, hız, kontrol, uyum ve işletme yükünün tamamını etkiler ve tek doğru cevabı yoktur.

Yönetilen API'nin gücü basitliktir. Bir uç noktaya (endpoint) istek atarsın; ölçekleme, GPU tedariki, batching, güncelleme ve arıza yönetimi sağlayıcının sorumluluğundadır. Dakikalar içinde başlarsın, sabit altyapı maliyeti taşımazsın ve yükün değişkense yalnızca kullandığın kadar ödersin. Bedeli, token başına maliyetin yüksek hacimde birikmesi, veriyi kurum dışına göndermek zorunda kalman ve model/versiyon üzerinde sınırlı kontroldür. Erken aşamada, değişken yükte ve küçük ekiplerde yönetilen API neredeyse her zaman en akılcı başlangıçtır.

Self-host'un gücü ise kontrol ve ekonomidir. Yüksek ve öngörülebilir hacimde, kendi GPU'nda çalıştırmak token başına maliyeti belirgin düşürebilir; veriyi kurum sınırında tutarak KVKK ve veri ikametgahı gereksinimlerini karşılar; ve model seçimi, kuantizasyon, versiyon sabitleme gibi konularda tam kontrol verir. Bedeli, GPU tedariki, operasyon, gözlemlenebilirlik ve yedeklilik yükünü senin taşımandır. Bu kararın KVKK/BDDK boyutunu self-host LLM ile API karşılaştırması yazısında, şirket içi altyapının bütününü ise on-premise yapay zeka altyapısı ve on-prem LLM kurulumu yazılarında ayrıntılandırıyoruz.

Yönetilen API ile self-host inference sunucu karşılaştırması

Kriter	Yönetilen API	Self-host (vLLM/TGI)
Başlangıç hızı	Dakikalar	Kurulum ve tedarik gerekir
Altyapı bakımı	Sağlayıcıda	Sende
Yüksek hacim maliyeti	Token başına birikir	Sabit maliyete dağılır, düşebilir
Veri ikametgahı / KVKK	Sağlayıcıya bağlı	Kurum sınırında tutulabilir
Kontrol / özelleştirme	Sınırlı	Tam (model, versiyon, kuantizasyon)
En iyi kullanım	Erken aşama, değişken yük	Yüksek/öngörülebilir hacim, katı uyum

Pratik yol çoğu zaman ikisinin karışımıdır: değeri bir API ile hızla kanıtla, hacim ve uyum gereksinimi netleştikçe kritik iş yüklerini self-host'a taşı ve ikisini bir kurumsal LLM model seçimi çerçevesiyle yönet. Açık kaynak modelleri kendi altyapında çalıştırma seçeneğini açık kaynak LLM nedir ve açık mı kapalı model mi yazılarında değerlendiriyoruz.

Self-host yolunu seçtiğinde, ilk somut karar hangi inference sunucu üzerinde çalışacağındır. Inference sunucu, modeli belleğe yükleyen, gelen istekleri batching ile yöneten ve token üreten çekirdek yazılımdır. Bu alanda birkaç olgun seçenek vardır ve her biri farklı bir kullanım profiline hitap eder. Ürün adları hızla değiştiği için burada kategori düzeyinde düşünmek daha kalıcıdır.

vLLM, yüksek verim throughput hedefleyen üretim iş yükleri için en çok tercih edilen açık kaynak sunuculardan biridir. Öne çıkan iki tekniği vardır: continuous batching (istekleri dinamik olarak partiye alıp çıkaran zamanlayıcı) ve PagedAttention (GPU belleğini işletim sistemindeki sayfalama gibi verimli yöneterek KV cache israfını azaltan mekanizma). Bu ikisi sayesinde vLLM, aynı GPU'da çok daha fazla eşzamanlı istek karşılar. PagedAttention'ın mantığını PagedAttention ve continuous batching'i continuous batching yazılarında ele alıyoruz.

TGI (Text Generation Inference), kurumsal üretim özelliklerine (token streaming, güvenlik, gözlemlenebilirlik entegrasyonları, çoklu GPU dağıtımı) odaklanan olgun bir sunucudur; büyük ölçekli, kurumsal dağıtımlarda tercih edilir. Ollama ise farklı bir amaca hizmet eder: yerel makinede veya küçük ölçekte modeli hızlıca çalıştırmak, geliştirme, prototipleme ve düşük hacimli kullanım için pratik bir seçenektir. Ollama'nın kullanımını Ollama nedir yazısında ele alıyoruz. Bunların yanında NVIDIA'nın TensorRT-LLM'i, en yüksek performans için donanıma özel optimizasyon sunar; ama kurulum ve bakım karmaşıklığı daha yüksektir.

Yaygın inference sunucu seçenekleri ve uygun kullanım profilleri

Sunucu	Öne çıkan güç	En uygun kullanım	Dikkat
vLLM	Continuous batching + PagedAttention	Yüksek verimli üretim servisi	GPU ve kurulum gerektirir
TGI	Kurumsal üretim özellikleri	Büyük ölçekli kurumsal dağıtım	Operasyon yükü
Ollama	Kolay yerel kurulum	Geliştirme, prototip, küçük ölçek	Yüksek eşzamanlılıkta sınırlı
TensorRT-LLM	Donanıma özel en yüksek hız	En düşük gecikme hedefi	Kurulum karmaşıklığı yüksek

Doğru seçim, iş yükünün profilinden çıkar: yüksek eşzamanlı istek ve verim önceliğin ise vLLM veya TGI; yerel geliştirme ve deneme ise Ollama; en düşük gecikme kritikse ve donanıma yatırım yapabiliyorsan TensorRT-LLM. Bu seçeneklerin çıkarım tarafını daha derin optimize eden teknikleri LLM çıkarım servisi optimizasyonu yazısında ele alıyoruz.

Model servis etmenin tüm mühendisliği, iki büyük metrik arasındaki gerilime dayanır: verim ve gecikme. Verim, sistemin birim zamanda ürettiği toplam iş miktarıdır — saniyede işlenen token veya tamamlanan istek sayısı. Gecikme ise tek bir isteğin yanıt süresidir. Bu ikisi çoğu zaman birbirini çeker; birini iyileştirmek diğerini zorlar. İyi tasarım, bu dengeyi iş yükünün önceliğine göre bilinçle kurmaktır.

Gecikmeyi ölçerken iki ayrı süre önemlidir. İlk token gecikmesi (time to first token), kullanıcının isteği gönderdikten sonra ilk yanıt parçasını görmesine kadar geçen süredir; etkileşimli deneyimde algılanan hızın çoğunu belirler. Token başına süre (inter-token latency) ise yanıtın ne hızda aktığıdır. Sohbet gibi senaryolarda ilk token gecikmesi ve akıcı streaming kritiktir; çünkü kullanıcı boş bir ekrana değil, yazılmaya başlayan bir yanıta bakmak ister. Bu konunun tamamını LLM gecikme ve latency yazısında derinlemesine ele alıyoruz; bağlam boyutunun etkisini ise context window nedir yazısında.

Verim tarafında ise mesele donanımı doyurmaktır. Bir GPU tek bir isteği işlerken büyük ölçüde boş bekler; birden çok isteği aynı anda işlediğinde ise paralel hesaplama gücü dolar ve verim throughput değeri katlanır. İşte bu yüzden batching, verimin en güçlü kaldıracıdır. Ama batch boyutunu büyütmek bir isteğin partinin dolmasını beklemesine yol açabilir ve gecikmeyi artırabilir. Denge burada kurulur.

Verim ve gecikme önceliğine göre servis ayarı

Öncelik	Tipik senaryo	Ayar eğilimi
Düşük gecikme	Sohbet, canlı asistan	Küçük batch, streaming, küçük/orta model
Yüksek verim	Toplu belge işleme, çevrimdışı iş	Büyük batch, eşzamanlılık üst sınırı yüksek
Dengeli	Karma kurumsal yük	Continuous batching + p95 hedefi

Doğru yaklaşım, batch boyutu, eşzamanlılık sınırı ve model boyutunu bir p95/p99 gecikme hedefi ile bir toplam verim hedefini birlikte gözeterek ayarlamaktır. Kritik olan, gecikmeyi ortalama ile değil yüzdeliklerle ölçmektir: ortalama gecikme iyi görünürken p99'daki bir kullanıcı saniyelerce bekliyor olabilir. Model servis etme kalitesi, çoğu zaman bu "kuyruk gecikmesini" yönetmekten geçer.

Toplu işleme (batching), model servis etmenin ekonomisini tek başına değiştiren en güçlü tekniktir. Temel fikri basittir: birden çok isteği aynı anda GPU'ya vererek, donanımın paralel hesaplama gücünü tam kullanmak. Bir GPU, tek bir isteğin küçük hesaplamasını yaparken çekirdeklerinin çoğunu boş bırakır; aynı anda otuz isteği işlediğinde ise aynı çekirdekler dolar ve neredeyse aynı sürede otuz kat iş çıkar.

Ancak klasik (statik) batching'in bir sorunu vardır: bir partideki tüm istekler aynı anda başlar ve en uzun istek bitene kadar diğerleri bekler; kısa istekler, uzun olanları beklerken GPU kısmen boşa gider. Continuous batching (sürekli toplu işleme) bu sorunu çözer: partiyi sabit tutmaz; üretim sırasında biten isteği partiden çıkarır, kuyruktaki yeni isteği hemen içeri alır. Böylece GPU sürekli dolu kalır ve hem verim throughput yükselir hem de bekleyen isteklerin gecikmesi azalır. vLLM'in yüksek performansının büyük kısmı bu tekniğe dayanır; ayrıntısını continuous batching yazısında ele alıyoruz.

Batching'in bir de bellek boyutu vardır. Aynı anda ne kadar çok istek işlersen, her isteğin ürettiği ara durumu (KV cache) tutmak için o kadar çok GPU belleği gerekir. Yani batch boyutunu artırmak verimi yükseltir ama belleği tüketir; bellek dolduğunda daha fazla eşzamanlı istek alamazsın. Bu yüzden batching, GPU belleği yönetimiyle (özellikle PagedAttention gibi tekniklerle) el ele gider. Batch boyutu, verim, gecikme ve bellek arasındaki bu üçlü denge, sunum katmanı ayarının özüdür.

Model servis etmede kullanıcı deneyimini en çok etkileyen tekniklerden biri streaming'dir. Bir dil modeli yanıtı bir bütün olarak değil, token token (kelime parçası parçası) üretir. Streaming, bu token'ları üretildikçe kullanıcıya iletmek demektir; kullanıcı, tüm yanıtın bitmesini beklemek yerine, yanıtın yazılmaya başladığını anında görür.

Bu ayrım algılanan hız için kritiktir. Bir yanıtın tamamı on saniyede oluşuyorsa, streaming olmadan kullanıcı on saniye boş ekrana bakar; streaming ile ise ilk kelimeyi belki yarım saniyede görür ve gerisi akarken okumaya başlar. Ham hız aynı olsa bile, algılanan hız dramatik biçimde artar. Bu yüzden sohbet ve asistan arayüzlerinde streaming neredeyse zorunludur; ilk token gecikmesini (time to first token) düşük tutmak, toplam süreyi düşürmekten çoğu zaman daha değerlidir.

Streaming'in teknik bedeli, sunum katmanının yanıtı parça parça iletebilen bir bağlantı (genellikle sunucu gönderimli olaylar veya benzeri bir akış protokolü) tutmasıdır. Bu, bağlantı yönetimini ve hata durumlarını (akış ortasında kopan bağlantı) biraz karmaşıklaştırır; ama getirdiği deneyim kazancı, bu maliyeti fazlasıyla haklı çıkarır. Çevrimdışı, toplu iş yüklerinde ise streaming gereksizdir; orada kullanıcı beklemediği için tüm yanıtı bir kerede almak yeterlidir. Yani streaming kararı da, tıpkı batching gibi, iş yükünün etkileşimli mi çevrimdışı mı olduğuna bağlıdır.

Gerçek bir üretim servisinde istekler tek tek gelmez; aynı anda onlarca, yüzlerce eşzamanlı istek gelir ve model servis etmenin en zorlu kısmı bu yükü zarifçe karşılamaktır. Eşzamanlı istek yönetimi iki katmanda çalışır: tek bir sunucu içinde istekleri verimli birleştirmek ve kapasite dolduğunda daha fazla sunucu ekleyerek yatay ölçeklemek.

Tek sunucu içinde eşzamanlı istek yükünü karşılamanın temel aracı, daha önce ele aldığımız continuous batching'dir: gelen istekler tek bir GPU'da dinamik bir partide birleşir ve GPU boşta kalmaz. Ama bir sunucunun kapasitesi sonsuz değildir; GPU belleği ve hesaplama gücü dolduğunda yeni istekler ya bekler ya reddedilir. Bu noktada iki ölçekleme yolu vardır. Dikey ölçekleme, daha büyük veya daha çok GPU'lu tek bir makineye geçmektir; basittir ama bir sınırı vardır. Yatay ölçekleme ise aynı modelin birden çok kopyasını çalıştırıp önlerine bir yük dengeleyici koymaktır; istekler kopyalar arasında dağıtılır ve kapasite kopya ekleyerek neredeyse doğrusal büyür.

Nasıl Yapılır

Eşzamanlı istek yükünü karşılamanın katmanları

Bir model servis etme sisteminin artan eşzamanlı istek yükünü zarifçe karşılamak için izlediği temel katmanlar.

1. 1

   Continuous batching ile birleştir

   Tek GPU içinde eşzamanlı istekleri dinamik partide birleştirerek donanımı doyur.

2. 2

   Önbellek ve yönlendirme ekle

   Sık sorulanları önbelleğe al, kolay istekleri küçük modele yönlendirerek yükü azalt.

3. 3

   Yatay ölçekle

   Aynı modelin birden çok kopyasını bir yük dengeleyici arkasına koyup istekleri dağıt.

4. 4

   Kuyruk ve geri basınç kur

   Kapasite dolduğunda istekleri sıraya al veya nazikçe reddet; sistemi çökertme.

5. 5

   Otomatik ölçekle

   Yük metriklerine göre kopya sayısını otomatik artırıp azalt.

Eşzamanlı istek yükünü yönetmenin sık ihmal edilen bir boyutu geri basınçtır (backpressure): kapasite dolduğunda sistem sonsuz istek kabul etmemeli, aksi halde tüm istekler yavaşlar ve hepsi başarısız olur. İyi bir sunum katmanı, kapasitesini bildiğinde fazla isteği ya kuyruğa alır ya da nazikçe reddeder; böylece kabul ettiği istekleri hedef gecikmede yanıtlar. Ayrıca sık tekrar eden sorguları önbelleğe almak ve kolay istekleri küçük bir modele yönlendirmek, eşzamanlı istek yükünü kaynağında azaltan güçlü yöntemlerdir. Küçük ve büyük modelin bu iş bölümünü küçük ve büyük model eğilimi yazısında ele alıyoruz.

Model servis etmenin fiziksel gerçekliği GPU belleğinde yaşanır. Bir GPU'nun belleği iki büyük şeyi tutmak zorundadır: modelin ağırlıkları ve her aktif isteğin ürettiği ara durum, yani KV cache. Bu ikisinin bellek bütçesini nasıl paylaştığın, aynı donanımda kaç eşzamanlı istek karşılayabileceğini doğrudan belirler. GPU'nun kurumsal rolünü kurumsal AI için GPU yazısında ele alıyoruz.

KV cache (anahtar-değer önbelleği), bir dil modelinin yanıt üretirken daha önce işlediği token'ların ara hesaplamalarını tekrar tekrar hesaplamamak için sakladığı bellektir. Yanıt uzadıkça ve eşzamanlı istek sayısı arttıkça, KV cache belleği hızla büyür ve çoğu zaman model ağırlıklarından bile fazla yer tutabilir. KV cache'in ne olduğunu key-value cache yazısında ele alıyoruz. Klasik yaklaşımda her isteğe bitişik bir bellek bloğu ayrılır; bu, hem israfa (ayrılıp kullanılmayan alan) hem de parçalanmaya yol açar ve pratikte karşılanabilecek eşzamanlı istek sayısını düşürür.

PagedAttention tam bu sorunu çözer. İşletim sistemlerindeki sayfalı bellek yönetiminden esinlenerek, KV cache'i küçük, esnek sayfalara böler ve belleği bitişik blok zorunluluğu olmadan tahsis eder. Sonuç, çok daha az bellek israfı ve aynı GPU'da çok daha fazla eşzamanlı istektir. Bu tekniğin ayrıntısını PagedAttention yazısında ele alıyoruz. Çok büyük modeller tek bir GPU'ya sığmadığında ise model, birden çok GPU'ya bölünür; bu bölme stratejilerinden birini tensör paralelliği yazısında ele alıyoruz.

Model servis etme maliyetini düşürmenin en doğrudan iki kaldıracı, modeli küçültmek (kuantizasyon) ve zaten küçük bir model seçmektir. İkisi de aynı hedefe hizmet eder: aynı donanımda daha fazla eşzamanlı istek, daha yüksek verim ve daha düşük token başına maliyet.

Kuantizasyon, model ağırlıklarını daha düşük hassasiyetle (örneğin 16 bit yerine 8 veya 4 bit) temsil ederek modelin bellek ayak izini küçültme tekniğidir. Küçülen model hem daha az GPU belleği kaplar (böylece KV cache'e daha çok yer kalır ve daha fazla eşzamanlı istek sığar) hem de genellikle daha hızlı çalışır. Bedeli, çok agresif kuantizasyonda kalitenin bir miktar düşebilmesidir; bu yüzden kuantizasyon seviyesi bir değerlendirme kümesiyle doğrulanmalıdır. Kuantizasyonun türlerini int8 kuantizasyon ve eğitim sonrası kuantizasyon yazılarında ele alıyoruz.

Model boyutu seçimi ise daha stratejik bir karardır. Çoğu kurumsal görev, en büyük ve en pahalı modeli gerektirmez; iyi seçilmiş bir görevde küçük veya orta boy bir model neredeyse aynı kaliteyi çok daha düşük maliyetle üretir. Akıllı desen, görevleri zorluğuna göre ayıran bir model yönlendirme (routing) katmanı kurmaktır: basit istekler küçük ve hızlı bir modele, yalnızca gerçekten zor olanlar büyük modele gider. Bu yaklaşım, ortalama maliyeti dramatik düşürürken kaliteyi korur. Küçük modele doğru bu genel eğilimi küçük ve büyük model eğilimi yazısında, çıkarım maliyetini düşürme yöntemlerini ise LLM çıkarım maliyeti optimizasyonu yazısında ele alıyoruz.

Servis maliyetini düşüren kaldıraçlar ve etkileri

Kaldıraç	Nasıl çalışır	Etki	Dikkat
Kuantizasyon	Ağırlıkları düşük bit ile temsil eder	Daha az bellek, daha çok eşzamanlılık	Agresifse kalite düşebilir
Küçük model seçimi	Göreve yeten en küçük modeli kullanır	Düşük gecikme, yüksek verim	Zor görevde yetmeyebilir
Model yönlendirme	İsteği zorluğa göre modele dağıtır	Ortalama maliyeti düşürür	Yönlendirme mantığı gerektirir
Önbellek	Tekrar eden yanıtları saklar	Yükü kaynağında azaltır	Tazelik yönetimi gerekir

Model servis etmenin ekonomisini yönetmek için, maliyetin nereden geldiğini net görmek gerekir. Yönetilen API'de maliyet genellikle token başına faturalanır: gönderdiğin (girdi) ve aldığın (çıktı) token sayısına göre ödersin. Self-host'ta ise maliyet farklı yapıdadır: GPU'nun saatlik/aylık sabit bedeli, elektrik ve operasyon; bunu işlediğin toplam token sayısına bölünce gerçek token başına maliyeti bulursun.

Bu iki modelin kesişim noktası, self-host kararının kalbidir. Düşük ve değişken hacimde, yönetilen API'nin token başına bedeli görece yüksek olsa da toplam düşük kalır ve sabit altyapı taşımazsın; API kazanır. Ama hacim yükselip öngörülebilir hale geldiğinde, self-host'un sabit maliyeti çok sayıda token'a dağılır ve token başına maliyet API'nin çok altına inebilir; bu eşiği geçtiğinde self-host ekonomik olur. Bu hesabı ciddi yapmadan self-host'a geçmek de, hacim yüksekken API'de kalmak da pahalı hatalardır. Maliyet disiplininin bütününü LLM maliyet optimizasyonu yazısında ele alıyoruz.

Token başına maliyeti düşüren teknikler, aslında bu rehber boyunca ele aldığımız her şeyle örtüşür. Batching, aynı GPU'dan daha çok token çıkararak sabit maliyeti daha çok işe böler. Kuantizasyon ve küçük model, hem hızı artırıp hem belleği azaltarak eşzamanlılığı yükseltir. Önbellek, tekrar eden istekleri hiç modele göndermeden yanıtlar. Model yönlendirme, pahalı büyük modeli yalnızca gerektiğinde çağırır. Yani model servis etmede maliyet optimizasyonu ayrı bir iş değildir; iyi tasarlanmış bir sunum katmanının doğal sonucudur.

Ölçmediğin bir servisi yönetemezsin; bu, model servis etme için özellikle geçerlidir. Bir üretim LLM servisi, izleme ve sağlık kontrolü olmadan sessizce bozulur: gecikme sürünerek artar, hata oranı yükselir, GPU dolar ve kimse fark etmez. Bu yüzden gözlemlenebilirlik, sonradan eklenecek bir lüks değil, sunum katmanının baştan kurulan bir bileşenidir. LLM tarafında gözlemlenebilirliğin ne anlama geldiğini LLM gözlemlenebilirliği nedir yazısında ele alıyoruz.

İzlenmesi gereken metrikler birkaç grupta toplanır. Gecikme metrikleri: ilk token gecikmesi ve toplam yanıt süresi, mutlaka yüzdeliklerle (p50, p95, p99) izlenmelidir; ortalama, kuyruktaki kötü deneyimi gizler. Verim metrikleri: saniyede işlenen token ve tamamlanan istek sayısı, kapasitenin ne kadarının kullanıldığını gösterir. Kaynak metrikleri: GPU kullanımı, GPU bellek doluluğu ve KV cache doluluğu, darboğazın nerede olduğunu söyler. Kalite ve hata metrikleri: hata oranı, zaman aşımı sayısı, reddedilen istek oranı ve yanıt kalitesi göstergeleri.

Model servis etmede izlenmesi gereken temel metrikler

Metrik grubu	Örnek ölçüt	Ne söyler
Gecikme	İlk token, p95/p99 yanıt süresi	Kullanıcı deneyimi bozuluyor mu
Verim	Saniyedeki token/istek	Kapasitenin ne kadarı dolu
Kaynak	GPU kullanımı, KV cache doluluğu	Darboğaz nerede
Hata	Hata oranı, zaman aşımı, red	Sistem sağlıklı mı
Maliyet	Token başına maliyet, GPU doluluğu	Ekonomi sürdürülebilir mi

Metriklerin yanında sağlık kontrolü (health check) mekanizmaları da şarttır. Her model kopyası, "ayakta ve yanıt verebilir durumda mıyım" sorusuna cevap veren bir sağlık ucu sunmalı; yük dengeleyici, sağlıksız kopyaları trafikten çıkarıp sağlam olanlara yönlendirmelidir. Bir kopya çöktüğünde otomatik yeniden başlatma, bellek sızıntısında otomatik geri dönüşüm ve anormal gecikmede uyarı, üretim dayanıklılığının temelidir. Bu operasyonel disiplinin bütününü LLMOps nedir yazısında ele alıyoruz.

Model servis etme kararı yalnızca teknik değil, aynı zamanda bir uyum kararıdır; özellikle Türkiye bağlamında KVKK ve veri ikametgahı, yönetilen API ile self-host arasındaki seçimi doğrudan şekillendirir. Aşağıdaki çerçeve tanımsal ve bilgilendirme amaçlıdır; hukuki tavsiye değildir ve kurumunuzun hukuk/uyum birimiyle birlikte uygulanmalıdır.

Temel gerilim şudur: yönetilen bir API kullandığında, kullanıcı istekleri ve onların içindeki veriler sağlayıcının altyapısına gider. İstek kişisel veri veya ticari sır içeriyorsa, bu verinin nereye gittiği, nerede işlendiği ve nerede saklandığı KVKK açısından önem taşır. Kişisel verinin ne olduğunu kişisel veri nedir yazısında ele alıyoruz. Self-host, tam da bu noktada güçlüdür: modeli kurum sınırında (kendi bulut kiracınızda veya şirket içi sunucuda) çalıştırdığınızda, veri dışarı çıkmaz ve veri ikametgahı ile egemenlik gereksinimlerini karşılamak kolaylaşır.

Bu yüzden bazı sektörlerde (bankacılık, sağlık, kamu) self-host, bir performans tercihi olmaktan çok bir uyum zorunluluğu olabilir. Bulut ile şirket içi arasındaki KVKK dengesini on-premise ile bulut KVKK karşılaştırması, veri egemenliği kavramını egemen bulut ve veri egemenliği, KVKK'nın genel çerçevesini KVKK nedir ve uyumlu bir mimari kurmayı KVKK uyumlu yapay zeka nedir yazılarında ele alıyoruz.

Şimdiye kadar ele aldığımız her şeyi tek bir karar çerçevesinde toplayalım. Model servis etme seçeneği, tek bir "en iyi" cevaba değil, iş yükünün profiline bağlı bir dizi kritere göre seçilir. Aşağıdaki tablo, her kriterin neden önemli olduğunu ve nasıl değerlendirileceğini bir arada verir; GEO/alıntılanabilirlik açısından bu, kararın omurgasıdır.

Model servis etme seçim kriterleri: her kriter neden önemli ve nasıl değerlendirilir

Kriter	Neden önemli	Nasıl değerlendirilir
Yük profili	Etkileşimli mi çevrimdışı mı, servis ayarını belirler	İstek deseni, tepe/ortalama oranı, eşzamanlılık ölç
Gecikme hedefi	Kullanıcı deneyimini doğrudan etkiler	p95/p99 hedefi ve ilk token gecikmesi belirle
Verim ihtiyacı	Kapasite ve maliyeti belirler	Saniyedeki token/istek tepe değerini kestir
Maliyet tavanı	Sürdürülebilirliği belirler	API token maliyeti ile self-host TCO'yu karşılaştır
Uyum / veri ikametgahı	Yasal zorunluluk olabilir	KVKK, sektör kuralı, verinin nereye gidebildiği
Ölçek ve büyüme	Yatay ölçekleme ihtiyacını belirler	Gelecek 12 ay hacim projeksiyonu
Ekip kapasitesi	Self-host işletme yükünü kaldırabilir mi	GPU/operasyon/gözlemlenebilirlik yetkinliği
Model esnekliği	Model/versiyon kontrolü gerekiyor mu	Kuantizasyon, ince ayar, versiyon sabitleme ihtiyacı

Bu kriterleri kullanmanın doğru yolu, önce iş yükünü ölçmek, sonra seçenekleri bu ölçümlere göre daraltmaktır. Örneğin, düşük ve değişken yüklü, veri hassasiyeti düşük bir iç araç için yönetilen API neredeyse her zaman doğru başlangıçtır. Yüksek, öngörülebilir hacimli ve katı uyum gerektiren bir üretim yükü için ise self-host bir inference sunucu (vLLM veya TGI) ekonomik ve uyumlu olabilir. Çoğu olgun kurum, ikisini birlikte kullanır: hassas ve yüksek hacimli yükleri self-host eder, geri kalanı API ile karşılar. Bu karar çerçevesini kurumsal bağlamda kurumsal LLM model seçimi yazısında derinleştiriyoruz.

Model servis etmeyi tam kavramanın en iyi yolu, tek bir isteğin sunum katmanı içindeki yolculuğunu adım adım izlemektir. Bir kullanıcının bir sohbet asistanına soru sorduğunu düşünelim; bu basit görünen istek, perde arkasında bir dizi katmandan geçer ve her katman nihai deneyimin kalitesini belirler.

Önce istek API geçidine ulaşır. Burada kimlik doğrulanır, hız sınırı (rate limit) kontrol edilir ve istek, o an en uygun model kopyasına yönlendirilmek üzere yük dengeleyiciye verilir. Yük dengeleyici, sağlık kontrolünden geçmiş, kapasitesi olan bir kopya seçer; sağlıksız veya dolu kopyaları atlar. Böylece istek, yanıt verebilecek durumda bir inference sunucuya ulaşır. Bu ilk katman, eşzamanlı istek yükünün adilce dağıtılmasını sağlar.

Inference sunucuya varan istek, hemen işlenmez; devam eden batch'e katılır. Continuous batching zamanlayıcısı, bu yeni isteği o an üretim yapan partiye ekler; GPU, artık bu isteği de diğerleriyle birlikte paralel işler. Sunucu, isteğin girdisini işlerken KV cache'te yer ayırır; PagedAttention sayesinde bu bellek verimli tahsis edilir ve israf azalır. İlk token üretildiği anda, streaming katmanı onu kullanıcıya iletmeye başlar; kullanıcı, tüm yanıtın bitmesini beklemeden yanıtın yazılmaya başladığını görür.

Yanıt token token akarken, izleme katmanı sessizce çalışır: ilk token gecikmesi, toplam süre, işlenen token sayısı ve GPU doluluğu kaydedilir. Yanıt tamamlandığında istek batch'ten çıkar, KV cache'teki yeri serbest bırakılır ve o alan yeni bir istek için hazır hale gelir. İşte bu uçtan uca yolculuk — geçit, yük dengeleme, batching, bellek yönetimi, streaming ve izleme — model servis etmenin özüdür. Dikkat edin: bu yolculukta modelin "zekâsı" tek başına belirleyici değildir; asıl belirleyici, isteğin bu katmanlardan ne kadar hızlı, verimli ve güvenilir geçtiğidir.

Batching ve bellek yönetiminin ötesinde, model servis etmede gecikmeyi düşürmek ve verim throughput değerini yükseltmek için birkaç ileri çıkarım tekniği daha vardır. Bunlar, sunum katmanının performansını aynı donanımda belirgin biçimde artırabilir; ama her biri belirli bir iş yükünde anlamlıdır ve körlemesine eklenmemelidir.

Speculative decoding (spekülatif kod çözme), büyük bir modelin yanıtını hızlandırmak için küçük ve hızlı bir "taslak" modeli kullanır: küçük model birkaç token'ı hızlıca tahmin eder, büyük model bunları tek seferde doğrular; doğru tahminler kabul edilir, yanlışlar düzeltilir. Sonuç, aynı kalitede yanıtın daha az adımla, yani daha düşük gecikmeyle üretilmesidir. Bu tekniğin mantığını speculative decoding yazısında ele alıyoruz. Prefix caching ise aynı sistem promptunun veya aynı belge bağlamının tekrar tekrar işlenmesini önler: bir kez hesaplanan ön ekin KV cache'i saklanır ve sonraki isteklerde yeniden kullanılır; uzun ve sabit sistem promptları olan senaryolarda ciddi tasarruf sağlar.

Bir üst katmanda ise anlamsal önbellek (semantic cache) ve prompt önbelleği bulunur. Anlamsal önbellek, daha önce benzer bir sorunun sorulduğunu tanır ve yanıtı modele hiç gitmeden döndürür; sık tekrar eden sorgularda hem gecikmeyi hem maliyeti sıfıra yakın düşürür. Bu yaklaşımı semantik önbellekleme ve prompt caching ile maliyet optimizasyonu yazılarında ele alıyoruz. Bu tekniklerin çoğunu tek bir yönlendirme katmanında birleştiren AI gateway ve semantik cache deseni, kurumsal model servis etmede giderek standart hale geliyor.

Model servis etmenin sık ihmal edilen bir boyutu, soğuk başlangıçtır (cold start): bir model kopyası ilk kez ayağa kaldırıldığında, ağırlıkların diskten GPU belleğine yüklenmesi saniyeler hatta on saniyeler sürebilir. Bu süre, sürekli çalışan bir serviste görünmez; ama otomatik ölçekleme veya ölçek-sıfıra-inme (scale to zero) kullanıyorsan, ani bir yük artışında yeni kopyanın hazır olması gecikir ve ilk kullanıcılar uzun bekler.

Bu gerilim, bir maliyet-hazırlık dengesidir. Düşük ve seyrek yükte, kullanılmayan GPU'yu kapatmak (ölçek-sıfıra-inme) maliyeti düşürür; ama bir istek geldiğinde model yeniden yüklenene kadar soğuk başlangıç gecikmesi yaşanır. Yüksek ve sürekli yükte ise en az bir kopyayı hep sıcak tutmak (warm pool) gecikmeyi düşürür ama boşta GPU maliyeti getirir. Doğru denge, yük deseninize göre kurulur: öngörülebilir tepe saatlerinde önceden ısıtma, gece düşük yükte küçültme gibi.

Soğuk başlangıç süresini kısaltmanın pratik yolları vardır: model ağırlıklarını hızlı depolamada tutmak, kuantize edilmiş (daha küçük) model kullanmak, bir sıcak kopyayı hep hazır bekletmek ve ölçekleme eşiklerini yük tepesinden önce tetiklenecek biçimde ayarlamak. Model servis etmede bu ayrıntı, kullanıcı deneyimini sessizce belirler; çünkü ortalama gecikme iyi görünürken, ölçekleme anında yakalanan kullanıcılar kötü bir deneyim yaşayabilir.

Gerçek kurumlar tek bir modeli tek bir ekip için değil, çoğu zaman birden çok modeli birden çok ekip veya müşteri için servis eder. Bu, model servis etmeye iki yeni boyut ekler: aynı altyapıda birden çok modeli barındırmak (çoklu model) ve aynı servisi birden çok kiracıya izole biçimde sunmak (çok kiracılılık).

Çoklu model servisinde temel karar, hangi modelin nerede çalışacağıdır. Sık kullanılan büyük bir modeli kendi özel GPU'sunda tutmak mantıklıdır; ama seyrek kullanılan onlarca küçük modeli her biri için ayrı GPU ayırarak çalıştırmak israftır. Bu noktada modelleri talebe göre belleğe yükleyip çıkaran (model swapping) veya küçük modelleri aynı GPU'da paylaştıran stratejiler devreye girer. Birden çok uzman modeli tek çatı altında birleştiren uzmanların karışımı (mixture of experts) yaklaşımı da, farklı bir düzeyde, bu verimlilik arayışının bir parçasıdır.

Çok kiracılılıkta ise mesele izolasyon ve adalettir. Bir kiracının ağır yükü, diğer kiracıların gecikmesini bozmamalıdır; bu, kiracı başına hız sınırı, kota ve öncelik kuyruğu gerektirir. Ayrıca kiracılar arası veri sızıntısını önlemek için istekler ve önbellekler sıkı biçimde ayrılmalıdır; bir kiracının verisi, asla başka bir kiracının yanıtında görünmemelidir. Bu izolasyon, hem KVKK hem de kurumsal güven açısından kritiktir ve model servis etme mimarisinin baştan tasarlanan bir parçası olmalıdır.

Self-host kararını verdiğinde, bir sonraki soru GPU'nun fiziksel olarak nerede duracağıdır. Model servis etme için üç ana dağıtım seçeneği vardır ve her biri maliyet, esneklik ve uyum açısından farklı bir profil sunar. Bu seçim, sunum katmanının ekonomisini ve dayanıklılığını doğrudan etkiler.

Birincisi büyük bulut sağlayıcıların yönetilen GPU'larıdır: dakikalar içinde ölçeklenir, bakım gerektirmez ve değişken yükte esnektir; ama uzun vadede ve yüksek doluluğun altında saatlik bedel birikir. İkincisi özel GPU bulut sağlayıcıları veya kiralık GPU'lardır: genellikle büyük bulutlardan daha ucuza GPU sunarlar, orta ölçekli sürekli yükler için ekonomik olabilirler; ama coğrafi konum, ağ ve destek açısından değerlendirilmelidir. Üçüncüsü şirket içi (on-premise) donanımdır: en yüksek başlangıç yatırımını gerektirir ama yüksek ve sürekli yükte en düşük uzun vadeli maliyeti ve en katı veri egemenliğini sağlar. Bu seçeneklerin bütününü on-premise yapay zeka altyapısı ve donanım tarafını on-prem LLM donanım boyutlandırma yazılarında ele alıyoruz.

Model servis etme için dağıtım seçenekleri

Seçenek	Güçlü yanı	Zayıf yanı	En uygun
Büyük bulut GPU	Anında ölçek, bakımsız	Yüksek dolulukta pahalı	Değişken/patlamalı yük
Kiralık / özel GPU bulut	Daha düşük GPU bedeli	Konum/destek değişken	Orta ölçek sürekli yük
Şirket içi (on-premise)	En düşük uzun vade maliyeti, tam egemenlik	Yüksek başlangıç yatırımı	Yüksek/sürekli yük, katı uyum

Doğru seçim çoğu zaman karışıktır: temel sürekli yükü ucuz bir sabit kaynakta (şirket içi veya kiralık) tutup, tepe yükleri esnek bulut GPU'ya taşıran hibrit bir model, hem maliyeti hem esnekliği optimize eder. Bu "taban + tepe" deseni, model servis etmede olgun kurumların sıkça başvurduğu bir yaklaşımdır.

Model servis etme yalnızca bir performans problemi değil, aynı zamanda bir güvenlik problemidir. Bir modeli bir API arkasında dünyaya açtığında, onu kötüye kullanıma, aşırı yüke ve girdi tabanlı saldırılara karşı korumak zorundasın. Güvenlik katmanı, sunum katmanının ihmal edilmemesi gereken bir bileşenidir.

İlk katman erişim ve hız kontrolüdür. Her istek kimlik doğrulamalı (kim çağırıyor), yetki kontrolünden geçmeli (bu modeli kullanmaya hakkı var mı) ve hız sınırına (rate limit) tabi olmalıdır. Hız sınırı olmadan, tek bir hatalı istemci veya kötü niyetli aktör, tüm servisi aşırı yükle çökertebilir; hız sınırı, hem adaleti hem dayanıklılığı sağlar. Kota ve öncelik kuyrukları, kritik iş yüklerinin her zaman kapasite bulmasını güvence altına alır.

İkinci katman girdi ve çıktı denetimidir. Dil modelleri, kullanıcı girdisi yoluyla manipüle edilebilir; bir saldırgan, modeli talimatlarından saptırmaya çalışabilir. Bu saldırı türünü prompt injection nedir yazısında ele alıyoruz. Sunum katmanı, girdileri süzen ve çıktıları denetleyen koruyucu bir kabuk (guardrail) içermelidir; hassas veri sızıntısını, zararlı içerik üretimini ve talimat kaçırmayı bu katman yakalar. Koruyucu katmanların tasarımını guardrail nedir yazısında ele alıyoruz. Ayrıca tüm isteklerin ve yanıtların denetim kaydı (audit log) tutulması, hem KVKK uyumu hem de olay incelemesi için gereklidir.

Bir model servis etme sistemi asla durağan değildir: modeller güncellenir, promptlar değişir, yeni sürümler çıkar. Bu değişiklikleri üretime güvenli biçimde taşımak, olgun bir sunum katmanının kritik bir yeteneğidir. Kontrolsüz bir güncelleme, sessizce kaliteyi düşürebilir veya gecikmeyi bozabilir; bu yüzden sürüm yönetimi baştan planlanmalıdır.

Temel araç kademeli yayındır. Yeni bir model sürümünü tüm trafiğe bir anda açmak yerine, önce küçük bir yüzdeye (canary) yönlendirir, metrikleri (gecikme, hata oranı, yanıt kalitesi) izler ve sorun yoksa kademeli olarak yüzdeyi artırırsın. Böylece bir sorun çıkarsa yalnızca küçük bir trafik etkilenir ve hızla geri alabilirsin. A/B dağıtımı ise iki sürümü aynı anda çalıştırıp gerçek trafikte karşılaştırmayı sağlar; hangi sürümün daha iyi yanıt verdiğini kanıta dayalı ölçersin.

Sürüm yönetiminin en önemli parçası güvenli geri almadır (rollback). Yeni sürüm beklenenden kötü çıktığında, tek bir komutla önceki bilinen-iyi sürüme dönebilmek, üretim güvenilirliğinin temelidir. Bunun için sürümler versiyonlanmalı, önceki sürüm kısa süre hazır tutulmalı ve geri alma prosedürü önceden test edilmelidir. Ayrıca model, prompt ve yapılandırma değişiklikleri izlenebilir olmalı; bir kalite düşüşü yaşandığında "hangi değişiklik bunu tetikledi" sorusuna cevap verebilmelisin. Bu operasyonel olgunluğu LLMOps nedir yazısında ele alıyoruz.

Model servis etmenin ekonomisini sessizce belirleyen bir etken, isteklerin girdi uzunluğudur. Bir dil modeli, girdideki her token'ı işlemek zorundadır; girdi uzadıkça hem işleme süresi hem KV cache bellek kullanımı artar. Uzun bağlam pencereleri güçlü bir yetenektir; ama servis tarafında doğrudan maliyet ve gecikme demektir.

Bu, özellikle RAG (bilgi getirimiyle üretim) gibi bağlama çok sayıda belge parçası eklenen senaryolarda kritiktir. Bağlama ne kadar çok parça eklersen, o kadar çok token işlenir, o kadar çok bellek tüketilir ve aynı GPU o kadar az eşzamanlı istek karşılayabilir. Bu yüzden "bağlamı daha çok belgeyle doldurmak" her zaman iyi değildir; gereksiz uzun bağlam, hem maliyeti artırır hem de modelin dikkatini dağıtabilir. Uzun bağlamda bilginin ortada kaybolması sorununu uzun bağlam yönetimi yazısında ele alıyoruz; bağlam boyutunun temelini ise context window nedir yazısında.

Servis tarafında pratik sonuç şudur: girdi uzunluğunu bilinçle yönetmek, model servis etme kapasitesini doğrudan artırır. Yalnızca gerçekten gerekli bağlamı göndermek, sabit sistem promptlarını prefix caching ile paylaştırmak ve girdi uzunluğuna göre kapasite planlamak, aynı donanımdan çok daha fazla verim throughput çıkarmanı sağlar. Bu yüzden bir sunum katmanı tasarlarken, yalnızca çıktı üretimini değil, girdi işleme yükünü de hesaba katmak gerekir.

Model servis etmede gecikmeyi düşürmenin ilk adımı, gecikmenin nereden geldiğini görmektir. Bir isteğin toplam yanıt süresi tek bir yerde değil, sunum katmanının birçok aşamasında birikir; bu süreyi parçalara ayırmak, hangi aşamanın en çok zaman yediğini ve nereye yatırım yapman gerektiğini gösterir. Buna gecikme bütçesi denir.

Bir isteğin süresi kabaca şu aşamalara dağılır. Önce ağ ve geçit süresi: istemciden API geçidine ulaşma, kimlik doğrulama ve yük dengeleyici yönlendirmesi. Sonra kuyruk süresi: istek, GPU dolu ise devam eden batch'e katılmadan önce bekleyebilir; yüksek yükte bu süre büyür. Ardından girdi işleme (prefill) süresi: modelin promptun tamamını işleyip ilk token'a hazırlanması — bu, girdi uzunluğuyla doğru orantılıdır. Sonra ilk token üretimi ve nihayet token token üretim süresi: yanıtın uzunluğu kadar süren asıl üretim.

Bu ayrıştırma, optimizasyonu odaklar. İlk token gecikmesi yüksekse, sorun genellikle kuyruk (kapasite yetersiz) veya prefill (girdi çok uzun) aşamasındadır; çözüm daha çok kapasite veya kısa girdi/prefix caching'dir. Token başına süre yavaşsa, sorun model boyutu veya bellek bant genişliğidir; çözüm daha küçük/kuantize model veya daha hızlı GPU'dur. Yalnızca "yavaş" demek yerine "hangi aşamada yavaş" diyebilmek, model servis etmede doğru kaldıraca basmanın anahtarıdır. Gecikmenin bütününü LLM gecikme ve latency yazısında derinlemesine ele alıyoruz.

"Hangi model servis etme aracını kullanmalıyım" sorusu yanlış soruyla başlar; çünkü olgun bir servis tek bir araç değil, bir dizi bileşenin birleşimidir. Doğru soru, her katman için doğru bileşeni seçip onları kurumunuzun ölçek, gecikme, maliyet ve uyum gereksinimlerine göre birleştirmektir. Ürün adları hızla değiştiği için burada kategori düzeyinde düşünmek daha kalıcıdır.

Tipik bir model servis etme yığını şu katmanlardan seçim gerektirir: çekirdek inference sunucu (vLLM, TGI, Ollama, TensorRT-LLM); önüne konan API geçidi ve yük dengeleyici; anlamsal önbellek ve model yönlendirme katmanı; gözlemlenebilirlik ve loglama; ve dağıtım/ölçekleme altyapısı (genellikle konteyner orkestrasyonu). Her katmanda, hazır bir bulut hizmeti mi kullanacağın yoksa kendin mi kuracağın kararı, hem maliyeti hem KVKK/veri ikametgahı uyumunu doğrudan etkiler. Bu katmanların çıkarım optimizasyonu tarafını LLM çıkarım servisi optimizasyonu yazısında ele alıyoruz.

Yığını kurarken birkaç ilke yardımcı olur. Birincisi başta sadelik: ilk pilotu en az bileşenle, hazır hizmetlerle kur ve değeri kanıtla; karmaşıklığı ancak ihtiyaç doğrulandığında ekle. İkincisi değiştirilebilirlik: bileşenleri gevşek bağlı tut ki gerektiğinde inference sunucuyu veya GPU sağlayıcısını değiştirebilesin. Üçüncüsü ölçüm önceliği: hangi aracı seçersen seç, gözlemlenebilirliği baştan kur. Bu ilkeler sayesinde, ekosistem değişse bile sistemin ayakta kalır; çünkü kalıcı olan, belirli bir ürün değil, iyi tasarlanmış bir sunum katmanı ve ölçüm disiplinidir.

Self-host model servis etmenin en somut ve en pahalı kararlarından biri, hangi GPU'nun seçileceğidir. Bu karar, yalnızca bir bütçe kalemi değil; aynı anda kaç eşzamanlı istek karşılayabileceğini, hangi model boyutunu çalıştırabileceğini ve token başına maliyetini doğrudan belirler. GPU seçimini iyi yapmak, sunum katmanının tavanını belirler. GPU'nun kurumsal rolünü kurumsal AI için GPU yazısında ele alıyoruz.

Seçimde en belirleyici tek özellik GPU belleğidir. Daha önce gördüğümüz gibi, bir GPU'nun belleği hem model ağırlıklarını hem de eşzamanlı isteklerin KV cache'ini tutmak zorundadır; bellek ne kadar büyükse, o kadar büyük model veya o kadar çok eşzamanlı istek sığar. İkinci özellik bellek bant genişliğidir: token üretimi büyük ölçüde belleğe erişim hızına bağlıdır, bu yüzden yüksek bant genişliği düşük gecikme demektir. Üçüncüsü hesaplama gücü ve desteklenen sayısal formatlardır (örneğin düşük-bit kuantizasyon için donanım desteği). Bu üçü birlikte, bir GPU'nun model servis etme için ne kadar uygun olduğunu belirler.

Pratik bir çerçeve şudur: önce çalıştıracağın modelin bellek ayak izini (ağırlıklar + tepe KV cache) hesapla, sonra hedeflediğin eşzamanlı istek sayısıyla çarp ve bu bütçeyi karşılayan GPU'yu seç. Model tek GPU'ya sığmıyorsa, çok GPU'ya bölmek gerekir; bunun bir yolunu tensör paralelliği yazısında ele alıyoruz. Kuantizasyon ile modeli küçültmek, çoğu zaman daha ucuz bir GPU'da çalışmayı mümkün kılar; bu yüzden donanım ve kuantizasyon kararları birlikte verilmelidir. Donanım boyutlandırmanın ayrıntısını on-prem LLM donanım boyutlandırma yazısında ele alıyoruz.

Model servis etme denince akla çoğunlukla gerçek zamanlı, etkileşimli servis gelir; ama kurumsal iş yüklerinin önemli bir kısmı çevrimdışıdır: gecelik belge işleme, toplu özetleme, büyük veri kümesini sınıflandırma, gömme (embedding) üretimi. Bu senaryolarda öncelik gecikme değil, verimdir; ve bu, sunum katmanını tamamen farklı ayarlamayı gerektirir.

Çevrimdışı, toplu çıkarımda kullanıcı beklemediği için ilk token gecikmesi ve streaming önemsizdir; tek önemli metrik, verilen sürede ne kadar çok iş bitirildiğidir. Bu yüzden bu iş yüklerinde batch boyutunu olabildiğince büyük tutabilir, eşzamanlılık üst sınırını yükseltebilir ve GPU'yu tam doyurabilirsin. Aynı donanım, etkileşimli bir serviste düşük gecikme için kısıtlıyken, toplu bir işte çok daha yüksek verim throughput üretir; çünkü gecikme kısıtı ortadan kalkar. Toplu işleme mantığının genel çerçevesini toplu işleme (batch processing) yazısında ele alıyoruz.

Bu ayrım, kaynak planlaması için de fırsat yaratır. Etkileşimli yükün düştüğü saatlerde (örneğin gece), aynı GPU'ları çevrimdışı toplu işlere yönlendirerek doluluğu yükseltebilir ve maliyeti tabana yayabilirsin. Olgun kurumlar, etkileşimli ve toplu iş yüklerini tek bir kaynak havuzunda akıllıca zamanlayarak GPU'yu neredeyse hiç boşta bırakmaz. Model servis etmede bu "iş yükü karması yönetimi", self-host ekonomisini iyileştiren güçlü ama sık gözden kaçan bir kaldıraçtır.

Bir model servis etme sistemini profesyonelce yönetmek, "iyi çalışıyor" gibi belirsiz bir hisle değil, net servis seviyesi hedefleriyle (SLO) mümkündür. SLO, servisin karşılaması beklenen ölçülebilir taahhüttür: örneğin "isteklerin %95'i 2 saniyenin altında yanıtlanacak" veya "aylık kullanılabilirlik %99,9 olacak". Bu hedefler, hem mühendislik kararlarını hem kapasite planlamasını yönlendirir.

SLO'lar, daha önce ele aldığımız yüzdelik gecikme metrikleriyle doğrudan bağlıdır. Bir p95 gecikme hedefi koymak, batch boyutu, eşzamanlılık sınırı ve model boyutu ayarını bu hedefe göre yapmayı zorunlu kılar. Hedef net olmadan optimizasyon körlemesine olur; hedef netse, "bu değişiklik SLO'yu iyileştiriyor mu kötüleştiriyor mu" sorusuna kanıtla cevap verebilirsin. SLO ayrıca bir bütçe aracıdır: daha katı bir gecikme hedefi daha çok GPU (ve maliyet) gerektirir; kurum, hedefi bilinçli seçerek maliyet-kalite dengesini belirler.

Kapasite planlaması, SLO'yu gelecekteki yükte de korumayı amaçlar. Bunun için tepe yükü (aynı anda beklenen en yüksek eşzamanlı istek), büyüme projeksiyonunu ve tepe/ortalama oranını kestirmen gerekir. İyi bir plan, ortalama yüke değil tepe yüke göre boyutlandırır ve otomatik ölçekleme ile tepe anlarını karşılar. Ayrıca bir güvenlik payı (headroom) bırakmak, ani yük sıçramalarında SLO'yu korur. Bu disiplin olmadan, sistem sıradan günlerde iyi çalışır ama yoğun bir günde çöker; model servis etmede güvenilirlik, tam olarak bu tepe anlarını sorunsuz atlatabilmektir. Bu operasyonel çerçevenin bütününü LLMOps nedir yazısında ele alıyoruz.

Teknik olarak sağlam bir model servis etme sistemi kurmak yeterli değildir; o servisin kurum için gerçek değer üretip üretmediğini de gösterebilmek gerekir. Aksi halde proje, "çalışıyor ama pahalı" damgası yiyip bütçe masasında düşer. Model servis etmenin iş değeri ölçülebilir ve bu ölçüm, doğru dağıtım kararını da haklı çıkarır.

Değerin ilk boyutu maliyet verimliliğidir: iyi tasarlanmış bir sunum katmanı, aynı iş yükünü çok daha az GPU ile karşılar. Batching, kuantizasyon, küçük model yönlendirme ve önbellek, token başına maliyeti kat kat düşürebilir; bu, doğrudan ölçülebilir bir tasarruftur. İkinci boyut deneyim ve dönüşümdür: düşük gecikme ve akıcı streaming, kullanıcı memnuniyetini ve ürünün benimsenmesini artırır; yavaş bir asistan terk edilir, hızlı bir asistan kullanılır. Üçüncü boyut ölçek ve dayanıklılıktır: doğru kurulmuş bir servis, yük arttığında çökmek yerine zarifçe ölçeklenir; bu, güvenilirlik ve iş sürekliliği demektir.

Bu değeri savunulabilir kılmak için bir temel çizgi (baseline) şarttır: servis öncesi token başına maliyet neydi, gecikme neydi, kaç eşzamanlı istek karşılanabiliyordu? Bu sayılar ölçülmeden, iyileştirme iddiası havada kalır. Yapay zeka projelerinde getirinin nasıl hesaplandığını yapay zeka ROI nasıl hesaplanır yazısında ele alıyoruz; aynı disiplin model servis etme için de geçerlidir. Bu yetkinliği ekiplere kazandıran eğitim çerçevesini ise kurumsal yapay zeka eğitimi nedir yazısında ele alıyoruz. Nihayetinde model servis etmenin getirisi, yalnızca teknolojiden değil, o teknolojinin doğru ölçülmesinden ve sürekli iyileştirilmesinden gelir.

Teoride model servis etmeyi anlamak kolaydır; üretimde ayakta duran bir servis kurmak zordur. Deneyimli bir gözle bakıldığında, başarısız servis projeleri benzer hatalarla düşer. En yaygınları şunlardır:

• Demoyu üretim sanmak: Tek kullanıcıyla çalışan bir prototipin, yüzlerce eşzamanlı istek altında da çalışacağını varsaymak. Demo ile üretim arasındaki uçurum, model servis etmenin asıl işidir.
• Batching'i ihmal etmek: İstekleri tek tek işleyip GPU'nun çoğunu boşa harcamak. Continuous batching olmadan verim throughput değeri düşük, maliyet yüksek kalır.
• Belleği yanlış bütçelemek: KV cache'in ne kadar yer tuttuğunu hesaba katmadan batch boyutunu büyütmek; bellek taşar ve eşzamanlı istek kapasitesi çöker.
• Yüzdelikleri değil ortalamayı izlemek: Ortalama gecikmeye bakıp p99'daki kötü deneyimi görmemek. Kuyruk gecikmesi, kullanıcı memnuniyetini belirleyen asıl metriktir.
• Streaming'i atlamak: Etkileşimli bir arayüzde tüm yanıtı bir kerede döndürüp kullanıcıyı boş ekranda bekletmek; algılanan hızı gereksiz düşürür.
• Maliyeti hesaplamadan self-host'a geçmek (veya kaçmak): API ile self-host kesişim noktasını ölçmeden karar vermek; ya yüksek hacimde API'de para yakmak ya da düşük hacimde boş GPU beslemek.
• Uyumu sonraya bırakmak: Veri ikametgahı ve KVKK kısıtlarını mimariyi kurduktan sonra eklemeye çalışmak; bu, çoğu zaman baştan yeniden tasarım gerektirir.
• İzlemesiz üretim: Sağlık kontrolü ve metrik olmadan yayına almak; sistem sessizce bozulur ve sorun ancak kullanıcı şikâyetiyle fark edilir.

Model servis etme tek başına bir hedef değildir; üzerine kurulan her gelişmiş yapay zeka uygulamasının sessiz bel kemiğidir. Bir RAG (bilgi getirimiyle üretim) sistemi, bir ajan (agent) mimarisi veya bir sohbet asistanı — hepsi, altında güvenilir bir sunum katmanı olmadan ayakta kalamaz. Bu yüzden servis kalitesi, üstündeki tüm uygulamanın kalitesini belirler.

Bu ilişki, özellikle çok adımlı sistemlerde belirginleşir. Bir ajan, tek bir soruya yanıt vermek için modeli defalarca çağırabilir; her adım, sunum katmanından bir istek daha geçer. Böyle bir sistemde tek bir çağrının gecikmesi küçük görünse de, on çağrılık bir zincirde toplam gecikme katlanır; ve eşzamanlı çok sayıda ajan çalışıyorsa, sunum katmanı üzerindeki eşzamanlı istek yükü hızla büyür. Bu yüzden ajan ve RAG sistemleri tasarlarken, model servis etme kapasitesi baştan hesaba katılmalıdır; aksi halde sistem, kullanıcı sayısı arttığında beklenmedik biçimde yavaşlar.

Pratik sonuç şudur: gelişmiş bir yapay zeka ürünü kurmak isteyen bir kurum, önce sağlam bir model servis etme temeli atmalıdır. Batching, önbellek, ölçekleme ve izleme yerinde olduğunda, üstüne kurulan RAG veya ajan katmanı hem hızlı hem ekonomik çalışır; bu temel zayıfsa, en zekice tasarlanmış uygulama bile üretimde tökezler. Model servis etme, gösterişli olmayan ama her şeyi taşıyan altyapıdır; ona yapılan yatırım, üstündeki tüm ürünlere değer olarak geri döner.

Model servis etmeyi anlamak bir şey, ilk servisini sağlam kurmak başka bir şeydir. En sık yapılan hata, "tüm iş yüklerini tek seferde en optimize altyapıya taşıyalım" gibi dev bir hedefle başlamaktır; böyle projeler kapsam altında ezilir. Doğru yaklaşım tersidir: tek, dar ve ölçülebilir bir iş yüküyle başlamak.

İyi bir pilot iş yükünün üç özelliği vardır. Birincisi darlık: tek bir kullanım senaryosu, tek bir model, net bir istek profili. Örneğin yalnızca bir iç asistan. İkincisi ölçülebilirlik: başarının bir sayıyla tanımlanabilmesi — hedef p95 gecikme, hedef eşzamanlı istek kapasitesi, token başına maliyet tavanı. Üçüncüsü gerçek yük: pilotun, gerçek kullanıcı trafiğiyle test edilmesi; çünkü bir sistem ancak gerçek eşzamanlı istek altında sınanınca gerçek davranışını gösterir.

Pilotu kurarken sıra önemlidir. Önce bir yönetilen API ile değeri hızla kanıtla; altyapı yükü taşımadan, senaryonun işe yarayıp yaramadığını gör. Değer kanıtlandıysa ve hacim/uyum gereksinimi self-host'u gerektiriyorsa, en basit self-host kurulumunu yap: tek bir inference sunucu (örneğin vLLM), continuous batching açık, temel izleme kurulu. Bu ilk kurulumun gecikme, verim ve maliyet metriklerini ölç; darboğazı (genellikle bellek veya batch ayarı) bul ve iyileştir. Ancak metrikler hedefe ulaştıktan sonra ölçeği ve kapsamı büyüt. Bu "ölç, iyileştir, sonra büyüt" döngüsü, kâğıt üzerinde iyi görünüp üretimde çöken servislerle başarılı olanları ayırır. Şirket içi altyapıya geçiyorsan donanım boyutlandırmayı on-prem LLM donanım boyutlandırma yazısında ele alıyoruz.

Model servis etme, sonunda bir denge sanatıdır: verim ile gecikme, maliyet ile kalite, kontrol ile işletme yükü arasında kurumunuza özel bir denge kurmak. Bu dengeyi doğru kurmak, hem teknik hem stratejik bir karardır ve deneyim gerektirir. Kurumunuza özel bir model servis etme mimarisi ve pilot yol haritası tasarlamak için bir danışmanlık görüşmesi ile başlayabilir, ekiplerinizin yetkinliği için kurumsal eğitim seçeneklerini inceleyebilir ve tüm kavramları öğrenme merkezinde derinleştirebilirsiniz.

Kısaca, model servis etme nedir sorusunun cevabı: eğitilmiş bir yapay zeka modelini, gerçek kullanıcı isteklerine düşük gecikme, yüksek verim ve güvenilirlikle yanıt üreten bir üretim servisine dönüştürme işidir. Bunun kalbinde bir sunum katmanı bulunur: isteği karşılayan bir inference sunucu, eşzamanlı istekleri toplu işleyen batching zamanlayıcısı, GPU belleğini ve KV cache'i yöneten bir mekanizma, yanıtı token token ileten streaming ve tüm bunları ölçen izleme.

En önemli mesaj şudur: model servis etme kalitesi çoğu zaman modelden değil, sunum katmanının tasarımından gelir. İlk büyük karar yönetilen API mi self-host mu olduğudur ve bu, performanstan önce hacim, maliyet ve KVKK/veri ikametgahı kısıtlarıyla belirlenir. İkinci büyük denge verim throughput ile gecikme arasındadır; batching, streaming, kuantizasyon, GPU tahsisi ve eşzamanlı istek yönetimi bu dengeyi kurar. Bu bileşenler yerinde olduğunda, ortalama bir model bile hızlı, ucuz ve güvenilir bir servis sunar; bozuk olduğunda ise en güçlü model bile ayakta duramaz. Temel kavramlar için LLM nedir, GPU nedir ve token nedir yazılarına, kurumunuza özel bir tasarım için ise danışmanlık ve öğrenme merkezi kaynaklarına bakabilirsiniz.