Apple Silicon LLM 추론: omlx vs vLLM Metal 성능 비교 분석

Apple Silicon 환경에서 LLM을 로컬에서 돌릴 때, 어떤 추론 엔진을 써야 할지 고민하는 개발자가 많습니다. omlx(continuous batching 기반)와 vLLM Metal(vLLM 공식 Apple Silicon 플러그인)은 가장 핫한 두 옵션인데, 실제 성능과 아키텍처 차이는 생각보다 큽니다.

2026년 7월 기준으로 최신 벤치마크 데이터와 아키텍처 차이를 비교 분석했습니다.

---

둘의 정체

omlx(GitHub, 17.6k stars)는 Apple Silicon 전용 LLM 추론 서버입니다. continuous batching과 SSD 기반 KV 캐시가 핵심이며, OpenAI 호환 API를 제공해 기존 코드 변경 없이 바로 쓸 수 있습니다. macOS 메뉴 바에서 관리되는 네이티브 애플리케이션 형태로도 제공됩니다.

vLLM Metal(GitHub)은 vLLM 프로젝트의 공식 Apple Silicon 하드웨어 플러그인입니다. CUDA 환경에서 검증된 vLLM의 아키텍처(PagedAttention 등)를 Metal 백엔드로 이식하려는 시도이며, 2026년 4월 v0.2.0에서 Unified paged varlen Metal kernel이 기본 attention 백엔드로 채택되었습니다.

아키텍처 비교

두 프로젝트의 근본적인 차이를 먼저 정리합니다.

omlx 아키텍처:

• continuous batching: 여러 요청을 하나의 forward pass로 묶어 실행 — Apple Silicon에서 실제 batching이 동작하는 유일한 백엔드
• SSD KV 캐시: 긴 컨텍스트에서 메모리 압력을 SSD로 오프로드 — 32k 토큰 입력에서도 throughput 유지
• MLX 기반: Apple의 MLX 프레임워크 위에서 동작하며 Metal GPU를 직접 활용
• OpenAI 호환 API: localhost:8000에서 HTTP SSE 스트리밍 제공
• macOS 네이티브 앱: 메뉴 바에서 모델 시작/종료, 설정 관리

vLLM Metal 아키텍처:

• vLLM 공식 플러그인: UC Berkeley에서 개발한 vLLM 생태계와 통합
• PagedAttention 이식 시도: v0.2.0에서 Unified paged varlen Metal kernel 도입 — v0.1.0 대비 83배 TTFT 개선, 3.6배 throughput 향상
• MLX + PyTorch 통합 lowering: MLX와 PyTorch를 단일 경로로 통합
• 텍스트 전용: 현재 텍스트 모델만 지원 (멀티모달 미지원)
• ARM64 네이티브 Python 3.12: Rosetta 없이 동작

벤치마크 결과 (Qwen3.5-9B, 4-bit)

Latent Space의 5종 백엔드 벤치마크(출처)와 vLLM Metal 공식 데이터를 종합했습니다.

단일 요청 Throughput

Qwen3.5-9B 모델을 4-bit 양자화로 실행한 결과입니다.

MLX (직접 호출): 25.06 tok/s — 라이브러리 직접 호출이라 HTTP 오버헤드 없음

omlx: ~20 tok/s — continuous batching 스케줄러 오버헤드 포함

vLLM Metal: MLX 범위 추적 — 단일 요청에서는 MLX와 유사한 수준

llama.cpp Metal: 15.34 tok/s

Ollama: 13.76 tok/s

단일 요청에서는 raw MLX가 가장 빠르고, omlx는 약 20% 정도 느립니다. omlx의 overhead는 continuous batching 스케줄러 큐 + SSE 프레이밍에서 옵니다.

TTFT (Time To First Token)

llama.cpp Metal: 196ms — 가장 빠름

MLX: 396ms

Ollama: 470ms

omlx: 968ms — continuous batching 큐 대기 + SSE 오버헤드

TTFT는 단일 요청에서 omlx가 가장 느립니다. 하지만 이 overhead는 동시 요청이 늘어날 때 batching 효율로 상쇄됩니다.

Concurrency (동시 요청)

