개인용 로컬 LLM 추론의 새 기준, MLX

MLX는 개인용 로컬 LLM 추론에서 가장 현실적인 선택지 중 하나가 됐다. Mac mini M4 Pro 24GB에서 gemma-4-26b-a4b-it-4bit, gemma-4-31b-4bit, Qwen3.6-27B-4bit는 기본 설정으로 실행됐고, Qwen3.6-35B-A3B-4bit는 처음에는 Metal OOM으로 실패했지만 macOS wired memory limit를 조정하자 생성까지 성공했다. 다만 이 결과는 “Mac mini가 GPU 서버를 대체한다”는 뜻이 아니다. 개인용 추론과 작은 팀의 내부 자동화에는 MLX가 충분히 매력적이고, 기업용 대규모 서빙에는 여전히 NVIDIA Blackwell, NVFP4, vLLM 같은 서버 GPU 생태계가 더 적합하다.

최근 로컬 LLM을 개인 장비나 사무실의 작은 머신에 올려두려는 니즈가 커지고 있다. 외부 API로 보내기 어려운 문서가 있고, Slack bot이나 내부 자동화는 상시 실행되어야 하며, 개발 중에는 OpenAI 호환 API처럼 바로 붙일 수 있는 로컬 엔드포인트가 편하다. 이 글은 그 니즈에 대해 “Mac mini가 얼마나 좋은가”를 말하려는 글이 아니다. 더 정확한 질문은 이것이다. 개인용 로컬 추론에는 MLX가 어디까지 현실적이고, 기업용 추론 서버와는 어디서 갈라지는가?

MLX란 무엇인가

MLX는 Apple Silicon에서 효율적이고 유연한 머신러닝을 실행하기 위한 Apple의 배열 프레임워크다. MLX 공식 사이트는 MLX를 Apple Silicon용 machine learning array framework로 설명하고, 핵심 특징으로 NumPy와 유사한 API, unified memory 설계, CPU/GPU 멀티 디바이스 지원을 든다. 쉽게 말하면 Mac의 CPU와 GPU가 같은 메모리 풀에 접근하는 구조를 전제로 만든 프레임워크다.

이 unified memory 모델이 로컬 LLM에서는 중요하다. 일반적인 GPU 서버에서는 CPU 메모리와 GPU VRAM 사이의 이동을 신경 써야 한다. 반면 MLX에서는 배열이 unified memory에 있고, 어떤 디바이스에서 연산할지 지정하는 방식으로 동작한다. MLX 문서는 Apple Silicon에서 CPU와 GPU가 같은 메모리 풀에 직접 접근한다고 설명한다. 이 구조 덕분에 Mac에서도 4bit로 양자화된 20~30B급 모델을 비교적 단순하게 실행할 수 있다.

참고: MLX 공식 사이트, MLX Unified Memory 문서

MLX를 조금 더 기술적으로 보면

MLX의 실행 모델은 NumPy처럼 보이지만 내부적으로는 즉시 실행만 하는 단순 배열 라이브러리가 아니다. MLX는 lazy evaluation을 사용한다. 배열 연산을 작성하면 바로 계산을 끝내는 것이 아니라, 계산 그래프를 만들고 실제 값이 필요해지는 시점에 평가한다. 이 방식은 불필요한 중간 계산을 줄이고, 여러 연산을 더 효율적으로 묶어 실행할 여지를 만든다.

LLM 추론에서는 이 lazy evaluation이 prefill과 decode 루프에서 의미가 있다. 프롬프트를 한 번에 처리하는 prefill 단계에서는 큰 행렬 연산이 많고, 토큰을 하나씩 생성하는 decode 단계에서는 작은 연산이 반복된다. MLX는 이런 연산들을 Apple GPU stream에서 실행하고, 필요할 때 eval 또는 동기화 지점에서 실제 계산을 끝낸다. 따라서 벤치마크를 할 때는 단순히 함수 호출 시간을 보는 것이 아니라, 실제 평가가 끝나는 시점을 기준으로 봐야 한다.

MLX에는 function transform도 있다. grad, vmap, compile 같은 변환을 통해 같은 Python 함수를 미분하거나 벡터화하거나 컴파일할 수 있다. LLM 서빙만 놓고 보면 학습용 grad보다 compile과 메모리 관리가 더 중요하다. 반복되는 연산을 컴파일하고, KV cache를 양자화하고, prefill step size를 줄이면 같은 Mac에서도 peak memory와 지연 시간이 달라진다.

