RTX PRO 6000 Blackwell Max-Q: ile tokenów na sekundę?

Na naszym serwerze Qwen3-8B Q4_K_M osiągnął 202,21 tokena/s przy głębokości 2048 tokenów i 111,73 tokena/s przy 32 768 tokenach. To wyniki generowania w mikrobenchmarku llama-bench: średnie z trzech prób, po rozgrzewce, z modelem na jednej karcie RTX PRO 6000 Blackwell Max-Q. Nie są czasem odpowiedzi aplikacji ani wynikiem jakości modelu.

Najważniejszy wniosek przy wyborze serwera: sama nazwa GPU i pojedyncza liczba „tokenów/s” nie wystarczają. Trzeba podać model, kwantyzację, długość kontekstu i rodzaj pomiaru. Poniżej pokazujemy je razem z wynikami, które można pobrać i sprawdzić.

Na czym wykonaliśmy pomiar

Build silnika jest przypiętą wersją badawczą oznaczoną przez projekt jako pre-release, nie deklaracją użycia najnowszego stabilnego wydania. Rewizje, sumy plików modelu i wyniki poszczególnych prób są w JSON.

Wyniki Qwen3-8B Q4_K_M

Znak „±” oznacza odchylenie standardowe trzech prób raportowane przez narzędzie, nie przedział ufności ani gwarantowany zakres. Przy przetwarzaniu wejścia podana długość to liczba tokenów promptu. Przy generowaniu jest to już wypełniony kontekst, do którego dochodzi 256 nowych tokenów.

W serii Qwen3-8B generowanie przy głębokości 32 768 tokenów było około 45% wolniejsze niż przy 2048. Nie oznacza to, że aplikacja z długimi dokumentami będzie dokładnie o 45% wolniejsza: musi jeszcze przygotować prompt, ewentualnie wyszukać dokumenty i przesłać odpowiedź. Pokazuje natomiast, dlaczego test z bardzo krótkim wejściem nie opisuje dobrze pracy z długą historią rozmowy.

Wyniki Qwen3-32B Q4_K_M

Ukończyliśmy również wszystkie sześć przypadków dla Qwen3-32B: przetwarzanie wejścia oraz generowanie przy każdej z trzech długości kontekstu. Zachowaliśmy ten sam build llama.cpp 0.5.0-dev b11146, KV cache F16, Flash Attention i 256 generowanych tokenów. Każda wartość poniżej jest średnią z trzech mierzonych powtórzeń, a „±” ich odchyleniem standardowym raportowanym przez narzędzie.

Tabele zaokrąglamy do dwóch miejsc po przecinku; dokładniejsze średnie, odchylenia i poszczególne próby są w danych do pobrania. Użyliśmy pliku Qwen3-32B-Q4_K_M.gguf z repozytorium wydawcy w rewizji 938a7432affaec9157f883a87164e2646ae17555. Ta rewizja modelu ma licencję Apache-2.0; nie przenosimy jej automatycznie na inne modele ani składniki środowiska.

Ważna różnica: chłodzenie między przypadkami

Serię 8B wykonaliśmy bez dodatkowego oczekiwania na schłodzenie między przypadkami. W serii 32B przed każdym z sześciu osobnych przypadków czekaliśmy na odczyt GPU nie wyższy niż 40°C. Potem narzędzie wykonywało swoją rozgrzewkę i trzy mierzone powtórzenia, bez dodatkowych przerw na chłodzenie wewnątrz tego przypadku. Przerwy pomiędzy przypadkami nie wchodzą do podanej przepustowości silnika.

Są to wyniki dwóch opisanych konfiguracji, nie kontrolowane porównanie modeli w jednakowym stanie cieplnym ani pomiar samego wpływu liczby parametrów. Schłodzenie przed uruchomieniem nie oznacza równowagi termicznej pod ciągłym obciążeniem. Ta seria nie potwierdza stabilności po czterech godzinach pracy i nie ocenia jakości odpowiedzi modelu. Różnicę procedury zachowujemy także w publicznym JSON i CSV.

Próba 72B: co ukończyliśmy, a czego nie

