Gecikme (Latency) Nedir? Kullanıcı Deneyimine Etkisi

LLM gecikme nedir? Gecikme (latency), bir dil modeline soru gönderildiği an ile üretilen yanıtın kullanıcıya ulaştığı an arasında geçen süredir. Yapay zeka uygulamalarında bu süre yalnızca teknik bir sayı değildir; doğrudan kullanıcı algısını, güveni ve ürünün kullanılabilirliğini belirler. Bir yanıt ne kadar doğru olursa olsun, gelmesi çok uzun sürerse kullanıcı vazgeçer.

Bu rehber bir sık sorulanlar (SSS) yazısı olarak kurgulanmıştır, ama konuyu 360 derece derinleştirir: gecikme tanımı, ilk token süresi ile toplam yanıt süresi ayrımı, akış (streaming) yönteminin algıya etkisi, LLM gecikmesini artıran bileşenler, model boyutu ve önbelleklemenin rolü, kabul edilebilir eşikler ve gecikmenin doğru ölçümü (ortalama değil p95/p99 yüzdelikleri). Amaç, "yanıt neden yavaş" sorusuna yüzeysel değil, mühendislik disiplinine dayanan bir cevap vermektir. Konuyu hem kavramsal olarak (gecikme nedir, hangi parçalardan oluşur) hem de pratik olarak (nasıl ölçülür, nasıl azaltılır, hangi eşikler kabul edilebilir) ele alarak, LLM gecikme konusunda uçtan uca bir başvuru kaynağı sunmayı hedefliyoruz.

Tanım

Gecikme (Latency)

Bir dil modeline istek gönderildiği an ile yanıtın kullanıcıya ulaştığı an arasında geçen süre. LLM bağlamında gecikme iki bileşene ayrılır: ilk token süresi (TTFT) — modelin ilk kelimeyi üretmeye başlaması için geçen bekleme; ve token başına süre — sonraki kelimelerin üretim hızı. Toplam yanıt süresi bu ikisinin birleşimidir. Gecikmeyi model boyutu, girdi ve çıktı uzunluğu, önbellekleme, toplu işleme ve altyapı belirler; akış (streaming) toplam süreyi değiştirmeden kullanıcı algısını iyileştirir.

Ayrıca: latency, yanıt süresi, ilk token süresi, TTFT, LLM gecikme, gecikme süresi

Gecikmenin en kısa tanımı şudur: bir isteğin sonuç üretmesi için geçen bekleme süresi. Dil modelleri bağlamında bu, kullanıcının "gönder" dediği an ile yanıtın tamamlandığı an arasındaki süredir. Ancak LLM gecikme, klasik bir web isteğinin gecikmesinden farklı davranır ve bu farkı anlamak, geri kalan her şeyin temelidir.

Klasik bir yazılımda bir istek genellikle tek seferde işlenir: sorgu gider, sunucu hesaplar, yanıt bir bütün olarak döner. Dil modelleri ise yanıtı tek seferde değil, kelime kelime (daha doğrusu token token) üretir. Bu yüzden LLM gecikmesinde tek bir "yanıt süresi" değil, iki ayrı boyut vardır: ilk kelimenin ne zaman geldiği ve kelimelerin ne hızla aktığı. Modelin metni nasıl parçalara böldüğünü anlamak için token nedir ve tokenization yazıları iyi bir başlangıçtır.

Bir benzetme yardımcı olur. Klasik bir istek, musluğu açıp bardağın bir anda dolmasına benzer: ya boştur ya doludur. LLM yanıtı ise bir bardağın yavaşça, damla damla dolmasına benzer: ilk damlanın ne zaman düştüğü (ilk token süresi) ile bardağın dolma hızı (token başına süre) ayrı deneyimlerdir. Kullanıcı, bardağın dolmaya başladığını gördüğü an rahatlar; işte bu yüzden LLM gecikmesinde "algı" ile "ham süre" birbirinden ayrılır ve bu ayrım tasarımın kalbindedir.

Dil modelleri, yanıtı üreten bir "otoregresif" süreçle çalışır: her yeni kelimeyi, o ana kadar üretilmiş kelimelere bakarak tahmin eder. Yani ikinci kelime birinciyi, üçüncü kelime ilk ikisini bekler. Bu üretim biçiminin adına otoregresif çözümleme denir ve gecikmenin neden çıktı uzunluğuyla doğrudan büyüdüğünü açıklar. Bu mekanizmayı autoregressive decoding yazısında ele alıyoruz.

Bu tek yönlü zincir, LLM gecikmesini benzersiz kılar. Çünkü model 500 kelimelik bir yanıt üretecekse, bu 500 adımın çoğu birbirini bekler; adımları tamamen paralelleştiremezsiniz. Bir resmi aynı anda tüm pikselleriyle çizemeyip, satır satır boyamak gibidir. Sonuç olarak toplam yanıt süresi, üretilecek token sayısıyla neredeyse doğrusal büyür — çıktı ne kadar uzunsa, kullanıcı o kadar bekler.

Bu farkın pratik bir sonucu vardır: LLM gecikmesini yönetmek, klasik "sunucuyu hızlandır" refleksiyle çözülmez. Girdiyi kısaltmak, çıktı uzunluğunu sınırlamak, önbelleği devreye almak, akışı açmak ve doğru model boyutunu seçmek gibi LLM'e özgü kaldıraçlar gerekir. Bu yüzden dil modeli performansını, klasik uygulama performansından ayrı bir disiplin olarak düşünmek gerekir; temel kavramlar için LLM nedir yazısı bağlam sağlar.

LLM gecikmesini doğru anlamanın anahtarı, tek bir "yanıt süresi" yerine iki ayrı metriği görmektir. Birincisi ilk token süresidir (Time To First Token, TTFT): kullanıcı soruyu gönderdiği an ile modelin ilk kelimeyi üretmeye başladığı an arasındaki süre. İkincisi token başına süredir: model üretime başladıktan sonra her bir sonraki kelimenin ne hızla geldiği.

İlk token süresi, kullanıcının "sistem beni duydu mu" hissini belirler. İlk kelime ekranda belirene kadar kullanıcı boş ekrana bakar ve bu bekleme, süre uzadıkça huzursuzluğa dönüşür. TTFT'yi belirleyen ana etken, modelin yanıt üretmeden önce girdiyi (prompt) baştan sona okuyup işlemesidir; buna prompt işleme veya "ön dolum" denir. Girdi ne kadar uzunsa bu işleme o kadar uzar; bu yüzden uzun bağlam, ilk token süresini doğrudan artırır. Bağlamın sınırlarını context window nedir yazısında ele alıyoruz.

Token başına süre ise "ne kadar hızlı yazıyor" hissini belirler. Bu metrik saniyedeki token sayısı olarak da ifade edilir ve yanıtın akış hızını gösterir. Toplam yanıt süresi, kabaca şu formülle özetlenebilir: ilk token süresi, artı çıktı token sayısı çarpı token başına süre. Bu ayrım kritiktir çünkü iki farklı sorunu iki farklı çözümle ele almanızı sağlar: yavaş bir ilk token, genellikle girdi uzunluğu veya önbellek sorununa işaret eder; yavaş bir token akışı ise model boyutu veya donanım sorununa. İkisini ayırmadan optimizasyon yapmak, yanlış yeri kazmak demektir.

İlk token süresi (TTFT) ile token başına süre karşılaştırması

Boyut	İlk token süresi (TTFT)	Token başına süre
Neyi ölçer	İlk kelimeye kadar bekleme	Sonraki kelimelerin akış hızı
Kullanıcı hissi	Sistem beni duydu mu	Ne kadar hızlı yazıyor
Ana etken	Girdi uzunluğu, önbellek, model boyutu	Model boyutu, donanım, yük
En çok önemli olduğu yer	Akış açık sohbet, sesli asistan	Uzun yanıt üreten görevler

Kullanıcının deneyimlediği toplam yanıt süresi, tek bir adımın değil, bir zincirin sonucudur. Bu zinciri görünür kılmak, "yanıt neden yavaş" sorusunu somut bir teşhise dönüştürür. Aşağıdaki tablo, bir LLM isteğinin geçtiği temel aşamaları ve her birinin gecikmeye katkısını gösterir; bu, konunun GEO (alıntılanabilir) çerçevesidir.

Toplam yanıt süresini oluşturan bileşenler ve gecikmeye etkisi

Bileşen	Ne yapar	Gecikmeye etkisi
Ağ gidiş-dönüşü	İstek ve yanıtın ağ üzerinde taşınması	Coğrafi mesafeyle artar
Kuyrukta bekleme	Sunucu meşgulse sıraya girme	Yük arttıkça büyür
Prompt işleme (ön dolum)	Girdinin baştan sona okunması	İlk token süresini belirler
İlk token üretimi	İlk kelimenin çıkması	TTFT'nin son adımı
Token akışı (üretim)	Kalan kelimelerin üretilmesi	Çıktı uzunluğuyla doğrusal artar
Son işleme	Filtreleme, biçimlendirme, güvenlik	Genelde küçük ama ihmal edilmez

