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

Model się ładuje, ale działa boleśnie wolno — liczy na CPU

WindowsLinuxmacOS

Autor: Jakub Rusinowski · Ostatnia aktualizacja: 22 czerwca 2026

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

Komunikat błędu

llm_load_tensors: offloaded 0/33 layers to GPU

Kiedy się pojawia

Model ładuje się bez problemu i odpowiada poprawnie — tylko wlecze się w tempie kilku tokenów na sekundę albo gorszym, wentylatory procesora wyją, a GPU stoi bezczynnie. Zdradza to log ładowania: linijka mówiąca, że na GPU trafiła tylko część warstw albo żadna.

Co się właściwie dzieje

Tokeny powstają szybko wyłącznie wtedy, gdy cały model mieszka w VRAM-ie. Gdy się nie mieści, llama.cpp i Ollama zostawiają nadmiarowe warstwy w RAM-ie systemowym i liczą je na CPU. To właśnie ten nadmiar odpowiada za spowolnienie: wnioskowanie na CPU i podróże przez PCIe są o rząd wielkości wolniejsze od pracy na samej karcie. W gruncie rzeczy masz więc problem z brakiem pamięci w przebraniu — model się nie wysypał, tylko sam zdegradował się do procesora.

Jak to naprawić

1. Wybierz model albo kwantyzację, które w całości mieszczą się w VRAM-ie Najczęstsze rozwiązanie

Jeśli offloadowanych jest choćby kilka warstw, zostawiasz na stole większość swojej prędkości. Rozwiązaniem, które faktycznie przyspiesza, jest dobranie rozmiaru i kwantyzacji mieszczących się w całości na GPU — wtedy ładuje się 100% warstw, a liczba tokenów na sekundę wraca tam, gdzie powinna być. Sprawdź dokładnie, która kwantyzacja twojego modelu mieści się na twojej karcie, żeby dostać pełną prędkość zamiast pełzania po CPU.

2. Upewnij się, że GPU rzeczywiście pracuje

Najpierw sprawdź, czy środowisko uruchomieniowe w ogóle widzi twoje GPU. Obserwuj obciążenie w trakcie generowania — jeśli karta stoi na 0%, model liczy w całości na CPU, a to problem z buildem albo sterownikiem, nie zwykłe przelewanie się poza pamięć.

# NVIDIA: watch GPU use live while the model generates
nvidia-smi -l 1

3. Wymuś więcej warstw na GPU (llama.cpp)

Jeśli niewiele ci brakuje, przerzuć na kartę tyle warstw, ile się da, przez --n-gpu-layers. Wysoka wartość (albo -1 dla wszystkich) maksymalizuje to, co siedzi w VRAM-ie. Jeśli po tym dostaniesz OOM, po prostu przekroczyłeś budżet — zejdź o jedną kwantyzację.

./llama-cli -m model.gguf --n-gpu-layers -1

4. Sprawdź, czy masz build z obsługą GPU

Build llama.cpp przeznaczony wyłącznie na CPU *nigdy* nie tknie GPU, bez względu na przekazane flagi. Jeśli kompilowałeś ze źródeł, przebuduj z właściwym backendem: CUDA dla NVIDII, Metal dla Maca, ROCm/HIP dla AMD. Ollama dostarcza obsługę GPU domyślnie, ale zestarzała instalacja potrafi ją stracić po aktualizacji systemu lub sterownika.

Dotyczy także: Linux · Apple

Powiązane

• Windows: sterownikowe i środowiskowe powody, dla których Ollama wybrała CPU
• Windows: przelewanie się do współdzielonej pamięci GPU przez PCIe
• Mac: szybko na starcie, o połowę wolniej po dziesięciu minutach
• Laptop: całą robotę wykonuje zintegrowana karta

Najczęstsze pytania

Skąd mam wiedzieć, czy model liczy na CPU, czy na GPU?

Poszukaj w logu ładowania linijki „offloaded N/M layers to GPU” — jeśli N jest mniejsze od M, część modelu siedzi na CPU. Możesz też obserwować nvidia-smi (NVIDIA) albo historię GPU w Monitorze aktywności (Mac) w trakcie generowania; zajęte GPU oznacza, że jest używane.

Dlaczego częściowy offload na GPU jest aż tak wolny?

Każdy token musi przejść przez warstwy siedzące w RAM-ie i przekroczyć magistralę PCIe, a warstwy liczone na CPU są znacznie wolniejsze. Jeden wolny etap dławi cały potok, więc nawet niewielkie przelanie się poza VRAM potrafi zabić liczbę tokenów na sekundę.

Czy wolno działający większy model jest lepszy od mniejszego?

Przy pracy interaktywnej mniejszy model działający w całości na GPU zwykle wygrywa z większym pełzającym po CPU — różnica w jakości jest niewielka, a w szybkości ogromna. Zanim pogodzisz się z pełzaniem, spróbuj mniejszego modelu, który się mieści.