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

MLX nie chce się zainstalować albo liczy na CPU

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

ERROR: Could not find a version that satisfies the requirement mlx (from versions: none)
ERROR: No matching distribution found for mlx

Który to przypadek?

Kiedy się pojawia

Dwa różne objawy z jedną wspólną przyczyną. Albo pip stanowczo odmawia znalezienia pakietu, który na pewno istnieje, albo instaluje się czysto i nie dowozi ani odrobiny prędkości, którą MLX ma zapewniać.

• Jesteś na Macu z serii M, a pip install mlx zgłasza brak pasującej dystrybucji.
• Twój Python pochodzi ze starej instalacji Homebrew, z condy zbudowanej pod Intela albo z pobranego instalatora uniwersalnego.
• Przeniosłeś się z Maca z Intelem przez Asystenta migracji i zachowałeś stary toolchain.
• Twój terminal ma zaznaczone „Otwórz przy użyciu Rosetty” w oknie informacji — być może ustawione lata temu.
• MLX zainstalował się bez problemu i nie jest szybszy od llama.cpp na tym samym modelu.

Co się właściwie dzieje

MLX wymaga macOS 14.0 lub nowszego, Apple Silicon oraz natywnego Pythona arm64 w wersji 3.10 albo wyższej. Publikuje wyłącznie wheele arm64, bo jest frameworkiem opartym na Metalu i nie ma sensownego powodu, by dostarczać cokolwiek dla x86. Jeśli twój interpreter to build x86 działający pod Rosettą 2, pip słusznie zgłasza, że żadna dystrybucja nie pasuje — komunikat jest prawdziwy, tylko nie mówi dlaczego. Cała diagnoza to jedno polecenie: platform.processor() musi wypisać arm. Na Macu z serii M wypisuje i386, gdy interpreter jest x86 pod Rosettą, a ten jeden fakt tłumaczy zarówno nieudaną instalację, jak i — w mieszanych środowiskach — rozczarowanie wydajnością.

Jak to naprawić

1. Sprawdź procesor — na tym polega cały ten artykuł

Jedno polecenie mówi ci, czy masz ten problem. Musi wypisać arm. Jeśli na Macu z serii M wypisuje i386, twój Python to build x86 działający pod Rosettą 2 i wszystko inne z tego wynika. Nic poniżej nie ma sensu, dopóki to nie wypisze arm.

# zsh
python3 -c "import platform; print(platform.processor())"
# arm   -> native, good
# i386  -> x86 Python under Rosetta, this is your problem

uname -m           # arm64 on Apple Silicon
sw_vers            # MLX needs macOS >= 14.0
python3 --version  # MLX needs >= 3.10

python3 -c "import platform; print(platform.processor())"

2. Znajdź winnego Pythona

Na maszynie zwykle jest więcej niż jeden interpreter, a ten niewłaściwy stoi pierwszy w twoim PATH. which -a python3 wypisuje je wszystkie po kolei, a file podaje architekturę każdego pliku binarnego wprost. Sama lokalizacja jest już mocną wskazówką: /opt/homebrew to prefiks Homebrew dla arm64, a /usr/local — ten intelowy — więc python3 rozwiązujący się w /usr/local na Macu z serii M jest niemal na pewno winowajcą.

# zsh — every python3 on PATH, in order
which -a python3

# What architecture is the one you are getting?
file $(which python3)
# ... Mach-O 64-bit executable arm64        <- good
# ... Mach-O 64-bit executable x86_64       <- the problem

# Is your shell itself running under Rosetta?
arch

file $(which python3) && arch

3. Sprawdź, czy terminal nie startuje pod Rosettą

Ustawienie, o którym łatwo zapomnieć i którego nie sposób odgadnąć: w Finderze zaznacz Terminal albo iTerm w /Applications/Utilities, naciśnij Command-I i sprawdź, czy zaznaczone jest „Otwórz przy użyciu Rosetty”. Jeśli tak, każdy proces uruchomiony przez terminal jest x86 — łącznie z Pythonem, który uruchomiony w dowolny inny sposób jest zupełnie natywny. Odznacz, zamknij terminal całkowicie i otwórz ponownie. Ludzie ustawiają to raz dla jakiegoś starego narzędzia i zapominają na lata.

# zsh — if this prints i386, the shell itself is under Rosetta
arch
sysctl -n sysctl.proc_translated   # 1 = running translated

arch; sysctl -n sysctl.proc_translated

4. Zainstaluj natywnego Pythona arm64 i odbuduj środowisko

Natywnego interpretera weź z jednego z trzech miejsc: instalatora universal2 z python.org, Homebrew w /opt/homebrew albo miniforge, które jest budowane pod arm64 i jest najprostszą drogą, gdy korzystasz z condy. Potem utwórz środowisko wirtualne od nowa, zamiast używać starego — istniejący venv zapamiętuje interpreter, który go stworzył, i będzie dalej używał tego x86, niezależnie od tego, jakiego Pythona zainstalowałeś od tamtej pory. To ten krok, który ludzie pomijają, i przez niego rozwiązanie sprawia wrażenie niedziałającego.

⚠️ Usunięcie i odtworzenie venva kasuje wszystko, co było w nim zainstalowane. Wyeksportuj najpierw swoje wymagania, jeśli nigdzie ich nie przypiąłeś.

# zsh — arm64 Homebrew Python
/opt/homebrew/bin/brew install python@3.12