여기서 진짜 차이가 납니다.

MLX, llama.cpp, Ollama는 동시 요청이 늘어나도 aggregate throughput이 거의 변하지 않습니다. NUM_PARALLEL은 큐 깊이를 제어할 뿐, 실제 batching을 하지 않기 때문입니다.

omlx만 실제 batching이 동작합니다:

512-token 입력: 15.6 to 21.9 tok/s (concurrency 1 to 4, 1.40배)

2048-token 입력: 11.2 to 14.4 tok/s (concurrency 1 to 4, 1.29배)

vLLM Metal v0.2.0:

Unified paged varlen Metal kernel 도입으로 v0.1.0 대비 83배 TTFT 개선, 3.6배 throughput 향상. 하지만 Apple Silicon에서 vLLM GPU 버전의 batching 이점을 완전히 재현하지는 못하고 있습니다. MLX-managed KV cache를 사용하며, CUDA 버전의 PagedAttention과는 다른 구현입니다.

긴 컨텍스트 (Long Context)

512 to 32k 토큰 입력에서 decode throughput 변화:

MLX / llama.cpp / Ollama: 512~8k까지는 안정적 — 32k에서 약 절반으로 급감. KV 캐시가 커지면서 unified memory 대역폭 압력이 증가합니다.

omlx: 512~32k 토큰에서 약 20 tok/s로 일정 유지. SSD 기반 KV 캐시가 긴 컨텍스트에서도 일관된 성능을 보장합니다.

vLLM-MLX: 하이브리드 접근

vllm-mlx(독립 프로젝트)는 또 다른 옵션입니다. MLX 위에 vLLM과 유사한 CLI/API를 제공하는 프로젝트로, M4 Max에서 464 tok/s(Qwen3-0.6B)를 기록했습니다. arXiv 논문(2601.19139)에 따르면 M4 Max에서 Qwen3-0.6B 텍스트 모델로 최대 525 tok/s, Qwen3-VL-4B로 143 tok/s를 달성했으며, mlx-lm과 llama.cpp 모두를 상회합니다.

하지만 Reddit 커뮤니티(출처)에서는 "실제 vLLM이 아니라 vLLM과 유사한 인터페이스를 제공하는 MLX 기반 프로젝트"라고 지적합니다. PagedAttention 같은 vLLM의 핵심 최적화를 구현하지 않았다는 평가입니다.

언제 무엇을 써야 할까?

단일 사용자 / 로컬 개발 (IDE, CLI):

MLX 직접 호출. 25 tok/s, 서버 프로세스 없이 라이브러리만 import 하면 됨. Python 기반이라면 가장 빠른 선택입니다.

다중 사용자 / 서버 환경:

omlx. Apple Silicon에서 유일하게 batching이 실제 동작하는 백엔드. 동시 요청 4개에서 aggregate throughput이 1.29~1.40배 향상되며, OpenAI 호환 API로 기존 코드와의 통합도 쉽습니다.

vLLM 생태계 통합:

vLLM Metal. CUDA 환경에서 테스트한 vLLM 워크플로우를 Apple Silicon으로 이식할 때 유용합니다. v0.2.0에서 Metal kernel이 크게 개선되었지만, 아직 CUDA 버전의 batching 성능에는 미치지 못합니다.

편의성:

Ollama. ollama pull 한 줄로 모델 다운로드부터 serving까지. throughput은 최적이 아니지만 운영 편의성이 최고입니다.

결론

Apple Silicon에서 LLM 추론을 돌릴 때 "무조건 vLLM"이라는 공식은 통하지 않습니다. CUDA GPU와 달리 Apple Silicon의 unified memory 아키텍처에서 vLLM Metal은 아직 batching 이점을 충분히 실현하지 못하고 있습니다.

실제 batching이 필요한 서버 환경에서는 omlx가 현재 가장 확실한 선택입니다. continuous batching + SSD KV 캐시 조합이 Apple Silicon의 unified memory 특성에 가장 잘 맞고, OpenAI 호환 API로 기존 코드와의 통합도 쉽습니다.

단일 사용자라면 raw MLX가 여전히 가장 빠릅니다. HTTP 서버 계층 없이 라이브러리 직접 호출이라 오버헤드가 거의 없습니다.