이번 실험의 OOM도 이 관점에서 이해할 수 있다. 모델 weight는 unified memory에 올라가고, generation 과정에서는 KV cache와 activation이 추가로 필요하다. 24GB Mac mini에서 Qwen 35B의 weight가 약 19GB에 가까워지자 기본 working set 한계를 넘었고, Metal command buffer가 insufficient memory로 실패했다. iogpu.wired_limit_mb를 올리자 실행된 것은 모델이 갑자기 작아져서가 아니라, macOS가 GPU가 붙잡아둘 수 있는 wired memory 한계를 더 넓게 허용했기 때문이다.

참고: MLX Lazy Evaluation, MLX Transforms, MLX Compilation

왜 지금 개인용 로컬 LLM인가

개인용 로컬 LLM은 cloud API를 완전히 대체하기보다, 반복적이고 민감도가 높은 작업을 가까운 장비에서 처리하는 보완재에 가깝다. 예를 들어 개인 문서 검색, 코드 리뷰 초안, 회의록 요약, 사내 Slack bot, 간단한 RAG 실험은 초고성능 GPU 서버보다 “항상 켜져 있고, 조용하고, 비용이 예측 가능한 장비”가 더 중요할 때가 많다.

Mac mini는 이 조건에 잘 맞는다. 전력 소모가 낮고 소음이 적으며, 책상 위나 사무실 한쪽에 두고 상시 구동하기 쉽다. 하지만 Mac mini가 항상 좋은 선택은 아니다. 동시 요청이 많거나, 긴 컨텍스트를 많이 쓰거나, SLA가 필요한 기업용 추론 서버라면 이야기가 달라진다. 그런 경우에는 vLLM, 멀티 GPU, Prometheus/Grafana, autoscaling, 저정밀 포맷 최적화가 가능한 NVIDIA 서버 생태계가 여전히 더 자연스럽다.

테스트 환경

테스트는 Mac mini M4 Pro 24GB에서 진행했다. 운영체제는 macOS 26.3.1, 칩은 Apple M4 Pro, CPU는 12코어 구성이다. Python은 3.12.13, mlx는 0.31.2, mlx-lm은 0.31.3, mlx-vlm은 0.4.4를 사용했다. 모델은 모두 Hugging Face의 mlx-community 변환본을 사용했다.

후보 모델: Dense와 MoE를 같이 봐야 한다

이번에 테스트한 모델은 4개다. 일부는 Dense 계열이고, 일부는 MoE, 즉 Mixture of Experts 구조다.

Dense 모델은 대부분의 파라미터가 매 토큰 계산에 관여한다. MoE 모델은 전체 expert weight는 메모리에 올라가지만, 토큰 생성 시 일부 expert만 활성화된다. 그래서 MoE는 “메모리를 덜 먹는 마법”이 아니다. 24GB Mac mini에서는 전체 weight가 이미 메모리 대부분을 차지하면, MoE라도 KV cache와 activation을 위한 공간은 별도로 필요하다. 대신 generation 단계에서는 활성 연산량이 줄어 빠르게 보일 수 있다.

벤치마크 결과

테스트 결과는 명확했다. 15~17GB급 4bit 모델은 기본 설정으로 실행됐다. 19GB급 Qwen 35B MoE는 기본 상태에서 OOM이 났지만, wired memory limit를 조정하면 실행됐다.

처음 Qwen 35B를 실행했을 때의 실패 로그는 다음과 같았다.

[WARNING] Generating with a model that requires 19456 MB
which is close to the maximum recommended size of 18186 MB.
...
[METAL] Command buffer execution failed: Insufficient Memory

이 실패는 모델이 깨졌거나 MLX가 지원하지 않아서가 아니었다. Mac mini 24GB에서 MLX가 보는 기본 max_recommended_working_set_size는 약 18.2GiB였고, Qwen 35B 모델 자체가 약 19.0GiB를 요구했다. 모델 weight만으로 이미 권장 working set을 넘는 상황에서 KV cache와 activation까지 들어가니 Metal OOM이 난 것이다.

Qwen 35B를 어떻게든 돌리는 방법

Qwen 35B는 기본 설정에서는 실패했지만, macOS의 wired memory limit를 올리면 실행됐다. MLX 문서도 큰 모델에서 wired limit를 조정할 수 있다고 안내한다. 단, 이 값은 전체 메모리보다 작아야 하고, 시스템 안정성을 해칠 수 있으므로 운영 환경에서는 보수적으로 접근해야 한다.

테스트에서는 다음처럼 설정했다.