Qwen2.5-72B-Instruct Q4_K_M ukończył przetwarzanie wejścia i generowanie przy głębokościach 2048 oraz 8192 tokenów — cztery przypadki, każdy z trzema mierzonymi powtórzeniami. Stosowaliśmy schładzanie do najwyżej 40°C przed przypadkiem. Podczas przetwarzania 32 768 tokenów zadziałał nasz próg bezpieczeństwa 85°C; generowania przy tej głębokości już nie uruchamialiśmy. Pełna macierz 72B nie została ukończona, dlatego nie dopisujemy jej do powyższych tabel i wykresu. Zakres ukończonych przypadków oraz sumę kontrolną zapisu przerwanej próby zachowujemy w JSON.

Ten model należy do innej generacji niż użyte Qwen3-8B i Qwen3-32B. Ma również odrębną licencję Qwen w przypiętej rewizji repozytorium, a nie Apache-2.0. Samo ukończenie krótkich przypadków nie potwierdza pracy ciągłej ani jakości odpowiedzi.

Dwie różne szybkości, dwa różne etapy

Przetwarzanie wejścia, czyli prefill, i generowanie kolejnych tokenów, czyli decode, to osobne pomiary. Wyniku ponad 10 tys. tokenów/s dla wejścia nie można przedstawiać jako prędkości pisania odpowiedzi. Dla Qwen3-8B w teście generowania uzyskaliśmy około 112–202 tokenów/s zależnie od głębokości kontekstu; dla Qwen3-32B było to około 44–54 tokenów/s, przy opisanej wyżej procedurze chłodzenia.

llama-bench używa syntetycznych tokenów i nie obejmuje tokenizacji ani samplingu. Metodę opisuje dokumentacja dokładnie użytej rewizji llama.cpp. Nie jest to także test poprawności odpowiedzi w języku polskim, programowania czy RAG.

Jak odtworzyć ustawienia

Poniższy przykład dla Qwen3-8B zakłada dostępny, przypięty build llama-bench oraz ten sam plik modelu. Dla głębokości 8192 uruchamialiśmy osobno przetwarzanie wejścia i generowanie:

llama-bench -m Qwen3-8B-Q4_K_M.gguf -ngl 999 -fa on -t 16 \
  -b 2048 -ub 512 -ctk f16 -ctv f16 -r 3 -o json \
  -p 8192 -n 0 -d 0

llama-bench -m Qwen3-8B-Q4_K_M.gguf -ngl 999 -fa on -t 16 \
  -b 2048 -ub 512 -ctk f16 -ctv f16 -r 3 -o json \
  -p 0 -n 256 -d 8192

Rozgrzewka narzędzia pozostawała włączona. W serii Qwen3-32B użyliśmy tych samych flag z plikiem Qwen3-32B-Q4_K_M.gguf, dodatkowo czekając na schłodzenie do maksymalnie 40°C przed każdym osobnym wywołaniem, jak opisano wyżej. Nie czyściliśmy systemowej pamięci podręcznej i nie prowadziliśmy równocześnie innych obliczeń na GPU. Oryginalne pliki wag 8B pochodzą od wydawcy Qwen3-8B GGUF; w danych obu modeli wskazujemy konkretną rewizję i SHA-256.

Co z tego wynika dla Twojego wdrożenia

Ten pomiar pomaga wstępnie oszacować wydajność obliczeń dla wskazanego modelu i kontekstu. Przed wyborem konfiguracji warto dodatkowo sprawdzić jakość modelu na własnych zadaniach, opóźnienie pierwszego tokena i obciążenie wieloma zapytaniami. Liczby z samego silnika nie wyznaczają liczby obsługiwanych pracowników ani gwarantowanego czasu odpowiedzi.

Wyników nie porównujemy z ofertą innego dostawcy bez identycznego testu. To pomiary własnego sprzętu opisane przez dostawcę usługi, nie niezależna certyfikacja. Metodyka i zasady aktualizacji wyjaśniają, jak przechowujemy wyniki oraz oddzielamy testy od specyfikacji oferty.

Sprawdź konfigurację serwera lub opisz model, długość dokumentów i oczekiwaną równoległość.