Inferencja LLM od początku do końca: prefill, decode, cache KV i próbkowanie

Od naciśnięcia klawisza do strumieniowego tokena

To przewodnik opisuje całą ścieżkę inferencji — tokenizator, embeddingi, uwaga, bufor KV, próbkowanie, dekodowanie spekulatywne — oraz odpowiada na trudne pytania na każdym etapie. Celem jest model mentalny gotowy do przedstawienia, a nie prezentacja dostawcy.

Część 1 — Dwa obciążenia, nie jedno

Q1. Co dzieje się między naciśnięciem klawisza Enter a pierwszym słowem?

Szczerzy opis całego procesu:

1. Wejście. Przychodzi ciąg UTF-8, np. "What is gravity?". Warstwa obsługi zazwyczaj otacza go szablonem czatu z specjalnymi tokenami dla ról systemu, użytkownika i asystenta.
2. Tokenizacja. Tekst jest dzielony na fragmenty i przyporządkowywany do identyfikatorów całkowitych. Ten krok to czysta obróbka ciągów znaków — jeszcze bez sieci neuronowych.

Wyszukiwanie w macierzy embeddingów. Każdy identyfikator wybiera wiersz z macierzy embeddingów E ∈ ℝ^(V × d_model), co daje tensor o wymiarach (seq_len, d_model). Sygnał pozycyjny jest dodawany tutaj lub później w mechanizmie uwagi (RoPE).

Prefill. Każdy token promptu przechodzi przez wszystkie N warstw transformera razem. Każda warstwa przechowuje swoje projekcje K i V w cache’u KV. Ta faza jest ograniczona zasobami obliczeniowymi.

Głowa LM. Tylko stan ukryty ostatniej pozycji jest projektowany na rozmiar słownika (~128K logitów).

Próbkowanie. Funkcja Softmax przekształca logity w rozkład; polityka (greedy, top-k, top-p, temperatura itp.) wybiera jeden identyfikator.

Pętla dekodowania. Ten identyfikator jest dodawany, wstawiany i ponownie przekazywany przez stos wraz z pamięcią cache KV — po jednym nowym tokenie na krok — aż zostanie uruchomiona zasada zatrzymania.

Detokenizacja i przesył strumieniowy. Identyfikatory stają się fragmentami tekstu; serwer może wysyłać częściowe łańcuchy do klienta, gdy tylko staną się ważne.

Czas do pierwszego tokena to niemal zawsze etap wypełniania początkowego. Wszystko, co następuje później, to proces dekodowania.

Q2. Dlaczego inferencję nazywa się dwoma różnymi obciążeniami?

Wypełnianie początkowe i dekodowanie znajdują się po przeciwnych stronach modelu roofline.

Wąskie gardło FLOPs / obliczenia Szerokość pasma pamięci Intensywność arytmetyczna Wysoka ~1–2 FLOPs/byte przy partii 1 Pomiędzy tokenami Całkowicie równolegle Etycznie sekwencyjnie Czynnik opóźnienia TTFT TPOT / ITL Miara skalowania Długość promptu Długość wyniku MFU (partia 1) Często 40–60% Często 1–5%

W trybie prefill ładujesz wagi raz i stosujesz je do tysięcy wektorów tokenów. W trybie decode ponownie ładujesz te same wagi dla jednego wektora — gigabajty danych są przemieszczane przy milionach FLOPs. GPU czeka na dane z HBM.

Prawie każda sztuczka związana z przetwarzaniem danych — grupowanie zadań, cache typu KV, kwantyzacja, dekodowanie spekulatywne, FlashDecoding, rozdzielone wcześniejsze uzupełnianie danych/dekodowanie — ma na celu zaopatrzenie tej spragnionej jednostki obliczeniowej.

Q3. Które metryki opóźnienia są istotne i które parametry je wpływają?

• TTFT — głównie wcześniejsze uzupełnianie danych; rośnie wraz z długością promptu (a jeszcze bardziej, gdy dominuje mechanizm uwagi). Pomaga cache z prefiksami, uzupełnianie danych w partiach, szybszy mechanizm uwagi oraz krótsze prompty.
• TPOT / ITL — głównie dekodowanie; mniej więcej bytes_per_step / bandwidth. Pomaga kwantyzacja, GQA/MQA, dekodowanie spekulatywne oraz mniejsze modele.
• End-to-end ≈ TTFT + TPOT × liczba tokenów wyjściowych.
• Przepustowość (tokeni/s/GPU) — metryka dotycząca całej grupy urządzeń; większe partie zwiększają ją, choć zazwyczaj pogarszają TPOT na użytkownika.

Przepustowość i opóźnienie są ze sobą sprzeczne. Polityka serwowania polega na wyborze punktu na tej krzywej.

Q4. Dlaczego dekodowanie nie może być zparalelizowane tak jak prefill?

Generowanie jest autoregresywne: każdy nowy token zależy od wszystkich poprzednich. Prefill już zna całe wezwanie, więc pozycje mogą być obliczane razem pod maską przyczynowo-skutkową. W przypadku dekodowania „przyszłość” jeszcze nie istnieje.

Rozwiązaniem jest dekodowanie spekulatywne: tworzy się tanie przypuszczenia, a następnie weryfikuje je w jednej równoległej fazie przetwarzania — co zamienia sekwencyjną zależność na równoległą weryfikację (Część 8).

Część 2 — Etapy pierwszy i drugi: wprowadzanie tekstu

Q5. Co to jest token — i dlaczego całe słowa lub surowe znaki to błędne skrajności

Token to atom podsłowa w ustalonej słowniczce. Czyste skrajności nie działają:

• Słowniki słów nie mają ograniczeń; błędy pisarskie i rzadkie nazwy zamieniają się w <UNK>, niszcząc informacje i powodując rozszerzenie tabeli embeddingów.
• Słowniki znaków unikają przypadków OOV, ale wydłużają sekwencje 4–5 razy, co utrudnia działanie mechanizmu uwagi kwadratowej i zmusza wczesne warstwy do ponownego odkrywania struktury morfologicznej.

Podsłowa znajdują złoty środek: powszechne słowa pozostają nienaruszone; rzadkie formy dzielą się na sensowne fragmenty; nic nie jest naprawdę OOV.

Q6. Jak szkolony jest BPE?

Byte-Pair Encoding zaczyna od znaków (lub bajtów) i wielokrotnie łączy najczęstsze sąsiednie pary, aż zostanie osiągnięta wymagana wielkość słownika. Te łączenia są przechowywane jako uporządkowana lista. Podczas inferencji stosuje się te same łączenia w sposób prosty, od lewej do prawej. Szkolenie opiera się na statystykach ilościowych, a nie na spadku gradientu — jednak uzyskana struktura segmentacji wpływa na wszystko w dalszej części procesu.

Q7. BPE vs WordPiece vs Unigram / SentencePiece

• BPE — łączenie według częstotliwości; dekodowanie jest deterministyczne przy użyciu tabeli łączeń.
• WordPiece (z okresu BERT) — podobne łączenia, ale oceniane według prawdopodobieństwa; często używa markerów kontynuacji ##.
• Unigram / SentencePiece — zaczyna od dużego zbioru kandydatów i wycinaje elementy za pomocą modelu unigramowego; może generować różne segmentacje i sprawnie obsługuje surowe bajty/Unicode bez konieczności użycia narzędzi specyficznych dla danego języka.

Dzisiejsze modele LLM w produkcji preferują wersje BPE lub SentencePiece na poziomie bajtów.

Q8. Dlaczego BPE na poziomie bajtów?

Praca z surowymi bajtami gwarantuje, że każda ścieżka tekstowa może zostać zakodowana — bez nieoczekiwanych problemów z Unicode. Słowniczek nadal uczy się częstych fragmentów wielobajtowych, dzięki czemu język angielski pozostaje wydajny, natomiast rzadsze systemy pisma są stopniowo przekształcane w alternatywy oparte na bajtach.

Q9. Dlaczego modele mają trudności z liczeniem liter w „strawberry”?

Ponieważ model nigdy nie widzi znaków; widzi identyfikatory tokenów. Jeśli "strawberry" składa się z jednego lub dwóch elementów, polecenie „licz litery r” wymaga struktury, która została już odrzucona przed pierwszą warstwą. Zadania na poziomie znaków wymagają albo tokenizera, który zachowuje znaki, albo zewnętrznego narzędzia.

Q10. Czy identyfikatory tokenów same w sobie coś znaczą?

Nie. ID to jedynie indeks w tabeli embeddingów danego modelu. ID 100 w jednym tokenizerze nie ma związku z ID 100 w innym. Nigdy nie łącz tokenizerów z różnych modeli.

Q11. Pułapki przy użyciu tokenizera w produkcji

• Środowiska do rozmów i specjalne tokeny muszą odpowiadać tym użytym podczas treningu.
• Pierwsze spacje często stają się oddzielnymi tokenami — " Hello" ≠ "Hello".

Przycięcie może w tajemnicy usunąć instrukcje systemowe, jeśli liczy się znaki zamiast tokenów.

Multijęzyczne alternatywy oparte na bajtach zwiększają długość i koszt.

Specjalne tokeny multimodalne dla obrazów i dźwięku zmieniają zasady pakowania.

Q12. Kompromisy między rozmiarem słownika a wydajnością

Większy rozmiar V skraca sekwencje i ułatwia obsługę wielu języków, ale zwiększa parametry embeddingów oraz głowy modelu LM (V × d_model dla każdego z nich) oraz koszt dekodowania metodą softmax. Typowe współczesne wartości wynoszą około 32K–150K; powyżej tego trzeba płacić za pamięć i przepustowość przy malejących korzyściach.

Q6. Jak faktycznie trenuje się BPE

Kodowanie par bajtowych jest formą kompresji wykorzystywanej do nauki słownika:

1. Załaduj słownik podstawowymi symbolami (dla BPE na poziomie bajtów: wszystkie 256 bajtów).
2. Przedstaw zbiór tekstowy jako sekwencje tych symboli.
3. Licz przyległe pary; wybierz te najczęstsze.

Zlóż tę parę w nowy symbol, dodaj go do słownika i zapisz odpowiadającą jej zasadę łączenia.

Powtarzaj to, aż osiągniesz pożądaną wielkość (na przykład około 100K–128K w nowoczesnych rozwiązaniach).

Artefakty: mapa symbol→ID oraz uporządkowana lista łączeń. Kodowanie podczas odtwarzania procesów inferencji przeprowadza łączenia w tej kolejności – w sposób deterministyczny, bez szukania najkrótszych możliwych segmentów.

Uwagi: łączenia optymalizują częstotliwość występowania, a nie aspekty językoznawcze. ing staje się tokenem, ponieważ jest często używany. Elegancja morfologiczna ma drugorzędne znaczenie.

Q7. BPE vs WordPiece vs Unigram / SentencePiece

• BPE (GPT, Llama): łączenia oparte na częstotliwości; kodowanie deterministyczne.

WordPiece (z okresu BERT): podobny mechanizm, ale wybiera fuzje, które maksymalizują prawdopodobieństwo danych treningowych w modelu unigramowym — oceniając, na ile pary są informacyjne razem w porównaniu z osobno.

