Czy duży model językowy może pracować na jednej karcie GPU? Sprawdzamy Qwen2.5-72B w formacie Q4_K_M na NVIDIA RTX PRO 6000 Blackwell Max-Q. Ten artykuł pokazuje szybkość samego silnika obliczeń. Czas oczekiwania użytkownika i pracę kilku osób naraz mierzymy oddzielnie w teście API.
„72B” oznacza około 72 miliardów parametrów modelu, nie jego rozmiar w gigabajtach. Q4_K_M to oszczędniejszy sposób zapisu tych parametrów. Wybrany model i format pozostają takie same we wszystkich poniższych scenariuszach. Zmieniamy długość tekstu, z którym silnik ma pracować, zgodnie ze wspólną metodyką CORE 1.1.
Dwa etapy, które warto odróżnić
Zanim model zacznie odpowiadać, musi przetworzyć wejście: instrukcję, pytanie i dołączone materiały. Ten etap nazywa się prefill. Potem tworzy kolejne fragmenty odpowiedzi — decode. Użytkownik widzi jeden przepływ, ale oba etapy mają inne tempo.
Token jest fragmentem tekstu: słowem, częścią słowa albo znakiem. Tokenów na sekundę nie należy więc odczytywać jako słów na sekundę. Nie przeliczamy też każdej badanej długości na stałą liczbę stron — wynik zależałby od języka i zawartości dokumentu.
Wyniki dla trzech długości wejścia
| Tokeny wejścia / kontekstu | Prefill, średnia tokenów/s | Decode, średnia tokenów/s |
|---|---|---|
| 2048 | 1236,6 | 25,9 |
| 8192 | 1173,0 | 25,6 |
| 32768 | 964,0 | 22,5 |
W tabeli podajemy średnią szybkość z pięciu powtórzeń po rozgrzewce. To syntetyczny pomiar obliczeń, nie test rozumienia dokumentów. Przetwarzanie wejścia i generowanie są osobnymi próbami programu pomiarowego, a nie dwoma stoperami uruchomionymi podczas tej samej rozmowy. Pełne wartości, minimum, maksimum i medianę można sprawdzić w danych do pobrania.
Przy zwiększeniu wejścia z 2048 do 8192 tokenów tempo generowania zmieniło się nieznacznie: z 25,9 do 25,6 tokenów/s. Przy 32 768 tokenach wyniosło 22,5 tokenów/s, a przetwarzanie wejścia zwolniło do 964,0 tokenów/s. Ta konfiguracja obsłużyła więc również najdłuższy badany kontekst na jednej karcie, choć z niższą szybkością obliczeń.
Co to oznacza przy pracy z dokumentami?
Przy krótkim pytaniu samo wejście może stanowić niewielką część zadania. Przy obszernym materiale przygotowanie odpowiedzi zaczyna się od większej ilości obliczeń. Nawet jeśli model ma udzielić tylko kilku zdań odpowiedzi, musi najpierw obsłużyć przekazany mu tekst.
Praktycznym zastosowaniem jest asystent pracujący z dokumentacją: aplikacja wybiera istotne fragmenty i przekazuje je modelowi wraz z pytaniem. Innym przykładem są robocze podsumowania materiałów. Są to propozycje zastosowania do sprawdzenia na własnych dokumentach, nie zadania ocenione w tym teście silnika.
Nie zawsze warto przekazywać modelowi wszystko naraz. Dobrze dobrany fragment może ograniczyć czas i zajęcie pamięci, ale nie powinien usuwać informacji potrzebnych do odpowiedzi. Wielkość dostępnego kontekstu jest możliwością, nie obowiązkiem wykorzystania całej puli przy każdym pytaniu.
Dlaczego sama szybkość nie wybiera najlepszego modelu?
Odpowiedzi oceniamy w zadaniach praktycznych, opisanych wraz z pomiarami pojemności. Tam rozdzielamy wymagany format wyniku i zgodność jego wartości z przygotowanym wzorcem.
Równie ważny jest sposób korzystania z aplikacji. Jedna osoba oczekuje krótkiego czasu odpowiedzi, a system przetwarzający kolejkę dokumentów może bardziej skorzystać z większej liczby ukończonych zadań. Mikrobenchmark nie uwzględnia kolejki, uwierzytelniania, wyszukiwania dokumentów ani połączenia przez Internet.
Przed wdrożeniem zestaw szybkość z jakością odpowiedzi, pomiarami API i potrzebną pamięcią. Zobacz ofertę serwera lub opisz model i zadanie, które chcesz uruchomić.
Szczegóły techniczne
Co dokładnie porównujemy
Seria CORE 1.1 używa Qwen2.5-72B-Instruct Q4_K_M, llama.cpp b11146 z commitu 7fe450e19305b828c199d602c23a8337aaa1f03b, sterownika NVIDIA 595.91.07 i Rocky Linux 10.2. Pliki modelu i programu mają przypięte sumy SHA-256. Jest to konkretne sprawdzone wydanie programu, nie deklaracja użycia najnowszego stabilnego wydania.
Każda długość 2048, 8192 i 32 768 tokenów ma osobny pomiar prefill oraz generowania 256 tokenów przy zadanej głębokości. Każdy proces llama-bench wykonuje własną rozgrzewkę i pięć próbek. Używamy GPU dla wszystkich warstw, Flash Attention, KV F16, 16 wątków, batch 2048, ubatch 512 oraz jawnych mmap i lazy-mode off. Między procesami stosujemy kontrolowane schłodzenie; nie doliczamy go do wewnętrznych czasów silnika.
Pomiary silnika nie korzystają z serwera HTTP ani slotów API. Nie przypisujemy im czasu do pierwszego widocznego tekstu. Odczyty zasobów obejmują cały proces z ładowaniem i rozgrzewką, ponieważ narzędzie nie udostępnia bezwzględnych znaczników początku i końca każdej wewnętrznej próbki. Nie przedstawiamy ich jako dokładnego zużycia zasobów podczas samego decode.
Odtworzenie i granice wyniku
Aktualne dane są w JSON CORE i CSV poniżej. Zawierają wersje, parametry, liczbę prób i statystyki bez zaokrąglania. Dokumentacja przypiętego llama-bench opisuje zakres pomiaru narzędzia; repozytorium modelu określa jego pochodzenie i licencję.
Wcześniejsze zestawienia pozostają w archiwum danych z własną metodyką i liczbą powtórzeń. Nie łączymy ich z nowymi pięcioma próbkami. Próba 32 768 tokenów dotyczy tutaj silnika 72B, a nie nowego testu API 8B. Wielogodzinne obciążenie w osobnym artykule dotyczy modelu 32B; nie rozszerzamy jego wyniku automatycznie na 72B.