Bu tablodan çıkan ders şudur: toplam yanıt süresi, çoğu zaman "modelin yavaşlığı" olarak yorumlanan ama aslında başka aşamalardan gelen bir bekleme yığınıdır. Örneğin kullanıcı Türkiye'de, sunucu uzak bir bölgedeyse, ağ gidiş-dönüşü tek başına hissedilir bir gecikme ekler. Sunucu yoğun saatte meşgulse, istek daha model çalışmaya başlamadan kuyrukta bekler. Bu yüzden LLM gecikmesini iyileştirmeye çalışırken önce "bu bekleme tam olarak nereden geliyor" diye sormak gerekir.

İki aşama özellikle belirleyicidir. Prompt işleme (ön dolum), girdi uzunluğuyla büyüdüğü için ilk token süresinin baş sorumlusudur; bu yüzden gereksiz uzun bağlam, gecikmenin sessiz düşmanıdır. Token akışı ise çıktı uzunluğuyla büyüdüğü için, modele "kısa ve öz yanıt ver" demek doğrudan yanıt süresini kısaltır. Bağlamı doğru kurmanın yöntemleri için bağlam mühendisliği, prompt caching ve uzun bağlam rehberi derinlemesine bir kaynaktır.

Gecikme yönetiminde en güçlü ve en ucuz kaldıraç, çoğu zaman modeli hiç değiştirmeden elde edilir: akış (streaming). Akış streaming, modelin ürettiği kelimeleri, tamamının bitmesini beklemeden üretildikçe kullanıcıya göstermesidir. Bu, ham gecikmeyi değiştirmez ama kullanıcı algısını kökten dönüştürür.

Farkı somutlaştıralım. Akış streaming kapalıyken kullanıcı, yanıtın son kelimesi de üretilene kadar boş bir ekrana ya da dönen bir simgeye bakar; toplam yanıt süresi ne olursa olsun, bu bekleme "ölü zaman" gibi hissedilir ve uzun görünür. Akış streaming açıkken ise ilk kelimeler ekranda belirir belirmez kullanıcı okumaya başlar; geri kalan üretim, kullanıcı okurken arka planda devam eder ve fark edilmez. Toplam süre matematiksel olarak aynı olsa bile, algılanan gecikme belirgin biçimde düşer.

Bu yüzden akış streaming, bir performans hilesi değil, temel bir kullanıcı deneyimi tasarımıdır. İnsanlar bekleme süresini nesnel olarak değil, öznel olarak değerlendirir: bir şeyin ilerlediğini görmek, aynı süreyi çok daha kısa hissettirir. Bir yükleme çubuğunun neden var olduğunu düşünün — süreyi kısaltmaz, ama beklemeyi katlanılır kılar. Akış da LLM yanıtları için tam olarak bunu yapar ve ilk token süresini kullanıcı algısındaki en kritik metrik hâline getirir.

LLM gecikme tek bir sebepten doğmaz; birbirini besleyen birkaç bileşenin toplamıdır. Bu bileşenleri tek tek tanımak, hangi kaldıracın hangi durumda işe yarayacağını görmeyi sağlar. En belirleyici etkenler şunlardır:

• Model boyutu: Daha büyük modeller her token için daha fazla hesaplama yapar; hem ilk token süresi hem token başına süre uzar. Boyut, gecikmenin en temel belirleyicisidir.
• Girdi uzunluğu: Model, yanıt üretmeden önce tüm girdiyi okur (ön dolum). Uzun bağlam, ilk token süresini doğrudan büyütür.
• Çıktı uzunluğu: Her kelime bir üretim adımıdır; uzun yanıt, token başına süre sabit olsa bile toplam yanıt süresini uzatır.
• Önbellekleme durumu: Aynı ön ek daha önce işlendiyse (prompt/KV önbelleği), model tekrar hesaplamaz ve ilk token süresi kısalır. Önbellek devrede değilse her istek sıfırdan başlar.
• Toplu işleme (batching): Sunucu birden çok isteği bir arada işlerse verim artar ama bireysel istek biraz bekleyebilir; denge önemlidir.
• Altyapı ve donanım: İşlemci (GPU) kapasitesi, bellek ve modelin donanıma dağıtımı, üretim hızını doğrudan belirler.
• Ağ ve coğrafya: Kullanıcı ile sunucu arasındaki fiziksel mesafe, her isteğe bir taban gecikme ekler.
• Yük ve kuyruk: Yoğun saatlerde istekler sıraya girer; sistem kapasitesinin üstünde yüklenirse gecikme hızla büyür.

Bu bileşenlerin çoğu birbirini etkiler. Örneğin büyük bir modeli, uzun bir bağlamla, önbelleksiz ve uzak bir sunucuda çalıştırmak, gecikme açısından en kötü senaryodur; aynı görevi küçük bir modelle, kısa bağlamla, önbellekli ve yakın bir sunucuda çalıştırmak dramatik biçimde daha hızlıdır. LLM gecikmesini yönetmek, bu bileşenleri görevin ihtiyacına göre dengelemektir. Donanımın rolü için GPU nedir ve kurumsal ölçekte kurumsal AI için GPU yazıları arka planı verir.

Model boyutu, LLM gecikmesinin en temel belirleyicilerinden biridir ve ilişki sezgiseldir: daha çok parametre, her token için daha çok hesaplama, dolayısıyla daha uzun süre demektir. Ancak bu ilişki basit bir doğru çizgi değildir; mimari, optimizasyon ve donanım tabloyu değiştirir.

Büyük modeller genellikle daha yetenekli ama daha yavaştır; küçük modeller daha hızlı ama belirli görevlerde daha sınırlıdır. Buradaki püf noktası, "en yetenekli model her zaman en iyi seçim değildir" gerçeğidir. Basit bir sınıflandırma, kısa bir özet veya rutin bir yanıt için büyük bir modeli çağırmak, hem gecikmeyi hem maliyeti gereksiz yere artırır. Bu mantığı her iş için en pahalı LLM'i çağırmanın neden yanlış olduğu yazısında ayrıntılı ele alıyoruz.

Bu yüzden olgun sistemler tek bir model yerine bir model havuzu kullanır ve görevleri zorluk düzeyine göre yönlendirir (model routing). Basit sorular hızlı, küçük bir modele; karmaşık akıl yürütme gerektirenler yavaş, büyük bir modele gider. Böylece ortalama LLM gecikme düşer, çünkü isteklerin çoğu zaten basittir ve hızlı modelle karşılanır. Küçük modellerin yükselen rolünü küçük dil modelleri (SLM) ve fine-tuning ve genel eğilimi küçük mü büyük mü model eğilimi yazılarında değerlendiriyoruz. Bazı büyük modeller ise "uzman karışımı" (mixture of experts) gibi mimarilerle, her token için parametrelerinin yalnızca bir kısmını çalıştırarak boyut-hız dengesini iyileştirir; bu yaklaşımı mixture of experts yazısında ele alıyoruz.

LLM gecikmesinin en çok hafife alınan kaynağı girdi uzunluğudur. Model, ilk kelimesini üretmeden önce, kendisine verilen tüm girdiyi (sistem talimatı, bağlam, örnekler, kullanıcı sorusu) baştan sona okumak zorundadır. Bu okuma-işleme adımı ilk token süresini doğrudan belirler: girdi ne kadar uzunsa, kullanıcı ilk kelimeyi o kadar geç görür.

Bu, uzun bağlam pencereleri çağında özellikle önemlidir. Modellerin yüz binlerce token bağlam alabilmesi cazip görünür, ama bedava değildir: bağlama koyduğunuz her ek belge, her gereksiz talimat, her "her ihtimale karşı" eklenen örnek, ilk token süresine küçük bir vergi ekler. Bu vergiler toplanır ve yanıt süresini fark edilir biçimde büyütür. Uzun bağlam ile seçici getirme (RAG) arasındaki dengeyi RAG mı uzun bağlam penceresi mi yazısında tartışıyoruz.

Pratik sonuç açıktır: girdiyi kısa ve öz tutmak, gecikmeyi düşürmenin en doğrudan yollarından biridir. Gereksiz bağlamı ayıklamak, talimatları sadeleştirmek ve yalnızca gerçekten ilgili bilgiyi vermek hem ilk token süresini kısaltır hem maliyeti düşürür hem de çoğu zaman kaliteyi artırır (çünkü model gürültüyle boğulmaz). Bilgiyi seçerek getirmenin mimarisi için RAG nedir kapsamlı bir rehberdir; bağlamı akıllıca yönetmek, gecikme optimizasyonunun görünmeyen ama en etkili adımıdır.

Girdi ilk token süresini belirlerken, çıktı uzunluğu toplam yanıt süresini belirler. Model yanıtı otoregresif biçimde, kelime kelime ürettiği için, üretilecek her ek token toplam süreye eklenir. Yani 100 kelimelik bir yanıt ile 800 kelimelik bir yanıt arasındaki fark, doğrudan kullanıcının bekleme süresine yansır.

