Co oznacza niskie obciążenie GPU przy uruchamianiu LLM za pomocą llama.cpp?

Często oznacza to, że wiele warstw pozostaje na CPU, co powoduje gwałtowny spadek prędkości generowania tokenów. Możesz spróbować zwiększyć liczbę warstw przenoszonych na GPU za pomocą parametru ngl, wybrać mniejszy kwant lub skrócić kontekst, aby większa część modelu mieściła się na GPU.

W jaki sposób dłuższe okno kontekstowe wpływa na liczbę tokenów na sekundę przy 16 GB VRAM?

Dłuższy kontekst zwiększa rozmiar bufora KV i zużycie pamięci VRAM, co może obniżyć liczbę tokenów na sekundę lub wymusić częściowe odciążenie na urządzenie hosta. Krótszy kontekst, mniejsze modele lub bardziej agresywne kwantyzacje pomagają utrzymać wysoką prędkość na pojedynczej karcie z 16 GB pamięci.

Które kompromisy przy kwantyzacji mają znaczenie dla uruchomienia dużych modeli na 16 GB?

Kwantyzacja niższych bitów zużywa mniej pamięci VRAM i może zwiększyć liczbę tokenów na sekundę, ale może pogorszyć jakość. Kwantyzacje w stylu IQ3 i IQ4 są powszechnymi kompromisami dla llama.cpp na pojedynczej karcie GPU o pamięci 16 GB, gdy wymagany jest długi kontekst lub większe checkpointy.

Czy modele mixture-of-experts mogą być szybkie na jednym GPU o pamięci 16 GB?

Modele MoE mogą osiągać wysoką przepustowość tokenów na sekundę, ponieważ podczas każdego kroku forward uruchamiana jest tylko część sieci, jednak nadal wymaga się wystarczającej ilości VRAM na aktywne eksperty, wagi oraz bufor KV dla wybranej długości kontekstu.

Co można zrobić, gdy kontekst 64K jest znacznie wolniejszy niż 32K na tej samej karcie GPU?

Dostosuj liczbę warstw ładowanych na GPU za pomocą parametru ngl, zaakceptuj krótszy kontekst, jeśli odpowiada on Twoim zadaniom, lub przełącz się na lżejszą kwantyzację, aby więcej warstw pozostało na urządzeniu, a presja na bufor KV zmalała.

Testy wydajności LLM na 16 GB VRAM z llama.cpp (prędkość i kontekst)

Szybkość generowania tokenów llama.cpp na VRAM 16 GB (tabele).

Page content

Oto porównuję szybkość kilku modeli LLM działających na GPU z 16 GB pamięci VRAM i wybieram najlepszy z nich do samodzielnego hostingu.

Uruchamiałem te modele LLM w llama.cpp z oknami kontekstowymi o rozmiarze 19K, 32K i 64K tokenów.

Stylizowany GPU z blokami VRAM i wykresami w stylu testów wydajności

W tym poście zapisuję swoje próby wycisnięcia z sprzętu możliwie jak najlepszej wydajności pod względem szybkości.

Tabela porównawcza szybkości LLM (tokeny na sekundę i VRAM)