Unigram LM (często za pośrednictwem SentencePiece; klasa T5/Gemma): zaczyna od dużego rozmiaru i usuwa tokeny, których usunięcie najmniej wpływa na prawdopodobieństwo. Segmentacja probabilistyczna umożliwia regularizację podsłówkową (wybieranie alternatywnych rozcięć podczas treningu).

SentencePiece to biblioteka, która może wykonywać BPE lub Unigram. Jej praktyczną zaletą jest traktowanie surowych znaków z widocznym markerem przestrzeni, dzięki czemu tokenizacja jest odwracalna i nie wymaga pre-tokenizacji przestrzeni — co jest kluczowe dla języków chińskiego, japońskiego i tajskiego.

Q8. BPE na poziomie bajtów jest ważne, ponieważ…

Inicjały składające się z znaków Unicode wymagałyby około 150 tysięcy symboli początkowych, a mimo to nadal potrzebny byłby <UNK>. Korzystanie z bytes UTF-8 oznacza, że każda sekwencja tekstu — emoji, pismo cyrylickie, uszkodzone bajty — może zostać zakodowana. Nie ma problemu z przekroczeniem zakresu.

Koszt: emoji mogą zużyć wiele tokenów; pisma niełacińskie często wymagają 2–4 razy więcej zasobów niż pismo angielskie przy tym samym znaczeniu, więc użytkownicy korzystający z języków innych niż angielski szybciej napotykają ograniczenia ilościowe i problemy z kontekstem. Większe zasoby słownictwa (skoki od 32 tysięcy do 128 tysięcy znaków) istnieją częściowo po to, by zmniejszyć tę różnicę w sprawiedliwości.

Q9. Dlaczego pytanie „ile liter ‘r’ jest w słowie strawberry?” nie działa?

Sieć nigdy nie widzi liter; widzi identyfikatory. Jeśli strawberry składa się z kilku podsłów, liczenie znaków wymaga odzyskiwania pisowni z embeddingów i jej agregacji — nie istnieje wbudowana operacja „przechodzenia po znakach”. Ta sama problematyka występuje w przypadku anagramów, palindromów, odwróceń oraz prostej arytmetyki, gdy grupowanie cyfr jest niespójne w różnych liczbach. Współczesne tokenizery czasami wymuszają podział cyfr specjalnie po to, aby arytmetyka mogła być wykorzystywana.

Q10. Identyfikatory tokenów w izolacji

Identyfikator to indeks do tabel danego modelu. Porównywanie tokenizerów nie ma sensu. Nawet „specjalne” identyfikatory różnią się pomiędzy poszczególnymi rodzinami.

Q11. Pułapki, które występują w produkcji

Zobowiązujące jest dopasowanie szablonu rozmowy używanego do treningu oraz zestawu specjalnych tokenów. Przestrzenie na początku zwykle stanowią rzeczywiste tokeny. Liczenie znaków przy fakturowaniu przez API w oparciu o tokeny powoduje ciche skracanie instrukcji. Tokeny sentymentalne wielomodalne zmieniają sposób pakowania danych. Klucze cache muszą zawierać informację o wersji tokenizera. Niewłaściwe obsługiwanie sygnałów BOS/EOS zakłóca warunki zatrzymania procesu oraz audyty wartości logprob.

Q12. Kompromisy między rozmiarem słownika a jakością

V skraca sekwencje i ułatwia pakowanie danych wielojęzycznych, ale zwiększa rozmiar parametrów embeddingów oraz głowy modelu LM oraz funkcji decode softmax. Po osiągnięciu liczby około 100K–200K zwykle trzeba płacić za pamięć i przepustowość tylko po to, by uzyskać niewielkie ulepszenia jakości, chyba że wymaga tego obsługa wielu języków.

Część 3 — Embeddingi

Q13. Embeddingi: metoda gather vs matmul

Wyszukiwanie wiersza jest równoznaczne z mnożeniem wektora one-hot przez E. Metoda gather służy do gromadzenia danych, natomiast obliczenia pozostają liniowe.

Q14. Czy ma to charakter kontekstowy?

Wiersze wejściowe są niekontekstowe. Kontekst jest budowany poprzez uwagę między warstwami. Embeddingi używane do wyszukiwania to zazwyczaj głębsze stany, a nie wiersze tabeli wejściowej.

Q15. Powiązanie wag

Dzielenie się wagami embeddingów z głową LM (przekształcenie transponowanym) służy do oszczędzania parametrów — jest to powszechne w mniejszych modelach. Duże LM często rozwiązują to powiązanie dla lepszej jakości. Powiązane głowy nie stanowią dodatkowej, niezależnej macierzy d × V.

Q16. Informacje pozycyjne

Absolutne embeddingi dodają wektory dla każdego indeksu. RoPE obraca wartości Q/K, dzięki czemu względne odchylenia pojawiają się w wynikach i współpracują z buforowaniem KV. Alternatywą są schematy względnych biasów; RoPE dominuje w nowych LLM.

Q17. RoPE i rozszerzenie na długie konteksty

Geometria względna RoPE daje lepsze wyniki przy ekstrapolacji niż proste tabele absolutne. Rozszerzenia (interpolacja pozycji, skalowanie uwzględniające NTK, YaRN itp.) przeskalowują częstotliwości obrotowe, dzięki czemu dłuższe konteksty pozostają stabilne bez konieczności szkolenia od zera.

Q18. Czynnik √d_model

Gdy wektory tokenów i pozycji są dodawane, mogą występować konflikty skalowania; mnożenie wektorów embeddingów przez √d_model zapewnia ich równowagę. Struktury RoPE oparte na rotacji często pomijają to mnożenie.

Część 4 — Blok transformera

Q19–Q23. Mechanizmy uwagi (rozszerzone)

x → MultiHeadSelfAttention → Add & Norm → FFN → Add & Norm → out

Attention(Q, K, V) = softmax(QKᵀ / √d_k) V

Zapytania szukają, klucze reklamują, wartości dostarczają. Softmax na skalowanych punktach daje wagi mieszające. Dzieli się przez √d_k, aby wyniki nie były przeciążone w miarę wzrostu szerokości. Wiele głow decyzyjnych zróżnicowuje podprzestrzenie. Maska przyczynowa wpisuje −∞ do zabronionych przyszłości, dzięki czemu masa softmax wynosi dokładnie zero — zerka w masce nadal mogłyby przeciekać informacje. Podczas czystego dekodowania z pamięcą cache, zbiór kluczy nie zawiera pozycji przyszłych, więc maska jest domyślna; mimo to konieczne jest maskowanie (lub użycie jądra przyczynowego).

Q24–Q26. Kształty, koszt, reszty

Każda projekcja ma rozmiar około d × d (zmodyfikowana w ramach GQA). FFN dominują pod względem liczby parametrów, przy około 4-krotnym zwiększeniu. Koszt uwagi rośnie wykładniczo jak O(n² d), natomiast FFN – jak O(n d²). Krótkie prompty: ograniczenia wynikające z masy i FFN. Długie konteksty: dominują mechanizmy uwagi oraz pamięć KV. Reszty pozwalają na szkolenie głębokich struktur poprzez dostarczenie „autostrad gradientowych” oraz dodatkowych ulepszeń.

Q27–Q30. Normy, szerokość FFN, aktywacje, MoE

RMSNorm pomija krotność średniej i jest tańszy od LayerNorm. Pre-norm stabilizuje bardzo głębokie sieci w porównaniu z klasycznym post-norm. Szerokie FFN (~4×) zapewniają większą pojemność na każdy token pomiędzy mechanizmami mieszania uwagi. Nieliniowości zapobiegają załamaniu się warstw liniowych; SwiGLU odniosło sukcesy w wielu eksperymentach z LLM. MoE kieruje tokeny do kilku specjalistycznych FFN, dzięki czemu liczba parametrów rośnie szybciej niż FLOPs na token – metoda ta wymaga dużo pamięci, ale jest mniej intensywna pod względem obliczeniowym.

Q31–Q32. Głębokość/szerokość oraz warianty uwagi

Głębokość powtarza proces mieszania; szerokość wzbogaca cechy. Laboratoria dokonują wyboru w ramach ograniczeń danych i klastrów. MHA przechowuje wartości K/V dla każdego elementu; MQA dzieli się jedną wartością K/V pomiędzy różne zapytania; GQA dzieli je w ramach grupy; MLA dodatkowo kompresuje te wartości K/V. Koszty serwowania napędziły rozwój branży zgodnie z tą sekwencją.

Część 5 — Pamięć cache KV

Q33. Co to jest pamięć cache KV i dlaczego tylko K i V?

Na etapie dekodowania t przychodzi jeden nowy token. Jego zapytanie q_t musi sprawdzić klucze i wartości dla pozycji 1..t. Klucze i wartości dla 1..t−1 zależą wyłącznie od wcześniejszych tokenów oraz ustalonych wag. Zasada przyczynowości gwarantuje, że wprowadzenie tokena t nie może zmienić tych wcześniejszych tensorów K/V — są one niezmienne — więc są obliczane raz i przechowywane.

Zapytania się różnią: do bieżącego kroku potrzebny jest tylko q_t. Starsze zapytania już wygenerowały starsze wyniki i nigdy nie zostaną ponownie odczytane, więc przechowywanie Q to marnotrawstwo pamięci.

Bez cache’u emisja tokena t wymusiłaby ponowne przetworzenie całego prefiksu — praca ta rośnie gwałtownie wraz z długością. Z cache’em uwaga na każdym kroku jest liniowa względem aktualnej długości, a FFN faktycznie wymaga stałej ilości obliczeń na każdy nowy token. Generowanie staje się liniowe w zależności od liczby kroków dekodowania, zamiast kwadratowe w zależności od liczby przejść.

Q34. Wyznaczenie rozmiaru cache’u KV za pomocą rzeczywistej liczby

KV bytes = 2 (K and V)
         × n_layers
         × n_kv_heads × d_head
         × seq_len
         × batch_size
         × bytes_per_element

Użyjmy układu GQA typu Llama-3–70B: osiemdziesiąt warstw, osiem głow klucz/wartość, sto dwadzieścia osiem wymiarów na każdą głowę, przechowywanych jako liczby zmiennoprzecinkowe o długości dwóch bajtów.

Mnożąc te czynniki: dwa tensory (K i V) × osiemdziesiąt × osiem × dwadzieścia osiem jeden × dwa bajty dają wynik bliski 320 KB na każdy token w każdej żywej sekwencji.

Gdy rozszerzymy to do dialogu z 8k tokenów, ilość danych wynosi około 2,6 GB na jednego użytkownika. Przy kontekście 128k ta sama formuła wskazuje na dziesiątki GB – tyle, że jedna rozmowa może zajmować znaczną część urządzenia klasy H100, zanim w ogóle uwzględniony zostanie problem wag.

Sytuacja hipotetyczna bez GQA (64 głowy KV): wartość dla 8K skacze do około ~21 GB na sekwencję. GQA stanowi różnicę między dziesiątkami jednoczesnych użytkowników a zaledwie kilkoma.

Wagi to jednorazowy, stały podatek. Cache KV stanowi bezgraniczny podatek, obliczany indywidualnie dla każdego użytkownika i każdego tokena. Określa on maksymalną wielkość partii, co z kolei wpływa na przerobność i ostatecznie na koszt w dolarach za milion tokenów. Dlatego też w diagramach określa się go jako główny wąskie gardło pamięci.

