Tensormesh uruchamia platformę, która obniża koszty inferencji LLM dzięki ponownemu wykorzystaniu pamięci podręcznej KV

Za każdym razem, gdy asystent AI otrzymuje długi dokument, musi go przetworzyć, zanim zacznie odpowiadać. Gdy ponownie pojawiają się te same dokumenty, instrukcje lub historia rozmowy, znaczna część tego przetwarzania może się powtórzyć. W skali przedsiębiorstwa takie powtórzenia mogą pochłaniać kosztowne zasoby GPU, nie przynosząc żadnej dodatkowej korzyści.

Tensormesh chce rozwiązać ten problem za pomocą Tensormesh Platform, ogłoszonej 14 października 2026 r. Firma, której zespół stworzył projekt open source LMCache, wprowadza warstwę zarządzania dla pamięci podręcznej klucz-wartość, czyli pamięci podręcznej KV, przeznaczoną dla organizacji obsługujących duże modele językowe we własnej infrastrukturze.

Platforma zarządza stanem inferencji, który można ponownie wykorzystać, w pamięci GPU, pamięci CPU i pamięci masowej. Jej zamierzona korzyść jest prosta: ograniczyć ilość przetwarzania promptów, które musi powtarzać klaster GPU, a jednocześnie zapewnić operatorom kontrolę nad przechowywaniem, udostępnianiem i monitorowaniem tego stanu w pamięci podręcznej.

Dlaczego pamięć podręczna KV ma znaczenie

Inferencja LLM obejmuje dwa ważne etapy. Podczas wstępnego przetwarzania (prefill) model przetwarza prompt wejściowy. Podczas dekodowania generuje odpowiedź token po tokenie. Pamięć podręczna KV przechowuje pośredni stan związany z mechanizmem uwagi, dzięki któremu model może odwoływać się do przetworzonych tokenów bez ponownego obliczania wszystkiego od początku.

Ponowne wykorzystanie tego stanu między żądaniami może ograniczyć pracę związaną ze wstępnym przetwarzaniem, gdy powtarza się kontekst wejściowy. Na przykład asystent obsługi klienta może korzystać z tej samej instrukcji obsługi produktu, odpowiadając na setki różnych pytań. Agent może wielokrotnie dołączać te same instrukcje lub narzędzia do zmieniającego się zadania.

Różni się to od buforowania gotowej odpowiedzi. System może ponownie wykorzystać obliczenia związane ze wspólnym kontekstem, a jednocześnie wygenerować nową odpowiedź na nowe pytanie.

Dokumentacja automatycznego buforowania prefiksów w vLLM opisuje tę korzyść w przypadku powtarzających się zapytań dotyczących dokumentów i rozmów wieloturowych. Wskazuje też istotne ograniczenie: buforowanie prefiksów przyspiesza przetwarzanie promptu, a nie generowanie nowych tokenów wyjściowych. W przypadku zadań zdominowanych przez długie odpowiedzi lub w dużej mierze niepowtarzalne dane wejściowe korzyści mogą być mniejsze.

Dla klientów korporacyjnych istotne jest pytanie, jaka część ich rzeczywistych obciążeń obejmuje kontekst, który można ponownie wykorzystać — oraz czy można go odzyskać szybciej i taniej, niż obliczać go ponownie.

Przekształcanie pamięci podręcznej w zarządzaną infrastrukturę

W opisie wprowadzonego rozwiązania Tensormesh wskazuje pięć priorytetów operacyjnych: bezpieczeństwo, obserwowalność, odporność, zarządzanie politykami i obsługę wielu dzierżawców. Odpowiadają one na praktyczne potrzeby związane z ochroną danych w pamięci podręcznej, monitorowaniem wydajności, przywracaniem działania po awariach, kontrolowaniem okresu przechowywania i usuwania danych oraz rozdzielaniem zespołów lub klientów korzystających ze współdzielonej infrastruktury.

Firma opisuje również interfejsy API kontrolera umożliwiające przypinanie, lokalizowanie, przenoszenie, kompresowanie i usuwanie wpisów z pamięci podręcznej. Zarządzanie cyklem życia pamięci podręcznej staje się tym samym wyraźnie określonym zadaniem operacyjnym, zamiast pozostawać wyłącznie w gestii poszczególnych procesów inferencji.