Model	Size	19K VRAM	19K GPU/CPU	19K T/s	32K VRAM	32K Load	32K T/s	64K VRAM	64K Load	64K: T/s
Qwen3.6-35B-A3B-UD-IQ3_XXS	13.2	13.8GB	96%/100%	147.5	14.0GB	96%/101%	149.1	14.7GB	96%/101%	145.8
Qwen3.6-35B-A3B-UD-IQ4_XS	17.7	14.3GB	62%/266%	95.0	14.9GB	58%/279%	92.3	14.9GB	57%/293%	86.4
Qwen3.5-35B-A3B-UD-IQ3_S	13.6	14.3GB	93%/100%	136.4	14.6GB	93%/100%	138.5	14.9GB	88%/115%	136.8
Qwen3.5-27B-IQ3_XXS-bartowsky	11.3	12.8	98/100	44.9	13.5	98/100	44.9	14.5	45/415	23.6
Qwen3.5-27B-UD-IQ3_XXS	11.5	12.9	98/100	45.3	13.7	98/100	45.1	14.7	45/410	22.7
Qwen3.5-27B-IQ4_XS.gguf	15.0	14.6	49/406	20.5	14.7	37/465	17.4	14.7	23/533	13.3
Qwen3.5-122B-A10B-UD-IQ3_XXS	44.7	14.7	30/470	22.3	14.7	30/480	21.8	14.7	28/490	21.5
Qwen3.5-122B-A10B-UD-IQ3_S	46.5	14.7	25/516	19.4	14.7	24/516	19.5	14.7	24/516	19.6
Mistral-Small-4-119B UD-IQ3_XXS	42.8	14.8	28/585	30.4	14.7	27/574	28.5	14.9	20/590	31.5
Qwen3-Coder-Next-UD-IQ4_XS	38.4	14.6	32/460	41.1	14.7	29/440	41.3	14.8	32/460	38.3
Nemotron Super 120b IQ3_XXS	56.2	15.0	26/517	17.5	14.6	26/531	17.4	14.6	26/535	17.6
gemma-4-26B-A4B-it-UD-IQ4_XS	13.4	14.7	95/100	121.7	14.9	95/115	114.9	14.9	75/190	96.1
gemma-4-31B-it-UD-IQ3_XXS	11.8	14.8	68/287	29.2	14.8	41/480	18.4	14.8	18/634	8.1
GLM-4.7-Flash-IQ4_XS	16.3	15.0	66/240	91.8	14.9	62/262	86.1	14.9	53/313	72.5
GLM-4.7-Flash-REAP-23B IQ4_XS	12.6	13.7	92/100	122.0	14.4	95/102	123.2	14.9	71/196	97.1

19K, 32K i 64K to rozmiary okna kontekstowego.

Pojęcie load powyżej oznacza wykorzystanie GPU. Jeśli widzisz niską wartość w tej kolumnie, oznacza to, że model działa głównie na procesorze CPU i nie jest w stanie osiągnąć zadowalającej prędkości na tym sprzęcie. Taki wzorzec odpowiada temu, co użytkownicy obserwują, gdy zbyt mała część modelu mieści się na GPU lub gdy kontekst powoduje przemieszczenie obliczeń na procesor hosta.

O llama.cpp, wydajności LLM, OpenCode i innych porównaniach

Jeśli chcesz poznać ścieżki instalacji, przykłady użycia llama-cli i llama-server oraz parametry wpływające na zużycie VRAM i liczbę tokenów na sekundę (rozmiar kontekstu, partycjonowanie, -ngl), zacznij od artykułu Szybki start z llama.cpp: CLI i serwer.

Aby uzyskać szerszy obraz wydajności (przepustowość względem opóźnień, limity VRAM, równoległe żądania oraz sposób łączenia wyników testów wydajnościowych na różnych sprzętach i środowiskach wykonawczych), zobacz artykuł Wydajność LLM w 2026: Testy wydajności, wąskie gardła i optymalizacja.

Jakość odpowiedzi analizowana jest w innych artykułach, na przykład:

Najlepsze LLM dla OpenCode - przetestowane lokalnie. Możesz przeczytać więcej o Opencode w artykule Szybki start z OpenCode: Instalacja, konfiguracja i użycie terminalowego agenta AI do kodowania
Porównanie jakości tłumaczenia stron Hugo - LLM na Ollama

Przeprowadziłem podobny test dla LLM na Ollama: Najlepsze LLM dla Ollama na GPU z 16GB VRAM.

Jeśli uruchamiasz Qwen 3.6 27B lub 35B przez llama.cpp i chcesz zwiększyć szybkość generowania, zobacz Qwen 3.6 MTP vs Standardowe dekodowanie na GPU 16GB — speculacyjne dekodowanie MTP zwiększa przepustowość generowania o do 67% dla gęstego modelu 27B, z tabelami pokazującymi koszt VRAM i kompromisy związane z oknem kontekstowym na każdym poziomie --spec-draft-n-max.

Dlaczego długość kontekstu zmienia liczbę tokenów na sekundę