Q35. Dlaczego dekodowanie jest ograniczone przez pamięć — aspekty arytmetyczne

Rozważmy model 70B w formacie fp16, który przy jednej partii generuje jeden token:

• Liczba przesuniętych bajtów: około 140 GB wag plus kilka GB danych KV ≈ 142 GB.
• FLOPs: ≈ 2 × 70e9 × 1 = 140 GFLOPs.
• Intensywność obliczeń: ≈ 1 FLOP/bajt.

Karta H100 oferuje prędkość przesyłu danych w pamięci HBM na poziomie około 3,35 TB/s oraz moc obliczeniową w formacie fp16 na poziomie około 1000 TFLOPs. Punkt, w którym obliczenia dorównują przepustowości pamięci, występuje przy setkach FLOPs/bajt. Przy intensywności 1 FLOP/bajt wykorzystujemy znikomą część maksymalnych możliwości jednostek obliczeniowych — karta graficzna pełni głównie rolę przewoźnika danych pomiędzy pamięciami.

Czas przetwarzania ściany ≈ 142 GB / 3,35 TB/s ≈ 42 ms → około 24 tokena/s tylko dzięki przepustowości. W rzeczywistych systemach wyniki wahają się w granicach dwukrotności tej wartości, co pokazuje, jak silnie reguły związane z przepustowością wpływają na wyniki.

Korolarnia: zwiększanie rozmiaru partii jest praktycznie bezkosztowe dla ruchu związanych z wagami, dopóki nie wystąpi ograniczenie wynikające z mocy obliczeniowej. Przejście od partii 1 do 32 umożliwia ponowne użycie jednego obciążenia wag w 32 sekwencjach, co może zwiększyć przepustowość tokenów. Ta amortyzacja stanowi kluczowy aspekt ekonomiczny serwowania modeli LLM.

Q36. Jeśli grupowanie jest „bezkosztowe”, dlaczego nie używać partii 512?

Ponieważ każda sekwencja wymaga własnej przestrzeni KV, a pamięć cache skaluje się z batch × seq_len:

GPU memory = model weights + KV cache + activations + fragmentation overhead

Przykład: 140 GB wag na 2×H100 (160 GB) pozostawia około 20 GB na cache. Przy 320 KB/token oznacza to około 65 tysięcy tokenów w całej partii. Szesnaście użytkowników z kontekstem 4K już wypełnia to limity.

Zatem wielkość bloków KV ogranicza rozmiar partii, a to z kolei ogranicza przepustowość. Mechanizmy takie jak GQA, MLA, kwantyzacja pamięci cache, struktury paginacji oraz zasady wyrzucania to funkcje zapewniające przepustowość, które „udają” elementy pamięci.

Q37. PagedAttention i problem fragmentacji

Serwery prostsze rezerwują dla każdego żądania ciągły obszar pamięci KV o długości do max_seq_len. To powoduje problemy na dwa sposoby:

• Fragmentacja wewnętrzna — uzupełnienie tekstu składającego się z 100 tokenów, przy rezerwowaniu 4096 slotów, marnuje większość dostępnej przestrzeni.
• Fragmentacja zewnętrzna — zwolnione obszary o różnych rozmiarach tworzą luki, w które nie można umieścić nowych bloków pamięci.

Marnotrawstwo pamięci w takich prostych mechanizmach alokacji wynosi często od 60 do 80% całej pamięci KV.

PagedAttention (upowszechniony przez vLLM) kopiuje koncepcję wirtualnej pamięci systemu operacyjnego: bloki o stałej wielkości (np. 16 tokenów) wraz z tablicą bloków, która mapuje pozycje logiczne na fizyczne bloki w całym zasobie. Bloki są przydzielane w miarę wzrostu długości generowanego tekstu.

Korzyści:

• Znikoma fragmentacja → często 2–4 razy więcej sekwencji mogą działać jednocześnie na tych samych kartach graficznych.
• Dzielenie się prefiksem / kopiowanie przy zapisie — wiele zapytań z tym samym promptem dzieli fizyczne bloki, dopóki ich sufiksy się nie różnią; idealne dla agentów, instrukcji RAG oraz przy pracy z małą liczbą przykładów.
• Strumienie i próbki równoległe dzielą wspólny prefiks zamiast go klonować.

Ceną jest pośrednictwo oraz jądro uwagi, które zbiera dane z nieprzylegających do siebie bloków.

Q38. Batchowanie statyczne vs ciągłe

Statyczne grupowanie czeka, aż zostanie napełniona partia, uruchamia wszystkie sekwencje jednocześnie zgodnie z najdłuższą z nich i uzupełnia braki. Krótkie żądania muszą czekać na dłuższe; karty graficzne tracą zasoby na obsługę tokenów uzupełniających.

Kontynuowe (na poziomie iteracji) grupowanie odbudowuje partię na każdym kroku dekodowania: zakończone sekwencje opuszczają partię, a nowe do niej wchodzą, przy czym karta graficzna pracuje wyłącznie nad aktualnymi tokenami. Zmienność opóźnień spada, a wydajność znacznie rośnie – to standard we współczesnych silnikach (vLLM, TensorRT-LLM itp.).

Q39. Przedwypełnianie w fragmentach i rozdzielenie przedwypełniania od dekodowania

Przedwypełnianie obejmujące tysiące tokenów może zmonopolizować kartę graficzną i spowolnić dekodowanie dla użytkowników interaktywnych. Przedwypełnianie w fragmentach dzieli długie polecenia na mniejsze części, które są mieszane z krokami dekodowania, dzięki czemu czas od pierwszego tokenu do odpowiedzi nieco wzrasta, ale czas całkowitej obsługi pozostaje bardziej stabilny.

Rozbicie na części idzie jeszcze dalej: wykonywanie operacji wypełniania uprzednio na pulach optymalizowanych pod obliczenia oraz dekodowanie na pulach optymalizowanych pod pamięć, przy czym dane KV są przesyłane przez sieć. Zwiększa to złożoność orkiestracji, ale dopasowuje każdą fazę do sprzętu, który faktycznie jest obciążany.

Q40. Zmniejszanie rozmiaru danych KV poza GQA

Sposoby obejmują:

• MQA / GQA / MLA — mniej lub skompresowane elementy danych KV.
• Kasety kwantyzowane (w stylu INT8/FP8/NF4) — często niemal bezstratne dla danych K/V.
• Uwaga okienkowa / przesuwna — pomijanie odległych tokenów, gdy zadanie na to pozwala.
• Zasady wyrzucania / strumieniowania dla ekstremalnych warunków.
• Mnogokrotnego wykorzystania między warstwami – pomysły badawcze polegające na wspólnym wykorzystywaniu informacji między poszczególnymi warstwami.

Każda z tych metod poświęca nieco jakości lub uniwersalności w zamian za większą efektywność wykorzystania pamięci.

Q41. Cacheowanie prefiksów — gdy zmienia się architektura

Jeśli wiele połączeń dzieli długi, niezmienialny prefiks (prompt systemu, schematy narzędzi, pobrany kontekst), przechowywanie w pamięci tymczasowej par klucz-wartość tego prefiksu pozwala uniknąć ich ponownego obliczania. W takich architekturach preferowane są stabilne prefiksy oraz zmiennicze sufiksy: niestabilny tekst użytkownika umieszcza się na końcu, natomiast wspólna część pozostaje identyczna na poziomie bajtów, aby klucze pamięci cache były trafne. Teksty produktowe oraz kompilatory promptów stają się elementem wpływającym na wydajność.

Q42. Kiedy pamięć cache klucz-wartość staje się nieważna?

W każdym momencie, gdy tokeny są modyfikowane, a nie tylko dodawane: przy regeneracji w trakcie rozmowy, przepisywaniu promptu systemu, zmianie definicji narzędzi lub stosowaniu modyfikacji niesprzężonych czasowo. Pamięci cache prefiksów muszą być kluczowane na podstawie dokładnej tożsamości tokena (oraz wersji szablonu). Parametry próbkowania nie sprawiają, że dane K/V stają się nieważne – zmieniają jedynie sposób przekształcania logitów w kolejny identyfikator – natomiast zmiana adaptera modelu, wersji roboczej modelu lub skali RoPE w trakcie pracy może to spowodować.

Część 6 — Głowa LM (liniowa + softmax)

Q43. Co robi głowa LM i jakie ma kształty

Ostatni blok wytwarza h ∈ ℝ^(seq_len × d_model). Po ostatniej normalizacji jedna mapa liniowa generuje logity słownika:

logits = h @ W_lm      W_lm ∈ ℝ^(d_model × V)

Dla d_model = 4096 i V = 128,000, W_lm zawiera 524M parametrów i daje wektor o szerokości 128K dla każdej ocenianej pozycji.

Q44. Czy podczas dekodowania istnieją logity dla każdej pozycji?

Nie. Prefill może oceniać wiele pozycji podczas treningu lub dla określonych API, ale zwykła dekodacja wymaga tylko stanu ukrytego ostatniej pozycji. Wcześniejsze pozycje już wybrały swoje tokeny.

Q45. Koszt działania głowy LM podczas dekodowania

Każdy krok mnoży wektor d przez d × V – co generuje około 2 × d × V operacji FLOP oraz pełne odczytanie potencjalnie niepowiązanego elementu. Przy dużych wartościach V jest to porównywalne z działaniem fragmentu FFN, co skłania do stosowania adaptacyjnego softmax, równoległego dzielenia słownika oraz powiązanych embeddingów, gdy jest to dozwolone.

Q46. Logity a prawdopodobieństwa

Logity to nieograniczone wyniki oceny. Softmax je normalizuje:

p_i = exp(z_i) / Σⱼ exp(z_j)

Pamiętaj o niewzględności względem przesunięcia: dodanie stałej do wszystkich logitów nie zmienia prawdopodobieństw – to podstawa stabilnych implementacji oraz zastosowania temperatury jako metody skalowania różnic.

Q47. Numericznie stabilny softmax

Naiwne zastosowanie exp(z_i) powoduje przepełnienie w formacie fp16 przy umiarkowanych wartościach logitów, a także może spowodować obniżenie całego wiersza do zera, co skutkuje błędem 0/0. Rozwiązaniem jest najpierw odejmowanie maksymalnej wartości z wiersza:

p_i = exp(z_i − max(z)) / Σⱼ exp(z_j − max(z))

Największy wyraz wynosi exp(0) = 1; pozostałe znajdują się w przedziale (0, 1]. Algorytmy online (jak w FlashAttention) łączą to z operacją matmul, aby uniknąć tworzenia ogromnych macierzy ocen.

Q48. Perplexity

Perplexity to exp(średnia ujemna log-likelihood) dla tokenów — pokazuje, na ile „zaskoczony” jest model. Oblicza się ją z tej samej fazy logits/softmax. Niższy poziom perplexity w danym domenie wskazuje na lepszą kalibrację kolejnych tokenów, ale nie jest to bezpośrednia miara użyteczności czy bezpieczeństwa.

Część 7 — Strategie próbkowania

Po modułowaniu językowym mamy wektor logits. Probkowanie to sposób, w jaki ten wektor staje się kolejnym ID.

Q49. Dekodowanie chciwe — i dlaczego jest rozczarowujące

