Tanie inference: KV cache, batching i quantization

Aby wygenerować token, decoder-only transformer bierze całą dotychczasową sekwencję, przepuszcza ją przez każdą warstwę i odczytuje rozkład prawdopodobieństwa z ostatniej pozycji. Potem dopisuje wybrany token i robi to znowu. Ten opis jest poprawny — i dokładnie to robi wolny przebieg.

Jest też ogromnie marnotrawny, a powodem jest maska przyczynowa z Rozdziału 9. Wektory key i value pozycji 7 są obliczane z wejścia pozycji 7 oraz pozycji przed nią. Kiedy pojawia się pozycja 8, pozycja 7 nie może jej zobaczyć — to właśnie znaczy „przyczynowa” — więc key i value pozycji 7 są dokładnie tymi samymi liczbami co wcześniej. Wolny przebieg mimo to przelicza je na każdym kroku.

Więc je zapisz. Ten zapis to key-value cache, najważniejsza pojedyncza optymalizacja w serving modeli językowych:

out = model(prompt_ids, use_cache=True)          # prefill: the whole prompt
past = out.past_key_values                        
nxt = out.logits[:, -1].argmax(-1, keepdim=True)

for _ in range(n - 1):
    out = model(nxt, past_key_values=past, use_cache=True)   
    past = out.past_key_values                                
    nxt = out.logits[:, -1].argmax(-1, keepdim=True)

Zobacz, co trafia do modelu w pętli: nxt, jeden token. Nie sekwencja. Query nowego token attend względem każdego zapisanego key, a zapisane key i tak nigdy nie miały się zmienić. To nie jest przybliżenie — o to chodziło w sprawdzeniu identycznego wyniku powyżej. Cache nie wymienia jakości na szybkość; usuwa zbędną arytmetykę.

Aby czysto zobaczyć skalowanie, usuń transformer i zmierz jedną głowicę attention z $d = 64$, jeden krok generation liczony na oba sposoby:

Prawa kolumna jest przyczyną. Przeliczanie buduje pełną macierz attention $n \times n$ na każdym kroku — $O(n^2)$ z ramki o notacji asymptotycznej w Rozdziale 9, płacone raz za token. Z cache budujesz zamiast tego wiersz $1 \times n$: przy 4,096 token, 67 MB wyników kontra 16 KB.

Liczenie multiply-accumulates zamiast milisekund usuwa maszynę z argumentu. Aby wygenerować $T$ token od zimnego startu:

Na krok wersja z cache jest liniowa względem kontekstu, a bez cache kwadratowa; zsumowane przez generation, $O(T^2)$ kontra $O(T^3)$, ze stosunkiem rosnącym bez ograniczeń. Dziewięciokrotna różnica z otwarcia została zmierzona na 48 token — krócej niż pierwszy wiersz tej tabeli.

Cache zmienia też to, co musi być w pamięci. Na laptopowym GPU 8 GB generującym 256 token w fp16, biorąc szczyt alokatora i odejmując rezydentne wagi:

8,3 raza więcej pamięci, wydane po to, by wyprodukować te same token wolniej. To obietnica z Rozdziału 5, przychodząca z nieoczekiwanej strony: tam reverse-mode autodiff musiał trzymać każdy stan pośredni przy życiu dla backward pass, a activations dominowały pamięć training. Przy inference nie ma backward pass i nie ma czego dla niego przechowywać — więc pamięć dominuje zamiast tego cache, i jest to świadomy wybór, nie nieunikniony koszt.

Spójrz jeszcze raz na szybki przebieg: jego pierwszy token zachował się inaczej niż pozostałe czterdzieści siedem.

prefill, 40 prompt tokens : 1.0224 s   ->  25.6 ms per token
decode,  47 steps         : 0.1665 s mean per step

Prompt kosztował 25.6 ms na token, a każdy wygenerowany token kosztował 166 ms. Ten sam model, ten sam sprzęt, te same wagi, sześciokrotna różnica na token — i w kierunku, którego większość osób się nie spodziewa. Prompt jest częścią tanią. Generation dzieli się na dwie fazy o naprawdę odmiennej fizyce:

Obie połówki da się zmierzyć. Prefill, jedno przejście przez $P$ token:

Decode, jeden token względem cache $C$:

Przeczytaj drugą tabelę dwa razy. Przejście z 16 token kontekstu do 1,024 — sześćdziesiąt cztery razy więcej historii do attend — zmieniło koszt kroku o nic mierzalnego. Attention względem cache to realna praca, ale przyćmiewa ją stały koszt przeciągnięcia pół miliarda wag przez magistralę pamięci, aby wyprodukować jeden wektor. Ten stały koszt jest powodem wszystkiego w następnej sekcji.

Te dwie fazy są źródłem dwóch liczb raportowanych przez każdy system serving. Time to first token to zasadniczo prefill i rośnie z prompt, dlatego długa rozmowa wolno startuje. Tokens per second to $1/\text{decode step}$ i jest mniej więcej stałe, dlatego odpowiedź potem płynie równo. Chat, który zaczyna powoli, a potem płynnie streamuje, nie jest sztuczką renderowania. To są te dwie tabele.

Cache wymienia arytmetykę na pamięć, a pamięć, której chce, nie jest mała. Dla każdego token w kontekście każda warstwa trzyma jeden wektor key i jeden wektor value na key-value head:

2 oznacza keys i values; cała reszta to architektura. Dla modelu mierzonego w tym rozdziale — 24 warstwy, 14 query heads, 2 key-value heads, wymiar head 64 — w fp16 daje to $2 \times 24 \times 2 \times 64 \times 2 = 12{,}288$ bajtów na token.

Formuły w tej dziedzinie mają zwyczaj mylić się o czynnik dwa, więc sprawdź to względem alokatora zamiast wierzyć:

KV cache tensors per layer: (1, 2, 295, 64) float16
measured: 3,624,960 bytes for 295 tokens = 12,288 bytes/token
formula : 2 * 24 * 2 * 64 * 2                = 12,288 bytes/token

Dokładnie, i pozostaje dokładnie dla każdego sprawdzonego kształtu:

Ostatnie trzy wiersze zasługują na drugie spojrzenie. Trzydziestu dwóch użytkowników po 2,048 token każdy, sześćdziesięciu czterech po 1,024, stu dwudziestu ośmiu po 512 — cache ma 768 MB w każdym przypadku, bo wszystkie trzy trzymają 65,536 token. Cache zależy tylko od łącznej liczby rezydentnych token, a nie od tego, jak są rozdzielone między użytkowników. Ten fakt jest fundamentem sekcji o batching.

Rozdział 9 wprowadził multi-query i grouped-query attention oraz odłożył powód do tego rozdziału. Powodem jest ta formuła, a konkretnie $H_{kv}$ w niej.

Standardowe multi-head attention daje każdej query head własne key i value heads. Ten model ma 14 query heads; przy pełnym multi-head attention jego cache wynosiłby $2 \times 24 \times 14 \times 64 \times 2 = 86{,}016$ bajtów na token — 84 KB zamiast 12 KB, dokładnie siedem razy więcej, czyli stosunek query heads do key-value heads.

Multi-query attention¹ doprowadza to do granicy: wszystkie query heads współdzielą jedną key-value head. Grouped-query attention² to kompromis, który wygrał — garść key-value heads, każda współdzielona przez grupę query heads — bo utrata jakości MQA była realna, a GQA nie jest. Żadne z nich nie kupuje arytmetyki. Istnieją po to, by podzielić tę formułę przez liczbę całkowitą, i rozeszły się po branży w chwili, gdy długie konteksty uczyniły cache ograniczeniem wiążącym.

A robią to szybko. Dla modelu klasy 7B z 32 warstwami i 8 key-value heads o wymiarze 128 cache ma 128 KB na token w fp16:

Własne wagi tego modelu mają 13.0 GB w fp16, jak w tabeli na końcu rozdziału. Więc przy context 128,000 token cache jednego użytkownika jest większy niż model. To arytmetyka, którą Rozdział 16 zamienia w pieniądze, i dlatego długa rozmowa nie jest tylko wolna — zajmuje stały kawałek maszyny tak długo, jak request żyje.