sudo sysctl iogpu.wired_limit_mb=22000

설정 후 MLX가 보는 max_recommended_working_set_size는 약 23.1GB로 올라갔다. 그 상태에서 Qwen3.6-35B-A3B-4bit는 동일한 벤치 조건으로 생성까지 성공했다. 다만 이 결과를 “운영 가능”으로 바로 해석하면 위험하다. generation 속도는 83 tok/s로 매우 빠르지만, prompt 처리 속도는 5.8 tok/s로 낮았다. 짧은 대화형 챗봇에서는 빠르게 느껴질 수 있지만, 긴 문서 요약이나 RAG에서는 병목이 다르게 나타난다.

참고: MLX set_wired_limit 문서

같은 질문으로 응답 품질 비교

속도만으로 모델을 고르면 안 된다. 로컬 서버는 결국 사용자가 보는 답변 품질이 중요하다. 같은 질문을 네 모델에 넣고 응답을 비교했다.

질문은 다음과 같았다.

Mac mini M4 Pro 24GB에서 MLX로 로컬 LLM 서버를 운영하려고 한다.
아래 형식으로 한국어 4줄만 출력해줘.
장점1: ...
장점2: ...
한계1: ...
한계2: ...

Gemma 4 26B A4B IT 4bit

장점1: M4 Pro의 강력한 통합 메모리 대역폭
장점2: MLX 최적화로 효율적인 추론 속도
한계1: 24GB 메모리로 대규모 모델 구동 제한
한계2: GPU 가속 한계로 인한 학습 속도 제약

Gemma 4 26B A4B IT는 형식 준수가 좋고 속도도 안정적이었다. 68.6 tok/s 수준으로 짧은 챗봇 응답에는 충분히 빠르다. 다만 마지막 한계에서 “학습 속도”를 언급한 것은 로컬 추론 서버라는 맥락에서는 살짝 빗나간 답변이다. 그래도 24GB Mac mini에서 상시 서버 후보를 하나만 고른다면 가장 먼저 볼 모델이다.

Gemma 4 31B 4bit

답변:
장점1: M4 Pro의 강력한 성능으로 빠른 추론 속도 제공
장점2: 24GB 메모리로 대규모 모델 로딩 및 처리 가능
한계1: GPU가 없어 CUDA 가속 불가능, CPU 연산만 가능
한계2: 메모리 용량 제한으로 매우 큰 모델은 로딩 어려움

Gemma 4 31B는 실행은 됐지만 실사용 후보로는 애매했다. generation 속도는 13.5 tok/s로 낮고, 답변에는 “CPU 연산만 가능”이라는 잘못된 표현이 들어갔다. MLX는 Apple GPU와 Metal을 활용한다. 또한 이 모델은 it가 아닌 base 성격이라 프롬프트 반복도 나타났다. 비교군으로는 의미가 있지만, 챗 서버로 바로 쓰기에는 부적합했다.

Qwen3.6 27B 4bit

장점1: Apple Silicon 최적화로 저전력 고효율 추론 가능
장점2: 24GB 메모리로 중형 모델 원활한 로딩 및 실행
한계1: 24GB 한계로 대형 모델 실행 시 성능 저하 발생
한계2: CPU 기반 연산으로 GPU 대비 추론 속도가 느림

Qwen3.6 27B는 문장 품질이 비교적 좋고, 지시 형식도 잘 지켰다. 다만 여기서도 “CPU 기반 연산”이라는 틀린 표현이 나왔다. 속도는 15.8 tok/s 수준이라 빠른 챗봇보다는 정확한 답변이 중요한 내부 도구에 더 어울린다. 15GB급 모델이라 메모리 여유는 Gemma 31B보다 낫지만, generation 속도는 Gemma 26B MoE보다 훨씬 낮았다.

Qwen3.6 35B A3B 4bit

장점1: M4 Pro의 높은 메모 대역폭으로 추론 속도가 빠릅니다.
장점2: 24GB 통합 메모리로 모델 적재와 실행이 효율적입니다.
한계1: 24GB 제한으로 대형 모델(70B 이상) 로딩이 어렵습니다.
한계2: 메모리 부족 시 디스크 스왐핑으로 성능이 급격히 저하됩니다.

Qwen3.6 35B A3B는 답변이 가장 자연스러웠고 generation 속도도 가장 높았다. MoE 구조의 장점이 잘 드러난다. 하지만 24GB Mac mini에서는 기본 설정으로는 OOM이었고, iogpu.wired_limit_mb 조정이 필요했다. 따라서 “가장 빠른 모델”이지만 “가장 편한 운영 모델”은 아니다.

