Co oznacza niskie wykorzystanie karty graficznej podczas uruchamiania modelu LLM przy użyciu llama.cpp?

Oznacza to często, że wiele warstw pozostaje na CPU, co prowadzi do gwałtownego spadku prędkoś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 zmieścić więcej modelu na GPU.

Jak 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 bufor KV i zużycie VRAM, co może zmniejszyć liczbę tokenów na sekundę lub wymusić częściowe przeniesienie danych. Krótszy kontekst, mniejsze modele lub bardziej agresywne kwantowanie pomagają zachować wydajność na pojedynczej karcie z 16 GB pamięci.

Które kompromisy kwantyzacji są kluczowe dla dopasowania dużych modeli do 16 GB pamięci?

Niższe kwantyzacje bitowe zużywają mniej pamięci VRAM i mogą zwiększyć liczbę 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 potrzebna jest długa kontekstowa pamięć lub większe modele.

Czy modele typu mixture-of-experts mogą działać szybko na pojedynczej karcie GPU o pamięci 16 GB?

Modele MoE mogą osiągnąć wysoką przepustowość tokenów na sekundę, ponieważ w każdym kroku do przodu działa tylko część sieci, jednak nadal wymagają wystarczającej ilości pamięci VRAM dla aktywnych ekspertów, wag oraz bufora KV dla wybranego rozmiaru kontekstu.

Co można spróbować, jeśli kontekst 64K działa znacznie wolniej niż 32K na tym samym GPU?

Dostosuj liczbę warstw ładowanych na GPU przy pomocy parametru ngl, zaakceptuj krótszy kontekst, jeśli odpowiada to Twoim wymaganiom, lub przejdź na lżejszą kwantyzację, aby więcej warstw pozostało na urządzeniu i zmniejszyć obciążenie pamięci KV cache.

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

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

Page content

Porównuję tutaj prędkość działania kilku modeli LLM uruchamianych na GPU z 16 GB pamięci VRAM, wybierając najlepszy do samodzielnego hostowania.

Uruchamiałem te modele w llama.cpp z oknami kontekstu o wielkości 19K, 32K i 64K tokenów.

Stylizowana GPU z blokami VRAM i wykresami benchmarkowymi

W tym artykule dokumentuję swoje próby wyciśnięcia jak największej wydajności w sensie prędkości.

Tabela porównania prędkości LLM (tokeny na sekundę i VRAM)

Model	Rozmiar	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
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.

Powyższa wartość load to GPU Load. Jeśli zobaczysz niską liczbę w tej kolumnie, oznacza to, że model działa głównie na procesorze CPU i nie osiąga przyzwoitej prędkości na tym sprzęcie. Ten wzorzec jest zgodny z tym, co obserwują użytkownicy, gdy na GPU mieści się zbyt mała część modelu lub gdy kontekst zmusza do powrotu pracy na host.

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

Jeśli chcesz uzyskać ścieżki instalacji, przykłady llama-cli i llama-server oraz flagi mające wpływ na VRAM i tokeny na sekundę (rozmiar kontekstu, batchowanie, -ngl), zacznij od Szybki start llama.cpp z CLI i Serwerem.

Dla szerszego obrazu wydajności (przepustowość vs opóźnienie, limity VRAM, równoległe żądania i jak benchmarky łączą się przez sprzęt i środowiska uruchomieniowe), zobacz Wydajność LLM w 2026: Benchmarki, wąskie gardła i optymalizacja.

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

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

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

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

Gdy przechodzisz z 19K do 32K lub 64K tokenów, rośnie bufor KV (KV cache), a ciśnienie na VRAM wzrasta. Niektóre wiersze pokazują duży spadek tokenów na sekundę przy 64K, podczas gdy inne pozostają płaskie, co jest sygnałem, by ponownie przemyśleć kwantyzacje, limity kontekstu lub offloading warstw, zamiast zakładać, że model jest ogólnie „wolny".

Modele i kwantyzacje, które wybrałem do testów, mają za zadanie sprawdzić, czy dają dobry zysk w sensie kosztu/korzyści na tym sprzęcie, czy nie. Więc tutaj nie ma kwantyzacji q8 z kontekstem 200k :) …

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

llama.cpp podczas automatycznej konfiguracji warstw do wyładowania na GPU stara się zachować 1 GB wolnej pamięci. Ręcznie określamy ten parametr za pomocą parametru linii polecenia -ngl, ale tutaj nie wykonuję strojenia, tylko trzeba zrozumieć, że jeśli występuje znaczący spadek wydajności przy zwiększaniu okna kontekstu z 32k do 64k – możemy spróbować zwiększyć prędkość przy 64k, strojąc liczbę warstw wyładowanych.

Sprzęt testowy i konfiguracja llama.cpp

Testowałem prędkość LLM na komputerze z następującą konfiguracją:

CPU i-14700
RAM 64GB 6000Hz (2x32GB)
GPU RTX-4080
Ubuntu z sterownikami NVidia
llama.cpp/llama-cli, bez ręcznego określania warstw do wyładowania
Początkowe uż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 ciekawych modeli i kwantyzacji próbowałem znaleźć specjalne parametry linii polecenia llama-cpp, aby lepiej wykorzystać VRAM. Oto czego udało mi się osiągnąć:

Model	Kontekst	Warstwy na GPU	CPU/CPU load	Prędkość
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 faworyt Qwen3.5-27B-UD-IQ3_XXS wygląda dobrze w swoim punkcie optymalnym 50k kontekstu (osiągam ok. 36t/s)
Qwen3.5-122B-A10B-UD-IQ3_XXS wyprzedza pod względem wydajności Qwen3.5 27B w kontekstach powyżej 64K.
Mogę wymusić Qwen3.5-35B-A3B-UD-IQ3_S do obsługi kontekstu 100k tokenów i mieści się w VRAM, więc nie ma spadku wydajności.
Nie użyję gemma-4-31B na 16GB VRAM, ale gemma-4-26B może być średnio-dobrze…, trzeba przetestować.
Należy przetestować, jak dobrze działają Nemotron cascade 2 i GLM-4.7 Flash REAP 23B. Czy będą lepsze od Qwen3.5-35B q3? Mam wątpliwości, ale mimo wszystko, może przetestować, aby potwierdzić podejrzenie.