10초 결론 (Runbook)
Claude Code는 항상 Ollama(:11434) 경로. MLX는 오프라인 벤치마크·모델 검증 전용.
본 글 규범(Claude Code / Cursor 로컬 모델)에서 선택은 런타임 계층에서만 일어나며, 기본·권장은 Ollama. 세 번째 «공식 경로»는 없다.
많은 사람이 Ollama vs MLX를 묻는 것은 사실 런타임 계층 질문이다. Claude Code 로컬 모델에 대한 이 페이지의 답은 다음과 같다.
되돌릴 수 없는 결론
Claude Code 기본 스택은 Ollama 하나뿐. MLX는 본 글의 Agent 런타임 선택에 참여하지 않는다(벤치마크·CI·연구만).
- 런타임(Claude Code / 로컬 API) → Ollama만
- 오프라인(벤치마크 / CI / 연구) → MLX
- M4 Mac Mini 로컬 LLM · 16GB → 먼저 7B 클래스, 그다음
ollama serve
한눈에 보는 차이 (비교표는 이것만)
M4 Mac Mini 로컬 LLM에서 Claude Code 로컬 모델(Ollama vs MLX)은 아래 두 «치명적» 행을 먼저 본다 — MLX는 «대체 런타임»이 아니라 Agent 경로에 넣으면 안 되는 도구다.
| 차원 | Ollama | MLX |
|---|---|---|
| Agent 런타임으로 쓸 수 있는가(Claude Code / Cursor / tool loop) | ✅ | ❌ |
| Claude Code가 glue 없이 쓸 수 있는가(zero glue code) | ✅ :11434 | ❌ 자체 게이트웨이 필요 |
| 내장 HTTP 추론 서비스 | ✅ | ❌(본 글에서는 자체 GW 비권장) |
| tok/s(8B, swap 없음) | 기준 | 약 +3 % ~ +12 %(오프라인 참고만) |
팀 ollama serve | ✅ 표준 | ❌ Agent 경로 밖 |
위 두 행이 승부를 가른다. tok/s는 아래 참고 — Claude Code 런타임 선택에 쓰지 않는다.
핵심 오해: 90%가 잘못된 질문을 한다
Ollama vs MLX에서 «누가 더 빠른가?»를 묻는다 — M4 Mac Mini 로컬 LLM에서는 잘못된 질문이다.
Claude Code 로컬 모델에서도 마찬가지. 진짜 질문은:
이 모델을 Agent가 프로덕션 런타임으로 쓸 수 있는가?
순서를 틀렸다(먼저 7B/14B·메모리) → 상단 시리즈 경로.
MLX 측 흔한 오판(전환 핵심)
벤치에서 Apple Silicon 추론이 MLX가 약간 빠르다고 해서 Claude Code 뒤에 붙이려 한다 — 틀렸다.
Claude Code 병목은 tok/s가 아니라 보통:
- 안정적인 HTTP serve(
:11434) - 다회 tool loop 지연·타임아웃
- context / 모델 tag 관리와 팀 공유
Claude Code / Cursor에는 MLX를 런타임 백엔드로 쓰지 않는다. FastAPI로 HTTP를 감싸는 것은 자체 glue이며, 운영 비용은 대개 Ollama 직결보다 크다.
Claude Code 런타임 3계층(선택은 중간층만)
Claude Code 로컬 모델의 올바른 그림은 «Ollama vs MLX 이원»이 아니라 3계층 분업:
| 계층 | 내용 | 선택? |
|---|---|---|
| 앱 계층 | Claude Code, Cursor, Agent tool loop | 아니오(여기서 작업) |
| 런타임 계층 | Ollama(본 글 유일 권장) · HTTP :11434 | 예 — 본 규범은 Ollama 고정 |
| 연산 계층 | MLX · 오프라인 벤치 / CI / 연구 | 아니오(Claude Code 주 경로 밖) |
선택은 런타임 계층에서만, 연산 계층이 아니다. Claude Code 로컬 모델 독자에게 MLX가 빨라도 런타임 결론은 변하지 않는다.
Claude Code 로컬 모델 연결(실전)
Claude Code 로컬 모델 기본: ANTHROPIC_BASE_URL → 로컬 Ollama :11434. MLX는 이 체인에 없다.
brew install ollama
ollama pull qwen2.5-coder:7b
ollama serveexport ANTHROPIC_BASE_URL=http://127.0.0.1:11434
export ANTHROPIC_AUTH_TOKEN=ollama
export ANTHROPIC_API_KEY=설정 후 Claude Code는 로컬 모델 사용. 또는 ollama launch claude --model qwen2.5-coder:7b. 비용·팀 → Claude Code + Ollama 실측.
16GB M4 Mac Mini 강력 권장
- 7B 모델(예:
qwen2.5-coder:7b) - 14B + Chrome + IDE로 메모리를 계속 꽉 채우지 말 것
- MLX로 바꿔도 swap이 «최적화»되지는 않음
MLX가 가끔 더 빠른 이유(런타임 결정은 그대로)
아래 숫자는 Ollama vs MLX Apple Silicon 추론 벤치 차이 설명용 — «Claude Code → Ollama만»은 바뀌지 않음.
- MLX: Metal 커널 직접 + 배열 연산
- Ollama: llama.cpp + HTTP + 런타임 서비스 오버헤드
MLX는 서비스 껍질이 얇다 — 차이는 보통 작다:
- 16GB: 약 0 %–5 %
- 24GB: 약 5 %–8 %
- 48GB: 약 8 %–12 %
설명: 구간은 Macstripe Lab 추세(Llama-3.1-8B 4-bit, 2026년 6월), 선택에 쓰지 않음. 16GB Ollama 약 27–31, MLX 약 28–32 tok/s; 48GB Ollama 약 72–78, MLX 약 80–88 tok/s. 방법 → Hub 실측.
Claude Code에 Ollama만 있는 이유
M4 Mac Mini 로컬 LLM 일상에서 Claude Code가 보는 것은 생성 속도만이 아니다:
| 지표 | Agent 관점 |
|---|---|
| tok/s | 낮음 |
| API 안정성 | 높음 |
| tool loop 지연 | 매우 높음 |
| 유지보수(pull / serve / 공유) | 매우 높음 |
Agent 연결 방식 ≫ 몇 퍼센트 추론 차이.
실제 실패 사례(16GB · M4 Mac Mini 로컬 LLM)
Claude Code 로컬 모델 일상 부하에서 동시 실행: Claude Code · Ollama qwen2.5-coder:14b · Chrome(약 15탭) · VS Code(m4-16gb-lab-01, 2026-05-28).
- 메모리 압력: 빨강
- swap: 8GB+
- tok/s: 약 28–31 → 한 자릿수
- Claude Code: 타임아웃
결론: MLX/Ollama 문제가 아니라 메모리 단계·모델 크기 선택 오류. → 7B vs 14B
2026 권장 모델 조합(실전)
| 시나리오 | 권장 |
|---|---|
| Claude Code | qwen2.5-coder:7b |
| 범용 Agent | Qwen3 8B(ollama pull qwen3:8b) |
| 추론형 | DeepSeek-R1 distill |
| 벤치 대조 | Llama 3.1 8B |
M4 Mac Mini 로컬 LLM 팀: 한 대에서 ollama serve, 전원 Claude Code를 같은 :11434로; MLX는 그 Mac에서 야간 벤치만, Agent에는 연결하지 않음.
최종 규칙(본 글 Runtime Spec)
Claude Code / Cursor / 표준 Agent tool loop에서 로컬 모델은 HTTP 추론 런타임 계층을 탄다 — 본 규범에서는 Ollama. MLX는 연산 계층 도구이며 Agent 런타임이 바로 나오지 않는다; 본 글은 «MLX + 자체 HTTP»를 Claude Code 권장 아키텍처로 두지 않는다.
엔지니어링 유보: 극히 드문 자체 Agent 런타임(Claude Code/Cursor 아님, 자체 GW·SLA)에서는 MLX + HTTP 가능 — 본 글 범위 밖, Claude Code 로컬 모델 결론은 동일.
FAQ
MLX HTTP를 직접 만들어 Claude Code에 연결?
Claude Code용: 비권장. 기술적으로 가능하나 호환·모델 관리·안정성을 짊어진다 — 대개 Ollama보다 나쁘다. 자체 Agent 플랫폼(Claude Code 아님)은 MLX+HTTP 가능, 본 글 권장 아키텍처 아님(유보 참고).
MLX가 Ollama를 대체할 수 있나?
본 규범에서는 불가. Claude Code/Cursor 권장 런타임은 Ollama; MLX는 오프라인 벤치용, Agent에서 Ollama를 대체하지 않음.
Ollama가 더 느린가?
swap 없이 같은 모델 벤치에서는 Ollama가 몇 포인트 느릴 수 있다. 일상 코딩·Agent에서는 거의 체감 없음 — 병목은 연결과 메모리.
24GB vs 48GB?
24GB: 7B/8B, 개인 또는 경량 Agent. 48GB: 14B, 다인 공유, 긴 num_ctx. 기기 업그레이드가 Ollama↔MLX보다 효과 큰 경우가 많다.
MLX가 꼭 필요한 때?
벤치마크, CI 회귀, 연구 스크립트(야간 tok/s, 신규 양자화, mlx-community 검증)만. Claude Code 런타임에는 넣지 않음; MLX가 있어도 Agent는 Ollama만.
의사결정 경로(마무리)
자세히 → 최종 규칙. 설정 → Claude Code + Ollama(④단계).
메모리 노드(필연 도출, 주관적 추천 아님)
전제(고정): 런타임 = Ollama(Claude Code 로컬 모델 규범)
부하: Claude Code(Ollama) + 14B + 다인 tool loop + ollama serve
유일 병목: 통합 메모리 — 가중치 + KV + 컨텍스트 + IDE/브라우저 동일 풀
결론(도출): 24GB / 48GB 전용 M4 추론 노드 필요 — «MLX를 고른다»가 아니라 메모리 단계 부족
16GB: 개인 7B + 로컬 Ollama; 14B 다인 공유에 들어가면 변수는 «Ollama vs MLX»에서 «통합 메모리가 충분한가»로 → Macstripe 24GB/48GB + ollama serve 클러스터.
최종 결론
Apple Silicon에서 Ollama vs MLX는 대등한 선택이 아니다: Agent → Ollama, 벤치 → MLX; 진짜 막는 것은 M4 Mac Mini 로컬 LLM의 메모리 단계와 모델 크기다.
