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

Podnoszenie limitu VRAM Metala na Apple Silicon

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

ggml_metal_init: recommendedMaxWorkingSetSize  = 98304.00 MB
ggml_metal_init: skipping kernel_... (not supported)
ggml_backend_metal_buffer_type_alloc_buffer: error: failed to allocate buffer, size = 42000.00 MiB

Który to przypadek?

Kiedy się pojawia

Masz mnóstwo pamięci, a loader jest innego zdania. Zdradza to linia recommendedMaxWorkingSetSize w wyjściu startowym llama.cpp albo Ollamy, podająca limit znacznie niższy od tego, co maszyna faktycznie ma zainstalowane.

• Masz 64 GB albo 128 GB, a duży model odmawia alokacji mimo oczywistego zapasu wolnej pamięci.
• Loader wypisuje rozmiar zestawu roboczego równy mniej więcej trzem czwartym zainstalowanego RAM-u.
• Model, który na papierze się mieści, kończy błędem alokacji bufora Metala.
• Chcesz uruchomić model 70B na maszynie z 64 GB, gdzie domyślny podział zostawia cię o włos za krótko.
• Przeczytałeś o tym sysctl na forum i chcesz wiedzieć, co on właściwie robi, zanim go uruchomisz.

Co się właściwie dzieje

Metal ogłasza zalecany maksymalny rozmiar zestawu roboczego — ilość pamięci zunifikowanej, którą uważa za bezpieczną do oddania GPU — a llama.cpp, Ollama i większość środowisk opartych na Metalu traktują tę wartość jak twardy sufit. macOS ustawia ją zachowawczo, zwykle na jakieś 75% zainstalowanej pamięci, rezerwując resztę dla systemu. Na maszynie ze 128 GB oznacza to około 96 GB dla GPU, co w liczbach bezwzględnych jest sporo, a mimo to potrafi zabraknąć dużemu modelowi razem z jego cache'em KV. Podział ten zmienia sysctl iogpu.wired_limit_mb. Jest to nieudokumentowane pokrętło: Apple go nie publikuje, jego nazwa zmieniła się już raz między wersjami macOS i może zmienić się ponownie w dowolnym wydaniu.

Jak to naprawić

1. Ustal, który klucz przyjmuje twoja wersja macOS i na co jest ustawiony

To ustawienie nosiły dwa klucze. Obecne systemy używają iogpu.wired_limit_mb, starsze wersje macOS — debug.iogpu.wired_limit. Odczytanie obu mówi ci, który istnieje na twojej maszynie, a ma to znaczenie, bo ustawienie klucza, którego twój system nie ma, pozornie się udaje i nie robi absolutnie nic — i tak właśnie ludzie dochodzą do wniosku, że to pokrętło jest mitem. Wartość 0 znaczy „użyj domyślnej systemowej”, a nie „bez limitu”.

# zsh — which key exists here?
sysctl iogpu.wired_limit_mb 2>/dev/null || echo "iogpu.wired_limit_mb: not present"
sysctl debug.iogpu.wired_limit 2>/dev/null || echo "debug.iogpu.wired_limit: not present"

# Total installed memory, in MB
sysctl -n hw.memsize | awk '{printf "%d MB installed\n", $1/1048576}'

2. Podnieś limit w megabajtach, zostawiając realny zapas dla macOS

Wartość podaje się w megabajtach: 60 GB to 61440, a 96 GB to 98304. Ustaw ją przez sysctl, a zadziała natychmiast, bez restartu. Ile zostawić, to kwestia osądu, a poniższa tabela jest naszą rekomendacją, a nie wartością udokumentowaną przez Apple — wskazówka ze źródeł mówi tylko tyle, że zbliżanie się do 100% jest tym miejscem, w którym robi się źle, a jako bezpieczny sufit często podaje się około 70% pamięci fizycznej. Na Macu z 32 GB zostaw systemowi co najmniej 8 GB (ustaw ~24576). Przy 64 GB zostaw co najmniej 10 GB (ustaw ~55296). Przy 128 GB — co najmniej 16 GB (ustaw ~114688).

