Czy oznacza niskie obciążenie GPU podczas uruchamiania LLM za pomocą llama.cpp?

Często oznacza to, że wiele warstw pozostaje na CPU, co powoduje gwałtowny spadek szybkości generowania tokenów. Możesz spróbować zwiększyć liczbę warstw przenoszonych na GPU za pomocą parametru ngl, wybrać mniejszą kwantyzację lub skrócić kontekst, aby pomieścić na GPU większą część modelu.

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

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

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

Kwantyzacje o niższej liczbie bitów zużywają mniej pamięci VRAM i mogą zwiększyć przepustowość tokenów na sekundę, ale mogą pogorszyć jakość. Kwantyzacje w stylu IQ3 i IQ4 są powszechnymi kompromisami dla llama.cpp na jednej karcie GPU z 16 GB pamięci, gdy potrzebny jest długi kontekst lub większe punkty kontrolne.

Czy modele typu mixture-of-experts mogą być szybkie na jednym GPU 16 GB?

Modele MoE mogą osiągać wysoki przepustowość tokenów na sekundę, ponieważ przy każdym kroku do przodu aktywna jest tylko część sieci, ale nadal wymaga się wystarczającej ilości pamięci VRAM na aktywne eksperty, wag oraz bufor KV przy wybranej długości kontekstu.

Co można wypróbować, jeśli kontekst 64K jest znacznie wolniejszy niż 32K na tej samej karcie graficznej?

Dostosuj liczbę warstw ładowanych na GPU za pomocą parametru ngl, zaakceptuj krótszy kontekst, jeśli to odpowiada charakterowi Twojego zadania, lub przełącz się na lżejszą kwantyzację, aby więcej warstw pozostało na urządzeniu, a presja na pamięć KV cache się zmniejszyła.

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

Prędkość tokenów w llama.cpp na 16 GB VRAM (tabele).

Page content

Tutaj porównuję szybkość działania kilku LLM działających na GPU z 16 GB pamięci VRAM i wybieram najlepszy model do samodzielnego hostowania.

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

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

W tym poście dokumentuję moje próby wyciśnięcia jak największej wydajności w rozumieniu szybkości.

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

Model	Rozmiar	19K VRAM	19K GPU/CPU	19K tok/s	32K VRAM	32K Wczyt	32K tok/s	64K VRAM	64K Wczyt	64K: tok/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 kontekstu.

Kolumna load powyżej odnosi się do obciążenia GPU (GPU Load). Jeśli widzisz niską liczbę w tej kolumnie, oznacza to, że model działa głównie na procesorze CPU i nie jest w stanie osiągnąć zadowalającej szybkości na tym sprzęcie. Ten schemat odpowiada temu, co ludzie zauważają, gdy zbyt mała część modelu mieści się w pamięci GPU lub gdy kontekst zwraca obliczenia na procesor główny.

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

Jeśli chcesz poznać ścieżki instalacji, przykłady dla llama-cli i llama-server oraz parametry istotne dla pamięci VRAM i tokenów na sekundę (rozmiar kontekstu, przetwarzanie partiami, -ngl), zacznij od artykułu Szybki start z llama.cpp: CLI i Serwer.

Szerszy obraz wydajności (przepustowość w porównaniu z opóźnieniem, limity pamięci VRAM, równoległe żądania oraz to, jak testy wydajności łączą się na różnych architekturach i w różnych środowiskach wykonawczych), możesz znaleźć w artykule Wydajność LLM w 2026 roku: Testy, wąskie gardła i optymalizacja.

Jakość odpowiedzi analizuję w innych artykułach, na przykład:

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

Przeprowadziłem podobne testy dla LLM na Ollama: Najlepsze LLM dla Ollama na GPU 16GB VRAM.

Jeśli uruchamiasz Qwen 3.6 27B lub 35B przez llama.cpp i chcesz pójść dalej w zwiększaniu szybkości generowania, zobacz Qwen 3.6 MTP vs Standardowe kodowanie dekodujące na GPU 16GB — spekulatywne dekodowanie MTP zwiększa przepustowość generowania o do 67% dla gęstego modelu 27B, a tabele pokazują koszt w pamięci VRAM i kompromis dla okna kontekstu na każdym poziomie --spec-draft-n-max.

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

Gdy przechodzisz z 19K do 32K lub 64K tokenów, cache KV rośnie, a ciśnienie na pamięć VRAM wzrasta. W niektórych wierszach widać znaczący spadek liczby tokenów na sekundę przy 64K, podczas gdy inne pozostają bez zmian. Jest to sygnał, aby ponownie rozważyć kwantyzację, limity kontekstu lub offload warstw, zamiast zakładać, że model jest ogólnie „wolny”. Aby poznać kalkulacje budżetu stojące za tymi liczbami — dokładny wzór na bajty KV na token, tabele typów cache dla 32K/64K/128K oraz sposób obliczania własnego zapasu pamięci — zobacz [Cache KV na GPU 16 GB: Jak zmieścić długi kontekst](https://www.glukhov.org/pl/llm-performance/optimization/kv-cache-16gb-long-context/ “Zmieść kontekst LLM 32K do 128K w 16 GB VRAM, obliczając koszt cache KV, wybierając precyzję cache i bezpiecznie optymalizując llama.cpp, vLLM lub Ollama.”

Modele i kwantyzacje, które wybrałem do testów, służą do uruchomienia przez mnie samego, aby zobaczyć, czy dają dobre zyski w sensie koszt/korzyść na tym sprzęcie. Dlatego nie znajdziesz tu kwantyzacji q8 z kontekstem 200k :) …

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

Gdy llama.cpp automatycznie konfiguruje wyładowywanie warstw na GPU, stara się pozostawić 1 GB wolnego miejsca. Parametr ten możemy ręcznie określić za pomocą parametru wiersza polecenia -ngl, ale tutaj go nie doprecyzowuję, chcę jedynie zrozumieć, że jeśli wystąpi znaczący spadek wydajności przy zwiększaniu rozmiaru okna kontekstu z 32k do 64k - możemy spróbować zwiększyć szybkość przy 64k, doprecyzowując liczbę warstw wyładowanych na GPU.

Sprzęt testowy i konfiguracja llama.cpp

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

CPU i-14700
RAM 64GB 6000Hz (2x32GB)
GPU RTX-4080
Ubuntu z driverami NVidia
llama.cpp/llama-cli, nie określono liczy warstw wyładowanych
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 z dopracowanymi parametrami

Dla niektórych ciekawych modeli i kwantyzacji starałem się znaleźć specjalne parametry wiersza polecenia llama-cpp, aby lepiej wykorzystać pamięć VRAM. Oto, co udało mi się osiągnąć:

Model	Kontekst	Warstwy na GPU	Obciążenie CPU/GPU	Szybkość
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 16 GB VRAM

Mój obecny faworyt Qwen3.5-27B-UD-IQ3_XXS wygląda dobrze w swoim optymalnym zakresie 50k kontekstu (osiągam około 36 tok/s).
Qwen3.5-122B-A10B-UD-IQ3_XXS wyprzedza Qwen3.5 27B pod względem wydajności na kontekstach powyżej 64K.
Mogę wymusić na Qwen3.5-35B-A3B-UD-IQ3_S obsługę 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ć tak… średnio, trzeba to przetestować.
Trzeba przetestować, jak dobrze działają Nemotron cascade 2 i GLM-4.7 Flash REAP 23B. Czy będą lepsze niż Qwen3.5-35B q3? Mam wątpliwości, ale mimo to mogę przetestować, aby potwierdzić podejrzenia.