Przejdź do treści
Czas na świecieEU--:--UK--:--USA--:--CN--:--PLDEFRIT中文EN

portal o AI i technologiiwydarzenia · analizy · wywiady · tło techniczne

Szukaj
NA ŻYWO
›

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ą.

AI i modeleWyjaśnienieAnna KaczmarekOpublikowano: 12 września 20265 min czytaniaŹródła 3
890 bajtów na token: jak DeepSeek ściska KV Cache

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.

Komentarze 0

Źródła

3
  1. 01DeepSeek-V4.1-Flash 模型卡EN
  2. 02DeepSeek V4.1 Flash:更少缓存,更省成本ZH
  3. 03把记忆交给 CPU,大模型会变快ZH

Wszystkie 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.

Anna Kaczmarek

Anna Kaczmarek

AI, modele i technologie

Anna Kaczmarek pisze o technologiach, AI i modelach oraz mediach i internecie, opierając się na dokumentacji, repozytoriach i danych źródłowych, a nie na komunikatach prasowych. Przy testach modeli sprawdza karty techniczne, parametry wejściowe i liczy wyniki na tych samych zbiorach, zamiast powtarzać liczby od producentów. Czeka na premiery API i aktualizacje wag, rozmawia z inżynierami oraz porównuje wersje modeli pod kątem kosztów i opóźnień. Prywatnie self-hostuje usługi i konfiguruje sieci domowe, więc do redakcji wnosi praktykę z własnego serwera. Nie publikuje zapowiedzi ani parametrów, których nie może odtworzyć na własnym środowisku.

Redakcja →

Komentarze

0
  1. Brak komentarzy — bądź pierwszy.

Dodaj komentarz

Komentarze są widoczne publicznie. Nie publikujemy wulgaryzmów, spamu i treści reklamowych.