Jaka karta GPU do inferencji LLM? (używane akceleratory pod lokalne modele)

Krótka odpowiedź, zanim rozwinę temat: jeśli stawiasz pierwszy raz lokalny model językowy i nie wiesz od czego zacząć, w 8 na 10 przypadków wygrywa Tesla P40 z 24 GB VRAM — nie dlatego, że jest najszybsza, tylko dlatego, że ma najwięcej pamięci za rozsądne pieniądze. Reszta tego tekstu to wyjaśnienie, dlaczego VRAM jest tu ważniejszy niż surowa moc obliczeniowa, i kiedy warto odejść od tego domyślnego wyboru.

Dlaczego przy inferencji liczy się VRAM, a nie TFLOP-y

Kiedy zaczynałem bawić się lokalnymi modelami, intuicyjnie szukałem karty z jak najwyższą mocą obliczeniową — w końcu to "AI". Szybko się przekonałem, że to błędne myślenie, przynajmniej przy inferencji (samym odpytywaniu gotowego modelu, bez treningu).

Model językowy musi trzymać w pamięci karty swoje wagi — i to one, nie liczba rdzeni CUDA, decydują, czy w ogóle uda się go uruchomić. Jeśli model nie mieści się w VRAM, koniec zabawy: albo błąd out of memory, albo część warstw ląduje na CPU i wydajność siada drastycznie. Dlatego pierwsze pytanie, jakie sobie zadaję patrząc na kartę, to nie "ile ma rdzeni Tensor", tylko "ile mam gigabajtów do dyspozycji".

Tu z pomocą przychodzi kwantyzacja — okrojenie precyzji wag z natywnych FP16/BF16 do INT8 albo nawet INT4. Brzmi jak strata jakości i owszem, jakaś strata jest, ale w praktyce (przy formatach typu GGUF, o których niżej) różnica bywa trudna do wyłapania, a zysk na VRAM jest ogromny — model 4-bitowy zajmuje z grubsza jedną czwartą miejsca względem wersji FP16. Dzięki temu 24 GB pamięci potrafi pomieścić modele, które "na papierze" wymagałyby dużo więcej.

Orientacyjny dobór VRAM do wielkości modelu

Kilka liczb orientacyjnych, które sam trzymam w pamięci przy planowaniu:

• 8 GB — modele rzędu 7B w kwantyzacji, bez zapasu na dłuższy kontekst.
• 16 GB — 13B komfortowo, z miejscem na kontekst i ewentualny drugi mały model obok.
• 24 GB — 13B z zapasem, a modele 34B "na styk", zależnie od kwantyzacji.
• 2×24 GB (razem 48 GB) — realny próg wejścia do 70B, czyli już poważnych modeli klasy Llama 2/3 70B w rozsądnej kwantyzacji (Q4 to zwykle ok. 40–48 GB). Pojedyncze 32 GB wystarczy tylko przy mocnej kwantyzacji i/lub offloadzie części warstw na CPU.

To wartości orientacyjne, nie sztywne reguły — dokładne zużycie zależy od architektury modelu, długości kontekstu i formatu kwantyzacji, ale jako punkt startowy sprawdzają się nieźle.

Które używki NVIDII mają sens do inferencji

W homelabie i w ofertach z drugiej ręki najczęściej trafiają się karty z rodziny Tesla/data center: P4, P40, P100, V100 i nowsza A2. Każda to inna architektura i inny kompromis. To nie jest zamknięta lista — to po prostu modele, które najczęściej mamy od ręki; inny akcelerator sprowadzamy na zamówienie i wyceniamy indywidualnie na zapytanie.

Pascal: P4, P40, P100 — starsza, ale wciąż użyteczna generacja

Cała trójka to architektura Pascal (compute capability 6.x). Tu jest pułapka, na którą sam się kiedyś nabrałem: P40 i P4 mają okrojone natywne wsparcie FP16 — wolniejsze niż liczenie na FP32, co dla treningu byłoby problemem, ale dla inferencji w kwantyzacji INT8/INT4 nie ma większego znaczenia, bo i tak nie liczymy w FP16. Inaczej sprawa wygląda z P100 — ta ma pełne FP16 i mocne FP64, więc jest ciekawsza, jeśli komuś zależy też na obliczeniach naukowych, nie tylko na LLM-ach.

P40 ma 24 GB GDDR5 i przepustowość ok. 346 GB/s. To domyślny wybór na start, o którym pisałem na początku — dużo VRAM, niska cena wejścia, sprawdzona pozycja w społeczności (jest sporo wątków na r/LocalLLaMA i w dokumentacji llama.cpp poświęconych właśnie tej karcie). Szczegółowo rozpisałem to podejście w osobnym tekście o Tesli P40 pod Ollamę, jeśli chcesz zobaczyć konkretne ustawienia.

P4 to zupełnie inna liga — 8 GB GDDR5, 192 GB/s, zasilanie tylko ze slotu PCIe (75 W), bez dodatkowego kabla. Sensowna, jeśli chcesz cichy, energooszczędny serwerek do naprawdę małych modeli albo jako drugą kartę do odciążenia głównej.