Decode jest memory-bound: wagi są przeciągane przez magistralę, by wyprodukować jeden token, a jednostki arytmetyczne bezczynnie czekają. Dołóż więc więcej pracy do tego samego kroku. Uruchom kilka request naraz, a wagi, odczytane raz, obsłużą je wszystkie. Zmierzone na tym samym modelu, każdy request trzyma 64-token cache i dekoduje jeden token:

Czytaj dwie prawe kolumny względem siebie, bo to cały sens. Przejście z jednego request do szesnastu mnoży throughput przez 6,0 i mnoży czekanie pojedynczego request przez 2,67. Batch uczynił serwer lepszym, a każdego użytkownika gorszym.

To nie błąd do dostrojenia; to sama wymiana, i po każdej stronie ma nazwę. Latency to to, czego doświadcza osoba czekająca na odpowiedź. Throughput to to, przez co dzieli się fakturę. Żadne ustawienie nie poprawia obu.

Zauważ też, gdzie to się zatrzymuje. Od 16 do 32 throughput zyskuje 9 %, podczas gdy latency prawie się podwaja: krok przestał być memory-bound i stał się compute-bound, a za tym kolanem batch niczego nie kupuje. Każde deployment ma takie kolano; jego położenie trzeba zmierzyć u siebie, ale jego istnienie nie.

Naiwny sposób na batch polega na zebraniu $B$ request, uruchomieniu ich razem i zwróceniu wyników, gdy wszystkie skończą. Ale nie kończą razem: niektóre odpowiedzi mają dwadzieścia token, inne pięćset. Stały batch działa, aż skończy jego najdłuższy członek, a każdy zakończony request nadal zajmuje swój slot, dokładając padding, aż do tego momentu.

Weź 64 request z realistycznie skośnym rozkładem długości wyjścia — mediana 18 token, najdłuższy 231, łącznie 1,874 — i zasymuluj obie polityki przy zmierzonym koszcie kroku dla ośmiu slotów:

Throughput poprawia się 1,6x. Średnie latency poprawia się ponad dziesięciokrotnie, bo przy static batching request, który skończył w czterech krokach, nadal czeka na sąsiada z 231 token, zanim ktokolwiek o nim usłyszy.

Continuous batching³ jest poprawką i jest tak proste, jak brzmi: batch nie jest grupą, lecz zbiorem slotów, a slot, który się zwalnia, przyjmuje następny request z kolejki już w kolejnym kroku. Scheduler działa z granulacją jednego token, nie jednego request. Każdy stos serving w produkcji robi to teraz.

Ma też drugą połowę: cache. Sloty, które przychodzą i odchodzą, zostawiają pofragmentowaną pamięć cache, a rezerwowanie dla każdego slotu maksymalnie możliwego context marnuje większość rezerwacji. PagedAttention⁴ pożycza odpowiedź z systemów operacyjnych: przechowuj cache w blokach stałego rozmiaru z tabelą bloków na sekwencję, tak aby cache sekwencji mógł być fizycznie rozproszony, pozostając logicznie ciągły — co pozwala też dwóm sekwencjom ze wspólnym prefiksem współdzielić bloki, które go trzymają. Na tym zbudowano vLLM i dlatego silnik serving jest alokatorem pamięci z dołączonym transformer.

Druga połowa rachunku to same wagi. Pół miliarda parametrów po cztery bajty każdy to 1.98 GB; po dwa bajty, 0.99 GB; po jeden bajt, 0.49 GB. Mniej bitów na wagę zmniejsza model na dysku, zmniejsza go w pamięci i — ponieważ decode jest bandwidth-bound — sprawia, że każdy krok jest szybszy, bo trzeba przenieść mniej bajtów.

Najprostszy schemat to symetryczna quantization względem maksimum bezwzględnego i mieści się w trzech liniach:

qmax  = 2 ** (bits - 1) - 1
scale = W.abs().max() / qmax                        
Wq    = torch.round(W / scale).clamp(-qmax - 1, qmax)
W_hat = Wq * scale                                  # dequantized

