890 bajtów na token: jak DeepSeek ściska KV Cache
Koszt długiego kontekstu rozbija się zwykle o pamięć, nie o wagi. DeepSeek V4.1 Flash ściska KV Cache do około 890 bajtów na token. Zapotrzebowanie na HBM spada do jednej czwartej, a na SSD do jednej ósmej w porównaniu z poprzednią generacją.

Model, który czyta długi dokument, trzyma klucze i wartości uwagi dla każdego tokenu w kontekście. Ten wynik pośredni to KV Cache. Rośnie liniowo wraz z długością kontekstu i decyduje o tym, ile długich sesji zmieści się naraz na jednej karcie. Dlatego koszt długiego kontekstu rozbija się o pamięć, a nie o wagi.
Ile miejsca zajmuje KV Cache, można policzyć na publicznym modelu. Qwen3-8B w publicznej konfiguracji, przy BF16 lub FP16, gdzie każda wartość zajmuje 2 bajty, potrzebuje 147456 bajtów danych KV na jeden token, czyli około 147KB. Rachunek wygląda tak: 2 kopie K/V razy 36 warstw razy 8 głowic KV razy 128 wymiarów na głowicę razy 2 bajty. Do tego dochodzą dodatkowe koszty zarządzania pamięcią podręczną.
DeepSeek w V4.1 Flash postawił na kompresję. Z oficjalnego porównania wynika, że względem poprzedniej generacji zapotrzebowanie modelu na HBM spadło do jednej czwartej, a na SSD do jednej ósmej. W stosunku do pierwszego modelu KV Cache zmniejszył się 437 razy. Jeśli zestawić oficjalne dane z opisami z różnych źródeł, KV Cache w V4.1 Flash to około 890 bajtów na token.
Dlaczego akurat ta liczba jest ważna? Bo trafienia w pamięć podręczną mają duży udział w kosztach zadań typu Agent. Zadanie agenta kodującego to wielokrotne czytanie kodu, sprawdzanie materiałów i uruchamianie testów, a historia rośnie z każdą rundą. Kiedy pamięć karty się zapełni, system usuwa część cache. W kolejnej rundzie trzeba od nowa robić Prefill, więc użytkownik dłużej czeka na pierwszy token.
Inżynieryjne wyjście to podział na warstwy. Dane, które właśnie powstają, zostają w HBM. Te możliwe do ponownego użycia w krótkim okresie trafiają do pamięci DDR po stronie CPU, a te, do których dawno nie sięgano, spływają na SSD albo do pamięci zdalnej. Na przykład KV Offloading w vLLM pozwala przenosić bloki cache do pamięci CPU i konfigurować dodatkową warstwę pamięci masowej. Przy pobieraniu dane przechodzą przez warstwę cache po stronie CPU.
890 bajtów to więc nie tylko liczba. Oznacza, że ta sama pamięć karty udźwignie więcej równoległych długich sesji, a zespoły prowadzące własne serwery inferencji kupią mniej kart. Dla działów zakupów i utrzymania rozmiar KV Cache liczy się dziś tak samo jak jakość modelu. Warto wpisać go na listę kryteriów wyboru.
Źródła
3Wszystkie liczby i cytaty w tym tekście pochodzą z poniższych źródeł. Nie dopisujemy danych, których w źródłach nie ma.
Materiały zostały przygotowane przez zespół redakcyjny wspierane przez AI.
Komentarze
0- Brak komentarzy — bądź pierwszy.