Model na GPU czy podzielony między GPU i CPU?

Jeden model można uruchomić na GPU albo podzielić jego pracę między kartę, procesor i RAM. Sprawdzamy, ile pamięci karty można w ten sposób zwolnić i jak zmienia się czas odpowiedzi. Te dwie informacje pomagają wybrać podział pasujący do własnego zadania.

VRAM to pamięć karty graficznej; RAM jest pamięcią systemową. Przeniesienie części pracy z GPU na CPU nazywamy tutaj offloadem. RAM nie staje się przez to drugą kartą graficzną: część obliczeń wykonuje procesor, a model musi uwzględnić ich wynik.

Ten sam model, trzy sposoby podziału pracy

Punktem odniesienia jest Qwen2.5-72B-Instruct Q4_K_M na GPU. „72B” oznacza około 72 miliardów parametrów modelu, nie gigabajty, a Q4_K_M to oszczędniejszy format ich zapisu o obniżonej precyzji. Dwa kolejne warianty zwiększają udział procesora i RAM. Zachowujemy te same pliki modelu, format, sprzęt, tekst wejściowy i długość odpowiedzi. Dzięki temu porównanie pokazuje wpływ podziału pracy przy tym samym modelu.

Nowa seria korzysta ze wspólnej metodyki CORE 1.1: pełnej rozgrzewki i pięciu mierzonych odpowiedzi dla każdego wejścia. To pozwala zestawić dane także z artykułami o zajęciu CPU i pamięci systemowej, które korzystają z tych samych przypadków.

GiB to jednostka pamięci stosowana w pomiarach systemowych; różni się od dziesiętnego GB.

Czasy dotyczą wejść 2048 i 8192 tokeny oraz odpowiedzi długości 256 tokenów, przy jednym zapytaniu naraz. Token jest fragmentem tekstu, nie zawsze całym słowem. Mediana to środkowy wynik z pięciu prób. Szczyty VRAM i RAM procesu pochodzą z okien odpowiedzi obu długości; nie muszą wystąpić w tej samej chwili.

W pośrednim wariancie szczyt zajęcia VRAM spadł niemal o połowę: z 43,9 do 22,5 GiB. Towarzyszył temu wzrost RAM procesu oraz dłuższe oczekiwanie. Przy krótszym wejściu typowa odpowiedź trwała około 4,2 min zamiast 11,6 s na GPU. Jeszcze większy udział CPU obniżył szczyt VRAM do 12,2 GiB, ale wydłużył tę odpowiedź do około 6,1 min. Przy dłuższym wejściu oba warianty z CPU wymagały więcej czasu.

Ten model mieścił się na badanej karcie bez takiego podziału. Dlatego przy szybkim, interaktywnym użyciu wyniki przemawiają tutaj za pozostawieniem go na GPU. Pomoc CPU i RAM daje realną oszczędność VRAM, ale na tym serwerze ma duży koszt czasowy. Warto rozważać ją wtedy, gdy ograniczona pamięć jest ważniejszą przeszkodą niż oczekiwanie na zadanie w kolejce — po sprawdzeniu, czy zmierzone czasy odpowiadają potrzebom aplikacji.

Co warto odczytać z tego porównania?

Najpierw spójrz na czas całej odpowiedzi dla krótszego wejścia. To proste porównanie kosztu oczekiwania przy tej samej liczbie tokenów odpowiedzi. Następnie sprawdź dłuższe wejście: model ma do przetworzenia więcej materiału, więc rezultat może zmienić się nawet przy tej samej długości odpowiedzi.

Dopiero obok czasu postaw oszczędność VRAM. Zwolnienie miejsca może być przydatne, jeżeli wybrany model inaczej nie mieści się na karcie. Nie należy jednak zakładać, że uzyskana przestrzeń automatycznie pozwoli uruchomić dodatkową usługę. Taki układ dzieliłby GPU, CPU i RAM między aplikacje, czego ten test nie obejmuje.

Równie ważny jest RAM procesu. W tabeli to PSS: pamięć przypisana programowi z modelem, ze wspólnymi obszarami podzielonymi proporcjonalnie między programy. Pokazuje część kosztu ponoszonego przez serwer, ale nie całe zapotrzebowanie systemu. Program może potrzebować więcej miejsca podczas ładowania niż podczas odpowiedzi. Samo dodanie wartości z dwóch kolumn nie daje więc minimalnej wymaganej konfiguracji.

Dlaczego więcej RAM nie daje prostej prognozy szybkości?

Pojemność pamięci mówi, ile danych można przechować. Szybkość działania zależy również od procesora, przepustowości pamięci i podziału obliczeń. Większy zapas RAM może ułatwić uruchomienie modelu, ale nie pozwala wyliczyć krótszego czasu odpowiedzi bez pomiaru.

To podobna różnica jak między miejscem na dokumenty a tempem ich opracowania: dodatkowe miejsce pomaga pomieścić pracę, lecz nie wykonuje jej samo. Przy modelu korzystającym z CPU znaczenie ma cały zestaw. Dlatego nie przenosimy zmierzonych czasów na inny procesor lub układ pamięci wyłącznie na podstawie liczby gigabajtów.

Rozmowa na żywo czy zadania w kolejce?

Pracownik korzystający z asystenta czeka po każdym pytaniu. W takim zastosowaniu warto zacząć od modelu mieszczącego się na GPU i zmierzyć jego odpowiedzi na własnych przykładach. Potem sprawdzić, czy większy lub inaczej rozmieszczony model daje korzyść, która uzasadnia dodatkowe oczekiwanie.

Inaczej wygląda zadanie dodane do kolejki, po którego wynik wraca się później. Podział GPU i RAM jest wtedy wariantem do rozważenia, jeśli priorytetem jest dostęp do konkretnego modelu. Przykładem może być nocne przygotowanie roboczych zestawień dokumentów do późniejszej kontroli. To propozycja zastosowania, nie wykonany tutaj test poprawności takiej analizy.

Osobny artykuł o modelu 235B pokazuje, jak badamy znacznie większą konfigurację korzystającą z obu rodzajów pamięci. Nie jest ona czwartym wariantem tego porównania: zmienia się model i jego budowa.

Jak wybrać ustawienie do własnego projektu?

Przygotuj krótkie pytanie, typowy dokument i najdłuższy tekst, który rzeczywiście planujesz wysyłać. Ustal również dopuszczalny czas odpowiedzi. Dzięki temu można porównać nie tylko uruchomienie programu, ale wykonanie potrzebnej pracy.

Jeśli model nie mieści się na karcie, dostępne drogi to podział z CPU/RAM, oszczędniejszy format wag albo inny model. Zmiana formatu lub modelu wymaga ponownej oceny odpowiedzi. Sama liczba tokenów na sekundę nie powie, która opcja najlepiej rozwiązuje zadanie.

Warto szukać konfiguracji dającej wystarczająco dobrą odpowiedź w potrzebnym czasie, a nie samego najniższego zużycia VRAM. Zobacz pozostałe modele, sprawdź serwer lub opisz swój model i akceptowalne oczekiwanie. Nazwy wyjaśnia słownik AI i GPU.