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

Twój Mac swapuje na dysk, zamiast uruchomić model

macOS

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

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

Komunikat błędu

Activity Monitor → Memory
  Memory Pressure:  ▇▇▇▇▇▇▇▇  (red)
  Swap Used:        14.62 GB
  Memory Used:      31.88 GB of 32.00 GB

Który to przypadek?

Jeśli widziszPrzyczyną jestPrzejdź do
Presja pamięci jest czerwona, a Użyty swap rośnie w gigabajtyZestaw roboczy przekracza pamięć fizyczną i macOS stronicuje na SSDRozwiązanie 2: przytnij model albo kontekst
Wszystko zamiera i pojawia się kręcąca się piłka w chwili ładowania modeluJedna duża alokacja wepchnęła cały system w swap za jednym zamachemRozwiązanie 1: potwierdź to w Monitorze aktywności, potem rozwiązanie 2
Działa przez jakiś czas i psuje się, gdy rozmowa rośnieCache KV rośnie wraz z kontekstem i zjada resztę zapasuRozwiązanie 3: ogranicz długość kontekstu
Presja jest żółta, a generowanie jest tylko wolne, nie zamrożoneJesteś blisko granicy, ale jeszcze jej nie przekroczyłeśRozwiązanie 4: zamknij przeglądarkę i odzyskaj kilka gigabajtów
Z pamięcią wszystko gra, a loader wciąż zgłasza mały zestaw roboczyTo limit zestawu roboczego Metala, a nie presja pamięciTo inna strona — zobacz poradnik o limicie wired

Kiedy się pojawia

Na Macu z Apple Silicon nie ma osobnego VRAM-u, który mógłby się skończyć, więc nie ma też błędu braku pamięci do przeczytania. Model się ładuje, macOS przyjmuje alokację, a potem maszyna staje się bezużyteczna — kursor się zacina, kręci się piłka, wszystko zwalnia, a generowanie idzie w tempie ułamka tokenu na sekundę.

Co się właściwie dzieje

Apple Silicon dzieli jedną pulę pamięci między CPU i GPU — to właśnie czyni go dobrym w tej robocie, bo nie trzeba kopiować wag przez magistralę, i to samo zabiera siatkę bezpieczeństwa. Na dedykowanej karcie za duży model kończy błędem braku pamięci. Tutaj macOS robi to, co zawsze przy niedoborze pamięci: swapuje, zapisując najdawniej używane strony na SSD. Dla większości aplikacji przebiega to łagodnie. Dla wnioskowania jest katastrofą, bo zestawem roboczym są wagi modelu, a te są dotykane przy każdym pojedynczym tokenie — maszyna spędza więc czas na przerzucaniu gigabajtów tam i z powrotem. Model, który na papierze mieści się w twojej całej pamięci, w praktyce się nie mieści, bo z tej samej puli czerpią jeszcze sam macOS, twoja przeglądarka i narzut aplikacji do wnioskowania.

Jak to naprawić

1. Potwierdź to w Monitorze aktywności, zanim cokolwiek zmienisz

Otwórz Monitor aktywności → Pamięć. Liczą się dwie wartości i żadną z nich nie jest „Użyta pamięć”. Presja pamięci to wykres na dole: zielony znaczy zdrowo, żółty — ciasno, czerwony — że macOS aktywnie stronicuje. Użyty swap powinien być bliski zeru na maszynie z zapasem; gigabajty swapu przy załadowanym modelu to gotowa diagnoza. vm_stat daje ten sam obraz w terminalu, a liczniki pageout są tymi, które warto obserwować.

zsh
# zsh — swap in use, and how much has been paged out
sysctl vm.swapusage
vm_stat | grep -E 'Pageouts|Swapins|Swapouts'

# Watch memory pressure live while a model generates
memory_pressure -l 1
Czy zadziałało? Diagnoza jest potwierdzona, gdy vm.swapusage pokazuje rosnący użyty swap w trakcie pracy modelu i wypłaszcza się po jego wyładowaniu.
sysctl vm.swapusage

2. Dobierz model do mniej więcej 70–75% swojej pamięci, a nie do 100% Najczęstsze rozwiązanie

