RAM i cache: ile pamięci naprawdę potrzebuje serwer LLM?

RAM i VRAM pełnią różne role, dlatego zapotrzebowania serwera nie da się odczytać z jednej liczby przy modelu. VRAM to pamięć karty GPU. RAM jest pamięcią systemową, z której korzystają również aplikacja, baza dokumentów i sam Linux. Nawet gdy obliczenia modelu odbywają się na karcie, te elementy nadal potrzebują miejsca.

W serii CORE 1.1 oddzielamy ładowanie modelu od późniejszego tworzenia odpowiedzi. Porównujemy zarówno modele pracujące na GPU, jak i konfiguracje wykorzystujące CPU i RAM do części obliczeń. Zakres pomiarów opisuje wspólna metodyka testów LLM. Dzięki jednakowym zasadom można sprawdzić, kiedy pamięć jest potrzebna i co właściwie pokazuje dany licznik.

Pamięć podczas startu i podczas odpowiedzi

Tabela rozdziela najwyższy zaobserwowany odczyt pamięci procesu podczas ładowania od odczytu w trakcie odpowiedzi. Obok pokazuje najmniejszy dostępny zapas RAM całego systemu w czasie tych odpowiedzi. To różne pytania: pierwsze dotyczy jednego programu, drugie miejsca pozostającego systemowi i innym usługom. Dostępny RAM obejmuje również pamięć podręczną, którą system może odzyskać — nie jest osobną pulą, którą można dodać do pamięci procesu.

GiB to jednostka pamięci stosowana w pomiarach systemowych; różni się od dziesiętnego GB. Litera B w nazwie modelu oznacza natomiast miliardy parametrów, nie ilość pamięci. Dopiski Q4, Q8 i MXFP4 oznaczają formaty ich zapisu. Ogólną zasadę oszczędniejszego zapisu, czyli kwantyzację, wyjaśnia słownik AI i GPU.

Przy tym samym modelu 72B Q4 najwyższy odczyt RAM procesu podczas odpowiedzi wyniósł 1,2 GiB przy pracy na GPU, a 22,7 lub 33,0 GiB po przeniesieniu części obliczeń na CPU. Z kolei podczas ładowania wariantu GPU odczyt osiągnął 41,3 GiB — przygotowanie modelu i późniejsza obsługa odpowiedzi wymagają więc osobnego planowania. Wykorzystanie VRAM ograniczyło RAM przypisany procesowi podczas odpowiedzi, ale nie oznacza to, że resztę pamięci można bez wpływu na szybkość oddać innym aplikacjom: dostępny zapas obejmuje także odzyskiwalną pamięć podręczną.

Odczyty podczas odpowiedzi obejmują oba wejścia testowe — 2048 i 8192 tokeny — z pięcioma mierzonymi rundami dla każdego. Nie obejmują ładowania, rozgrzewek i przerw między rundami. Kolumna startu ma osobny zakres. Tych szczytów nie należy dodawać: mogły wystąpić w różnych chwilach, a część liczników może opisywać te same dane.

PSS, użyty w tabeli, to sposób przypisania pamięci do procesu z proporcjonalnym udziałem we współdzielonych obszarach. Jego niska wartość nie oznacza, że kompletny serwer potrzebuje tylko tyle RAM. Jeśli w krótkiej fazie nie było próbki, brak odczytu nie jest zerowym zużyciem.

Co naprawdę trzeba zmieścić w pamięci?

Wyobraź sobie asystenta odpowiadającego na pytania z firmowych dokumentów. Oprócz programu z modelem może działać wyszukiwarka, baza danych i kolejka zadań. Aplikacja przechowuje też tekst bieżących zapytań i wyniki, zanim zapisze je lub odeśle użytkownikowi. Przy imporcie plików pojawia się dodatkowa praca, która może nakładać się na obsługę rozmów.

To przykład planowania aplikacji, nie zestaw usług zmierzony w naszej próbie. Pomaga jednak przygotować sensowną listę: co będzie działało stale, co tylko podczas importu i które zadania mogą wystąpić jednocześnie. Dopiero dla takiego zestawu warto sprawdzać zapas pamięci, zamiast mnożyć rozmiar pliku modelu przez liczbę użytkowników.