Podstawowy projekt LMCache oddziela zarządzanie pamięcią podręczną od silnika obsługującego modele oraz obsługuje przenoszenie danych do innych warstw pamięci i ich pobieranie z wielu warstw pamięci masowej. Dokumentacja opisuje ponowne wykorzystywanie danych między żądaniami, sesjami i instancjami silnika, z możliwością podłączania różnych zapleczy pamięci masowej i transportu.

Platforma dla przedsiębiorstw rozwija te rozwiązania. Zgodnie z przewodnikiem instalacji operator Kubernetes zarządza komponentami silnika pamięci podręcznej, a serwery pamięci podręcznej działają na węzłach GPU, zaś koordynator odpowiada za koordynację całego klastra. Helm służy do wdrażania, a obsługę zapewniają interfejs internetowy i narzędzia wiersza poleceń.

Ta architektura ma znaczenie, ponieważ pamięć GPU jest ograniczonym zasobem. Przechowywanie w niej każdego promptu, który potencjalnie można ponownie wykorzystać, konkurowałoby o zasoby z innymi potrzebami związanymi z inferencją. Przenoszenie mniej potrzebnego w danej chwili stanu do pamięci hosta lub pamięci masowej może zwiększyć ilość przechowywanych danych, choć ich pobieranie wiąże się z dodatkowymi kosztami przepustowości i opóźnień.

Poza identyczne prefiksy promptów

Buforowanie prefiksów sprawdza się, gdy dwa prompty zaczynają się od tych samych tokenów. Generowanie wspomagane wyszukiwaniem (RAG) może być trudniejsze: aplikacja pobiera odpowiednie dokumenty, ale mogą one występować w różnej kolejności lub po innym poprzedzającym je tekście.

Rozważmy dwa hipotetyczne żądania korzystające z tych samych dokumentów. W jednym dokument A występuje przed dokumentem B, a w drugim — dokument B przed dokumentem A. Oba zawierają dane, które można ponownie wykorzystać, ale ich wspólny początek może być krótki.

Tensormesh wykorzystuje CacheBlend, aby rozszerzyć możliwość ponownego użycia danych poza początkową część promptu. Dokumentacja LMCache wyjaśnia, że rozwiązanie to ponownie oblicza wybiórczo część tokenów, a jednocześnie wykorzystuje zapisane w pamięci podręcznej fragmenty. Ponowne obliczanie jest istotne, ponieważ kontekst otaczający dany fragment może wpływać na wewnętrzny stan modelu.

W artykule naukowym poświęconym CacheBlend, zaprezentowanym na EuroSys 2025, odnotowano od 2,2 do 3,3 razy krótszy czas do pierwszego tokenu oraz przepustowość większą od 2,8 do 5 razy w porównaniu z ponownym obliczeniem całej pamięci podręcznej KV w ocenianych obciążeniach. Autorzy przetestowali trzy modele open source i cztery zbiory danych testowych.

Są to wyniki badań uzyskane w określonych warunkach, a nie gwarancja oszczędności w każdym wdrożeniu Tensormesh. Pokazują jednak, dlaczego ponowne wykorzystanie danych wykraczające poza wspólny prefiks jest interesujące z technicznego punktu widzenia: pozwala odzyskać część obliczeń, które umknęłyby konwencjonalnemu dopasowywaniu prefiksów.

Ponowne wykorzystanie danych między węzłami i znaczenie obsługi zależnej od wersji

W ogłoszeniu o premierze opisano transfery KV peer-to-peer, dzięki którym jeden węzeł może pobrać stan z pamięci podręcznej innego węzła. Materiały produktowe firmy opisują natomiast rozdzielenie etapów prefill i dekodowania. Pozwala ono oddzielić przetwarzanie promptu od generowania odpowiedzi, tak aby oba etapy mogły działać na różnych węzłach roboczych.

Są to uzupełniające się sposoby organizacji wnioskowania. Udostępnianie zgodnego stanu pozwala uniknąć ponownego wykonywania obliczeń na innym węźle, a rozdzielenie etapów umożliwia zespołom infrastrukturalnym odmienny przydział zasobów w zależności od zapotrzebowania na moc obliczeniową.

Publicznie dostępne materiały nie są jednak w pełni zgodne co do statusu udostępnienia tych funkcji. W wprowadzeniu do premiery opisano udostępnianie danych między węzłami i rozdzielenie etapów, natomiast w macierzy zgodności dla poszczególnych wersji z datą 17 września transfer peer-to-peer i rozdzielenie etapów wymieniono w planie rozwoju. Dokumentacja funkcji zawiera również strony z podglądem.

