Sama informacja, że lokalny model generuje 20 lub 40 tokenów na sekundę, nie wystarcza do rzetelnej oceny jego wydajności. Liczy się także czas oczekiwania na pierwszy fragment odpowiedzi, szybkość przetwarzania polecenia, długość kontekstu oraz zużycie pamięci. W tym poradniku pokazujemy, jak mierzyć szybkość lokalnego modelu AI krok po kroku i porównywać konfiguracje bez wyciągania błędnych wniosków.

  • Podstawową miarą szybkości generowania jest liczba tokenów na sekundę, oznaczana jako tokens/s lub t/s.
  • Osobno należy mierzyć przetwarzanie promptu, generowanie odpowiedzi i czas do pojawienia się pierwszego tokenu.
  • Testy trzeba wykonywać na tym samym modelu, kwantyzacji, poleceniu i ustawieniach.
  • Pierwsze uruchomienie modelu należy oddzielić od kolejnych prób, ponieważ obejmuje ono czas jego wczytywania.
  • Wiarygodny wynik powinien być oparty na kilku powtórzeniach oraz uzupełniony informacją o zużyciu RAM-u, VRAM-u i temperaturach.
Jak mierzyć szybkość lokalnego modelu AI? Praktyczny poradnik krok po kroku
Źródło: Canva Pro

Jak mierzyć szybkość lokalnego modelu AI i co właściwie oznaczają wyniki?

Wydajność lokalnego modelu językowego można podzielić na kilka etapów. Każdy z nich odpowiada za inny element odczuwalnej szybkości.

Prompt processing, nazywany również prefill, oznacza przetwarzanie tekstu wejściowego. Im dłuższa historia rozmowy, dokument lub instrukcja, tym większe znaczenie ma szybkość tego etapu.

Token generation to właściwe tworzenie odpowiedzi, token po tokenie. To właśnie ten wynik najczęściej widzimy w aplikacjach jako 15, 30 lub 60 tokens/s.

TTFT, czyli Time to First Token, określa czas od wysłania polecenia do otrzymania pierwszego fragmentu odpowiedzi. Niski TTFT sprawia, że model wydaje się responsywny nawet wtedy, gdy później generuje tekst w umiarkowanym tempie.

Warto zapisywać również całkowity czas odpowiedzi oraz czas wczytywania modelu. Oficjalne API Ollama rozdziela między innymi czas ładowania, przetwarzania promptu i generowania tokenów, natomiast API LM Studio udostępnia bezpośrednio szybkość generowania oraz TTFT. 

Krok 1: Zapisz dokładną konfigurację testową

Benchmark bez informacji o konfiguracji ma ograniczoną wartość. Dwa wyniki tego samego modelu mogą znacząco się różnić przez zmianę kwantyzacji, długości kontekstu albo sposobu wykorzystania karty graficznej.

Przed rozpoczęciem testu zanotuj:

  • pełną nazwę modelu i liczbę parametrów,
  • format oraz kwantyzację, na przykład GGUF Q4_K_M,
  • wersję programu, na przykład Ollama, LM Studio lub llama.cpp,
  • używany backend, na przykład CUDA, Vulkan, Metal, ROCm albo CPU,
  • liczbę warstw przeniesionych na GPU,
  • ustawioną długość kontekstu,
  • liczbę wątków procesora,
  • model procesora i karty graficznej,
  • ilość RAM-u oraz VRAM-u,
  • system operacyjny i wersję sterownika GPU,
  • tryb zasilania komputera.

Podczas porównania zmieniaj tylko jeden parametr naraz. Jeżeli jednocześnie zmienisz model, kwantyzację, długość kontekstu i liczbę warstw GPU, nie będziesz wiedzieć, która modyfikacja odpowiada za uzyskany wynik.

Krok 2: Przygotuj stałe prompty testowe

Do każdej próby używaj dokładnie tego samego tekstu. Najlepiej przygotować co najmniej dwa scenariusze.