P100 — 16 GB HBM2, 732 GB/s, pamięciowo szybsza niż P40, choć z mniejszą pojemnością. Ma sens, gdy zależy ci na przepustowości i pełnym FP16, a 16 GB wystarczy.

Volta: V100 — kiedy warto od razu iść wyżej

V100 to inna półka — architektura Volta (CC 7.0), pierwsza generacja rdzeni Tensor, pamięć HBM2 do 900 GB/s, wersje 16 lub 32 GB. Jeśli od razu wiesz, że interesują cię większe modele (34B) albo serwowanie kilku modeli jednocześnie, warto rozważyć wariant 32 GB zamiast dokładania kolejnych mniejszych kart — pamiętaj jednak, że na pełne 70B i tak realnie potrzeba pary kart (2× 24 GB/48 GB), samo 32 GB tego nie zapewni. Co do sterowników: w CUDA 13 deprecjonowane są zarówno Pascal, jak i Volta — długą perspektywę wsparcia ma dopiero Ampere (A2).

Ampere: A2 — nowoczesność i niski pobór, ale nie do dużych modeli

A2 to Ampere (CC 8.6), z trzecią generacją rdzeni Tensor i wsparciem BF16/TF32. Ma jednak tylko 16 GB GDDR6 przy 200 GB/s i niski profil (low-profile), pobór rzędu 40–60 W. Wybrałbym ją nie do maksymalnej pojemności, tylko do zastosowań brzegowych (edge) — mały, cichy serwer, gdzie liczy się pobór prądu i rozmiar obudowy bardziej niż to, czy zmieści się 70B. Do modeli w okolicach 13B sprawdza się dobrze, a przy karcie działającej 24/7 niski pobór robi realną różnicę na rachunku za prąd.

Tabela porównawcza pod kątem inferencji

Karta	VRAM	Pasmo pamięci	Architektura	FP16 natywnie	Zasilanie	Najlepsza do
P4	8 GB GDDR5	192 GB/s	Pascal	okrojone	z slotu, 75 W	małe modele, cicho i tanio
A2	16 GB GDDR6	200 GB/s	Ampere	pełne (+BF16/TF32)	niski profil, 40–60 W	edge, niski pobór
P100	16 GB HBM2	732 GB/s	Pascal	pełne	8-pin EPS	przepustowość + FP64
P40	24 GB GDDR5	346 GB/s	Pascal	okrojone	8-pin EPS	domyślny start, duże modele w kwantyzacji
V100 32GB	32 GB HBM2	do 900 GB/s	Volta	pełne + Tensor gen1	8-pin EPS	trening/fine-tuning, 34B (70B w parze); Volta wycofywana w CUDA 13

Praktyczna uwaga o zasilaniu, którą sam musiałem sobie kiedyś przypomnieć na własnej skórze: V100, P100 i P40 mają złącze 8-pin EPS (procesorowe), nie PCIe — potrzebny jest adapter, inaczej karta się nie odpali. P4 zasila się wyłącznie ze slotu, a A2 też ma niskie wymagania. I druga rzecz: żadna z tych kart nie ma wyjścia wideo — to czyste akceleratory obliczeniowe, więc do obrazu potrzebujesz iGPU procesora albo osobnej karty graficznej.

Praktyka: llama.cpp, Ollama i kwantyzacja GGUF

Cała ta teoria o VRAM przekłada się bezpośrednio na praktykę. Standardem w społeczności lokalnych LLM-ów jest dziś format GGUF obsługiwany przez llama.cpp (i nakładki na niego, jak Ollama) — pozwala trzymać model skwantyzowany do 4 czy 8 bitów i ładować go bezpośrednio na kartę.

Kilka rzeczy, które sam sprawdziłem w praktyce:

• Kwantyzacja Q4_K_M to zwykle sensowny kompromis jakość/rozmiar — jeśli masz zapas VRAM, warto spróbować Q5 lub Q8, ale to mniej krytyczne niż sam fakt zmieszczenia się w pamięci.
• Ollama pobiera i uruchamia model w tle, ale pod spodem korzysta z tego samego mechanizmu co llama.cpp — parametr liczby warstw offloadowanych na GPU (num_gpu / --n-gpu-layers) ma realne znaczenie na starszych kartach z ograniczoną pamięcią.
• Linux to naturalne środowisko dla tych kart — sterowniki data-center i CUDA działają lepiej niż na Windows. Windows da się skonfigurować, ale jeśli masz wybór, oszczędzisz sobie nerwów na Linuksie.
• Częsty mit: do liczenia na CUDA nie potrzebujesz licencji vGPU. To ograniczenie dotyczy wirtualizacji GPU między maszynami wirtualnymi, a nie uruchamiania obliczeń na gołym metalu.
• Jeśli karta jest pasywna (bez wentylatora, jak większość Tesli), w desktopie musisz dorobić shroud i dmuchawę wymuszającą przepływ powietrza — inaczej prędzej czy później dostaniesz throttling albo karta wyłączy się z przegrzania. To warunek konieczny stabilnej pracy, nie opcjonalny dodatek.

Ile dokładnie VRAM potrzebujesz do konkretnych rozmiarów modeli (7B, 13B, 70B) rozpisałem szerzej w osobnym artykule o doborze VRAM do Llamy — tam jest więcej konkretów pod różne kwantyzacje.