Autor: Jakub Rusinowski · Ostatnia aktualizacja: 12 lipca 2026
Dwa konsumenckie GPU dają mniej więcej 1,5× — a nie 2× — prędkości pojedynczego żądania względem jednej karty, więc wnioskowanie na wielu GPU opłaca się dokładnie z jednego powodu: żeby uruchamiać mod
Dwa konsumenckie GPU dają mniej więcej 1,5× — a nie 2× — prędkości pojedynczego żądania względem jednej karty, więc wnioskowanie na wielu GPU opłaca się dokładnie z jednego powodu: żeby uruchamiać modele zbyt duże na VRAM jednej karty. Ten poradnik wyjaśnia prostym językiem różnicę między równoległością tensorową a potokową, pokazuje uczciwe wyniki benchmarków i omawia konfigurację w Ollama, llama.cpp i vLLM.
Ostatnia aktualizacja: lipiec 2026
Równoległość tensorowa dzieli każdą macierz wag między GPU; każde liczy swoją część *każdej* warstwy i synchronizuje się po jej zakończeniu. Oba GPU pracują jednocześnie — to jedyny tryb, który przyspiesza pojedyncze żądanie — ale synchronizacja następuje dziesiątki razy na token, więc to przepustowość połączenia decyduje, ile z tego zysku zostaje. To właśnie --tensor-parallel-size w vLLM.
Równoległość potokowa (warstwowa) umieszcza warstwy 1–40 na GPU 0, a 41–80 na GPU 1. Token przepływa przez jedno GPU, a *potem* przez drugie — karty pracują na zmianę, więc pojedyncze żądanie działa z prędkością jednego GPU (minus koszt przeskoku). Tak domyślnie działają llama.cpp i Ollama: dodaje to VRAM, a nie prędkość.
Równoległość danych ładuje pełną kopię modelu na każde GPU i rozdziela między nie *żądania*. Prędkość pojedynczego żądania bez zmian; łączna przepustowość podwaja się. Ma sens tylko wtedy, gdy model i tak mieści się na jednej karcie, a Ty obsługujesz wielu użytkowników.
Reprezentatywne wyniki llama.cpp/vLLM dla powyższych schematów:
| Konfiguracja | Model 8B Q4 | Model 70B Q4 |
|---|---|---|
| 1× RTX 3090 (24 GB) | ~100–110 t/s | Nie mieści się |
| 2× RTX 3090, podział warstw (domyślnie w Ollama) | ~95–105 t/s (bez zysku) | ~15–18 t/s (teraz działa!) |
| 2× RTX 3090, równoległość tensorowa (vLLM) | ~140–160 t/s (~1,5×) | ~20–25 t/s |
| 2× RTX 3090 + NVLink, równoległość tensorowa | ~160–175 t/s | ~24–28 t/s |
Dlaczego nie 2×? Równoległość tensorowa synchronizuje GPU po każdej warstwie — przy modelu 70B to 80 synchronizacji na token. Po PCIe 4.0 x16 (~32 GB/s w każdą stronę) opóźnienie tych synchronizacji jest podatkiem, który płacisz. RTX 3090 to ostatnia konsumencka karta z NVLink (~112 GB/s) — dlatego pary używanych 3090 pozostają klasycznym budżetowym zestawem pod modele 70B; zobacz poradnik o używanych GPU.
Jeszcze jedna pozycja, o której ludzie zapominają: komputer z dwoma GPU pobiera pod obciążeniem 700–850 W i potrzebuje zasilacza 1200 W lub mocniejszego — miesięczne rachunki wylicza poradnik o kosztach prądu.
Dwie karty podwajają też twoją ekspozycję na problemy ze stanem sterownika: aktualizacja pakietu, po której stary moduł zostaje załadowany, daje niezgodność wersji sterownika i biblioteki NVML na obu GPU naraz.
Ollama automatycznie wykorzystuje każde widoczne GPU, dzieląc warstwy. Naprawdę nie ma tu czego konfigurować:
nvidia-smi # potwierdź, że obie karty są widoczne
ollama run llama3.3:70b # automatycznie dzieli model między obie
# Przypnij pracę do jednej karty, gdy nie chcesz podziału:
CUDA_VISIBLE_DEVICES=0 ollama serveW czystym llama.cpp możesz kontrolować proporcje — przydatne przy niedobranych kartach:
# Karta 24 GB bierze 60%, karta 16 GB bierze 40%
./llama-cli -m llama-70b-q4.gguf --n-gpu-layers 999 --tensor-split 60,40Różne GPU działają w llama.cpp (mniejsza karta po prostu ogranicza swój udział); nastawiaj się na „model działa”, a nie „model jest szybki”.
vllm serve meta-llama/Llama-3.3-70B-Instruct \
--quantization awq --tensor-parallel-size 2 --max-model-len 8192Zasady, które oszczędzą Ci wieczoru debugowania: równoległość tensorowa chce *identycznych* GPU (dzieli równo — para 24 GB + 16 GB zachowuje się jak 2× 16 GB), liczba głowic uwagi modelu musi dzielić się przez liczbę GPU (2, 4 i 8 są bezpieczne), a przekraczanie 2 GPU na konsumenckim PCIe szybko przynosi malejące korzyści. Pełny kontekst serwowania znajdziesz w poradniku konfiguracji vLLM.
| Twoja sytuacja | Werdykt |
|---|---|
| Model mieści się na obecnej karcie, chcesz prędkości | Nie dokładaj GPU — wymień kartę albo zejdź niżej z kwantyzacją |
| Chcesz 70B i masz jedną kartę 24 GB | Druga identyczna karta: klasyczne posunięcie |
| Wybierasz między 1× 4090 a 2× 3090 | 4090 do wszystkiego ≤24 GB; 2× 3090 tylko przy ambicjach 70B+ |
| Obsługujesz wielu użytkowników, model mieści się na jednej karcie | Równoległość danych (dwie instancje + load balancer), nie tensorowa |
| Czytasz to jako użytkownik Maca | Odpuść sobie całość — Mac z 64 GB+ uruchamia 70B na jednym układzie (poradnik dla Maca) |
Nie. Przy równoległości tensorowej licz na ~1,4–1,6× na konsumenckim PCIe; przy domyślnym podziale warstw w Ollama — na ~1,0× (dodaje pamięć, nie prędkość). Podwojenie, które sobie wyobrażasz, dotyczy wyłącznie *przepustowości* przy wielu równoległych żądaniach, a nie Twojej pojedynczej rozmowy.
Przy równoległości tensorowej w vLLM: praktycznie tak (równy podział, dopasowane kernele). Przy podziale warstw w llama.cpp/Ollama: nie — mieszane karty działają, z --tensor-split do wyrównania obciążenia, a liczy się łączna ilość VRAM.
Mniej więcej połowi karę za synchronizację przy równoległości tensorowej na 3090 (to ostatnia konsumencka karta z jego obsługą; mostki kosztują 80–150 USD na rynku wtórnym). Warto przy dedykowanym zestawie 2× 3090 pod 70B; bez znaczenia w trybie pojemnościowym z podziałem warstw.
W praktyce nie — wybierz jeden backend. Buildy llama.cpp na Vulkanie technicznie potrafią wykryć karty różnych producentów, ale podatek od stabilności i wydajności zamienia to w projekt badawczy, a nie konfigurację do pracy.