Wybierz skalę tak, by największa waga mapowała się na największą liczbę całkowitą, podziel, zaokrąglij, zapisz liczby całkowite i skalę. Odtwórz przez przemnożenie z powrotem. Nie ma w tym nic sprytnego i działa — aż przestaje.

Zmierzone na rzeczywistych wagach modelu: wszystkie 168 macierzy projekcji, 357.8 miliona parametrów, błąd względny $\lVert W - \hat{W}\rVert / \lVert W \rVert$:

Czwarty wiersz to załamanie. Błąd względny 0.99 na najgorszej macierzy oznacza, że rekonstrukcja nie zachowuje właściwie nic z oryginału — macierz została zastąpiona szumem o mniej więcej właściwej wielkości. Przyczyna jest widoczna w tym samym eksperymencie na pojedynczej macierzy:

model.layers.12.mlp.down_proj.weight   (896 x 4864)
mean |w| 0.01386   std 0.01822   max |w| 0.43945   max/std 24.1
weights beyond 6 sigma: 692 of 4,358,144   (0.016 %)

Jedna waga na sześć tysięcy leży dalej niż sześć odchyleń standardowych, a największa jest 24 odchylenia dalej. Przy jednej skali dla całej macierzy ta jedna waga ustala rozmiar kroku dla wszystkich 4,3 miliona pozostałych. Przy 8 bitach jest 256 kroków i typowa waga nadal ląduje na sensownym. Przy 4 bitach jest ich 16, skrajny zarezerwowany jest dla wartości, której prawie nic nie ma, a zwykłe wagi — czyli wszystkie — zaokrąglają się do dwóch lub trzech różnych poziomów.

Wszystko po tym wierszu to ta sama naprawa na różnych granularnościach: daj skali mniejsze terytorium. Skala na wiersz wyjściowy dzieli błąd przez 3,4; skala na grupę 128 kolejnych wag dzieli go znowu. Kosztem jest księgowość — 16-bitowa skala na grupę 128 to $4 + 16/128 = 4.125$ bitu na wagę zamiast 4 — a odzyskuje większość luki.

NF4 podchodzi do tego z drugiej strony.⁵ Poziomy nie muszą być równo rozmieszczone. Wagi w bloku są w przybliżeniu normalnie rozłożone, więc wybierz szesnaście poziomów jako kwantyle rozkładu normalnego: gęsto przy zerze, gdzie wagi faktycznie są, rzadko w ogonach, gdzie ich nie ma. Te same cztery bity, ta sama skala blokowa, przy mniejszym bloku — 4.25 bitu na wagę kontra 4.125 dla group-128 — a zmierzony błąd spada z 0.1323 do 0.0952, o 28 % mniej. Część tego to drobniejszy blok, reszta to ustawienie poziomów tam, gdzie jest masa, a rozdzielenie tych dwóch wymagałoby trzeciego wiersza.

Ramka o floating-point z Rozdziału 2 skończyła się obietnicą: że ten rozdział skwantyzuje wagi do 8 i 4 bitów i znajdzie garść cech odstających, które nie dadzą się ścisnąć. Oto one — i wyjaśniają, dlaczego „po prostu zaokrąglij liczby” nigdy nie miało działać na activations.

Wagi powyżej zachowywały się źle. Activations są w innej lidze. Weź zwykły 84-token prompt, przechwyć residual stream na każdej warstwie i zmierz największą wartość bezwzględną, jaką osiąga każdy z 896 wymiarów:

Wymiar 62 osiąga 1,579.6, podczas gdy wymiar medianowy nigdy nie przekracza 1.6. To nie wybryk jednego token ani jednej warstwy: ten sam wymiar jest obecny w warstwie 4 i nadal w warstwie 20, z prawie tą samą wartością. To są outlier features,⁶ i są systematyczne — właściwość wytrenowanego modelu, nie wejścia.

Histogram tych 896 maksimów per wymiar w warstwie 16 czyni kształt oczywistym:

     0 -      1 | ######################################## 254
     1 -      2 | ######################################## 283
     2 -      4 | ######################################## 226
     4 -      8 | ######################################## 93
     8 -     16 | ##################                       18
    16 -     32 | #########                                9
    32 -     64 | #######                                  7
    64 -    128 | #####                                    5
   128 -    256 |                                          0
   256 -    512 |                                          0
   512 -   1024 |                                          0
  1024 -   4096 | #                                        1

