Szybka odpowiedź dla jednej osoby i duża liczba odpowiedzi obsłużonych łącznie to nie to samo. W tym teście sprawdzamy oba przypadki: jedno zapytanie oraz cztery zapytania wysłane jednocześnie. Porównujemy modele Qwen 8B, 32B i 72B na tej samej karcie GPU. Dla 32B wykonaliśmy również osobną, czterogodzinną próbę.
API jest interfejsem, przez który aplikacja wysyła pytanie i odbiera odpowiedź. Mierzymy je lokalnie na serwerze, bez opóźnienia Internetu i dodatkowej aplikacji klienta. Wszystkie bieżące wyniki należą do wspólnej metodyki CORE 1.1.
Co oznaczają liczby w tabeli?
Pierwszy czas pokazuje, kiedy program pomiarowy odebrał pierwszy wygenerowany token. Nie zawsze jest to pierwszy fragment końcowej odpowiedzi widoczny dla użytkownika. Drugi czas mówi, kiedy kończy się cała odpowiedź. Podczas rozmowy można czytać pojawiające się fragmenty, ale program oczekujący kompletu danych musi zaczekać do końca.
Badamy dwa wejścia: 2048 i 8192 tokeny, czyli fragmenty tekstu używane przez model. Każda odpowiedź ma stałą długość 256 tokenów. Dzięki temu jeden wariant nie uzyskuje lepszego czasu tylko dlatego, że napisał mniej. Jest to kontrolowany test obliczeń, nie ocena sensu wygenerowanego tekstu.
Kolumna łącznego tempa opisuje całą grupę zapytań. Nie należy jej odczytywać jako szybkości odpowiedzi każdego użytkownika. Wartości czasu są medianami: środkowymi wynikami po uporządkowaniu prób.
Jedno i cztery zapytania
Oznaczenia 8B, 32B i 72B mówią o przybliżonej liczbie miliardów parametrów modelu, nie o rozmiarze pliku. Q4_K_M oznacza oszczędniejszy sposób zapisu tych parametrów. Słownik AI i GPU wyjaśnia te pojęcia na prostych przykładach.
| Model i format | Tokeny wejścia | Równoległe zapytania | Pierwszy token, mediana | Cała odpowiedź, mediana | Łączna przepustowość, tokeny/s |
|---|---|---|---|---|---|
| Qwen3-8B Q4_K_M | 2048 | 1 | 0,2 s | 1,5 s | 171,9 |
| Qwen3-8B Q4_K_M | 8192 | 1 | 0,8 s | 2,4 s | 108,8 |
| Qwen3-8B Q4_K_M | 2048 | 4 | 0,7 s | 3,3 s | 313,0 |
| Qwen3-8B Q4_K_M | 8192 | 4 | 2,5 s | 6,5 s | 155,5 |
| Qwen3-32B Q4_K_M | 2048 | 1 | 0,8 s | 5,5 s | 46,2 |
| Qwen3-32B Q4_K_M | 8192 | 1 | 3,4 s | 8,3 s | 30,8 |
| Qwen3-32B Q4_K_M | 2048 | 4 | 2,8 s | 12,5 s | 81,8 |
| Qwen3-32B Q4_K_M | 8192 | 4 | 10,1 s | 24,5 s | 41,5 |
| Qwen2.5-72B-Instruct Q4_K_M | 2048 | 1 | 1,7 s | 11,6 s | 22,0 |
| Qwen2.5-72B-Instruct Q4_K_M | 8192 | 1 | 7,1 s | 17,5 s | 14,7 |
| Qwen2.5-72B-Instruct Q4_K_M | 2048 | 4 | 6,1 s | 26,2 s | 38,9 |
| Qwen2.5-72B-Instruct Q4_K_M | 8192 | 4 | 21,2 s | 50,9 s | 20,0 |
Każdy scenariusz obejmuje pełną rozgrzewkę przy docelowej liczbie zapytań i pięć mierzonych rund. Zarówno próba pojedyncza, jak i równoległa mają cztery zarezerwowane miejsca obsługi, czyli sloty. Zmieniamy liczbę aktywnych zapytań, zachowując przydział pamięci. Osobne testy bazowe z jednym slotem służą innemu porównaniu i nie zastępują tej kontroli.
Przykład modelu 32B z dłuższym wejściem pokazuje kompromis: przy czterech zapytaniach naraz łączne tempo wzrosło z 30,8 do 41,5 tokenów/s, czyli o 34,9%. Jednocześnie typowy czas pojedynczej odpowiedzi wydłużył się z 8,3 do 24,5 s. Serwer wykonywał więcej pracy w jednostce czasu, ale każda osoba czekała dłużej. To może odpowiadać kolejce zadań w tle; w rozmowie na żywo ważniejsze będzie akceptowalne oczekiwanie.
Co z tego wynika dla firmowego asystenta?
Cztery zapytania naraz nie oznaczają limitu czterech kont. Z aplikacji może korzystać więcej osób, ale zwykle nie wszyscy wysyłają pytanie w tej samej chwili. Do planowania potrzebna jest liczba równoczesnych zadań i ich długość, nie tylko liczba pracowników.
Praktycznym krokiem jest przygotowanie kilku typowych pytań i kilku dłuższych dokumentów, a potem sprawdzenie ich przy spodziewanym ruchu. Nasze zadania praktyczne uzupełniają pomiar szybkości o wymagany format i zgodność odpowiedzi.
Dłuższa praca modelu 32B
| Czas pomiaru | Ukończone odpowiedzi | Łączna przepustowość, tokeny/s |
|---|---|---|
| 240,3 min | 2304 | 40,9 |
W ciągu 576 rund serwer ukończył 2304 odpowiedzi. Typowa pojedyncza odpowiedź trwała 24,9 s, a dla 95% odpowiedzi czas wyniósł około 25,1 s lub mniej — ten drugi odczyt nazywamy p95. To opis rozkładu tej próby, nie gwarantowany czas dla dowolnego pytania. Łączne 40,9 tokenów/s dotyczy grupy czterech zapytań, nie każdej osoby osobno.
Serwer ukończył czterogodzinny test obsługi zapytań. Temperatura była stabilna w zmierzonej konfiguracji. Wynik dotyczy tego przebiegu, nie oznacza stałego pełnego obciążenia GPU ani niezmiennej szybkości każdej odpowiedzi.
Długa próba dotyczy jednego, wskazanego wariantu: Qwen3-32B Q4_K_M, dłuższego wejścia i czterech równoczesnych zapytań. Nie rozszerzamy jej wyniku na każdy model z tabeli. Mierzony czas zaczyna się przy pierwszym właściwym żądaniu i kończy przy ostatniej ukończonej odpowiedzi; nie doliczamy ładowania ani rozgrzewki.
To test powtarzanej obsługi zapytań, nie gwarancja nieprzerwanej pełnej zajętości karty przez każdą sekundę. Pomiar mocy i energii pokazuje również przebieg dłuższego obciążenia.
Jak wybrać konfigurację?
Zacznij od maksymalnego akceptowanego oczekiwania, długości wejścia i przewidywanej liczby jednoczesnych zapytań. Następnie sprawdź odpowiedzi modelu na własnych danych. Dopiero zestawienie tych informacji mówi, czy konfiguracja pasuje do aplikacji.
Jeżeli celem jest własny prototyp, poradnik API pokazuje bezpieczne pierwsze uruchomienie. Zobacz ofertę serwera lub opisz nam swoją aplikację.
Szczegóły techniczne
Porównywalność pomiarów
Krótka macierz CORE 1.1 obejmuje Qwen3-8B Q4_K_M, Qwen3-32B Q4_K_M i Qwen2.5-72B-Instruct Q4_K_M. Dwa wejścia × dwa poziomy równoległości × trzy modele dają 12 scenariuszy. Dla każdego wykonujemy jedną pełną rundę rozgrzewkową oraz pięć mierzonych rund; przy czterech zapytaniach każda runda zawiera cztery odpowiedzi.
C1 i C4 mają po cztery sloty o przydziale 8704, łącznie 34816 tokenów. Pozostałe ustawienia pozostają takie same: GPU dla wszystkich warstw, KV F16, Flash Attention, 16 wątków, batch 2048, ubatch 512, mmap, wyłączone lazy loading, fit, cache promptu i przesuwanie kontekstu. Środowisko to Rocky Linux 10.2, NVIDIA 595.91.07 i llama.cpp b11146.
Jak liczymy czas i przepustowość
Żądania w rundzie równoległej startują przez wspólną barierę. Potwierdzamy wspólny okres aktywności wszystkich odpowiedzi. Czas żądania kończy zdarzenie końcowe generacji, a nie dopiero zamknięcie połączenia HTTP. Syntetyczny pierwszy token nie jest tym samym co pierwszy widoczny tekst końcowej odpowiedzi modelu rozumującego.
Łączne tempo to liczba wygenerowanych tokenów podzielona przez sumę połączonych okien odpowiedzi. Nakładających się okien nie sumujemy wielokrotnie. Nie jest to średnia z przepustowości dawnych rund ani szybkość pojedynczego decode. Wewnętrzny licznik silnika dla 256 tokenów wyjścia może obejmować 255 kroków decode; dane zachowują oba znaczenia.
Pięć rund nie uzasadnia wniosków o rzadkich opóźnieniach. W długim jednorodnym scenariuszu dopuszczamy opisowe p95 dopiero od 200 odpowiedzi. To empiryczny rozkład w badanej konfiguracji, nie zobowiązanie SLA.
Długi pomiar i źródła
Przed długą kampanią przypinamy plan, wykonawcę, analizator i kryteria oceny chłodzenia. Wymagamy co najmniej czterech godzin rzeczywistego okna ukończonych odpowiedzi, z kompletnym zapisem przerw i odczytów. Wyniki liczbowe są w JSON CORE, a ocena termiczna i godziny mocy w analizie długiej próby.
Wszystkie starsze pliki pozostają w archiwum bez zmian. Dawna próba API 8B z wejściem 32 768 tokenów nie należy do nowej macierzy 2048/8192. Osobny nowy pomiar 32 768 tokenów dotyczy silnika 72B, nie tej warstwy HTTP.
Wersje modelu i programu oraz statystyki bez zaokrąglania są dostępne w załącznikach. Sposób obsługi endpointów opisuje dokumentacja przypiętej wersji llama-server.