Ollama가 MLX를 품었다, Apple Silicon 로컬 AI 추론 속도가 2배가 된 이유
Ollama v0.19가 Apple MLX 프레임워크를 통합해 디코드 속도 2배 향상을 달성했습니다. 로컬 AI 추론이 실용적 수준에 도달한 전환점과 5개 도구의 경쟁 구도를 분석합니다.
Ollama가 드디어 Apple의 MLX 프레임워크를 품었습니다. 3월 30일 공개된 v0.19.0 프리뷰에서 Apple Silicon Mac의 로컬 LLM 추론 속도가 디코드 기준 약 2배 향상되었습니다. Hacker News에서 532포인트와 263개의 댓글을 기록하며 개발자 커뮤니티를 달궜습니다. 단순한 버전 업데이트가 아닙니다. 월 5,200만 다운로드를 기록하는 가장 대중적인 로컬 LLM 도구가, Apple이 자사 칩에 맞춰 만든 추론 엔진을 공식 백엔드로 채택한 것입니다.
이 통합이 왜 중요한지, 실제 성능은 얼마나 달라졌는지, 그리고 Ollama를 포함한 5개 로컬 AI 도구의 경쟁 구도가 어떻게 재편되고 있는지 함께 살펴보겠습니다.
왜 지금 로컬 AI인가
로컬 AI 추론에 대한 관심이 급격히 높아지고 있습니다. 그 배경에는 세 가지 구조적 동인이 있습니다.
첫째, 비용 입니다. Claude, GPT-4, Gemini 같은 프론티어 모델의 API 요금은 월 15달러에서 45달러, 그 이상까지 올라갑니다. 개인 개발자나 소규모 팀에게는 매월 반복되는 부담입니다. 로컬 추론은 하드웨어에 대한 일회성 투자 이후 추가 비용이 제로입니다.
둘째, 프라이버시 입니다. 코드, 내부 문서, 고객 데이터를 제3자 서버로 전송하는 것은 기업 보안 정책과 충돌하는 경우가 많습니다. 로컬에서 돌리면 데이터가 기기를 떠나지 않습니다.
셋째, 레이턴시와 오프라인 입니다. 네트워크 왕복이 없는 즉각적 응답, 그리고 비행기 안에서도 AI를 쓸 수 있다는 것은 생각보다 큰 차이를 만듭니다.
문제는 그동안 로컬 AI가 "쓸 수는 있지만, 쾌적하지는 않은" 수준에 머물러 있었다는 점입니다. 특히 Apple Silicon Mac 사용자들은 칩의 잠재력을 온전히 활용하지 못하고 있었습니다. Ollama의 기존 백엔드인 llama.cpp는 크로스 플랫폼 범용 엔진으로 설계되었기 때문에, Apple Silicon의 고유한 강점을 살리는 데 한계가 있었습니다.
Apple Silicon 통합 메모리, 왜 로컬 AI에 최적인가
Apple Silicon의 가장 독특한 특징은 통합 메모리 아키텍처(Unified Memory Architecture) 입니다. CPU와 GPU가 물리적으로 동일한 메모리 풀을 공유합니다. 이것이 AI 추론에서 의미하는 바는 상당합니다.
일반적인 NVIDIA GPU 환경에서는 모델 가중치를 시스템 RAM에서 GPU의 VRAM으로 복사해야 합니다. 이 과정에서 시간과 메모리가 모두 소모됩니다. VRAM 용량이 모델 크기의 상한선이 되기도 합니다. 소비자용 GPU의 VRAM은 보통 8GB에서 24GB 수준입니다.
Apple Silicon에서는 이 병목이 존재하지 않습니다. 데이터 복사 제로 입니다. CPU와 GPU가 같은 메모리에 직접 접근하므로, 시스템 전체 메모리를 AI 추론에 그대로 활용할 수 있습니다. 24GB Mac이면 8B 파라미터 모델을 BF16으로, 또는 30B급 MoE 모델을 4-bit 양자화로 구동할 수 있습니다. 32GB 이상이면 35B급 모델까지 올라갑니다.
Apple의 MLX 프레임워크는 바로 이 통합 메모리 위에서 동작하도록 설계된 전용 추론 엔진입니다. NumPy와 유사한 API를 제공하면서, lazy computation과 커널 퓨전 같은 최적화를 Apple Silicon에 맞춰 구현합니다. llama.cpp가 "어디서든 돌아가는" 엔진이라면, MLX는 "Apple Silicon에서 가장 빠르게 돌아가는" 엔진입니다.
Ollama 0.19, 숫자로 보는 성능 도약
Ollama가 공식 블로그에서 공개한 벤치마크를 보겠습니다. 테스트 모델은 Alibaba의 Qwen3.5-35B-A3B이며, NVFP4 양자화와 Q4_K_M 양자화를 비교했습니다.
Qwen3.5-35B-A3B · Apple Silicon · M5 Neural Accelerator + Metal 4 TensorOps
Prefill 속도 (tok/s)
Decode 속도 (tok/s)
Prefill 속도 는 1,154 tok/s에서 1,810 tok/s로, 1.57배 향상되었습니다. Prefill은 입력 프롬프트를 처리하는 단계로, TTFT(Time to First Token)에 직접 영향을 미칩니다. 사용자가 질문을 던진 후 첫 응답이 나타나기까지의 대기 시간이 크게 줄어든 것입니다.
Decode 속도 는 58 tok/s에서 112 tok/s로, 약 2배(1.93x) 가까이 뛰었습니다. Decode는 토큰을 하나씩 생성하는 단계입니다. 실제로 텍스트가 타이핑되듯 화면에 나타나는 속도가 두 배로 빨라진 것입니다. MLX의 int4 모드를 사용하면 134 tok/s까지 도달합니다.
이 수치가 실감나지 않을 수 있습니다. 112 tok/s는 초당 약 80-90 단어를 생성하는 속도입니다. 사람이 읽는 것보다 빠릅니다. 35B 파라미터 모델이 로컬에서 이 정도 속도로 응답한다는 것은, 클라우드 API의 응답 속도와 체감상 큰 차이가 나지 않는 수준입니다.
M5 Neural Accelerator, 한 단계 더 나아간 가속
Apple이 M5 시리즈에 탑재한 GPU Neural Accelerator는 이 수치를 더 끌어올립니다. Apple Machine Learning Research 팀이 발표한 데이터에 따르면, M5는 M4 대비 TTFT에서 3.3배에서 4.0배 개선을 보여줍니다. 토큰 생성 속도도 19%에서 27% 추가 향상됩니다.
구체적으로 살펴보면, Qwen 14B 4-bit 모델(9.16GB)의 TTFT가 10초 이하로 떨어졌습니다. Qwen 30B MoE 4-bit 모델(17.31GB)은 TTFT 3초 이하를 달성합니다. M5의 메모리 대역폭이 153GB/s로 M4의 120GB/s 대비 28% 향상된 것이 핵심 요인입니다. LLM 추론은 본질적으로 메모리 대역폭에 의존하는(memory-bandwidth bound) 작업이기 때문입니다.
macOS 26.2에서 MLX의 M5 Neural Accelerator 지원이 활성화되었으며, 이미지 생성 모델인 FLUX-dev-4bit(12B)에서는 M4 대비 3.8배 빠른 생성 속도를 기록했습니다. Apple이 칩 레벨에서 로컬 AI 추론을 전략적으로 밀고 있다는 신호입니다.
NVFP4와 캐싱, 세부적인 개선들
Ollama 0.19는 NVIDIA의 NVFP4 양자화 포맷을 지원합니다. 프로덕션 환경에서 사용하는 것과 동일한 양자화 표준을 로컬에서도 쓸 수 있다는 의미입니다. 모델 정확도를 유지하면서 메모리 사용량과 대역폭 요구를 줄입니다.
캐싱 개선도 눈에 띕니다. 교차 대화 캐시 재사용 으로 메모리 소비가 줄었고, 프롬프트 처리 중 체크포인트 스냅샷 을 주기적으로 생성하여 처리 시간을 단축합니다. 분기 대화에서도 접두사 캐시가 유지됩니다. 코딩 에이전트처럼 긴 컨텍스트를 반복적으로 참조하는 워크플로우에서 체감 효과가 큽니다.
5개 도구가 겨루는 로컬 AI 추론 전쟁
Ollama의 MLX 통합은 로컬 AI 추론 도구 시장의 경쟁을 더욱 뜨겁게 만들고 있습니다. 현재 Apple Silicon에서 경쟁하는 주요 도구 5개를 비교해 보겠습니다.
| 도구 | 설치 난이도 | Apple Silicon 최적화 | API 호환 | 타겟 | 비용 |
|---|---|---|---|---|---|
| Ollama 0.19 | 원클릭 | MLX + llama.cpp | OpenAI 호환 | 개인 개발자 | 무료 |
| LM Studio | GUI 설치 | Metal (llama.cpp) | OpenAI 호환 | GUI 선호 사용자 | 무료 |
| Swama | CLI | MLX 네이티브 | OpenAI 호환 | Apple Silicon 전용 | 무료 |
| vLLM-MLX | 고급 CLI | MLX 네이티브 | OpenAI 호환 | 서버급 처리량 | 무료 (OSS) |
| Docker Model Runner | Docker CLI | vLLM + Metal | OpenAI 호환 | Docker 생태계 | 베타 |
Ollama 0.19 는 MLX와 llama.cpp 이중 백엔드를 갖추게 되었습니다. 월 5,200만 다운로드의 압도적인 사용자 기반과 자체 모델 라이브러리가 최대 강점입니다. CLI와 HTTP API를 제공하며, OpenAI 호환 API도 지원합니다. 단점은 연속 배치(continuous batching)를 아직 지원하지 않는다는 점입니다.
LM Studio 는 GUI 기반으로 초보자에게 가장 친화적인 도구입니다. HuggingFace의 GGUF 모델을 직접 불러올 수 있으며, llama.cpp 위에서 Metal을 통해 Apple Silicon을 활용합니다. MLX 네이티브 통합은 아직 없어서, 이번 Ollama의 행보로 Apple Silicon 최적화 측면에서 한 발 뒤처지게 되었습니다.
Swama 는 가장 급진적인 접근을 택한 도구입니다. Apple Silicon 전용으로, 순수 Swift로 작성되었습니다. MLX를 네이티브로 사용하며, 비전 모델과 음성 인식, 임베딩을 기본 지원합니다. 개발자 Edward Tsang은 이렇게 말했습니다.
"Ollama가 결국 MLX 지원을 추가하면 돌아갈 수도 있지만, Swama가 그때쯤 더 나은 기능을 갖출 수도 있습니다."
(원문: "Ollama may eventually add MLX support, and I may switch back, but Swama might have better features by then.")
Ollama 0.19가 정확히 MLX를 통합하면서 Swama의 차별점이 줄어들었습니다. 하지만 Swift 네이티브의 성능 이점과 멀티모달 기능은 여전히 Swama만의 영역입니다.
vLLM-MLX 는 기술적으로 가장 야심찬 프로젝트입니다. M4 Max에서 최대 525 tok/s라는 인상적인 수치를 기록했으며, llama.cpp 대비 21%에서 87% 높은 처리량을 보여줍니다. 핵심 차별점은 연속 배치 입니다. 16개 동시 요청에서 총 처리량이 4.3배 증가합니다. MCP tool calling과 멀티모달도 지원합니다. 다만 아직 v0.2.6 초기 단계입니다.
Docker Model Runner 는 Docker 생태계와의 통합이 강점입니다. vLLM을 Metal 위에서 구동하며, 기존 Docker 워크플로우에 로컬 AI 추론을 자연스럽게 녹일 수 있습니다. 아직 Alpha/Beta 단계이지만, Docker의 거대한 사용자 기반을 고려하면 잠재력이 큽니다.
경쟁의 핵심 축
이 다섯 도구의 경쟁에서 세 가지 축이 두드러집니다.
첫째는 편의성 vs 성능 입니다. Ollama와 LM Studio가 쉬운 설치와 넓은 모델 생태계로 대중성을 확보한 반면, Swama와 vLLM-MLX는 Apple Silicon 전용 최적화로 원시 성능에서 앞섭니다.
둘째는 단일 사용자 vs 다중 동시 접속 입니다. Ollama와 LM Studio는 개인 개발자의 단일 세션에 최적화된 반면, vLLM-MLX와 Docker Model Runner는 연속 배치로 여러 요청을 동시에 처리하는 서버 시나리오를 겨냥합니다.
셋째는 모델 포맷 생태계 입니다. Ollama의 자체 라이브러리와 LM Studio의 GGUF 생태계가 모델 다양성에서 우위를 가지며, MLX 네이티브 포맷은 아직 모델 수가 상대적으로 적습니다.
개발자 실무에 미치는 영향
어떤 모델을 로컬에서 돌릴 수 있는가
메모리별로 실용적으로 구동 가능한 모델 규모를 정리하면 다음과 같습니다.
- ▸ Llama 3.1 8B (4-bit)
- ▸ Qwen 2.5 7B (4-bit)
- ▸ Mistral 7B (4-bit)
코드 자동완성, 문서 요약, 번역
- ▸ Qwen 14B (4-bit)
- ▸ Qwen3.5-35B-A3B (4-bit)
- ▸ 30B MoE 모델 (4-bit)
코딩 어시스턴트 실용 구간 진입 · MLX 백엔드 필수
- ▸ Qwen 32B (4-bit)
- ▸ DeepSeek 33B (4-bit)
- ▸ Llama 3.1 70B (저정밀도)
프론티어급 80%+ 성능 · 복잡한 추론 가능
- ▸ Llama 3.1 70B (4-bit)
- ▸ Mistral Large (4-bit)
- ▸ Qwen 72B (4-bit)
Mac Studio / Mac Pro · 소규모 팀 AI 서버 구축
16GB Mac 에서는 Llama 3.1 8B, Qwen 2.5 7B 같은 7B-8B급 모델을 4-bit 양자화로 실행할 수 있습니다. 간단한 코드 자동완성, 문서 요약, 번역 작업에 충분합니다.
24GB Mac 에서는 Qwen 14B를 4-bit로, 또는 8B 모델을 BF16 풀 정밀도로 구동할 수 있습니다. 30B급 MoE(Mixture of Experts) 모델도 올라갑니다. 이 구간부터 코딩 어시스턴트로서의 실용성이 확보됩니다.
32GB Mac 에서는 이번 벤치마크의 주인공인 Qwen3.5-35B-A3B를 돌릴 수 있습니다. 35B급은 상당수 작업에서 프론티어 모델의 70-85% 성능을 보여줍니다. 다만, Ollama 0.19의 MLX 통합은 현재 32GB 이상에서만 지원된다는 점을 유의해야 합니다.
64GB 이상 이면 Llama 3.1 70B 같은 대형 모델까지 4-bit로 구동 가능합니다.
개발 워크플로우의 변화
로컬 추론 속도가 실용적 수준에 도달하면서, 개발자들의 작업 패턴도 변화하고 있습니다.
코딩 에이전트 로컬 실행 이 현실이 되고 있습니다. Claude Code, OpenCode, Codex 같은 에이전트를 로컬 모델로 구동하면, API 비용 없이 코드 리뷰, 리팩토링, 테스트 생성을 자동화할 수 있습니다. 디코드 속도 2배 향상은 이 시나리오에서 직접적인 체감 차이를 만듭니다.
VS Code 에이전트 모드 와의 연동도 확대되고 있습니다. Ollama v0.18.3부터 VS Code의 에이전트 모드를 지원하며, MLX 백엔드의 속도 향상이 여기에도 적용됩니다.
프라이빗 AI 어시스턴트 구축 사례도 늘고 있습니다. 소규모 사업체에서 Qwen 3.5를 Mac에 올려 고객 응대나 문서 처리에 활용하는 패턴이 등장했습니다. Hacker News 토론에서는 이것이 엔터프라이즈 AI 라이선스보다 저렴하다는 비용 분석이 공유되기도 했습니다.
로컬 AI의 현실적 한계
물론 한계도 분명합니다. 로컬 모델은 프론티어 모델의 70-85% 수준이라는 품질 격차가 존재합니다. 환각(hallucination) 빈도도 프론티어 대비 높습니다. 에너지 효율 측면에서는 데이터센터의 배치 처리가 로컬 단일 추론보다 효율적이라는 지적도 있습니다.
Ollama 0.19의 MLX 통합도 아직 프리뷰 단계입니다. 32GB 이상의 통합 메모리가 필요하고, 현재 Qwen3.5 모델만 우선 지원됩니다. macOS 26.2 이상이 필요하며, 안정성 이슈가 있을 수 있습니다. 프로덕션 환경에서의 사용은 정식 릴리스 이후를 권장합니다.
커뮤니티 반응, "하이브리드가 답이다"
Hacker News에서 532포인트와 263개의 댓글을 기록한 이 뉴스에 대한 반응은 열광과 현실론이 공존합니다.
긍정적인 쪽에서는 로컬 AI의 미래에 대한 기대가 뚜렷합니다.
"온디바이스 모델이 미래입니다. 사용자들이 선호하고, 프라이버시 이슈가 없습니다."
(원문: "On-device models are the future. Users prefer them. No privacy issues.")
Mac으로 소규모 사업체에서 Qwen 3.5를 구동하는 것이 엔터프라이즈 라이선스보다 저렴하다는 비용 분석이 호응을 얻었고, 코딩 에이전트를 로컬에서 실행하는 것에 대한 기대감도 높았습니다.
회의적인 시각도 만만치 않습니다.
"로컬 모델은 원격 모델만큼 잘 작동하지 않습니다. 유일한 장점은 프라이버시뿐입니다."
(원문: "Local models don't work remotely as well...The only upside is privacy.")
프라이버시 자체에 대한 근본적 회의도 있었습니다.
"사용자들은 프라이버시에 신경 쓰지 않습니다. 만약 신경 썼다면, Meta와 Alphabet이 1조 달러 이상의 가치를 지니고 있을까요?"
(원문: "Users don't care about privacy. If they did, Meta and Alphabet wouldn't be worth $1T+.")
기술적 논점도 활발했습니다. llama.cpp(GGML + Metal)과 MLX는 완전히 별개의 프레임워크라는 점을 명확히 하는 댓글이 여러 개 올라왔습니다. MLX가 순수 속도에서 우위를 점하는 반면, llama.cpp는 GGUF 포맷 생태계, 즉 모델 다양성에서 강점을 유지합니다.
Reddit r/LocalLLaMA에서도 비슷한 논의가 진행되었습니다. 커뮤니티의 컨센서스는 명확합니다.
"Ollama는 편의성(convenience)으로, MLX는 Apple Silicon의 깊은 최적화로 각자 승리한다."
두 도구를 함께 사용하는 패턴, 즉 "Ollama를 쉬운 런타임으로, MLX를 더 깊은 최적화의 토끼굴로" 활용하는 접근이 선호되고 있습니다. 흥미롭게도 llama-swap이라는 제3의 도구가 모델 간 핫스왑을 Ollama나 LM Studio보다 잘 처리한다며 주목받기도 했습니다.
가장 강한 컨센서스는 "하이브리드 아키텍처" 입니다. 로컬 모델이 일상적인 작업을 처리하고, 복잡한 쿼리는 클라우드 프론티어 모델로 위임하는 구조가 현실적이라는 데 대다수가 동의합니다. 로컬 AI가 클라우드를 대체하는 것이 아니라, 보완하는 것입니다.
로컬 AI의 다음 단계
Ollama의 MLX 통합은 시작점입니다. 앞으로 어떤 방향으로 전개될까요?
모델 지원 확대 가 가장 급선무입니다. 현재 Qwen3.5만 우선 지원되지만, Llama, Mistral, Gemma 등 주요 모델로 확대될 예정입니다. 모델 다양성이 확보되어야 MLX 백엔드가 기본 선택지로 자리잡을 수 있습니다.
16GB Mac 지원 도 관건입니다. 현재의 32GB 이상 제한이 풀리면 훨씬 더 넓은 사용자층에 도달합니다. MacBook Air와 기본형 MacBook Pro 사용자까지 포함되기 때문입니다.
Apple의 전략적 의도 도 주목할 부분입니다. M5의 Neural Accelerator, macOS 26.2의 MLX 지원 강화, 그리고 Apple Machine Learning Research 팀의 적극적인 벤치마크 공개. Apple은 자사 하드웨어를 AI 추론 플랫폼으로 포지셔닝하는 데 상당한 리소스를 투입하고 있습니다. Ollama의 MLX 통합은 이 전략의 생태계 확장입니다.
연속 배치와 서빙 영역에서의 경쟁도 본격화될 것입니다. vLLM-MLX가 보여준 연속 배치의 4.3배 처리량 향상은, Ollama도 결국 이 기능을 구현해야 한다는 압력을 만듭니다. 개인 개발자의 단일 세션을 넘어, 소규모 팀이 로컬 Mac을 AI 서버로 활용하는 시나리오가 현실화되고 있기 때문입니다.
Apple Machine Learning Research · macOS 26.2 / Neural Accelerator
TTFT (Time to First Token) 개선율
토큰 생성 속도 및 메모리 대역폭
토큰 생성 속도 향상
M5 vs M4
메모리 대역폭
M4 → M5
대역폭 향상율
LLM 추론 핵심 지표
가장 큰 그림은 로컬과 클라우드의 공존 입니다. 로컬 AI는 클라우드 AI를 대체하지 않습니다. 대신 개발자에게 선택지를 줍니다. 빠른 프로토타이핑, 프라이버시가 중요한 작업, 오프라인 환경에서는 로컬 모델을 쓰고, 최고 품질이 필요한 복잡한 추론에서는 클라우드 프론티어 모델을 호출하는 하이브리드 워크플로우. Ollama 0.19의 MLX 통합은 이 하이브리드 구조에서 로컬 쪽의 실용성을 한 단계 끌어올린 전환점입니다.
로컬 AI 추론이 "가능하다"에서 "쾌적하다"로 넘어가는 경계에 우리가 서 있습니다. Apple Silicon의 통합 메모리와 MLX, 그리고 Ollama의 대중성이 만든 이 조합이 그 경계를 밀어내고 있습니다.