Bare-metal GPU dla firm · 96 GB VRAM · Katowice

TESTY I PORADNIKI

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

Ten sam Qwen2.5-72B na GPU oraz podzielony między GPU i CPU. Porównujemy czas odpowiedzi, szybkość i pamięć, a następnie wyjaśniamy, kiedy taki podział ma sens.

Ilustracja podziału pracy modelu między kartę GPU a procesor i pamięć RAM.
Ilustracja AI.

Jeżeli model mieści się na karcie, warto zacząć od obliczeń na GPU. W naszym porównaniu ten sam model 72B odpowiadał znacznie szybciej, gdy obliczenia modelu wykonywała karta. Pomoc procesora z RAM pozwoliła zwolnić znaczną część pamięci karty, ale odpowiedź zajmowała więcej czasu. Sprawdziliśmy obie strony tego wyboru: odzyskane miejsce i czas oczekiwania.

VRAM to pamięć karty graficznej; RAM to pamięć systemowa serwera. Podział pracy między GPU i CPU nazywamy tutaj offloadem. Może umożliwić uruchomienie większego modelu, ale nie zamienia RAM w równie szybką pamięć karty.

Co zmieniło przeniesienie części modelu do RAM?

Porównaliśmy Qwen2.5-72B-Instruct Q4_K_M na jednym serwerze. Format Q4_K_M to oszczędniejszy zapis danych modelu; we wszystkich trzech wariantach użyliśmy dokładnie tych samych plików. Najpierw obliczenia modelu wykonywała karta, następnie zwiększaliśmy udział procesora i RAM. Nie zmienialiśmy modelu, jego formatu ani sprzętu. To pozwala przyjrzeć się skutkom samego podziału pracy.

Zasady czytania wyników opisuje wspólna metodyka testów LLM. Dokładne ustawienia tej wykonanej serii znajdują się w szczegółach poniżej.

Rozmieszczenie modelu Pierwszy token — mediana Cała odpowiedź — mediana Generowanie — średnia VRAM — najwyższa próbka
Model na GPU 1,7 s 11,4 s 26,1 tokena/s 43,9 GiB
GPU + CPU: mniejsze zajęcie VRAM 12,4 s 249,6 s 1,1 tokena/s 22,5 GiB
GPU + CPU: jeszcze mniejsze zajęcie VRAM 17,6 s 365,0 s 0,7 tokena/s 12,2 GiB

Czasy dotyczą wejścia 2048 tokenów i odpowiedzi 256 tokenów, po jednym zapytaniu naraz. Token to fragment tekstu, nie zawsze całe słowo. Mediana oznacza środkowy wynik z trzech prób. Kolumna VRAM obejmuje próbki z sześciu odpowiedzi danego wariantu, łącznie dla wejść 2048 i 8192 tokenów — nie wyłącznie krótszy test.

Najłatwiej zauważyć różnicę w kolumnie całej odpowiedzi: od około jedenastu sekund do około czterech i sześciu minut. To czasy kontrolowanej próby z odpowiedzią o stałej długości, a nie obietnica czasu dowolnej rozmowy. Pokazują jednak, że oszczędność pamięci w tym ustawieniu nie była bezpłatna pod względem szybkości.

Dlaczego samo dodanie RAM nie wystarcza?

RAM zapewnia miejsce na dane, ale nie przejmuje szybkości obliczeń karty. W badanych wariantach procesor wykonywał część pracy wcześniej wykonywanej przez GPU. Model musiał czekać na wynik tej części, zanim odpowiedź mogła postępować dalej. Więcej wolnego miejsca na karcie i szybsza odpowiedź to więc dwa różne cele.

Warto też oddzielić pojemność RAM od sposobu jego pracy. Znaczenie mają procesor, szybkość pamięci i jej konfiguracja. Dokładny układ stanowiska opisujemy niżej. Samo zwiększenie liczby gigabajtów nie pozwala obliczyć, o ile skróci się odpowiedź; wymagałoby to osobnego porównania.

Dla kogo GPU, a dla kogo GPU z RAM?

Do interaktywnego czatu wybralibyśmy tutaj wariant GPU. Najkrótsze oczekiwanie i najwyższa szybkość generowania były jego wyraźną przewagą. Gdy model już mieści się na karcie, przenoszenie go do RAM wyłącznie po to, by zwolnić VRAM, ma w tej konfiguracji znaczący koszt czasowy.

