LLM uygulamalarında gecikmeyi ölçmek ve adım adım azaltmak

Gecikme tek bir sayı değildir: ilk token ve toplam süre

Kullanıcının hissettiği bekleme birkaç ayrı süreden oluşur. İsteğin sunucuya ulaşması, kuyrukta sıra beklemesi ve modelin girdiyi işlemesi ilk aşamadır; ekranda ilk karakterin belirmesine kadar geçen bu süreye ilk token süresi denir. Sonrasında model cevabı parça parça üretir ve burada belirleyici olan token başına süre ile cevabın uzunluğudur. Toplam bekleme, bu aşamaların toplamıdır.

Ayrım önemlidir, çünkü her aşamanın ilacı farklıdır. Girdi çok uzunsa ilk token geç gelir; cevap çok uzunsa üretim uzar. Sohbet arayüzünde kullanıcı ilk sözcüğü hızlı görürse bekleme algısı belirgin biçimde düşer. Arka planda rapor üreten bir iş akışında ise yalnızca toplam süre önemlidir. Bu yüzden optimizasyona başlamadan önce uygulamanın kullanım biçimini yaz: etkileşimli sohbet mi, sesli asistan mı, toplu belge işleme mi?

Ortalama süreye değil, en yavaş isteklere bak. Kullanıcılar ortalamayı değil, takıldıkları o yavaş isteği hatırlar. Bu nedenle ölçümde ortalamanın yanında kuyruk gecikmesini, yani en yavaş isteklerin içinde bulunduğu üst yüzdelik dilimi de izle.

Önce ölç: süre hangi halkada harcanıyor?

Gecikme optimizasyonunun en sık yapılan hatası, ölçmeden model değiştirmeye kalkmaktır. Gerçek bir LLM uygulaması çoğu zaman tek model çağrısından ibaret değildir: kullanıcı sorusu yeniden yazılır, vektör veritabanında arama yapılır, bulunan parçalar sıralanır, istem birleştirilir, model çağrılır, çıktı denetlenir ve belki bir dış araç çağrılır. Her halkanın süresini ayrı kaydet.

Basit bir ölçüm iskeleti şöyle görünür:

başla = zaman() arama_sonucu = ara(soru) arama_bitti = zaman() ilk_parca = model_akisi_baslat(istem) ilk_token_geldi = zaman() cevap_tamamlandi = zaman()

Bu ara değerlerden arama süresi, ilk token süresi ve üretim süresi ayrı ayrı çıkarılır. Hangisi baskınsa çalışmaya oradan başla. Arama adımı süreyi yutuyorsa modeli hızlandırmak sonucu değiştirmez; üretim süresi baskınsa istemi kısaltmak etki etmez.

Ölçüm yaparken gerçek kullanıcı sorularına benzeyen bir örnek küme kullan. Kısa selamlama soruları ile uzun belgeye dayalı sorular çok farklı davranır. Kümeyi kısa, orta ve uzun girdi grupları olarak ayır ve her grup için sonuçları ayrı oku.

Girdiyi küçült: istem, bağlam ve arama adımı

Modelin işleyeceği metin ne kadar uzunsa ilk token o kadar geç gelir. Girdiyi küçültmenin yolları somuttur:

• Sistem istemindeki tekrarları, kullanılmayan kuralları ve eski denemelerden kalan açıklamaları temizle. Her cümle her istekte yeniden işlenir.
• Arama ile getirilen parça sayısını ve parça boyunu gözden geçir. Soruyla gerçekten ilgili birkaç parça, uzun bir yığından çoğu zaman daha iyi sonuç ve daha kısa bekleme verir.
• Sohbet geçmişini olduğu gibi taşıma. Eski turları özetle, yalnızca gerekli olanları tut.
• Sabit kısımları (kurallar, örnekler, belge başlıkları) istemin başına, değişen kısımları (kullanıcı sorusu, getirilen parçalar) sonuna yaz. Çoğu servis, istemin değişmeyen ön ekini yeniden işlememek için önbellek sunar; bunun işlemesi için sıralamanın tutarlı olması gerekir.
• Örnekleri (few-shot) sayıca azalt ve kısalt; çoğu zaman çalışan birkaç örnek yeterlidir.

