llama.cpp와 MLX 중 어느 쪽이 빠른지는 모델과 워크로드에 따라 갈린다. r/LocalLLaMA의 M5 Max 128GB 실측에서 Qwen 3.5 27B는 MLX 4bit가 31.6 tok/s, llama.cpp Q6_K가 16.5 tok/s로 MLX가 1.9배 빨랐다. 반면 rapidmlx의 M2 Pro 실측에서는 긴 문서를 한 번에 넣는 prefill 단계에서 llama.cpp가 모든 모델에 대해 1.7~2.2배 빨랐다. 채팅·에이전트 위주면 MLX, 대용량 문서 일괄 처리 위주면 llama.cpp가 맞는 선택이다. 이 글의 모든 수치는 아래 출처의 공개 실측 자료에서 그대로 가져온 것이고, 직접 돌린 벤치는 없다.
M5 Max에서 llama.cpp와 MLX, 어떤 모델이 더 빨랐나
r/LocalLLaMA에 올라온 M5 Max 128GB 벤치는 GPU 40코어, 대역폭 614 GB/s, GPU 할당 메모리 122,880 MB 환경에서 llama.cpp v8420과 MLX 0.31.1을 같은 모델로 붙여봤다.
| 모델 | 파라미터 | 양자화 | 엔진 | 토큰 속도 (tok/s) |
|---|---|---|---|---|
| DeepSeek-R1 8B | 8B | Q6_K | llama.cpp | 72.8 |
| Qwen 3.5 27B | 27B | 4bit | MLX | 31.6 |
| Gemma 3 27B | 27B | Q6_K | llama.cpp | 21.0 |
| Qwen 3.5 27B | 27B | Q6_K | llama.cpp | 16.5 |
| Qwen 2.5 72B | 72B | Q6_K | llama.cpp | 7.6 |
같은 Qwen 3.5 27B에서 16.5와 31.6이 나온 게 핵심이다. 저자는 이 격차를 1.9배로 계산했다. llama.cpp 쪽에 Qwen 3.5 아키텍처 관련 알려진 성능 저하가 있다고 설명한다. 같은 표에서 DeepSeek-R1 8B는 614 GB/s 대역폭 기준 이론치 97.5 tok/s에 실제 72.8로 75% 효율이었다.
llama.cpp가 이기는 구간은 어디인가
rapidmlx 실측(M2 Pro 32GB, llama.cpp build 10330, mlx-lm 0.31.3)은 다른 그림을 보여준다. prefill, 즉 프롬프트를 처음 읽히는 단계에서 llama.cpp가 세 모델 전부에서 앞섰다.
| 모델 (prefill tok/s) | MLX | llama.cpp | ratio |
|---|---|---|---|
| gpt-oss-20b | 250 | 558 | 0.45 |
| Qwen3.6-35B-A3B | 277 | 460 | 0.60 |
| Gemma4-12B-it | 96 | 172 | 0.56 |
50쪽 PDF 요약처럼 프롬프트가 긴 일회성 작업이면 llama.cpp를 쓰라는 결론이다. 콜드 프롬프트 첫 토큰까지 시간도 llama-server가 2.3초(Qwen)로 rapid-mlx의 3.4초보다 빨랐다. 다만 대화는 두 스택 모두 프롬프트 접두어를 캐시해서 두 번째 턴부터는 체감 차이가 거의 없다.
왜 MoE 모델에서 격차가 크게 나나
Qwen3.6-35B-A3B는 파라미터 35B를 저장하지만 토큰마다 약 3B만 켜는 sparse MoE다. decode가 메모리 대역폭과 부분 가중치 집계에 묶인 구조라, 통합 메모리 기반으로 설계된 MLX가 이 패턴을 잘 다룬다. rapidmlx 실측에서 raw 기준 61.7 대 39.1, 서버 경로 기준 58.5 대 38.3 tok/s로 두 경로 모두에서 MLX가 약 1.5배 앞섰다. 동시에 돌리는 스트림이 늘어나도 MLX 서버만 aggregate 속도가 올랐다(75.7에서 82.9). llama.cpp는 오히려 53.2에서 48.8로 떨어졌다.
Ollama나 LM Studio를 쓸 때는 무엇을 확인해야 하나
Ollama와 LM Studio는 llama.cpp와 MLX(백엔드)를 감싸는 껍질이다. 새 모델일수록 엔진 선택이 속도 차를 만들기 때문에, GUI를 써도 결국 위 표와 같은 엔진·양자화 조합을 고르는 문제가 된다. 워크로드가 채팅이면 MLX 계열, 문서 일괄 처리면 GGUF 계열을 고르면 된다. GGUF와 MLX 포맷 자체의 차이는 앞서 다룬 GGUF vs MLX 가이드를 참고한다.
결국 어떤 기준으로 골라야 하나
- 채팅, 코딩 어시스턴트, 에이전트 루프: decode 속도가 지배적. MLX가 이기고 MoE면 격차가 더 크다.
- 긴 문서 한 번에 요약, fresh 청크 RAG: prefill이 지배적. llama.cpp가 약 2배.
- dense 소형 모델: 격차가 10~15% 수준이라 속도보다 생태계로 골라야 한다.
- 병행 설치는 부담이 없다. 두 스택은 GGUF와 safetensors로 파일이 달라 한 맥에서 공존한다. 이 노트북에서 직접 돌린 모델별 토큰 수치는 로컬 LLM 허브에 정리해 뒀다.
llama.cpp의 강점은 Linux·Windows·CUDA·Vulkan까지 되는 이식성인데, Mac만 쓴다면 그 장점이 무의미해진다. 반대로 MLX는 Apple 전용이다.
자주 묻는 질문
맥에서 MLX가 무조건 더 빠른가요?
아니요. 생성(decode) 구간에서는 대부분의 모델에서 MLX가 앞섰지만, 프롬프트 처리(prefill)에서는 llama.cpp가 모든 모델에서 1.7~2.2배 빨랐다. 워크로드가 생성 위주인지 입력 위주인지가 기준이다.
수치는 언제까지 유효한가요?
llama.cpp와 MLX 모두 업데이트가 잦다. 위 수치는 각각 2026년 3월과 8월 실측 시점 기준이며, rapidmlx 측도 수치에 유통기한이 있다고 명시한다. 재현 프로토콜과 raw JSON이 공개돼 있으니 직접 돌려 비교하는 게 정확하다.
두 개를 같이 써도 되나요?
가능하다. 가중치 포맷이 GGUF와 MLX(safetensors)로 달라서 같은 기계에 공존한다. 실사용 예로는 평상시 채팅·코딩은 MLX 서버, 대용량 문서 배치는 llama.cpp로 나누는 구성이 제안돼 있다.
출처
- r/LocalLLaMA, M5 Max 128g Performance Tests (2026-03-30 게시)
- rapidmlx, MLX vs llama.cpp on Apple Silicon: Measured Performance (2026-08-11, 갱신 2026-08-12)
기준일 2026-10-15. 수치는 각 자료 게시 시점의 공개 실측값이며 직접 재현한 벤치가 아닙니다.
답글 남기기