Pierwszy powinien zawierać krótki prompt, zbliżony do zwykłego pytania zadawanego podczas rozmowy. Może mieć około 100–300 tokenów.

Drugi powinien być znacznie dłuższy. Możesz wkleić fragment dokumentu, instrukcji albo historii rozmowy zawierający od około 1000 do kilku tysięcy tokenów. Dzięki temu sprawdzisz, jak komputer radzi sobie z przetwarzaniem większego kontekstu.

Dobrze skonstruowane polecenie testowe powinno wymuszać stosunkowo długą odpowiedź. Przykład:

Wyjaśnij, jak działa lokalny model językowy. Przygotuj odpowiedź składającą się z kilku logicznych sekcji i nie kończ jej przed omówieniem najważniejszych etapów przetwarzania danych.

Nie oceniaj szybkości na podstawie odpowiedzi, która raz ma 30, a innym razem 300 tokenów. Ustaw stały limit generowania, na przykład 128 lub 256 tokenów. W aplikacjach obsługujących takie parametry ustaw również stałe ziarno losowości oraz temperaturę równą 0 lub zbliżoną do 0. Ollama udostępnia między innymi parametry seed, temperature i num_predict, które pomagają zachować podobne warunki kolejnych prób. 

Krok 3: Oddziel pierwsze uruchomienie od rozgrzanego modelu

Pierwsze zapytanie po uruchomieniu programu może obejmować:

  • odczyt pliku modelu z dysku,
  • alokację pamięci RAM i VRAM,
  • inicjalizację backendu obliczeniowego,
  • przeniesienie warstw na kartę graficzną,
  • przygotowanie pamięci podręcznej.

Jest to tak zwany cold start, czyli uruchomienie modelu od zera. Kolejne zapytania wykonywane przy modelu pozostającym w pamięci są testami typu warm start.

Oba wyniki są przydatne, ale odpowiadają na inne pytania. Cold start pokazuje, ile użytkownik poczeka po pierwszym uruchomieniu aplikacji. Warm start lepiej odzwierciedla szybkość zwykłej rozmowy.

Wykonaj więc:

  1. jedno zapytanie po całkowitym wyładowaniu modelu z pamięci,
  2. jedno zapytanie rozgrzewające, którego wyniku nie zapisujesz,
  3. przynajmniej pięć właściwych powtórzeń przy modelu pozostającym w pamięci.

Nie mieszaj wyników cold start i warm start w jedną średnią.

Krok 4: Uruchom benchmark za pomocą llama-bench

Użytkownicy modeli GGUF mogą skorzystać z narzędzia llama-bench, dostarczanego wraz z llama.cpp. Pozwala ono niezależnie przetestować szybkość przetwarzania promptu i generowania tekstu.

Przykładowe polecenie:

./llama-bench -m ./model.gguf -p 512 -n 128 -r 5

W systemie Windows nazwa pliku wykonywalnego może mieć postać:

.\llama-bench.exe -m .\model.gguf -p 512 -n 128 -r 5

Najważniejsze parametry oznaczają:

  • -m – ścieżkę do modelu,
  • -p 512 – test przetwarzania promptu o długości 512 tokenów,
  • -n 128 – test generowania 128 tokenów,
  • -r 5 – pięć powtórzeń każdego testu.

W wynikach pojawią się dwa podstawowe oznaczenia:

  • pp – prompt processing, czyli przetwarzanie wejścia,
  • tg – token generation, czyli tworzenie odpowiedzi.

llama-bench podaje średnią liczbę tokenów na sekundę oraz odchylenie wyników. Może także zapisywać dane w formatach CSV, JSON i JSONL. Trzeba jednak pamiętać, że pomiary tego narzędzia nie uwzględniają czasu tokenizacji ani samplingu, dlatego nie są dokładnym odpowiednikiem opóźnienia odczuwanego w gotowej aplikacji. 

Aby zapisać wynik do pliku JSON, możesz użyć:

./llama-bench -m ./model.gguf -p 512 -n 128 -r 5 -o json > wynik.json

Jak sprawdzić wpływ długiego kontekstu?

Model może działać bardzo szybko podczas krótkiej rozmowy, ale zwolnić po wczytaniu długiego dokumentu. W llama-bench parametr -d pozwala wykonać test przy określonej głębokości kontekstu.

Przykład:

./llama-bench -m ./model.gguf -p 512 -n 128 -d 0,2048,8192 -r 5

Porównanie wyników dla pustego, dwutysięcznego i ośmiotysięcznego kontekstu pokaże, jak szybkość zmienia się wraz z rozmiarem pamięci podręcznej KV. Oficjalna dokumentacja narzędzia przewiduje wykonywanie testów przy różnych głębokościach kontekstu właśnie za pomocą parametru -d. 

Krok 5: Zmierz szybkość modelu uruchomionego w Ollama

Ollama zwraca szczegółowe statystyki w odpowiedzi API. Najłatwiej odczytać je po wyłączeniu strumieniowania.

Przykładowe zapytanie:

curl http://localhost:11434/api/generate -d '{

  „model”: „qwen3:8b”,

  „prompt”: „Wyjaśnij krok po kroku, jak działa lokalny model językowy.”,

  „stream”: false,

  „options”: {

    „temperature”: 0,

    „seed”: 42,

    „num_predict”: 128

  }

}’

Na Windowsie polecenie można uruchomić w terminalu obsługującym curl. Nazwę qwen3:8b należy zastąpić modelem zainstalowanym na komputerze.

W odpowiedzi znajdziesz między innymi:

  • total_duration – całkowity czas odpowiedzi,
  • load_duration – czas ładowania modelu,
  • prompt_eval_count – liczbę tokenów wejściowych,
  • prompt_eval_duration – czas przetwarzania promptu,
  • eval_count – liczbę wygenerowanych tokenów,
  • eval_duration – czas generowania.

Wszystkie czasy podawane przez API Ollama są wyrażone w nanosekundach.

Jak obliczyć tokens/s w Ollama?

Szybkość generowania obliczysz według wzoru:

eval_count / (eval_duration / 1 000 000 000)

Przykład:

128 tokenów / 4 sekundy = 32 tokens/s

Szybkość przetwarzania promptu oblicza się analogicznie:

prompt_eval_count / (prompt_eval_duration / 1 000 000 000)

Nie dziel liczby tokenów przez total_duration, jeżeli chcesz poznać czystą szybkość generowania. Całkowity czas może obejmować również ładowanie modelu i przetwarzanie wejścia.

Jak zmierzyć TTFT w Ollama?

Końcowa odpowiedź API zawiera szczegółowe czasy całego zapytania, ale do pomiaru TTFT najlepiej użyć odpowiedzi strumieniowej. Uruchom stoper w momencie wysłania żądania i zatrzymaj go po otrzymaniu pierwszego fragmentu odpowiedzi.

Ten pomiar obejmuje nie tylko obliczenia modelu, lecz także narzut serwera i klienta. Dzięki temu dobrze odzwierciedla to, co rzeczywiście odczuwa użytkownik.

Krok 6: Odczytaj wyniki w LM Studio

LM Studio może udostępniać statystyki bezpośrednio przez lokalne API. Wśród zwracanych parametrów znajdują się:

  • tokens_per_second,
  • time_to_first_token_seconds,
  • model_load_time_seconds,
  • liczba tokenów wejściowych i wyjściowych.

Dzięki temu nie trzeba samodzielnie przeliczać nanosekund. Należy jednak sprawdzić, czy model był już załadowany. Parametr czasu ładowania może pojawić się tylko wtedy, gdy aplikacja musiała wczytać model dla danego zapytania. 

