Üretimdeki bir LLM uygulaması nadiren daha önce hiç sorulmamış bir soruyla karşılaşıyor. Destek asistanları ve belge tabanlı sistemler aynı niyeti günde binlerce kez, her seferinde farklı kelimelerle karşılıyor.
Çoğu yığın bu tekrarları yeni ve tam ücretli istek olarak işliyor. Oysa maliyet iki ayrı yerde birikiyor ve bu iki yerin çözümü de farklı.
Bu rehber iki önbellek katmanını ayırıyor: biri çağrıyı ucuzlatıyor, diğeri çağrıyı tamamen ortadan kaldırıyor. Hangisinin hangi yükte işe yaradığı, sırayla kurulduğunda ne kadar tasarruf ettiği ve nerede durmak gerektiği aşağıda.
İki farklı önbellek, iki farklı tasarruf
Aradaki fark tek cümleyle özetlenebiliyor: önek önbelleği isabeti daha ucuz bir üretim çağrısı demek, engellenmiş bir çağrı değil. Anlamsal önbellek isabeti ise modele hiç gidilmemesi demek.
Bu ayrım maliyet hesabının tamamını belirliyor. Birinci katman gecikmeyi ve işlenen jeton sayısını azaltıyor; ikinci katman isteğin kendisini ortadan kaldırıyor.
- Önek önbelleği: istemin sabit başlangıcının hesaplanmış hâlini saklıyor, model yine çalışıyor.
- Önek farkında yönlendirme: aynı başlangıcı taşıyan istekleri aynı makineye göndererek bu önbelleğin ısınmasını sağlıyor.
- Anlamsal önbellek: anlamı eşleşen bir soru daha önce yanıtlandıysa yanıtı doğrudan döndürüyor.
- Üçü birlikte: katmanlar birbirinin yerine değil, arka arkaya çalışıyor.
- Sıra önemli: anlamsal katman isabet vermezse istek zaten önek önbelleğine düşüyor.
Önek önbelleği ne yapıyor
Bir LLM uygulamasında modele gönderilen istem genellikle iki parçadan oluşuyor: bağlamı kuran sabit bir bölüm ve asıl kullanıcı girdisini taşıyan değişken bir bölüm.
| Parça | Örnek | Tipik boyut |
|---|---|---|
| Sabit bölüm | Talimatlar, politika metinleri, konuşma geçmişi | 3.000 jeton |
| Değişken bölüm | Kullanıcının yazdığı soru | 50 jeton |
| Sonuç | Aynı 3.000 jeton her istekte yeniden işleniyor | istek başına |
vLLM ve TensorRT-LLM gibi sunum çerçevelerinin buna bir çözümü var. Daha önce görülmüş istem önekleri için hesaplanan anahtar-değer çiftlerini saklıyorlar. Aynı başlangıç yeni bir istekte göründüğünde model o hesabı yeniden kullanıyor ve yalnızca sondaki yeni jetonları işliyor.
Buna önek önbelleği deniyor ve ilk jetona kadar geçen süreyi belirgin biçimde düşürebiliyor. Tek bir makinede çalışırken beklendiği gibi işliyor.
Bir örnekle somutlaştırmak kolay. Bir müşteri hizmetleri botunda her istek aynı metin bloğuyla başlıyor: "AnyCompany için destek temsilcisisin, politikalarımız şunlar…" Ardından müşterinin yazdığı cümle geliyor. Baştaki talimatlar 3.000 jeton tutuyorsa, yüzlerce istek boyunca model aynı 3.000 jetonu tekrar tekrar işliyor demektir.
Ölçek sorunu: filo önbelleği dağıtıyor
Tek makineden çıkıp bir uç noktanın arkasına makine filosu koyduğunuzda mekanizma bozuluyor. İstekler bütün makinelere dağıtılıyor.
- Aynı 3.000 jetonluk önek bir istekte A makinesine, sonrakinde B'ye, ardından C'ye düşüyor.
- Hiçbir makine o öneki güvenilir bir önbellek kuracak sıklıkta görmüyor.
- Önbellek özelliği açık duruyor ama yönlendirme katmanı istekleri fazla inceye yaydığı için işe yaramıyor.
Yani sorun önbellekte değil, isteklerin nasıl dağıtıldığında. Özellik çalışıyor, sadece hiçbir zaman ısınmaya fırsat bulamıyor. Üstelik filo büyüdükçe durum kötüleşiyor: makine sayısı arttıkça aynı öneki aynı makinede yakalama ihtimali düşüyor.
Önek farkında yönlendirme
Amazon SageMaker Inference bu noktaya önek farkında yönlendirme adıyla bir strateji ekledi. Uç noktaya gelen isteğin başlangıcına bakıp aynı başlangıcı taşıyanları tutarlı biçimde aynı makineye gönderiyor.
- On istek aynı öneki paylaşıyorsa onu da aynı makineye gidiyor ve o makinenin önbelleği sıcak kalıyor.
- Farklı başlangıçlar farklı makinelere dağılıyor, yük dengesi bozulmuyor.
- İstekleri etiketlemeniz ya da yakınlık kuralını kendiniz yönetmeniz gerekmiyor.
- Llama 3.1 70B kıyaslamasında KV önbellek isabet oranı yaklaşık %25'ten %80'in üzerine çıktı.
Aynı kıyaslamada P50 ilk jeton süresi %77'ye kadar düştü ve iş hacmi %16'ya kadar arttı. Bunlar dikkate değer rakamlar, ancak hâlâ bir üretim çağrısını ucuzlatmaktan bahsediyoruz. Kendi altyapısında vLLM çalıştıran bir ekip için de ders aynı: önbelleği açmak yetmiyor, yönlendirmeyi de ona göre kurmak gerekiyor.
Buradaki kazanç gerçek ama sınırı da net. İstek yine modele ulaşıyor, yeni jetonlar yine işleniyor ve yanıtın tamamı yine çözülüyor. Önek önbelleği isabeti, faturayı sıfırlayan değil küçülten bir şey.
Anlamsal önbellek: çağrıyı hiç yapmamak
İkinci katman farklı bir soruya cevap veriyor. Bir destek asistanına gelen şu üç isteği düşünün: "Aylık planı aldıktan sonra iade alabilir miyim?", "Aylık abonelik iade edilebilir mi?", "Planı iptal edip paramı geri alabilir miyim?"
Kelimeler farklı ama soru da cevap da aynı. Anlamsal önbellek olmadan bu üç ifadenin her biri tam bir üretim tetikliyor: girdi jetonları işleniyor, çıktı jetonları çözülüyor, kullanıcı bekliyor.
Redis'in LangCache servisi bu katmanı yönetilen bir hizmet olarak sunuyor. Uygulama ile model arasında duruyor, gelen istemleri metin olarak değil anlam olarak daha önce yanıtlanmışlarla eşleştiriyor ve yeterince yakın bir eşleşme varsa saklanan yanıtı döndürüyor. Şirket API maliyetinde %90'a varan tasarruf ve isabet durumunda 15 kata kadar hızlı yanıt bildiriyor.
İki çağrılık döngü
Mimari basit ve uygulama tarafında iki çağrıya iniyor.
- Modeli çağırmadan önce istem arama uç noktasına gönderiliyor; servis bir gömme üretip saklanan kayıtlar üzerinde vektör araması yapıyor.
- Anlamca benzer bir kayıt ayarlanan eşiği geçiyorsa saklanan yanıt dönüyor ve model hiç çağrılmıyor.
- Isabetsizlik durumunda uygulama kendi seçtiği modeli normal şekilde çağırıyor.
- Ardından istem ve yeni yanıt kayıt uç noktasına yazılıyor, böylece sonraki eşleşmeler için havuza giriyor.
Gömme üretimini servis üstleniyor; varsayılan modellerle çalışabildiği gibi kendi modelinizi de getirebiliyorsunuz. Servis şu an Redis Cloud üzerinde açık ön izlemede, REST API ile erişiliyor ve Python ile JavaScript istemcileri var. Ön izleme olduğu için davranışın değişebileceği not düşülmüş.
Ölçüm noktaları
Bu iki katmanın işe yarayıp yaramadığını gösteren rakamlar da farklı. Birini diğerinin ölçütüyle değerlendirmek, kazancı olduğundan büyük ya da küçük gösteriyor.
- Önek önbelleği için: KV önbellek isabet oranı ve P50 ilk jeton süresi. İsabet oranı düşükse yönlendirme sorunu var demektir.
- Anlamsal önbellek için: isabet oranı ve engellenen çağrı sayısı. Fatura kalemi doğrudan bu ikinciye bağlı.
- Ortak ölçüt: istek başına toplam maliyet. Katmanları eklerken bu tek rakamın nasıl hareket ettiğine bakın.
- Gözden kaçan kalem: gömme üretiminin maliyeti. Düşük isabet oranında bu kalem tasarrufu yiyebiliyor.
Ölçümü katman katman yapmak da önemli. İkisini aynı hafta açarsanız hangi kazancın nereden geldiğini ayıramıyorsunuz ve bir sonraki ayarlamayı körlemesine yapmak zorunda kalıyorsunuz.
Benzerlik eşiği nerede ayarlanır
Anlamsal önbelleğin tek gerçek riski yanlış isabet: benzer görünen ama aslında farklı olan bir soruya eski yanıtı döndürmek. Bu riski yöneten şey benzerlik eşiği.
Eşik yüksek tutulduğunda isabet oranı düşüyor ve tasarruf azalıyor; düşük tutulduğunda yanlış yanıt ihtimali artıyor. Servis bunun yanında yaşam süresi ve tahliye politikaları ile kesinlik ve duyarlılığı ayarlayan uyarlanabilir kontroller sunuyor. Pratikte doğru yol, eşiği yüksekten başlatıp kaydedilen isabetleri elle okuyarak aşağı indirmek.
Eşiği ayarlarken soru tiplerini ayırmak da işe yarıyor. Politika ve tanım soruları geniş bir eşiği kaldırabiliyor, çünkü cevap zamanla değişmiyor. Hesap durumu ya da fiyat gibi kişiye ve ana bağlı sorularda ise anlamsal önbellek baştan kapatılmalı; oradaki doğru yanıt dünkü yanıt değil.
Hangi yükte hangisi
İki katman farklı desenlerde kazandırıyor. Önek önbelleği, uzun ve sabit bir sistem istemi olan her uygulamada işe yarıyor; sorular birbirine hiç benzemese bile.
Anlamsal önbellek ise ancak sorular tekrar ediyorsa değer üretiyor. Destek asistanı, sık sorulan sorular ve belge tabanlı arama bu tanıma giriyor. Her isteği benzersiz olan bir kod üretme aracında ise neredeyse hiç isabet alamazsınız ve eklenen gömme maliyeti zarara dönüşür.
Türkçe yükte küçük bir ek not gerekiyor. Anlamsal eşleştirme gömme modelinin dili ne kadar iyi temsil ettiğine bağlı ve çok dilli modellerin Türkçedeki ayrımı İngilizcedeki kadar keskin olmayabiliyor. Eşiği İngilizce için bulduğunuz değerle Türkçeye taşımak, sessizce yanlış isabete yol açabilir.
Nerede durmalı
Önce ölçüm. Uygulamanızın günlüklerinden gelen isteklerin ne kadarının anlamca tekrar olduğunu çıkarmadan anlamsal önbellek kurmak, çözümü sorundan önce seçmek demek.
Sıra da önemli: önce sabit istemi düzenleyip önek önbelleğinden yararlanır hâle getirin, filo büyükse yönlendirmeyi buna uygun kurun, ancak ondan sonra anlamsal katmanı ekleyin. Tersten gidildiğinde ikinci katman birinci katmanın hiç çözülmemiş problemini gizliyor ve fatura beklediğiniz kadar düşmüyor. Önbellek, kötü kurulmuş bir istemi ya da gereksiz uzun bir bağlamı da aynı sadakatle saklıyor; asıl tasarruf çoğu zaman o metni kısaltmakla başlıyor.