Dziewięćset wymiarów w schludnej kupce poniżej 8, kompletnie nic przez trzy oktawy, a potem jeden samotny wymiar na dalekim końcu. Teraz skwantyzuj ten tensor do INT8 i policz, co się dzieje:

Czternaście poziomów z 256. Skalę ustawiło 1,579.6, więc każdy krok ma szerokość 12.44, a typowa activation — mediana wartości bezwzględnej 0.26, dziewięćdziesiąty dziewiąty percentyl 2.51 — nie ma gdzie wylądować. Per wymiar jest to jeszcze ostrzejsze:

single tensor-wide scale = 12.4378
  dim 826 (max |h| = 4.77):  1 distinct level out of 256
  dim 336 (max |h| = 1.62):  1 distinct level out of 256
  dim  96 (max |h| = 0.69):  1 distinct level out of 256

after excluding the top 4 dimensions, scale = 0.5749  (22x smaller)
  dim 826: 8 levels    dim 336: 4 levels    dim  96: 3 levels

Jeden poziom. Cały wymiar, każdy token, skwantyzowany do tej samej liczby. Przydzielono osiem bitów i użyto mniej więcej zera, a model czytający te activations dostaje stałą.

Ten pomiar uzasadnia każdą technikę, której ludzie naprawdę używają:

Prawie każdy artykuł o quantization zatrzymuje się na poprzedniej sekcji: wyjaśnia metodę, cytuje współczynnik kompresji i stwierdza, że jakość jest „w dużej mierze zachowana”. Rozdział 4 był o tym, by nie oszukiwać samego siebie, więc sprawdźmy.

Ten sam model, wagi kwantyzowane in place każdym schematem, potem trzy pomiary: perplexity na 2,048 token zatrzymanej angielskiej prozy — tutaj szkicu tego kursu, dlatego repozytorium podstawia stałą książkę z domeny publicznej i drukuje tabelę o tym samym kształcie z innymi liczbami — zestaw 16 krótkich pytań faktograficznych ze znanymi odpowiedziami przy greedy decoding oraz odsetek token, przy których model quantized zgadza się z full-precision przy identycznym context.

Cztery rzeczy w tej tabeli warto powiedzieć wprost.

INT8 zrobione poprawnie jest darmowe. Per-row INT8 daje 22.96 wobec referencyjnego 23.08 — różnica jednej części na dwieście, czyli szum, który należy czytać jako „identyczne”. Kierunek szumu nie jest stabilny: na korpusie domeny publicznej z repozytorium te same dwa schematy wychodzą 22.24 wobec 22.18: połowa tej odległości i w drugą stronę. Zgadza się z modelem full-precision na 142 ze 144 wygenerowanych token. Jedna czwarta pamięci wobec referencji fp32, połowa wobec fp16, które faktycznie byś wdrożył, i brak wykrywalnego kosztu. INT8 zrobione niedbale też jest prawie darmowe: jedna skala na macierz kosztuje 0.5 punktu perplexity i żadnej odpowiedzi z baterii. Osiem bitów wybacza na tyle, że granularność prawie nie ma znaczenia — dokładnie dlatego ludzie uogólniają z INT8 na INT4 i dostają po łapach.

INT4 z jedną skalą na tensor niszczy model. Perplexity 365 milionów: nie pogorszone, unicestwione. Granularność staje się wtedy całą grą — per-tensor 365,416,000, per-row 46.18, per-group-of-128 31.08, NF4 24.55. Te same cztery bity na wagę, czynnik piętnastu milionów między najgorszym a najlepszym.

