Duży plik modelu na dysku, pamięć zajęta przez proces i odczyt „used” w systemie nie oznaczają tego samego. Linux może przechowywać odczytane dane w pamięci podręcznej, aplikacja może mapować plik modelu, a jego warstwy mogą jednocześnie znajdować się w VRAM.
Żeby dobrać RAM, warto więc śledzić zapas dostępny dla systemu i pamięć procesu, a nie tylko rozmiar pliku GGUF. Pojemność samej karty opisujemy osobno w poradniku modeli mieszczących się w 96 GB VRAM.
Nasz pomiar pamięci z Qwen3-8B
W krótkich próbach z modelem na GPU najwyższy zarejestrowany PSS procesu wyniósł 813,20 MiB. To pamięć przypisana procesowi według konkretnego licznika, nie całkowite zapotrzebowanie serwera na RAM. Obok pozostają system, cache plików i pozostałe usługi.
| Etap | Najwyższy odczyt PSS procesu | Najniższy MemAvailable systemu | Liczba próbek |
|---|---|---|---|
| Gotowy model, 10 s bez zapytań tuż po załadowaniu | 750,02 MiB | 89,41 GiB | 5 |
| Wejście 2048 tokenów, 1 zapytanie naraz | 782,44 MiB | 89,39 GiB | 3 |
| Wejście 8192 tokeny, 4 zapytania naraz | 813,20 MiB | 89,35 GiB | 10 |
MiB i GiB są jednostkami binarnymi: 1 GiB = 1024 MiB. Wykres pokazuje te same maksymalne odczyty PSS w GiB. W próbkach tych etapów użycie swapu wynosiło zero. System przechowywał również cache plików z wcześniejszych zadań — nie przypisujemy całego tego cache modelowi Qwen3-8B.
Sprzęt i sposób pomiaru
| Element | Konfiguracja pomiaru |
|---|---|
| RAM systemowy | 96 GB |
| CPU | AMD EPYC 4565P, 16 rdzeni / 32 wątki |
| GPU | RTX PRO 6000 Blackwell Max-Q Workstation Edition, 96 GB VRAM |
| System i sterownik | Rocky Linux 10.2, NVIDIA 595.91.07 |
| Model i silnik | Qwen3-8B Q4_K_M, llama.cpp b11146, model na GPU |
Każdy scenariusz obejmował rozgrzewkę i trzy mierzone rundy, z 256 nowymi tokenami na odpowiedź. API działało lokalnie, miało cztery sloty po 8704 tokeny, KV cache F16 i Flash Attention; cache promptu był wyłączony. Przed scenariuszem GPU schładzało się do najwyżej 40°C.
RSS i PSS procesu oraz pamięć hosta odczytywaliśmy przez /proc co około dwie sekundy. Do tabeli weszły próbki gotowości oraz ukończonych mierzonych rund, bez rozgrzewki i przerw. Zarejestrowane maksima mogą ominąć krótsze skoki. Faza ładowania miała tylko jedną próbkę, dlatego nie używamy jej do określania szczytu pamięci.
Pomiar miał ciepły cache systemu po sprawdzeniu sumy modelu. Nie ograniczaliśmy dostępnego RAM, więc nie jest to test minimalnej wymaganej pojemności. CSV zawiera również maksymalne odczyty RSS, a JSON — zakresy i definicje liczników. Narzut tej telemetrii odróżnia badanie od wcześniejszego testu szybkości API.
Trzy odczyty, trzy różne pytania
| Odczyt | Na jakie pytanie odpowiada? |
|---|---|
| MemAvailable | Ile pamięci system może udostępnić nowym aplikacjom bez swapowania? |
| RSS procesu | Ile pamięci z mapowań procesu jest obecnie w RAM? |
| PSS procesu | Ile pamięci przypada na proces po proporcjonalnym podziale współdzielonych stron? |
MemAvailable uwzględnia część pamięci, którą system może odzyskać, dlatego nie jest tym samym co MemFree. RSS współdzielonych danych może być widoczny w kilku procesach; PSS dzieli ten udział. Definicje opisuje dokumentacja pamięci w /proc.
Nie dodawaj bezpośrednio RSS procesu i całego systemowego cache jako dwóch niezależnych kosztów modelu. Te odczyty mogą częściowo opisywać te same strony pamięci.
Dlaczego drugi start może być inny
Po odczytaniu pliku modelu część danych może zostać w cache systemu. Następne uruchomienie może więc korzystać z pamięci zamiast ponownie odczytywać cały plik z dysku. To ciepły start, który różni się od startu bez tych danych w cache.
Nawet sprawdzenie sumy kontrolnej czyta cały plik i może rozgrzać cache przed pomiarem. Dlatego czas od uruchomienia programu do gotowości API trzeba opisywać wraz z warunkami, w których go uzyskano. Szybki drugi start nie jest sam w sobie testem szybkości NVMe.
llama.cpp udostępnia różne tryby ładowania modelu, w tym mapowanie pliku. Nie zakładaj, że rozmiar pliku oznacza identyczną ilość prywatnej pamięci procesu w każdym trybie.
Jak ustalić potrzebny zapas RAM
Sprawdź oddzielnie ładowanie modelu, oczekiwanie na zapytanie i pracę pod ruchem. Dodaj usługi, które rzeczywiście mają działać obok: bazę dokumentów, indeks, API, kolejkę zadań czy przetwarzanie plików.
Najbardziej przydatny jest najmniejszy zaobserwowany MemAvailable podczas reprezentatywnego zadania, zestawiony ze swapem i czasem odpowiedzi. Zapas powinien uwzględniać również aktualizację modelu, dodatkowe procesy i krótkie skoki obciążenia. Jedna krótka próba nie wyznacza minimalnej pamięci dla każdej aplikacji korzystającej z tego samego modelu.
Kiedy więcej RAM może pomóc
Większa pamięć systemowa daje przestrzeń dla dodatkowych usług i cache, a przy konfiguracji częściowo korzystającej z CPU także dla danych modelu po stronie hosta. Nie zamienia się jednak automatycznie w VRAM i nie gwarantuje większej liczby tokenów na sekundę, gdy ograniczenie leży gdzie indziej.
Przed rozbudową sprawdź, czego faktycznie brakuje: pamięci hosta, miejsca na GPU, czasu CPU czy szybkości odczytu danych. To pozwala dobrać konfigurację pod zadanie, zamiast kierować się jedną liczbą w specyfikacji.
Zobacz również rolę CPU w pracy z LLM i wybór dystrybucji Linux.
Sprawdź konfigurację serwera lub opisz modele i usługi, które mają działać równocześnie.