Dil modeli neden yavaşlar?

01Üretim bir seferde değil, tek tek ilerler#

Tahmin yazısında gördüğün gibi, seçilen her token bir sonraki adımın bağlamına eklenir. Bu, üretimi ardışık yapar: 500 tokenlık bir yanıt, 500 ayrı “tek token” adımıdır ve her adım bir öncekinin sonucunu bekler. Eğitimde bir dizinin birçok konumu paralel hesaplanabilir; üretimde bu mümkün değildir (bkz. Transformer yazısı).

Saf bir uygulamada her yeni token için bütün bağlamı baştan işlemek gerekirdi. 2000 tokenlık bir geçmişin üstüne 1 token eklemek için 2000 tokenın attention hesabı yeniden yapılırdı. Bu boşa harcama çok büyük olurdu, çünkü önceki tokenlar için hesaplananların büyük kısmı değişmez.

02KV önbelleği: bir kez hesapla, tekrar kullan#

Bir tokenın anahtar (K) ve değer (V) vektörleri, o tokenın kendisine ve önceki tokenlara bağlıdır; sonradan gelen tokenlar onları değiştirmez (nedensel maske sayesinde). Bu yüzden her tokenın K ve V vektörleri bir kez hesaplanıp saklanabilir. Yeni bir token geldiğinde yalnızca onun sorgu, anahtar ve değer vektörleri hesaplanır; sorgu, önbellekteki tüm anahtarlarla karşılaştırılır. Hugging Face belgeleri bunu şöyle özetler: otoregresif modeller bir seferde bir token tahmin ettiği için KV skorları her seferinde yeniden hesaplanırdı; önbellek bu hesapları saklar, hesap süresini düşürür ve yanıt hızını artırır. Hugging Face, KV cache ↗

Ayrıca önbellek, istem (prefill) ile üretim (decode) arasında farklı bir yük yaratır. İstemin tamamı paralel işlenebilir; üretim adımları ise tek tek ilerler ve her adımda büyük bir önbelleği bellekten okur. Bu yüzden uzun bir bağlam, yalnızca daha fazla hesap değil, daha fazla bellek okuması demektir.

03Önbellek büyür, bellek darboğaz olur#

Önbellek bedava değildir. Kabaca boyutu şu çarpımdır:

2 (K ve V) × katman sayısı × KV başı sayısı × baş boyutu × token sayısı × sayı başına bayt

Varsayımsal bir modelle hesaplayalım (belirli bir ürünün yapılandırması değil): 32 katman, 8 KV başı, 128 baş boyutu, 16 bitlik sayılar (2 bayt) ve 8192 token. Çarpım 2 × 32 × 8 × 128 × 8192 × 2 = 1.073.741.824 bayt, yani tam olarak 1 GiB, tek bir konuşma için. Aynı anda yüzlerce kullanıcıya hizmet veren bir sistemde bu, ağırlıkların kendisi kadar bellek tutabilir. Hugging Face belgeleri de KV önbelleğinin belleğin önemli bir bölümünü kaplayıp uzun bağlamlı üretimde darboğaz olabildiğini belirtir.

Bu darboğaza karşı iki çeşit çözüm var:

• Önbelleği küçültmek: Birçok sorgu başının daha az KV başını paylaşması (multi-query ve gruplanmış sorgulu attention). Ainslie ve arkadaşları, mevcut çoklu başlı bir modeli, ön eğitim hesabının yaklaşık %5’iyle gruplanmış sorgulu attention’a dönüştürmenin, çoklu başlı attention’a yakın kaliteyi çoklu sorgulu attention’a yakın hızla verebildiğini bildirdi. GQA ↗ Önbelleği düşük hassasiyetle (nicelenmiş) saklamak da mümkündür; ancak kısa bağlamlarda gecikmeyi artırabilir.
• Önbelleği daha iyi yönetmek: Kwon ve arkadaşları, her isteğin önbelleğinin büyük ve değişken boyutlu olduğunu, bunun parçalanma ve kopyalamayla belleği boşa harcayarak aynı anda işlenebilen istek sayısını sınırladığını gösterdi. İşletim sistemlerindeki sanal belleğe benzeyen PagedAttention ile önbelleği sabit boyutlu bloklara bölüp bitişik olmayan bellekte tutarak, rapor ettikleri sistemde (vLLM) sunum veriminin, karşılaştırdıkları sistemlere göre 2–4 kat arttığını bildirdi. PagedAttention ↗

04Bunu günlük kullanımda nasıl görürsün?#

Bu tablo olası nedenleri sıralar; belirli bir ürünün iç tasarımı hakkında iddia taşımaz. Hız, bellek ve kalite arasındaki bu ödünleşimi hafifletmenin başka yolları da var: Büyük modeller nasıl küçültülür?