Çıkarım kapasitesi planlamak

Kapasite planını istek/saniye üzerine kurmak, farklı boyuttaki işleri aynı sayıyor demektir. Kısa bir sınıflandırma isteği ile uzun bir rapor üretimi aynı hatta çok farklı yük bırakır: birincisi neredeyse yalnızca ön doldurma, ikincisi dakikalarca süren bir çözümleme işidir. Planın birimi bu yüzden istek değil tokendır.

Tepe tanımını günlük ortalamadan değil, en yoğun birkaç dakikalık pencereden alın. Haftanın günü, mesai saati ve kampanya takvimi gibi düzenli dalgalar ayrı ayrı görünsün: kapasite kararı ortalamaya değil bu pencerelerin en yükseğine göre verilir.

Tek bir "ortalama yanıt süresi" hedefi iki ayrı bütçeyi birbirine karıştırır. İlk token süresi kuyruk ve ön doldurmadan, token arası süre çözümlemeden beslenir; biri bozulduğunda diğerini iyileştiren ayar işe yaramaz. Ayrıca ortalama, kullanıcının şikâyet ettiği kuyruğu gizler: hedef her zaman bir yüzdelikle yazılır.

Kopya kapasitesi bir tahmin değil ölçüm sonucudur ve tek bir sayı olarak değil bir eğri olarak çıkar. Eşzamanlılık arttıkça verim bir noktaya kadar yükselir, sonra düzleşir; gecikme ise düzleşmez, artmaya devam eder. Kullanılabilir kapasite bu iki eğrinin ayrıştığı dirsektir.

1. 1Isınma turu koş

   Ağırlıklar ve önbellekler yerine oturana kadar ölçüm başlatmayın; ısınma verisi rapora girmez.

2. 2Eşzamanlılığı kademelendir

   Eşzamanlılığı sabit kademelerle artırın ve her kademeyi kuyruk dengeye gelene kadar sürdürün.

3. 3Girdi dağılımını sabitle

   Her kademede aynı istem ve çıktı uzunluğu dağılımını kullanın; dağılım değişirse kademeler karşılaştırılamaz.

4. 4İki eğriyi birlikte çiz

   Her kademe için p95 gecikme ile saniyedeki token verimini kaydedin; doyma noktası ikisinin ayrıştığı yerdir.

Doğrulama adımı: dirsek noktasını bulduktan sonra bir kademe altında uzun bir koşu yapın ve p95'in kademe boyunca sabit kaldığını görün. Sabit kalmıyorsa ölçtüğünüz şey kapasite değil, kuyruğun henüz dolmamış hâlidir.

Doluluk ile bekleme arasındaki ilişki doğrusal değildir: tavana yaklaştıkça küçük bir yük artışı beklemeyi orantısız biçimde büyütür. Bu yüzden "donanımı sonuna kadar kullanmak" bir verimlilik hedefi gibi görünse de kapasite planında bir risk kaynağıdır. Hedef doluluk, tepe dalgasını yutacak payı bırakacak şekilde seçilir.

Kuyruğa bir üst sınır ve bir kabul denetimi koyun. Sınırsız kuyruk, bir verim sorununu zaman aşımı fırtınasına çevirir: istekler sırada beklerken istemci yeniden dener, yeniden denemeler kuyruğu daha da büyütür. Sınıra ulaşıldığında açıkça reddetmek, sessizce geciktirmekten hem dürüst hem ucuzdur.

# VARSAYIM: aşağıdaki değerler ölçüm değildir, kendi eğrinizden gelmelidir.
import math

tepe_eszamanlilik = 120   # adım 1: tepe penceresindeki açık istek sayısı
kopya_kapasitesi = 16     # adım 3: dirsek noktasının bir kademe altı
hedef_doluluk = 0.7       # adım 4: kuyruk payı

taban = math.ceil(tepe_eszamanlilik / (kopya_kapasitesi * hedef_doluluk))
yedeklilik = 1            # N+1; iki bölgeye yayılıyorsa bölge başına tekrarlanır
toplam_kopya = taban + yedeklilik

Yedeklilik payı filonun büyüklüğüne göre değişir. İki kopyayla çalışıyorsanız birinin kaybı kapasitenin yarısını götürür; küçük filolar bu yüzden oransal olarak daha fazla pay ister. Birden çok bölgeye yayıyorsanız hesap bölge başına tekrarlanır: bir bölgenin tamamı düştüğünde kalan bölgeler tepe yükü taşıyabilmelidir.

Cihaz doluluğu, dil modeli sunumunda yanıltıcı bir sinyaldir: çözümleme adımları bellek bant genişliğine takıldığında doluluk yüksek görünürken iş ilerlemez, tersine kuyrukta istek beklerken doluluk düşük okunabilir. Talebi gösteren sinyal, bekleyen istektir.

• Kuyrukta bekleyen istek sayısı
• Kuyrukta geçen sürenin p95 değeri
• Çalışan toplu işin doluluk oranı
• Reddedilen veya zaman aşımına uğrayan istek oranı

Tetikleyici eşiğini ısınma süresine göre öne alın: yeni kopya hazır olana kadar geçen süre boyunca yük artmaya devam edecektir. Ölçek-içeri tarafında ise histerezis kullanın; eşiğin hemen altına inen bir dalgalanma kopyayı kapatıp birkaç dakika sonra yeniden açtırırsa, en pahalı durumu sürekli tekrar edersiniz.

Kararlı durumda yapılan testler iki şeyi gizler: soğuk başlangıç ve önbellek kaybı. Bir kopya düştüğünde yalnızca kapasite azalmaz, o kopyanın önek önbelleği de gider; hayatta kalan kopyalar hem daha çok trafik hem daha soğuk trafik alır. Bu çift etki ancak provada görünür.

1. 1Tepeyi gerçek süresince sürdür

   Yükü üretimde beklenen tepe penceresi kadar sürdürün; birkaç dakikalık bir tepe gerçek tepe değildir.

2. 2Bir kopyayı düşür

   Yük sürerken bir kopyayı kapatın; hata oranını, p95 gecikmeyi ve kuyruk derinliğini kaydedin.

3. 3Kurtarma süresini ölç

   Yeni kopyanın yük almaya hazır olmasına kadar geçen süreyi ayrı ölçün; bu süre yedeklilik payınızın alt sınırıdır.

4. 4Bozulma sırasını doğrula

   Kapasite yetmediğinde hangi trafiğin önce düşürüleceği yazılı mı ve prova sırasında o sırayla mı düşüyor?

Provanın çıktısı bir rapor değil iki karardır: yedeklilik payı yeterli mi ve bozulma planı yazılı mı? Bozulma planı, kapasite yetmediğinde hangi isteğin bekletileceğini, hangisinin daha kısa yanıtla karşılanacağını ve hangisinin reddedileceğini önceden söyler.

Birim maliyeti gerçek doluluğunuzda hesaplayın, tam kapasitede değil. Aynı donanım üçte bir dolulukla çalıştığında token başına maliyet üç katına çıkar; bu yüzden kapasite ve maliyet aynı tablonun iki sütunudur. Yedeklilik payı da bu tabloya girer: ödediğiniz şey kullanılan kapasite değil, kullanılabilir kapasitedir.

Planı canlı bir belge olarak tutun ve yenileme tetikleyicilerini yazın: istem şablonunun değişmesi, yeni bir ürün akışının açılması, model değişimi ve bağlam kullanımının artması. Bunların her biri token profilini değiştirir, yani kapasite hesabının girdisini değiştirir.