Test kart graficznych do AI: który układ najlepiej radzi sobie z modelami LLM

Jakie problemy rozwiązuje mocna karta graficzna w pracy z LLM

Praca z modelami językowymi wyłącznie na CPU

Uruchamianie modeli LLM wyłącznie na procesorze CPU działa, ale tylko do pewnego pułapu. Małe, mocno zquantyzowane modele 3B–7B jeszcze są w stanie „jakoś” funkcjonować, ale wraz ze wzrostem rozmiaru parametrycznego i długości kontekstu rośnie opóźnienie odpowiedzi i spada komfort pracy. Nawet szybki, wielordzeniowy procesor potrafi generować kilka–kilkanaście tokenów na sekundę, co przy pracy interaktywnej jest zwyczajnie męczące.

Im większy model, tym bardziej dokucza też konieczność agresywnej quantyzacji. Model 7B w INT4 daje się uruchomić na przeciętnym desktopie, jednak większe konstrukcje 13B i 34B bez GPU praktycznie nie wchodzą w grę – albo brakuje RAM-u, albo odpowiedź na pojedyncze pytanie trwa kilkadziesiąt sekund. Przy analizie długich dokumentów czy wielokrotnych wywołaniach LLM czas robi się krytyczny, a CPU po prostu nie jest w stanie zapewnić odpowiedniej przepustowości obliczeniowej.

Do tego dochodzi obciążenie całego systemu. Gdy LLM w pełni zajmuje CPU, każda inna aplikacja zaczyna działać ociężale: przeglądarka, IDE, odtwarzacz wideo. Dla osoby, która chce pracować z lokalnym asystentem w tle, jest to nie do zaakceptowania. GPU przejmuje ciężar obliczeń macierzowych, zwalniając procesor do zadań systemowych i logiki aplikacji.

Trenowanie, fine-tuning i inference – trzy różne obciążenia

W kontekście kart graficznych do AI trzeba jasno rozdzielić trzy tryby pracy z LLM: trenowanie od zera, fine-tuning (np. LoRA) oraz wnioskowanie (inference). Trenowanie pełnowymiarowego modelu językowego jest dla domowego sprzętu praktycznie niedostępne – wymaga dziesiątek lub setek kart, ogromnych zasobów danych i wyspecjalizowanej infrastruktury. W tym obszarze sens ma jedynie chmura lub dedykowane klastry GPU.

Fine-tuning i adaptacja modeli, zwłaszcza metodami typu LoRA, QLoRA czy PEFT, to zupełnie inna historia. Tutaj nawet pojedyncza karta z 12–24 GB VRAM potrafi wykonać sensowną pracę: dopasować istniejący model 7B lub 13B do specyficznej dziedziny, stylu firmy czy rodzaju dokumentów. Wydajny GPU skraca czas eksperymentów z wielu godzin do dziesiątek minut, co bezpośrednio przekłada się na możliwość iteracyjnego ulepszania modeli.

Inference, czyli samo generowanie odpowiedzi, jest najmniej wymagające z punktu widzenia pamięci, a najbardziej wrażliwe na przepustowość i równoległość obliczeń. Tutaj mocna karta graficzna robi największą różnicę dla typowego użytkownika: pozwala osiągać wielokrotnie większą liczbę tokenów na sekundę, a przy tym utrzymywać niskie opóźnienia pierwszej odpowiedzi. GPU, które świetnie radzi sobie w grach, nie zawsze równie dobrze sprawdzi się w LLM – wszystko zależy od tego, jak wygląda jego architektura pod kątem obliczeń tensorowych.

Zastosowania domowe i półprofesjonalne lokalnych LLM

Lokalny chatbot na karcie graficznej przestaje być gadżetem, a staje się realnym narzędziem, gdy model odpowiada szybko, spójnie i bez irytujących przycięć. W praktyce oznacza to: możliwość ładowania modeli 7B–13B (a czasami 34B) bez agresywnej quantyzacji, z rozsądną długością kontekstu (np. 8k–16k tokenów). Taki asystent może pomagać w kodowaniu, podsumowywać dokumenty, generować drafty tekstów czy wspierać analizę logów – bez wysyłania danych na zewnątrz.

Dla półprofesjonalisty – programisty, badacza danych, konsultanta – lokalny LLM to laboratorium do błyskawicznych eksperymentów. Można testować różne architektury, prompt engineering, chaining narzędzi, a nawet własne pipeline’y RAG (retrieval augmented generation) bez czekania na kolejkę w chmurze. Karta graficzna o odpowiedniej ilości VRAM umożliwia trzymanie w pamięci jednocześnie kilku wariantów modeli, co ułatwia porównania i produkcyjne decyzje.

Lokalna infrastruktura AI przydaje się także w firmach, które nie chcą, by poufne dane opuszczały sieć wewnętrzną. Symptomatyczny przykład: mała kancelaria prawnicza, która chce analizować umowy i pisma procesowe. Zamiast wysyłać treści do zewnętrznej usługi, można uruchomić wyspecjalizowany model na serwerze z mocnym GPU i dać pracownikom dostęp przez wewnętrzny interfejs webowy.

Chmura kontra lokalne GPU – gdzie jest realny zysk