⚠️ Nie ustawiaj tego blisko 100% zainstalowanej pamięci. macOS potrzebuje pamięci, której nie może wypchnąć na dysk, a zagłodzenie go kończy się paniką jądra i wymuszonym restartem — tracisz wszystko, co niezapisane, a maszyna potrafi spanikować ponownie w trakcie odzyskiwania. Zostaw zapas podany wyżej.

# zsh — 60 GB ceiling on a 64 GB Mac; takes effect immediately, lost on reboot
sudo sysctl iogpu.wired_limit_mb=55296

# Read it back
sysctl iogpu.wired_limit_mb

sysctl iogpu.wired_limit_mb

3. Potwierdź, że środowisko uruchomieniowe naprawdę widzi nowy limit

Ustawienie sysctl to nie to samo co uszanowanie go przez środowisko uruchomieniowe — i właśnie to sprawdzenie domyka pętlę. Uruchom model i przeczytaj w wyjściu loadera linię ggml_metal_init: recommendedMaxWorkingSetSize. Jeśli ta liczba się nie ruszyła, albo ustawiłeś klucz, którego twój system nie używa, albo środowisko już działało i zapamiętało starą wartość — zrestartuj je.

# zsh — llama.cpp prints it on every load
./llama-cli -m model.gguf -ngl 999 2>&1 | grep -i recommendedMax

# Ollama: restart the app, then read its log
log show --last 5m --predicate 'process CONTAINS "ollama"' 2>/dev/null | grep -i recommendedMax

./llama-cli -m model.gguf -ngl 999 2>&1 | grep -i recommendedMax

4. Utrwal ustawienie — albo świadomie tego nie rób

sysctl ustawiony w wierszu poleceń przepada przy restarcie. Dodanie klucza do /etc/sysctl.conf czyni go trwałym. Istnieje sensowny argument, żeby tego nie robić: wartość dobra na długą sesję wnioskowania nie jest tą, którą chcesz mieć w mocy przy montażu wideo albo pracy z maszyną wirtualną, a sudo sysctl na sesję ogranicza zmianę do momentów, w których naprawdę jej potrzebujesz. Jeśli jednak ją utrwalasz, bądź hojny przy zapasie, bo zła wartość obowiązuje teraz przy każdym starcie.

⚠️ Zbyt agresywna trwała wartość obowiązuje przy każdym starcie, także przy tym, którym chcesz ją naprawić. Najpierw przetestuj ją na żywo przez sysctl i utrwalaj dopiero taką, która przez dłuższy czas wytrzymała obciążenie.

# zsh — persist across reboots
echo "iogpu.wired_limit_mb=55296" | sudo tee -a /etc/sysctl.conf

# Or revert to the system default at any time (0 = default, not unlimited)
sudo sysctl iogpu.wired_limit_mb=0

sysctl iogpu.wired_limit_mb

5. Wypatruj objawów przesady

Ostrzeżenie ze źródeł jest dosadne — robi się poważnie źle, jeśli nie zostawisz dość miejsca — a warto wiedzieć, jak wygląda to „poważnie źle”, żeby rozpoznać w tym własne sprawstwo. Kolejność jest taka: system robi się ospały pod obciążeniem; serwer okien zacina się, a aplikacje wolno się przerysowują; potem przychodzi panika jądra i wymuszony restart, a razem z nim utrata niezapisanej pracy. Jeśli po podniesieniu limitu zobaczysz którykolwiek z dwóch pierwszych objawów, obniż go, zamiast brnąć dalej.

