Apple Silicon 맥북으로 로컬 LLM을 처음 돌려보려는 사람들이 한 번씩 막히는 지점이 있다. Ollama를 설치하면 되는 건지, llama.cpp를 직접 빌드해야 하는 건지, 아니면 요즘 이야기 많이 나오는 MLX를 써야 하는 건지. 각각의 GitHub 리포지토리를 열어보면 설명이 다 다르고, 벤치마크 숫자는 출처마다 제각각이다.
세 가지를 정확히 이해하려면 먼저 이것들이 같은 층위의 도구가 아니라는 점을 짚어야 한다. llama.cpp는 C++로 작성된 추론 엔진 그 자체다. Apple Silicon의 GPU를 쓰는 Metal 백엔드를 포함해서 다양한 하드웨어에 맞게 직접 계산을 처리한다. 모델 파일 포맷은 GGUF를 기본으로 쓰며, 지원하는 모델 범위가 가장 넓다. Llama, Mistral, Phi, Gemma, Qwen 계열 등 거의 모든 인기 오픈소스 모델을 GGUF로 변환하면 올릴 수 있다. 커맨드라인에서 직접 실행하거나 간단한 HTTP 서버 모드로 올릴 수 있는데, 그 유연함 덕분에 임베디드 환경부터 서버까지 두루 쓰인다.
Ollama는 그 llama.cpp를 내부 엔진으로 감싼 래퍼 레이어다. Docker와 비슷한 방식으로 모델을 레지스트리에서 내려받고 관리하며, REST API를 기본으로 제공한다. ollama run llama3 한 줄이면 모델 다운로드부터 추론까지 처리된다는 편의성이 핵심이다. 개발자 입장에서는 OpenAI API와 호환되는 엔드포인트를 바로 쓸 수 있어서, 기존 앱 코드를 거의 수정하지 않고 로컬 모델로 전환하기 좋다. 다만 추론 엔진 자체는 llama.cpp이므로 순수 성능 상한은 동일하고, 추상화 레이어가 얹힌 만큼 미세한 오버헤드가 생긴다.
MLX는 결이 다르다. Apple이 직접 만든 머신러닝 프레임워크로, Apple Silicon의 통합 메모리 아키텍처와 Metal 셰이더를 깊숙이 활용하도록 설계됐다. llama.cpp가 여러 플랫폼을 지원하면서 Metal을 하나의 백엔드로 추가한 것과 달리, MLX는 처음부터 Apple Silicon만을 염두에 두고 만들어졌다. 모델 포맷도 다르다. Hugging Face의 safetensors나 MLX 전용 포맷을 쓰며, llama-cpp-python 커뮤니티와 별개의 생태계를 형성하고 있다. mlx-lm 패키지를 통해 Llama 3, Mistral, Phi-3, Gemma 등 인기 모델을 지원하지만, 지원 모델 폭은 llama.cpp에 비해 아직 좁다.
실제로 얼마나 빠른가
수치를 이야기하기 전에 한 가지 단서를 달아야 한다. “Apple Silicon 맥북”이라는 말 안에 M1, M2, M3, M4 시리즈가 모두 섞여 있고, 칩마다 GPU 코어 수와 메모리 대역폭이 다르기 때문에 절대 수치보다는 상대적 관계를 보는 것이 더 의미 있다.
Llama 3 8B Q4_K_M 기준으로 여러 측정치를 종합하면 대략 이런 양상이 나타난다.
| 런타임 | 대략적 토큰/초 | 비고 |
|---|---|---|
| MLX (mlx-lm) | 50~80 t/s | M2/M3 계열, 최적화 모델 기준 |
| llama.cpp Metal | 40~65 t/s | 동일 하드웨어, Q4_K_M |
| Ollama | 38~62 t/s | llama.cpp 기반, API 오버헤드 포함 |
MLX가 llama.cpp Metal 대비 10~30% 빠른 경향이 있다는 수치가 자주 언급된다. 특히 배치 처리나 긴 프롬프트 상황에서 차이가 더 벌어진다. 이는 MLX가 Apple Silicon의 통합 메모리를 CPU-GPU 간 복사 없이 직접 공유하는 방식을 극단적으로 활용하기 때문이다. llama.cpp의 Metal 백엔드도 같은 하드웨어를 쓰지만, 범용성을 유지하는 설계 탓에 Metal 셰이더 수준의 최적화 밀도에서 차이가 난다.
이미지 출처: Unsplash
흥미로운 건 Ollama와 순수 llama.cpp의 격차가 생각보다 작다는 점이다. Ollama의 오버헤드는 주로 API 레이어에서 발생하는데, 이미 추론이 시작된 이후 토큰 생성 속도 자체보다는 첫 토큰까지의 지연(TTFT, Time to First Token)에서 차이가 드러나는 경우가 많다. 스트리밍 응답을 보면 응답이 시작되는 시점이 0.2~0.5초 정도 늦을 수 있지만, 그 이후 토큰 스트림 속도는 거의 동일하다.
어떤 상황에서 무엇을 쓸 것인가
속도만 보면 MLX가 유리하지만, 실제 선택은 상황에 따라 달라진다.
모델을 빠르게 바꿔가며 테스트하거나, LLM 기반 앱을 로컬에서 프로토타이핑하는 용도라면 Ollama가 가장 손쉽다. 모델 관리 명령어가 직관적이고, OpenAI 호환 API 덕분에 LangChain, LlamaIndex 같은 프레임워크와 바로 연결된다. 편의성이 뚜렷하게 앞선다.
모델 지원 폭이 필요하거나 아직 MLX 컨버팅이 안 된 최신 모델을 써야 한다면 llama.cpp가 정답이다. GGUF 포맷으로 변환된 모델은 Hugging Face에 수천 개가 올라와 있고, 커뮤니티 반응 속도도 빠르다. 새 모델이 공개된 다음 날이면 대부분 GGUF 버전이 등장한다.
반면 Apple Silicon 맥북을 메인 개발 환경으로 쓰고, 매일 로컬 LLM을 많이 돌리는 상황이라면 MLX를 배우는 게 중장기적으로 이득이다. 속도 차이가 체감될 만큼 나고, 파인튜닝 실험까지 하려면 MLX의 훈련 파이프라인이 Mac에서 가장 자연스럽게 돌아간다. 다만 지원 모델이 제한적이라는 점과, 파이썬 환경 설정을 직접 해야 한다는 점은 처음엔 진입 장벽이 될 수 있다.
사실 세 가지를 동시에 설치해도 충돌하지 않는다. 실제로 많은 로컬 AI 사용자들이 평소엔 Ollama로 빠르게 돌리다가, 성능이 중요한 작업은 mlx-lm으로 따로 실행하는 식으로 병행한다.
Apple이 MLX를 꾸준히 업데이트하고 있고, mlx-lm의 모델 지원 목록도 빠르게 넓어지고 있다. 현재 지원 범위의 격차는 시간이 지나면서 좁혀질 가능성이 높다. 반대로 llama.cpp와 Ollama 쪽도 손놓고 있지 않아서, Metal 백엔드 최적화와 모델 로딩 속도 개선이 꾸준히 올라오고 있다. 결국 이 경쟁이 이어질수록 맥북에서 로컬 LLM을 돌리는 환경은 더 빨라질 것이고, 지금 어느 쪽을 먼저 써보든 크게 틀린 선택은 없다.
출처