Często powtarza się hasło: „do AI potrzebna jest tylko chmura, lokalny sprzęt nie ma sensu”. To wygodna narracja dostawców usług, ale rzeczywistość jest bardziej złożona. Chmura sprawdza się świetnie przy krótkotrwałych, bardzo intensywnych zadaniach lub gdy potrzebne są zasoby, których fizycznie nie da się wstawić do jednego biura. Jednak przy regularnej pracy eksperymentalnej, budowaniu własnych prototypów i lokalnych usług, własne GPU wychodzi taniej i wygodniej.

Koszt wynajmu instancji z sensownym GPU (np. 24 GB VRAM i więcej) liczony w dziesiątkach lub setkach godzin miesięcznie bywa porównywalny z ratą za fizyczną kartę, którą można później odsprzedać lub wykorzystać do innych zadań. Do tego dochodzi kwestia prywatności: lokalny model nie „widział” niczego poza tym, co znajduje się w twoim środowisku, co upraszcza zgodność z RODO i wymogami branżowymi.

Mit polega na założeniu, że każda praca z AI musi skalować się w nieskończoność. Wiele zastosowań LLM jest z natury jednostanowiskowych lub ograniczonych do małego zespołu. W takich scenariuszach mocna karta graficzna w stacjonarnym PC lub niewielkim serwerze daje samowystarczalność i pozwala testować nowe pomysły bez czekania na budżet na chmurę i formalne procedury.

Jakie parametry karty graficznej naprawdę liczą się w AI

Pojemność i przepustowość VRAM a rozmiar modelu

Najważniejszym ograniczeniem przy pracy z modelami LLM jest pamięć wideo (VRAM). Każdy parametr modelu musi zostać załadowany do VRAM w wybranym formacie liczbowym, a do tego dochodzi jeszcze miejsce na bufory, cache i kontekst. W uproszczeniu: im więcej VRAM, tym większy model w wyższej precyzji można uruchomić bez uciekania się do ekstremalnej quantyzacji.

Model 7B w formacie INT4 zwykle mieści się w 6–8 GB VRAM, podobny model w INT8 potrzebuje już około 8–10 GB, a warianty FP16 wymagają nawet kilkunastu gigabajtów. Przy 13B i wyżej sensowne stają się karty 16 GB i więcej, zwłaszcza jeśli planowane jest wykorzystanie dłuższych kontekstów. Dla modeli 34B i powyżej, nawet z quantyzacją, granica 24 GB VRAM zaczyna być ciasna i konieczne jest dzielenie modelu na kilka GPU lub ograniczanie parametrów.

Istotna jest też przepustowość VRAM, zależna m.in. od szerokości magistrali pamięci i taktowania. Wysoka przepustowość przyspiesza transfery między pamięcią a rdzeniami obliczeniowymi, co zmniejsza ryzyko, że jednostki tensorowe będą się „nudzić”, czekając na dane. Dlatego dwie karty z tą samą ilością VRAM, ale różną szerokością magistrali (np. 128-bit vs 256-bit), mogą znacząco się różnić wydajnością w modelach LLM.

Rdzenie CUDA, jednostki obliczeniowe i wyspecjalizowane akceleratory

Klasyczna liczba rdzeni CUDA (w przypadku Nvidii) czy jednostek CU (Compute Units) w kartach AMD jest ważna, ale przy AI coraz większe znaczenie mają wyspecjalizowane jednostki do obliczeń macierzowych: Tensor Cores, Matrix Cores, XMX itp. To one obsługują operacje typu GEMM (general matrix multiply), które dominują w architekturach transformerów wykorzystywanych w LLM.

W praktyce oznacza to, że karta o porównywalnej liczbie rdzeni ogólnego przeznaczenia, ale nowszej generacji z ulepszonymi Tensor Cores, potrafi być kilkukrotnie szybsza w zadaniach AI niż starszy model o większej „surowej” mocy w TFLOPS FP32. Dla użytkownika ważniejsze jest więc wsparcie dla określonych trybów obliczeń (np. FP16, BF16, INT8 z akceleracją) niż sama liczba „shaderów”.

Mit, który często pojawia się na forach, brzmi: „im więcej TFLOPS, tym lepiej do AI”. Rzeczywistość jest bardziej zniuansowana – marketingowe TFLOPS dotyczą zwykle konkretnych trybów (np. FP32), podczas gdy LLM korzystają masowo z niższych precyzji i wyspecjalizowanych instrukcji. Dwie karty o podobnych TFLOPS FP32 mogą mieć dramatycznie różną wydajność INT8 czy FP16, co przekłada się bezpośrednio na liczbę tokenów na sekundę.

Typy liczb: FP32, FP16, BF16, INT8, INT4 i ich praktyczne znaczenie

Modele LLM rzadko działają w pełnej precyzji FP32, zwłaszcza na etapie inference. Standardem produkcyjnym staje się FP16 lub BF16, a w zastosowaniach domowych i półprofesjonalnych bardzo popularne są quantyzacje INT8, INT4, a nawet eksperymentalnie INT3 czy INT2. Każde obniżenie precyzji drastycznie zmniejsza wymagania co do VRAM oraz pozwala na wykorzystanie szybszych ścieżek sprzętowych.

