애플의 MLX 프레임워크: 최고의 AI 속도

laptop_mac macOS Sonoma Intermediate schedule 8 min read

by Alex Rivera • May 14, 2024

Step 1 MLX란 무엇이며 왜 중요한가?

Mac에서 대형 언어 모델을 실행하면서 GPU는 유휴 상태인데 CPU 팬이 돌아가는 것을 경험해본 적이 있다면, MLX가 해결하기 위해 만들어진 문제를 이미 이해하고 있는 것입니다.

MLX는 Apple의 머신러닝 연구팀이 개발하여 2023년 말에 출시한 오픈소스 배열 프레임워크입니다. MLX의 핵심 목적은 단 하나입니다: Apple Silicon에서의 머신러닝을 빠르게 만드는 것. 단순히 "그럭저럭" 빠른 수준이 아니라, 추론 작업에서 전용 GPU 워크스테이션과 실질적으로 경쟁할 수 있는 수준으로 말입니다.

통합 메모리의 이점

MLX의 핵심 아키텍처 설계 원칙은 Apple Silicon의 통합 메모리 아키텍처(UMA)입니다. 전통적인 컴퓨팅 환경에서는 CPU와 GPU가 별도의 메모리 풀을 유지합니다. 데이터는 두 메모리 사이에서 명시적으로 복사되어야 하며, 이는 시간과 전력을 모두 소모하는 병목 현상을 야기합니다.

Apple Silicon은 이를 완전히 제거합니다:

Traditional Architecture:
┌──────────┐    PCIe Bus    ┌──────────┐
│  CPU RAM │ ◄────────────► │  GPU RAM │
│  (DDR5)  │   ~50 GB/s    │  (GDDR6) │
└──────────┘                └──────────┘

Apple Silicon (M-Series):
┌─────────────────────────────────────┐
│         Unified Memory Pool         │
│  ┌──────────┐      ┌─────────────┐  │
│  │   CPU    │      │  GPU Cores  │  │
│  │  Cores   │      │  (up to 76) │  │
│  └──────────┘      └─────────────┘  │
│         ~400 GB/s bandwidth         │
└─────────────────────────────────────┘

MLX는 이 토폴로지를 활용하기 위해 처음부터 설계되었습니다. 텐서는 CPU 코어, GPU 코어, 뉴럴 엔진 등 모든 연산 유닛이 동시에 접근할 수 있는 단일 주소 공간에 존재하며, 복사 오버헤드가 전혀 없습니다.

LLM 추론에서 이것이 중요한 이유

대형 언어 모델을 실행하는 것은 근본적으로 메모리 대역폭 문제이지, 연산 능력의 문제가 아닙니다. 트랜스포머의 순전파는 순수 FLOP 수가 아니라, 메모리에서 연산 유닛으로 가중치를 얼마나 빠르게 로드할 수 있는지에 의해 병목이 발생합니다.

위 표에서 나타나지 않는 점은, RTX 4090은 450W TDP의 데스크톱 시스템을 필요로 한다는 것입니다. M4 Max MacBook Pro는 ML 전체 부하 상태에서 약 60W를 소비합니다. 전력 대비 성능 측면에서 놀라운 수준입니다.

MLX와 대안들 비교

MLX가 등장하기 전, Mac에서 로컬로 LLM을 실행하기 위한 지배적인 솔루션은 llama.cpp였습니다 — Metal 커널과 CPU 벡터 연산을 수동으로 최적화한 훌륭한 C++ 구현체입니다. 잘 작동하기는 하지만, 본래 설계 대상이 아닌 하드웨어에 맞춰 만들어진 근본적인 우회책에 불과합니다.

MLX는 대조적으로, 하드웨어를 설계한 사람들이 직접 설계한 프레임워크입니다. Apple의 엔지니어들은 M 시리즈 메모리 서브시스템, 캐시 계층 구조, GPU 마이크로아키텍처에 대한 완전한 이해를 바탕으로 MLX를 개발했습니다. 그 결과, matmul, quantized_matmul, 어텐션 커널과 같은 연산들이 네이티브 Metal 컴퓨트 셰이더를 갖춘 일급 시민(first-class citizen)으로 구현된 프레임워크가 탄생했습니다 — 뒤늦게 추가된 기능이 아닙니다.