Bu adımlar kaliteyi korumak koşuluyla yapılmalıdır. Her kısaltmadan sonra aynı değerlendirme kümesini yeniden koştur; cevap kalitesi düştüyse kısaltmayı geri al. Hız ile kalite arasındaki dengeyi sezgiyle değil, ölçümle kur.

Çıktıyı kısalt ve akıt

Üretim süresi cevabın uzunluğuyla doğrudan orantılıdır; model her token'ı sırayla üretir. En ucuz hız kazancı çoğu zaman cevabı kısaltmaktır. İstemde beklenen biçimi açıkça belirt: kısa özet mi, madde listesi mi, tek cümle mi? Gereksiz giriş cümlelerini, tekrar eden özetleri ve kullanıcının istemediği açıklamaları yasakla. Çıktı için bir üst sınır belirle; sınırı çok düşük tutarsan cevap yarıda kesilir, bu yüzden sınırı gerçek cevap uzunluklarına bakarak seç.

Yapılandırılmış çıktıda (JSON gibi) alan adlarını kısa tut ve yalnızca kullanılacak alanları iste. Model kullanıcıya gösterilmeyecek alanları da üretiyorsa bu süre boşa gider.

Akış (streaming) toplam süreyi kısaltmaz ama algılanan beklemeyi büyük ölçüde düşürür. Cevap tamamlanmadan ekrana yazılmaya başlar ve kullanıcı okurken geri kalanı gelir. Akış kullanırken şu noktaları düşün: çıktı denetimi (güvenlik süzgeci, biçim doğrulama) akışla birlikte nasıl çalışacak, ve arayüz tamamlanmamış cevabı nasıl gösterecek. Sesli uygulamalarda ise cümle bittikçe konuşmaya başlamak, bütün cevabı beklemekten çok daha doğal bir deneyim verir.

Model tarafı: boyut, nicemleme, toplu işleme ve önbellek

Girdi ve çıktı toparlandıktan sonra modelin kendisine bakmak mantıklıdır. Bu bölümdeki seçeneklerin çoğu, modeli kendi altyapında çalıştırıyorsan geçerlidir; hazır bir servis kullanıyorsan elinde daha az ayar bulunur.

• Daha küçük model: Her isteğin büyük modele gitmesi gerekmez. Sınıflandırma, yönlendirme, kısa özet gibi basit işleri küçük bir modele ver; yalnızca zor soruları büyük modele yönlendir. Bu, hem gecikmeyi hem maliyeti düşürür.
• Nicemleme (quantization): Model ağırlıklarını daha düşük hassasiyetle tutarak bellek kullanımını ve çoğu durumda üretim hızını iyileştirir. Kalitedeki küçük kayıpları kendi değerlendirme kümende ölç.
• Toplu işleme: Sunucu aynı anda gelen istekleri birlikte işleyebilir. Burada verim (throughput) ile tek istek gecikmesi arasında denge vardır: grup büyüdükçe toplam iş artar ama tek tek isteğin beklemesi uzayabilir.
• Çıkarım önbelleği: Model, önceki token'lar için hesapladığı ara değerleri saklar; böylece her yeni token için baştan hesap yapmaz. Bellek yetersizse bu önbellek kısıtlanır ve hız düşer.
• Tahmini çözümleme (speculative decoding): Küçük bir model taslak token'lar önerir, büyük model bunları toplu doğrular. Uygun kurulumda üretimi hızlandırır; ancak kurulum ve ayar bilgisi ister.
• Donanım ve servis çerçevesi: Aynı model, farklı bir çıkarım çerçevesinde ve uygun donanımda belirgin biçimde farklı hızlarda çalışabilir.

Mimari hamleler: paralellik, yönlendirme ve eşzamansızlık

Bazen en büyük kazanç model ayarında değil, iş akışının şeklindedir.