FP16 i BF16 to kompromis między dokładnością a wydajnością – karty graficzne mają dla nich specjalne jednostki i ścieżki, więc inference jest tu zwykle znacznie szybsze niż dla FP32. INT8 to kolejny krok, często używany w modelach produkcyjnych tam, gdzie zależy na maksymalnej przepustowości przy minimalnej utracie jakości. INT4 i niżej to domena zastosowań lokalnych i eksperymentalnych – tu zysk wydajności jest ogromny, ale niektóre modele gorzej znoszą tak daleką redukcję rozdzielczości wag.

Podczas wyboru GPU do AI warto sprawdzić, jakie precyzje są sprzętowo akcelerowane i jak wygląda wsparcie w bibliotekach (np. cuBLAS, cuDNN, ROCm). Część tańszych lub starszych kart niby obsługuje FP16, ale bez pełnych Tensor Cores, przez co realny zysk jest mniejszy niż sugerowałyby tabelki. Z kolei nowe układy potrafią oferować bardzo szybkie INT8, ale tylko przy określonych konfiguracjach pamięci i rozmiarach macierzy.

Interfejs PCIe, zasilanie i limity mocy

Interfejs PCIe (np. 3.0 x16, 4.0 x8, 5.0 x16) jest kolejnym elementem, który pojawia się w specyfikacjach, ale jego realne znaczenie w LLM bywa przeceniane. Modele językowe ładują się do VRAM raz na jakiś czas, a sam inference wymaga stosunkowo niewielkiego strumienia danych między CPU a GPU. Oznacza to, że dla pojedynczej karty różnica między PCIe 3.0 x16 a 4.0 x16 jest zwykle marginalna, o ile nie dochodzi do ciągłego przeładowywania modelu.

Znacznie istotniejsze okazują się limity mocy i kształt krzywej boost. Przy długotrwałym obciążeniu, typowym dla sesji z LLM, karta musi utrzymać stabilne taktowanie przez wiele minut lub godzin. Zbyt agresywny limit mocy, słabe chłodzenie lub nieoptymalna obudowa mogą sprawić, że GPU zacznie obniżać zegary, co bezpośrednio zmniejsza liczbę tokenów na sekundę. Dlatego konstrukcje o dobrej sekcji zasilania i chłodzeniu mają realną przewagę, nawet jeśli „na papierze” ich parametry wyglądają podobnie.

Przy kilku kartach w jednej maszynie dochodzi także problem przepustowości PCIe oraz zasilacza. Dwa lub trzy GPU bez NVLink muszą się dzielić liniami PCIe i mocą, co komplikuje konfigurację. W zastosowaniach domowych najczęściej używa się pojedynczej karty; wtedy kluczowe jest jedynie zapewnienie odpowiedniego zasilacza (z zapasem) i sprawdzić, czy obudowa pozwoli na swobodny przepływ powietrza przy typowym dla AI obciążeniu ciągłym.

Specyfikacja kontra realna wydajność w LLM

Producenci kart graficznych bombardują liczbami: TFLOPS, GHz, GB/s, rdzenie, cache. W praktyce wydajność w modelach LLM zależy od kombinacji tych parametrów oraz jakości sterowników i bibliotek. Karta o imponujących TFLOPS FP32, ale z kiepsko zoptymalizowanym sterownikiem dla CUDA lub ROCm, może wypadać gorzej niż pozornie słabszy konkurent z lepiej dopracowanym ekosystemem.

Rzeczywiste testy inferencji LLM pokazują, że skalowanie wydajności często nie jest liniowe. Zwiększenie liczby rdzeni o 50% nie musi przekładać się na 50% więcej tokenów na sekundę, jeśli wąskim gardłem stanie się przepustowość VRAM, cache lub opóźnienia w pipeline’ach bibliotecznych. Dlatego oceniając kartę do AI, lepiej patrzeć na wyniki w konkretnych benchmarkach LLM niż na surowe liczby z broszury.

Mit: „najdroższa karta gamingowa zawsze jest najlepsza do AI” – bywa prawdziwy jedynie w wąskim sensie „maksymalnych” wyników. Z perspektywy relacji cena/wydajność, dostępności VRAM i energooszczędności często wygrywają modele ze średniej i wyższej średniej półki, które oferują wystarczający zapas mocy do LLM, a nie ciągną przy tym rachunków za prąd jak mały serwer.

Środowisko AI a wybór GPU: CUDA, ROCm, DirectML i inne niuanse

Dominacja CUDA i ekosystemu Nvidii

CUDA jest od lat standardem de facto w obliczeniach GPU dla AI. Większość popularnych frameworków – PyTorch, TensorFlow, JAX, a także nakładki do LLM (oobabooga, Text Generation WebUI, Open WebUI, LM Studio, różne forki KoboldAI) – w pierwszej kolejności wspiera karty Nvidii. Oznacza to prostszą konfigurację, lepszą dokumentację oraz szybsze wprowadzanie optymalizacji pod nowe architektury.

ROCm i karty AMD – kiedy to ma sens

Ekosystem AMD długo pozostawał w cieniu, jeśli chodzi o AI i LLM, ale wraz z rozwojem ROCm sytuacja zaczęła się zmieniać – choć nierównomiernie. Topowe układy serwerowe (MI210, MI300) potrafią świecić w benchmarkach, natomiast użytkownika desktopowego częściej interesują karty konsumenckie: serie RX 6000 i 7000.