Bu, sık gözden kaçan bir kaldıraçtır. Bir modele "kapsamlı ve detaylı yanıt ver" demek, kaliteyi artırıyor gibi görünse de, gecikmeyi ve maliyeti sessizce şişirir. Oysa çoğu kullanıcı, uzun bir denemeyi değil, kısa ve isabetli bir yanıtı bekler. Modele beklenen yanıt uzunluğunu açıkça belirtmek (örneğin "en fazla üç cümlede özetle"), token başına süre hiç değişmese bile toplam yanıt süresini kısaltır.

Özellikle etkileşimli uygulamalarda, uzun yanıtları akışla sunmak ve gerektiğinde "devamını göster" gibi bir mekanizmayla ilerlemek, kullanıcıya kontrol verir ve algılanan gecikmeyi düşürür. Çıktı uzunluğunu bilinçli yönetmek — ne çok kısa ki eksik kalsın, ne çok uzun ki beklesin — kullanıcı deneyimi ile gecikme arasındaki dengeyi kuran ince bir ayardır. Yanıt uzunluğu, maliyet başına başarılı çıktı disiplininin de merkezindedir; bu çerçeveyi başarılı çıktı başına maliyet yazısında ele alıyoruz.

Önbellekleme, LLM gecikmesini düşürmenin en etkili tekniklerinden biridir ve birkaç farklı biçimde çalışır. Ortak fikir basittir: aynı hesaplamayı iki kez yapma. Eğer bir bilgi daha önce hesaplandıysa, onu yeniden üretmek yerine hazır sonucu kullan; bu, hem ilk token süresini hem maliyeti düşürür.

Birinci biçim, model içi anahtar-değer önbelleğidir (KV cache). Otoregresif üretim sırasında model, önceki tokenler için bir ara hesaplama tutar ve her yeni token için bunu yeniden kullanır; bu, üretimi tekrar tekrar sıfırdan başlamaktan kurtarır. Bu mekanizmayı KV cache ve daha ayrıntılı biçimde key-value cache yazılarında ele alıyoruz. İkinci biçim, prompt (ön ek) önbelleğidir: birçok istek aynı sistem talimatı veya aynı uzun bağlamla başlar; bu ortak ön ek bir kez işlenip saklanırsa, sonraki isteklerde tekrar işlenmez ve ilk token süresi belirgin biçimde kısalır. Bu tekniği prompt caching ile maliyet optimizasyonu yazısında inceliyoruz.

Üçüncü biçim, anlamsal önbelleklemedir (semantic caching): daha önce sorulmuş bir soruya benzer bir soru geldiğinde, modeli hiç çağırmadan hazır yanıtı döndürmek. Bu, tekrarlayan sorularda gecikmeyi neredeyse sıfıra indirir. Yaklaşımı semantic caching ve yönlendirme katmanındaki rolünü AI gateway ve semantik cache yazısında ele alıyoruz. Bu üç katman birlikte kullanıldığında, özellikle tekrarlı kurumsal iş yüklerinde ortalama LLM gecikme dramatik biçimde düşer.

Önbellekleme türleri ve gecikmeye etkisi

Önbellek türü	Neyi saklar	Gecikmeye etkisi
KV cache (anahtar-değer)	Üretim sırasındaki ara hesaplamalar	Token başına süreyi düşürür
Prompt/ön ek önbelleği	Ortak sistem talimatı ve bağlam	İlk token süresini kısaltır
Anlamsal önbellek (semantic)	Benzer sorulara verilmiş yanıtlar	Tekrarlı soruda gecikmeyi neredeyse sıfırlar

Sunucu tarafında gecikmeyi doğrudan etkileyen bir başka etken toplu işlemedir (batching). Fikir şudur: bir işlemci (GPU) tek bir isteği işlerken kapasitesinin çoğu boşta kalır; birden çok isteği aynı anda işlerse donanım çok daha verimli kullanılır. Ancak bu, bireysel istek ile toplam sistem verimi arasında bir gerilim yaratır.

Klasik toplu işlemede sistem, birkaç isteği toplayıp birlikte işler; bu, saniyede işlenen toplam istek sayısını (verim, throughput) artırır ama bir istek, grubun oluşmasını beklediği için biraz gecikebilir. Yani batching, verimi artırırken bireysel gecikmeyi bir miktar büyütebilir. Bu dengeyi batch processing yazısında ele alıyoruz. Modern sunum sistemleri bu gerilimi "sürekli toplu işleme" (continuous batching) ile hafifletir: yeni istekler, hâlihazırda süren üretime esnek biçimde eklenir, böylece hem yüksek verim hem düşük gecikme aynı anda elde edilebilir. Bu tekniği continuous batching yazısında inceliyoruz.

Donanım tarafında iki teknik daha gecikmeyi belirler. Birincisi paged attention: belleği daha verimli kullanarak aynı donanımda daha çok eşzamanlı isteği düşük gecikmeyle karşılamayı sağlar. İkincisi tensor parallelism: büyük bir modeli birden çok işlemciye bölerek üretim hızını artırır. Bu sunum katmanı kararlarının bütününü model servis etme seçenekleri yazısında derinleştiriyoruz; verim ve gecikme dengesi, üretim ortamında LLM gecikmesini yöneten en teknik alandır.

Gecikmeyi tartışırken çoğu zaman modelin kendisine odaklanılır, ama toplam yanıt süresinin önemli bir kısmı modelin dışındaki katmanlardan gelir. Bu katmanlar görünmez oldukları için ihmal edilir; oysa kullanıcının hissettiği gecikme, bu görünmeyen adımların toplamıdır.

Birincisi ağ mesafesidir. Kullanıcı ile modeli çalıştıran sunucu arasındaki fiziksel uzaklık, her isteğe bir taban gecikme ekler. Türkiye'deki bir kullanıcı, uzak bir kıtadaki sunucuya bağlanıyorsa, model daha çalışmaya başlamadan sırf ağ gidiş-dönüşü hissedilir bir bekleme yaratır. Bu yüzden kullanıcıya coğrafi olarak yakın bölgelerden hizmet vermek, hiçbir model değişikliği yapmadan yanıt süresini iyileştirir.

İkincisi soğuk başlangıçtır (cold start). Bir model sürekli çalışır durumda tutulmuyorsa, ilk istek geldiğinde modelin belleğe yüklenmesi gerekir ve bu ilk istek çok yavaş olur; sonraki istekler hızlıdır. Talebin dalgalı olduğu sistemlerde soğuk başlangıç, ara sıra ortaya çıkan ve kullanıcıyı şaşırtan uzun gecikmelerin sık nedenidir. Üçüncüsü kuyruk gecikmesidir: sistem kapasitesinin üstünde yüklenirse, istekler işlenmeyi beklerken sıraya girer ve gecikme hızla büyür. Bu altyapı davranışlarını izlemek için gözlemlenebilirlik şarttır; konuyu LLM gözlemlenebilirliği nedir ve üretimde LLM izleme yazılarında ele alıyoruz.

"Kaç saniye gecikme kabul edilebilir" sorusunun tek bir cevabı yoktur; eşik, görevin doğasına ve kullanıcı beklentisine bağlıdır. Aynı gecikme, bir bağlamda tamamen kabul edilebilirken başka bir bağlamda ürünü kullanılamaz kılar. Bu yüzden mutlak bir sayı yerine, göreve göre bir "gecikme bütçesi" düşünmek gerekir.

Etkileşimli sohbette kritik metrik ilk token süresidir. Kullanıcı, yanıtın "hemen" başladığını hissetmelidir; akış açıkken kısa bir ilk token süresi, uzun bir toplam yanıt süresini bile katlanılır kılar. Burada kullanıcı algısı, ham süreden daha belirleyicidir. Buna karşılık, sesli asistanlarda eşik çok daha katıdır: insan konuşmasının doğal ritmi (konuşma sırası, turn-taking) çok kısa bir sessizlik toleransına sahiptir; gecikme bu eşiği aşarsa konuşma yapay ve kesik hissedilir. Sesli sistemlerde gecikme tasarımını sesli AI ajanı, turn-taking ve latency tasarımı yazısında ayrıntılandırıyoruz.

Toplu ve arka plan işlerinde ise durum tersine döner: bir gecelik veri işleme veya toplu belge özetleme görevinde, tek bir isteğin gecikmesi neredeyse önemsizdir; orada asıl metrik verimdir (birim zamanda işlenen toplam iş). Bu spektrumu görmek, doğru mühendislik kararını verdirir: gerçek zamanlı deneyimde gecikme her şeydir, toplu işte ise verim önceliklidir.

Görev tipine göre gecikme önceliği ve kritik metrik

Kullanım senaryosu	Gecikme önceliği	Kritik metrik
Etkileşimli sohbet	Yüksek	İlk token süresi (akış açık)
Sesli asistan	Çok yüksek (katı)	Uçtan uca yanıt süresi
Kod/yazım asistanı	Orta-yüksek	İlk token + akış hızı
Arama/özet arayüzü	Orta	Toplam yanıt süresi
Toplu/arka plan işi	Düşük	Verim (throughput)