vLLM Metal은 v0.2.0에서 큰 걸음을 내딛었지만, Apple Silicon 환경에서는 아직 omlx가 앞선다고 보는 것이 현실적입니다. 다만 vLLM Metal이 CUDA 버전의 PagedAttention을 완전히 재현하면 게임 체인저가 될 잠재력은 분명히 있습니다.

---

벤치마크 데이터 출처: Latent Space - Apple Silicon LLM Backends Benchmark, vLLM Metal GitHub, arXiv 2601.19139

Apple Silicon LLM 추론 서버: omlx vs vLLM Metal 성능 비교 분석

Apple Silicon Mac 에서 LLM 을 로컬에서 돌릴 때, 어떤 추론 서버를 선택해야 할까요? 2026 년 현재 가장 주목받는 두 프로젝트 omlx 와 vLLM Metal (vllm-mlx) 의 성능, 아키텍처, 사용 사례를 상세히 비교 분석합니다.

1. 개요: 두 프로젝트는 무엇인가

omlx (jundot/omlx)

GitHub 17.6k stars, 1.5k forks 를 기록하며 Apple Silicon 생태계에서 가장 인기 있는 LLM 추론 서버입니다. macOS 메뉴 바 에서 직접 모델을 관리할 수 있는 네이티브 앱을 제공하며, continuous batching 과 SSD 티어드 KV 캐시 가 핵심 차별점입니다. 1,774 회의 커밋으로 매우 활발하게 개발 중이며, Qwen3.5/3.6 네이티브 prefill 커널, DeepSeek V4 MXFP4 MoE 가속 등 최신 모델 지원을 빠르게지원하며 있습니다.

vLLM Metal (vllm-mlx, waybarrios/vllm-mlx)

GitHub 1.4k stars, 버전 0.4.0. vLLM 의 아키텍처를 MLX 로 이식한 프로젝트로, OpenAI 와 Anthropic 양쪽 API 를 단일 프로세스에서 제공합니다. EuroMLSys 2026 에 논문이 채택되었으며, continuous batching, paged KV cache, prefix caching 을 지원합니다. 특히 멀티모달 (Vision-Language) 모델 에서 content-based prefix caching 을 통해 이미지 중복 인코딩을 제거하는 것이 핵심 강점입니다.

2. 아키텍처 비교

omlx

• Apple MLX 에 최적화된 네이티브 추론 서버
• Continuous batching: 동시 요청을 효율적으로 배치 처리
• SSD 티어드 KV 캐시: hot tier (RAM) + cold tier (SSD). 메모리가 부족해도 SSD 로 캐시를 저장하여 컨텍스트를 유지
• macOS 메뉴 바 앱: 모델 다운로드, 시작/정지, 모니터링을 터미널 없이 관리
• Admin Dashboard: /admin 에서 실시간 모니터링, 벤치마크, 모델 설정
• 지원: 텍스트 LLM, Vision-Language Model, 임베딩, 리랭커
• OpenAI 호환 API: http://localhost:8000/v1
• 설치: Homebrew (brew install omlx) 또는 .dmg 앱

vLLM Metal (vllm-mlx)

• MLX 위에 vLLM 스타일 아키텍처 재구현
• PagedAttention: vLLM 의 핵심 메모리 관리 알고리즘을 Metal 로 이식
• Continuous batching: 동시 요청 스케줄링 및 배치 처리
• Prefix caching: 중복 프롬프트 prefix 의 KV 캐시 재사용
• Content-based vision cache: 동일한 이미지의 content hash 로 캐시 재사용 (멀티모달 특화)
• SSD cold tier: 메모리 초과 시 SSD 로 KV 캐시 오프로드
• OpenAI + Anthropic 양쪽 API 지원: /v1/chat/completions 와 /v1/messages
• Multi-Token Prediction (MTP), Chunked prefill, KV cache quantization
• 설치: pip install vllm-mlx

3. 성능 벤치마크 (M4 Max 128GB 기준)

단일 요청 처리 속도 (tok/s, 4-bit 양자화)