Problem w tym, że wsparcie ROCm jest selektywne. Oficjalne listy wspieranych kart często nie obejmują dużej części konsumenckiego segmentu, a nawet jeśli coś „działa”, to wymaga konkretnej wersji kernela, sterownika i dystrybucji Linuksa. Dla osób, które lubią dłubać i nie boją się kompilacji z gałęzi deweloperskich, to jest do przejścia. Dla kogoś, kto chce uruchomić LM Studio na Windowsie w 10 minut – już mniej.

Rzeczywistość jest taka, że na kartach AMD można dziś sensownie uruchomić wiele modeli LLM, zwłaszcza przez projekty takie jak llama.cpp czy Ollama z backendem HIP/ROCm. Jednak konfiguracja często wymaga świeżych wersji bibliotek, czytania issue na GitHubie i gotowości na obejścia. Losowe „crashe” przy długich sesjach czy brak optymalizacji dla konkretnej architektury GPU wciąż się zdarzają częściej niż w ekosystemie CUDA.

Mit, który przewija się w dyskusjach, to „AMD jest bezużyteczne do AI”. Nie jest – ale nie jest też jeszcze pełnoprawnym zamiennikiem CUDA dla większości użytkowników. Dobrze sprawdza się u osób, które świadomie wybierają Linuksa jako główny system, godzą się na trochę pracy konfiguracyjnej i chcą wykorzystać kuszącą relację cena/VRAM w niektórych modelach Radeonów.

DirectML, Vulkan i inne ścieżki na Windowsie

Użytkownicy Windowsa często szukają „CUDA bez Nvidii”. Tym tropem pojawia się DirectML – warstwa abstrakcji Microsoftu, która pozwala używać GPU różnych producentów (Nvidia, AMD, Intel) przez jednolity interfejs. Żeby jednak miało to znaczenie dla LLM, potrzebne są dobre implementacje po stronie frameworków.

DirectML jest dziś używany m.in. przez ONNX Runtime, a część aplikacji do lokalnych LLM eksperymentuje z backendami opartymi na tej technologii. Działa to, ale zwykle ustępuje wydajnością natywnemu CUDA, a czasem także dobrze skonfigurowanemu ROCm. Zdarzają się też drobne niekompatybilności – model, który stabilnie pracuje na GPU przez CUDA, pod DirectML potrafi wywołać błędy alokacji lub zawieszenia przy dłuższym kontekście.

Alternatywną ścieżką jest Vulkan i projekty takie jak kompute czy wgpu, które starają się budować multiplatformowe backendy obliczeniowe. W praktyce są one głównie domeną bardziej niszowych aplikacji lub środowisk deweloperskich, a nie gotowych narzędzi „dla każdego”. Jeśli jednak ktoś programuje własne pipeline’y inference, może w ten sposób uniezależnić się od jednego producenta GPU – kosztem sporego nakładu pracy.

Z perspektywy osoby, która chce „po prostu odpalić LLM lokalnie”, DirectML i Vulkan to ciekawostki, nie baza. Najczęściej kończy się na tym, że wybór karty graficznej i tak podporządkowuje się temu, jak działają CUDA lub ROCm, a reszta technologii pełni rolę planu B.

Wsparcie w aplikacjach i narzędziach LLM

Goła biblioteka CUDA czy ROCm to dopiero początek. Liczy się też to, jakie backendy oferują konkretne narzędzia do pracy z LLM. Przykładowo, popularne interfejsy webowe mogą nominalnie wspierać różne GPU, ale:

• wariant Nvidia dostaje najpierw aktualizacje i optymalizacje,
• porty pod ROCm bywają oznaczone jako eksperymentalne lub wymagające manualnych flag środowiskowych,
• wersje oparte o DirectML czy tylko CPU często odstają wydajnością o rząd wielkości.

Przykład z praktyki: ta sama aplikacja uruchomiona na karcie Nvidia i AMD, przy podobnej ilości VRAM, potrafi generować dwa razy mniej tokenów na sekundę na Radeonach – nie dlatego, że GPU jest słabe, ale dlatego, że backend ROCm jest młody, używa mniej agresywnych optymalizacji lub nie korzysta jeszcze z najnowszych trików (np. fused-kernel GEMM).

Jeszcze jedno złudzenie: „jak coś działa w PyTorchu na ROCm, to każda aplikacja LLM też zadziała”. Niekoniecznie. Część projektów korzysta z własnych forków bibliotek, kompiluje je statycznie lub wymaga konkretnych wersji. W efekcie zestaw: „dystrybucja systemu + sterownik + biblioteka + wersja aplikacji” musi się zgodzić co do szczegółów. Na CUDA też bywa to problemem, ale skala kłopotów jest zwykle mniejsza, bo autorzy narzędzi zaczynają od tej platformy.

Znaczenie systemu operacyjnego

System operacyjny bywa traktowany jak detal, a tymczasem ma realny wpływ na to, jaką kartę opłaca się kupić do LLM. Na Windowsie dominują karty Nvidii, bo ekosystem sterowników i narzędzi deweloperskich jest dojrzalszy, a wiele aplikacji lokalnych wprost celuje w ten zestaw. Radeon na Windowsie może działać nieźle, ale szybciej natkniemy się na brak wsparcia w konkretnym GUI czy konieczność ręcznych obejść.

