omlx는 Apple Silicon 환경에서 로컬 LLM을 좀 더 “운영 가능한 서버” 형태로 다루기 위해 만든 도구입니다. 단순히 모델 하나를 띄우는 수준을 넘어, 연속 배칭(continuous batching), SSD 기반 KV 캐시, 멀티 모델 관리, 관리자 대시보드, macOS 메뉴바 앱까지 포함한 것이 특징입니다.
한 줄로 요약하면 이렇습니다.
- MLX는 Apple이 만든 머신러닝 프레임워크입니다.
- **
mlx-lm**은 MLX 기반으로 LLM을 실행하고 파인튜닝하는 패키지입니다. - oMLX는 그 위에서 실제 서비스 운영에 필요한 서버 기능과 관리 UX를 덧붙인 제품에 가깝습니다.
즉, oMLX는 “MLX를 대체하는 것"이라기보다, MLX 생태계 위에서 로컬 추론 서버를 더 쉽게 운영하게 해주는 계층이라고 보는 편이 정확합니다.
1. oMLX란 무엇인가?
README 기준으로 oMLX는 다음 성격을 갖습니다.
- Apple Silicon용 로컬 LLM 추론 서버
- OpenAI / Anthropic 호환 API 제공
- 텍스트 LLM뿐 아니라 VLM, OCR, 임베딩, 리랭커 지원
- 관리자 웹 UI와 macOS 메뉴바 앱 제공
- 모델 다운로드, 로드/언로드, 핀(pin), TTL 설정 등 운영 기능 포함
기본 엔드포인트는 http://localhost:8000/v1이며, 채팅 UI는 http://localhost:8000/admin/chat, 관리 UI는 http://localhost:8000/admin으로 접근합니다.
지원 API도 꽤 실용적입니다.
POST /v1/chat/completionsPOST /v1/completionsPOST /v1/messagesPOST /v1/embeddingsPOST /v1/rerankGET /v1/models
그래서 기존에 OpenAI 호환 클라이언트를 쓰고 있었다면, base URL만 로컬 oMLX 서버로 바꿔 붙이는 방식으로 연동하기 쉽습니다.
2. MLX와 무엇이 다른가?
여기서 가장 중요한 포인트는 비교 대상이 정확히 누구인지입니다.
MLX는 프레임워크
MLX는 Apple machine learning research 팀이 만든 배열 기반 머신러닝 프레임워크입니다. NumPy/PyTorch와 비슷한 개발 경험을 제공하면서 Apple Silicon의 통합 메모리와 GPU를 효율적으로 활용하도록 설계되어 있습니다.
즉 MLX는 다음에 가깝습니다.
- 텐서/배열 연산
- 자동 미분
- 모델 학습 및 실험
- 연구용/개발용 기반 라이브러리
oMLX는 운영용 추론 서버
반면 oMLX는 MLX 자체가 아니라, 주로 mlx-lm과 관련 생태계를 활용해 실제 로컬 AI 서버를 운영하는 경험에 초점을 둡니다.
즉 oMLX는 다음 문제를 풀어줍니다.
- 여러 모델을 한 서버에서 관리하고 싶다
- 자주 쓰는 모델은 메모리에 남겨두고 싶다
- 메모리가 부족하면 자동으로 정리하고 싶다
- 긴 컨텍스트를 SSD 캐시와 함께 재활용하고 싶다
- 터미널만이 아니라 웹 UI와 메뉴바에서 관리하고 싶다
- OpenAI 호환 API로 기존 도구를 쉽게 붙이고 싶다
정리하면
| 구분 | MLX | oMLX |
|---|---|---|
| 역할 | 머신러닝 프레임워크 | 로컬 추론 서버/운영 도구 |
| 주 사용자 | 연구자, 모델 개발자 | 로컬 LLM 운영자, 앱 개발자 |
| 초점 | 연산, 학습, 모델 구현 | 서빙, 관리, 캐시, 멀티 모델 |
| UI | 라이브러리 중심 | Admin UI, Chat UI, 메뉴바 앱 |
| API 서버 | 직접 구성 필요 | 기본 제공 |
따라서 “MLX보다 낫다"라기보다는, 로컬 추론 운영 경험에서는 MLX보다 상위 레벨의 편의 기능을 제공한다고 보는 것이 맞습니다.
3. oMLX가 특히 나은 점
oMLX의 강점은 성능 수치 하나보다도, 실제 운영에서 번거로운 지점을 많이 줄여준다는 데 있습니다.
1) 멀티 모델 운영
mlx-lm을 직접 쓰면 일반적으로 한 번에 특정 모델을 명시해 실행하는 흐름이 많습니다. 반면 oMLX는 모델 디렉터리를 스캔해서 여러 모델을 한 서버 안에서 관리합니다.
그리고 다음 기능이 붙어 있습니다.
- LRU eviction: 메모리가 부족할 때 오래 안 쓴 모델을 자동 정리
- manual load/unload: 필요할 때 즉시 로드/언로드
- model pinning: 자주 쓰는 모델은 메모리에 고정
- per-model TTL: 일정 시간 유휴 상태면 자동 언로드
개발용 로컬 서버를 오래 켜두는 사람에게 이 차이는 꽤 큽니다.
2) Tiered KV Cache
oMLX README에서 가장 눈에 띄는 부분이 Hot + Cold KV Cache입니다.
- Hot tier (RAM): 자주 쓰는 KV 블록을 메모리에 유지
- Cold tier (SSD): 메모리가 차면 SSD에
safetensors형식으로 오프로딩
그리고 다음 요청에서 prefix가 맞으면 디스크에서 복원해 재사용합니다. README 설명상 이 캐시는 서버 재시작 이후에도 재활용 가능합니다.
긴 프롬프트, 반복되는 시스템 프롬프트, 코드베이스 컨텍스트처럼 prefix 재사용이 많은 작업에서 실용적인 장점이 있습니다.
3) Continuous Batching
oMLX는 mlx-lm의 BatchGenerator를 활용해 동시 요청을 처리합니다. 그래서 여러 클라이언트나 여러 탭에서 요청이 들어와도 단순 직렬 처리보다 효율적으로 운영할 수 있습니다.
혼자 쓰는 로컬 서버여도 다음 같은 상황에 도움이 됩니다.
- 에디터 플러그인
- 터미널 에이전트
- 웹 UI
- 백그라운드 임베딩 작업
이런 요청이 동시에 붙을 때 한 모델 서버를 조금 더 현실적으로 굴릴 수 있습니다.
4) 관리 UI와 메뉴바 앱
oMLX는 CLI만 있는 도구가 아닙니다.
/admin에서 모델 상태, 메모리, 설정, 다운로드, 벤치마크 확인/admin/chat에서 내장 채팅 UI 사용- macOS 메뉴바 앱으로 시작/중지/상태 확인
즉, “설치 후 앱처럼 쓴다"는 감각이 강합니다. 터미널에 익숙하지 않은 팀원과 같이 쓰기에도 상대적으로 부담이 적습니다.
5) OpenAI / Anthropic 호환 API
기존 클라이언트를 거의 바꾸지 않고 연동할 수 있다는 점도 큽니다.
- OpenAI 호환
/v1/chat/completions - Anthropic 호환
/v1/messages - 임베딩과 리랭크 API 제공
이미 OpenAI SDK나 OpenAI 호환 클라이언트를 쓰는 프로젝트라면, 로컬 테스트 백엔드로 붙이기 쉽습니다.
4. 모델 관리는 어떻게 하나?
oMLX는 --model-dir 아래의 하위 디렉터리들을 모델 저장소로 취급합니다.
예시는 README에 이렇게 나옵니다.
~/models/
├── Step-3.5-Flash-8bit/
├── Qwen3-Coder-Next-8bit/
├── gpt-oss-120b-MXFP4-Q8/
├── Qwen3.5-122B-A10B-4bit/
└── bge-m3/
2단계 디렉터리 구조도 지원하므로 이런 형태도 가능합니다.
~/models/
└── mlx-community/
└── model-name/
서버는 이 디렉터리들을 스캔해서 모델 타입을 자동 판별합니다.
- LLM
- VLM
- OCR
- Embedding
- Reranker
모델 다운로드 방법
모델 다운로드는 크게 두 가지 흐름으로 보면 됩니다.
1) Admin Dashboard에서 다운로드
README 기준으로 oMLX는 관리자 대시보드에서 Hugging Face의 MLX 모델을 검색하고 바로 다운로드할 수 있습니다. 모델 카드와 파일 크기를 보고 원클릭으로 내려받는 방식입니다.
이 방식은 가장 편합니다.
- 터미널 명령어를 외울 필요가 적음
- 모델 저장 위치가 관리 UI와 자연스럽게 연결됨
- 어떤 모델이 이미 존재하는지 확인하기 쉬움
2) 직접 모델 디렉터리에 준비
CLI에서 omlx pull 같은 전용 다운로드 명령은 README 기준으로 보이지 않습니다. 그래서 필요하면 MLX 형식 모델을 직접 --model-dir 아래에 배치하는 방식도 가능합니다.
실제로는 이런 식으로 접근하면 됩니다.
mlx-community등에서 MLX 포맷 모델을 준비한다.--model-dir가 가리키는 하위 디렉터리에 둔다.omlx serve --model-dir ...로 서버를 시작한다.- Admin UI 또는
/v1/models에서 인식 여부를 확인한다.
즉, 모델 관점에서 oMLX는 **“모델 변환 도구"라기보다 “이미 준비된 MLX 모델들을 서빙하고 관리하는 서버”**에 더 가깝습니다.
5. 설치와 실행 방법
README 기준 설치 방식은 세 가지입니다.
1) macOS App
가장 단순한 방식입니다.
- GitHub Releases에서
.dmg다운로드 - Applications로 드래그
- 앱 실행
주의할 점은 macOS 앱 설치만으로 omlx CLI가 생기지는 않는다는 점입니다. 터미널에서 omlx 명령을 쓰려면 Homebrew 설치나 소스 설치가 필요합니다.
2) Homebrew 설치
brew tap jundot/omlx https://github.com/jundot/omlx
brew install omlx
업그레이드는 다음처럼 합니다.
brew update && brew upgrade omlx
백그라운드 서비스로도 돌릴 수 있습니다.
brew services start omlx
brew services stop omlx
brew services restart omlx
brew services info omlx
Homebrew 서비스는 기본적으로 ~/.omlx/models, 포트 8000 기준 zero-config로 동작합니다.
3) 소스에서 설치
git clone https://github.com/jundot/omlx.git
cd omlx
pip install -e .
MCP까지 포함하려면:
pip install -e ".[mcp]"
요구사항
README 기준 요구사항은 다음과 같습니다.
- macOS 15.0+
- Python 3.10+
- Apple Silicon (M1/M2/M3/M4)
6. 가장 기본적인 실행 흐름
가장 핵심 명령은 이것입니다.
omlx serve --model-dir ~/models
실행 후 기대할 수 있는 흐름은 다음과 같습니다.
~/models아래 모델들을 자동 스캔- 지원 가능한 모델 타입 판별
http://localhost:8000/v1에서 API 제공http://localhost:8000/admin에서 관리 UI 제공http://localhost:8000/admin/chat에서 채팅 UI 제공
모델 목록은 OpenAI 스타일로 확인할 수 있습니다.
curl http://localhost:8000/v1/models
채팅 API 호출 예시는 이런 형태입니다.
curl http://localhost:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "Qwen3-Coder-Next-8bit",
"messages": [
{"role": "user", "content": "oMLX의 장점을 세 줄로 요약해줘."}
]
}'
기존 OpenAI SDK도 base URL만 바꿔 붙이면 됩니다.
from openai import OpenAI
client = OpenAI(
base_url="http://localhost:8000/v1",
api_key="not-needed"
)
response = client.chat.completions.create(
model="Qwen3-Coder-Next-8bit",
messages=[
{"role": "user", "content": "Apple Silicon에서 oMLX를 쓰는 이유를 설명해줘."}
],
)
print(response.choices[0].message.content)
7. 자주 보게 될 주요 옵션
README에 나온 CLI 설정 중 실무적으로 중요한 옵션을 추리면 아래와 같습니다.
메모리 관련
# 로드된 모델이 사용할 메모리 제한
omlx serve --model-dir ~/models --max-model-memory 32GB
# 프로세스 전체 메모리 제한
omlx serve --model-dir ~/models --max-process-memory 80%
로컬 서버는 모델 하나보다도 전체 프로세스가 얼마나 메모리를 먹는지가 중요하기 때문에 --max-process-memory를 먼저 보는 편이 좋습니다.
SSD 캐시 관련
omlx serve \
--model-dir ~/models \
--paged-ssd-cache-dir ~/.omlx/cache
이 옵션을 켜두면 긴 컨텍스트 재사용에서 장점이 커질 수 있습니다. 대신 SSD 용량과 I/O 패턴도 함께 고려해야 합니다.
RAM 핫 캐시 크기
omlx serve --model-dir ~/models --hot-cache-max-size 20%
핫 캐시를 너무 크게 잡으면 다른 모델 로딩 여유가 줄어들 수 있고, 너무 작게 잡으면 캐시 적중 이점이 약해질 수 있습니다.
동시 요청 수
omlx serve --model-dir ~/models --max-concurrent-requests 16
에이전트, 편집기, 브라우저 UI가 한 서버를 같이 쓰는 경우 조정할 만한 옵션입니다.
MCP 설정
omlx serve --model-dir ~/models --mcp-config mcp.json
모델이 tool calling을 지원하고, MCP 서버 설정이 맞다면 좀 더 에이전트다운 활용이 가능합니다.
Hugging Face 미러
omlx serve --model-dir ~/models --hf-endpoint https://hf-mirror.com
네트워크 제약이 있는 환경에서 유용할 수 있습니다.
API Key 보호
omlx serve --model-dir ~/models --api-key your-secret-key
혼자 쓰는 로컬 머신이 아니거나, LAN에서 접근 가능하게 열어둘 경우 최소한의 보호 장치로 필요합니다.
8. 운영 팁
1) 자주 쓰는 모델만 pin 하자
여러 모델을 한꺼번에 항상 메모리에 올리면 편해 보이지만, Apple Silicon의 통합 메모리는 CPU/GPU가 같이 쓰기 때문에 체감 압박이 빨리 옵니다. 주력 모델 1~2개만 pin 하고 나머지는 TTL과 LRU에 맡기는 편이 안정적입니다.
2) --model-dir 구조를 처음부터 정리하자
이름이 뒤죽박죽이면 /v1/models나 Admin UI에서 헷갈립니다. 모델명, 양자화 형식, 용도를 파일명에 같이 넣는 습관이 좋습니다.
예:
~/models/
├── qwen3-coder-next-8bit/
├── qwen3-4b-instruct-4bit/
├── bge-m3/
└── reranker-modernbert/
3) SSD 캐시는 빠른 내부 디스크에 두는 편이 낫다
Tiered KV Cache의 장점은 I/O 성능에 영향을 받습니다. 가능하면 외장 느린 디스크보다 내부 SSD 쪽이 유리합니다.
4) OpenAI 호환이라고 해서 모델 차이가 사라지는 것은 아니다
API 모양은 같아도 모델별 chat template, tool calling 포맷, reasoning 출력 방식은 다를 수 있습니다. 특히 tool calling은 모델의 chat template이 tools 파라미터를 지원하는지를 확인해야 합니다.
5) oMLX는 “학습 프레임워크"가 아니라 “서빙 도구"다
모델 학습, 변환, 양자화 연구를 깊게 하려면 여전히 MLX나 mlx-lm 쪽을 직접 다뤄야 합니다. oMLX는 그 결과물을 운영 가능한 서버 경험으로 묶어주는 도구라고 이해하면 가장 덜 헷갈립니다.
9. 어떤 사람에게 잘 맞나?
oMLX는 특히 다음 경우에 잘 맞습니다.
- Apple Silicon 맥에서 로컬 LLM 서버를 오래 띄워두고 싶은 경우
- OpenAI 호환 API로 기존 앱을 빠르게 붙이고 싶은 경우
- 여러 모델을 웹 UI에서 관리하고 싶은 경우
- 긴 컨텍스트 재사용이 잦은 에이전트/코딩 워크플로우를 돌리는 경우
- 터미널뿐 아니라 메뉴바 앱과 관리 화면도 원하는 경우
반대로 다음 경우에는 MLX나 mlx-lm만으로 충분할 수 있습니다.
- 모델 하나만 잠깐 실행하면 되는 경우
- 직접 코드로 제어하는 쪽이 더 중요한 경우
- 학습, 파인튜닝, 변환 파이프라인이 주업무인 경우
마무리
oMLX는 MLX 생태계 위에서 “로컬 추론 서버 운영"에 필요한 기능을 꽤 촘촘하게 채운 도구입니다. MLX가 저수준의 강력한 기반이라면, oMLX는 그 위에서 모델 관리, 캐시, API, UI, 운영 편의성을 묶어 실제로 쓰기 쉽게 만든 레이어에 가깝습니다.
Apple Silicon 맥을 로컬 AI 서버처럼 활용하고 싶다면, 특히 여러 모델을 동시에 관리하고 싶다면, oMLX는 한 번 충분히 검토해볼 만한 선택지입니다.