Więcej tokenów na sekundę dla całego serwera nie musi oznaczać szybszej odpowiedzi dla jednej osoby. W naszym teście Qwen3-8B przy wejściu 2048 tokenów przejście z jednego do czterech równoległych zapytań zwiększyło łączną przepustowość z 171,22 do 312,65 tokena/s. Jednocześnie mediana czasu całej odpowiedzi wzrosła z 1,49 do 3,26 s.
To praktyczne rozróżnienie przy projektowaniu wewnętrznego asystenta lub API: przepustowość opisuje ilość obsłużonej pracy, a opóźnienie — czas oczekiwania na konkretną odpowiedź. Nie można bezpośrednio zamienić jednej miary w drugą.
Wyniki Qwen3-8B przez strumieniowe API
Każde zapytanie generowało 256 tokenów. TTFT to czas od rozpoczęcia zapytania klienta do pierwszego odebranego zdarzenia z generowanym tokenem. „Cała odpowiedź” obejmuje jej dokończenie. Dla obu czasów pokazujemy medianę; przepustowość jest średnią z trzech rund.
| Tokeny wejścia na zapytanie | Równoległe zapytania | TTFT, mediana | Cała odpowiedź, mediana | Łączna przepustowość wyjścia |
|---|---|---|---|---|
| 2048 | 1 | 0,19 s | 1,49 s | 171,22 tokena/s |
| 2048 | 4 | 0,70 s | 3,26 s | 312,65 tokena/s |
| 8192 | 1 | 0,85 s | 2,37 s | 107,84 tokena/s |
| 8192 | 4 | 2,49 s | 6,56 s | 154,86 tokena/s |
Scenariusz z jednym zapytaniem ma trzy mierzone odpowiedzi, a z czterema — dwanaście. Łącznie ta seria obejmuje 30 poprawnie zakończonych odpowiedzi. Dane do pobrania zawierają również percentyl 95, ale przy tak małej próbie jest on wyłącznie opisem próbki, nie wiarygodną gwarancją p95 usługi produkcyjnej.
Jak czytać te liczby
Dla wejścia 8192 tokenów cztery równoległe zapytania dały większą łączną przepustowość niż jedno, lecz mediana pierwszego tokena wzrosła z około 0,85 do 2,49 s. Zwiększenie równoległości miało więc koszt w opóźnieniu. Osobno widać wpływ długości promptu: przy jednym zapytaniu wydłużenie wejścia z 2048 do 8192 tokenów zwiększyło TTFT z około 0,19 do 0,85 s.
Nie oznacza to, że serwer obsługuje tylko czterech użytkowników. Mierzyliśmy jednoczesne zapytania, a nie liczbę kont czy osób. Aplikacja, w której użytkownicy piszą sporadycznie, ma inny profil niż wsadowy proces utrzymujący stale cztery aktywne generowania. Nie testowaliśmy tu ruchu większego niż cztery równoległe zapytania.
Przepustowość rundy liczyliśmy jako łączną liczbę wygenerowanych tokenów podzieloną przez czas zakończenia całej rundy. Obejmuje ona przetworzenie promptu, oczekiwanie i generowanie. Dlatego nie jest to ta sama miara co samo decode w mikrobenchmarku llama-bench.
Ustawienia i granice eksperymentu
Test wykonaliśmy na jednej karcie RTX PRO 6000 Blackwell Max-Q 96 GB VRAM, z limitem 300 W, procesorem EPYC 4565P i 96 GB RAM systemowego. System: Rocky Linux 10.2; sterownik: NVIDIA 595.91.07; silnik: przypięty llama.cpp 0.5.0-dev, b11146; model: Qwen3-8B Q4_K_M.
Serwer miał cztery sloty, po 8704 tokeny kontekstu, KV cache F16 i włączone Flash Attention. Ten sam rozmiar przydziału pozostawał również przy pomiarze jednego aktywnego zapytania. Wyłączyliśmy automatyczne zmniejszanie konfiguracji i przesuwanie kontekstu.
Wejście powstawało przez tokenizację jawnego tekstu testowego, powtarzanie jego tokenów i przycięcie do dokładnie 2048 albo 8192 tokenów. Każdą grupę pomiarową poprzedzało jedno niemierzone żądanie rozgrzewkowe na slocie 0, nie runda czterech równoległych klientów. Następnie wykonywaliśmy trzy mierzone rundy danej grupy. Cache promptu był wyłączony, a liczniki odpowiedzi sprawdzane, aby ponownie użyty prompt nie udawał pełnego przetwarzania wejścia. Generowanie miało stałą długość 256 tokenów z ignorowaniem wcześniejszego EOS. To syntetyczny test infrastruktury, nie ocena sensowności odpowiedzi.
Klient i serwer komunikowały się przez localhost. Podane czasy nie obejmują połączenia klienta z Polski, Niemiec ani innego kraju, VPN, zewnętrznego proxy czy sieci publicznej. Protokół /completion opisuje dokumentacja użytej rewizji llama-server.
Czego test nie potwierdza
Zakończona seria dotyczy wejść 2048 i 8192 tokenów. Oddzielna próba rozszerzenia API do 32 768 tokenów została zatrzymana przez przyjęty limit bezpieczeństwa 85°C; nie przedstawiamy jej jako zaliczonego testu API. Krótka seria w tabeli osiągnęła maksymalny odnotowany odczyt 73°C. Nie jest to dowód wielogodzinnej stabilności ani limit temperatury określony przez producenta karty.
Osobna próba API z Qwen3-32B Q4_K_M ukończyła trzy scenariusze: 2048 tokenów przy 1 i 4 zapytaniach oraz 8192 przy 1. Podczas rozgrzewki 8192/4 skrypt zatrzymał test przy 85°C i raportowanym zapasie termicznym 7°C — bez ukończonej rozgrzewki ani mierzonej rundy tego scenariusza. Przyczyną zatrzymania był próg skryptu, nie zgłoszenie braku pamięci (OOM). W próbce przy zatrzymaniu odczyty SW/HW thermal slowdown miały stan „Not Active”, a ograniczenie mocy „Active” przy fabrycznym limicie 300 W. Nie dopisujemy tej niepełnej serii do tabeli ukończonych pomiarów API.
Próba API Qwen2.5-72B-Instruct Q4_K_M również pozostała niepełna. Scenariusz 2048 tokenów / 1 zapytanie ukończył trzy mierzone rundy, natomiast 2048 / 4 — tylko jedną rundę z czterema odpowiedziami. Scenariusze z wejściem 8192 tokenów nie zostały uruchomione. Test zatrzymał skrypt po osiągnięciu progu 85°C. Nie zaliczamy tej próby jako pełnej serii ani nie publikujemy przepustowości częściowo zakończonego scenariusza jako wyniku porównawczego.
Uruchomiliśmy też planowaną próbę czterogodzinną Qwen3-32B: 8192 tokeny wejścia, cztery równoległe zapytania i 256 tokenów wyjścia na odpowiedź. Zatrzymał ją próg skryptu 85°C. Cała kampania trwała 105,11 s, łącznie z rozgrzewką i czynnościami końcowymi — nie oznacza to 105,11 s ciągłego generowania. Ukończyły się trzy rundy, czyli 12 odpowiedzi, ale nie planowany test czterogodzinny. Nie przedstawiamy tej próby jako zaliczonego testu stabilności ani nie podajemy jej średniej przepustowości.
Nie mierzyliśmy jakości odpowiedzi, skuteczności RAG, dostępności usługi ani aplikacyjnego SLA. Weryfikacja produkcyjna wymaga własnych promptów, realistycznej częstości zapytań i dłuższego obserwowania kolejek oraz błędów.
Przed rozmową o konfiguracji określ: typowy i maksymalny prompt, długość odpowiedzi, liczbę jednoczesnych generowań oraz akceptowalny czas do pierwszego tokena. Opisz swój scenariusz lub skorzystaj z poradnika lokalnego API i tunelu SSH.