Praktyczna reguła mówi, że dla modelu dostępne jest około 70–75% całej pamięci zunifikowanej, a reszta idzie na macOS, serwer okien i wszystko inne, co masz otwarte. Tego samego ułamka używa nasz kalkulator, więc liczby tutaj i w analizatorze się zgadzają. Poniżej: co faktycznie się mieści przy Q4_K_M i kontekście 8K, policzone tym samym silnikiem, który napędza cały serwis — wartości obejmują cache KV i narzut środowiska uruchomieniowego, nie same wagi. 8 GB (~6 GB użytecznych): model 3B (3,7 GB) wygodnie, model 4B (4,4 GB) na styk. Model 8B w Q4 potrzebuje 6,7 GB i będzie swapował. 16 GB (~12 GB użytecznych): model 8B (6,7–7,0 GB) wygodnie; model 14B (11,1 GB) mieści się z niewielkim zapasem. 24 GB (~18 GB użytecznych): model 14B wygodnie, model 24B (16,4 GB) się mieści. 36 GB (~27 GB użytecznych): model 32B (22,8 GB) albo 27B (25,4 GB), ten drugi ciasno. 48 GB (~36 GB użytecznych): model 32B z realnym zapasem albo MoE 30B. 64 GB (~48 GB użytecznych): model 70B (45,7 GB) mieści się, praktycznie bez zapasu. 128 GB (~96 GB użytecznych): model 70B wygodnie, z miejscem na długi kontekst.

zsh
# zsh — your actual total, in GB
sysctl -n hw.memsize | awk '{printf "%.0f GB total, ~%.1f GB usable for a model\n", $1/1073741824, $1/1073741824*0.75}'
Czy zadziałało? Po zejściu o rozmiar albo poziom kwantyzacji presja pamięci zostaje zielona, a Użyty swap przestaje rosnąć przez całe generowanie.
sysctl vm.swapusage && ollama ps
Sprawdź, co zmieści się na twoim sprzęcie — sprawdź dokładne zapotrzebowanie modelu na pamięć wobec twojego Maca
Otwórz kalkulator VRAM →

3. Ogranicz długość kontekstu — to ta sama arytmetyka

Cache KV rośnie liniowo z kontekstem i czerpie z tej samej puli co wagi. Model, który wygodnie ładuje się przy 4K, potrafi wepchnąć Maca z 16 GB w swap przy 32K — i to dokładnie ten wzorzec kryje się za „było dobrze, a potem zaczęło zwalniać w trakcie rozmowy”. Domyślna wartość w Ollamie to 4096 tokenów; jej podniesienie jest decyzją o pamięci, nie o wygodzie. Ustaw ją świadomie i zmierz efekt.

zsh
# zsh — cap it for one run and watch what changes
OLLAMA_CONTEXT_LENGTH=4096 ollama run qwen3:8b

# Persist it for the Ollama app
launchctl setenv OLLAMA_CONTEXT_LENGTH 8192
# then quit and reopen the Ollama app
Czy zadziałało? Przy krótszym kontekście swap przestaje rosnąć podczas długiej rozmowy, która wcześniej się psuła.
sysctl vm.swapusage

4. Zamknij przeglądarkę — naprawdę drugi największy konsument

Brzmi jak rada z zapchajdziury, a nią nie jest: na większości Maców przeglądarka jest największym konsumentem pamięci zaraz po modelu. Okno Chrome'a albo Safari z trzydziestoma kartami, rozmowa wideo i para aplikacji w Electronie regularnie zbierają 6–10 GB — a na maszynie z 16 GB to cała różnica między zmieszczeniem się a swapowaniem. Posortuj Monitor aktywności po pamięci i spójrz na górę listy, zanim uznasz, że model jest za duży.

zsh
# zsh — top ten memory consumers right now
ps -A -o rss=,comm= | sort -rn | head -10 | awk '{printf "%.1f GB  %s\n", $1/1048576, $2}'
Czy zadziałało? Wolna pamięć rośnie o gigabajt albo więcej, a presja pamięci wraca w stronę zieleni, jeszcze zanim załadujesz model.
memory_pressure -l 1 | tail -3

