Gecikmede ortalama yalan söyler; kararı kuyruk verir

Tez#

Gecikme panolarının çoğu tek bir sayıyla başlıyor: ortalama yanıt süresi. Bu alışkanlık klasik web servislerinden geliyor ve orada büyük ölçüde makul — bir veritabanı sorgusunun süresi belirli bir aralıkta değişir, dağılım görece dar ve ortalama temsil eder.

Dil modeli sistemlerinde dağılım bambaşka. Yanıt süresi dört değişkene bağlı ve dördü de geniş aralıkta oynuyor: girdi bağlamının uzunluğu, üretilen çıktının uzunluğu, o anda kuyrukta bekleme süresi ve ajan akışlarında tur sayısı. Bir kullanıcı üç kelimelik bir soruya iki cümlelik cevap alırken, diğeri uzun bir belgeyle gelip beş sayfa özet istiyor. İki isteğin süresi arasında büyüklük mertebesinde fark olabiliyor ve ortalama ikisinin arasında, ikisini de temsil etmeyen bir yerde duruyor.

Bağlam: dört gecikme kaynağı#

Kuyruğu neyin oluşturduğunu bilmek, hangi müdahalenin işe yarayacağını da söylüyor. Aşağıdaki tablo dört kaynağı ve her birinin hangi ölçüde görüldüğünü ayırıyor.

İkinci satırın pratik sonucu sık atlanıyor: çıktı uzunluğu gecikmeyi neredeyse doğrusal büyüttüğü için, gecikme sorununun bir bölümü aslında bir ürün kararı. Cevabın ne kadar uzun olacağı istemle ve arayüzle belirlenebilir; "kısa ve öz cevap ver" talimatı bir kalite tercihi olduğu kadar bir gecikme müdahalesi. Bu kaldıraç altyapıya hiç dokunmadan çalışıyor ve genellikle en ucuz olanı.

Kanıt: hangi ölçüler izlenmeli#

Gecikmeyi doğru izlemek tek bir sayı yerine bir ölçü kümesi gerektiriyor. Aşağıdaki liste, panoda bulunması gereken asgari kümeyi veriyor.

• İlk tokena kadar süre: kullanıcının algıladığı yanıt hızının ana bileşeni. Akışlı arayüzlerde toplam süreden daha belirleyici.
• Çıktı token hızı: uzun yanıtlarda toplam süreyi bu belirliyor; ilk tokenla birlikte okunmalı.
• Yüzde doksan dokuz ve yüzde doksan dokuz virgül dokuz dilimleri: kuyruğun nerede olduğunu gösteren tek ölçü.
• Kuyrukta bekleme süresi ayrı: model süresinden ayrılmadıkça kapasite sorunu ile model sorunu karışır.
• Ajan akışlarında tur sayısı dağılımı: gecikme değil ama gecikmenin nedeni; tur dağılımı görülmeden kuyruk açıklanamaz.

Dördüncü madde teşhiste belirleyici. Kuyrukta bekleme süresi model süresinden ayrılmadığında, tepe saatlerdeki yavaşlama "model yavaşladı" diye yorumlanıyor ve yanlış müdahale yapılıyor — daha küçük modele geçmek gibi. Oysa sorun kapasite ve çözümü ölçekleme ya da geri basınç. İki süreyi ayırmak, bu yanlış teşhisi tümden ortadan kaldırıyor.

Mekanizma: algılanan hız ile gerçek süre#

Akış hâlinde üretim, gecikme tartışmasına ikinci bir boyut ekliyor: algılanan hız. Kullanıcı ilk tokenı gördüğü anda sistemin çalıştığını anlıyor ve bekleme algısı kırılıyor. Bu yüzden aynı toplam süreye sahip iki sistem, ilk tokena kadar süreleri farklıysa tümüyle farklı deneyimler üretiyor.

Pratik sonuç şu: gecikme optimizasyonunun ilk hedefi toplam süre değil ilk tokena kadar süre olmalı. Bu ölçüyü iyileştiren müdahaleler — bağlam bütçesini küçültmek, istem önbelleğinden yararlanmak, kuyruk beklemesini azaltmak — kullanıcı deneyiminde toplam süreyi kısaltmaktan daha büyük fark yaratıyor. Buna karşılık akış olmayan yapılandırılmış çıktılarda durum tersine dönüyor: yarım JSON göstermek anlamsız olduğu için orada belirleyici olan toplam süre. Yani doğru ölçü, çıktının nasıl tüketildiğine bağlı ve bu bir ürün kararı.

