GGUF는 llama.cpp 계열이 쓰는 범용 양자화 형식이고, MLX는 애플 실리콘 전용 프레임워크의 형식입니다. 맥에서는 둘 다 돌아가는데 성격이 다릅니다. 같은 M5 Max 128GB에서 측정해 보니 생성 속도와 프롬프트 처리 속도가 형식에 따라 정반대로 갈렸습니다. 숫자부터 보겠습니다.
같은 기계에서 측정한 결과
생성 속도만 보면 MLX가 유리해 보입니다. 그런데 프롬프트 처리 속도를 같이 보면 그림이 뒤집힙니다.
| 모델 | 형식 | 크기 | 생성 tok/s | 프롬프트 tok/s |
|---|---|---|---|---|
| llama3.1 8B | GGUF | 4.9GB | 99.9 | 994.4 |
| qwen3.5 9B | GGUF | 6.6GB | 79.0 | 595.0 |
| phi4 14B | GGUF | 9.1GB | 55.2 | 484.9 |
| mistral-small 24B | GGUF | 14.3GB | 35.4 | 621.1 |
| gemma4 26B | MLX bf16 | 52.5GB | 78.9 | 5.3 |
| qwen3.6 35B-a3b | MLX mxfp8 | 37.7GB | 97.0 | 26.5 |
MLX bf16 쪽 프롬프트 처리가 초당 5.3토큰입니다. GGUF 모델들이 484에서 994 사이인 것과 비교하면 100배 가까운 차이입니다. 생성은 78.9 tok/s로 빠른데 입력을 읽는 단계가 극단적으로 느립니다.
이 표는 형식 자체의 우열이 아닙니다. MLX 쪽은 bf16·mxfp8로 양자화가 거의 안 된 52.5GB·37.7GB 파일이고, GGUF 쪽은 전부 4비트급입니다. 공정한 대조가 아니라 ‘이 조합으로 받으면 이렇게 된다’는 실측 기록으로 읽으십시오.
그래서 무엇이 갈리나
프롬프트 처리 속도는 긴 입력을 넣을 때만 체감됩니다. 짧은 질문 한두 줄이면 어느 쪽이든 차이를 못 느낍니다. 반대로 문서를 통째로 붙여넣거나 코드베이스를 넣는 작업이면 여기서 전부 결정됩니다.
MLX bf16 : 8,000 ÷ 5.3 = 1,509초 = 약 25분
8,000토큰짜리 문서 하나를 넣는 데 드는 시간입니다. 같은 작업이 8초와 25분으로 갈립니다.
어떤 형식을 받아야 하나
| 상황 | 권장 | 이유 |
|---|---|---|
| 짧은 대화 위주 | 둘 다 | 체감 차이 없음 |
| 긴 문서 요약 | GGUF 4비트 | 프롬프트 처리가 빠름 |
| 메모리가 넉넉하고 품질 우선 | MLX | 고정밀 가중치 유지 |
| 맥이 아닌 환경 | GGUF | MLX는 애플 실리콘 전용 |
| 도구 호환성 | GGUF | 지원 범위가 넓음 |
정리하면 처음이라면 GGUF 4비트부터가 안전합니다. 파일이 작고 어느 도구에서나 열리고 프롬프트 처리가 빠릅니다. MLX는 메모리가 충분하고 애플 실리콘에서 고정밀 가중치를 쓰고 싶을 때의 선택지입니다.
받을 때 형식을 지정하는 법
LM Studio는 플래그로 강제합니다. 아무것도 안 주면 시스템이 지원하는 형식만 후보로 잡습니다.
lms get qwen/qwen3.5-9b --gguf
lms get qwen/qwen3.5-9b --mlx허깅페이스에서 직접 받을 때는 저장소 이름으로 구분됩니다. 이름 끝에 GGUF가 붙은 저장소가 GGUF 전용이고, MLX 커뮤니티가 올린 저장소는 보통 MLX라고 표시돼 있습니다.
hf download Qwen/Qwen2.5-0.5B-Instruct-GGUF qwen2.5-0.5b-instruct-q4_k_m.gguf파일명 끝의 q4_k_m이 양자화 등급입니다. 숫자가 비트 수를 뜻하므로 q4는 4비트, q8은 8비트입니다. 숫자가 작을수록 파일이 작고 빠르지만 품질이 떨어집니다. 받는 방법 전반은 허깅페이스 사용법에 정리돼 있습니다.
양자화 등급은 어디까지 내려도 되나
형식을 정했으면 다음은 등급입니다. 같은 모델이라도 q4와 q8은 파일 크기와 메모리 요구량이 두 배 가까이 차이납니다.
| 등급 | 비트 | 14B 기준 가중치 | 용도 |
|---|---|---|---|
| q3_k_m | 3비트 | 약 6.3GB | 메모리가 정말 부족할 때 |
| q4_k_m | 4비트 | 약 8.2GB | 기본 선택 |
| q5_k_m | 5비트 | 약 9.8GB | 여유가 있을 때 |
| q8_0 | 8비트 | 약 15GB | 품질 우선 |
실무 기준은 간단합니다. q4_k_m부터 시작하고, 메모리가 남으면 q5나 q8로 올리고, 모자라면 q3로 내립니다. q3 아래로는 한국어 출력에서 어색함이 눈에 띄기 시작하므로 권하지 않습니다.
등급을 올렸을 때 얻는 것이 크지 않다는 점도 알아두시면 좋습니다. q4에서 q8로 가면 메모리는 두 배가 되는데 체감 품질 향상은 그만큼이 아닙니다. 그 메모리로 한 등급 큰 모델의 q4를 돌리는 쪽이 보통 더 낫습니다. 14B q8과 24B q4 중에는 후자가 유리하다는 뜻입니다.
자주 묻는 질문
MLX가 무조건 빠른 것 아니었나요?
생성 단계는 빠를 수 있습니다. 측정에서도 MLX 35B가 97.0 tok/s로 GGUF 24B의 35.4 tok/s보다 빨랐습니다. 다만 프롬프트 처리는 반대였습니다.
윈도우에서 MLX를 쓸 수 있나요?
없습니다. MLX는 애플 실리콘 전용입니다. 윈도우나 리눅스에서는 GGUF나 safetensors를 쓰셔야 합니다.
GGUF와 safetensors는 뭐가 다른가요?
safetensors는 파이썬 transformers가 쓰는 원본 가중치 형식이고, GGUF는 llama.cpp 계열이 쓰는 양자화 배포 형식입니다. 용도가 다릅니다.
q4와 q8 중 뭘 받아야 하나요?
메모리가 빠듯하면 q4, 여유가 있으면 q8입니다. 같은 모델이라도 q8은 파일이 약 두 배이고 그만큼 VRAM을 더 씁니다.
답글 남기기