Start / Poradniki / Rozwiązywanie problemów / Windows

Współdzielona pamięć GPU na Windowsie każe modelowi pełznąć, zamiast go zatrzymać

Windows

Autor: Jakub Rusinowski · Ostatnia aktualizacja: 1 września 2026

Edukator AI i prowadzący warsztaty z wdrażania lokalnych modeli LLM

Komunikat błędu

Task Manager → Performance → GPU
  Dedicated GPU memory:   7.9/8.0 GB
  Shared GPU memory:      6.2/15.9 GB   <-- this should be 0.0 GB

Który to przypadek?

Jeśli widzisz	Przyczyną jest	Przejdź do
„Współdzielona pamięć GPU” rośnie powyżej 0 GB, gdy model generuje	Sterownik przelał alokację do RAM-u systemowego przez PCIe	Rozwiązanie 2: wyłącz awaryjne sięganie po pamięć systemową dla tej aplikacji
Dedykowana pamięć GPU stoi przyklejona do około 100% pojemności karty	Model razem z cache'em KV jest większy niż twój VRAM	Rozwiązanie 3: spraw, żeby model się zmieścił
Maszyna z Linuksem i tą samą kartą zwraca zamiast tego CUDA OOM	Linux nie ma awaryjnego sięgania po pamięć systemową, więc ta sama alokacja uczciwie tam zawodzi	Rozwiązanie 2, potem 3 — uczciwy błąd też ci się przyda
Pracujesz w WSL2	WSL2 nie respektuje ustawienia z Panelu sterowania	Ta strona cię nie dotyczy — zajrzyj do poradnika o WSL2
Pamięć współdzielona wynosi 0, a mimo to jest wolno	Wąskim gardłem jest coś innego — najpewniej warstwy siedzące na CPU	Rozwiązanie 4: sprawdź, gdzie te warstwy naprawdę są

Kiedy się pojawia

Tu również nie ma żadnego błędu i właśnie dlatego jest to najbardziej mylący windowsowy tryb awarii: wszystko raportuje sukces. Model się ładuje. GPU pracuje. Nic nie świeci na czerwono. Tyle że generuje dwa czy trzy tokeny na sekundę na karcie, która powinna wyrabiać sześćdziesiąt.

Przeszedłeś z kwantyzacji Q4 na Q6 albo Q8 tego samego modelu i prędkość się zawaliła.
Zwiększyłeś długość kontekstu i generowanie dramatycznie zwolniło, nie zgłaszając błędu.
Ten sam model i ta sama karta dają czysty błąd CUDA out of memory na linuksowej maszynie kolegi.
Prędkość jest w porządku przez pierwsze kilkaset tokenów rozmowy i spada, w miarę jak ta rośnie.
Otwarta jest przeglądarka albo inna aplikacja korzystająca z GPU, a jej zamknięcie robi dużą różnicę.

Co się właściwie dzieje

Od gałęzi sterownika 536 windowsowy sterownik NVIDII nie odrzuca alokacji CUDA, która przekroczyłaby dostępny VRAM. Zamiast tego zaspokaja ją z RAM-u systemowego, a Windows pokazuje tę pulę w Menedżerze zadań jako Współdzieloną pamięć GPU. Alokacja się udaje, więc twoje narzędzie do wnioskowania nie ma czego zgłosić — i nie zgłasza. Naprawdę zmieniło się to, że każda waga z przelanego obszaru przekracza teraz magistralę PCIe przy każdym pojedynczym tokenie. PCIe daje mniej więcej o rząd wielkości mniejszą przepustowość niż własna pamięć karty, a dekodowanie jest ograniczone przepustowością, więc spowolnienie jest brutalne i nieproporcjonalne do tego, jak bardzo przekroczyłeś budżet. Na Linuksie ta sama alokacja po prostu kończy się błędem CUDA out of memory — i dlatego twój znajomy z Linuksem dostaje czytelny komunikat, a ty zagadkę.

Jak to naprawić

1. Potwierdź to — obserwuj Współdzieloną pamięć GPU w trakcie pracy modelu