Wyobraźmy sobie asystenta, któremu pracownik zadaje kolejne krótkie pytania. Oczekiwanie powtarza się przy każdej odpowiedzi, więc nawet poprawny wynik po kilku minutach może przeszkadzać w pracy. Inna sytuacja to zadanie dodane do kolejki, po którego wynik wraca się później. Tam dłuższa odpowiedź może być akceptowalna, jeżeli potrzebny model nie mieści się w całości na karcie.

Podział może być sensowny przy pracy w kolejce: na przykład nocnym przetwarzaniu dokumentów, gdy ważniejszy jest dostęp do większego modelu niż natychmiastowa odpowiedź. To przykład zastosowania do sprawdzenia, nie wykonany tutaj test jakości analizy dokumentów. Osobno pokazujemy działający model 235B z GPU i RAM.

Jak podjąć decyzję we własnym projekcie?

Najpierw sprawdź, czy wybrany model mieści się na GPU wraz z miejscem na tekst i odpowiedzi. Jeżeli tak, warto zmierzyć wariant GPU jako punkt odniesienia. Jeżeli nie, można rozważyć oszczędniejszy format modelu, inny model albo podział pracy z CPU. Każda z tych dróg odpowiada na inne potrzeby; zmiana modelu lub formatu wymaga ponownego sprawdzenia przydatności odpowiedzi.

Przy podziale GPU i RAM dobrze zacząć od kilku własnych zadań: krótkiego pytania, typowego dokumentu i najdłuższego przewidywanego wejścia. Oceń nie tylko to, czy program wystartował, ale również czy kończy zadanie w akceptowalnym czasie. Tak powstaje użyteczne kryterium wyboru: odpowiedź wystarczająco dobra i dostarczona wtedy, gdy jest potrzebna.

Ocena: RAM poszerza możliwości doboru modelu, a GPU daje szybkość. Wyniki dotyczą konkretnego procesora i układu pamięci tego stanowiska; nie są prognozą dla każdego serwera ani konfiguracji z większą ilością RAM.

Zobacz, jakie modele przetestowaliśmy, sprawdź konfigurację serwera lub opisz swój model i akceptowalny czas odpowiedzi. Pojęcia wyjaśniamy w słowniku AI i GPU.

Szczegóły techniczne

Warunki porównania

Nazwy wariantów w tabeli głównej opisują korzyść pamięciową. „Model na GPU” odpowiada wszystkim 81 warstwom na karcie; „mniejsze zajęcie VRAM” — 40 z 81, a „jeszcze mniejsze zajęcie VRAM” — 20 z 81. Warstwa jest częścią obliczeń modelu. Jej liczba nie jest procentem zajęcia pamięci. Poniższa tabela zachowuje te dokładne ustawienia dla odtworzenia pomiaru.

Źródłem modelu jest Qwen2.5-72B-Instruct-GGUF w przypiętej rewizji, format Q4_K_M, pliki wag o łącznej wielkości 41,0 GiB. Model ma odrębną Qwen License. Zmienialiśmy żądane rozmieszczenie warstw, nie model, jego format ani sprzęt. Rzeczywiste liczby warstw potwierdza zapis uruchomionego silnika.

Element Konfiguracja pomiaru
Testowana karta NVIDIA RTX PRO 6000 Blackwell Max-Q Workstation Edition, 96 GB VRAM
Procesor AMD EPYC 4565P, 16 rdzeni i 32 procesory logiczne
RAM systemowy stanowiska 96 GB
Sterownik NVIDIA 595.91.07
Silnik llama.cpp 0.5.0-dev, wydanie b11146
Wejście / odpowiedź 2048 lub 8192 tokeny / 256 tokenów
Równoległość Jedno zapytanie i jeden slot serwera
Powtórzenia Jedna osobna rozgrzewka, następnie trzy mierzone odpowiedzi dla każdego wejścia
Pula kontekstu 8704 tokeny; KV cache F16 i Flash Attention
CPU / batch / ubatch 16 wątków / 2048 / 512
Limit mocy GPU i chłodzenie 300 W; automatyczne sterowanie wentylatorami obudowy