Przechodząc od 19K do 32K lub 64K tokenów, cache KV rośnie, a presja na pamięć VRAM wzrasta. W niektórych wierszach obserwujemy duży spadek liczby tokenów na sekundę przy 64K, podczas gdy w innych pozostaje ona bez zmian. Jest to sygnał, by ponownie rozważyć kwantyzację, limity kontekstu lub offloading warstw, zamiast zakładać, że model jest ogólnie „wolny”. Aby poznać kalkulacje budżetowe stojące za tymi liczbami — dokładny wzór na bity KV na token, tabele typów cache dla 32K/64K/128K oraz sposób obliczenia własnego zapasu pamięci — zobacz Cache KV na GPU 16 GB: Jak naprawdę pomieścić długi kontekst.

Modele i kwantyzacje, które wybrałem do testów, służą do samodzielnego sprawdzenia, czy dają dobre zyski w sensie stosunku kosztów do korzyści na tym sprzęcie. Dlatego nie ma tu kwantyzacji q8 z kontekstem 200k :) …

GPU/CPU to obciążenie, mierzone za pomocą nvitop.

llama.cpp przy automatycznej konfiguracji zrzucania warstw na GPU stara się utrzymać 1 GB wolnej pamięci. Parametr ten możemy ręcznie określić za pomocą argumentu wiersza poleceń -ngl, ale nie stroję go tu szczegółowo, chcę jedynie zrozumieć, że jeśli występuje znaczący spadek wydajności przy zwiększaniu okna kontekstowego z 32k do 64k - możemy spróbować zwiększyć szybkość przy 64k poprzez dostrojenie liczby zrzucanych warstw.

Sprzęt testowy i konfiguracja llama.cpp

Testowałem szybkość LLM na komputerze PC o następującej konfiguracji:

CPU i-14700
RAM 64GB 6000Hz (2x32GB)
GPU RTX-4080
Ubuntu z sterownikami NVidia
llama.cpp/llama-cli, bez określonych warstw zrzucanych na CPU
Początkowe zużycie VRAM, przed uruchomieniem llama-cli: 300MB

Dodatkowe uruchomienia z kontekstem 128K (Qwen3.5 27B i 122B)

Model	128K Load	128K: T/s
Qwen3.5-27B-UD-IQ3_XXS	16/625	9.6
Qwen3.5-122B-A10B-UD-IQ3_XXS	27/496	19.2

Uruchomienia zoptymalizowane

Dla niektórych interesujących modeli i kwantyzacji starałem się znaleźć specjalne parametry wiersza poleceń llama.cpp, aby lepiej wykorzystywać pamięć VRAM. Oto, co mi się udało osiągnąć:

Model	Context	Layers on GPU	CPU/CPU load	Speed
Qwen3.5-27B-IQ4_XS.gguf	18k	65	98%/100%	38.0
Qwen3.5-27B-IQ4_XS.gguf	64k	53	33%/488%	15.7

Wnioski dla konfiguracji z 16 GB VRAM

Mój obecny ulubieniec Qwen3.5-27B-UD-IQ3_XXS wygląda dobrze w swoim optymalnym zakresie 50k kontekstu (osiągam ok. 36 tokenów/s).
Qwen3.5-122B-A10B-UD-IQ3_XXS wyprzedza pod względem wydajności Qwen3.5 27B przy kontekstach powyżej 64K.
Mogę skłonić Qwen3.5-35B-A3B-UD-IQ3_S do obsługi kontekstu 100k tokenów i mieści się on w pamięci VRAM, więc nie ma spadku wydajności.
Nie będę używać gemma-4-31B na 16GB VRAM, ale gemma-4-26B może być średnio-dobry…, trzeba przetestować.
Muszę przetestować, jak dobrze działają Nemotron cascade 2 i GLM-4.7 Flash REAP 23B. Czy będą lepsze niż Qwen3.5-35B q3? Podejrzewam, że nie, ale mimo wszystko warto to sprawdzić, by potwierdzić podejrzenie.
Aby dowiedzieć się, dlaczego zakres 25–34B to domyślny wybór w 2026 roku, gdy masz 24 GB, oraz dlaczego Q4 Qwen3.8-27B nie nadaje się naprawdę na tę kartę 16 GB, zobacz Sprawna granica modeli otwartych w 2026.