Token ekonomisi ve gecikme bütçesi

Teori: maliyeti ne belirler#

Girdi tokenları tek geçişte işlenir; çıktı tokenları ise birer birer üretilir ve her yeni token kendinden öncekilere bakar. Bu asimetrinin iki sonucu vardır: aynı sayıda çıktı tokenı, aynı sayıda girdi tokenından hem daha yavaş hem genellikle daha pahalıdır, ve çıktı uzunluğu toplam süreyi neredeyse doğrusal büyütür. Yani "kısa cevap ver" talimatı bir üslup tercihi değil, aynı zamanda bir maliyet ve gecikme kararıdır.

Girdi tarafındaki şişmenin kaynağı nadiren kullanıcının yazdığı metindir. Sistem talimatı her istekte yeniden gönderilir, geri getirme katmanı her istekte parça ekler, konuşma geçmişi tur başına birikir. Çok adımlı akışlarda bu birikim çarpanla büyür: her adım bir çağrıdır ve her çağrı birikmiş bağlamı yeniden taşır. Bu yüzden "bir kullanıcı işi kaç çağrı sürüyor" sorusu, "hangi model" sorusundan daha belirleyici olabilir.

Örnek hesap: varsayımla yürütmek#

def istek_maliyeti(girdi_token, cikti_token, cagri, bg, bc):
    """Tek bir kullanıcı işini tamamlamanın maliyeti.

    VARSAYIM — gerçek ölçüm değil, yalnızca hesabın iskeleti:
      girdi_token: çağrı başına ortalama girdi token sayısı
      cikti_token: çağrı başına ortalama çıktı token sayısı
      cagri: bir kullanıcı işini bitirmek için gereken çağrı sayısı
      bg, bc: girdi ve çıktı için token başına birim fiyat

    Birim fiyatları kendi sözleşmenizden okuyun; burada sabit yazılmaz.
    """
    return cagri * (girdi_token * bg + cikti_token * bc)


def kalem_paylari(girdi_token, cikti_token, bg, bc):
    """Hangi kalem baskın? Bunu bilmeden kol çekilmez."""
    girdi = girdi_token * bg
    cikti = cikti_token * bc
    toplam = girdi + cikti
    return {"girdi": girdi / toplam, "cikti": cikti / toplam}

Hesabın değeri sonucunda değil, hangi kalemin baskın olduğunu göstermesindedir. Girdi payı baskınsa çekilecek kol bağlam bütçesidir: geri getirilen parça sayısı, sistem talimatının uzunluğu, geçmişin ne kadarının taşındığı. Çıktı payı baskınsa kol çıktı uzunluğu ve biçimidir. Çağrı sayısı baskınsa kol akış tasarımıdır. Bu üçünü ölçmeden model değiştirmek, çoğu zaman aynı israfı farklı bir birim fiyattan ödemektir.

Gecikme: iki süre, iki algı#

İlk tokenin gelme süresi kullanıcının "çalışıyor mu" sorusunu, toplam süre "bitti mi" sorusunu cevaplar. Akışlı yanıt ikincisini kısaltmaz, yalnızca birincisini algıda öne alır — ve bu gerçek bir kazançtır, çünkü bekleyen kullanıcı boş ekrana bakmaz. Ama akış her yerde işe yaramaz: çıktı bir forma yazılacak yapılandırılmış veriyse parça parça göstermenin kullanıcıya faydası yoktur, orada kazanılacak yer toplam süredir.

İkinci ve daha sinsi kaynak kuyruk gecikmesidir. Bir sistem aynı anda belirli sayıda isteği işleyebilir; varış hızı bu kapasiteye yaklaştıkça bekleme süresi doğrusal değil hızlanarak büyür. Sezgi şudur: sistemde aynı anda duran iş sayısı, varış hızı ile bir işin sistemde geçirdiği ortalama sürenin (bekleme artı işlenme) çarpımına eşittir — işlenme süresini uzatan her şey (uzun çıktı, fazladan çağrı) hem bu çarpımı hem de kapasiteyi tüketir. Bu yüzden gecikme ortalamayla yönetilemez: ortalama sakin görünürken uç dilim çoktan bozulmuş olur. İzlenecek sayı uç dilimdir ve yanına eşzamanlılık ile kuyruk uzunluğu yazılır.

Kollar ve etkileri#

Karar: hangi kolu önce çekersiniz#

1. 1Baskın kalemi ölçün

   Girdi, çıktı ve çağrı sayısını gerçek trafikten çıkarın; tahminle kol çekilmez.

2. 2Bedeli olmayan kolları önce çekin

   Önbellek, gereksiz tekrar eden talimat, aynı bağlamın iki kez gönderilmesi. Bunlar ödünleşimsiz kazançtır.

3. 3Biçim kollarını çekin

   Çıktı uzunluğu ve biçim yönergesi; kalite etkisi ölçülebilir ve karar geri alınabilir.

4. 4Akış tasarımını sadeleştirin

   Adımları birleştirin, gereksiz aracı çağrıyı kaldırın; ara denetim adımlarını korumaya dikkat edin.

5. 5Model kolunu en sonda çekin

   Model küçültmek en büyük kalite riskini taşır; ancak ölçüm kümesi kuruluysa ve dilim bazlı sonuç görülüyorsa çekilir.

Sık yapılan hata#