Gecikmeyi yönetmenin ilk şartı onu doğru ölçmektir ve buradaki en yaygın hata, ortalamaya güvenmektir. Ortalama yanıltıcıdır: birkaç çok hızlı istek, çok sayıda yavaş isteği maskeleyebilir ve size "her şey yolunda" yanılsaması verir. Oysa kullanıcı deneyimini belirleyen, ortalama istek değil, en yavaş istekler dilimidir.

Doğru pratik, yüzdelikleri (percentile) izlemektir. p50 (medyan), isteklerin yarısının altında kaldığı süredir ve tipik deneyimi gösterir. p95, isteklerin yüzde 95'inin altında kaldığı süredir ve "en kötü makul deneyim"i temsil eder — kullanıcıların önemli bir kısmının fiilen yaşadığı en uzun bekleme buradadır. p99 ise uç durumları, yani en talihsiz yüzde birlik dilimi gösterir. Çoğu ekip için asıl hedef metrik p95'tir, çünkü ürünün algılanan kalitesini o belirler.

Ölçümde ikinci ilke, ilk token süresini ve toplam yanıt süresini ayrı izlemektir. İkisi farklı sorunlara işaret eder: yavaş bir ilk token, genellikle girdi uzunluğu veya önbellek sorununu; yavaş bir toplam süre, çıktı uzunluğu veya model boyutu sorununu gösterir. Bu metrikleri üretim ortamında sürekli toplamak ve alarma bağlamak, bozulmaları büyümeden yakalar; kurulumu üretimde LLM izleme yazısında ele alıyoruz.

Nasıl Yapılır

LLM gecikmesini ölçmek için adım adım yaklaşım

Gecikmeyi ortalamayla değil, yüzdeliklerle ve bileşenlerine ayırarak ölçmenin pratik yolu.

1. 1

   İki metriği ayır

   İlk token süresini (TTFT) ve toplam yanıt süresini ayrı ayrı ölç; ikisi farklı sorunlara işaret eder.

2. 2

   Yüzdelikleri topla

   Ortalama yerine p50, p95 ve p99 değerlerini kaydet; hedefi çoğunlukla p95 üzerinden koy.

3. 3

   Bağlamı etiketle

   Her ölçümü model, girdi uzunluğu ve önbellek durumu gibi etiketlerle sakla ki nedeni bulabilesin.

4. 4

   Eşik ve alarm kur

   Görev tipine göre bir p95 hedefi belirle ve bu eşik aşıldığında uyarı verecek bir alarm tanımla.

5. 5

   Düzenli gözden geçir

   Model, trafik ve bağlam değiştikçe dağılımı yeniden incele; gecikme yaşayan bir metriktir.

Gecikmenin bileşenlerini anladıktan sonra, azaltma yöntemleri de netleşir: her kaldıraç, belirli bir bileşeni hedefler. Doğru yaklaşım, hepsini birden uygulamaya çalışmak değil, ölçümün gösterdiği darboğaza uygun kaldıracı seçmektir. Aşağıdaki tablo, yaygın yöntemleri ve hangi soruna çözüm olduklarını özetler.

LLM gecikmesini azaltma yöntemleri ve hedefledikleri sorun

Yöntem	Neyi hedefler	Dikkat
Akış (streaming) açmak	Algılanan gecikme	Ham süreyi değiştirmez, algıyı düzeltir
Prompt/anlamsal önbellek	İlk token süresi, tekrarlı sorular	Önbellek geçerliliği yönetilmeli
Girdiyi kısaltmak	İlk token süresi	İlgili bağlamı atmamaya dikkat
Çıktıyı sınırlamak	Toplam yanıt süresi	Yanıtı eksik bırakmamalı
Model routing (küçük model)	Model boyutu kaynaklı gecikme	Kaliteyi görev bazında doğrula
Sürekli batching / paged attention	Verim ve eşzamanlılık	Sunum katmanı uzmanlığı gerektirir
Spekülatif çözümleme	Token başına süre	Ek karmaşıklık ve doğrulama maliyeti
Yakın bölgeden sunma	Ağ kaynaklı gecikme	Altyapı ve veri yeri kısıtları

Bu yöntemlerden biri özellikle ilgi çekicidir: spekülatif çözümleme (speculative decoding). Fikir, küçük ve hızlı bir modelin birkaç tokeni önceden tahmin etmesi, büyük modelin ise bu tahminleri tek adımda doğrulamasıdır; doğru tahminler kabul edilince üretim hızlanır. Bu tekniği speculative decoding ve üretim ortamındaki uygulamasını LLM çıkarım servisi optimizasyonu yazısında ele alıyoruz. Bir başka kaldıraç kuantizasyondur: modeli daha düşük sayısal hassasiyetle çalıştırarak bellek ve hız kazancı sağlar; bedeli ve dengesi için kuantizasyon nedir yazısına bakabilirsiniz.

Pratik öncelik sırası genellikle en ucuzdan en pahalıya doğrudur: önce akışı aç (algıyı düzelt), sonra önbelleği ve girdi/çıktı disiplinini kur (ilk token ve toplam süreyi kısalt), en son model ve altyapı düzeyinde optimizasyona geç. Bu sıra, en az emekle en çok kazancı verir.

LLM gecikmesini tek başına optimize etmek yanıltıcıdır; çünkü gecikme, maliyet ve kalite birbirine bağlı üç köşeli bir üçgen oluşturur. Birini iyileştirmek çoğu zaman diğerini zorlar ve doğru tasarım, mutlak bir "en iyi" aramak yerine, göreve uygun bilinçli bir denge kurar.

İlişkileri görelim. Kaliteyi artırmak için daha büyük bir model, daha uzun bir bağlam veya daha uzun bir yanıt seçmek, gecikmeyi ve maliyeti büyütür. Gecikmeyi azaltmak için daha küçük bir model veya daha kısa bir çıktı seçmek, maliyeti düşürür ama kaliteyi zorlayabilir. Maliyeti kısmak için önbelleği ve küçük modelleri devreye almak, çoğu zaman gecikmeyi de iyileştirir — bu, üçgenin nadir "kazan-kazan" köşesidir. Bu bağı, model seçimindeki gerçek karar kriterleri açısından bağlam penceresi, gecikme, maliyet ve kalite dengesi yazısında derinlemesine ele alıyoruz.

Doğru yaklaşım, üçgenin hangi köşesinin bu görev için öncelikli olduğunu açıkça belirlemektir. Bir müşteri destek sohbetinde gecikme (ve algı) önce gelir; bir hukuki analiz aracında kalite her şeyin üstündedir; büyük ölçekli bir toplu işlemede maliyet ve verim önceliklidir. Bu önceliği baştan koymak, sonraki tüm mühendislik kararlarını netleştirir. Maliyet tarafının bütününü LLM çıkarım maliyeti optimizasyonu ve LLM maliyet optimizasyonu yazılarında ele alıyoruz.

Tek bir model çağrısının gecikmesini anlamak önemlidir, ama gerçek kurumsal sistemler nadiren tek çağrıdan oluşur. Bilgi getiren (RAG) veya çok adımlı görev yürüten (ajan) sistemlerde gecikme, tek çağrının çok ötesine geçer; çünkü her ek adım kendi gecikmesini toplama ekler.

RAG (bilgi getirimiyle üretim) mimarisinde, model yanıt üretmeden önce bir arama yapılır: soru vektöre çevrilir, ilgili belgeler getirilir, yeniden sıralanır ve modele bağlam olarak verilir. Bu getirme adımlarının her biri gecikme ekler ve getirilen bağlam uzadıkça ilk token süresi de büyür. Yani RAG, doğruluk ve dayanaklılık kazandırırken bir miktar gecikme maliyeti getirir. Bu dengeyi tasarlamak için RAG nedir rehberi temel oluşturur.

Ajan sistemlerinde ise durum daha da belirgindir. Bir ajan, tek bir yanıt üretmek yerine plan yapar, araç çağırır, sonucu değerlendirir ve gerekirse yeni bir adım atar; bu döngünün her turu ayrı bir model çağrısı ve dolayısıyla ayrı bir gecikmedir. Beş adımlı bir görev, kabaca beş yanıt süresinin toplamı kadar sürer. Bu yüzden ajan mimarilerinde gecikme yönetimi, adım sayısını gereksiz yere artırmamak, paralelleştirilebilen adımları paralel çalıştırmak ve her adımda mümkün olan en hızlı modeli kullanmakla ilgilidir. Karmaşık iş yüklerinde gecikme, tek bir metrik değil, tüm zincir boyunca yönetilen bir bütçedir.

