Kompresja pamięci podręcznej KV to decyzja infrastrukturalna, a nie debata o modelach
Kompresja pamięci podręcznej KV (KV cache) to już nie jest debata o jakości modelu. To decyzja zakupowa w obszarze infrastruktury, z którą wiąże się konkretny problem matematyczny.
Mówię to wprost, ponieważ zbyt wiele zespołów wciąż traktuje pamięć LLM z długim kontekstem jak wyścig na benchmarki: TurboQuant kontra OSCAR kontra EpiCache – wybierz zwycięzcę i idź dalej. W praktyce wdrożenia nie kończą się w ten sposób. Kończą się porażką, ponieważ jeden zespół optymalizuje pod kątem liczby bitów, drugi pod kątem przenośności, a trzeci zbyt późno odkrywa, że historia wieloetapowego czatu to zupełnie inny problem niż pojedynczy prompt o długości 128 tys. tokenów. Według podsumowania MarkTechPost z 18 czerwca, te trzy podejścia rozwiązują sąsiadujące ze sobą wąskie gardła, a nie ten sam problem.
Kompresja pamięci podręcznej KV staje się bolesna, gdy sufitem jest HBM, a nie FLOPy
Matematyka pamięci to element, którego operatorzy nie mogą ignorować. Przykład źródłowy wykorzystuje Llama-3.1-70B w formacie BF16: około 0,31 MB pamięci podręcznej KV na token, co daje około 40 GB przy 128 tys. tokenów i ponad 300 GB przy 1 mln tokenów. To moment, w którym pamięć podręczna może przekroczyć rozmiar samych wag modelu. Jeśli obsługujesz zapytania z długim kontekstem przy dużej współbieżności, każdy zdekodowany token przeciąga tę pamięć podręczną przez pamięć o wysokiej przepustowości (HBM).
Ta zmiana znaczy więcej niż kolejny punkt w rankingu. Gdy dekodowanie staje się ograniczone przepustowością, krzywa kosztów ulega zmianie. Nie pytasz już: „Czy ten model dobrze odpowiada?”, lecz: „Ile sesji mogę utrzymać, zanim ruch w pamięci zniszczy opóźnienia?”.
W jednym z testów obciążeniowych, które przeprowadziłem w zeszłym miesiącu, wybór modelu nie był głównym ograniczeniem. Ponowne wykorzystanie prefiksu wyglądało świetnie w izolacji, ale gdy liczba współbieżnych sesji rosła, opóźnienia typu tail latency skakały, ponieważ ograniczeniem był ruch w pamięci, a nie moc obliczeniowa. Dlatego praca nad 2-bitową bazą KIVI wciąż ma znaczenie w 2026 roku: zdefiniowała ona kwantyzację pamięci podręcznej KV jako problem systemów wnioskowania, a nie tylko sztuczkę kompresyjną.
TurboQuant to gra o przenośność, a nie uniwersalny zwycięzca
TurboQuant jest imponujący z konkretnego powodu. Google Research i NYU stworzyły podejście niezależne od danych, które atakuje kanały odstające (outlier channels) bez kalibracji. Najpierw losowo rotuje wektory, aby współrzędne zachowywały się bardziej jak niezależne zmienne Gaussa. Następnie stosuje wstępnie obliczony kwantyzator skalarny i transformację 1-bitową QJL do reszty. Teoretyczne założenie jest silne: zniekształcenia pozostają w granicach małego stałego czynnika dolnej granicy.
To właściwe narzędzie, gdy zależy Ci na przenośności modelu i nie możesz pozwolić sobie na niestandardową kalibrację dla każdego celu wdrożenia. Zgłaszany złoty środek to zakres od 3 do 4 bitów, gdzie jakość pozostaje niemal bezstratna w obciążeniach podkreślanych w publikacji. To czyni TurboQuant atrakcyjnym dla zespołów zarządzających mieszanymi flotami lub eksperymentujących z wieloma architekturami.
Ale oto moja kontrowersyjna opinia: ludzie wciąż powtarzają niewłaściwą obietnicę. Najgłośniejszym hasłem wokół TurboQuant jest „8-krotnie szybsza uwaga na H100” z bloga Google Research o TurboQuant, jednak artykuł źródłowy słusznie zauważa, że odnosi się to do wąskiego mikrobenchmarku, a nie do pełnego procesu obsługi zapytań. Widziałem ten wzorzec wcześniej przy kernelach wnioskowania: sukces na jednym etapie staje się argumentem zakupowym dla całego stosu technologicznego. W ten sposób zespoły fundują sobie rozczarowanie.
OSCAR ma znaczenie, bo ktoś faktycznie wdrożył trudne elementy
Jeśli Twoim celem jest wdrożalna kompresja pamięci podręcznej KV do INT2, OSCAR jest obecnie najbardziej praktycznym rozwiązaniem. System Together AI nie tylko proponuje rotację uwzględniającą mechanizm uwagi (attention-aware), ale pakuje wokół tego stronicowanie o mieszanej precyzji, kernele Triton i integrację ze SGLang. To duża sprawa, ponieważ zyski produkcyjne zazwyczaj wynikają z gotowego pakietu, a nie z samej publikacji naukowej.
Szczegóły mają znaczenie. OSCAR utrzymuje tokeny typu „sink” oraz najnowsze tokeny w BF16, kompresując historyczne tokeny do INT2, pozostawiając tylko około 0,24% tokenów nieskompresowanych przy kontekście 128 tys. tokenów. Dostarcza również wstępnie obliczone rotacje dla wspieranych modeli, co eliminuje jeden uciążliwy krok wdrożeniowy. Deklarowane korzyści są znaczne: do 7,83-krotnie wyższa przepustowość na poziomie zadań, około 8-krotna redukcja pamięci podręcznej KV przy kontekście 100 tys. i nawet 3-krotnie szybsze dekodowanie w testowanych konfiguracjach.
Dlatego uważam, że OSCAR obecnie wygrywa argument wdrożeniowy w ekstremalnie niskiej precyzji bitowej. Nie dlatego, że pomysł jest ładniejszy, ale dlatego, że ktoś zasypał przepaść między teorią kwantyzacji a rzeczywistością serwowania modeli.
Argument za wyborem jednego zwycięzcy w bezpośrednim starciu nadal upada
Uczciwym kontrargumentem jest to, że przedsiębiorstwa potrzebują prostych odpowiedzi. Jeśli jedna metoda przewyższa drugą pod względem jakości w benchmarkach i przepustowości, wybór lidera zmniejsza złożoność. Jest w tym logika. Każda dodatkowa ścieżka wnioskowania zwiększa narzut testowy, logikę wycofywania zmian (rollback), pracę nad obserwowalnością i obciążenie wsparcia. Standaryzacja na jednej metodzie jest często rozsądnym wyborem operacyjnym.
Zgadzam się z tym instynktem. Po prostu nie uważam, że obecne dowody wspierają wybór uniwersalnego zwycięzcy.
Porównanie przedstawione przez OSCAR sugeruje, że TurboQuant wypada słabo przy podobnych budżetach, ale ten odczyt zawiera zastrzeżenia, które artykuł źródłowy słusznie wskazał: porównanie odbywa się w ramach frameworka OSCAR, kwantyzuje wszystkie warstwy, używa jednego ziarna losowości i ocenia TurboQuant poniżej jego docelowego zakresu 3-4 bitów. To za mało, by wydać ostateczny werdykt. Z drugiej strony, argument o przenośności TurboQuant nie odpowiada na pytanie, czy w przyszłym tygodniu uzyskasz stabilne zachowanie INT2 w produkcji na swoim konkretnym stosie.
Więc prawdziwa decyzja jest węższa i bardziej nudna:
- Wybierz TurboQuant, gdy wdrożenie niezależne od modelu i niemal bezstratne zachowanie w zakresie 3-4 bitów są ważniejsze niż absolutna kompresja.
- Wybierz OSCAR, gdy potrzebujesz obsługi INT2 dla wspieranych modeli, integracji produkcyjnej i natychmiastowych oszczędności pamięci przy długim kontekście.
- Nie zmuszaj żadnego z nich do rozwiązywania problemów zarządzania pamięcią w wieloetapowych konwersacjach, bo to nie jest ich zadanie.
EpiCache przypomina, że długie prompty i długie rozmowy to różne problemy systemowe
To element, który umyka wielu zespołom. Pojedynczy prompt o długości 128 tys. tokenów i dwugodzinna rozmowa to nie to samo obciążenie, nawet jeśli oba wyglądają na slajdach jak „długi kontekst”.
EpiCache od Apple odnosi się bezpośrednio do przypadku konwersacyjnego. Zamiast pytać tylko o to, jak precyzyjnie przechowywać tokeny, pyta o to, którą historię utrzymać jako aktywną, jak podzielić ją na spójne epizody i jak pobierać właściwy epizod podczas wnioskowania. Framework dodaje wstępne wypełnianie blokowe (block-wise prefill), klastrowanie epizodyczne, pobieranie z epizodów i budżetowanie pamięci warstwowej.
Operacyjnie to inna oś niż kwantyzacja pamięci podręcznej KV. To zarządzanie pamięcią podręczną, a nie tylko jej zmniejszanie. Zgłaszane zyski w materiale źródłowym są dokładnie powodem, dla którego to rozróżnienie ma znaczenie: do 40% wyższa dokładność niż w przypadku bazowych metod usuwania danych, dokładność niemal pełnej pamięci podręcznej przy 4-6-krotnej kompresji, do 3,5-krotnie niższe szczytowe zużycie pamięci i około 2,4-krotnie niższe opóźnienia w ocenianych benchmarkach konwersacyjnych.
Moja odpowiedź na mentalność „po prostu wybierz zwycięzcę” jest prosta: EpiCache łączy się z TurboQuant lub OSCAR. Więc jeśli Twoim obciążeniem jest copilot wsparcia, asystent badawczy lub wewnętrzny agent z głęboką historią czatu, najlepszy stos może składać się z jednej metody do retencji i drugiej do precyzji przechowywania. To nie niezdecydowanie. To projektowanie systemów.
Właściwe pytanie brzmi: które ograniczenie kosztuje Cię najwięcej?
Kiedy wchodzę na przegląd wnioskowania, nie zaczynam od nazw publikacji. Zaczynam od trzech pytań.
Po pierwsze, czy flota serwująca jest ograniczona pamięcią w czasie dekodowania, czy wciąż mocą obliczeniową? Po drugie, czy potrzebujemy przenośności między modelami, czy możemy mocno zoptymalizować pod wspierany stos? Po trzecie, czy obciążenie jest zdominowane przez jeden długi prompt, czy przez wiele etapów konwersacji?
Te pytania zazwyczaj szybko zawężają pole wyboru. Jeśli dominuje przenośność, TurboQuant ma bardziej przejrzysty argument. Jeśli Twój zespół korzysta już ze stosu wspieranego przez OSCAR i potrzebujesz agresywnych oszczędności INT2 już teraz, OSCAR wygląda solidniej. Jeśli punktem bólu są sesje wsparcia lub pamięć agenta, EpiCache powinien znaleźć się w projekcie, nawet jeśli stosujesz kwantyzację.
Dlatego wciąż wracam do tej samej kontrowersyjnej tezy: kompresja pamięci podręcznej KV to w rzeczywistości nie wyścig. To problem projektowania stosu technologicznego, który został sprzedany jako walka w klatce.
Powiązane lektury
Martin Kuvandzhiev
CEO and Founder of Encorp.io with expertise in AI and business transformation