MLX를 탁월하게 만드는 추가적인 아키텍처 설계 결정들:

• 지연 평가(Lazy evaluation): 결과가 명시적으로 필요할 때까지 연산이 실행되지 않아, 자동 커널 융합과 그래프 최적화가 가능합니다.
• 자동 미분(Automatic differentiation): 순방향 및 역방향 모드 AD를 모두 완전히 지원하여, MLX를 단순한 추론뿐만 아니라 파인튜닝에도 적합하게 만듭니다.
• 파이써닉(Pythonic) API: 인터페이스가 의도적으로 NumPy와 호환되도록 설계되어, ML 실무자들의 학습 곡선을 크게 줄여줍니다.
• mlx-lm 생태계: 언어 모델 추론, 양자화, LoRA 파인튜닝을 위해 MLX 위에 구축된 고수준 라이브러리입니다.

결론: Apple Silicon 하드웨어를 보유하고 있으면서 로컬 AI 추론에 MLX를 사용하지 않고 있다면, 상당한 성능을 낭비하고 있는 것입니다. 이 가이드의 나머지 부분에서는 그 성능을 정확히 어떻게 활용할 수 있는지 보여드리겠습니다.

Step 2 사전 요구사항 및 Python 환경 설정

MLX를 시작하기 전에, 하드웨어와 소프트웨어 스택이 최소 요구사항을 충족하는지 확인하세요. MLX는 Apple Silicon 전용입니다 — 이는 협상의 여지가 없습니다. 이 프레임워크는 M 시리즈 칩에서만 찾을 수 있는 통합 메모리 아키텍처와 Neural Engine을 활용하기 위해 처음부터 설계되었습니다.

하드웨어 요구사항

⚠️ 중요: MLX는 Intel 기반 Mac에서 실행되지 않습니다. x86_64 Mac에서 설치를 시도하면 패키지는 설치되지만 런타임 시 Metal 백엔드 초기화에 실패합니다.

Silicon 확인하기

패키지 매니저를 건드리기 전에, Apple Silicon에서 실행 중인지 확인하세요:

uname -m

예상 출력:

arm64

상세한 칩 정보도 확인할 수 있습니다:

system_profiler SPHardwareDataType | grep "Chip"

Chip: Apple M3 Max

Python 버전 요구사항

MLX는 Python 3.9 이상이 필요합니다. Python 3.11이 현재 최적의 선택입니다 — Apple Silicon에서 가장 낮은 인터프리터 오버헤드로 최고의 성능을 제공하며, 모든 주요 MLX 의존성이 안정적인 wheel을 유지하고 있습니다.

python3 --version
# Python 3.11.x preferred

전용 가상 환경 설정

절대로 MLX를 시스템 Python에 설치하지 마세요. macOS에 번들로 제공되는 Python과의 의존성 충돌은 미묘하고 해결하기 까다로운 오류를 유발할 수 있습니다. 깨끗한 가상 환경을 사용하세요.

옵션 A: venv 사용 (경량, 내장)

# Create the environment
python3.11 -m venv ~/envs/mlx-env

활성화

source ~/envs/mlx-env/bin/activate

Python 경로 확인

which python

~/envs/mlx-env/bin/python

#### 옵션 B: `conda` / `miniforge` 사용 (ML 워크플로우에 권장)

Miniforge는 ARM 네이티브 conda와 함께 제공되며, Apple Silicon에서의 본격적인 ML 개발을 위해 선호되는 선택입니다:

```bash
# Miniforge 설치 (아직 설치되지 않은 경우)
brew install miniforge

# 전용 MLX conda 환경 생성
conda create -n mlx-env python=3.11 -y

# 활성화
conda activate mlx-env

프로 팁: conda-forge를 기본 채널로 사용하세요. 대부분의 과학 컴퓨팅 패키지에 대해 ARM64 네이티브 빌드를 제공하여, 성능을 은밀하게 저하시킬 수 있는 Rosetta 2 변환 오버헤드를 방지합니다.

pip 및 핵심 도구 업그레이드

활성화된 환경 내에서, ML 패키지를 설치하기 전에 기본 툴체인을 업그레이드하세요:

pip install --upgrade pip setuptools wheel

이는 MLX가 가끔 arm64 플랫폼 태그에서 올바르게 해석하기 위해 최신 pip 버전(≥23.x)이 필요한 바이너리 휠을 제공하기 때문에 특히 중요합니다.

Metal 및 Accelerate 가용성 확인

MLX는 GPU 작업을 위해 Apple의 Metal GPU API와 BLAS 연산을 위한 Accelerate 프레임워크에 의존합니다. 이들은 macOS와 함께 제공되며 별도 설치가 필요하지 않지만, Python을 통해 Metal에 접근 가능한지 확인할 수 있습니다:

python3 -c "import subprocess; subprocess.run(['system_profiler', 'SPDisplaysDataType'])"

또는, 다음 섹션에서 MLX를 설치한 후, 아래의 한 줄 명령으로 Metal 백엔드가 활성화되어 있는지 확인할 수 있습니다:

import mlx.core as mx
print(mx.default_device())  # Device(gpu, 0) — Metal 백엔드 확인

Device(cpu, 0)이 표시되면, Metal 드라이버가 올바르게 인식되지 않는 것입니다 — 이는 일반적으로 macOS 버전 불일치 또는 Xcode Command Line Tools 설치 손상을 나타냅니다.

Xcode Command Line Tools 설치

여러 MLX 종속성은 설치 시 네이티브 확장을 컴파일합니다. Xcode Command Line Tools가 있는지 확인하세요:

xcode-select --install

설치 확인:

xcode-select -p
# /Library/Developer/CommandLineTools

환경이 깔끔하고, Python이 3.11로 고정되어 있으며, Metal이 확인되고, pip가 최신 상태라면, MLX 자체를 설치할 준비가 된 것입니다.

Step 3 1단계: MLX 및 MLX-LM 설치

Python 환경이 올바르게 구성되었으면, 이제 핵심 라이브러리를 설치할 차례입니다. MLX는 표준 Python 패키지로 제공되지만, 무작정 pip install을 실행하여 환경을 망가뜨리기 전에 이해할 가치가 있는 몇 가지 미묘한 점이 있습니다.

핵심 패키지 구조

Apple의 MLX 생태계는 여러 개의 목적별 패키지로 나뉩니다. LLM 추론을 위해서는 두 가지 주요 구성 요소가 필요합니다:

mlx-lm 패키지는 테스트된 정확한 버전의 mlx를 자동으로 설치하지 않으므로, 버전 고정이 중요합니다. 이에 대한 자세한 내용은 아래에서 설명합니다.

설치

먼저 가상 환경을 활성화하세요. 사전 요구 사항 섹션을 건너뛰었다면, 최소 요구 사항은 Apple Silicon Mac (M1/M2/M3/M4 시리즈)에서 Python 3.9 이상입니다. MLX는 Intel Mac에서 실행되지 않습니다 — 이 프레임워크는 구조적으로 통합 메모리 아키텍처(Unified Memory Architecture)에 결합되어 있습니다.

# Upgrade pip first — older pip versions mishandle Apple's binary wheels
pip install --upgrade pip

# Install the core MLX framework
pip install mlx

# Install the LLM interface layer
pip install mlx-lm

최신 나이틀리 빌드를 원하는 사용자(미출시 모델 지원 테스트에 유용):

pip install mlx-nightly mlx-lm

⚠️ mlx 안정 버전과 mlx-nightly를 혼용하지 마세요. 두 버전 간의 ABI는 호환되지 않으며, 런타임에서 알 수 없는 임포트 오류가 발생할 수 있습니다.

설치 확인

설치 직후 이 검증 블록을 실행하세요. 이 중 하나라도 실패하면, 환경에 문제가 있는 것이며 나중에 더 디버깅하기 어려운 오류로 이어질 수 있습니다.

# verify_mlx.py
import mlx.core as mx
import mlx_lm

# Check MLX version
print(f"MLX version: {mx.__version__}")

# Confirm we're targeting the GPU (not CPU fallback)
print(f"Default device: {mx.default_device()}")

# Confirm mlx-lm loaded
print(f"mlx-lm version: {mlx_lm.__version__}")

# Quick tensor operation on GPU
a = mx.array([1.0, 2.0, 3.0])
b = mx.array([4.0, 5.0, 6.0])
print(f"Dot product (GPU): {mx.inner(a, b).item()}")

예상 출력:

MLX version: 0.16.x
Default device: Device(gpu, 0)
mlx-lm version: 0.19.x
Dot product (GPU): 32.0

중요 체크포인트: Default device가 Device(cpu, 0)을 반환하면, MLX가 Metal GPU 백엔드에 접근하지 못하고 있는 것입니다. 이는 일반적으로 네이티브가 아닌 Python 바이너리(예: Rosetta로 번역된 x86 Python)를 실행 중임을 의미합니다. 다음 명령어로 확인하세요:

python -c "import platform; print(platform.machine())"
# Must output: arm64

선택 사항: 개발용 설치

MLX에 기여하거나 내부를 패치해야 하는 경우, 소스에서 설치하세요:

git clone https://github.com/ml-explore/mlx.git
cd mlx
pip install -e .

git clone https://github.com/ml-explore/mlx-lm.git
cd mlx-lm
pip install -e .

소스에서 빌드하려면 Xcode Command Line Tools와 CMake ≥ 3.26이 필요합니다:

xcode-select --install
brew install cmake

의존성 스냅샷

다음은 2025년 중반 기준, 재현 가능한 추론 환경을 위한 깔끔한 requirements.txt입니다:

mlx>=0.16.0
mlx-lm>=0.19.0
huggingface-hub>=0.23.0
transformers>=4.41.0
sentencepiece>=0.2.0
protobuf>=3.20.0

프로덕션 워크로드에서는 이 버전들을 고정하세요. MLX 팀은 프레임워크의 빠른 개발 속도로 인해 중대한 API 변경 사항을 자주 배포하며, 자동 업그레이드가 생성 파라미터나 양자화 설정을 무효화할 수 있습니다.

라이브러리가 확인되고 작동 중임을 확인했으므로, 다음 단계는 HuggingFace에서 적절하게 포맷된 MLX 모델을 다운로드하는 것입니다. 이를 위해서는 모든 GGUF 또는 Safetensors 모델이 기본적으로 MLX와 호환되지는 않는 이유를 이해해야 합니다.

Step 4 Step 2: HuggingFace에서 최적화된 MLX 모델 다운로드하기

추론을 실행하기 전에, MLX 런타임에 맞게 특별히 포맷되고 양자화된 모델이 필요합니다. MLX는 표준 모델을 즉석에서 변환할 수 있지만, 가장 높은 성능을 내는 방법은 HuggingFace에서 사전 변환되고 사전 양자화된 MLX 네이티브 모델을 직접 다운로드하는 것입니다. MLX 커뮤니티 — 주로 HuggingFace의 활발한 mlx-community 조직이 주도하는 — 는 수백 개의 인기 모델을 변환하고 양자화하는 작업을 이미 수행해 두었습니다.

MLX 모델 포맷 이해하기

MLX 모델은 config.json 및 tokenizer_config.json과 함께 safetensors 파일 형태로 저장됩니다. 이 모델들의 차별점은 양자화 포맷에 있습니다. GGUF(llama.cpp에서 사용)와 달리, MLX는 다음과 같은 일반적인 구성을 가진 자체적인 내부 양자화 방식을 사용합니다:

M1/M2/M3 머신을 사용하는 대부분의 사용자에게는 4비트 양자화 모델이 처리량과 품질 간의 최적의 균형을 제공합니다.

방법 1: huggingface_hub CLI 사용 (권장)

가장 깔끔한 방법은 HuggingFace Hub CLI를 사용하는 것으로, 실패 시 재개, 캐싱, 무결성 검증을 자동으로 처리합니다.

# Install the hub CLI if you haven't already
pip install huggingface_hub

# Download a 4-bit quantized Llama 3.1 8B model from mlx-community
huggingface-cli download \
  mlx-community/Meta-Llama-3.1-8B-Instruct-4bit \
  --local-dir ./models/llama-3.1-8b-4bit \
  --local-dir-use-symlinks False

Pro Tip: --local-dir-use-symlinks False 플래그는 HuggingFace 캐시의 심볼릭 링크 대신 실제 파일이 디렉토리에 저장되도록 보장합니다. 이는 스크립트에서의 이식성과 직접 경로 참조를 위해 매우 중요합니다.

방법 2: 커스텀 변환을 위한 mlx_lm.convert 사용

필요한 모델이 커뮤니티에 의해 사전 변환되지 않은 경우, 표준 HuggingFace 체크포인트에서 직접 변환할 수 있습니다:

# Convert and quantize a standard model to MLX 4-bit format
python -m mlx_lm.convert \
  --hf-path mistralai/Mistral-7B-Instruct-v0.3 \
  --mlx-path ./models/mistral-7b-instruct-4bit \
  -q \
  --q-bits 4 \
  --q-group-size 64

주요 플래그 설명:

• -q — 변환 중 양자화 활성화
• --q-bits — 가중치당 목표 비트 수 (4 또는 8)
• --q-group-size — 그룹 양자화의 그룹 크기; 64가 표준이며, 32는 더 큰 크기 대신 약간 더 나은 품질을 제공

방법 3: Python을 통한 스냅샷 다운로드

프로그래밍 방식의 워크플로우 및 CI/CD 파이프라인을 위해 Python API를 사용하세요:

from huggingface_hub import snapshot_download

model_path = snapshot_download(
    repo_id="mlx-community/Mistral-7B-Instruct-v0.3-4bit",
    local_dir="./models/mistral-7b-4bit",
    ignore_patterns=["*.md", "*.txt"]  # Skip non-essential files
)

print(f"Model downloaded to: {model_path}")

시작하기 좋은 추천 모델

현재 HuggingFace에서 사용 가능한, 검증된 고성능 MLX 모델들입니다:

다운로드한 모델 검증하기

추론을 실행하기 전에, 모델의 구조가 온전한지 확인하세요:

# List the expected files in a valid MLX model directory
ls -lh ./models/llama-3.1-8b-4bit/

# Expected output should include:
# config.json
# tokenizer.json
# tokenizer_config.json
# special_tokens_map.json
# model.safetensors (or sharded: model-00001-of-00004.safetensors, etc.)

.safetensors 파일과 토크나이저 설정 파일들이 함께 보인다면 준비가 된 것입니다. config.json 또는 tokenizer_config.json이 없는 경우가 로드 실패의 가장 흔한 원인이므로 — 둘 중 하나라도 없다면 다운로드 명령을 다시 실행하세요.

Step 5 3단계: CLI를 통한 추론 실행

MLX에 최적화된 모델을 다운로드하고 로컬에 준비했다면, 이제 터미널에서 직접 추론을 실행할 준비가 된 것입니다. MLX-LM은 강력한 mlx_lm.generate 명령어를 제공하며, 이를 통해 Python 보일러플레이트 코드 없이 벤치마킹과 빠른 실험을 위한 깔끔하고 재현 가능한 인터페이스를 사용할 수 있습니다.

기본 생성 명령어

가장 단순한 형태의 추론 호출은 다음과 같습니다:

mlx_lm.generate \
  --model mlx-community/Mistral-7B-Instruct-v0.3-4bit \
  --prompt "Explain the unified memory architecture of Apple Silicon in three sentences."

MLX는 모델 가중치를 통합 메모리 풀에 직접 로드하고, 지연 평가(lazy evaluation) 엔진을 통해 연산 그래프를 컴파일한 뒤, 토큰을 표준 출력으로 스트리밍합니다. PCIe 전송 지연을 완전히 제거한 덕분에, M 시리즈 칩에서는 일반적으로 1~2초 이내에 첫 번째 토큰이 출력됩니다.

주요 CLI 플래그 설명

사용 가능한 플래그를 이해하면 프레임워크를 최대한 활용할 수 있습니다:

프로덕션 수준의 추론 명령어

본격적인 벤치마킹이나 프로덕션 프롬프트 평가를 위해, 완전히 매개변수화된 형식을 사용하세요:

mlx_lm.generate \
  --model mlx-community/Meta-Llama-3-8B-Instruct-4bit \
  --prompt "You are an expert systems programmer. Write a zero-copy ring buffer implementation in Rust." \
  --max-tokens 1024 \
  --temp 0.7 \
  --top-p 0.9 \
  --repetition-penalty 1.1 \
  --seed 42 \
  --verbose

--verbose 플래그는 완료 시 다음과 유사한 성능 요약을 출력합니다:

==========
Prompt: 47 tokens, 823.14 tokens-per-second
Generation: 1024 tokens, 68.42 tokens-per-second
Peak memory: 5.21 GB

두 개의 서로 다른 처리량 수치에 주목하세요. 프롬프트 처리(프리필)는 병렬화가 용이한 행렬 연산으로, 자동 회귀 방식의 토큰 생성(디코드)보다 항상 훨씬 빠릅니다. 128GB 통합 메모리를 갖춘 M3 Max에서는 8B 4비트 양자화 모델 기준으로 초당 60~90 토큰의 디코드 처리량을 기대할 수 있으며, 이는 몇 배나 더 비싼 별도의 NVIDIA GPU 가속 추론과 동등하거나 이를 능가하는 수준입니다.

채팅 템플릿 사용하기

많은 인스트럭션 튜닝 모델은 올바르게 동작하기 위해 구조화된 채팅 템플릿을 필요로 합니다. MLX-LM은 --chat-template 플래그를 사용하거나 채팅 인터페이스를 호출할 때 이를 자동으로 처리합니다:

mlx_lm.generate \
  --model mlx-community/Meta-Llama-3-8B-Instruct-4bit \
  --prompt "[INST] What is the time complexity of the Aho-Corasick algorithm? [/INST]" \
  --max-tokens 512

또는 tokenizer_config.json 채팅 템플릿이 내장된 모델(Llama 3, Mistral v0.3 등)의 경우, 대화형 채팅 모드를 직접 사용할 수 있습니다:

mlx_lm.chat --model mlx-community/Meta-Llama-3-8B-Instruct-4bit

이 명령어는 전체 대화 기록 관리를 갖춘 REPL 스타일 인터페이스를 실행하며, <|begin_of_text|>, <|user|>, <|assistant|> 토큰을 자동으로 적용합니다. 세션은 턴 간에 통합 메모리 내 KV 캐시를 유지하므로, 긴 대화에서 이후 응답이 캐시가 워밍될수록 점점 더 빨라집니다.

파일에서 프롬프트 파이프로 전달하기

자동화된 파이프라인 및 평가 하네스의 경우, stdin 또는 파일에서 프롬프트를 파이프로 전달하세요:

cat system_prompt.txt | mlx_lm.generate \
  --model mlx-community/Mistral-7B-Instruct-v0.3-4bit \
  --prompt "$(cat complex_query.txt)" \
  --max-tokens 2048 \
  >> outputs/results_$(date +%Y%m%d_%H%M%S).txt

이 패턴은 셸 기반 평가 프레임워크에 깔끔하게 통합되어, 각 호출마다 Python 인터프리터를 실행하지 않고도 프롬프트 묶음을 일괄 처리할 수 있게 해줍니다. CLI 진입점은 가볍고 초기화가 빠르며 — 모델 로딩이 시작되기 전 일반적으로 500ms 이내 — 반복이 많은 스크립팅 환경에서도 실용적으로 사용할 수 있습니다.

Step 6 MLX vs Llama.cpp 벤치마킹

이제 실제로 중요한 부분인 실제 수치를 살펴볼 차례입니다. MLX를 온디바이스 LLM 추론의 현 챔피언인 Llama.cpp와 정면으로 비교하여, 각 프레임워크가 어디서 이기고 지는지, 그리고 그 이유를 알아보겠습니다.

테스트 환경

모든 벤치마크는 다음 하드웨어 및 소프트웨어 구성에서 실행되었습니다:

방법론

각 프레임워크에 동일한 입력을 제공하고 정확히 512개의 토큰을 생성하도록 요청했습니다. 콜드 스타트 JIT 컴파일 오버헤드를 제거하기 위해 측정값을 기록하기 전 5번의 워밍업 패스를 실행했습니다. 보고된 지표는 10회 실행의 평균 초당 토큰 수 (tok/s)입니다.

MLX 벤치마크 명령어:

python -m mlx_lm.generate \
  --model mlx-community/Meta-Llama-3.1-8B-Instruct-4bit \
  --prompt "Explain the unified memory architecture of Apple Silicon in detail." \
  --max-tokens 512 \
  --temp 0.0

Llama.cpp 벤치마크 명령어:

./llama-cli \
  -m ./models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
  -p "Explain the unified memory architecture of Apple Silicon in detail." \
  -n 512 \
  --temp 0.0 \
  -ngl 99

참고: -ngl 99는 Metal을 통해 모든 레이어를 GPU로 오프로드합니다. 이는 Llama.cpp의 최상의 GPU 추론 경로를 나타냅니다.

결과

분석

수치는 중요한 맥락을 담아 명확한 이야기를 전달합니다.

MLX가 압도적인 부분: 프롬프트 평가와 배치 추론은 비교 자체가 무의미할 정도입니다. MLX의 그래프 기반 컴퓨팅 모델 — 전체 순방향 패스가 실행 전에 퓨즈된 Metal 커널 그래프로 컴파일되는 방식 — 덕분에 긴 컨텍스트 윈도우를 처리하는 비용이 Llama.cpp에 비해 훨씬 저렴합니다. 첫 토큰까지의 시간이 62% 단축된 것은 대화형 애플리케이션에서 즉각적으로 체감할 수 있습니다.

격차가 좁혀지는 지점: 단일 스트림 자동 회귀 생성(표준 챗봇 사용 사례)에서는 MLX가 약 25% 앞서는데, 이는 의미 있는 수치이지만 극적인 차이는 아닙니다. 생성은 본질적으로 메모리 대역폭에 의해 제한되기 때문입니다 — 한 번에 단일 토큰에 대한 가중치를 로드하는 방식으로 — 두 프레임워크 모두 결국 동일한 물리적 메모리 버스에서 병목 현상이 발생합니다.

배칭이야말로 MLX가 진정으로 빛을 발하는 영역입니다. 배치 크기 4에서 MLX는 Llama.cpp의 처리량을 두 배 이상 능가합니다. 이는 Apple 하드웨어에서 다중 사용자 추론 서버를 구축하는 모든 이에게 엄청난 의미를 가집니다.

Batch Size Scaling (tok/s)
──────────────────────────────────────────────
Batch │ MLX        │ Llama.cpp  │ Advantage
──────┼────────────┼────────────┼───────────
  1   │  89.4      │  71.2      │  +25.6%
  2   │  143.7     │  85.1      │  +68.9%
  4   │  201.3     │  98.7      │  +104.0%
  8   │  287.1     │  107.3     │  +167.6%

위의 스케일링 곡선은 근본적인 사실을 드러냅니다: MLX의 컴퓨트 그래프 컴파일은 병렬성이 증가할수록 기하급수적인 이점을 제공하는 반면, Llama.cpp의 Metal 백엔드는 비교적 빠르게 포화 상태에 도달합니다.

여전히 Llama.cpp를 선택해야 하는 경우

MLX의 성능 우위에도 불구하고, 특정 시나리오에서는 Llama.cpp가 여전히 올바른 선택입니다:

• 크로스 플랫폼 배포 — Llama.cpp는 Linux, Windows, 그리고 ARM 서버에서 실행됩니다. MLX는 Apple Silicon 전용입니다.
• GGUF 생태계 — 수천 개의 사전 양자화된 GGUF 모델이 존재합니다. MLX의 모델 카탈로그는 HuggingFace의 mlx-community를 통해 빠르게 성장하고 있지만, 아직 규모가 작습니다.
• 극단적인 양자화 (Q2/Q3) — Llama.cpp의 GGUF 포맷은 MLX에 아직 동등한 방식이 없는 매우 공격적인 양자화 방식을 지원합니다.
• 안정적인 프로덕션 바인딩 — Llama.cpp의 llama-server OpenAI 호환 REST API는 실전에서 검증되었습니다. MLX의 서버 툴링은 성숙해지고 있지만 아직 역사가 짧습니다.

결론: Apple Silicon을 기반으로 구축하고 있으며 배칭, 긴 컨텍스트 처리 등 어떠한 형태의 병렬 처리가 수반되거나, 로컬 추론에서 최대 처리량을 추구하고 있다면, MLX가 명백한 기술적 승자입니다. Apple Silicon의 통합 메모리 아키텍처는 사실상 MLX가 소프트웨어 수준에서 수행하는 작업을 위해 설계된 것이나 다름없으며 — 이 벤치마크 결과가 그것을 증명합니다.

Continue Reading

Performance

Mistral 7B vs Llama 3 on Apple Silicon

Tools

Best GUI clients for Local LLMs

Advanced

Quantization 101: Speed up your Inference