# zsh — did the machine panic since you changed this?
ls -lt /Library/Logs/DiagnosticReports/*.panic 2>/dev/null | head -3

# Back off to the default while you reconsider
sudo sysctl iogpu.wired_limit_mb=0

ls -lt /Library/Logs/DiagnosticReports/*.panic 2>/dev/null | head -3

6. Pamiętaj, że to nie tworzy pamięci Najczęstsze rozwiązanie

Najważniejsze zdanie na tej stronie: podniesienie limitu zmienia podział, a nie dokłada pamięci. Jeśli model potrzebuje więcej, niż twój Mac ma, żadna wartość tego sysctl nie pomoże, a pchanie sufitu w górę na maszynie, której już brakuje, przenosi ból z nieudanej alokacji Metala na swapowanie albo panikę. Nie jest to też zamiennik kupienia odpowiedniej ilości pamięci — na Macu z 16 GB uczciwą odpowiedzią jest mniejszy model. Najpierw sprawdź, co naprawdę się mieści, a limit podnoś dopiero wtedy, gdy arytmetyka mówi, że brakuje ci naprawdę niewiele.

# zsh — installed, current ceiling, and what is left for macOS
sysctl -n hw.memsize | awk '{printf "installed: %d MB\n", $1/1048576}'
sysctl -n iogpu.wired_limit_mb 2>/dev/null | awk '{printf "gpu ceiling: %s MB\n", $1}'

Jeśli nic z tego nie pomogło

Jeśli presja pamięci była czerwona, zanim dotknąłeś czegokolwiek z tego, limit nigdy nie był ograniczeniem, a właściwa jest strona o swapowaniu. Jeśli Metal nie jest używany w ogóle, żadna zmiana limitu nie pomoże.

• Twój Mac swapuje na dysk, zamiast uruchomić model
• Apple Silicon: model nie chce korzystać z GPU / Metal nieaktywny
• Twój MacBook jest szybki przez dwie minuty, potem o połowę wolniejszy

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

• Linia ggml_metal_init: recommendedMaxWorkingSetSize z twojego loadera
• Wynik sysctl iogpu.wired_limit_mb (albo klucza debug) oraz sysctl hw.memsize
• Twoja wersja macOS i model Maca
• Czy po zmianie pojawiły się raporty paniki w /Library/Logs/DiagnosticReports

Powiązane

• Co się zmieści w 64 GB
• Który Mac do lokalnych modeli LLM
• Sprawdź, co zmieści się na twoim Macu

Najczęstsze pytania

Co właściwie zmienia iogpu.wired_limit_mb?

To, ile pamięci zunifikowanej Metal pozwoli GPU przypiąć na stałe — a środowiska uruchomieniowe odczytują tę wartość jako recommendedMaxWorkingSetSize i traktują jak twardy sufit. Redystrybuuje istniejącą pamięć między GPU a system; nie dokłada ani bajta.

Ile zostawić dla macOS?

Nasza rekomendacja to co najmniej 8 GB na Macu z 32 GB, 10 GB przy 64 GB i 16 GB przy 128 GB. Wskazówka ze źródeł jest luźniejsza — nie zbliżaj się do 100%, a jako bezpieczne podaje się często około 70% pamięci fizycznej. To są osądy, a nie wartości udokumentowane przez Apple.

Czy ustawienie przeżywa restart?

Nie. sysctl z wiersza poleceń przepada przy restarcie. Dodanie klucza do /etc/sysctl.conf go utrwala. Wiele osób woli tego nie robić, żeby agresywna wartość obowiązywała wyłącznie w tych sesjach, w których faktycznie jest potrzebna.

Mój sysctl mówi „unknown oid”. Co teraz?

Twoja wersja macOS używa zamiast tego starszego klucza debug.iogpu.wired_limit. Ma to znaczenie, bo ustawienie klucza, którego system nie ma, wygląda na udane i niczego nie zmienia — zawsze odczytaj wartość z powrotem i sprawdź, czy zgłaszany przez loader rozmiar zestawu roboczego się ruszył.

Co się stanie, jeśli ustawię za wysoko?

System robi się ospały, serwer okien zacina się, a w końcu maszyna wpada w panikę jądra i restartuje się, tracąc niezapisaną pracę. macOS potrzebuje pamięci, której nie może wypchnąć na dysk. Jeśli po podniesieniu limitu widzisz dwa pierwsze objawy, obniż go.