Bu çok adımlı sistemlerde algılanan gecikmeyi yönetmenin özel bir yolu vardır: ara adımları kullanıcıya görünür kılmak. Ajan "belgeler getiriliyor", "seçenekler değerlendiriliyor" gibi ara durumları akışla gösterirse, kullanıcı toplam sürenin uzunluğuna rağmen sistemin çalıştığını hisseder ve beklemeyi tolere eder. Yani zincirin toplam yanıt süresi uzasa bile, her adımda geri bildirim vermek kullanıcı algısını korur. Ajan ve getirme sistemlerinde gecikme, hem teknik olarak (adımları azaltmak, paralelleştirmek) hem de deneyim olarak (ilerlemeyi göstermek) yönetildiğinde kabul edilebilir kalır; ikisini birlikte tasarlamak, LLM gecikme sorununu uçtan uca çözmenin anahtarıdır.

Gecikmenin en acımasız test alanı sesli ve gerçek zamanlı uygulamalardır. Metin tabanlı bir sohbette kullanıcı birkaç saniyelik beklemeyi tolere edebilirken, sesli bir asistanda aynı bekleme konuşmayı bozar; çünkü insan konuşması, doğal bir sessizlik ritmine sahiptir ve bu ritim çok kısa bir toleransla çalışır.

Sesli bir sistemde toplam gecikme, yalnızca modelin yanıt süresinden ibaret değildir; konuşmanın metne çevrilmesi (STT), modelin yanıt üretmesi ve yanıtın sese dönüştürülmesi (TTS) adımlarının tamamı zincire eklenir. Bu uçtan uca zincirin her halkası, kullanıcının hissettiği gecikmeye katkıda bulunur. Bu yüzden sesli uygulamalarda ilk token süresi kritik hâle gelir: model, ilk kelimeyi ne kadar erken üretirse, seslendirme o kadar erken başlar ve konuşma o kadar doğal akar. Bu uçtan uca tasarımı sesli AI ajanı geliştirme rehberi yazısında ayrıntılı ele alıyoruz.

Gerçek zamanlı uygulamalarda kullanıcı algısı, ham gecikmeden bile daha belirleyici olabilir. Kısa bir "düşünme" sesi, bir doğrulama tonu veya yanıtın hemen akmaya başlaması, aynı ham gecikmeyi çok daha kabul edilebilir kılar. İşte bu yüzden gerçek zamanlı sistemlerde mühendislik, yalnızca "daha hızlı" değil, "daha akıcı hissettiren" bir deneyim tasarlamakla ilgilidir; gecikme burada bir sayı değil, bir ritim meselesidir.

Gecikme ile verim (throughput), performans tartışmalarında en sık karıştırılan iki kavramdır; oysa farklı şeyleri ölçerler ve çoğu zaman birbirinin aleyhine çalışırlar. Gecikme, tek bir isteğin ne kadar sürede tamamlandığını; verim ise sistemin birim zamanda kaç isteği işleyebildiğini gösterir. Biri "bu kullanıcı ne kadar bekledi" sorusuna, diğeri "sistem saatte kaç kişiye hizmet verebiliyor" sorusuna cevap verir.

Bu ayrım pratikte kritiktir çünkü ikisini iyileştirmek çoğu zaman zıt yönlere çeker. Örneğin toplu işleme (batching), aynı anda çok isteği işleyerek verimi artırır ama tek bir isteğin gecikmesini bir miktar büyütebilir. Tersine, her isteği tek tek ve hemen işlemek gecikmeyi düşürür ama donanımı verimsiz kullanır ve toplam verimi azaltır. Bu yüzden bir sistemi "hızlı" diye nitelemek yetmez; kimin için hızlı — tek kullanıcı için mi (gecikme), yoksa tüm sistem için mi (verim) — diye sormak gerekir.

Doğru mühendislik kararı, görevin doğasına bağlıdır. Etkileşimli bir sohbet uygulamasında gecikme önceliklidir: kullanıcı beklerken verim istatistiği onu ilgilendirmez. Buna karşılık, gece çalışan bir toplu belge işleme görevinde verim önceliklidir: tek bir belgenin kaç saniyede bittiği önemsizdir, önemli olan sabaha kadar kaç belgenin bittiğidir. LLM gecikme ile verim arasındaki bu gerilimi bilinçle yönetmek, sunum katmanı tasarımının özüdür. Sürekli toplu işleme gibi modern teknikler bu gerilimi hafifletse de tamamen ortadan kaldırmaz; her zaman bir denge noktası seçmek gerekir.

Son dönemde yaygınlaşan muhakeme (reasoning) modelleri, gecikme tablosuna yeni bir boyut ekler. Bu modeller, nihai yanıtı vermeden önce görünür veya gizli bir "düşünme" adımı üretir: problemi adım adım çözer, ara sonuçlar hesaplar ve ancak ondan sonra cevabı yazar. Bu düşünme adımı, kaliteyi belirgin biçimde artırabilir ama bir bedeli vardır — üretilen ek tokenler, doğrudan yanıt süresine eklenir.

Bu, gecikme açısından önemli bir sonuç doğurur. Klasik bir modelde toplam yanıt süresi, görünür çıktının uzunluğuyla orantılıdır; muhakeme modellerinde ise kullanıcı hiç görmese bile, arka planda üretilen "düşünme" tokenleri de süreye dahildir. Yani ekranda kısa bir cevap görseniz de, model o cevaba varmak için uzun bir iç akıl yürütme yapmış olabilir ve ilk token süresi ile toplam süre buna göre uzar. Muhakeme, kaliteyi gecikmeyle takas eden bilinçli bir tercihtir.

Pratik sonuç, muhakeme modellerini her göreve değil, gerçekten çok adımlı akıl yürütme gerektiren görevlere ayırmaktır. Basit bir sınıflandırma veya kısa bir yanıt için muhakeme modelini çağırmak, gecikmeyi gereksiz yere şişirir. Doğru desen, görevin karmaşıklığına göre standart bir modelle muhakeme modeli arasında yönlendirme yapmaktır. Bu, model boyutu tartışmasının bir uzantısıdır ve doğru modeli doğru göreve yönlendirme mantığıyla birebir örtüşür. Muhakeme modellerinde LLM gecikme, kalite kazancının doğrudan bedelidir ve bu takas bilinçle yönetilmelidir.

İlk token süresi (TTFT), etkileşimli uygulamalarda kullanıcı algısının en belirleyici parçası olduğu için, onu kısaltmak çoğu zaman en yüksek getirili optimizasyondur. Neyse ki TTFT'yi düşürmenin birkaç somut ve uygulanabilir yolu vardır ve çoğu, model değiştirmeden hayata geçirilebilir.

Birincisi girdiyi kısaltmaktır. Model, ilk kelimeyi üretmeden önce tüm girdiyi okur; bu yüzden gereksiz uzun sistem talimatları, tekrarlı bağlam ve "her ihtimale karşı" eklenen örnekler doğrudan ilk token süresini büyütür. Talimatları sadeleştirmek ve yalnızca ilgili bağlamı vermek, TTFT'yi hemen düşürür. İkincisi önbelleklemedir: birçok istek aynı sistem talimatıyla başlar; bu ortak ön eki bir kez işleyip saklayan prompt önbelleği, sonraki isteklerde ilk token süresini belirgin biçimde kısaltır. Bunu prompt caching yazısında ele aldık.

Üçüncüsü altyapı ve konumdur. Modeli kullanıcıya coğrafi olarak yakın bir bölgede çalıştırmak, ağ gidiş-dönüşünü ve dolayısıyla ilk kelimeye kadar geçen süreyi kısaltır. Dördüncüsü modeli sıcak tutmaktır: sürekli talep gören bir modeli bellekte hazır bekletmek, soğuk başlangıç kaynaklı uzun ilk token sürelerini önler. Beşincisi, gerektiğinde daha küçük ve hızlı bir modele yönlendirmektir. Bu beş kaldıraç birlikte uygulandığında, kullanıcının hissettiği yanıt süresi — özellikle akış açıkken — dramatik biçimde iyileşir. TTFT'yi kısaltmak, çoğu üründe en çok fark yaratan tek optimizasyondur.

Gecikme yalnızca bir altyapı meselesi değildir; arayüz tasarımı, aynı ham gecikmeyi çok daha kabul edilebilir kılabilir. Kullanıcı algısı, beklemenin nesnel süresinden çok, o bekleme sırasında ne hissettirildiğine bağlıdır. Bu yüzden iyi bir ürün ekibi, gecikmeyi hem teknik hem tasarım düzeyinde yönetir.

En güçlü desen akıştır (streaming): yanıtı üretildikçe göstermek, beklemeyi okumaya dönüştürür ve boş ekranın yarattığı huzursuzluğu ortadan kaldırır. İkinci desen anında geri bildirimdir: kullanıcı gönder dediği an bir yazıyor göstergesi, dönen bir simge veya kısa bir onay, sistemin isteği aldığını hissettirir; bu, ilk token gelene kadar geçen boşluğu doldurur. Üçüncü desen ilerleme hissidir: uzun bir işlemde adımları göstermek (örneğin "belgeler getiriliyor", "yanıt hazırlanıyor"), aynı süreyi çok daha kısa hissettirir.