Na Linuksie sytuacja jest bardziej zrównoważona. CUDA i tak ma przewagę, ale ROCm oraz sterowniki otwartego oprogramowania dla AMD dają większe pole do eksperymentów. Dla osób, które planują używać kilku GPU równocześnie, Linuks jest często jedynym sensownym wyborem – Windows potrafi sprawiać problemy z wieloma kartami, zwłaszcza mieszając różne generacje i producentów.

Przy laptopach dochodzi jeszcze temat hybrydowych rozwiązań (iGPU + dGPU) i technologii oszczędzania energii. Część frameworków słabo radzi sobie z poprawnym wyborem GPU, jeśli system zarządza przełączaniem grafik. Zdarzają się przypadki, gdzie LLM „klei się” do zintegrowanego GPU, ignorując mocnego RTX-a, dopóki użytkownik nie wymusi ręcznie profilu wydajności w sterowniku lub systemie.

Jak testować karty graficzne pod kątem modeli LLM – metodologia

Dobór modeli i formatów quantyzacji

Test karty graficznej „do AI” ma sens tylko wtedy, gdy dotyka realnych scenariuszy użycia. Dla LLM oznacza to przede wszystkim wybór kilku reprezentatywnych modeli różnych rozmiarów i w różnych formatach. Typowy zestaw, który daje sensowny przekrój, może obejmować:

• model ~7B parametrów w formacie INT4/INT8 – scenariusz „domowy”, szybkie generowanie na średnich kartach,
• model ~13B w INT4/INT8 i FP16 – granica komfortu dla kart z 12–16 GB VRAM,
• model 30–34B w mocno skompresowanej quantyzacji – test VRAM oraz przepustowości,
• opcjonalnie większy model 65B (jeśli konfiguracja pozwala), choćby częściowo na CPU/offload – pokazanie limitów architektury.

Warto celowo wymieszać modele typu „instruct” oraz bardziej ogólne, bo niektóre implementacje różnią się stopniem optymalizacji warstw (attention, MLP) lub sposobem buforowania kontekstu. W praktycznych testach szybko widać, że model A i B o tej samej liczbie parametrów potrafią generować z nieco różną szybkością – to normalne.

Mit: „wystarczy przetestować jeden model i skalować wnioski na resztę”. Rzeczywistość jest bardziej skomplikowana – zmiana architektury (np. Mistral vs LLaMA) czy samego formatu quantyzacji potrafi przesuwać wąskie gardła między przepustowością VRAM a mocą obliczeniową Tensor Cores.

Tokeny na sekundę – jak to mierzyć sensownie

Podstawowym wskaźnikiem wydajności w LLM jest liczba tokenów generowanych na sekundę (tok/s). Diabeł tkwi w szczegółach, bo łatwo „podkręcić” wynik w sposób, który niewiele mówi o realnym użyciu.

Przy sensownym pomiarze należy:

• pominąć czas ładowania modelu do VRAM – mierzyć tylko sam inference po załadowaniu,
• rozróżniać prędkość tokenów „po rozgrzaniu” (po pierwszych kilku) od samego startu,
• zapisywać osobno prędkość przy krótkim kontekście (np. 256–512 tokenów) i długim (kilka tysięcy),
• zachować te same ustawienia sampling (temperature, top-k/top-p) oraz długości odpowiedzi.

Jeśli narzędzie nie podaje wprost tok/s, można zmierzyć czas generacji znanej liczby tokenów (np. 512) i policzyć wynik ręcznie. Przy kilku powtórzeniach widać, jak stabilny jest odczyt i czy karta nie wpada w throttling po dłuższej pracy.

Warto też spojrzeć na jitter – czyli wahania prędkości w trakcie jednej generacji. Wysokie piki i spadki wskazują na potencjalne problemy z zasilaniem, chłodzeniem albo konflikty z innymi procesami w systemie, co w warunkach produkcyjnych potrafi być bardziej uciążliwe niż sama średnia tok/s.

Jednowątkowe vs równoległe obciążenie

Jedna sesja z modelem to najprostszy scenariusz, ale nie zawsze najbardziej miarodajny. W praktyce często zachodzi potrzeba obsługi kilku zapytań naraz – albo jednoczesnego generowania tekstu, analizy dokumentów i embeddingów. GPU wtedy nie pracuje już jak w syntetycznym benchmarku.

Przy testach kart warto więc uwzględnić:

• kilka równoległych instancji tego samego modelu (np. 2–4),
• mieszane obciążenie: jedna instancja LLM + proces generujący embeddingi lub wykonujący batch requesty,
• zachowanie przy „kolejkowaniu” zapytań w jednym serwerze modelu (np. vLLM, text-generation-inference).

Niektóre GPU lepiej radzą sobie z pełnym „wypchaniem” potoku obliczeń przy wielu strumieniach, inne szybciej się dławią, gdy rośnie liczba kontekstów. Tu ujawniają się zalety większego cache, lepszych schedulerów wewnątrz architektury czy samego oprogramowania (np. support dla paged attention).

Często okazuje się, że karta, która jest minimalnie wolniejsza w pojedynczej sesji, wygrywa przy bardziej złożonym, wielowatkowowym scenariuszu – i to takie testy lepiej opisują realne użycie na małym serwerze zespołowym.

Monitoring VRAM, temperatur i throttlingu