MLX와 NVFP4는 경쟁 관계라기보다 역할 분담이다

MLX와 NVIDIA NVFP4는 같은 문제를 다른 규모에서 푼다. MLX는 개인용 또는 작은 팀의 로컬 추론을 쉽게 만든다. 반면 NVFP4는 NVIDIA Blackwell 세대에서 저정밀 추론을 효율적으로 처리하기 위한 포맷이며, vLLM 같은 추론 서버와 결합했을 때 기업용 대규모 서빙에 더 잘 맞는다. 듀얼 Blackwell GPU 환경에서 NVFP4 모델을 vLLM으로 실제 서빙하면서 겪은 운영 노하우는 NVFP4 + vLLM 듀얼 Blackwell 서빙 가이드에 정리해두었다.

NVFP4는 “엔진”이 아니라 Blackwell에서 가속되는 4비트 부동소수점 포맷이다. NVIDIA는 NVFP4가 FP16 대비 모델 메모리를 크게 줄이고, 정확도 손실을 줄이기 위해 block scaling 구조를 사용한다고 설명한다. 이런 장점은 개인용 Mac mini보다는 대량 요청, 긴 컨텍스트, 멀티 테넌트, 모니터링과 SLA가 필요한 기업 환경에서 더 큰 의미를 가진다.

참고: NVIDIA NVFP4 소개

M5 세대가 오면 무엇이 달라질까

2026년 5월 기준으로 M5 Pro와 M5 Max는 루머가 아니라 Apple이 이미 2026년 3월 발표한 확정 제품이다. Apple은 M5 Pro가 최대 18코어 CPU, 최대 20코어 GPU, 최대 64GB unified memory, 최대 307GB/s 메모리 대역폭을 지원한다고 밝혔다. M5 Max는 최대 40코어 GPU, 최대 128GB unified memory, 최대 614GB/s 메모리 대역폭을 지원하며, Apple은 이 대역폭 증가가 LLM token generation에도 도움이 된다고 설명했다.

다만 Mac mini M5/M5 Pro는 아직 미확정이다. Macworld 등은 2026년 Mac mini에 M5와 M5 Pro가 적용될 가능성을 보도하고 있지만, 2026년 5월 6일 현재 Apple이 Mac mini M5를 공식 발표한 상태는 아니다. 따라서 글을 쓰는 시점에서는 “M5 세대의 방향은 확인됐고, Mac mini 적용은 유력하지만 아직 루머”라고 표현하는 것이 정확하다.

M5 Mac mini가 실제로 나오면 개인용 로컬 LLM에는 세 가지 변화가 생길 수 있다. 첫째, 메모리 대역폭이 올라가 prompt 처리와 generation 모두 개선될 가능성이 있다. 둘째, 64GB unified memory 구성이 더 일반화되면 20GB급 MoE 모델을 더 안정적으로 운영할 수 있다. 셋째, Apple GPU 코어의 AI 가속 기능이 강화되면 MLX가 이를 활용하는 폭도 넓어질 수 있다. 하지만 이것이 기업용 NVIDIA 서버를 대체한다는 뜻은 아니다. M5는 개인용 로컬 추론의 상한을 올리고, Blackwell/NVFP4는 기업용 서빙의 효율을 올리는 방향에 가깝다.

참고: Apple M5 Pro/Max 발표, Macworld Mac mini M5 루머 정리

OpenAI 호환 서버로 띄워보기

로컬 LLM이 실제로 쓸모 있으려면 Python 스크립트 한 번 실행으로 끝나면 안 된다. Slack bot이나 내부 자동화에 붙이려면 OpenAI 호환 API 서버로 떠야 한다. mlx_vlm server는 /v1/models, /v1/chat/completions 형태의 API를 제공한다.

Gemma 4 26B A4B IT를 다음처럼 띄웠다.

python -m mlx_vlm server \
  --model models/gemma-4-26b-a4b-it-4bit \
  --host 127.0.0.1 \
  --port 8080 \
  --prefill-step-size 512 \
  --kv-bits 4 \
  --max-kv-size 4096 \
  --trust-remote-code

/v1/chat/completions 호출도 정상 동작했다.

{
  "input_tokens": 32,
  "output_tokens": 41,
  "total_tokens": 73,
  "prompt_tps": 25.07,
  "generation_tps": 69.97,
  "peak_memory": 15.71
}

