przetwarzanie promptu i generowanie

Dwie fazy pracy modelu o przeciwnej charakterystyce. Prefill przetwarza cały prompt równolegle, obciąża rdzenie i decyduje o czasie do pierwszego tokena. Decode generuje odpowiedź sekwencyjnie, obciąża pamięć i decyduje o liczbie tokenów na sekundę.

W Polsce nazywane też:

prefilldecodeprzetwarzanie promptufaza generowaniadwie fazy wnioskowania

Model nie wykonuje jednej pracy, tylko dwie — i są to prace tak różne, że gdyby nie dzieliły wag, nikt nie nazwałby ich tym samym słowem.

Czym są prefill i decode

Prefill to faza przetwarzania promptu: model przepuszcza przez wszystkie warstwy cały tekst wejściowy, liczy dla każdego tokenu klucz i wartość i zapisuje je do pamięci podręcznej kontekstu. Decode to faza generowania: model produkuje jeden token, dopisuje go do historii i powtarza ten krok aż do warunku zatrzymania.

Dlaczego prefill jest szybki

Cały prompt jest znany z góry, więc wszystkie jego tokeny można przetworzyć naraz. Zamiast przepuszczać przez warstwę jeden wektor, przepuszcza się macierz o tysiącu wierszy — przy tym samym jednym odczycie wag z pamięci.

Koszt odczytu rozkłada się na tysiąc porcji pracy. Wąskie gardło przestaje być pamięcią, a zaczyna być liczeniem, i akcelerator wreszcie pracuje tak, jak został zaprojektowany. Model generujący trzydzieści tokenów na sekundę potrafi w prefillu przetwarzać ich dwa tysiące.

Prefill nie skaluje się jednak liniowo: każdy token musi spojrzeć na każdy inny, więc przy bardzo długich promptach dochodzi składnik rosnący kwadratowo.

Dlaczego decode jest wolny

Żeby policzyć token numer siedem, trzeba znać szósty. To ograniczenie logiczne, nie techniczne — żaden sprzęt go nie obejdzie. Każdy krok wymaga przejścia jednego wektora przez cały model, czyli odczytania wszystkich wag, żeby wyprodukować jedno słowo.

W tej fazie wykorzystanie mocy obliczeniowej akceleratora wynosi od jednego do trzech procent. To marnotrawstwo jest przyczyną, dla której dostawcy API przetwarzają dziesiątki rozmów w jednej partii.

Dwa profile zadania

Krótkie pytanie i długa odpowiedź: prefill jest niezauważalny, czas zdominowany przez decode w ponad dziewięćdziesięciu procentach.

Długi dokument i krótkie streszczenie: prefill zjada dwie trzecie czasu, a generowanie kończy się w kilka sekund.

Nie ma jednej optymalizacji pomagającej na oba profile — i to jest główny powód, dla którego warto znać to rozróżnienie.

akcelerator obliczeniowyUkład zaprojektowany do wykonywania wielu prostych operacji równolegle — karta graficzna, TPU lub NPU. Dla modeli językowych liczą się w nim dwa parametry osobno: moc obliczeniowa, która rządzi przetwarzaniem promptu, i przepustowość pamięci, która rządzi generowaniem odpowiedzi.przetwarzanie partiami w trybie ciągłymTechnika serwowania modeli, w której wiele równoległych rozmów dzieli jeden odczyt wag z pamięci, a żądania dołączają i opuszczają partię w trakcie jej przetwarzania. Podstawa ekonomii API — bez niej koszt tokenu byłby wielokrotnie wyższy.czas do pierwszego tokenaMetryka mierząca czas od wysłania żądania do otrzymania pierwszego tokenu odpowiedzi. Obejmuje sieć, bramę, kolejkę i prefill. Jest niezależna od liczby tokenów na sekundę i bywa z nią sprzeczna, bo optymalizacje poprawiające przepustowość systemu pogarszają czas oczekiwania.przepustowość pamięciIlość danych, jaką sprzęt przepycha między pamięcią a rdzeniami w ciągu sekundy. Przy generowaniu odpowiedzi to ona, a nie moc obliczeniowa, wyznacza sufit prędkości — bo każdy pojedynczy token wymaga przeczytania wszystkich wag modelu.wnioskowanie modeluUżycie wytrenowanego modelu do wygenerowania odpowiedzi, przy zamrożonych wagach. Dzieli się na przetworzenie promptu i sekwencyjne generowanie token po tokenie — stąd różne stawki za tokeny wejściowe i wyjściowe oraz to, że długa odpowiedź kosztuje czasowo więcej niż długi prompt.pamięć podręczna klucz-wartośćPamięć podręczna przechowująca pośrednie reprezentacje dotychczasowych tokenów, dzięki której generowanie kolejnego tokenu nie wymaga przeliczania całej sekwencji. Rośnie liniowo z długością kontekstu i liczbą sesji — to główny konsument pamięci przy inference. Podstawa mechanizmu cache promptu.