• Birbirine bağımlı olmayan çağrıları paralel çalıştır. Örneğin aynı soru için hem belge araması hem kullanıcı profili sorgusu gerekiyorsa bunları arka arkaya değil aynı anda başlat.
• Zincirleme model çağrılarını sorgula. Her adım için ayrı bir model çağrısı yapan bir akış, bazı adımlar birleştirilebiliyorsa gereksiz yere uzamıştır.
• Sık tekrar eden sorulara anlamsal önbellek uygula: yeni soru, önceden cevaplanmış bir soruya yeterince benziyorsa cevabı yeniden üretmek yerine saklanandan dön. Bunun riski, benzer görünen ama farklı anlam taşıyan sorulara yanlış cevap vermektir; bu yüzden benzerlik eşiğini dikkatle seç ve hassas konularda kullanma.
• Uzun süren işleri eşzamansız yap. Kullanıcıdan hemen yanıt beklemeyen işlerde (rapor üretimi, toplu belge analizi) isteği kuyruğa al, bittiğinde bildir.
• Zaman aşımı ve yeniden deneme politikası koy. Takılan bir çağrı bütün isteği kilitlememeli; bir noktadan sonra yedek model ya da kısa bir yedek cevapla devam edilmelidir.
• Sunucuya yakın bölge seçmek ve bağlantıyı açık tutmak, küçük görünse de her istekte biriken ağ gecikmesini azaltır.

Örnek senaryo: yavaş cevap veren kurumsal bilgi asistanı

Örneğin bir şirketin iç politika sorularını yanıtlayan asistanı düşün. Kullanıcılar cevabın geç geldiğinden yakınıyor. Ölçüm yapıldığında şu tablo çıkıyor: arama adımı hızlı, model çağrısı ise ilk token'ı geç veriyor. Nedenini ararken istem incelendiğinde her isteğe uzun bir politika özeti ve geniş sohbet geçmişi eklendiği görülüyor.

Uygulanan adımlar sırayla şöyle olabilir: önce sohbet geçmişi özetlenir ve arama sonucunda dönen parça sayısı azaltılır. Sabit kurallar istemin başına taşınır ve önbellekten yararlanılır. Ardından cevap biçimi netleştirilir: önce kısa cevap, ardından yalnızca gerekirse ayrıntı. Son olarak akış açılır. Her adımdan sonra aynı soru kümesi yeniden koşturulur; ilk token süresi, toplam süre ve cevap kalitesi karşılaştırılır.

Bu örnekte model hiç değişmemiştir, ama kullanıcı deneyimi belirgin biçimde iyileşmiştir. Sıra önemlidir: önce ölç, sonra en ucuz ve en az riskli müdahaleden başla, kalite ölçümüyle doğrula. Model değişikliği ya da donanım yatırımı en sona kalır, çünkü en pahalı ve en riskli adımdır.

Sık hatalar ve öğrenme yolu

Sık yapılan hatalar şunlardır: ölçmeden varsayımla hareket etmek; kaliteyi ölçmeden istemi kısaltmak; ortalamaya bakıp kuyruk gecikmesini göz ardı etmek; hız artsın diye çıktı sınırını aşırı düşürüp cevapları eksik bırakmak; anlamsal önbelleği hassas konularda denetimsiz kullanmak; akışı açıp çıktı denetimini unutmak.

Öğrenme yolu için başlangıç düzeyinde LLM'in token mantığını, istem yapısını ve ölçüm kavramlarını öğren. Orta düzeyde akış, önbellek, yönlendirme ve değerlendirme kümesi kurma becerisi edinirsin. İleri düzeyde çıkarım sunucusu ayarı, nicemleme, toplu işleme ve çok GPU dağıtımı gibi konulara geçilir.

Mindset kataloğunda bu alana yakın programlar öne çıkar. LLM Performans Optimizasyonu programının modülleri arasında çıkarım optimizasyon teknikleri, çıkarım mimarisi ve performans ölçümü, üretim ortamında servis ve nicemleme yer alır; bu program model sunan ve altyapıyı yöneten mühendislik ekiplerine hitap eder. LLM Maliyet Optimizasyonu programı ise model büyüklüğü, yönlendirme stratejileri, önbellek ve istem sıkıştırma modüllerini içerir; ürün sahipleri ve geliştirici ekipler için, hız ve maliyet dengesini birlikte kurmak isteyen takımlara uygundur.