Karşı görüş#

İki itiraz var. Birincisi: kuyruk dilimlerini izlemek gürültülü — az sayıda aşırı uzun istek, yüzde doksan dokuz virgül dokuz dilimini tümüyle belirliyor ve o istekler genellikle uç durumlar. İkincisi: ortalama, kapasite planlaması için hâlâ doğru ölçü; toplam yük ortalamayla hesaplanır.

Kuyruk dilimini panoya koyduk ve panik yarattık: sayı sürekli zıplıyordu. Sonra ayrıştırdık — zıplamayı tek bir toplu iş akışı üretiyordu ve o akışın kullanıcı beklentisi yoktu.

Alıntı birinci itirazın haklı yanını ve çözümünü birlikte gösteriyor: kuyruk ölçüsü iş akışı bazında ayrıştırılmadıkça gürültülü. Kullanıcı bekleyen etkileşimli akışlar ile arka planda çalışan toplu işler aynı panoda toplandığında kuyruk yorumlanamaz hâle geliyor. Çözüm ölçüyü bırakmak değil, akışa göre ayırmak. İkinci itiraz da doğru ama sınırlı: ortalama kapasite planlaması için uygun bir ölçü — toplam token hacmi ortalamayla hesaplanır. Kullanıcı deneyimi için ise uygun değil. İki farklı soru, iki farklı ölçü; sorun ikisini aynı panoda tek sayıyla temsil etmek.

Sınırlar ve belirsizlik#

Bu analiz bir hedef gecikme değeri önermiyor; kabul edilebilir gecikme ürüne ve kanala bağlı.

• Kabul edilebilir eşik ürüne özgü: sesli arayüzde saniyeler, toplu belge işlemede dakikalar kabul edilebilir olabilir.
• Algılanan hız ölçümü zor: ilk tokena kadar sürenin kullanıcı memnuniyetine etkisi kendi ürününüzde ölçülmeli.
• Kuyruk ölçüsünün gürültüsü akışa bağlı: ayrıştırma yapılmadan yüzde doksan dokuz virgül dokuz dilimi yorumlanamaz.
• Ajan tur dağılımı ölçülmeden kuyruk açıklanamaz: çoğu sistemde bu dağılım hiç kaydedilmiyor.

Sonuç#

Ortalama gecikme, simetrik dağılımlar için tasarlanmış bir ölçü ve bu sistemlerde dağılım simetrik değil. Ortalamaya bakan bir ekip, kullanıcılarının bir bölümünün sistemi kullanılamaz bulduğunu panodan asla öğrenemez.

Asgari düzeltme üç adımlı: ilk tokena kadar süreyi ayrı izlemek, kuyruk dilimlerini iş akışı bazında ayrıştırmak ve kuyrukta bekleme süresini model süresinden ayırmak. Üçü kurulduğunda gecikme tartışması bir tahmin olmaktan çıkıp bir teşhise dönüşüyor — ve hangi müdahalenin işe yarayacağı kendiliğinden görünüyor.

Ne yapmalı?#

1. 1İlk tokena kadar süreyi ana ölçü yapın

   Akışlı arayüzlerde algılanan hızı bu belirliyor. Toplam süre ikinci sırada.

2. 2Kuyruk dilimlerini akış bazında ayırın

   Etkileşimli akışlar ile toplu işler aynı panoda toplanmasın; birleştirilmiş kuyruk yorumlanamaz.

3. 3Bekleme süresini model süresinden ayırın

   Ayrılmadığında tepe saatlerdeki yavaşlama "model yavaşladı" diye yanlış teşhis edilir.

4. 4Çıktı uzunluğunu bir kaldıraç olarak kullanın

   Cevap uzunluğu bir ürün kararı ve gecikmeye doğrusal etki ediyor; altyapıya dokunmadan kazanç sağlar.

5. 5Ajan tur dağılımını kaydedin

   Tur sayısı görülmeden kuyruk açıklanamaz. Dağılımın kuyruğu maliyeti de belirliyor.

6. 6Hedefi kanala göre belirleyin

   Sesli arayüz, sohbet ve toplu işlem aynı eşiği taşımaz. Tek bir hizmet hedefi üçünü de yanlış yönetir.