Dördüncü desen iskelet ekranlardır (skeleton): yanıt gelmeden önce yaklaşık düzeni gösteren gri bloklar, kullanıcının gözünü meşgul eder ve sabırsızlığı azaltır. Beşinci desen kademeli açımlamadır: önce kısa bir özet gösterip, ayrıntıyı isteğe bağlı sunmak, hem algılanan gecikmeyi düşürür hem kullanıcıya kontrol verir. Bu desenlerin ortak noktası şudur: hiçbiri ham gecikmeyi değiştirmez, ama hepsi kullanıcı algısını iyileştirir. Ürün deneyiminde bu tasarım katmanı, çoğu zaman birkaç yüz milisaniyelik teknik iyileştirmeden daha değerlidir; çünkü kullanıcı, saati değil, deneyimi hatırlar.

Gecikmeyi ciddiye alan ekipler, onu bir dilek olarak değil, sayısal bir hedef olarak yönetir. Bunun aracı, gecikme bütçesi ve hizmet seviyesi hedefidir (Service Level Objective, SLO): "isteklerin yüzde 95'i şu süre içinde tamamlanacak" gibi açık, ölçülebilir bir taahhüt. Bu hedef olmadan gecikme, herkesin farklı bir şey anladığı belirsiz bir kavram olarak kalır.

İyi bir gecikme SLO'su üç şeyi netleştirir. Birincisi hangi metrik: ilk token süresi mi, toplam yanıt süresi mi ölçülüyor? İkincisi hangi yüzdelik: ortalama yanıltıcı olduğu için hedef genellikle p95 veya p99 üzerinden konur. Üçüncüsü hangi koşul: hedef, tipik girdi uzunluğu ve normal yük altında mı geçerli, yoksa uç durumları da kapsıyor mu? Bu üçü belirlenmeden konan bir "hızlı olsun" hedefi, ölçülemez ve dolayısıyla yönetilemez.

Gecikme bütçesi, mühendislik kararlarını da disipline eder. Yeni bir özellik (örneğin ek bir getirme adımı veya daha büyük bir model) bütçeyi aşacaksa, o özellik ya optimize edilmeli ya da bir yerden gecikme geri kazanılmalıdır. Böylece gecikme, sonradan fark edilen bir sorun olmaktan çıkıp, tasarımın en baştan gözettiği bir kısıt hâline gelir. Bu hedefleri üretimde sürekli izlemek ve aşıldığında uyarı almak için gözlemlenebilirlik altyapısı gerekir; kurulumu LLM gözlemlenebilirliği yazısında ele alıyoruz. Ölçülebilir bir gecikme hedefi, LLM gecikme yönetimini sezgiden çıkarıp mühendisliğe taşır.

Talebi dalgalanan sistemlerde, en sinir bozucu gecikmeler çoğu zaman ortalama istekte değil, ara sıra çıkan uzun beklemelerde saklıdır ve bunların baş sorumlusu soğuk başlangıçtır (cold start). Bir model sürekli çalışır durumda tutulmuyorsa, uzun bir sessizlikten sonra gelen ilk istek, modelin belleğe yüklenmesini beklemek zorunda kalır; bu ilk istek, sonrakilerden kat kat yavaş olur. Kullanıcı açısından bu, "bazen çok hızlı, bazen çok yavaş" gibi tutarsız ve güven sarsan bir deneyime dönüşür.

Bu sorun, maliyet ile gecikme arasındaki klasik gerilimin bir yüzüdür. Modeli her zaman sıcak (hazır) tutmak, soğuk başlangıcı ortadan kaldırır ama boşta beklerken bile kaynak tüketir ve maliyeti artırır. Modeli talep olmadığında kapatmak maliyeti düşürür ama soğuk başlangıç gecikmesini geri getirir. Doğru denge, trafiğin desenine bağlıdır: sürekli ve öngörülebilir bir yük varsa modeli sıcak tutmak; seyrek ve ani bir yük varsa, ısınma süresini kabul edip bunu kullanıcıya iyi bir arayüzle yönetmek mantıklı olabilir.

Otomatik ölçekleme (autoscaling) de benzer bir gecikme kaynağı yaratır. Yük aniden arttığında sistem yeni kapasite eklemeye çalışır, ama bu yeni kapasitenin hazır olması zaman alır; bu arada gelen istekler kuyrukta birikir ve gecikme fırlar. Bu yüzden ani yük artışlarını öngörüp önden kapasite ayırmak (ön ısıtma), ölçekleme kaynaklı gecikme sıçramalarını yumuşatır. Bu davranışları görmek için soğuk başlangıç ve kuyruk metriklerini ayrı izlemek gerekir; aksi hâlde ortalama iyi görünürken, kullanıcıların bir kısmı düzenli olarak kötü deneyim yaşar.

Toplam yanıt süresinin, modelin hesaplamasından bağımsız, tamamen fiziksel bir bileşeni vardır: kullanıcı ile sunucu arasındaki mesafe. Işık hızı bile sonlu olduğu için, veri kıtalar arası gidip geldiğinde her isteğe hissedilir bir taban gecikme eklenir. Bu, hiçbir model optimizasyonuyla giderilemez; yalnızca coğrafi yerleşimle yönetilebilir.

Çözümün özü, hesaplamayı kullanıcıya yaklaştırmaktır. Modeli, kullanıcı kitlesine coğrafi olarak yakın bölgelerde çalıştırmak, ağ gidiş-dönüşünü kısaltır ve ilk token süresini doğrudan iyileştirir. Türkiye'deki kullanıcılara hizmet veren bir sistem için, uzak bir kıtadaki tek bir bölge yerine, kullanıcıya yakın bir bölgeden sunum yapmak, model hiç değişmeden yanıt süresini belirgin biçimde düşürebilir. Küresel bir kullanıcı kitlesi varsa, birden çok bölgeye dağıtım ve isteği en yakın bölgeye yönlendirme mantıklı olur.

Ancak bölgesel dağıtımın bir de veri boyutu vardır. Modeli farklı bölgelerde çalıştırmak, o bölgelerde hangi verinin işlendiği ve saklandığı sorusunu gündeme getirir; bu, KVKK ve veri egemenliği açısından dikkatle tasarlanmalıdır. Yani gecikme için "kullanıcıya yakın sun" ilkesi ile uyum için "veriyi doğru yerde tut" ilkesi arasında bir denge kurmak gerekir. Kenar yerleşimi ve bölgesel dağıtım, altyapı kaynaklı LLM gecikmesini azaltmanın en doğrudan yoludur; ama bu karar, yalnızca hız değil, uyum ve maliyet boyutlarıyla birlikte verilmelidir.

Bir sistemin gerçek gecikme davranışı, ancak yük altında ortaya çıkar. Tek bir isteğin boş bir sistemde ne kadar sürdüğü yanıltıcıdır; asıl soru, sistem gerçek trafikle dolduğunda gecikmenin nasıl davrandığıdır. Bu yüzden gecikmeyi ciddiye alan ekipler, üretime çıkmadan önce yük testi (load testing) yapar ve gecikmeyi artan eşzamanlılık altında ölçer.

İyi bir yük testi birkaç ilkeye dayanır. Birincisi gerçekçi girdi: test istekleri, gerçek kullanıcıların tipik girdi ve çıktı uzunluklarını yansıtmalıdır; çünkü kısa örneklerle yapılan test, uzun bağlamlı gerçek trafiğin gecikmesini olduğundan iyi gösterir. İkincisi artan yük: sistemi kademeli olarak yükleyip, gecikmenin hangi eşzamanlılık düzeyinde bozulmaya başladığını bulmak. Üçüncüsü doğru metrik: ortalama değil, p95 ve p99 yüzdeliklerini yük altında izlemek. Sistem, düşük yükte harika görünüp belirli bir eşiğin üstünde aniden çökebilir; bu kırılma noktasını önceden bilmek kritiktir.

Kıyaslama (benchmark) yaparken sık düşülen bir tuzak, farklı sistemleri farklı koşullarda ölçüp haksız karşılaştırma yapmaktır. Adil bir kıyaslama, aynı girdi, aynı çıktı uzunluğu ve aynı yük altında yapılır; ilk token süresi ile toplam yanıt süresi ayrı raporlanır. Bu disiplin olmadan, "şu sistem daha hızlı" iddiası havada kalır. Yük testi ve kıyaslama, LLM gecikmesini üretim öncesinde görünür kılar ve sürprizleri kullanıcı yerine ekibin yaşamasını sağlar. Bu ölçümleri üretimde sürekli izlemeye taşımak için üretimde LLM izleme yazısı yol gösterir.

Gecikme teknik bir metrik gibi görünse de, sonuçları doğrudan iş dünyasına yansır. Kullanıcılar, yavaş bir sistemi terk eder; bu, e-ticarette tamamlanmayan sepet, destekte yarıda bırakılan konuşma, üründe düşen kullanım demektir. Yanıt ne kadar doğru olursa olsun, gelmesi çok uzun sürerse değer üretmeden kaybolur. Bu yüzden gecikme, bir mühendislik ayrıntısı değil, bir iş metriğidir.

