Mac에서 로컬 모델을 실행하다 보면 결국 동일한 갈림길에 서게 됩니다. 동일한 모델이 GGUF 파일과 MLX 버전으로 모두 제공될 때, 무엇을 다운로드해야 할지 결정해야 합니다. 짧은 답변은 MLX가 Apple Silicon에서 더 빠르고, GGUF는 어디서나 작동한다는 것입니다. 유용한 답변은 그 차이가 실제로 언제 중요한지 아는 것인데, 왜냐하면 많은 설정에서는 그 차이가 중요하지 않기 때문입니다.

이유와 함께 실용적인 버전을 소개합니다.

두 형식이 실제로 무엇인지

GGUF는 단일 자립형 파일입니다. 가중치(Weights), 토크나이저(Tokenizer), 메타데이터(Metadata), 그리고 양자화 파라미터(Quantization parameters)가 모두 하나의 휴대 가능한 블롭(Blob)으로 묶여 있어, llama.cpp(및 이를 기반으로 구축된 모든 것)가 Mac, Linux, Windows, CPU, CUDA, Metal 어디에서나 로드할 수 있습니다. 이러한 휴대성이 이 형식의 핵심 목적입니다.

MLX는 Apple의 어레이 프레임워크(Array framework)이지 파일 형식이 아닙니다. MLX 모델은 safetensors 파일들이 담긴 디렉토리와 MLX 런타임(Runtime)이 직접 읽는 설정(Config) 파일로 구성됩니다. 이는 Apple Silicon에서 실행되고 통합 메모리 풀(Unified memory pool)을 대상으로 네이티브하게 양자화(Quantize)되도록 구축되었습니다. 이는 Apple Silicon을 벗어나지 않습니다. 결론적으로 그렇습니다.

따라서 이것은 엄밀히 말해 "두 가지 파일 형식"이 아닙니다. 하나는 휴대 가능한 형식이고, 다른 하나는 우연히 동일한 모델 가중치를 전달하는 Apple 네이티브 런타임입니다.

성능 격차는 실재하지만 제한적입니다

동일한 Mac에서 동일한 양자화 수준(Quantization level)으로 실행할 때, MLX는 GGUF보다 약 15~40% 더 빠르고 메모리를 약 10% 적게 사용합니다. 이러한 속도 향상은 MLX가 Apple Silicon용으로 컴파일되었고, CPU와 GPU가 하나의 RAM 블록을 공유하며 모든 기가바이트를 모델 메모리로 사용할 수 있는 통합 메모리 풀에서 직접 작동하기 때문에 발생합니다.

알아둘 만한 품질상의 미세한 차이가 하나 있습니다. 4비트(4-bit)에서 GGUF의 Q4_K_M은 각 레이어 내부에서 혼합 정밀도(Mixed precision)를 사용하므로, 단순한 4비트 MLX 양자화보다 품질을 약간 더 잘 유지할 수 있습니다. 작은 차이이지만, 메모리가 부족한 기기에서 공격적으로 양자화를 진행한다면 출력 결과에서 나타날 수 있는 부분입니다.

	GGUF	MLX
정의	휴대 가능한 단일 파일	Apple 프레임워크, safetensors 디렉토리
...

사람들이 흔히 오해하는 도구 지원 (Tool support)

어떤 형식을 선택할지는 이미 사용 중인 도구에 의해 부분적으로 결정됩니다.

LM Studio는 2024년 말부터 MLX 백엔드를 지원해 왔으며, 번들로 포함된 llama.cpp를 통해 GGUF도 실행합니다. 따라서 LM Studio를 사용한다면 모델별로 진정으로 선택권을 가질 수 있으며, M-시리즈 칩에서 MLX 빌드를 선택하는 것은 대개 공짜로 속도를 얻는 것과 같습니다.

Ollama는 오랫동안 llama.cpp의 Metal 경로를 통해 GGUF를 실행해 왔습니다. 0.19 프리뷰 버전에서는 약 두 배의 속도를 보고하는 선택적 MLX 백엔드를 추가했지만, 이는 통합 메모리(unified memory)가 32GB 이상인 Mac을 대상으로 합니다. 16GB 기기에서는 GGUF/Metal 경로를 유지해야 하므로, MLX 선택 문제는 아직 당신에게 해당되지 않습니다.

이 32GB라는 기준선은 단순한 벤치마크 수치보다 더 중요합니다. 많은 "MLX가 2배 더 빠르다"라는 주장들은 대다수의 사람들이 가지고 있지 않은 사양의 기기를 은연중에 가정하고 있습니다.

나중에 발목을 잡을 수 있는 휴대성(Portability)의 함정

MLX가 Apple 전용이라는 점은 상황이 바뀌기 전까지는 괜찮습니다. 만약 당신이 CUDA 폴백(fallback), Linux 서버, 또는 Windows 사용자를 필요로 할 수도 있는 무언가를 만들고 있는데, MLX만을 유일한 빌드로 배포했다면, 그러한 요구사항이 발생하는 날 압박감 속에서 다시 양자화(re-quantizing)를 진행해야 할 것입니다. GGUF였다면 그냥 실행되었을 것입니다.

이것이 진짜 결정 축이며, 속도에 관한 문제가 아닙니다. 이것은 당신의 설정(setup)이 얼마나 오래 지속되어야 하는지, 그리고 어디에서 실행되어야 하는지에 관한 문제입니다. 오직 당신의 MacBook에서만 실행될 주말 프로젝트라면 MLX의 속도 향상을 누리지 않을 이유가 없습니다. 하지만 단일 런타임(runtime)보다 더 오래 지속될 인프라라면 GGUF를 기본값으로 사용하거나, 두 가지 모두를 제공해야 합니다.

요약된 결정 사항

• 32GB 이상의 M-시리즈 Mac을 사용하는 개인 사용자: MLX를 선택하세요. 더 빠르고 가벼우며, 놓치게 될 손실도 없습니다.
• 16GB Mac을 사용하거나, 가장 단순한 경로를 원하는 경우: GGUF를 선택하세요. 어차피 GGUF 경로를 사용하게 될 가능성이 높으며, 휴대성(portability)은 공짜 보험과 같습니다.
• 크로스 플랫폼, 서버, 또는 나중에 CUDA가 필요할 수도 있는 모든 경우: GGUF를 선택하거나 둘 다 빌드하세요. 20%의 속도 향상을 위해 자신을 Apple 전용 환경에 가두지 마세요.
• 확신이 서지 않는 경우: GGUF를 선택하세요. 어디서나 실행되며, MLX 빌드가 필요하다는 것을 알게 되었을 때 언제든 나중에 추가할 수 있습니다.

솔직한 요약은 둘 다 좋으며, 최신 Mac에서는 동일한 도구를 사용하여 보통 몇 분 안에 각각을 시도해 볼 수 있다는 것입니다. 속도는 측정하기 쉬운 축이지만, 가장 먼저 최적화해야 할 축은 아닙니다. 휴대성은 그것이 사라졌을 때에만 비로소 깨닫게 되는 요소입니다.

AI의 도움을 받아 작성되었으며 사람이 편집하였습니다. 형식 세부 사항은 2026년 7월 기준의 공개 정보를 반영하며 빠르게 변하므로 (특히 Ollama의 MLX 백엔드는 아직 초기 단계입니다), 특정 수치에 의존하기 전에 각 도구의 최신 릴리스 노트를 확인하십시오.