Metoda chciwa zawsze wybiera argmax. Jest deterministyczna i tania, ale często nudna lub lokalnie uparta: wczesne tokeny o wysokiej prawdopodobieństwie mogą uwięzić sekwencję w powtarzalnych, wysokoprawdopodobieństwowych pętlach, które człowiek uznaje za gorsze od alternatyw o nieco niższym prawdopodobieństwie. Używaj jej do zadań wymagających wrażliwej ekstrakcji; unikaj jej jako domyślnej metody przy prozie otwartej.

Q50. Dlaczego nie metoda poszukiwania wiązki?

Metoda poszukiwania wiązki przechowuje B najlepszych częściowych hipotez. Jest przydatna, gdy cel jest krótki i ograniczony (w stylu tłumaczenia). W przypadku otwartych rozmów ma tendencję do generowania ogólnikowego, bezpiecznego pod względem prawdopodobieństwa tekstu, wymaga obliczeń w ilości B× i źle współpracuje z różnorodnością typu nucleus. Większość aplikacji opartych na LLM porzuciła ją na rzecz metody próbkowania.

Q51. Top-k

Zachowaj tylko k największych wartości logits, znormalizuj je ponownie i wybierz próbkę. Proste rozwiązanie, ale k jest zbyt sztywne: czasami masa prawdopodobieństwa poza grupą top-k nadal ma znaczenie; czasami top-k zawiera nieistotne wartości, gdy rozkład jest ostry. Stała wartość k nie może dostosować się do stopnia ostrości rozkładu.

Q52. Top-p (jądro)

Ułóż wartości według prawdopodobieństwa, zachowaj najmniejszą zbiór, którego łączna masa wynosi co najmniej p, a następnie wybierz próbkę. Gdy model jest pewny siebie, jądro się kurczy; gdy niepewny – rozszerza. To właśnie ta zdolność adaptacji sprawia, że top-p zastąpił stałe top-k jako standard w wielu systemach. Typowe wartości p wynoszą około 0,9–0,95 i są dostosowywane indywidualnie dla każdego produktu.

Q53. Temperatura — matematyka i intuicja

p_i = exp(z_i / T) / Σⱼ exp(z_j / T)

Przed zastosowaniem funkcji softmax podziel wartości logits przez T.

• T → 0 — różnice między wartościami rosną gwałtownie; rozkład sprowadza się do wartości argmax (metoda chciwa).
• T = 1 — nieskalowany rozkład modelu.

T > 1 — spłaszczenie rozkładu; większa ilość niespodzianek i ryzyko niejednoznaczności.

W implementacji temperatura sama w sobie nie „dodaje losowości” — ona jedynie zmienia rozkład, z którego czerpie sampler.

Q54. Kolejność: temperatura vs obcięcie

Najpierw zastosuj temperaturę do logitów, a następnie użyj metody top-k / top-p na uzyskanym rozkładzie (lub równoważnie obcięj prawdopodobieństwa po zastosowaniu temperatury). Obcięcie przed zastosowaniem temperatury zmienia to, które wartości występują, i zazwyczaj jest błędną kombinacją. Dokumentuj kolejność, której używa twój serwer; bezawaryjne zamiany mogą zmienić zachowanie.

Q55. Kary za powtórzenia, częstotliwość i obecność

• Powtórzenia / częstotliwość — zmniejsz wagę tokenów już widzianych, często skalując to według ich liczby wystąpień.
• Obecność — nałożenie kary na token raz, jeśli w ogóle się pojawił, niezależnie od liczby wystąpień.

Walczą z pętlami w kreatywnym dekodowaniu, ale mogą szkodzić celowej powtórce (kodu, poezji, frazom prawniczym). Wolą łagodne kary i ścisłe zasady zatrzymania niż agresywne ograniczenia.

Q56. Poza top-p

Min-p – progi względem najwyższej prawdopodobieństwa (p_i ≥ min_p × p_max), które działają lepiej przy wysokiej temperaturze i rozproszonej masie danych. Mirostat oraz podobne sterowniki dążą do określonego poziomu zaskoczenia. Typowa produkcja nadal opiera się na temperaturze + top-p, choć min-p zyskuje coraz większą popularność.

Q57. Dlaczego temperatura 0 nadal się zmienia?

Nawet „chciwe” struktury różnią się między sobą pod względem:

• Niedeterministycznych redukcji na GPU oraz połączonych jąder.
• Różnych harmonogramów grupowania danych / ciągłego grupowania.
• Spekulatywnych ścieżek oraz numerycznie różnych implementacji funkcji softmax.
• Domyślnych kar, ciągów zatrzymania oraz szablonów po stronie serwera.

Szum routingu MoE, jeśli jest włączony.

Metoda Bit-stable greedy wymaga zamkniętych jąder, rozmiaru partii 1 oraz identycznych wersji oprogramowania — co jest rzadkością w flotach wielu użytkowników.

Q58. Przymusowe używanie JSON lub schematu

Opcje rosną w stopniu trudności:

1. Nacisk na użycie JSON (kruche).
2. Ograniczona dekodacja / maski gramatyczne — eliminowanie nieprawidłowych tokenów na każdym kroku (regex, JSON schema, CFG).
3. Używanie narzędzi/funkcji z API, które analizują kanały boczne zamiast wolnego tekstu.
4. Naprawa po fakcie (ostateczność).

Ograniczona dekodacja to niezawodne rozwiązanie w systemach, gdy ważna jest poprawność danych.

Q59. Ocena ustawień próbkowania

Zatrzymaj model w nieruchomym stanie i przetestuj ustawienia temperatury/top-p na zbiorku oznaczonym etykietami: sukces zadania, toksyczność, różnorodność (distinct-n), częstotliwość powtórzeń, opóźnienie. Wolno preferować ocenę offline w połączeniu z testami A/B online przy wyraźnych metrykach produktu. Nie dostosowuj modelu na podstawie pojedynczego, selekcjonowanego specjalnie promptu.

Część 8 — Dekodowanie spekulatywne

Q60. Podstawowa idea

Tani model wstępny proponuje kilka przyszłych tokenów; model celowy weryfikuje je jednocześnie podczas sekwencji przetwarzania tego wstępnego tekstu. Przyjęty prefiks staje się wynikiem; przy pierwszej odrzuceniu wybierze się zastępstwo z rozkładu modelu celowego i odrzuca pozostałe propozycje. Większość zasobów modelu celowego wykorzystuje się na równoległą weryfikację zamiast na sekwencyjne kroki obejmujące pojedynczy token.

Q61. Dlaczego rozkład wyników pozostaje niezmieniony

Akceptacja wykorzystuje stosunki między docelowym p a wersją roboczą q, tak aby akceptowane tokeny wraz z resztkowym próbkowaniem odtworzyły dokładnie p:

P(emit x) = q(x)·min(1, p(x)/q(x)) + P(reject)·p'(x)

Akceptowana ścieżka wnosi min(q,p); resztkowe próbkowanie uzupełnia max(0, p−q). Suma daje p. Dlatego dekodowanie spekulatywne jest bezstratne w porównaniu z zwykłym próbkowaniem docelowym — to przyspieszenie systemu, a nie aproksymacja modelu.

Q62. Oczekiwane przyspieszenie

Przy stopie akceptacji α i długości wersji roboczej k, oczekiwana liczba tokenów na jeden krok docelowy wynosi:

E[tokens] = (1 − α^(k+1)) / (1 − α)

Nawet jeśli każdy token z wersji roboczej się nie sprawdzi, nadal otrzymujesz jeden token z etapu weryfikacji docelowego tekstu. Przy koszcie wersji roboczej c w odniesieniu do jednego kroku docelowego:

speedup ≈ E[tokens] / (1 + k·c)

Przykład: α=0,8, k=4 → oczekiwana liczba tokenów ok. 3,36; przy c=0,05 → ok. 2,8×. Zwycięstwa publikowane często mieścią się w przedziale 2–3×. Duże wartości k przynoszą coraz mniejsze korzyści, ponieważ prawdopodobieństwo przetrwania spada wraz z α^k.

Q63. Kiedy spekulacje szkodzą

Niska akceptacja (trudne polecenia, zmiana dziedziny, słaby projekt), zbyt wysokie koszty tworzenia projektu lub jądra, które nie mogą efektywnie weryfikować równolegle. W takich przypadkach koszty przewyższają korzyści — decyzja zależy od zmierzonej wartości α.

Q64. Pamięć KV przy odrzuceniu

Zapisy celów cofania (oraz projektu) dla odrzuconych pozycji. Implementacje określają długość punktów kontrolnych i je skracają; błędy w tym obszarze psują przyszłą funkcję uwagi. Akceptowane tokeny zachowują swoje wartości K/V.

Q65. Współczesne warianty

Medusa / projekty wielogłowe, narzędzia do tworzenia projektów na poziomie cech w stylu orła, projekty oparte na wyszukiwaniu promptów / n-gramach z samego kontekstu oraz narzędzia typu kaskadowe. Ten sam princip weryfikacji z użyciem celu.

Q66. Uwaga drzewiasta

Narzędzia te mogą proponować drzewo kandydatów, a nie tylko liniową łańcuch. Uwaga drzewiasta sprawdza kilka gałęzi w jednej rundzie przetwarzania celu, co zwiększa liczbę akceptowanych wyników na każde wezwanie, gdy tworzenie gałęzi jest tanie.

Część 9 — Detokenizer i przepływ danych

Q67. Detokenizacja to nie prosta odwrotna mapa

Detokenizery muszą usuwać znaczniki przestrzeni, radzić sobie z awariami na poziomie bajtów, łączyć wielotokensowe grafemy oraz unikać wyświetlania niekompletnej informacji UTF-8. Detokenizacja w trybie przepływowym buforuje dane, aż pełny znak/część będzie mogła zostać bezpiecznie wyświetlona — w przeciwnym razie klienci widzą znaki zastępcze.

Q68. Jak działa przepływ danych i co należy mierzyć

Serwery wytwarzają tokeny (lub częściowe łańcuchy znaków) w momencie ich powstania. Należy mierzyć TTFT, TPOT oraz czas do pierwszego czytelnego znaku po procesie detokenizacji i buforowania. Dla doświadczenia użytkownika kluczowe jest właśnie to ostatnie wartości, a nie surowe daty tokenów.

Q69. Sekwencje zakończenia są skomplikowane

Sekwencje zakończenia mogą obejmować granice tokenów (\n\n w porównaniu z jednym tokenem zawierającym obie nowe linie). Trzeba sprawdzać zdekodowany tekst (lub dokładny zakres tokenów), a nie tylko równość identyfikatorów. W przypadku nakładania się częściowo wygenerowanych sekwencji zakończenia konieczne jest cofnięcie operacji, aby tekst zakończenia nie został wyświetlony.

Q70. Co kończy proces generowania?

EOS / specjalne identyfikatory zakończenia, dopasowane łańcuchy znaków zakończenia, limity maksymalnej liczby tokenów, anulowanie przez klienta lub mechanizm nadzoru serwera. Zaleca się wyraźne obsługiwanie sygnału EOS zgodnie z szablonem czatu.

Część 10 — FlashAttention, kwantyzacja, roofline

Q71. FlashAttention — precyzyjne twierdzenia