Otwórz Menedżer zadań, przejdź do Wydajność → GPU i uruchom generowanie. Liczą się dwie liczby. Dedykowana pamięć GPU to twój prawdziwy VRAM; jeśli stoi przyklejona do górnej granicy, jesteś przy suficie. Współdzielona pamięć GPU powinna wynosić 0. Cokolwiek powyżej zera przy załadowanym modelu oznacza, że strumieniujesz wagi przez PCIe — i to jest twoja odpowiedź. Porównaj dedykowaną pamięć GPU z faktycznym rozmiarem modelu na dysku plus kilka gigabajtów na cache KV i narzut.

PowerShell

# PowerShell — the same two numbers without opening Task Manager
Get-Counter "\GPU Process Memory(*)\Dedicated Usage" -MaxSamples 1
Get-Counter "\GPU Process Memory(*)\Shared Usage" -MaxSamples 1

Czy zadziałało? Diagnoza jest potwierdzona, gdy wartość współdzielona jest niezerowa dla procesu wnioskowania w trakcie generowania i bliska zeru w bezczynności.

2. Zmuś sterownik, żeby uczciwie zawiódł, zamiast po cichu zwalniać

Otwórz Panel sterowania NVIDIA → Zarządzaj ustawieniami 3D → Ustawienia programu, dodaj plik wykonywalny, który naprawdę prowadzi wnioskowanie — ollama.exe, LM Studio albo python.exe z twojego środowiska wirtualnego — i ustaw CUDA - Sysmem Fallback Policy na Prefer No Sysmem Fallback. Od tej chwili za duża alokacja zwróci błąd braku pamięci, zamiast po cichu przechodzić przez magistralę. Ustaw to dla konkretnego programu, nie globalnie, żeby nie zmieniać zachowania gier i aplikacji kreatywnych, którym awaryjna pamięć faktycznie służy.

⚠️ To zamienia ciche spowolnienie w twarde awarie z braku pamięci. O to właśnie chodzi — uczciwy błąd mówi ci, co naprawić — ale aplikacja będzie się teraz zatrzymywać, zamiast brnąć dalej, więc licz się z tym, że pierwsze uruchomienie po zmianie zawiedzie, jeśli dotąd polegałeś na przelewaniu.

Czy zadziałało? Załaduj model, który pełzał. Jeśli ustawienie zadziałało, zamiast działać wolno, kończy się teraz błędem CUDA out of memory, a Współdzielona pamięć GPU zostaje na 0.

ollama run llama3.1:8b "hi"
ollama ps

3. Teraz napraw właściwy problem — model jest za duży Najczęstsze rozwiązanie

Polityka awaryjnej pamięci zmienia tylko sposób, w jaki się o tym dowiadujesz. Pod spodem fakt jest taki, że wagi plus cache KV plus trochę narzutu przekraczają twój VRAM, a dźwignie są dokładnie trzy: niższa kwantyzacja (przejście z Q6 na Q4_K_M mniej więcej połowi wagi przy różnicy w jakości, której większość osób w czacie nie wychwyci), krótszy kontekst (cache KV rośnie z nim liniowo, a okno 32K przy modelu 8B to same w sobie gigabajty) albo mniejszy model. Ustal, która kombinacja się mieści, zanim cokolwiek jeszcze pobierzesz.

PowerShell

# PowerShell — cap the context for one run and watch what changes
$env:OLLAMA_CONTEXT_LENGTH="4096"
ollama run llama3.1:8b "hi"

Czy zadziałało? Współdzielona pamięć GPU zostaje na 0 przez całe generowanie, a ollama ps pokazuje 100% GPU.

ollama ps

Sprawdź, co zmieści się na twoim sprzęcie — znajdź kwantyzację i długość kontekstu mieszczące się w twoim dedykowanym VRAM-ie
Otwórz kalkulator VRAM →

4. Wyklucz drugi powód spowolnienia — warstwy na CPU

Współdzielona pamięć GPU i offload na CPU to dwie różne wolne ścieżki i wymagają różnych rozwiązań. Jeśli Współdzielona pamięć GPU wynosi 0, a mimo to jest wolno, warstwy nigdy nie trafiły na kartę: to twoje narzędzie wybrało umieszczenie na CPU, a nie sterownik przelał VRAM. ollama ps rozróżnia oba przypadki w jednej linii — wiersz 100% GPU z przelewem do pamięci współdzielonej to problem z tej strony, a podział albo 100% CPU to problem z rozmieszczeniem warstw.

PowerShell

# PowerShell
ollama ps