Etkisi özellikle etkileşimli ürünlerde belirgindir. Bir kullanıcı, yanıtın "hemen" başladığını hissederse konuşmaya devam eder; uzun bir sessizlikle karşılaşırsa sabırsızlanır ve çoğu zaman vazgeçer. Bu yüzden ilk token süresi ve akış streaming, yalnızca teknik tercihler değil, doğrudan dönüşüm ve memnuniyet kaldıraçlarıdır. Kullanıcı algısını iyileştirmek, çoğu zaman ürünün benimsenmesini artırmanın en ucuz yollarından biridir.

Gecikmenin iş etkisini yönetmenin yolu, onu diğer iş metrikleriyle birlikte izlemektir: gecikme ile kullanım, gecikme ile tamamlama oranı, gecikme ile memnuniyet arasındaki ilişkiyi ölçmek. Bu bağ kurulduğunda, "gecikmeyi şu kadar iyileştirirsek, kullanımda şu kadar kazanırız" gibi somut bir gerekçe çıkar ve gecikme optimizasyonu, keyfi bir mühendislik uğraşı olmaktan çıkıp bir yatırım kararına dönüşür. Maliyet ve değer boyutunu birlikte değerlendirmek için LLM maliyet optimizasyonu yazısı tamamlayıcı bir çerçeve sunar.

LLM gecikmesini teknik olarak derinlemesine anlamak için, üretimin iki farklı aşamadan geçtiğini görmek gerekir: prefill (ön dolum / girdi işleme) ve decode (üretim). Bu iki aşama farklı donanım davranışları sergiler ve bu yüzden farklı optimizasyonlara ihtiyaç duyar; ikisini ayırmadan yapılan optimizasyon, çoğu zaman yanlış yeri hedefler.

Prefill aşaması, modelin verilen girdinin tamamını bir kerede okuyup işlediği adımdır. Bu adım, tüm girdi tokenlerini paralel işleyebildiği için donanımı yoğun kullanır ve genellikle "hesaplama sınırlı"dır; yani işlemcinin ham gücü belirleyicidir. Prefill süresi girdi uzunluğuyla büyür ve doğrudan ilk token süresini oluşturur. Bu yüzden uzun bağlam, en çok prefill aşamasını ağırlaştırır; girdiyi kısaltmanın ilk token süresini neden bu kadar iyileştirdiği de buradan gelir.

Decode aşaması ise farklıdır: model, yanıtı tek tek token üreterek yazar ve her yeni token, önceki tokenlerin ara hesaplamasına (KV cache) erişmek zorundadır. Bu adım genellikle "bellek bant genişliği sınırlı"dır; yani belleğe erişim hızı, ham işlem gücünden daha belirleyici olur. Decode süresi çıktı uzunluğuyla büyür ve token başına süreyi oluşturur. İşte bu yüzden anahtar-değer önbelleği (KV cache) decode hızının kalbindedir; onsuz her yeni token için tüm geçmiş yeniden hesaplanırdı.

Bu ayrım, neden bazı optimizasyonların yalnızca bir aşamayı etkilediğini açıklar. Prompt önbelleği prefill'i hızlandırır (ilk token süresi); spekülatif çözümleme decode'u hızlandırır (token başına süre); sürekli batching ise ikisini de etkiler. Modern sunum sistemleri, prefill ve decode iş yüklerini ayrı ayrı planlayarak donanımı hem yüksek verim hem düşük gecikmeyle kullanır. Bu iki aşamayı ayrı düşünmek, LLM gecikme optimizasyonunu sezgisel tahminden mühendislik kararına dönüştüren temel içgörüdür.

Akışın (streaming) kullanıcı algısını nasıl iyileştirdiğini ele aldık; ama akışın teknik olarak nasıl teslim edildiği de gecikmeyi etkiler. Model tokenleri üretir üretmez kullanıcıya ulaştırmak, bir aktarım katmanı gerektirir: yanıtın parça parça, üretildikçe gönderilebildiği bir bağlantı. Bu katman iyi kurulmazsa, model hızlı üretse bile kullanıcı gecikme yaşayabilir.

Burada iki incelik vardır. Birincisi bağlantı kurma maliyetidir: her yeni istek için sıfırdan bir bağlantı açmak, özellikle güvenli bağlantılarda, ilk isteğe küçük ama gerçek bir gecikme ekler. Bağlantıları yeniden kullanmak (bağlantı havuzu) bu maliyeti azaltır. İkincisi arabelleğe alma (buffering) sorunudur: aradaki bir katman, modelin ürettiği tokenleri biriktirip topluca iletmeye çalışırsa, akışın tüm avantajı kaybolur — kullanıcı yine bekler. Akışın gerçekten uçtan uca çalıştığından, hiçbir ara katmanın tokenleri tutmadığından emin olmak gerekir.

Üçüncü bir etken de yeniden deneme ve zaman aşımı ayarlarıdır. Bir istek başarısız olup sessizce yeniden denenirse, kullanıcı iki isteğin toplam süresini bekler; zaman aşımı çok uzun ayarlanmışsa, kopmuş bir bağlantıda kullanıcı boşuna bekler. Bu yüzden akış açık bir sistemde, ilk token gelmezse makul bir sürede geri bildirim vermek (örneğin bir yeniden deneme veya hata mesajı), kullanıcıyı belirsiz bir beklemede bırakmaktan iyidir. Bağlantı ve aktarım katmanı, LLM gecikmesinin çoğu zaman gözden kaçan ama gerçek bir parçasıdır; model ne kadar hızlı olursa olsun, teslimat yavaşsa kullanıcı yavaşlık hisseder.

Gecikme yalnızca teknik bir optimizasyon değil, aynı zamanda bir beklenti yönetimi meselesidir. Kurumsal bir projede paydaşlar sık sık "neden anında cevap vermiyor" diye sorar; oysa dil modellerinin çalışma biçimi, klasik bir veritabanı sorgusundan farklıdır ve bu farkı açıklamak, gerçekçi beklentiler kurmanın ilk adımıdır. Gecikmeyi bir kusur gibi sunmak yerine, bir tasarım kısıtı olarak konumlandırmak, hem ekibi hem paydaşları rahatlatır.

Beklenti yönetiminin özü, doğru metriği doğru kitleye anlatmaktır. Bir yöneticiye "p99 gecikmemiz şu" demek anlam taşımayabilir; ama "kullanıcıların neredeyse tamamı yanıtın hemen akmaya başladığını görüyor" demek somut ve anlaşılırdır. Teknik ekibe ise ilk token süresi ve toplam süre ayrımını, p95 hedefini ve darboğazın nerede olduğunu net biçimde aktarmak gerekir. Aynı gerçeği farklı kitlelere farklı dille anlatmak, gecikme tartışmasını verimli kılar.

Bir başka önemli nokta, gecikme–maliyet–kalite üçgenindeki takasları paydaşlara açıkça göstermektir. "Yanıtı iki kat hızlandırabiliriz, ama bu ya daha küçük bir modele geçmeyi ya da altyapı maliyetini artırmayı gerektirir" demek, kararı teknik ekibin sırtından alıp doğru yere — iş önceliğine — taşır. Böylece gecikme, herkesin şikâyet ettiği ama kimsenin karar vermediği bir konu olmaktan çıkar. Kurumsal ölçekte bu dengeleri birlikte tasarlamak için danışmanlık sürecinde bir gecikme bütçesi ve önceliklendirme çerçevesi oluşturmak, projeyi baştan sağlam temele oturtur. Sonuçta LLM gecikme, yalnızca mühendislerin değil, ürün ve iş taraflarının da ortak sahiplendiği bir metrik olduğunda gerçekten yönetilebilir hâle gelir.

Gecikmeyi iyileştirmek, rastgele denemelerle değil, bir sıra izleyerek yapıldığında en çok kazancı verir. Doğru yol haritası, en ucuz ve en yüksek etkili adımlardan başlayıp, giderek daha teknik ve maliyetli optimizasyonlara ilerler. Bu sıra, hem emeği doğru yere yatırmayı hem de her adımın etkisini ölçerek ilerlemeyi sağlar.

İlk adım ölçmektir: ilk token süresi ile toplam yanıt süresini ayırarak, p95 ve p99 yüzdeliklerini toplamak. Ölçüm olmadan atılan her adım kördür. İkinci adım akışı açmaktır — hiçbir altyapı değişikliği gerektirmeden algılanan gecikmeyi düşüren en ucuz kazanç. Üçüncü adım girdi ve çıktı disiplinidir: gereksiz bağlamı ayıklamak ve yanıt uzunluğunu bilinçli sınırlamak. Dördüncü adım önbelleklemedir: prompt ve anlamsal önbellekle tekrarlı işleri hızlandırmak.

Beşinci adım model düzeyindedir: görevleri zorluğa göre doğru boyuttaki modele yönlendirmek ve gerektiğinde daha hızlı bir modele geçmek. Altıncı adım altyapıdır: kullanıcıya yakın bölgeden sunmak, modeli sıcak tutmak ve sunum katmanını (sürekli batching, paged attention) optimize etmek. Yedinci ve son adım, ileri tekniklerdir: spekülatif çözümleme veya kuantizasyon gibi, ek karmaşıklık pahasına token başına süreyi düşüren yöntemler. Bu sırayı izlemek, LLM gecikme optimizasyonunu dağınık bir çabadan, ölçülebilir ve tekrarlanabilir bir sürece dönüştürür. Her adımda "bu değişiklik p95'i ne kadar iyileştirdi" sorusunu sormak, yol haritasını disiplinli tutar.