FlashAttention oblicza uwagę bez tworzenia pełnej macierzy ocen n × n w pamięci HBM, wykorzystując techniki dzielenia na pola oraz statystyki softmax w czasie rzeczywistym. Dzięki temu zmniejsza ruch pamięciowy i umożliwia obsługę dłuższych sekwencji lub większych grup danych. Nie zmienia matematycznego wyniku obliczeń uwagi (z wyjątkiem ograniczeń numerycznych); jest to algorytm uwzględniający ograniczenia I/O, a nie inny model.

Q72. Czy pomaga to przy dekodowaniu?

Dekodowanie z użyciem pamięci cache często polega na uwzględnianiu kluczy o długości 1 w porównaniu z zapisanymi kluczami o długości n — klasowa przewaga FlashAttention (ogromne wartości ocen kwadratowych) jest wtedy mniejsza. Warianty tego rozwiązania (FlashDecoding itp.) nadal pomagają w wykorzystaniu przepustowości ścieżek KV, ale dekodowanie nadal jest ograniczone obciążeniem pamięcią, chyba że grupa danych jest duża.

Q73. Kwantyzacja

Zachowuj wagi (a czasami aktywacje/KV) w bardziej kompaktowych formatach (FP8, INT8, INT4, …). Pamięć i przepustowość zmniejszają się mniej więcej wraz z szerokością bitową; strata jakości zależy od metody (GPTQ, AWQ, smooth quant, …). Zasada praktyczna z notatek: 8-bit jest często niemal bezkosztowy; 4-bit wiąże się z niewielkimi kosztami, czasem porównywalnymi z szumem wynikającym z samego testowania — zawsze sprawdzaj to na swoich zadaniach.

Q74. Opis w jednym akapicie

Narysuj wykres osiągalnych FLOPów w zależności od intensywności arytmetycznej. Przygotowanie danych znajduje się blisko „dachu obliczeniowego”; dekodowanie w trybie batch-1 znajduje się blisko „dachu przepustowości” na poziomie około 1 FLOP/byte. Optymalizacje zwiększające intensywność (batching, mniej bitów przetwarzanych na każdy użyteczny FLOP) przesuwają cię w kierunku tego „grzbietu”; czyste przyspieszenia jądra nie mogą przebić się ponad istniejące ograniczenia.

Q75. Dzielenie dużego modelu między GPU

Tensor parallelny dzieli warstwy na fragmenty (wymaga szybkiego połączenia między nimi). Pipeline parallelny przydziela zakresy warstw poszczególnym rangom (istnieje ryzyko problemów typu „bubble”). Expert parallelny dzieli ekspertów w architekturze MoE. Replica / data parallelny kopiuje model w celu zwiększenia przepustowości. W rzeczywistych implementacjach łączy się te podejścia; dane KV muszą być podzielone lub skopiowane zgodnie z układem uwagi.

Część 11 — Liczby z tablicy

• Masy 70B w formacie fp16: 70e9 × 2 ≈ 140 GB.
• FLOPs w procesie przetwarzania: ~2 × parametry × tokeny (w przybliżeniu).
• Dane KV na token (Llama-3-70B-class GQA): ~dwa · liczba warstw · liczba głów KV · rozmiar głowy · liczba bajtów na typ danych, co odpowiada około jednej trzeciej megabajtu na token.

Rozbieranie toków w partii 1: ~bandwidth / weight_bytes (klasa H100: dziesiątki toków/s w formacie fp16 przed innymi rozwiązaniami).

Embedding + niepowiązana głowa LM przy V=128K, d=4096: po około 524 mln parametrów każda.

Parametry Attention vs FFN: w standardowym bloku mniej więcej 1:2 (4d² vs ~8d²).

Część 12 — Uwagi dotyczące diagramów

Częste diagramy instruktażowe pomijają: szablony rozmów przed tokenizacją, wpływ GQA/MQA na szerokość struktur KV, szczegóły kolejności próbkowania, buforowanie podczas detokenizacji, struktury KV z paginacją oraz pętle weryfikacyjne typu spekulatywne. Traktuj diagramy jako mapy, a nie umowy.

Zakończenie

Inferencja to proces przekształcania danych w postaci bajtów w tekst strumieniowy, przy którym prefill jest ograniczony zasobami obliczeniowymi, a decode – przepustowością; cache KV dominuje w zarządzaniu pamięcią w systemach wielu użytkowników, a każda istotna optymalizacja – GQA, pagowanie, ciągłe grupowanie zadań, kwantyzacja, FlashAttention, spekulacja – ma na celu przeniesienie obciążeń na najkorzystniejsze elementy sprzętowe, nie zmieniając przy tym modelu matematycznego bardziej, niż to zamierzono.

Głębsze spojrzenie A – Porównanie kosztów prefill i decode w praktyce

Gdy planujesz rozmiar floty, zacznij od podziału według linii dachu. Zadania typu prefill lubią rdzenie tensorowe: długie polecenia w funkcjach kodowych lub plikach RAG mogą pokazać wysoką efektywność MFU, jeśli jądra są sprawne. Dekodowanie zadań w pierwszej partii przypomina przypadkowe testy pamięci – te same wagi 70B przetwarzane są przez HBM przy jednym operacji GEMV. Dlatego produkt generujący odpowiedzi o długości 500 tokenów wydaje się wolny nawet na najnowocześniejszych kartach graficznych, chyba że zastosujesz grupowanie zadań, kwantyzację lub inne strategie optymalizacyjne.

Regresje typu TTFT zazwyczaj oznaczają, że polecenia stały się dłuższe (dzięki historii, RAG czy schematom narzędzi) bez wykorzystania buforowania prefiksów. Regresje typu TPOT zwykle wynikają z załamania się mechanizmu grupowania zadań, spadku przepustowości lub konieczności tworzenia bardzo małych grup zadań ze względu na presję na pamięć KV. Opóźnienie end-to-end nie jest zależne od jednego parametru – skracanie odpowiedzi pomaga w redukcji czasu TPOT o N, buforowanie poleczeń systemowych pomaga w przypadku TTFT, a dekodowanie spekulatywne poprawia czas TPOT przy wysokim wskaźniku akceptacji.

Metryki przepustowości publikowane na panelach kontrolnych łatwo jest sfałszować za pomocą dużych partii danych, co powoduje cierpienie użytkowników interaktywnych. Należy publikować oba wskaźniki: tokeny na sekundę na GPU oraz wartości p50/p95 TPOT w ramach realistycznego połączenia. Ciągłe grupowanie danych zapewnia dostawę danych do GPU bez dodatkowego obciążenia spowodowanego statycznymi partiami; podział na fragmenty umożliwia wcześniejsze uzupełnianie danych, co zapobiega zamarznięciu procesu dekodowania ze względu na jeden długi prompt o długości 32K.

Rozdzielone procesy wcześniejszego uzupełniania danych i dekodowania stanowią przyznanie w architekturze, że te dwa rodzaje zadań wymagają różnych urządzeń. Węzły do wcześniejszego uzupełniania danych mogą wykorzystywać bardziej intensywne obliczenia; węzły dekodujące potrzebują natomiast przestrzeni pamięci oraz przepustowości sieciowej do obsługi struktur KV. Sieć musi efektywnie przesyłać dane typu KV, w przeciwnym razie traci się korzyści. Nie każdy zespół powinien budować taką architekturę od samego początku — ale każdy zespół powinien rozumieć, dlaczego taki model istnieje.

Głębsze spojrzenie B — Tokenizer i koszty wielojęzyczne

Uniwersalność BPE na poziomie bajtów to zarówno dar, jak i obciążenie finansowe. Aplikacje do czatowania w języku angielskim nie uwzględniają prawidłowo kosztów obsługi tekstu w języku hindi, tajskim czy tekstów społecznościowych bogatych w emotikony. Jeśli model opiera się na założeniu liczby tokenów angielskich na sekundę, rozbudowa o języki obce może potajemnie zużywać budżet. Wybieraj tokenizery o szerszym zasięgu multijęzykowym, gdy taki ruch jest istotny; mierz liczbę tokenów na klastry grafemów w rzeczywistych korpusach, a nie w tekście lorem ipsum.

Środowiska do czatowania stanowią część tożsamości modelu. Jeden pominięty specjalny token końcowy może spowodować powstawanie zbyt długich wygenerowanych tekstów lub ich przedwczesne przerwanie. Przechowuj wersję szablonu obok numeru rewizji modelu w swoim rejestrze. Podczas debugowania problemu „model ignoruje polecenie systemowe” ztokenizuj obie strony i porównaj ich identyfikatory, zanim będziesz winić same wagi modelu.

Zasady obchodzenia się z cyframi są istotne dla narzędzi do tabelkach kalkulacyjnych oraz nauczycieli matematyki. Jeśli liczby 1000 i 1,000 są traktowane inaczej, algorytmy kolumnowe przestają być skuteczne. Podczas tworzenia kalkulatorów opartych na modelach językowych LLM należy preferować narzędzia tokenizujące z wyraźnymi regułami dotyczącymi cyfr lub przekazywać obliczenia do specjalistycznych narzędzi.

Głębsze spojrzenie na C — uwaga, GQA i pamięć

Historia mechanizmu multi-head attention to specjalizacja w ramach określonego budżetu. W przypadku GQA chodzi o liczbę bajtów KV. Przejście od MHA do GQA może zmniejszyć rozmiar pamięci cache o około tyle, ile wynosi stosunek liczby głów zapytania do grup KV — często o 4–8 razy — przy umiarkowanej utracie jakości po odpowiednim szkoleniu. MQA to skrajny przypadek; MLA oraz inne metody kompresji dążą do rozwiązania tego samego problemu, ale przy użyciu innych metod algebraicznych.

Maskowanie przyczynowe z użyciem ujemnej nieskończoności nie jest pedanterią: każda skończona wartość maski powoduje wyciek informacji. Błędy treningowe, które przypadkowo umożliwiają przyszłą uwagę, tworzą modele, które wydają się silne w metrykach narzuconych przez trenera, ale zawodzą przy rzeczywistym użyciu autoregresywnym. Jądra używane podczas dekodowania, które zakładają określoną strukturę pamięci cache, muszą odpowiadać geometrii treningu (liczba głowic, baza RoPE, skalowanie).

Rezydua i pre-normalizacja to powód, dla którego stosy 80–100 warstw są powszechne. Gdy architektura niestandardowa usuwa je „w celu uproszczenia”, należy się spodziewać niestabilności treningu zamiast innowacyjności. Mechanizm sterowania SwiGLU stanowi element wpływający na jakość z implikacjami dla pamięci — trzeba wiedzieć, czy dany stos go wykorzystuje.

Głębsze zagadnienia D — strategia paginacji KV i prefiksów

PagedAttention traktuje dane KV jako zbiór bloków. Konsekwencje to:

• Frameworki agentów z dużymi wspólnymi promptami systemowymi powinny kanonizować te prefiksy, aby hashe bloków się zderzały.

Biblioteki typu few-shot powinny przechowywać przykłady w stałym porządku; przetasowywanie psuje trafienia do pamięci cache.

Pola personalizacji powinny znajdować się po wspólnym fragmencie tekstu.

Narzędzia do debugowania powinny pokazywać wskaźniki trafień do tabeli bloków w taki sam sposób, w jaki CDN pokazuje wskaźniki trafień do pamięci cache.