# llama.cpp: force all layers onto the GPU and see whether it now fails
.\llama-cli.exe -m model.gguf -ngl 999

5. Zwolnij VRAM trzymany przez inne aplikacje

Windows przydziela VRAM temu, kto poprosi pierwszy, a przeglądarka z akceleracją sprzętową, drugi monitor, Discord albo otwarta gra potrafią trzymać jeden do dwóch gigabajtów, zanim twój model w ogóle wystartuje. Na karcie 8 GB to różnica między zmieszczeniem się a przelaniem. Zamknij je i załaduj model ponownie — nie tylko model, bo rozmieszczenie ustala się raz, przy ładowaniu, i nie jest rewidowane, gdy pamięć zwolni się później.

PowerShell

# PowerShell — what is holding VRAM right now
nvidia-smi --query-compute-apps=pid,process_name,used_memory --format=csv

Czy zadziałało? Dedykowana pamięć GPU w bezczynności powinna na desktopie wynosić poniżej mniej więcej 1 GB. Jeśli nie, coś nadal trzyma kartę.

nvidia-smi --query-gpu=memory.used,memory.total --format=csv

Jeśli nic z tego nie pomogło

Jeśli pracujesz w WSL2, żadna z powyższych wskazówek dotyczących Panelu sterowania cię nie dotyczy — WSL2 nie respektuje ustawienia awaryjnej pamięci systemowej, a to ograniczenie po stronie platformy, nie efekt twojej złej konfiguracji. Jeśli przełączyłeś się na No Sysmem Fallback i dostajesz teraz twarde błędy braku pamięci, to spodziewany wynik, a kolejna strona mówi, jak je czytać.

Dołącz to, zgłaszając problem

Wartości dedykowanej i współdzielonej pamięci GPU z Menedżera zadań w trakcie generowania
Wersja twojego sterownika NVIDII (nvidia-smi --query-gpu=driver_version --format=csv)
Dokładny tag modelu i kwantyzacja oraz ustawiona długość kontekstu
Czy Sysmem Fallback Policy jest ustawione i dla którego pliku wykonywalnego

Powiązane

Model, który mieści się na większości zestawów:

Zobacz model i wymagania →

Najczęstsze pytania

Czym jest „Współdzielona pamięć GPU” w Menedżerze zadań Windows?

To pamięć systemowa, której sterownik graficzny może użyć jako zapasu dla VRAM-u. Przy renderowaniu bywa użyteczną siatką bezpieczeństwa. Przy wnioskowaniu LLM jest pułapką: trzymane tam wagi są odczytywane przez PCIe przy każdym tokenie, czyli mniej więcej o rząd wielkości wolniej niż z własnej pamięci karty.

Dlaczego Linux daje mi błąd tam, gdzie Windows po prostu zwalnia?

Bo od gałęzi sterownika 536 windowsowy sterownik przelewa za duże alokacje CUDA do RAM-u systemowego, a Linux nie ma odpowiednika tego mechanizmu. Ten sam zbyt duży model zawodzi więc głośno na Linuksie i po cichu degraduje się na Windowsie. Ta sama przyczyna, dwa bardzo różne objawy.

Czy ustawić „Prefer No Sysmem Fallback” globalnie?

Nie. Ustaw to dla konkretnego programu, czyli dla swojego pliku wykonywalnego od wnioskowania. Gry i aplikacje kreatywne czasem polegają na tym mechanizmie, żeby się nie wysypać, a wyłączenie go w całym systemie zamienia zagadkę w jednej aplikacji na twarde awarie w kilku innych.

Czy dotyczy to kart AMD albo Intela na Windowsie?

Konkretne ustawienie z Panelu sterowania NVIDIA dla nich nie istnieje, a zachowanie sterownika jest inne. Arytmetyka pod spodem pozostaje jednak identyczna: model większy niż twój VRAM albo zawiedzie, albo zejdzie na coś znacznie wolniejszego — a rozwiązaniem wciąż jest sprawić, żeby się zmieścił.

Wyłączyłem awaryjną pamięć i teraz nic się nie ładuje. Zepsułem coś?

Nie — usunąłeś to, co ukrywało problem. Model nigdy się nie mieścił; przez cały czas działał częściowo z RAM-u systemowego. Zejdź o poziom kwantyzacji albo skróć kontekst, aż załaduje się czysto, a będzie znacznie szybszy niż wcześniej.