Ollama 0.19, Apple Silicon에서 MLX 백엔드로 전환 — 속도 대폭 향상 (Preview)
Ollama is now powered by MLX on Apple Silicon in preview
TL;DR Highlight
Ollama가 Apple Silicon에서 llama.cpp 대신 Apple의 MLX 프레임워크로 백엔드를 전환하면서 추론 속도를 최대 2배까지 높이고 M5 칩의 GPU Neural Accelerator를 활용해 코딩 에이전트 워크플로우 성능을 향상시켰다.
Who Should Read
Mac(Apple Silicon)에서 Claude Code, Codex 같은 코딩 에이전트나 로컬 LLM을 돌리고 있는 개발자. 특히 32GB 이상 통합 메모리를 가진 MacBook/Mac Studio 사용자.
Core Mechanics
- Ollama 0.19부터 macOS의 추론 백엔드가 기존 llama.cpp(GGUF 포맷)에서 Apple이 만든 머신러닝 프레임워크인 MLX로 바뀌었다. MLX는 Apple Silicon의 통합 메모리 아키텍처에 최적화되어 CPU/GPU/Neural Engine이 메모리를 공유하는 구조를 적극 활용한다.
- M5 Max 기준으로 Prefill 속도(첫 토큰이 나오기까지 프롬프트를 처리하는 속도)가 0.18 버전의 1154 tokens/s에서 0.19 버전에서 1810 tokens/s로 약 57% 향상됐고, Decode 속도(토큰을 생성하는 속도)는 58 tokens/s에서 112 tokens/s로 약 93% 향상됐다. 테스트 모델은 Alibaba의 Qwen3.5-35B-A3B.
- M5, M5 Pro, M5 Max 칩에서는 새로 추가된 GPU Neural Accelerator를 활용해 TTFT(Time To First Token, 첫 응답 지연)와 토큰 생성 속도 모두를 추가로 끌어올린다.
- 이번 업데이트에서 NVFP4(NVIDIA가 개발한 4비트 부동소수점 양자화 포맷)를 지원하기 시작했다. 기존 Q4_K_M 대비 모델 정확도를 더 잘 유지하면서도 메모리 사용량과 스토리지를 줄인다. 클라우드 프로덕션 환경에서 주로 쓰이는 포맷이라, 로컬과 프로덕션 결과를 동일하게 비교할 수 있게 된다.
- 캐시 시스템이 크게 개선됐다. 이제 여러 대화에 걸쳐 캐시를 재사용하므로 Claude Code처럼 시스템 프롬프트를 공유하는 도구에서 메모리 사용량이 줄고 캐시 히트율이 높아진다. 또한 프롬프트 내 적절한 위치에 스냅샷을 저장하는 '지능형 체크포인트' 기능과, 오래된 브랜치가 삭제돼도 공유 프리픽스는 더 오래 유지되는 스마터 eviction(캐시 제거) 정책도 추가됐다.
- 이번 프리뷰 릴리즈에서 공식 추천 모델은 코딩 작업용으로 튜닝된 Qwen3.5-35B-A3B NVFP4 버전이다. 실행하려면 32GB 이상의 통합 메모리가 필요하며, Claude Code나 OpenClaw 같은 코딩 에이전트와 연동해 사용하는 시나리오를 주 타깃으로 한다.
- 향후 커스텀 파인튜닝 모델을 Ollama로 더 쉽게 임포트할 수 있는 방법과, 지원 아키텍처 확장을 예고했다. 현재는 특정 아키텍처만 MLX 경로를 탄다.
Evidence
- M4 Pro + 48GB RAM 환경에서 직접 벤치마크를 돌린 사람이 결과를 공유했다. 같은 Qwen3.5-35B-A3B 모델을 포맷별로 비교하면 NVFP4(PromptEval 13.2 t/s, Decode 66.5 t/s)가 Q4_K_M(6.6 t/s, 30.0 t/s)보다 약 2배 빠르고, int4(59.4 t/s, 84.4 t/s)가 가장 빨랐다. 단, 품질 차이는 직접 확인하지 않았다고 밝혔다.
- LM Studio는 이미 오래 전부터 MLX를 지원해왔다는 지적이 있었고, 일부는 GGUF 포맷이 벤치마크상 일관되게 더 좋은 결과를 냈다는 경험을 공유했다. 차이가 크지는 않지만 존재한다는 의견이었다. Ollama가 뒤늦게 MLX를 도입했다는 시각도 있었다.
- M2 Max 96GB에서 llama.cpp로 Qwen 70B 4비트를 이미 잘 쓰고 있다는 사용자가, MLX 전환으로 메모리 핸들링이 나아질지 기대하면서도 GGUF 경로와 대형 모델에서 실제 성능 비교가 궁금하다고 했다. Ollama가 기존에 llama.cpp를 내부적으로 사용하고 있었다는 점도 이 댓글에서 재확인됐다.
- M4 Max 48GB RAM 사용자가 'Hello world' 같은 간단한 질문에도 6~25초가 걸린다고 문의했는데, 이는 추론 자체보다 모델이 '생각(thinking)' 과정을 거치기 때문으로 보인다. 코딩용 모델 특성상 thinking이 기본 활성화돼 있을 수 있어 설정 확인이 필요하다는 맥락이었다.
- 온디바이스 LLM의 미래에 대해 긍정적인 시각이 다수였다. 프라이버시, 외부 API 의존성 제거, 데이터센터 수요 분산, 전력 절감 등을 이유로 들었다. 반면 16GB RAM Mac에서는 아직 코딩 에이전트를 쾌적하게 쓰기 어렵다는 현실적인 한계를 지적하는 댓글도 있었다.
How to Apply
- M1/M2/M3/M4 Mac(32GB 이상)에서 Claude Code를 로컬 LLM과 연동해 쓰고 싶다면, Ollama 0.19로 업그레이드 후 `ollama launch claude --model qwen3.5:35b-a3b-coding-nvfp4` 명령어로 바로 시작할 수 있다. 기존 0.18 대비 Decode 속도가 약 2배 빨라져 에이전트 루프 대기 시간이 체감상 크게 줄어든다.
- 긴 시스템 프롬프트나 대용량 컨텍스트(50k+ 토큰)를 반복적으로 처리하는 RAG나 에이전트 워크플로우를 Mac 로컬에서 돌리고 있다면, 새로운 지능형 캐시 체크포인트 기능 덕분에 동일 프리픽스 반복 처리 비용이 줄어드니 업그레이드만 해도 효과를 볼 수 있다.
- M5 Max처럼 최신 칩을 쓰고 있다면 NVFP4 양자화 모델을 우선 사용하자. int4보다 품질이 안정적이고, 클라우드 프로덕션(NVIDIA GPU 서버)과 동일한 포맷이라 로컬 테스트 결과를 프로덕션에 그대로 적용할 수 있다.
- Ollama 대신 llama.cpp나 LM Studio를 이미 쓰고 있고 GGUF 모델로 만족하는 경우라면, 커뮤니티 벤치마크상 품질 차이가 소폭 존재한다는 의견이 있으니 바로 전환하기보다 동일 모델로 직접 품질을 비교해보고 결정하는 것이 좋다.
Code Example
# Claude Code와 연동
ollama launch claude --model qwen3.5:35b-a3b-coding-nvfp4
# OpenClaw과 연동
ollama launch openclaw --model qwen3.5:35b-a3b-coding-nvfp4
# 직접 채팅
ollama run qwen3.5:35b-a3b-coding-nvfp4
# 성능 측정 (--verbose 플래그 사용)
ollama run qwen3.5:35b-a3b-nvfp4 "calculate fibonacci numbers in a one-line bash script" --verbose
# 포맷별 성능 비교 결과 (M4 Pro 48GB 기준)
# Model PromptEvalRate EvalRate
# qwen3.5:35b-a3b-q4_K_M 6.6 t/s 30.0 t/s
# qwen3.5:35b-a3b-nvfp4 13.2 t/s 66.5 t/s
# qwen3.5:35b-a3b-int4 59.4 t/s 84.4 t/sTerminology
관련 논문
Bash4LLM+ – 의존성 없는 경량 Bash LLM API 래퍼
Python이나 Node.js 없이 순수 Bash만으로 Groq 등 OpenAI 호환 LLM API를 호출할 수 있는 단일 스크립트 도구로, Termux(Android)를 포함한 모든 Unix 환경에서 동작한다.
Wayfinder Router: 로컬과 hosted LLM 간 deterministic 쿼리 라우팅 도구
프롬프트의 복잡도를 모델 호출 없이 오프라인으로 점수화해서 간단한 쿼리는 로컬 모델로, 어려운 쿼리는 유료 모델로 자동 라우팅하는 CLI 도구다. LLM 비용을 줄이면서도 응답 품질을 유지하고 싶은 개발자에게 유용하다.
Apple Neural Engine: 아키텍처, 프로그래밍, 성능 (리버스 엔지니어링 가이드)
Apple 기기에 내장된 AI 전용 칩인 ANE(Apple Neural Engine)를 리버스 엔지니어링으로 분석한 302페이지짜리 기술 문서로, Core ML 아래 숨겨진 내부 구조와 직접 접근 경로를 처음으로 공개한다.
DSpark: Speculative Decoding으로 LLM 추론 속도를 획기적으로 높인 DeepSeek의 새 논문
DeepSeek이 Speculative Decoding을 개선한 DSpark 기법을 공개했는데, 같은 시스템 용량 기준으로 사용자당 생성 속도가 57~78% 빨라졌다고 한다. 이게 DeepSeek이 경쟁사 대비 훨씬 싼 가격으로 Pro 모델을 제공할 수 있는 핵심 기술 중 하나일 가능성이 높다.
Claude Code, Codex, Cursor에서 바로 쓰는 Smart Model Routing 도구
프롬프트마다 적합한 AI 모델을 50ms 이내에 자동으로 선택해주는 프록시 라우터로, API 비용을 40~70% 절감할 수 있다고 주장하는 오픈소스 도구다. 단, 프롬프트 캐싱 손실 문제로 커뮤니티 반응은 엇갈린다.
900KB Transformer를 과적합시켜 100MB CSV를 7MB로 압축한 실험
단일 파일을 통째로 암기하도록 Transformer를 과적합(overfitting)시킨 뒤 arithmetic coding으로 압축하는 실험으로, 100MB CSV를 7MB(~0.5 bits/byte)까지 줄이는 데 성공했다. 모델이 '범용 이해' 대신 '특정 파일 완전 암기'를 목표로 한다는 점에서 전통적 ML 학습과 정반대 방향이라 흥미롭다.