Nieważność pamięci cache z powodu prefiksu to problem poprawności, a nie tylko wydajności. Jeśli schemat narzędzia się zmieni, a klucz cache to zignoruje, model będzie korzystał ze starych danych KV przy nowych instrukcjach — to subtelne, uciążliwe błędy. Do klucza należy dodać ID tokenizatora, hash szablonu, ID LoRA oraz skalę RoPE.

W sytuacji ograniczeń pamięci konieczna jest jakaś polityka: zasada LRU dla nieaktywnych rozmów, sztywne limity kontekstu lub kompresja poprzez streszczenie. Bez względu na wybór, należy to uwzględnić w produkcie — ciche skracanie treści to błąd związany z brakiem zaufania.

Głębsze spojrzenie na E — Softmax, próbkowanie i determinizm

Stabilna funkcja softmax jest obowiązkowa w ścieżkach fp16/bf16. Zintegrowane jądra ukrywają operację max-subtract, ale niestandardowy kod badawczy nadal powoduje przeciążenie. Perplexity pozostaje przydatnym wskaźnikiem regresji, gdy zmienia się jądra lub schematy kwantyzacji – gwałtowne wzrosty oznaczają zmianę rozkładu.

Kompozycję procesu próbkowania należy przetestować metodą unit testing: najpierw temperatura, potem obcięcie danych, następnie kary, a na końcu losowanie. Zmień kolejność operacji w teście i obserwuj, jak różnią się wyniki. Dekodowanie z ograniczeniami dla JSON powinno być przetestowane pod kątem obciążenia; generowanie mask może stać się problemem związanym z wydajnością CPU, jeśli zostanie zaimplementowane w prosty sposób.

Stwierdzenie, że temperatura zero oznacza deterministyczny wynik, to fraza marketingowa, a nie gwarancja matematyczna na rzeczywistych kartach graficznych. Jeśli potrzebujesz danych w standardzie audytowym, zapisz wybrane identyfikatory (lub ziarna generatora losowego wraz z zamrożonymi jądrami z partii 1). Dla większości aplikacji wystarcza powtarzalność w ramach jednej wersji – należy to udokumentować.

Głębsze spojrzenie na F – Operacje dekodowania spekulatywnego

Spekulacja bez straty jakości jest skuteczna, ponieważ właściciele produktów obawiają się spadku jakości. Mimo to dział operacyjny musi śledzić wskaźnik akceptacji według kategorii zapytań. Kompletowanie kodu często odbywa się pomyślnie, natomiast kreatywne rozmowy otwarte mogą nie przynieść dobrych rezultatów. Adaptacyjna długość szkicu oparta na ostatnich wynikach akceptacji jest lepsza od statycznych przypuszczeń.

Spekulacja drzewiasta jest przydatna, gdy szkic może tanio zaproponować alternatywy. Testy poprawności odwracania zmian typu KV powinny być częścią procesu CI: należy celowo odrzucić takie zmiany w trakcie działania i upewnić się, że kolejne operacje odpowiadają bazie nieopartej na spekulacjach.

Modele szkicowe muszą dzielić ten sam tokenizer (lub kompatybilne mapowanie) z modelem docelowym. Niespójne tokenizery tworzą niewidoczne „śmieci”, które sprawiają wrażenie, jakby spekulacje uczyniły model mniej inteligentnym.

Głębsze spojrzenie na G — UX strumieniowe i zatrzymania

Użytkownicy odczuwają płynność dzięki znakom po detokenizacji, a nie surowym identyfikatorom. Zachowuj bufor do momentu, aż dane będą zgodne ze standardem Unicode; w przypadku czatu warto opróżniać bufor przy białych przestrzeniach, aby poprawić doświadczenie użytkownika. Sekwencje zakończeniowe, które nakładają się na tokeny, wymagają ostrożnego cofania działań, aby klient nigdy nie widział tekstu zakończeniowego. Jeśli produkt umożliwia kontynuację, maksymalne limity tokenów powinny zawierać wyraźny sygnał kontynuacji.

Szczegółowe omówienie H — FlashAttention i kwantyzacja w procesie obsługi

FlashAttention umożliwia dłuższe prefillowanie oraz większą gęstość partii dzięki oszczędzaniu pamięci HBM. Warto to docenić, choć nie należy twierdzić, że zmienia zasady dekodowania. Kwantyzacja jest kluczowym elementem dekodowania: mniej bajtów na każdą wagę zwiększa efektywną liczbę tokenów na sekundę. Sprawdź to w swoim zestawie testowym — szczególnie pod kątem wywoływania narzędzi i przywracania długich kontekstów — zanim uznasz, że 4-bitowa wersja jest dostępna.

Rozumowanie oparte na strukturze dachu zapewnia uczciwość argumentów: jeśli masz ograniczenia przepustowości, zakup większej liczby TFLOPS bez zwiększenia przepustowości (lub zmniejszenia liczby bajtów) jest rozczarowujący. Jeśli ograniczeniem jest moc obliczeniowa podczas procesu prefill, lepsze algorytmy GEMM oraz planowanie prac w blokach są ważniejsze niż redukcja rozmiaru danych KV.

Głębszy przegląd I — Realia wielu GPU

Paralelizm tensorowy wymaga szybkiego połączenia między jednostkami, w przeciwnym razie proces ugrzęźnie podczas operacji all-reduces. Paralelizm w formie łańcucha wymaga małych grup danych, aby ukryć problemy związane z opóźnieniami. Mieszanie tego z ciągłym grupowaniem danych oraz użyciem struktury KV opartej na stronach pamięci jest powodem, dla którego silniki inferencji składają się z dużych baz kodu. Gdy ktoś proponuje po prostu podzielenie modelu, należy zapytać o wybraną wymiarowość oraz to, co stanie się z układem danych KV.

Głębszy przegląd J — Budowa łańcucha obliczeniowego

Szlak żądania, który warto zapamiętać:

1. Wytwarzanie szablonu oraz tokenizacja na CPU
2. Wbudowywanie danych i proces prefill z użyciem uwagi przyczynowo-skutkowej, zapisywanie danych KV (GPU, ograniczenia moc obliczeniowa)

Głowa LM na ostatniej pozycji, następnie pobieranie próbek (GPU z polityką CPU)

Pętla dekodowania z pamięcą cache, ciągłe grupowanie danych, opcjonalna spekulacja (GPU, ograniczone przepustowością)

Detokenizacja, sprawdzanie zakończenia, przetwarzanie w CPU

Wyzwalanie wolnych lub wykorzystywanie bloków KV w alokatorem

Każda optymalizacja odpowiada jednej strzałce na tej liście. Jeśli nie możesz wskazać konkretnej strzałki, to jeszcze nie rozważasz procesu inferencji — jedynie zbierasz informacje.

Dodatkowe wyjaśnienia w stylu FAQ

Czy zwiększenie temperatury wpływa mierzalnie na kreatywność? Zwiększa ono entropię rozkładu następnego tokena. To, czy ludzie uznamą wynik za kreatywny, zależy od zadania; należy mierzyć to za pomocą wskaźników różnorodności i jakości, a nie tylko subiektywnych wrażeń.

Czy chciwość kiedykolwiek jest słuszna? Tak — klasyfikacja jako generowanie, strukturyzowane wydobywanie z ograniczoną dekodacją oraz niektóre narzędzia oceny. W dialogu otwartym zazwyczaj tak nie jest.

Czy można usunąć pamięć cache KV i przeliczyć dane? Zawsze, ale z kosztem kwadratowym. Urządzenia brzegowe czasami pracują w krótkich oknach bez cache; serwery prawie nigdy nie powinny tego robić.

Dlaczego w diagramach pokazano softmax wewnątrz mechanizmu uwagi oraz ponownie przy głowie modelu językowego? Różne wersje softmax: jedna mieszaje wartości wewnątrz warstwy; druga przekształca logity słownika na rozkład kategoryczny do losowania. Ta sama rodzina funkcji, różne zadania.

Czego powinien najpierw zapamiętać nowy inżynier? Problemy z wypełnianiem początkowym w porównaniu z dekodowaniem, wzór na liczba bajtów KV na token, TTFT w porównaniu z TPOT oraz to, że grupowanie danych wymienia opóźnienie na przepustowość. Wszystko inne wynika z tych czterech koncepcji.

Szerokie omówienie — jądra wypełniania początkowego i mechanizmy TTFT

Jakość wstępnego uzupełniania zasobów jest przede wszystkim kwestią szybkości, z jaką można przekształcić polecenie w gotowy cache KV. Jądra uwagi, połączone ścieżki MLP oraz sposób podziału poleceń na fragmenty decydują o kształcie krzywej TTFT. Gdy polecenia mają wspólną długą część, buforowanie prefiksów zamienia powtarzające się koszty wstępnego uzupełniania w szybkie wyszukiwanie; gdy tak nie jest, każda nowa sesja musi zapłacić pełną cenę.

Podział na fragmenty służy zarówno do zapewnienia sprawiedliwości, jak i redukcji opóźnień. Bez niego jedna operacja przetwarzania 40 tysięcy tokenów może zablokować dekodowanie dla wszystkich innych na karcie GPU. Dzięki niemu strumienie interaktywne nadal działają, podczas gdy długa operacja jest wykonywana etapami. Kompromisem jest nieco wyższy czas TTFT dla samej długiej operacji — co zazwyczaj jest do przyjęcia.

Rozmieszczenie prefiksu to decyzja produktowa. Umieść zmienny tekst użytkownika za ustalonym rdzeniem, aby klucze cache pozostały stabilne. Jeśli dział marketingu co dzień przepisuje komendy systemowe, traktuj to jako zdarzenie powodujące usunięcie danych z cache i oczekuj, że TTFT wzrośnie, dopóki nowy rdzeń znów nie stanie się popularny.

Szerokie objaśnienie — Wyjaśnienie matematyki przepustowości słowami

Załóżmy, że czytamy cały zestaw wag z HBM raz na każdy wygenerowany token przy rozmiarze partii równym jedności. Intensywność obliczeniowa spada do poziomu jednego użytecznego operacji mnożenia i akumulacji na przesunięty bajt. Sprzęt, który doskonale radzi sobie z intensywnymi operacjami GEMM, wydaje się nieaktywny, ponieważ czeka na kontrolery pamięci. Pracowanie w partiach umożliwia ponowne wykorzystanie każdego załadunku wag w wielu sekwencjach; kwantyzacja zmniejsza sam załadunek; weryfikacja spekulatywna zamienia kilka kroków sekwencyjnych w jedną równoległą kontrolę. To różne sposoby na pokonanie tego samego problemu.

Gdy ktoś twierdzi, że jądro jest „2× szybsze” podczas dekodowania, zapytaj, pod jakim dachem się znajdował. Jeśli wydajność była ograniczona przepustowością, sama optymalizacja ALU nie może zapewnić dwukrotnego wzrostu szybkości. Jeśli dodatkowo zmniejszono liczbę przesyłanych bajtów, uwierz im po zrzutku ekranu z narzędzia do analizy wydajności.

Szerokie omówienie — Zasady obsługi i SLO

