Sunum katmanını hızlandırmak: toplu işlem ve önbellek

Bir isteğin ömrü üç parçadan oluşur: kuyrukta bekleme, ön doldurma ve çözümleme. Toplam süre bu üçünün toplamıdır ve hangisinin bozulduğunu söylemez. Ayrıştırmadan yapılan her ayar denemesi, kör bir düzeltme girişimidir.

Akışlı yanıtta algılanan hız iki eşiğe bağlıdır: ilk kelimenin ne kadar sürede geldiği ve token akışının okuma hızının altına düşüp düşmediği. İkinci eşik aşıldıktan sonra token arası süreyi daha da kısaltmak kullanıcı için görünmez bir kazanç olur; bütçeyi oraya harcamayın.

Aynı anda açılan iki ayar, birbirinin etkisini gizler ve bazen birbirini götürür. Taban ölçüm, hızlandırma çalışmasının deney defteridir: profil sabit tutulmadığı sürece iki koşu karşılaştırılamaz.

• Eşzamanlılık kademesi
• Girdi ve çıktı uzunluğu dağılımı (ortalama değil, yüzdeliklerle)
• Önbelleğin sıcak mı soğuk mu olduğu
• Model, ağırlık duyarlılığı ve sunum yığını sürümü
• Değiştirilen ayar ve önceki değeri
• Ölçüm penceresi ile ısınma süresinin dışlanıp dışlanmadığı

Sabit toplu işte grup, içindeki en uzun yanıt bitene kadar kapalı kalır; kısa isteklerin yeri boşalsa bile yeni istek alınmaz ve kuyruk büyür. Sürekli toplu işlem bu boşluğu kapatır: her çözümleme yinelemesinde biten diziyi çıkarır, bekleyeni alır. Verim tarafındaki en büyük tek kazanım genellikle buradadır.

1. 1Tabanı sabitle

   Mevcut ayarla verimi ve p95 token arası süreyi kaydedin.

2. 2Tavanı kademeli artır

   Eşzamanlılık tavanını kademe kademe yükseltip her kademede aynı yük profilini koşun.

3. 3Doyma noktasını bul

   Verim artmayı bırakıp p95 token arası süre yükselmeye devam ettiğinde doyma noktasına gelinmiştir.

4. 4Bir kademe geri dön

   Tavanı doyma noktasının bir kademe altına sabitleyin; fazlası kuyrukta bekler ve herkesin token hızı korunur.

Tavan koymamak adil görünür ama değildir: sınırsız kabul, sisteme giren her yeni isteğin halihazırda yanıt alan herkesin token hızını düşürmesi demektir. Tavan artı kuyruk, aynı kapasiteyi daha öngörülebilir dağıtır ve p95'i savunulabilir kılar.

Ön doldurma ile çözümleme aynı kaynağı sırayla kullanır. Uzun bir istem tek parça hâlinde işlenirken, o sırada yanıt üreten bütün istekler bekler; kullanıcı bunu akan metnin ortasında bir duraklama olarak görür. Ön doldurmayı parçalara bölmek bu duraklamayı kısa aralıklara dağıtır.

Parça boyutu bir ödünleşimdir: küçük parça duraklamayı azaltır, ön doldurma verimini bir miktar düşürür. Değeri sabitlerken tek bakılacak metrik ilk token süresi değildir; süren yanıtların token arası süresindeki dalgalanma da ölçülmelidir.

İstem önbelleği, paylaşılan bir önekin hesaplanmış anahtar-değer durumunu yeniden kullanır; kazandırdığı şey ön doldurma işidir, yani öncelikle ilk token süresidir. Çözümleme hızını değiştirmez. Bu yüzden istem önbelleği bir toplu işlem alternatifi değil, tamamlayıcısıdır.

Önbellek belleği bedava değildir: aynı cihazda KV havuzuyla aynı kaynaktan beslenir. Önek önbelleğini büyütmek eşzamanlılık tavanını daraltabilir; bu yüzden isabet oranını tek başına değil, eşzamanlılık ve p95 ile birlikte izleyin.

Yanıt önbelleği, istem önbelleğinden farklı bir katmandır: ön doldurma işini değil bütün çağrıyı ortadan kaldırır. Kazancı büyüktür, riski de: yanlış anahtarlanmış bir yanıt önbelleği, bir kullanıcının cevabını başka bir kullanıcıya verebilir.

• Normalleştirilmiş istek metni (boşluk ve büyük-küçük harf farkları temizlenmiş)
• İstem şablonu sürümü
• Model kimliği ve sürümü
• Üretim parametreleri (örnekleme ayarları, azami token)
• Yetki kapsamı veya kiracı kimliği
• Geri getirme kullanılıyorsa dizin sürümü

Geçerlilik süresini içeriğin değişkenliğine göre belirleyin: sabit politika metnine dayanan bir cevap uzun süre yaşayabilir, güncel veriye dayanan bir cevap yaşayamaz. Şablon veya dizin sürümü değiştiğinde önbellek anahtar üzerinden kendiliğinden geçersizleşmelidir; elle temizlik unutulur.

Yöntem, küçük ve hızlı bir taslak üreticinin birkaç token önermesi, asıl modelin bunları tek geçişte doğrulamasıdır. Standart doğrulama şeması çıktı dağılımını korur; yani beklenen kazanç kalitede değil, süredeki değişimdedir. Kabul edilmeyen öneriler atılır ve harcanan işlem gücü geri gelmez.

Bu yüzden kazanç iki koşula bağlıdır. Yük düşükken çözümleme bellek bant genişliğine takılıdır ve boştaki işlem gücü bedavaya yakındır; spekülasyon burada token arası süreyi kısaltır. Yük yüksekken ve toplu iş zaten doluyken aynı işlem gücü kıt kaynaktır; spekülasyon o kaynağı harcadığı için verimi düşürebilir.

• Kabul oranı (önerilen tokenların kaçı doğrulamayı geçiyor)
• Taslak üreticinin kendi maliyeti ve bellek payı
• Düşük ve yüksek yükte ayrı ölçülmüş p95 token arası süre
• Aynı iki yük noktasında saniyedeki token verimi

Kabul oranı iş yüküne göre değişir: kalıplı, biçimi öngörülebilir çıktılarda yüksek, serbest ve yaratıcı metinde düşük olma eğilimindedir. Kararı kendi trafiğinizde ölçün; başka bir iş yükünde alınmış bir sonuç sizin hattınız için kanıt değildir.

Hız çalışmasıyla model veya duyarlılık değişikliğini aynı sürümde yapmayın. Buradaki ayarların çoğu çıktıyı değiştirmez; model değişimi ve nicemleme ise değiştirir. İkisi birlikte yayına çıkarsa, kalite şikâyeti geldiğinde hangisinin sorumlu olduğunu ayıramazsınız.

Kalıcı panoyu beş çizgiyle kurun: saniyedeki token verimi, p95 ilk token süresi, p95 token arası süre, önbellek isabet oranı ve (kullanılıyorsa) kabul oranı. Her ayarın yanına geri alma eşiğini yazın; eşik aşıldığında tartışma değil geri alma yapılır.