vllm-mlx 의 공식 논문 (arXiv:2601.19139) 에서 발표한 벤치마크 결과입니다:

소형 모델

• Qwen3-0.6B: vllm-mlx 525.5 vs vllm-metal 365.8 vs llama.cpp 281.5 (1.87x)
• Llama-3.2-1B: vllm-mlx 461.9 vs vllm-metal 350.9 vs llama.cpp 331.3 (1.39x)

중형 모델

• Qwen3-4B: vllm-mlx 159.0 vs vllm-metal 137.3 vs llama.cpp 118.2 (1.35x)
• Gemma 3-4B: vllm-mlx 152.5 vs vllm-metal 117.0 vs llama.cpp 123.2 (1.24x)
• Llama-3.2-3B: vllm-mlx 203.6 vs vllm-metal 174.3 vs llama.cpp 155.8 (1.31x)

대형 / MoE 모델

• Qwen3-8B: vllm-mlx 93.3 vs vllm-metal 87.1 vs llama.cpp 76.9 (1.21x)
• Qwen3-30B-A3B: vllm-metal 110.3 vs vllm-mlx 109.7 (역전)
• Nemotron-30B-A3B: vllm-mlx 121.8 vs llama.cpp 85.1 (1.43x)

핵심 인사이트:

• 소형 모델에서는 vllm-mlx 가 MLX 효율적인 소텐서 처리로 최대 1.87 배 우위
• 대형 MoE 모델 (Qwen3-30B-A3B) 에서는 vllm-metal 이 미세하게 앞섬 (110.3 vs 109.7)
• 실제 omlx 도 MLX 기반이므로 단일 요청 처리 속도는 vllm-mlx 와 유사한 수준 (약 5% 내외 차이)

동시 요청 (Concurrency) —_continuous batching_ 성능

여러 사용자가 동시에 접근하는 서버 환경에서 가장 중요한 지표입니다.

vllm-mlx 동시 요청 확장 (Qwen3-0.6B 기준)

• 1 개 요청: 441 tok/s
• 16 개 동시 요청: 1,642 tok/s (3.7 배 향상)
• 16 개 동시 요청 시: 초당 25+ 개 처리 가능
• Qwen3-8B: 16 개 동시 요청에서 2.6 배 aggregate throughput 향상 (메모리 대역폭 포화 영향)

omlx 동시 요청

• continuous batching 지원으로 동시 요청 시 aggregate throughput 1.29~1.40 배 향상 확인
• SSD 티어드 캐시로 인해 동시 요청 시 메모리 포화 상황에 더 탄력적
• 메뉴 바 앱에서 실시간으로 동시 연결 수, GPU 사용률 모니터링 가능

멀티모달 (Vision-Language) 성능

vllm-mlx 의 가장 큰 강점입니다.

이미지 prefix 캐싱 (Qwen3-VL-8B 기준)

• 1 턴 (cold): 21.7 초
• 2 턴: 1.15 초 (19 배 향상)
• 3 턴+: 0.78 초 (28 배 향상)

비디오 분석 캐싱 (Qwen3-VL-4B 기준)

• 64 프레임 (8fps): 18.2 초, 8.2 tok/s
• 동일 비디오 재분석 시 24.7 배 캐싱 가속

omlx 도 Vision-Language Model 을 지원하지만, vllm-mlx 의 content-based prefix caching 이 멀티모달 워크로드에서 압도적 우위를 보입니다.

4. 메모리 관리 비교

vLLM Metal (vllm-mlx)

• PagedAttention: 페이지 단위로 KV 캐시를 관리하여 메모리 단편화 최소화
• KV cache quantization: KV 캐시를 낮은 정밀도로 저장하여 메모리 사용량 절감
• SSD cold tier: 메모리 초과 시 SSD 로 자동 오프로드
• 4-bit, 8-bit 모델 지원 (MLX 양자화)

omlx

