다른 출생지, 다른 최적화
llama.cpp 가 CPU-랜드에서 태어남. 첫 목표가 CPU 에서 사용 가능한 속도로 LLM 돌리기, GPU 가속은 나중에 incremental 하게 추가됨. 개척한 형식 (GGUF) 이 그 기원 반영 — single-binary, Linux, Windows, Mac 의 CPU 와 GPU runtime 사이 portable 하게 디자인.
MLX 는 GPU/unified-memory-랜드에서 태어남. 디자인이 Apple Silicon 의 compute 모델 가정, Metal 에 직접 매핑되는 kernel 과 공유 CPU/GPU 메모리에 사는 array. 그 가정이 Mac 위에 있을 때 framework 의 강점이고 안 그럴 때 한계.
llama.cpp 가 이기는 곳
- Cross-platform 배포 — 같은 binary 가 Linux, Windows, Mac 에 동작. 배포 표면이 비-Apple 하드웨어 포함하면 llama.cpp 가 명백한 선택.
- CPU-first 추론 — llama.cpp 가 CPU-전용 머신에서 유용하게 돌 수 있어. MLX 는 Apple Silicon 의 GPU 필요.
- 양자화 폭 — GGUF 가 MLX 의 affine 양자화보다 더 다양한 양자화 schema 지원 (Q2_K 부터 Q8_0 까지 많은 K-quant 들 사이). 절대 가장 작은 크기 짜내려면 llama.cpp 가 역사적으로 우위.
- 단일-파일 portability — 한 .gguf 파일이 모델 전체. 출하 쉬움, 새 환경에 drop 쉬움.
MLX 가 이기는 곳
- Native Apple Silicon 성능 — MLX kernel 이 Metal 위해 직접 박힘, 번역 layer 없음. Mac 에서 MLX 가 보통 llama.cpp 의 Metal backend 위 small-to-meaningful 성능 우위 가짐.
- Python 통합 — MLX 는 Python-first; llama.cpp 는 wrapper 로서 Python 바인딩 가진 C++-first.
- Fine-tuning — MLX 가 first-class fine-tuning 워크플로 가짐 (Track 4); llama.cpp 는 추론-집중.
- Function transform 과 연구 워크플로 —
mx.grad,mx.vmap, custom architecture — MLX 의 영역. llama.cpp 는 서빙 runtime, 연구 framework 아님.
실용적 답
배포가 Mac-전용이면 기본 MLX. 배포가 플랫폼 가로지르면 기본 llama.cpp (또는 어떤 runtime 든 형식으로 GGUF). 선택은 단일 Mac 의 raw 성능에 거의 절대 의존 안 해 — 배포 표면, 언어 ecosystem, 추론 너머 모델로 뭐 할지에 대한 거.