Użyto rewizji silnika 7fe450e19305b828c199d602c23a8337aaa1f03b, ładowania mmap bez mlock; cache promptu, przesuwanie kontekstu, automatyczne dopasowanie pamięci i tryb lazy były wyłączone. To ukończona seria krótkich odpowiedzi, nie wielogodzinny test każdego wariantu. Obserwacje nie wykazały termicznego ograniczania szybkości w zapisanych próbkach; próbkowanie nie wyklucza krótszych zdarzeń między odczytami.

Wyniki obu długości wejścia

Wariant · tokeny wejścia Pierwszy token — mediana Cała odpowiedź — mediana Generowanie — średnia CPU procesu — średni udział mocy obliczeniowej serwera
GPU · 2048 1,7 s 11,4 s 26,1 tokena/s 3,1 %
GPU · 8192 7,0 s 17,2 s 25,2 tokena/s 3,1 %
GPU + RAM: 40/81 warstw na GPU · 2048 12,4 s 249,6 s 1,1 tokena/s 47,0 %
GPU + RAM: 40/81 warstw na GPU · 8192 50,9 s 300,8 s 1,0 tokena/s 41,5 %
GPU + RAM: 20/81 warstw na GPU · 2048 17,6 s 365,0 s 0,7 tokena/s 47,5 %
GPU + RAM: 20/81 warstw na GPU · 8192 72,2 s 439,5 s 0,7 tokena/s 42,1 %

CPU pokazuje średni udział procesu w całkowitej pojemności 32 procesorów logicznych, z liczników obejmujących każdą odpowiedź. Nie jest procentem zajęcia jednego rdzenia. Generowanie to średnia szybkość etapu decode raportowana przez silnik, a nie 256 tokenów podzielone przez całkowity czas oczekiwania. W tej wersji llama.cpp obejmuje 255 kroków decode: pierwszy token powstaje podczas przetwarzania wejścia. CSV oddzielnie zawiera szybkość całej odpowiedzi.

Pamięć i znaczenie konfiguracji RAM

Nazwa GPU nie oznacza zerowego wykorzystania RAM: system, aplikacja i część danych nadal go potrzebują. Odczyty VRAM w tabeli są globalnymi próbkami zajęcia karty w połączonych oknach sześciu mierzonych odpowiedzi. Nie są wielkością samych wag, wymaganą rezerwacją ani odczytem wyłącznie dla jednego wejścia. GiB oznacza jednostkę po 2³⁰ bajtów.

Zapis firmware SMBIOS raportuje dwa moduły po 48 GiB w pozycjach A0 i A1 kanału A, puste B0 i B1 oraz skonfigurowaną szybkość 3600 MT/s. To osobna obserwacja konfiguracji pamięci, nie fizyczna kontrola obsadzenia, pomiar przepustowości ani dowód przyczyny różnicy wydajności. Szybkość pracy na CPU zależy także od topologii i przepustowości RAM. Nie przenosimy tych czasów na oferowaną konfigurację 192 GB lub inne serwery.

Ładowanie, rozgrzewka i odpowiedzi mają różne zakresy pamięci i odczytów dyskowych. CSV rozdziela cały przebieg wariantu od połączonych okien ukończonych odpowiedzi; wartości pamięci i I/O powtarzane w wierszach obu wejść nie są osobnymi pomiarami dla tych wejść. Liczniki dyskowe obejmują zaobserwowane przedziały, a nie każdą operację na pamięci. Niezerowy odczyt pliku nie dowodzi korzystania ze swapu; mapowanie pliku nie dowodzi przechowywania całego modelu w RAM.

Pełne wyniki, wersje, hashe wag i zakresy znajdują się w przejrzanym JSON kampanii. Podane czasy i szybkości nie są testem jakości odpowiedzi ani porównaniem różnych modeli.

Ten sam model 72B · szybkość generowania
  1. Model na GPU26,126,1 tokens/s
  2. GPU + CPU: mniejsze zajęcie VRAM1,11,1 tokens/s
  3. GPU + CPU: jeszcze mniejsze zajęcie VRAM0,70,7 tokens/s

Qwen2.5-72B Q4_K_M · wejście 2048 tokenów. Średnia szybkość generowania silnika z 3 rund, nie czas całej odpowiedzi.

Dane do pobrania

Publiczne zestawienie wyników i ustawień testu, bez danych dostępowych i identyfikatorów administracyjnych.