# Recreate the venv with the NATIVE interpreter — do not reuse the old one
pip freeze > /tmp/requirements.txt
deactivate 2>/dev/null; rm -rf .venv
/opt/homebrew/bin/python3.12 -m venv .venv
source .venv/bin/activate
python -c "import platform; print(platform.processor())"   # must print: arm

pip install --upgrade pip
pip install mlx mlx-lm

python -c "import mlx.core as mx; print(mx.default_device())"

5. Potwierdź, że MLX naprawdę korzysta z GPU

Udana instalacja nie jest dowodem, że praca ląduje na GPU. mx.default_device() powinno zgłaszać urządzenie GPU. Uruchom krótkie generowanie i obserwuj Monitor aktywności → Okno → Historia GPU albo powermetrics z próbnikiem GPU — powinieneś zobaczyć rosnącą aktywność karty przez cały ten czas. Jeśli urządzenie jest właściwe, a wykres GPU pozostaje płaski, zadanie nie dociera do Metala.

# zsh — what device does MLX think it has?
python -c "import mlx.core as mx; print(mx.default_device())"

# A short generation to watch
python -m mlx_lm.generate --model mlx-community/Llama-3.2-3B-Instruct-4bit \
  --prompt "Write one sentence about the sea." --max-tokens 64

# In a second terminal, watch GPU power while it runs
sudo powermetrics --samplers gpu_power -i 1000 -n 10

sudo powermetrics --samplers gpu_power -i 1000 -n 5 | grep -i "GPU Power"

6. Rozstrzygnij, czy MLX jest tu w ogóle właściwym narzędziem Najczęstsze rozwiązanie

Czytelnicy przychodzą z założeniem, że MLX jest na Macu bezwzględnie szybszy od llama.cpp, a w różnych rodzinach modeli wcale nie jest to niezawodnie prawdą. MLX dobrze pasuje, gdy chcesz robić fine-tuning na Macu, pracować w Pythonie i w kodzie o kształcie NumPy-owym albo używać modelu opublikowanego przez społeczność w formacie MLX. llama.cpp i Ollama są lepszym domyślnym wyborem, gdy zależy ci na najszerszym wyborze GGUF-ów, na serwerze albo po prostu na najmniejszej ilości konfiguracji. Zamiast zakładać, przetestuj konkretny model, na którym ci zależy, na obu — a jeśli między tobą a MLX stoi budowanie ze źródeł, pamiętaj, że potrzebuje ono Xcode 15+, macOS SDK 14+, Clang 15+ i CMake 3.25+, a same Command Line Tools nie wystarczą.

# zsh — the source-build prerequisites, if you need one
xcodebuild -version              # Xcode >= 15.0
xcrun --show-sdk-version         # SDK >= 14.0
cmake --version                  # >= 3.25
clang --version                  # >= 15

Jeśli nic z tego nie pomogło

Jeśli MLX działa na GPU, a Mac wciąż się męczy, ogranicznikiem jest pamięć albo temperatura, a nie framework. Strona o swapowaniu omawia, co faktycznie mieści się w każdym wariancie pamięci; strona o throttlingu — prędkość, która dobrze się zaczyna i spada o połowę.

• 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

• Wynik python3 -c "import platform; print(platform.processor())"
• which -a python3 oraz file $(which python3)
• sw_vers, python3 --version i arch
• Dokładny błąd pipa, razem z linią „from versions:”

Powiązane

• Lokalna AI na macOS
• Instalacja Ollama
• Pierwszy fine-tuning w godzinę

Najczęstsze pytania

Dlaczego pip nie znajduje mlx?

Bo MLX dostarcza wyłącznie wheele arm64, a twój interpreter nie jest arm64. Python x86 działający pod Rosettą 2 nie pasuje do żadnej dystrybucji, więc pip zgłasza, że takiej nie ma. Uruchom python -c "import platform; print(platform.processor())" — musi wypisać arm.

Co znaczy, że platform.processor() wypisuje i386?

Że twój Python to build x86 działający pod Rosettą 2 na Macu z Apple Silicon. Zwykle bierze się to z intelowego Homebrew w /usr/local, condy zbudowanej pod Intela albo z terminala z zaznaczoną opcją „Otwórz przy użyciu Rosetty” w oknie informacji.

Zainstalowałem natywnego Pythona i dalej zawodzi. Dlaczego?

Prawie na pewno dlatego, że użyłeś istniejącego środowiska wirtualnego. Venv zapamiętuje interpreter, który go stworzył, i dalej z niego korzysta. Usuń venv i utwórz go na nowo natywnym Pythonem, a potem sprawdź procesor już w nowym środowisku.

Jakie są faktyczne wymagania MLX?

macOS 14.0 lub nowszy, Apple Silicon oraz natywny Python arm64 w wersji 3.10 lub nowszej. Budowanie ze źródeł wymaga dodatkowo Xcode 15+, macOS SDK 14+, Clang 15+ i CMake 3.25+ — same Command Line Tools do budowania ze źródeł nie wystarczą.

Czy MLX jest na Macu szybszy od llama.cpp?

Nie niezawodnie, a różni się to między rodzinami modeli. MLX pasuje do pracy w Pythonie, fine-tuningu na Macu i modeli publikowanych w formacie MLX. llama.cpp i Ollama pasują do najszerszego wyboru GGUF-ów i najmniejszej ilości konfiguracji. Przetestuj model, którego naprawdę używasz.