W planie uwzględnij też etapy pracy: wczytywanie modelu, gotowość bez zapytań i tworzenie odpowiedzi. Każdy może wymagać innego zapasu pamięci.

Zajęta pamięć nie zawsze oznacza brak miejsca

Linux wykorzystuje RAM również jako pamięć podręczną plików, czyli cache. Przechowuje w niej dane, które mogą przydać się ponownie. Część takiej pamięci system może odzyskać dla innych potrzeb, dlatego samo małe „wolne RAM” bywa mylące.

Przy odczytach warto rozdzielić pamięć przypisaną konkretnemu procesowi i pamięć dostępną całemu systemowi. PSS pomaga opisać proces, a MemAvailable szacuje, ile RAM system może udostępnić nowym zadaniom bez przenoszenia danych do swapu, czyli obszaru pomocniczego na dysku. Żaden z tych liczników nie zastępuje drugiego.

„Dostępna” nie oznacza jednak „wolna bez żadnego kosztu”. Odzyskanie pamięci podręcznej może sprawić, że model ponownie odczyta część plików z dysku. Dlatego wysoki odczyt MemAvailable nie jest obietnicą, że dodatkowe aplikacje nie wpłyną na czas odpowiedzi.

Nie dodawaj bezpośrednio pamięci procesu i całego cache jako dwóch niezależnych kosztów modelu. Mogą częściowo opisywać te same dane. Praktycznym sygnałem do sprawdzenia jest nie samo wysokie „zajęte RAM”, lecz utrata dostępnego zapasu połączona z opóźnieniami lub przenoszeniem danych na dysk.

Dlaczego drugi start może być szybszy?

Jeśli pliki były niedawno odczytane, część danych może pozostać w RAM. Kolejne uruchomienie korzysta wtedy z pamięci zamiast ponownie czytać wszystko z NVMe. Nawet kontrola sumy pliku modelu może przygotować taki „ciepły” cache przed startem programu.

To wyjaśnienie działania pamięci podręcznej; w tej serii nie mierzyliśmy osobno przyspieszenia drugiego uruchomienia.

Praktyczny przykład to restart usługi po zmianie ustawienia, gdy serwer wcześniej obsługiwał ten sam model. Taki start ma inne warunki niż pierwsze uruchomienie po przygotowaniu maszyny. Porównując oba, zapisz warunki i oddziel czas ładowania od czasu późniejszej odpowiedzi. Szybki restart sam w sobie nie dowodzi ani szybkości dysku, ani minimalnej wymaganej ilości RAM.

Czy większy RAM pozwala uruchomić większy model?

Może pomóc, jeżeli silnik obsługuje podział danych i obliczeń między GPU i CPU. Nie powiększa jednak fizycznej pamięci karty. Porównanie GPU i RAM na tym samym modelu 72B zestawia zajęcie pamięci z czasem odpowiedzi. W teście modelu 235B opisujemy osobną, większą konfigurację korzystającą z obu rodzajów pamięci.

Taki podział warto rozważyć, gdy ważniejsze jest uruchomienie konkretnego modelu niż najkrótsze oczekiwanie. Na przykład analiza dokumentów wykonywana w tle ma inne wymagania niż rozmowa z asystentem na żywo. To przykłady planowania, a nie dodatkowe wyniki testów. Dobór nadal wymaga konkretnej wersji modelu, długości zapytań i akceptowalnego czasu pracy. Samo zwiększenie RAM nie gwarantuje szybszego generowania tekstu.

Jak zaplanować zapas dla własnej aplikacji?

Sprawdź uruchomienie, obsługę typowego zapytania i sytuację, w której równocześnie pracują pozostałe usługi. Obserwuj pamięć procesu i systemu oraz opóźnienia aplikacji. Powtórz próbę z importem dokumentów lub inną pracą, która rzeczywiście będzie występować w tle.

Wniosek: planuj zapas RAM dla całej aplikacji, z uwzględnieniem jej najbardziej wymagających etapów. To pomaga dobrać konfigurację do rzeczywistej pracy. Pojemność karty omawiamy osobno w porównaniu 96 GB VRAM.

Sprawdź konfigurację serwera lub opisz model i usługi, które mają działać razem. Definicje znajdziesz w słowniku AI i GPU.