Start / Poradniki / Rozwiązywanie problemów / Apple
macOS
Autor: Jakub Rusinowski · Ostatnia aktualizacja: 1 września 2026
Edukator AI i prowadzący warsztaty z wdrażania lokalnych modeli LLM
Activity Monitor → Memory
Memory Pressure: ▇▇▇▇▇▇▇▇ (red)
Swap Used: 14.62 GB
Memory Used: 31.88 GB of 32.00 GB
| Jeśli widzisz | Przyczyną jest | Przejdź do |
|---|---|---|
| Presja pamięci jest czerwona, a Użyty swap rośnie w gigabajty | Zestaw roboczy przekracza pamięć fizyczną i macOS stronicuje na SSD | Rozwiązanie 2: przytnij model albo kontekst |
| Wszystko zamiera i pojawia się kręcąca się piłka w chwili ładowania modelu | Jedna duża alokacja wepchnęła cały system w swap za jednym zamachem | Rozwiązanie 1: potwierdź to w Monitorze aktywności, potem rozwiązanie 2 |
| Działa przez jakiś czas i psuje się, gdy rozmowa rośnie | Cache KV rośnie wraz z kontekstem i zjada resztę zapasu | Rozwiązanie 3: ogranicz długość kontekstu |
| Presja jest żółta, a generowanie jest tylko wolne, nie zamrożone | Jesteś 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 roboczy | To limit zestawu roboczego Metala, a nie presja pamięci | To inna strona — zobacz poradnik o limicie wired |
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ę.
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.
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 — 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 1vm.swapusage pokazuje rosnący użyty swap w trakcie pracy modelu i wypłaszcza się po jego wyładowaniu.sysctl vm.swapusagePraktyczna 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 — 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}'sysctl vm.swapusage && ollama psCache 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 — 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 appsysctl vm.swapusageBrzmi 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 — top ten memory consumers right now
ps -A -o rss=,comm= | sort -rn | head -10 | awk '{printf "%.1f GB %s\n", $1/1048576, $2}'memory_pressure -l 1 | tail -3Jeś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 — a Q4_K_M tag rather than the default
ollama pull qwen3:8b-q4_K_M
ollama run qwen3:8b-q4_K_M
ollama psIstnieje 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 — 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 recommendedMaxJeś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
sysctl hw.memsize i sysctl vm.swapusage przy załadowanym modeluBo 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.
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.
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.
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.
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ż.