여기서 작은 함정이 있었다. 서버를 로컬 경로 models/gemma-4-26b-a4b-it-4bit로 띄웠다면, 요청 JSON의 model 값도 같은 로컬 경로를 쓰는 편이 안전하다. Hugging Face repo id를 보내면 서버가 다른 모델 요청으로 판단해 다시 다운로드를 시도할 수 있었다.

이번 실험에서 얻은 운영 기준

개인용 로컬 LLM에서는 최고 성능보다 “충분히 빠르고, 안정적으로 켜져 있고, 관리가 쉬운가”가 중요하다. 이 기준에서는 15~17GB급 4bit instruct 모델이 가장 현실적이었다. 이 구간은 모델을 로드하고도 KV cache와 activation을 위한 여유가 남는다. gemma-4-26b-a4b-it-4bit가 이 sweet spot에 가장 가까웠다.

18GB 이상부터는 경계 구간이다. gemma-4-31b-4bit는 실행은 됐지만 MLX가 큰 모델 경고를 냈고, generation 속도와 답변 품질도 아쉬웠다. 이 구간에서는 모델 이름의 파라미터 수보다 실제 변환본 크기와 instruct 여부가 더 중요하다.

19~20GB 모델은 튜닝 없이는 위험하다. Qwen3.6-35B-A3B-4bit는 wired limit 조정 후 성공했지만, 기본값에서는 OOM이었다. 상시 서버로 쓸 거라면 시스템 메모리 압박, 긴 컨텍스트 요청, 동시 요청, swap 발생 여부를 추가로 테스트해야 한다.

결론: 개인용은 MLX, 기업용은 NVIDIA

MLX는 Mac mini를 기업용 GPU 서버의 대체재로 만들지는 않는다. 대신 개인이나 작은 팀이 로컬 LLM 추론을 일상적으로 사용할 수 있게 만드는 가장 현실적인 경로에 가깝다. CUDA 서버를 세팅하지 않아도, 24GB Mac mini에서 30B급 4bit 모델을 실제 API 서버로 띄울 수 있다는 점은 분명히 의미가 있다.

이번 실험에서 가장 실용적인 선택은 gemma-4-26b-a4b-it-4bit였다. 속도, 메모리, 형식 준수의 균형이 좋았다. Qwen 35B MoE는 더 빠르고 답변도 자연스러웠지만, 24GB에서는 wired limit 조정이 필요해 운영 난도가 올라간다. Gemma 31B와 Qwen 27B는 비교군으로는 의미가 있었지만, 각각 품질과 속도에서 아쉬움이 있었다.

개인용 로컬 추론의 새 기준은 MLX라고 말할 수 있다. 하지만 기업용 추론 인프라의 기준은 여전히 NVIDIA GPU 서버다. 둘은 같은 시장을 완전히 대체하는 관계가 아니라, 서로 다른 규모와 목적을 담당하는 선택지다. 같은 문제를 기업용 규모에서 어떻게 풀었는지는 NVIDIA Blackwell 전용 추론 엔진 NVFP4를 활용한 vLLM 로컬 모델 서빙에서 더 자세히 다뤘다.

부록: 실험 명령

python mlx_single_bench.py \
  --model models/gemma-4-26b-a4b-it-4bit \
  --prompt "Mac mini M4 Pro 24GB에서 MLX로 로컬 LLM 서버를 운영하려고 한다..." \
  --max-tokens 96 \
  --prefill-step-size 512 \
  --kv-bits 4 \
  --max-kv-size 4096 \
  --trust-remote-code

Qwen 35B를 24GB에서 테스트할 때 사용한 wired limit 조정:

sudo sysctl iogpu.wired_limit_mb=22000

테스트 후 원복:

sudo sysctl iogpu.wired_limit_mb=0

참고 자료

• Plaid Labs 기술 블로그 — NVFP4 + vLLM 듀얼 Blackwell 서빙 가이드 (기업용 시점)

• Plaid Labs 기술 블로그 — 오픈소스 LLM 생태계 2026: DeepSeek-V4·Qwen3.6·GLM-5.1 (모델 동향)

• Plaid Labs 기술 블로그 — Speculative Decoding이란 무엇인가? (추론 가속 시리즈 4편)

• Plaid Labs 기술 블로그 — LLM을 작게 만드는 여러가지 압축 기술들 (BitNet · AutoRound · TurboQuant · REAP)

• MLX 공식 사이트

• MLX Unified Memory 문서

• MLX set_wired_limit 문서

• NVIDIA NVFP4 소개

• Apple M5 Pro/Max 발표

• Macworld Mac mini M5 루머 정리