Perplexity jest narzędziem zgrubnym, a bateria jeszcze bardziej zgrubnym. Między NF4 a group-128 INT4 luka perplexity to 6.5 punktu, a bateria różni się o jedno pytanie — a przedział ufności z Rozdziału 4 mówi, że jedno pytanie z szesnastu nie odróżnia absolutnie niczego. Jest ostrzejsza demonstracja niż przedział: uruchom tę samą baterię z wyłączoną fabryczną karą za powtórzenia modelu, czyli tym, co naprawdę oznacza greedy decoding, a te dwa wiersze zamienią się miejscami. Jedno pytanie z szesnastu to nie mały efekt, tylko brak efektu. Ostrzeżenie z Rozdziału 8 też obowiązuje: perplexity jest porównywalne tylko między modelami współdzielącymi tokenizer, więc liczby z czyjegoś opisu nie da się porównać z twoją.

Kolumna zgodności jest najostrzejsza z trzech i prawie darmowa: uruchom model full-precision zachłannie, potem zapytaj quantized, na każdej pozycji, co wybrałby przy tym samym prefiksie. Ma 144 niezależne obserwacje zamiast 16, nie potrzebuje ground truth i degraduje się płynnie tam, gdzie bateria degraduje skokami. Jest też dokładnie tą wielkością, której potrzebuje następna sekcja.

To obietnica z Rozdziału 1 dotycząca tego rozdziału, przychodząca zgodnie z planem: matematyka mówi, że 4-bitowy model jest możliwy, a inżynieria decyduje, czy jest używalny.

Rozdział 12 zapowiedział to i zostawił rachunek tutaj.

Pomysł wynika prosto z podziału prefill/decode. Weryfikacja zaproponowanej sekwencji $\gamma$ token kosztuje jeden forward pass przez $\gamma$ pozycji — iloczyn macierz-macierz, ledwie droższy niż przejście przez jedną. Więc:

Rozkład wyjściowy pozostaje bez zmian. Przy greedy decoding to oczywiste — token jest akceptowany tylko wtedy, gdy target by go wyprodukował. Przy sampling wymaga to zmodyfikowanej reguły akceptacji, a Leviathan i współautorzy dowodzą, że wynikowy rozkład jest dokładnie rozkładem target.¹⁰ To druga dokładna optymalizacja w tym rozdziale.

Wszystko zależy więc od acceptance rate $\alpha$, które jest mierzalne — to kolumna zgodności powyżej, dlatego została tam policzona. Używając każdego quantized model jako draft dla full-precision target, na 144 wygenerowanych pozycjach:

Oczekiwana liczba zaakceptowanych token na verification pass, przy długości draft $\gamma$, wynosi

a netto speedup dzieli to przez własny koszt draft, ułamek $c$ target na token:

Pogrubiony wpis to ten do zapamiętania: speculative decoding może spowolnić generation. Przy 30 % acceptance z draft kosztującym jedną piątą target płacisz za pięć forward pass i zachowujesz 1.4 token. Ostatnia kolumna to druga pułapka — dłuższy draft pomaga tylko przy wysokim acceptance, bo ogon $\gamma$-token zgadywania prawie nigdy nie jest osiągany. Przy 90 % acceptance $\gamma = 8$ jest warte 3.40x, a przy 30 % jest warte 0.79x: ta sama konfiguracja, zysk albo strata zależnie od liczby zmierzonej na twoim ruchu.

Quantization zmniejsza model przez zapisanie tej samej funkcji w mniejszej liczbie bitów. Distillation zmniejsza go przez trenowanie mniejszego modelu, by naśladował większy¹¹ — pomysł starszy od deep learning o prawie dekadę.¹²

Subtelna część dotyczy tego, z czego uczy się student. Nie z poprawnej odpowiedzi: na niej można by go wytrenować bezpośrednio. To, co dodaje teacher, to cały rozkład. Zapytaj model, co następuje po frazie, i spójrz poza argmax:

"She poured the milk into the"
  ' jug' 0.1355   ' cup' 0.1051   ' bowl' 0.0605   ' large' 0.0380   ' milk' 0.0360

Hard label mówi jug i nic więcej. Soft label mówi jug, a także że cup było prawie równie dobre, bowl prawdopodobne, a large — przymiotnik, zupełnie inna kontynuacja gramatyczna — nadal żywe. To oryginalny argument: to jest 7, ale wygląda całkiem podobnie do 1, a podobieństwo jest informacją, którą hard label wyrzuca.