Same wyniki tok/s bez kontekstu potrafią być mylące. Równolegle z benchmarkiem trzeba obserwować zużycie VRAM, temperatury i wykres taktowania. Przydatne są narzędzia pokroju nvidia-smi, radeontop, GPU-Z czy dedykowane widgety monitorujące.

Przy analizie wykresów zwraca się uwagę na kilka rzeczy:

• czy VRAM jest faktycznie wykorzystany (jeśli GPU i tak „wisi” przy 4 GB zajętej pamięci, to większa karta mogłaby w danym scenariuszu zejść z mniejszym poborem mocy),
• czy taktowanie rdzenia i pamięci jest stabilne czy też spada po kilku minutach – objaw throttlingu,
• jak kształtuje się pobór mocy – czy karta dobija do limitów, czy ma jeszcze zapas.

Mit: „jak karta nie osiąga 100% użycia GPU w monitoringu, to jest coś nie tak”. Przy LLM wąskim gardłem bywa VRAM, scheduler lub biblioteka, więc 70–80% obciążenia rdzenia może być jak najbardziej normalne, zwłaszcza przy lżejszych modelach i niskiej kolejce zapytań.

Powtarzalność i konfiguracja testowa

Żeby wyniki między kartami dało się porównywać, konfiguracja musi być jak najbardziej spójna. Przede wszystkim chodzi o:

• ten sam system operacyjny i wersje sterowników (w miarę możliwości),
• identyczne wersje frameworków i bibliotek (PyTorch, transformers, llama.cpp, itp.),
• te same ustawienia zasilania CPU i GPU (brak undervoltingu na jednej karcie i „stock” na drugiej),
• stabilne warunki chłodzenia (ta sama obudowa, podobne ułożenie kabli i przepływ powietrza).

Warto przed każdym testem zresetować environment (np. restart systemu), bo wycieki pamięci w long-running procesach potrafią subtelnie zaniżać wydajność. Podobnie, trzeba odizolować inne procesy korzystające z GPU – przeglądarka z włączonym akceleratorem czy klient gier potrafią przeszkadzać bardziej, niż się wydaje.

Jeśli wyniki dla tej samej karty „skaczą” między uruchomieniami o kilkadziesiąt procent, problem leży zwykle w środowisku, a nie w samym GPU. Zanim sięgniemy po wnioski typu „ta karta jest niestabilna w LLM”, lepiej dociągnąć powtarzalność testu do sensownego poziomu.

Przegląd klas kart graficznych do AI – od budżetowych po półprofesjonalne

Segment budżetowy: używane i średnia półka poprzedniej generacji

Dla wielu osób pierwsze podejście do LLM lokalnie to „co kupić, żeby nie zbankrutować”. W tym segmencie liczą się przede wszystkim używane karty z przyzwoitą ilością VRAM, nawet jeśli wydajność w grach jest już przeciętna. Najrozsądniej wypadają:

• karty z 8–12 GB VRAM Nvidii poprzednich generacji (np. RTX 2060 12 GB, RTX 3060 12 GB),
• niektóre Radeony z 16 GB VRAM (np. RX 6800) – pod warunkiem gotowości na ROCm/Vulkan.

Średnia półka: uniwersalne karty do pracy i gier

W przedziale „rozsądny, ale nie budżetowy” mieszczą się nowe karty, które łączą przyzwoity VRAM z sensowną wydajnością obliczeniową. To najczęstszy wybór osób, które chcą równocześnie grać, montować wideo i bawić się LLM lokalnie.

W praktyce trzon tego segmentu to:

• RTX 3060 Ti / 3070 / 4060 Ti 16 GB – dobre CUDA, ale czasem ograniczeniem bywa VRAM poniżej 16 GB,
• RTX 4070 / 4070 Super (12 GB) – świetny stosunek wydajności do poboru mocy, lecz znowu: tylko 12 GB,
• Radeony RX 7700 XT / 7800 XT – mocne w grach i FP32, ale wymagające środowiska pod ROCm/DirectML.

Dla modeli 7–13B w INT4/INT8 to wygodny poziom – tok/s jest już na tyle wysoki, że generowanie „nie boli”, a karta nie dusi się przy równoległych zadaniach. Przy FP16 i modelach 13B limit 12 GB VRAM szybko zaczyna uwierać. Część użytkowników próbuje wtedy mieszać offload na RAM, co działa, ale potrafi dziwnie „szarpać” wydajnością.

Mit: „RTX z 12 GB wystarczy na długo do wszystkiego”. W generowaniu wideo czy grach – często tak. W LLM rozwój idzie w kierunku większych kontekstów i modeli; 12 GB dziś jest „sweet spotem”, za 1–2 lata może stać się nowym minimum komfortu.

Średnia półka to dobre miejsce dla osób, które nie chcą zamykać się na jeden scenariusz. Jeśli LLM ma być jednym z kilku zastosowań, a nie głównym powodem zakupu, taki kompromis ma sporo sensu – nawet kosztem nieco słabszych wyników w największych modelach.

Wyższa półka konsumencka: dużo VRAM i mocne Tensor Cores

Jeśli głównym celem jest AI, a gry są „dodatkiem”, zaczyna się robić ciekawie przy kartach z 16 GB VRAM i więcej. Tu przewagę mają przede wszystkim wybrane modele Nvidii oraz niektóre Radeony z dużą pamięcią.