Napisz oddzielne wartości SLO dla TTFT i TPOT. Wersja oprogramowania, która poprawia przepustowość, podczas gdy p95 TPOT się podwaja, stanowi regresję w zakresie doświadczenia użytkownika w czacie, nawet jeśli panel kontroli pojemności to celebruje. Parametry ciągłego grupowania (maksymalna liczba tokenów w grupie, maksymalna kolejka oczekujących, priorytet dekodowania w porównaniu z fragmentami prefill) to praktyczne elementy sterujące tymi SLO.

Kontrola przyjmowania sesji powinna znajdować się obok rozliczania KV: odrzucaj lub umieszczaj w kolejce nowe sesje, gdy przewidywana ilość pamięci cache przekroczy określony próg. W przeciwnym razie błędy z powodu braku pamięci wyglądają dla klientów jak losowe awarie modelu.

Szerokie omówienie — Lista kontrolna operacji tokenizera

Zanim uruchomisz model:

1. Zamroź pliki tokenizatora oraz tekst szablonu rozmowy w tym samym sklepie artefaktów co wagi modelu.
2. Przeprowadź testy na kilku wielojęzycznych ciągach znaków i emoji, aby sprawdzić braki w długości tokenów.
3. Przeprowadź testy na ciągach znaków zawierających wiele cyfr, jeśli produkt wykonuje obliczenia matematyczne.
4. Zapewnij się, że ID tokenów zakończenia odpowiadają znacznikom końca w szablonie.
5. Zapewnij się, że narzędzie do obliczania logprob używa tego samego tokenizatora co proces inferencji.

Pominięcie któregokolwiek z tych kroków spowoduje, że będziesz naprawiać „jakość modelu”, która w rzeczywistości wynika z odchyłek w pakietowaniu.

Szerokie omówienie — Warianty Attention jako chronologia

Ranne modele językowe wykorzystywały pełne MHA i opłacały je z pamięci cache. Presja produkcyjna doprowadziła do powstania MQA, a następnie GQA jako kompromisu przyjętego przez większość punktów kontrolnych. MLA oraz powiązane z nimi koncepcje KV o niskim rzędzie kontynuują tę samą historię: zachowanie bogactwa zapytania przy jednoczesnym zmniejszaniu ilości przechowywanych danych na jeden token. Czytając artykuł naukowy, należy przekładać stwierdzenia na „bajty na token KV” oraz „zmianę jakości w naszych testach” – język marketingowy dotyczący „efektywnej uwagi” jest w przeciwnym razie bezsensowny.

Szerokie omówienie — Paged KV i zachowanie wielu użytkowników

Matematyka fragmentacji jest surowa w przypadku ciągłych rezerwacji. Struktura paginowania przekształca to w problem alokatora z ustalonymi blokami. Klustery wielu użytkowników powinny śledzić niepowodzenia alokacji, „ukraść” opóźnienia z tabel bloków oraz uwzględniać wskaźnik trafień na początku sekwencji. Nagły spadek wskaźnika trafień często oznacza zmianę formatowania lub cichą aktualizację narzędzia tokenizacji.

Dzielenie się danymi typu copy-on-write pomiędzy różnymi wiązkami i równoległymi próbkami nie jest opcjonalne przy dekodowaniu w stylu wyszukiwania; bez niego bezpowrotnie zwiększasz zużycie pamięci o szerokość wiązki.

Szerokie omówienie — Próbkowanie dla produktów

Domyślne ustawienia dostawy dopasowane do zlecenia:

• Parametry ekstrakcji/narzędzi: niska temperatura, ograniczone dekodowanie, strategia greedy lub mały jądro.
• Chat obsługi klienta: umiarkowana temperatura, jądro wokół standardowej wartości 0.9, niewielka kara za powtórzenia w przypadku pojawienia się pętli.
• Kreatywne brainstorming: wyższa temperatura, uwzględnienie parametru min-p, silniejsze ostrzeżenia widoczne dla użytkownika dotyczące zmienności wyników.

Zapisuj wiązkę danych z próbkowaniem wraz z każdą odpowiedzią dla zgłoszeń obsługi klienta. Bez tego nie da się odpowiedzieć na pytania typu „Model wczoraj powiedział X”.

Szerokie omówienie — Wdrażanie dekodowania spekulatywnego

Rozwijaj rozwiązanie za pomocą flagi. Mierz poziom akceptacji na poziomie punktów końcowych. Wyłącz go, gdy α spadnie poniżej progu rentowności obliczonego na podstawie szacunkowej ceny c i długości k. Zawsze zachowuj niespekulatywny fragment ruchu typu canary – stanowi on Twoją rzeczywistą miarę jakości.

Zadbaj o to, aby ścieżki odrzucenia usuwały dane typu KV. Dodaj test chaosowy, który wymusza odrzucenia w trakcie sekwencji pod obciążeniem.

Szerokie omówienie — szczegóły protokołu strumieniowania

Decyduj, czy format przesyłania ma streamować tokeny, zdetokenizowane łańcuchy znaków, czy oba. Klienci, którzy dokonują ponownej tokenizacji w inny sposób, będą się nie zgadzać co do granic. Preferuj zdetokenizację po stronie serwera z wyraźnymi zdarzeniami „flush”, gdy gotowy jest kompletny klastr znaków. Udokumentuj, w jaki sposób usuwane są sekwencje zatrzymania, aby kod interfejsu nie obsługiwał ich dwukrotnie.

Szerokie omówienie — testy akceptacji kwantyzacji

Zanim wdrożysz wagi 4-bitowe w produkcji:

• Zaprowadź standardowy zestaw testów eval.
• Zaprowadź testy wykorzystujące narzędzia do wywoływania funkcji.
• Zaprowadź testy długiego kontekstu.
• Porównaj wyniki testów odmowy i bezpieczeństwa, jeśli to możliwe.
• Porównaj wartości p95 TPOT oraz zużycie VRAM.

Jeśli jakość mieści się w uzgodnionym przedziale błędu, a różnice czasu reakcji są rzeczywiste, wypuść produkt. W przeciwnym razie dla tego modelu pozostań przy formatie 8-bitowym.

Rozszerzona instrukcja – Odpowiedzi na ćwiczenia z tablicy białej w formie prozy

Pamięć potrzebna do przechowywania punktu kontrolnego z siedemdziesięcioma miliardami parametrów w formacie fp16 wynosi około stu czterdziestu gigabajtów tylko dla wag. Jedna iteracja obliczeń wymaga około dwóch operacji FLOP na parametr i token. Rosła liczba struktur KV jest liniowa w zależności od liczby aktywnych tokenów oraz liczby głow klucz/wartość, które faktycznie przechowujesz. Szybkość dekodowania w jednej partii danych zależy od przepustowości pamięci podzielonej przez liczbę bajtów edytowanych na krok. Tablice embeddingów oraz niepowiązane głowy modelu językowego mogą pochłaniać setki milionów parametrów przy dużych słownikach – nie są to błędy zaokrąglenia. Wewnątrz bloku ścieżka feed-forward często zawiera mniej więcej dwa razy tyle parametrów projekcji co mechanizm uwagi.

Rozszerzona instrukcja – Nauczanie uczciwości w diagramach

Gdy rysujesz schemat procesu dla początkujących, odznacz pominięte elementy: szablony, mechanizmy paginacji, ciągłe grupowanie danych, strategie spekulacyjne oraz buforzy do detokenizacji. W przeciwnym razie inżynierowie wdrożą diagram, a potem będą zaskoczeni zachowaniem systemu w warunkach rzeczywistych.

Zakończenie – jak wygląda „zakończone zadanie” dla właściciela inferencji

Możesz wyjaśnić, bez użycia slajdów, dlaczego dany incydent wpłynął negatywnie na TTFT w porównaniu z TPOT. Możesz oszacować ilość pamięci KV dla proponowanego celu dotyczącego jednoczesności i kontekstu. Możesz wskazać, który mechanizm – batch, quant, GQA, spekulacja, cache prefiksowy – ma związek z danym objawem. Traktujesz tokenizery i szablony jako zależności w wersjach. To właśnie jest podstawowa biegłość operacyjna przy inferencji modeli LLM; wszystko inne to szczegóły, które można sprawdzić.

Opis studium przypadku – interaktywny serwis o mocy 70B

Załóżmy, że udostępniasz model czatowy o mocy 70B w formacie fp16 na dwóch kartach GPU o dużej pojemności pamięci. Same wagi zajmują około stu czterdziestu gigabajtów, więc pamięć tych kart jest niemal w pełni wykorzystana jeszcze przed rozpoczęciem jakiejkolwiek rozmowy. Pozostała przestrzeń musi służyć do przechowywania danych KV dla wszystkich aktywnych sesji, aktywacji oraz do radzenia sobie z fragmentacją pamięci.

Ustaliłeś cel dla produktu: szesnastu użytkowników jednocześnie, konteksty o długości czterech tysięcy tokenów oraz odpowiedzi w formie strumienia. Szacunkowe obliczenia pokazują, że kilkaset kilobajtów na token daje w sumie dziesiątki gigabajtów – co przekracza dostępną ilość pamięci. Natychmiast pojawiają się opcje: przejście na punkt kontrolny GQA, kwantyzacja pamięci cache, obniżenie liczby użytkowników jednocześnie, skrócenie kontekstu lub dodanie kart graficznych. To właśnie takie proste obliczenia decydują o różnicy między niejasnym pytaniem typu „potrzebujemy więcej kart graficznych” a precyzyjnym planem wydajnościowym.

Zauważasz również gwałtowne wzrosty wartości TTFT na początku każdej godziny, gdy wielu klientów łączy się ponownie z identycznymi promptami systemowymi. Caching prefiksów pomaga kontrolować te wzrosty po ustaleniu stałej części promptu. Brak ustalenia tej stałej po edycji promptu objawia się w panelu metryk jako regresja modelu.

Opis studium przypadku – pętle agenta i klucze cache

Agent wysyła to samo schemat narzędzia na każdym kroku. Jeśli JSON tego schematu jest zserializowane z niestabilną kolejnością kluczy, hashe prefiksowe zawodzą i musisz ponownie uzupełniać tysiące tokenów na krok. Kanoniczne kodowanie JSON staje się więc elementem optymalizacji procesu inferencji. Podobnie, umieszczenie profilu użytkownika przed schematem utrudnia dzielenie się narzędziem między użytkownikami, natomiast umieszczenie go po schemacie zachowuje wspólne elementy narzędzia.

Opis studium przypadku — Dekodowanie spekulatywne w kodzie i czacie

W punkcie końcowym do uzupełniania kodu mały model wstępny, wyszkolony na podobnych danych, akceptuje większość tokenów; opóźnienie end-to-end zmniejsza się o około 2 razy. W punkcie końcowym do tworzenia treści otwartych akceptacja spada, a ten sam model wstępny marnuje zasoby. Flagi funkcjonalne dla poszczególnych ścieżek są skuteczniejsze niż globalny przełącznik spekulacji.

Opis studium przypadku — Błędy w sekwencjach zatrzymywania

Zespół wprowadza zatrzymanie dla ramki markdown. W połowie przypadków rama ta składa się z jednego tokena; w drugiej połowie jest podzielona. Użytkownicy widzą kończące się znaki backtick. Poprawka sprawdza okna tekstu po dekodowaniu i cofa zakres zatrzymania. Głównym błędem były zatrzymania oparte wyłącznie na identyfikatorze tokena.