LM Studio rozdziela szybkość generowania od czasu do pierwszego tokenu. To ważne, ponieważ dwa modele mogą osiągać podobne tokens/s, ale jeden z nich zacznie odpowiadać po pół sekundy, a drugi dopiero po kilku sekundach.

Krok 7: Kontroluj zużycie RAM-u, VRAM-u i temperatury

Najszybsza konfiguracja nie zawsze jest najlepsza. Model może osiągać wysoki wynik przez kilkanaście sekund, a następnie zwalniać z powodu limitu temperatury, przepełnienia pamięci albo przenoszenia części obliczeń między GPU i CPU.

Podczas testu obserwuj:

  • maksymalne zużycie pamięci RAM,
  • zajętość VRAM-u,
  • obciążenie GPU i CPU,
  • temperaturę procesora oraz karty graficznej,
  • pobór mocy,
  • częstotliwości taktowania,
  • ewentualne wykorzystanie pliku wymiany.

Na komputerach z kartami NVIDIA podstawowy podgląd zapewnia:

nvidia-smi -l 1

Polecenie odświeża informacje co sekundę. Narzędzie NVIDIA może raportować między innymi wykorzystanie pamięci, temperaturę i pobór mocy, choć zakres dostępnych parametrów zależy od modelu GPU oraz sterownika. 

W systemie Windows można dodatkowo otworzyć Menedżer zadań i obserwować zakładki CPU, Pamięć i GPU. W przypadku zintegrowanych układów graficznych część pamięci jest współdzielona z systemowym RAM-em, dlatego interpretacja wyniku może różnić się od pomiaru na karcie z własnym VRAM-em.

Krok 8: Powtórz test i policz medianę

Jedna próba nie jest wiarygodnym benchmarkiem. Na wynik mogą wpłynąć procesy działające w tle, chwilowa aktualizacja systemu, skanowanie antywirusowe, temperatura albo zmiana taktowania.

Wykonaj przynajmniej pięć właściwych prób. Następnie zapisz:

  • każdy pojedynczy wynik,
  • medianę,
  • średnią,
  • najniższy i najwyższy rezultat,
  • temperaturę oraz zużycie pamięci.

Mediana jest zwykle bardziej odporna na pojedynczy nietypowy pomiar niż zwykła średnia. Jeżeli wyniki różnią się od siebie o kilkanaście procent, sprawdź temperatury, procesy w tle i tryb zasilania, zanim uznasz pomiar za zakończony.

llama-bench domyślnie wykonuje pięć powtórzeń i raportuje średnią wraz z odchyleniem. Przy ręcznych testach Ollama lub LM Studio trzeba samodzielnie przeprowadzić kolejne zapytania. 

Krok 9: Porównuj konfiguracje po jednej zmianie

Po wykonaniu testu bazowego możesz sprawdzić, czy ustawienia programu da się zoptymalizować.

Zmieniając tylko jeden parametr, przetestuj kolejno:

  • liczbę wątków procesora,
  • liczbę warstw przeniesionych na GPU,
  • rozmiar partii przetwarzania,
  • długość kontekstu,
  • typ kwantyzacji modelu,
  • ustawienia pamięci podręcznej KV,
  • Flash Attention, jeżeli jest obsługiwane,
  • tryb zasilania komputera.

Nie zakładaj, że większa liczba wątków zawsze oznacza lepszy wynik. W oficjalnych przykładach llama-bench szybkość generowania nie rośnie liniowo wraz z dokładaniem kolejnych wątków, dlatego optymalną wartość należy znaleźć eksperymentalnie dla konkretnego procesora i modelu. 

Jak prawidłowo odczytać wynik benchmarku?

Załóżmy, że test przyniósł następujące rezultaty:

  • prompt: 512 tokenów,
  • odpowiedź: 128 tokenów,
  • prompt processing: 850 tokens/s,
  • generowanie: 28 tokens/s,
  • TTFT: 0,8 sekundy,
  • czas ładowania: 2,1 sekundy,
  • maksymalne wykorzystanie VRAM-u: 6,2 GB.

