Prefix Caching

Prefix Caching to ponowne wykorzystanie obliczonego KV Cache wspólnego początku sekwencji w kolejnych żądaniach. Model może pominąć przetwarzanie tego fragmentu podczas Prefill. Nowe pytanie o ten sam dokument nadal wymaga obliczeń dla nowej części promptu. Dokumentacja vLLM 0.21.0, „Introduction” i „Limits” rozróżnia tę oszczędność od późniejszego generowania odpowiedzi.

Liczy się identyczny prefiks tokenów w zgodnym kontekście obliczeń, a nie podobieństwo znaczenia. Key i value dalszych warstw zależą od wcześniejszego kontekstu. Ten sam końcowy akapit po zmienionym początku nie daje automatycznie tego samego KV.

vLLM identyfikuje blok na podstawie jego tokenów, identyfikatora poprzedniego bloku oraz dodatkowych danych, m.in. identyfikatora adaptera LoRA i wejścia obrazowego. W opisanej wersji zapisuje do ponownego użycia pełne bloki. Zobacz opis mechanizmu Automatic Prefix Caching. Zgodność modelu, pozycji i innych ustawień wpływających na KV jest warunkiem poprawnego ponownego użycia; samo porównanie tekstów nie wystarcza.

Jeden zmieniony token, różne skutki

Cache naszego przykładu zawiera sekwencję A B C D E F G H, podzieloną na bloki po dwa tokeny. Litery oznaczają umowne identyfikatory tokenów. Nowe żądanie zamienia dokładnie jedną pozycję na X. Zmieniaj jej miejsce i sprawdzaj, ile całych bloków można odzyskać.

Zmiana H na X pozostawia siedem wspólnych tokenów, lecz tylko sześć w pełnych blokach. Zmiana A na X daje zero trafień, mimo że dalsze siedem tokenów się zgadza. Wszystkie pozostałe warunki są w przykładzie stałe; cache jest dostępny i niczego z niego nie usunięto.

To cache obliczeń, nie gotowej odpowiedzi. Decode nadal musi wytworzyć dalsze tokeny, a usunięte bloki trzeba policzyć ponownie. Organizację pamięci w bloki wyjaśnia PagedAttention.

Wykorzystuję treści generowane przez AI jako część mojego codziennego procesu nauki.