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
관련 논문
Swift로 LLM 학습시키기 Part 1: 행렬 곱셈을 Gflop/s에서 Tflop/s로 끌어올리기
Apple Silicon에서 Swift로 직접 행렬 곱셈 커널을 구현하며 CPU, SIMD, AMX, GPU(Metal)를 단계별로 최적화해 Gflop/s에서 Tflop/s 수준까지 성능을 높이는 과정을 상세히 설명한 글이다. 프레임워크 없이 LLM 학습의 핵심 연산을 밑바닥부터 구현하고 싶은 개발자에게 Apple Silicon의 성능 한계를 체감할 수 있는 드문 자료다.
fsync 없이 로컬 스토리지 엔진을 crash-consistent하게 만든 방법
FractalBits가 fsync 없이 SSD 전용 KV 스토리지 엔진을 구현해 동일 조건 대비 약 65% 높은 쓰기 성능을 달성한 설계 방법을 공유했다. fsync의 메타데이터 오버헤드를 피하기 위해 사전 할당, O_DIRECT, SSD 원자 쓰기 단위 정렬 저널을 조합한 구조가 핵심이다.
Google Chrome, 사용자 동의 없이 4GB AI 모델(Gemini Nano)을 몰래 설치
Google Chrome이 사용자 동의 없이 Gemini Nano 4GB 모델 파일을 자동 다운로드하고, 삭제해도 재다운로드되는 문제가 발견됐다. GDPR 위반 가능성과 수십억 대 기기에 적용될 때의 환경 비용 문제가 제기되고 있다.
OpenAI가 대규모 저지연 Voice AI를 제공하는 방법
OpenAI가 9억 명 이상의 사용자에게 실시간 음성 AI를 제공하기 위해 WebRTC 스택을 어떻게 재설계했는지 설명하는 글로, relay + transceiver 분리 아키텍처의 설계 결정과 trade-off를 상세히 다룬다.
Truncated Decoding Tree의 결정론적 탐색을 통한 효율적인 Test-Time Inference
Self-consistency의 중복 샘플링 낭비를 없애는 결정론적 트리 탐색 디코딩 기법 DLE로 수학/코드 추론 성능과 속도를 동시에 개선
GoModel – Go로 작성된 오픈소스 AI Gateway
OpenAI, Anthropic, Gemini 등 여러 AI 프로바이더를 하나의 OpenAI 호환 API로 묶어주는 Go 기반 오픈소스 AI 게이트웨이로, LiteLLM의 컴파일 언어 대안이다.