Przetworzenie promptu trwa w przybliżeniu 0,6 sekundy. Wygenerowanie 128 tokenów zajmuje około 4,6 sekundy. Przy rozgrzanym modelu cała operacja powinna więc trwać nieco ponad 5 sekund, zależnie od narzutu aplikacji, tokenizacji i samplingu.

Dla interaktywnego czatu ważny będzie przede wszystkim TTFT i szybkość generowania. Do analizy długich dokumentów większe znaczenie może mieć prompt processing. Jeżeli model jest uruchamiany sporadycznie, istotny staje się również czas ładowania.

Nie istnieje jeden wynik, który opisuje wszystkie scenariusze użytkowania.

Najczęstsze błędy podczas mierzenia szybkości modelu AI

Poniżej prezentujemy najczęstsze błędy.

Porównywanie różnych kwantyzacji bez ich oznaczenia

Model Q4 może mieć inną szybkość i zużycie pamięci niż jego wariant Q8. Wyniki należy zawsze podpisywać pełną nazwą pliku lub wariantu modelu.

Uwzględnianie tylko pierwszego uruchomienia

Pierwsze zapytanie często zawiera czas wczytywania modelu. Nie powinno być porównywane bezpośrednio z kolejnymi próbami.

Brak stałego limitu odpowiedzi

Jeżeli model raz generuje 50, a innym razem 500 tokenów, całkowity czas odpowiedzi nie nadaje się do prostego porównania.

Zmienianie kilku ustawień jednocześnie

Zmiana kwantyzacji, kontekstu i liczby warstw GPU w jednym kroku uniemożliwia wskazanie źródła poprawy lub pogorszenia wydajności.

Testowanie laptopa na baterii

Tryb oszczędzania energii może obniżać limity mocy procesora i GPU. Porównania należy wykonywać w tym samym trybie zasilania, najlepiej po podłączeniu laptopa do zasilacza.

Porównywanie tokens/s między zupełnie różnymi modelami

Token nie jest odpowiednikiem jednego słowa. Tokenizery mogą dzielić ten sam tekst na różne fragmenty, dlatego wyniki dwóch modeli korzystających z innych tokenizerów nie zawsze są bezpośrednio porównywalne. Najbardziej miarodajne jest porównywanie tej samej rodziny modelu, tego samego promptu i tej samej liczby znaków wynikowego tekstu. 

Pomijanie pogorszenia jakości odpowiedzi

Wyższe tokens/s nie oznacza automatycznie lepszego modelu. Mocniejsza kwantyzacja może zmniejszyć zapotrzebowanie na pamięć i przyspieszyć generowanie, ale równocześnie wpłynąć na jakość odpowiedzi. Wydajność należy więc oceniać razem z poprawnością wyników.

Który wynik najlepiej opisuje szybkość lokalnego AI?

W przypadku zwykłego asystenta tekstowego najważniejsze będą czas do pierwszego tokenu oraz szybkość generowania. Model powinien szybko rozpocząć odpowiedź i tworzyć tekst w tempie pozwalającym na wygodne czytanie.

Przy analizowaniu plików, długich rozmów i rozbudowanych instrukcji równie ważne jest tempo przetwarzania promptu. Model z wysokim wynikiem generowania może nadal długo „milczeć”, jeżeli wolno analizuje kilka tysięcy tokenów wejściowych.

W automatyzacji i przetwarzaniu wielu zadań należy dodatkowo mierzyć całkowitą przepustowość, liczbę ukończonych zapytań oraz opóźnienie każdego z nich. W laptopie warto natomiast zestawić wynik z temperaturą, hałasem i poborem energii.

Rzetelny benchmark nie kończy się więc na zapisaniu jednej wartości tokens/s. Najlepsza konfiguracja to taka, która zapewnia powtarzalną wydajność w rzeczywistym zastosowaniu i mieści się w dostępnej pamięci bez przegrzewania sprzętu.