• Hot/Cold 티어드 캐시: RAM 에 빈번한 컨텍스트, SSD 에 덜 사용되는 컨텍스트 자동 분리
• 모델 고정 (Pin): 자주 쓰는 모델을 메모리에 영구 유지
• 자동 스왑 (Auto-swap): 무거운 모델을 필요할 때 로드, 사용하지 않으면 언로드
• 컨텍스트 길이 제한 설정: 각 모델별로 최대 컨텍스트 길이 개별 설정 가능
• MXFP4 MoE (DeepSeek V4 등) 지원으로 더 낮은 메모리 사용량

핵심 차이:

• vllm-mlx 는 PagedAttention 기반의 세분화된 메모리 페이지 관리에 강점
• omlx 는 실용적인 모델 관리 (고정, 스왑, 컨텍스트 제한) 에 강점 — 여러 모델을 번갈아 쓰는 사용자에게 적합

5. 설치 및 운영 편의성

omlx — 가장 쉬운 설치

• .dmg 다운로드 후 Applications 에 드래그 — 설치 완료
• brew install omlx 후 omlx start
• macOS 메뉴 바에서 모델 다운로드, 서버 시작/정지, 상태 모니터링
• /admin Web UI 에서 벤치마크 실행, 모델 설정, 실시간 로그 확인
• 자동 업데이트 지원 (앱 내)

vllm-mlx — 개발자 친화적

• pip install vllm-mlx 후 vllm-mlx serve --model ...
• 터미널 기반 운영 — 프로세스 관리 (systemd, tmux 등) 필요
• OpenAI + Anthropic 양쪽 API 동시 제공 — Claude Code 등 Anthropic 클라이언트와 직접 연동
• MCP (Model Context Protocol) 지원
• Structured output, reasoning models (<think>) 지원

6. 선택 가이드: 어떤 것을 써야 할까?

omlx 를 선택하세요 — 다음이 해당될 때:

• 일상적인 로컬 LLM 사용 (채팅, 코드보정, 글쓰기)
• 여러 모델을 번갈아 사용하며 메모리 관리가 중요한 경우
• 터미널 없이 GUI 로 서버를 관리하고 싶은 경우
• Claude Code, Copilot 등 AI 도구와 연결하여 개발 워크플로우에 활용
• 메모리가 제한된 Mac (32GB 이하) 에서 여러 모델을 효율적으로 돌릴 때

vllm-mlx 를 선택하세요 — 다음이 해당될 때:

• 동시에 여러 사용자가 접근하는 서버 환경 (continuous batching 이 중요한 경우)
• Vision-Language 모델 (이미지/비디오 분석) 을 주로 사용할 때
• Anthropic API 호환이 필요할 때 (Claude Code 등)
• PagedAttention 기반의 세분화된 메모리 관리가 필요할 때
• MCP, structured output 등 고급 기능이 필요할 때

7. 결론

Apple Silicon 에서 LLM 추론 서버를 선택할 때, 단일 요청 처리 속도 만 보면 두 프로젝트 모두 MLX 기반이라 큰 차이가 없습니다. 결정적인 차이는 어떤 기능과 워크플로우를 우선시하느냐 입니다.

omlx 는 "메뉴 바에서 모든 것을 관리하는" 철학으로, 로컬 LLM 을 일상의 도구로 만드는 데 최적화되어 있습니다. 모델 고정, 자동 스왑, SSD 캐싱이 실제로 매일 쓰는 사람에게 가장 중요한 기능들입니다.

vllm-mlx 는 "vLLM 의 모든 기능을 Apple Silicon 에서"라는 목표 아래, continuous batching 과 멀티모달 캐싱에 집중했습니다. 동시 요청 처리와 Vision-Language 모델 성능에서 가장 강력한 옵션입니다.

2026 년 Apple Silicon LLM 생태계는 NVIDIA A100 대비 여전히 뒤처지지만, 32GB Mac 에서 Qwen3-8B 를 초당 90 토큰 이상 생성하는 것은 로컬 AI 의 미래를 여는 충분한 속도입니다. 두 프로젝트 모두 이 속도를 현실로 만들고 있습니다.

참고 자료

• jundot/omlx (GitHub)
• waybarrios/vllm-mlx (GitHub)
• Native LLM and MLLM Inference at Scale on Apple Silicon (arXiv)
• Apple Silicon LLM Inference Optimization Guide
• vLLM-MLX Performance and Optimization (DeepWiki)