Najczęściej padają nazwy:

• RTX 4070 Ti Super 16 GB – bardzo szybkie inference 7–13B w FP16, rozsądne 30B w INT4,
• RTX 4080 / 4080 Super (16 GB) – więcej rdzeni i wyższa przepustowość, lepsze skalowanie przy wielu sesjach,
• karty typu RTX 3090 / 3090 Ti (24 GB) z rynku wtórnego – duży VRAM, choć wyższy pobór mocy i starsza architektura,
• Radeon 7900 XT / XTX (20–24 GB VRAM) – bardzo pojemne, ale mocno zależne od konkretnego stosu software.

W tej klasie pojawia się nowa jakość: możliwość sensownej pracy z modelami 30–34B bez brutalnej quantyzacji oraz komfortowe utrzymywanie długich kontekstów. Przy dobrze dobranych formatach (np. mieszane INT4/FP16, paged attention) jedną kartą można obsłużyć mały zespół – kilka równoległych czatów, plus embeddingi i analizy dokumentów w tle.

Rzeczywistość szybko weryfikuje mit „im większy, tym lepszy model zawsze warto ładować w całości w FP16”. Przy wielu zadaniach równocześnie 30B w agresywnej quantyzacji, ale z dużym kontekstem i wysokim tok/s, bywa po prostu praktyczniejsze niż perfekcyjnie odwzorowane 13B, które dławi się przy każdym dodatkowym zapytaniu.

Przy tej klasie kart szczególnie ważna staje się jakość chłodzenia i sekcji zasilania. LLM potrafią utrzymywać niemal stałe, wysokie obciążenie przez długie okresy, co jest zupełnie innym profilem niż typowe „piki” z gier. Tańsze, przegrzewające się konstrukcje potrafią tracić dziesiątki procent wydajności przez stały throttling, mimo że na papierze mają „tę samą” specyfikację.

Półprofesjonalne konfiguracje: 24 GB VRAM i więcej

Na granicy świata konsumenckiego i serwerowego pojawiają się układy z 24 GB VRAM (lub wyżej) i bardziej przewidywalną pracą pod ciągłym obciążeniem. To obszar dla osób, które faktycznie budują małe serwery LLM, a nie tylko „czasem odpalają czata”.

Typowe przykłady z tej półki:

• RTX 4090 24 GB – nadal formalnie karta „gamingowa”, ale realnie bardzo blisko rozwiązań półprofesjonalnych pod AI,
• RTX 4080/4090 w konfiguracjach multi-GPU – przy odpowiednim zasilaniu i obudowie,
• starsze karty serwerowe pokroju A4000 / A5000, lub używane Quadro/Titan z dużą ilością VRAM.

Przy 24 GB VRAM i dobrej obsłudze strumieni można już sensownie trzymać kilka instancji 13B w FP16, jednocześnie obsługując większy model 30B w INT4 do zadań wymagających wyższej jakości odpowiedzi. Pojawiają się też realne scenariusze fine-tuningu na niewielkich podzbiorach danych, bez konieczności żonglowania fragmentami modelu między RAM a VRAM co kilka kroków.

Mit, który często pada przy takich konfiguracjach: „4090 to przesada do LLM w domu”. Dla osoby, która raz na tydzień coś testuje – zgoda. Dla kogoś, kto dziennie przepuszcza setki zapytań, eksperymentuje z różnymi modelami, prowadzi mały serwer dla zespołu i okazjonalnie robi fine-tuning – różnica w „przesadzie” jest nagle dużo mniejsza, kiedy liczy się też czas i stabilność.

Półprofesjonalne zestawy mają jeszcze jedną zaletę – zwykle lepszy ekosystem do pracy ciągłej. Stabilniejsze sterowniki, lepsza tolerancja na wysokie obciążenie, sprawdzona współpraca z frameworkami serwerowymi (vLLM, TGI, Triton). Na dłuższą metę przekłada się to na mniej dziwnych awarii przy długotrwałych zadaniach.

Multi-GPU a modele LLM: kiedy ma to sens

Naturalnym krokiem po wyciśnięciu maksimum z jednej karty jest dorzucenie kolejnej. W przypadku LLM multi-GPU nie zawsze skaluje się tak „ładnie”, jak przy klasycznym trenowaniu modeli w dużych instytucjach, ale są konkretne scenariusze, gdzie to podejście działa dobrze.

W praktyce są dwie główne strategie:

• data parallel – każda karta obsługuje inne zapytania, model mieści się w VRAM pojedynczego GPU,
• model parallel / tensor parallel – jeden model jest rozłożony na kilka kart, współdzielących jego parametry.

Pierwszy wariant jest znacznie prostszy i w wielu małych setupach rozwiązuje 90% problemów – stawiamy dwa serwery modelu (po jednym na GPU), load balancer i po sprawie. Skaluje się to prawie liniowo, o ile CPU i RAM dotrzymują kroku.

Model parallel brzmi kusząco („zrobię z dwóch 12 GB jedną 24 GB”), ale rzeczywistość miewa ostre krawędzie. Dochodzi komunikacja między kartami (NVLink, PCIe), opóźnienia, dodatkowe złożone biblioteki i ograniczona liczba frameworków, które faktycznie potrafią to obsłużyć stabilnie w produkcji. Przy braku NVLink dwa RTX-y spięte tylko przez PCIe potrafią tracić tyle na synchronizacji, że przewaga nad jednym dużym GPU znika.

