두 줄 install (그리고 왜 가끔 옆길로 새는지)
Native ARM Python env 에서 pip install mlx mlx-lm. 그게 의도된 워크플로 전부야. 대부분의 실패는 사실 MLX 실패가 아냐 — MLX 를 import 하는 순간 드러나는 Python 환경 실패야.
이 레슨은 일부러 짧아. 핵심은 깨끗하고 재현 가능한 install 을 전용 env 에 받고, verify 체크 돌리고, 어느 요일이든 작동하는 setup 으로 돌아올 수 있다는 걸 알고 떠나는 거.
전용 conda env 써 (권장)
나는 MLX 를 자기 conda env (창의적으로 mlx 라고 이름) 에 두고 다른 ML 스택과 절대 env 공유 안 시켜. 이유는 종교적인 게 아냐 — MLX 는 의존성이 가볍고 거의 충돌 안 해 — 재현성이야. 3 개월 후 돌아왔는데 breaking-change 기차가 지나갔으면, 단일 목적 env 가 있다는 건 한 가지 만 업그레이드한다는 뜻이야.
Rosetta 함정, 자세히
네 python 이 Rosetta x86 emulation 아래 돌고 있으면, MLX 의 pip install 이 조용히 성공하고 첫 import mlx.core 에서 SIGSEGV 할 수 있어. 이유 — pip 가 잘못된 아키텍처용 의존성 wheel 을 resolve 하고 linker 가 import 시간에야 알아차려. Fix 는 자체 platform.machine() 에서 arm64 를 보고하는 Python 을 쓰는 거.
macOS 에서 그걸 보장하는 가장 깨끗한 방법은 miniforge (또는 현대 miniconda, 이제 기본으로 native ARM 출하). 둘 다 모든 Python 인터프리터가 진짜 ARM 인 환경 만들어. 피해야 할 한 함정 — Apple Silicon 에서 legacy x86_64 installer 로 miniconda 설치하지 마. Env 가 멀쩡해 보이고 조용히 Rosetta 써.
검증, 그리고 넘어가
세 체크. 다 통과하면 이 레슨 끝:
uname -m가arm64출력python -c "import platform; print(platform.machine())"도arm64출력 (Rosetta 가 거짓말하는 그것)import mlx.core as mx; print(mx.__version__)가 성공하고 버전 출력
특히 step 2 에서 실패하면 네 Python 은 Rosetta 아래 — 다른 어떤 거보다 먼저 그거 고쳐. "그냥 import 해서 보지" 가 아무리 유혹적이어도.