Deneyimli bir gözle bakıldığında, gecikme sorunları benzer hatalardan doğar. Bu hataları önceden tanımak, çoğunu daha ortaya çıkmadan engeller. En sık görülenler şunlardır:

• Ortalamaya güvenmek: Gecikmeyi ortalamayla izlemek, yavaş isteklerin çoğunu gizler. p95 ve p99 izlenmezse, kullanıcıların yaşadığı gerçek deneyim görünmez kalır.
• Akışı hiç açmamak: Akış streaming olmadan, kısa toplam yanıt süresi bile uzun hissedilir. Bu, en ucuz iyileştirmeyi masada bırakmaktır.
• Her göreve en büyük modeli koşmak: Kaliteyi marjinal artırırken gecikmeyi ve maliyeti belirgin büyütür. Basit görevler hızlı, küçük modele yönlendirilmelidir.
• Girdiyi gereksiz şişirmek: "Her ihtimale karşı" eklenen uzun bağlam, ilk token süresini sessizce büyütür ve çoğu zaman kaliteyi de düşürür.
• Çıktı uzunluğunu sınırlamamak: Modele beklenen uzunluğu söylememek, gereksiz uzun yanıtlara ve şişen yanıt süresine yol açar.
• Önbelleği hiç kullanmamak: Tekrarlayan sistem talimatları ve sorular her seferinde sıfırdan işlenirse, kolayca kazanılabilecek hız kaybedilir.
• Soğuk başlangıcı hesaba katmamak: Dalgalı trafikte ara sıra çıkan uzun gecikmeler, çoğu zaman soğuk başlangıçtan gelir ve fark edilmezse kullanıcıyı şaşırtır.
• Gecikmeyi izlememek: Ölçülmeyen gecikme yönetilemez; bozulmalar, kullanıcı şikâyeti gelene kadar görünmez kalır.

LLM yanıtı neden yavaş olur?

Bir LLM yanıtı yavaş algılanıyorsa, gecikme genellikle iki yerden gelir. Birincisi ilk token süresidir: model, girdiyi okuyup ilk kelimeyi üretene kadar bir hazırlık yapar; girdi uzunsa, model büyükse veya sunucu meşgulse bu bekleme uzar. İkincisi token başına süredir: model yanıtı kelime kelime üretir ve çıktı uzadıkça toplam yanıt süresi büyür. Buna ağ mesafesi, soğuk başlangıç, kuyrukta bekleme ve önbelleğin devrede olmaması gibi altyapı etkenleri eklenir. Kısacası LLM gecikme tek bir sebepten değil, birbirini besleyen bileşenler zincirinden doğar.

İlk token süresi (TTFT) nedir?

İlk token süresi, kullanıcının soruyu gönderdiği an ile modelin ilk kelimeyi üretmeye başladığı an arasındaki süredir. Bu süre, kullanıcının "sistem beni duydu mu" hissini doğrudan belirler; çünkü ilk kelime ekranda belirene kadar kullanıcı boş ekrana bakar. TTFT'yi girdi uzunluğu, model boyutu, önbellekleme ve sunucu yükü etkiler. Akış açıkken ilk token süresi, algılanan gecikmenin en kritik parçası hâline gelir; çünkü token başına süre ne olursa olsun, kullanıcı ilk kelimeyi ne kadar erken görürse deneyim o kadar iyi hisseder.

Akış (streaming) neden bu kadar fark yaratır?

Akış streaming, modelin ürettiği kelimeleri tamamının bitmesini beklemeden, üretildikçe kullanıcıya göstermesidir. Fark ham hızda değil kullanıcı algısındadır: akış kapalıyken kullanıcı tüm yanıt bitene kadar boş ekrana bakar ve bu bekleme uzun hissedilir; akış açıkken ilk kelimeler saniyeler içinde görünür ve kullanıcı okumaya başlar, böylece geri kalan üretim süresi gizlenmiş olur. Toplam yanıt süresi aynı kalsa bile algılanan gecikme belirgin biçimde düşer. Bu yüzden akış streaming, gecikmeyi teknik olarak azaltmadan kullanıcı deneyimini iyileştirmenin en etkili yoludur.

Gecikme ortalamayla mı yoksa yüzdelikle mi ölçülür?

Gecikme yüzdeliklerle ölçülmelidir. Ortalama yanıltıcıdır çünkü birkaç çok hızlı istek, çok sayıda yavaş isteği maskeleyebilir. Doğru pratik p50, p95 ve p99 değerlerini birlikte izlemektir: p95, isteklerin yüzde 95'inin altında kaldığı süredir ve tipik "en kötü makul deneyim"i temsil eder; p99 uç durumları gösterir. Ayrıca ilk token süresi ile toplam yanıt süresi ayrı ölçülmelidir, çünkü ikisi farklı sorunlara işaret eder. Kullanıcı deneyimini ortalama değil, en yavaş yüzde beşlik dilim belirler.

Model boyutu gecikmeyi nasıl etkiler?

Genel kural olarak daha büyük modeller daha yavaştır: her token için daha fazla hesaplama yapılır, hem ilk token süresi hem token başına süre uzar. Ancak ilişki doğrusal değildir; altyapı, optimizasyon ve donanım bunu değiştirir. Küçük ve orta boy modeller çoğu rutin görevi düşük gecikmeyle karşılarken, büyük modeller yalnızca gerçekten gereken karmaşık görevlere ayrılabilir. Yaygın bir desen, görevleri zorluk düzeyine göre farklı boyuttaki modellere yönlendirmektir; böylece ortalama LLM gecikme düşerken kalite korunur.

Kabul edilebilir gecikme sınırı nedir?

Tek bir evrensel sayı yoktur; eşik göreve ve kullanıcı beklentisine bağlıdır. Etkileşimli sohbette kritik olan ilk token süresidir; akış açıkken kısa bir TTFT genellikle yeterlidir. Sesli asistanlarda eşik çok daha katıdır, çünkü konuşma sırası doğal ritmi bozacak kadar gecikme kaldırmaz. Arka planda çalışan toplu işlerde ise gecikme neredeyse önemsizdir; orada verim önceliklidir. Doğru yaklaşım, mutlak bir hedef koymak yerine görevin doğasına göre bir bütçe belirlemek ve bunu p95 üzerinden izlemektir.

Kısaca özetlersek, LLM gecikme, bir dil modeline soru gönderildiği an ile yanıtın kullanıcıya ulaştığı an arasında geçen süredir ve iki temel parçadan oluşur: ilk token süresi (TTFT) — ilk kelimeye kadar bekleme; ve token başına süre — sonraki kelimelerin akış hızı. Toplam yanıt süresi bu ikisinin birleşimidir ve model boyutu, girdi/çıktı uzunluğu, önbellekleme, toplu işleme ve altyapı tarafından belirlenir. Akış (streaming), toplam süreyi değiştirmeden kullanıcı algısını iyileştirir; bu yüzden algılanan gecikme, çoğu zaman ham gecikmeden daha önemlidir.

En önemli mesaj şudur: gecikme tek bir sayı değil, yönetilmesi gereken bir dağılımdır. Onu ortalamayla değil p95 ve p99 yüzdeliklerle ölçün; ilk token süresi ile toplam süreyi ayırın; ve gecikme–maliyet–kalite üçgeninde her görev için hangi köşeyi koruyacağınızı bilinçle seçin.

Uygulamada izlenecek sıra da nettir: önce ölçün, sonra akışı açarak kullanıcı algısını iyileştirin, ardından girdi ve çıktı disiplini ile önbelleklemeyi kurun, en son model ve altyapı düzeyinde optimize edin. Bu adımların çoğu, en pahalı modeli seçmekle değil, boru hattını doğru tasarlamakla ilgilidir; tıpkı yanıt kalitesinin çoğu zaman modelden değil, verinin ve bağlamın kalitesinden gelmesi gibi. Gecikmeyi bir kez kurup unutulan bir ayar değil, ürün yaşadıkça ölçülen ve iyileştirilen yaşayan bir metrik olarak görmek, LLM gecikme yönetiminin özüdür. Hızlı hissettiren bir ürün, çoğu zaman doğru cevabı biraz daha erken veren değil, kullanıcıya beklediğini hiç hissettirmeyen üründür. Temel kavramlar için LLM nedir, context window nedir ve token nedir yazıları iyi bir zemin sunar. Performans, gecikme ve maliyet konularında düzenli, uygulanabilir içerikleri kaçırmamak için bültene katılabilir, kurumsal ölçekte yardım için danışmanlık seçeneklerini değerlendirebilir ve tüm kavramları öğrenme merkezinde derinleştirebilirsiniz.