Przykładowy, sensowny układ domowo-labowy to dwie karty 16–24 GB, każda z własnym serwerem modelu, spięte prostym load balancerem (nawet nginx albo haproxy). Zamiast walczyć z model parallel, łatwiej uruchomić dwa różne modele: lżejszy do codziennych pytań oraz cięższy, dokładniejszy do trudniejszych zadań.

Zużycie energii i kultura pracy pod obciążeniem AI

LLM generują inny typ obciążenia niż gry. Sesja z modelem 13B potrafi przez kilkadziesiąt minut trzymać GPU w okolicach stałego, wysokiego poboru mocy, bez typowych dla gier przerw i spadków. To szybko wychodzi przy rachunkach za prąd i temperaturach w pomieszczeniu.

Przy ocenie kart dobrze uwzględnić:

• jaką moc rzeczywiście ciągnie karta przy inference (nie zawsze jest to deklarowane TGP),
• czy da się bezboleśnie ograniczyć power limit o 10–20% bez dużej straty tok/s,
• jak głośne są wentylatory przy długim obciążeniu i czy obudowa radzi sobie z odprowadzaniem ciepła.

Mit: „undervolting i limity mocy są tylko dla maniaków oszczędzania watów”. W praktyce lekkie przycięcie limitu potrafi zmniejszyć temperatury i hałas, jednocześnie stabilizując zegary, przez co tok/s niemal się nie zmienia. Zamiast „gonić” każdy procent wydajności, często korzystniej ustawić kartę trochę poniżej maksymalnych możliwości, ale z gwarancją powtarzalności.

W dłuższej perspektywie różnica między kartą 200 W a 450 W, pracującą kilka godzin dziennie na wysokim obciążeniu, przekłada się na konkretne kwoty. Jeśli budżet energetyczny jest napięty (np. małe biuro, współdzielone z innymi serwerami), mniej prądożerna konfiguracja z pozoru słabszą kartą może wygrać ekonomicznie.

Specyfika laptopów z GPU do LLM

Laptopy kuszą mobilnością, ale przy LLM ujawniają swoje ograniczenia szybciej niż przy grach. Problemem nie jest tylko wydajność; równie istotne są limity mocy, temperatury i VRAM, który przy mobilnych GPU bywa przycięty.

Typowe bolączki mobilnych kart pod AI:

• niższe TGP względem desktopowych odpowiedników (np. „RTX 4070 Laptop” to zupełnie inny układ niż desktopowy),
• częstszy throttling termiczny, zwłaszcza przy długich zadaniach w ciepłym otoczeniu,
• kłopoty z przełączaniem między iGPU a dGPU w niektórych frameworkach i sterownikach.

Laptopowe RTX-y z 8 GB VRAM szybko dochodzą do ściany przy modelach powyżej 7–8B, gdy pojawia się potrzeba dłuższego kontekstu czy mniej agresywnej quantyzacji. Modele z 12–16 GB VRAM są znacznie bardziej użyteczne, ale kosztują odpowiednio więcej i wymagają solidnego chłodzenia.

W typowym scenariuszu „analityk w terenie” rozsądny jest kompromis: lokalny, mniejszy model 7B do szybkich odpowiedzi offline i dostęp do większego modelu (np. 34B) po VPN na serwerze biurowym. Próba zrobienia z cienkiego ultrabooka pełnoprawnej stacji LLM kończy się zwykle rozczarowaniem – i gorącą klawiaturą.

GPU a inne typy zadań AI obok LLM

Mało kto używa GPU wyłącznie do czatowania z LLM. W realnych konfiguracjach obok modeli językowych pojawiają się generatory obrazów (Stable Diffusion, sdxl), narzędzia do wideo, audio czy klasyczny machine learning. Te obciążenia bywają bardzo różne.

Przy wyborze karty sensownie jest spojrzeć na cały zestaw zadań:

• Stable Diffusion i pochodne wyjątkowo lubią VRAM – 12 GB to wygodny minimum, 16–24 GB daje znacznie większą swobodę,
• klasyczne biblioteki ML (XGBoost na GPU, RAPIDS) zwykle lepiej czują się na CUDA niż na ROCm/DirectML,
• narzędzia wideo (upscaling, de-noise, transkrypcja) też najczęściej mają lepsze wsparcie po stronie Nvidii.

Mit: „jak karta jest dobra do LLM, to będzie idealna do wszystkiego w AI”. Da się znaleźć takie słodkie punkty (np. RTX 4070/4080), ale są też skrajności: potężny Radeon z 24 GB VRAM będzie świetny do niektórych zadań, a przy innych (np. bardziej egzotyczne frameworki) polegnie z powodu słabszego wsparcia po stronie bibliotek.

Dobrym podejściem jest spisanie listy faktycznie używanych narzędzi – nie tych „może kiedyś”, tylko realnych – i weryfikacja, jak radzą sobie na CUDA/ROCm/DirectML. Czasem wyjdzie z tego klarowny wniosek, że zamiast maksymalizować VRAM, lepiej postawić na ekosystem, który po prostu nie sprawia problemów.