Python 이 잘못된 도구일 때
MLX Quest 의 대부분이 Python 가정 — 대부분 ML 작업이 Python 에서 일어나니까. 근데 Python 이 옵션 아닌 배포 타겟 있어 — App Store 애플리케이션, iOS / macOS 앱 binary 안에 출하해야 하는 무엇이든, Swift 의 더 빡빡한 Apple 의 앱 framework 통합 필요한 시나리오. 그런 케이스에 mlx-swift 가 Swift API 표면 가진 같은 MLX framework.
Mental model 이 매우 적은 surprise 로 Python MLX 에서 carry over. Array 가 typed; lazy evaluation 이 기본; function transform 존재. Syntax 가 Swift-shape (Swift 의 let, type inference, value 의 method), 근데 개념적 API 가 평행.
MLX Swift 가 주는 것
- Hood 아래 같은 MLX kernel — 성능이 같은 하드웨어의 Python MLX 와 비슷.
- 앱-출하 path — iOS / macOS 앱 안에 MLX 박고 App Store 통해 출하 가능. Python 은 이거 못 함.
- 빡빡한 Apple framework 통합 — SwiftUI, Combine, 그리고 Apple 의 앱 stack 의 나머지와 직접 interop.
- 더 작은 배포 표면 — Python 인터프리터 없음, pip 의존성 없음, 출하할 virtual env 없음.
포기하는 것
- 라이브러리 ecosystem — 대부분 ML 라이브러리 (Hugging Face transformers, 모든 convenience 가진 mlx-lm) 가 Python-first. mlx-swift 가 core 덮지만 full breadth 아님.
- Iteration 속도 — Swift 의 edit-compile-run loop 가 Python 의 REPL 보다 느려. Python 에서 iterate; Swift 에서 ship.
- 커뮤니티 크기 — Python MLX 가 더 많은 사용자, 더 많은 StackOverflow 답, 더 많은 예제 코드.
권장 워크플로
- Python MLX 에서 학습과 iterate. 실험 단계에 mlx-lm 또는 mlx-vlm 사용.
- 결과 변환 / fuse. LoRA fine-tune 했으면 배포 가능 모델로 fuse (Track 4 lesson 5).
- mlx-swift 통해 embed. Step 2 에서 생산한 같은 모델 디렉토리 로드; 파일 형식 동일.
- 앱 출하. 거기서 표준 iOS / macOS 배포.
이게 정확히 Ollama-on-Mac 이 사용하는 path. 배포 edge 의 언어가 Swift 라고 MLX path 가 안 변해.