5. Zejdź o poziom kwantyzacji, zanim zejdziesz o rozmiar modelu

Jeśli model jest blisko, ale nie do końca się mieści, tańszym ruchem jest niższa kwantyzacja niż mniejszy model. Q4_K_M to złoty środek przy zastosowaniach lokalnych, a różnica jakości względem Q6 czy Q8 jest na tyle mała, że większość osób nie odróżni jej w czacie, kodowaniu ani streszczaniu. Dopiero poniżej Q4 degradacja staje się wyraźna. Na Macu ten wybór waży więcej niż na dedykowanej karcie, bo karą za przestrzelenie jest swap, a nie czysta odmowa.

zsh
# zsh — a Q4_K_M tag rather than the default
ollama pull qwen3:8b-q4_K_M
ollama run qwen3:8b-q4_K_M
ollama ps

6. Dopiero potem zaglądaj do limitu zestawu roboczego Metala

Istnieje osobny limit tego, ile pamięci zunifikowanej Metal odda GPU, i czasem warto go podnieść — ale to ostatnia rzecz do wypróbowania, nie pierwsza. Nie tworzy pamięci; zmienia jej podział, a podniesienie go na maszynie, która już swapuje, pogarsza sprawę, zamiast ją poprawiać. Sięgaj po to dopiero wtedy, gdy presja pamięci przy wybranym rozmiarze modelu jest zielona, a loader nadal zgłasza limit zestawu roboczego niższy od tego, co masz wolne.

zsh
# zsh — what does Metal currently think it can use?
# Look for this line in llama.cpp / Ollama loader output:
#   ggml_metal_init: recommendedMaxWorkingSetSize = ...
journalctl 2>/dev/null || log show --last 5m --predicate 'process CONTAINS "ollama"' | grep -i recommendedMax

Jeśli nic z tego nie pomogło

Jeśli presja pamięci jest zielona, a loader wciąż odmawia alokacji, ogranicznikiem jest limit zestawu roboczego Metala, a nie sama pamięć. Jeśli GPU nie jest używane w ogóle — ze swapem czy bez — to inna awaria z własną stroną.

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

Powiązane

Model, który mieści się na większości zestawów:
Zobacz model i wymagania →

Najczęstsze pytania

Dlaczego mój Mac zamarza, zamiast pokazać błąd braku pamięci?

Bo w pamięci zunifikowanej nie ma osobnego VRAM-u, który mógłby się wyczerpać. macOS przyjmuje alokację i zrzuca najdawniej używane strony na SSD. Ponieważ wnioskowanie dotyka każdej wagi przy każdym tokenie, maszyna spędza czas na stronicowaniu — a to objawia się zamarciem, nie błędem.

Ile pamięci mojego Maca może faktycznie wykorzystać model?

W praktyce około 70–75%, a reszta idzie na macOS, serwer okien i twoje pozostałe aplikacje. Nasz kalkulator używa właśnie 75% z tego powodu, więc Mac z 16 GB ma mniej więcej 12 GB zapasu na model razem z jego cache'em KV.

Czy Mac z 8 GB w ogóle uruchomi lokalne modele?

Tak, do 3B włącznie. Model 3B w Q4 potrzebuje około 3,7 GB przy kontekście 8K, co mieści się w mniej więcej 6 GB, którymi dysponujesz. Model 8B w Q4 potrzebuje około 6,7 GB i wepchnie maszynę z 8 GB w swap.

Dlaczego zwalnia, gdy rozmowa się wydłuża?

Cache KV rośnie wraz z kontekstem i czerpie z tej samej puli pamięci co wagi. Model wygodny przy 4K tokenów potrafi przy 32K wepchnąć maszynę w swap. Ograniczenie długości kontekstu to naprawia i jest to ta sama arytmetyka co dobór rozmiaru modelu.

Czy podniesienie limitu wired w Metalu to naprawi?

Nie, a potrafi pogorszyć. To ustawienie zmienia podział pamięci zunifikowanej między GPU a system, a nie jej ilość. Na maszynie, która już swapuje, oddanie GPU większej części odbiera ją macOS. Najpierw doprowadź presję pamięci do zieleni, potem to rozważ.