통역사 vs 원어민, 구체적으로
PyTorch MPS 가 NVIDIA 하드웨어 위해 박힌 PyTorch 코드가 Apple Silicon 의 Metal backend 에서 돌게 하는 CUDA-API 번역 layer. 모든 PyTorch op 이 그 Metal Performance Shader 등가물에 dispatch (또는 MPS 구현 없으면 CPU 로 fallback). 번역 동작; GPU 가 자기 메모리 가진 별도 device 라는 세계관 물려받을 뿐.
MLX 는 Apple Silicon 위해 직접 박힌 framework. Unified-memory 모델, lazy graph, function transform — 이 중 어느 것도 기존 API 위에 retrofit 안 됨; framework 의 design center.
실제로 이게 어떻게 보이나
- API 표면 — PyTorch MPS 는 네가 아는 같은
torch.tensor,tensor.to('mps'), autograd-by-tape 패턴 사용. MLX 는mx.array,.to()없음, autograd-by-function-transform. 다른 비용에 다른 모양. - 성능 — 같은 모델에 PyTorch MPS 와 MLX 사이 갭이 small to moderate (가끔 한쪽 이김, 가끔 반대). 릴리스 사이 리더 바뀜. specific 워크로드 측정하지 않으면 성능으로 안 골라.
- Coverage — PyTorch MPS 가 Metal 의 PyTorch op 100% 지원 안 함. 갭이 매 릴리스 닫히지만 여전히 조용히 CPU 로 fallback 하는 op hit 가능, 성능 죽임. MLX 는 더 작고 완전 지원 표면 가짐 — PyTorch 가 가진 같은 모델 안 받지만 받는 거는 동작.
- 메모리 모델 — PyTorch MPS 가 Apple Silicon 이 안 필요해도 .to(device) 의식이 API 에 baked. MLX 의 API 가 하드웨어와 일치.
PyTorch MPS 가 맞는 호출일 때
- 기존 PyTorch codebase 가 있고 재작성 없이 Mac 에서 로컬 개발 원함. Drop-in CUDA → MPS swap 이 PyTorch MPS 가 존재하는 이유.
- PyTorch-specific 라이브러리 의존 (HuggingFace transformers, specific torch-only 모델). 아직 MLX 로 다 port 안 됨.
- Cloud GPU 학습과 bug-for-bug 호환성 원함 — Mac 에서 prototype 하고 NVIDIA 에 배포할 수 있게, 동작 surprise 없이.
MLX 가 맞는 호출일 때
- Apple Silicon 에 새로 시작하고 honor 할 PyTorch legacy 없음.
- Function-transform 스타일 원함 (JAX-flavor —
mx.grad,mx.vmap, 쉬운 compile). - GPU 빌리지 않고 LLM 로컬 fine-tune 원함 (mlx-lm 의 LoRA 워크플로가 PyTorch MPS 의 등가물보다 더 polish).
- Mac-전용 배포에 출하하고 native-shape API 원함.
솔직한 중간 지점
호스티드 GPU 클러스터와 Mac 사이 bounce 하는 연구엔, PyTorch MPS 가 코드 통합 유지. Mac-전용 작업, 특히 Mac-전용 LLM 워크플로엔, MLX 가 다른 사람의 하드웨어 위해 디자인 안 된 framework.