Opis studium przypadku — Niespodzianka z kwantyzacją

Ciężary czterobitowe poprawiły wydajność tok/s o około 40% na ścieżce dekodowania ograniczonej pamięcią. Wyceny z wykorzystaniem narzędzi spadły o trzy punkty. Kompromis: 8 bitów dla ścieżek z narzędziami, 4 bity dla długich szkiców blogów. Jeden artefakt modelu, dwa profile serwowania — możliwe dzięki routingu w bramce.

Praktyczna lista kontrolna — Gotowość do uruchomienia

• [ ] Dokumentacja historii Roofline dla prefill i dekodowania
• [ ] Pomiar liczby bajtów KV/token w rzeczywistym punkcie kontrolnym
• [ ] Połączenie liczby równoległych operacji z budżetem kontekstu pozwala na wykorzystanie pamięci GPU z zapasem
• [ ] Włączone ciągłe grupowanie z polityką priorytetów dekodowania

[ ] Klucze cache z prefiksem obejmują szablon, tokenizer, LoRA oraz skalę RoPE

[ ] Tupla próbek jest rejestrowana przy każdej odpowiedzi

[ ] Dekodowanie ograniczone dla dowolnego kontraktu JSON

[ ] Bufory detokenizacji strumieniowej z niekompletnym UTF-8

[ ] Sekwencje zatrzymania testowane pomiędzy granicami tokenów

[ ] Dekodowanie spekulatywne włączane na podstawie zmierzonego poziomu akceptacji

[ ] Kwantyzacja weryfikowana przy ocenach specyficznych dla zadań

[ ] Plan równoległy tensorów/procesorów odpowiada rzeczywistości interkonekcji

Praktyczna lista kontrolna — triaż incydentów

1. Czy TTFT lub TPOT nie działają?
2. Czy zmieniła się długość promptu lub skład partii?
3. Czy pamięć KV jest bliska limitu?
4. Czy wersje tokenizera/szablonu uległy zmianie?
5. Czy flaga jądra/kwantyzacji uległa zmianie?
6. Czy metoda spekulatywna daje słabe wyniki akceptacji?
7. Czy mamy ograniczenia przepustowości czy obliczeniowe w danym profilu?

Niech lista jest przetwarzana w kolejności; większość stron typu „model dzisiaj jest głupi” zostaje rozwiązana po czwartym kroku.

Glosariusz w jednym miejscu

TTFT — czas do momentu wygenerowania pierwszego tokena po rozpoczęciu żądania. TPOT / ITL — średni czas pomiędzy kolejnymi tokenami. Prefill — równoległe przetwarzanie promptu w celu wypełnienia struktury KV. Decode — kroki autoregresywne generujące nowe tokeny. KV cache — przechowywane klucze/wartości dotyczące wcześniejszych tokenów. GQA — grupowanie zapytań w celu zmniejszenia liczby głowic KV. PagedAttention — alokacja zasobów KV w blokach. Nucleus (top-p) — adaptacyjne obcinanie końcówki rozkładu prawdopodobieństwa. Speculative decoding — przyspieszenie poprzez tworzenie wstępnych wersji i ich weryfikację. Roofline — model określający związek między intensywnością obliczeń a maksymalną liczbą operacji FLOPs w stosunku do przepustowości.

Ostateczny akapit syntetyzujący

Traktuj inferencję jak linię produkcyjną. Tokenizatory określają pojemniki na części. Embeddingi i bloki to maszyny. Pamięć KV to zapasy w trakcie przetwarzania, które zajmują miejsce w magazynie na każde otwarte zamówienie. Próbkowanie to kontrola jakości każdej jednostki. Strumieniowanie to przystanek wysyłkowy. Dekodowanie spekulatywne to równoległa ścieżka inspekcji. Jeśli optymalizujesz jakąś stację, nie zwracając uwagi na zapasy i przepustowość, powstają stosy nieukończonych zadań oraz rozgniewani klienci — mimo że każda stacja „wygląda szybciej” w izolacji.

Dodatek — Porównanie modeli mentalnych, o których usłyszysz podczas wywiadów

Rozmówcy często proszą o pogodzenie trzech hasłów: „transformery działają równolegle”, „dekodowanie jest sekwencyjne” oraz „uwaga ma charakter kwadratowy”. Wszystkie one są prawdziwe w różnych kontekstach. Proces szkolenia i wypełniania początkowego wykorzystuje równoległość pomiędzy już istniejącymi pozycjami. Dekodowanie nie może z góry stworzyć przyszłych tokenów bez spekulacji. Czynnik kwadratowy w mechanizmie uwagi ma największe znaczenie, gdy długość sekwencji jest duża w porównaniu z operacjami matematycznymi realizowanymi na podstawie szerokości. Dobra odpowiedź określa najpierw kontekst, a dopiero potem podaje hasło.

Kolejną powszechną pułapką jest utożsamianie liczby parametrów z szybkością dekodowania. Parametry określają liczbę bajtów przetwarzanych na krok; układ (GQA), typ danych oraz grupowanie zadań decydują o tym, jak te bajty przekładają się na liczbę tokenów na sekundę. Dwa modele o pojemności 70B mogą różnić się dwukrotnie pod względem opóźnienia w interakcji po uwzględnieniu tych czynników.

Trzecią pułapką jest traktowanie próbkowania jako „zwykłego RNG”. Temperatura, skracanie danych, kary i ograniczenia każde z nich modyfikuje rozkład kategoryczny; RNG jedynie wybiera spośród tego, co pozostało. Naprawa dziwnych wyników zaczyna się od zapisywania tej pary.

Dodatek — Najważniejsze równania wartych zapamiętania

KV bytes ≈ 2 × layers × kv_heads × head_dim × bytes × seq_len × batch. Intensywność dekodowania dla batch-1 ≈ 2 × params / weight_bytes ≈ O(1) FLOP/byte dla gęstych danych typu fp16. Oczekiwana liczba tokenów speculatywnych na jedną weryfikację ≈ (1 − α^(k+1)) / (1 − α). Stabilność funkcji softmax: odejmij maksimum przed wykonywaniem funkcji exp. Maska przyczynowa: zapisz −∞, a nie zero, do zabronionych wyników.

Jeśli potrafisz ponownie wyprowadzić te wzory na tablicy i wyjaśnić każdy symbol, już przewyższasz większość niejasnych wyjaśnień.

Dodatek — Gdzie szukać dalszych informacji

Po tej wizycie po przepływie danych naturalnymi dalszymi krokami są: odczytanie ścieżki alokatora w stylu PagedAttention w uruchomionym silniku, profilowanie jednego kroku prefill oraz jednego kroku dekodowania za pomocą narzędzia profilującego dostarczanego przez producenta, a także implementacja małej pętli dekodowania opartej na zasadzie chciwości z wyraźną pamięcą KV w NumPy lub PyTorch, aby poznać strukturę danych. Te ćwiczenia przekształcają powyższy słownictwo w pamięć mięśniową bez konieczności użycia pełnego zestawu narzędzi do szkolenia.

Jeszcze jedna próba — powiązanie metryk z problemami użytkowników

Gdy w zgłoszeniu obsługi klienta widnieje informacja „sztuczna inteligencja działa wolno”, należy to przełożyć na konkretne przyczyny. Jeśli ikona spinująca pojawia się przed jakimkolwiek tekstem, należy sprawdzić czynniki takie jak długość promptu, zbyt długie prefiksy, przeciążenie podczas prefill lub brak pamięci cache. Jeśli tekst pojawia się szybko, ale następnie przyspieszenie spada, należy sprawdzić problemy takie jak zbyt duże grupy danych, konieczność używania małych grup ze względu na ograniczoną pamięć KV, niewekwantyzowane wagi na karcie o ograniczonej przepustowości lub wyłączenie mechanizmów spekulacji na trasie, która wcześniej przynosiła dobre wyniki.

Gdy w zgłoszeniu jest napisane „odpowiedzi stały się gorsze po wtorku”, porównaj pary próbek, hashe szablonów oraz flagi kwantyzacji przed ponownym trenowaniem czegokolwiek. Regresje w obsłudze danych często udają regresje inteligencji.

Gdy w zgłoszeniu jest napisane „tworzy JSON”, przestań dostosowywać parametr temperatury i zastosuj ograniczoną dekodację. Próbkowanie nie może narzucić gramatyki; maskowanie może to zrobić.

Spotkania dotyczące planowania mocy obliczeniowej przebiegają lepiej, gdy ktoś napisa na tablicy trzy liczby: bajty na token KV, docelowa jednoczesność działania oraz docelowy kontekst. Pomnóż je, dodaj wpływ wag i porównaj z pamięcią GPU. Argumenty o „magii AI” ustają; zaczyna się matematyka zakupów.

To właśnie jest cel całej tej prezentacji procesowej: zastąpić tajemnicę wskaźnikami, a wskaźniki dźwigniami, które możesz użyć.

Uwagi końcowe na temat zakresu

To przepisanie pozostaje w ramach ścieżki inferencji: to, co dzieje się po utworzeniu wag, gdy klient wysyła tekst, oraz przed tym, jak zespół operacyjny zaczyna rozmawiać o drobnej kalibracji. Kwestie związane z czasem treningu — mieszanki danych, optymalizatory, harmonogramy treningu równoległego — mają ogromne znaczenie, ale to inny temat. Jeśli potrafisz pod presją pamiętać o rozdzieleniu danych na prefill i decode, o koszcie KV oraz o składzie próbek, to już masz podstawy, do których mogą się przyłączyć te inne zagadnienia.

Ćwiczenie dla czytelnika

Weź jedną prośbę o przetworzenie z swoich logów. Zapisz liczbę tokenów wejściowych, liczbę tokenów wyjściowych oraz zaobserwowane wartości TTFT/TPOT, jeśli je masz. Oszacuj pamięć KV przy użyciu wzoru na liczbę tokenów dostosowanego do warunków warstw i struktury głowy twojego modelu. Zastanów się, czy prośba była bardziej związana z obliczeniami przy wypełnianiu danych wcześniej, czy z ograniczeniami przepustowości przy dekodowaniu. Wymień jeden element – cache z prefiksem, rozmiar partii, kwantyzację, GQA lub metody spekulacyjne – który mógłby wpłynąć na wskaźnik, który najbardziej cię interesuje. Jeśli potrafisz ukończyć to ćwiczenie bez ponownego otwierania tego artykułu, oznacza to, że przeredagowanie spełniło swój cel.

Zachowaj krótki osobisty przewodnik: różnica między wypełnianiem z góry a dekodowaniem, wzór na bajty KV, różnica między TTFT a TPOT oraz kolejność próbkowania. Przejrzyj go przed przeglądami pojemności i zanim obwiniasz model za błędy w działaniu. Takie małe nawyki składają się na niezawodną intuicję. Ćwicz wyjaśnianie procesu na głos w czasie krótszym niż dwie minuty; płynność pod presją czasu to prawdziwy test zrozumienia. Ćwicz wyjaśnianie procesu na głos w czasie krótszym niż dwie minuty; płynność pod presją czasu to prawdziwy test zrozumienia. Ćwicz wyjaśnianie procesu na głos w czasie krótszym niż dwie minuty; płynność pod presją czasu to prawdziwy test zrozumienia.