Ta sama macierz rozróżnia funkcje sprawdzone w testach Tensormesh od tych obsługiwanych w projektach nadrzędnych, które wymagają dodatkowych testów przed wdrożeniem produkcyjnym. Wymienia vLLM i NVIDIA Dynamo jako zweryfikowane silniki obsługujące wnioskowanie, a SGLang i TensorRT-LLM jako pozycje w planie rozwoju.

Oznacza to, że szeroko zakrojone deklaracje dotyczące zgodności wskazują kierunek rozwoju, a nie dowodzą, że zweryfikowano każdą kombinację modelu i infrastruktury. Zespoły powinny sprawdzić, czy dokładna wersja, silnik obsługujący wnioskowanie, model i tryb pamięci podręcznej, które zamierzają wdrożyć, są obsługiwane.

We wprowadzeniu do premiery opisano konkretnie działanie vLLM w Kubernetes z procesorami graficznymi NVIDIA lub obsługiwanymi układami AMD Instinct za pośrednictwem ROCm oraz korzystanie z pamięci masowej opartej na systemie plików. Wskazano w nim, że pamięć podręczna bez prefiksów dla modeli gęstych oraz obsługa SGLang są planowane na przyszłość. Wyjaśniono również, że pamięć podręczna działa równolegle z modelami hostowanymi samodzielnie; nie jest dodatkiem, który można dołączyć do dowolnego interfejsu API hostowanego modelu.

Gdzie rozwiązanie może się opłacać

Najlepszymi kandydatami są aplikacje, które wielokrotnie przetwarzają obszerne, wspólne konteksty: wewnętrzni asystenci korzystający z baz wiedzy, usługi analizy dokumentów oraz agenci wielokrotnie odwołujący się do stałego zbioru instrukcji lub materiałów referencyjnych.

Przydatna ocena powinna porównywać działanie przy pustej i rozgrzanej pamięci podręcznej z użyciem reprezentatywnego ruchu. Operatorzy powinni mierzyć czas do pierwszego tokenu, przepustowość, czas pobierania danych z pamięci podręcznej, wykorzystanie procesorów graficznych oraz koszty pamięci, przechowywania i sieci związane z utrzymywaniem stanu.

Sam współczynnik trafień w pamięci podręcznej nie wystarczy. Wysoki współczynnik jest korzystny tylko wtedy, gdy odzyskane obliczenia przynoszą korzyść netto po uwzględnieniu narzutu związanego z przesyłaniem danych i zarządzaniem nimi. Podobnie szybsze wygenerowanie pierwszego tokenu nie musi oznaczać proporcjonalnie szybszego zakończenia całej odpowiedzi.

Jakość odpowiedzi należy sprawdzić osobno, zwłaszcza gdy buforowane fragmenty są łączone w zmienionych kontekstach. Selektywne ponowne obliczanie w CacheBlend ma rozwiązać ten problem, ale testy produkcyjne powinny obejmować własne dokumenty organizacji, formaty promptów i konfiguracje modeli.

Utrzymywanie danych i izolacja dzierżawców nabierają większego znaczenia, gdy pamięć podręczna wykracza poza pojedynczy proces. Istotne z operacyjnego punktu widzenia pytania dotyczą tego, kto może ponownie wykorzystać dany wpis, jak długo pozostaje on dostępny oraz jak zmiany zasad lub żądania usunięcia wpływają na zapisany stan. Zapowiedziane przez Tensormesh funkcje zarządzania mają umożliwić kontrolowanie tych decyzji.

Praktyczny sposób na ograniczenie powtarzających się obliczeń

Według ogłoszenia firmy Tensormesh Platform jest dostępna od momentu premiery. Jej znaczenie polega na traktowaniu stanu wnioskowania jako zasobu, którym można zarządzać w całej flocie, zachowując możliwość ponownego wykorzystania obliczeń po zakończeniu obsługi danego żądania.

Dla przedsiębiorstw korzystających z własnej infrastruktury LLM to konkretny sposób na zwiększenie efektywności: ponowne wykorzystanie większej części pracy związanej z przetwarzaniem promptów, która została już wykonana. Rezultaty będą zależeć od częstotliwości powtarzania się obciążeń, zgodności pamięci podręcznej i kosztu przesyłania danych, ale są to mierzalne kwestie inżynieryjne, które zespoły mogą sprawdzić na podstawie własnego ruchu.