To także powód, dla którego distillation używa temperatury. Podzielenie logits przez $T$ przed softmax spłaszcza rozkład i podnosi względną wagę runner-up: w tej frazie stosunek między top token a trzecim spada z 2.24 przy $T = 1$ do 1.50 przy $T = 2$ — pierwiastka kwadratowego z pierwszego, czyli tego, co podzielenie logits przez dwa robi ze stosunkiem. Ta sama kolejność, więcej attention funkcji straty na bliskich pomyłkach. Gradient studenta niesie niepewność teacher, a nie tylko jego werdykt.

Wszystko w tym rozdziale jest teraz jedną sumą:

gdzie $T$ to łączna liczba rezydentnych token we wszystkich współbieżnych request. Zastosowanie: wiersze 7B i 70B zakładają 8 key-value heads o wymiarze 128, wiersz 13B pełne multi-head attention z 40 heads, bo tak zbudowano te generacje modeli — i to widać.

8 GB

16 GB

24 GB

Spójrz na wiersz 13B w tabeli 8 GB. Wagi się mieszczą — 6.2 GB z 8 — więc w zwykłym sposobie mówienia model 13B „działa na karcie 8 GB”. Ma 337 token kontekstu, czyli nie rozmowę, lecz ledwie prompt. „Czy się mieści” to złe pytanie. Właściwe brzmi: „z jakim context i dla ilu użytkowników naraz”.

Spójrz też na dwa wiersze int8 w tabeli 16 GB. 7B dostaje 65,378 token, a 13B dostaje 3,136 — dwudziestokrotna różnica z 5.6 GB dodatkowych wag, bo ten 13B ma multi-head attention, a jego cache kosztuje 800 KB na token wobec 128 KB dla 7B. Dwa modele podobnego rozmiaru, jeden bezużyteczny dla long context, z powodu, którego nie ma w nagłówku żadnej model card.

Trzynaście rozdziałów temu był to perceptron z dwiema wagami i bias. Teraz jest to transformer, który został zaprojektowany, wytrenowany, aligned, nauczony wydawać compute na trudne pytania i serwowany przy zmierzonym koszcie na token — bez żadnego nieotwartego pudełka w środku.

To kończy się tutaj, i kończy się celowo.

Rozdział 14 zaczyna się z modelem gdzieś indziej. Nie w twoim procesie, nie w twojej pamięci, nie w zmiennej, którą możesz wydrukować: na maszynie, której nie administrujesz, za kluczem API, portem i rachunkiem. Wszystko zmierzone tutaj nadal się dzieje — prefill nadal działa przed pierwszym token, cache nadal rośnie z rozmową, batch, w którym jesteś, nadal należy do kogoś innego i nadal decyduje o twoim latency — ale od teraz obserwujesz to przez strumień Server-Sent Events, finish_reason i HTTP 429 z nagłówkiem Retry-After. Pytania zmieniają się wraz z punktem widzenia: nie jak liczony jest ten gradient, lecz dlaczego moja faktura potroiła się. Język też się zmienia, a Rozdział 14 wyjaśnia tę regułę zamiast ją ogłaszać — do tego miejsca kod trzymał wagi, gradienty, logits i bajty tokenizer; odtąd trzyma połączenie, retry, cancellation i zgromadzony stan. Trzynaście rozdziałów za tobą nie zostaje wyrzuconych przy przekroczeniu granicy. Są opisem tego, co działa po drugiej stronie portu.

Dwa pominięcia są celowe. FlashAttention (Dao et al., arXiv:2205.14135) nie jest innym attention — liczy tę samą funkcję przez kafelkowanie operacji tak, aby macierz wyników $n \times n$ nigdy nie została zapisana do pamięci, dlatego 67 MB w drugiej tabeli tego rozdziału jest w praktyce mniejsze, niż sugeruje arytmetyka. A same kernels są delegowane: wykład 10 Stanford CS336 omawia systemy inference na głębokości, której ten tekst nie próbuje osiągnąć, a repozytorium llama.cpp i specyfikacja GGUF są głównymi źródłami dla strony CPU.