Jak buforowanie prefiksów ogranicza powtarzającą się pracę z promptami na domowym serwerze AI?

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Buforowanie prefiksów ogranicza powtarzanie pracy związanej z promptem, ponownie wykorzystując stan klucz-wartość obliczony wcześniej dla identycznej początkowej sekwencji tokenów.

Na domowym serwerze AI taki współdzielony prefiks może zawierać zasady systemowe, schemat narzędzi, długi dokument, zestaw instrukcji domowych lub powtarzaną historię czatu. Pierwsze żądanie nadal wymaga pełnego kosztu fazy prefill, ale kolejne zgodne żądania mogą pominąć znaczną jego część. Główną korzyścią jest krótsza ścieżka prefill i szybsze wygenerowanie pierwszego tokena, a nie generowanie bez kosztów.

Bez pamięci podręcznej powtarzane prompty ponownie wykonują tę samą fazę prefill

Przed wygenerowaniem odpowiedzi model autoregresyjny przetwarza tokeny wejściowe i tworzy stan klucz-wartość używany podczas późniejszego dekodowania. Długi prompt systemowy, schemat narzędzi, nagłówek dokumentu lub współdzielony blok instrukcji mogą więc wymagać wykonania tej samej pracy fazy prefill przy każdym żądaniu.

Prompt Cache formalizuje tę możliwość, ponownie wykorzystując stany uwagi z nakładających się fragmentów promptu. Na domowym serwerze AI powtarzana część może obejmować tysiące tokenów, mimo że użytkownik dodaje tylko jedno nowe zdanie.

Bez ponownego wykorzystania GPU lub CPU ponownie wykonuje te operacje macierzowe i odczytuje te same wagi modelu dla tego samego prefiksu. Wynik może być identyczny, ale serwer nadal ponosi koszt obliczeniowy przygotowania.

Pamięć podręczna prefiksu przechowuje stan KV dla już przetworzonego prefiksu

Po pierwszym zgodnym żądaniu środowisko uruchomieniowe może zachować stan KV powiązany ze współdzielonym prefiksem. Kolejne żądanie rozpoczyna się od sprawdzenia, czy jego początkowa sekwencja tokenów odpowiada zapisanym blokom.

Automatyczna pamięć podręczna prefiksów w vLLM identyfikuje bloki na podstawie tokenów w bloku oraz poprzedzającego go prefiksu. Zgodne żądania mogą wskazywać te same fizyczne bloki pamięci podręcznej zamiast przydzielać i obliczać zduplikowany stan.

Obiektem możliwym do ponownego wykorzystania nie jest końcowa odpowiedź ani ogólne podsumowanie semantyczne. Jest nim zależny od modelu stan uwagi dla dokładnie zgodnego prefiksu.

Trafienie do pamięci podręcznej pomija współdzieloną fazę prefill, ale nadal oblicza nowy sufiks

Gdy prefiks pasuje, środowisko uruchomieniowe może rozpocząć pracę od zapisanego stanu uwagi i przetworzyć tylko nowe tokeny znajdujące się za granicą zapisanej części. Asystent domowy z jednym stabilnym promptem systemowym może dzięki temu unikać powtarzania pracy przed każdą krótką komendą.

LMCache opisuje ponowne wykorzystywanie pamięci podręcznej KV między żądaniami LLM jako optymalizację warstwy obsługi, a nie zmianę wag modelu.

Nowa wiadomość użytkownika nadal wymaga fazy prefill, a każdy wygenerowany token nadal wymaga obliczeń dekodowania. Buforowanie prefiksów ogranicza głównie zbędną pracę przed rozpoczęciem generowania.

Długie, stabilne prefiksy zapewniają największą poprawę czasu do pierwszego tokena

Pamięć podręczna oszczędza pracę proporcjonalnie do części, która w przeciwnym razie zostałaby obliczona ponownie. Ponowne wykorzystanie 2000-tokenowego prefiksu instrukcji i dokumentu ma większe znaczenie niż ponowne wykorzystanie dziesięciotokenowego powitania.

Projekt obsługi SGLang wykorzystuje strukturalne ponowne użycie KV do przyspieszania obciążeń ze współdzielonym prefiksem. Odpowiednikiem na serwerze domowym może być powtarzana polityka agenta, katalog narzędzi, pakiet wiedzy domowej lub szablon dokumentu.

Dlatego buforowanie prefiksów należy oceniać na podstawie czasu do pierwszego tokena i przepustowości fazy prefill, a nie wyłącznie liczby tokenów na sekundę podczas generowania. Faza dekodowania może pozostać niemal niezmieniona, podczas gdy odpowiedź zacznie się pojawiać szybciej.

Niewielkie zmiany w prompcie mogą przerwać ponowne wykorzystanie na granicy bloku

Pamięć podręczna jest zwykle dokładna w odniesieniu do tokenów i stanu modelu. Zmiana kolejności definicji narzędzi, wstawienie zmiennego znacznika czasu na początku, przełączenie adapterów lub modyfikacja promptu systemowego może sprawić, że kolejne bloki nie będą mogły zostać ponownie wykorzystane.

Wskazówki dotyczące obsługi modeli Hugging Face rozróżniają harmonogramowanie faz prefill i dekodowania. Umieszczenie stabilnych treści na początku promptu sprawia, że większa jego część może zostać ponownie wykorzystana.

Aplikacje powinny więc unikać wstawiania zmiennych danych na początku skądinąd stabilnego prefiksu, jeśli te same informacje można umieścić później.

Pojemność pamięci podręcznej i eksmisja wyznaczają granice serwera domowego

Bloki KV zajmują pamięć, dlatego serwer nie może przechowywać każdego prefiksu bezterminowo. Równoczesne rozmowy, długie konteksty i kilka modeli konkurują o tę samą pulę pamięci, przez co starszy stan możliwy do ponownego wykorzystania może zostać usunięty.

Wyjaśnienie ZimaSpace dotyczące buforowania modeli i opóźnieniu odpowiedzi przy rozgrzanym środowisku przedstawia szerszą hierarchię pamięci podręcznej. Buforowanie prefiksów jest tylko jedną z warstw i nie należy go mylić z utrzymywaniem wag modelu w pamięci.

Mierz współczynnik trafień do pamięci podręcznej, liczbę ponownie wykorzystanych tokenów, czas do pierwszego tokena, przepustowość fazy prefill, wykorzystanie pamięci KV i współczynnik eksmisji przy rzeczywistym poziomie równoczesnego wykorzystania przez domowników.

Dokumentacja NVIDIA TensorRT-LLM opisuje ponowne wykorzystywanie pamięci podręcznej KV jako optymalizację obsługi z tym samym podstawowym ograniczeniem: ponownie wykorzystywany stan pomaga tylko wtedy, gdy zgodne bloki pozostają dostępne.

Centrum Technologii i Sztucznej Inteligencji

Więcej do przeczytania

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.