Mac에서 로컬 LLM을 사용하려고 검색하다 보면 거의 반드시 만나게 되는 이름이 있다.

MLX, Ollama, LM Studio

처음 로컬 LLM을 접하면 이 세 가지 가운데 하나를 선택해야 하는 것처럼 느껴진다.

나 역시 M4 Mac mini 24GB와 M1 Max 64GB MacBook Pro에서 로컬 LLM을 사용해보려고 관련 자료를 찾아보면서 자연스럽게 이 세 가지를 비교하게 됐다.

그런데 자료를 정리하다 보니 중요한 사실이 하나 있었다.

MLX와 Ollama, LM Studio는 사실 완전히 같은 종류의 프로그램이 아니다.

그래서 단순히

MLX가 빠른가?
Ollama가 빠른가?
LM Studio가 빠른가?

라고 비교하는 것부터 조금 잘못된 질문일 수 있다.

이번 글에서는 Apple Silicon Mac에서 로컬 LLM을 사용할 때 MLX, Ollama, LM Studio가 각각 어떤 역할을 하는지, 그리고 어떤 사용자에게 어떤 선택이 적합한지 정리해봤다.

먼저 결론부터

아주 간단하게 정리하면 다음과 같다.

목적추천

결국 하나가 무조건 다른 두 개보다 좋은 것은 아니다.

사용 목적이 다르다.

MLX는 정확히 무엇일까?

MLX는 Apple의 Machine Learning Research 팀이 만든 머신러닝 프레임워크다.

NumPy나 PyTorch와 비슷한 개념으로 볼 수 있다.

MLX의 가장 중요한 특징은 Apple Silicon의 Unified Memory, 통합 메모리 구조를 적극적으로 활용한다는 점이다.

Apple Silicon에서는 CPU와 GPU가 동일한 메모리 공간에 접근할 수 있다.

MLX에서는 배열 데이터를 CPU 메모리에서 GPU 메모리로 계속 복사할 필요 없이 같은 메모리를 CPU와 GPU가 사용할 수 있도록 설계되어 있다.

이 때문에 Apple Silicon과 굉장히 잘 맞는다.

MLX 자체는 단순한 LLM 실행 프로그램이 아니다.

머신러닝 모델을 만들고 실행하고 학습할 수 있는 프레임워크다.

그럼 MLX-LM은 무엇일까?

로컬 LLM 사용자 입장에서는 순수 MLX보다 MLX-LM을 접하게 될 가능성이 더 높다.

MLX-LM은 MLX를 이용해서 LLM을 실행하고 Fine-tuning하기 위한 패키지다.

모델 생성, 채팅, 양자화, LoRA 학습, 평가, 서버 실행 등의 기능을 제공한다. 공식 CLI에도 generate, chat, server, lora, benchmark, quant 관련 기능들이 포함돼 있다.

따라서

MLX = 기반 프레임워크

MLX-LM = MLX 기반 LLM 도구

라고 생각하면 이해하기 쉽다.

설치도 비교적 간단하다.

pip install mlx-lm

형태로 설치할 수 있다.

Apple Silicon에서 MLX 자체를 설치하려면 현재 공식 요구사항은 Apple Silicon, native Python 3.10 이상, macOS 14 이상이다.

MLX의 장점

MLX의 가장 큰 장점은 역시 Apple Silicon에 직접 접근한다는 것이다.

특히 다음과 같은 경우에 매력적이다.

• 모델별 성능 측정
• Prompt Processing 속도 측정
• Token 생성 속도 측정
• Peak Memory 측정
• 직접 Python 코드에서 모델 제어
• 양자화
• Fine-tuning
• LoRA
• 모델 구조 실험

MLX-LM의 생성 API에서는 실제로 Prompt TPS, Generation TPS, Peak Memory 같은 값도 얻을 수 있다.

즉 내가 가지고 있는

M4 Mac mini 24GB

와

M1 Max MacBook Pro 64GB

에서 동일한 모델의 성능을 제대로 비교하려면 MLX-LM이 상당히 좋은 도구가 된다.

MLX의 단점

반면 처음 사용하는 사람에게는 가장 진입장벽이 높다.

Python 환경을 구성해야 하고 터미널 명령어나 코드를 어느 정도 이해해야 한다.

또 모델을 그냥 다운받아 채팅해보고 싶은 사용자에게는 기능이 지나치게 전문적이다.

즉,

“로컬 AI 한번 써보고 싶다.”

라는 목적이라면 굳이 MLX부터 시작할 필요는 없다.

Ollama는 무엇이 다른가?

Ollama는 로컬 모델을 쉽게 다운로드하고 실행하고 API로 사용할 수 있게 만들어주는 도구다.

예를 들어 모델을 실행할 때 기본적으로

ollama run 모델명

정도의 명령으로 시작할 수 있다.

Mac뿐 아니라 Windows와 Linux에서도 사용할 수 있으며 현재 macOS 버전은 macOS 14 Sonoma 이상을 요구한다.

Ollama의 장점은 복잡한 모델 실행 환경을 사용자가 직접 구성하지 않아도 된다는 것이다.

모델 다운로드, 실행, 관리와 API 서버 역할까지 상당 부분 Ollama가 처리한다.

2026년에는 Ollama와 MLX의 관계도 달라졌다

예전에는

Ollama vs MLX

라는 비교가 비교적 자연스러웠다.

하지만 2026년에는 상황이 달라졌다.

Ollama가 Apple Silicon에서 MLX 엔진을 사용하기 시작했기 때문이다.

Ollama는 2026년 3월 Apple Silicon용 MLX 엔진을 공개했고, 6월에는 MLX 엔진의 추가 최적화를 통해 출력 속도와 메모리 효율을 개선했다고 발표했다.

즉 현재 Apple Silicon에서는

Ollama냐 MLX냐

라기보다는

MLX를 직접 사용할 것인가, Ollama를 통해 편하게 사용할 것인가

라는 질문에 가까워지고 있다.

이게 상당히 중요한 변화다.

Ollama의 가장 큰 장점은 개발 도구 연결

개발자 입장에서 현재 Ollama의 가장 흥미로운 기능 가운데 하나는 Coding Agent 연동이다.

2026년에는 ollama launch 명령이 추가됐다.

이를 이용하면 Claude Code, OpenCode, Codex 등의 Coding Agent를 Ollama의 로컬 또는 클라우드 모델과 연결할 수 있다.

예를 들어 Claude Code를 실행할 수 있고,

Codex 역시 Ollama의 OpenAI 호환 환경을 통해 로컬 모델을 사용할 수 있다.

이 기능 때문에

개발 머신 + 로컬 LLM

환경에서는 Ollama가 상당히 매력적이다.

Ollama의 장점

내가 개발용 Mac에서 사용할 목적이라면 다음이 가장 큰 장점이라고 생각한다.

첫째, 명령이 간단하다.

터미널 몇 줄만으로 모델을 설치하고 실행할 수 있다.

둘째, API 서버로 사용하기 쉽다.

로컬 앱이나 개발 프로젝트에서 LLM을 호출하기 편하다.

셋째, Agent 연동이 쉽다.

Claude Code, Codex 등과 연결하기가 상당히 간단해졌다.

넷째, Apple Silicon에서는 MLX 엔진까지 사용할 수 있다.

즉 편의성과 Apple Silicon 최적화를 어느 정도 동시에 얻을 수 있다.

Ollama의 단점

GUI 중심 사용자에게는 LM Studio만큼 직관적이지 않을 수 있다.

물론 Ollama도 macOS와 Windows용 앱을 제공하고 있으며 모델 채팅과 파일 입력 등의 기능을 사용할 수 있다.

하지만 모델을 검색하고

양자화 방식

모델 파일 크기

메모리 사용량

Context

런타임

등을 화면에서 하나씩 확인하면서 사용하는 경험은 LM Studio가 더 직관적인 편이다.

LM Studio는 무엇인가?

LM Studio는 세 제품 중 일반 사용자에게 가장 친숙한 형태다.

쉽게 말하면

로컬 LLM용 데스크톱 앱 + 모델 관리자 + 채팅 앱 + API 서버

라고 생각하면 된다.

앱 안에서 Hugging Face 기반 모델을 검색하고 다운로드하고 메모리에 올린 뒤 바로 채팅할 수 있다.

현재 Apple Silicon Mac에서는 GGUF 기반 llama.cpp뿐 아니라 MLX 모델도 직접 실행할 수 있다.

즉 LM Studio 역시 이제 단순한 llama.cpp GUI라고만 보기는 어렵다.

LM Studio의 가장 큰 장점은 GUI다

로컬 LLM을 처음 접한다면 LM Studio가 가장 이해하기 쉽다.

앱을 실행한 후

모델 검색

↓

다운로드

↓

모델 선택

↓

Load

↓

Chat

순서로 진행하면 된다.

터미널 환경이나 Python을 몰라도 된다.

이건 상당히 큰 장점이다.

24GB Mac에서는 LM Studio의 메모리 예측 기능이 특히 유용하다

M4 Mac mini 24GB 같은 시스템에서는 모델이 메모리에 들어갈지 여부가 상당히 중요하다.

LM Studio에서는 모델을 실제로 로딩하기 전에 메모리 요구량을 추정할 수 있다.

CLI에서는

lms load --estimate-only 모델명

형태로 사용할 수 있다.

이 기능은 Context Length와 GPU Offload, Flash Attention, Vision Model 여부 등을 고려해서 예상 메모리 사용량을 계산한다.

24GB나 32GB Mac에서 큰 모델을 시험할 때 상당히 유용하다.

LM Studio도 API 서버로 사용할 수 있다

GUI 프로그램이라고 해서 채팅용으로만 사용하는 것은 아니다.

LM Studio는 로컬 REST API 서버를 실행할 수 있다.

현재

OpenAI 호환 API

Anthropic 호환 API

LM Studio 자체 REST API

TypeScript SDK

Python SDK

등을 제공한다.

기존 OpenAI API 기반 프로그램이라면 Base URL을 LM Studio의 localhost 주소로 변경해서 로컬 모델을 사용할 수도 있다.

즉 GUI 프로그램이면서 동시에 개발용 서버 역할도 한다.

Claude Code도 LM Studio와 연결할 수 있다

이 부분도 흥미롭다.

LM Studio는 2026년부터 Anthropic 호환 /v1/messages API를 제공하면서 Claude Code와 직접 연결할 수 있게 됐다.

예를 들어 LM Studio의 로컬 서버를 실행하고 Claude Code의 ANTHROPIC_BASE_URL을 localhost로 바꾸면 로컬 모델을 Claude Code에서 사용할 수 있다.

Codex 역시 LM Studio의 OpenAI-compatible Responses API를 사용할 수 있다.

따라서

Claude Code → Ollama

만 가능한 것은 아니다.

Claude Code → LM Studio

구성도 충분히 가능하다.

LM Studio도 내부적으로 MLX를 사용한다

여기까지 보면 재미있는 관계가 만들어진다.

Apple Silicon 환경에서는

MLX

라는 기반 기술이 있고,

그 MLX를

Ollama

도 사용하고,

LM Studio

도 사용할 수 있다.

LM Studio는 자체 mlx-engine을 개발해서 MLX-LM과 MLX-VLM을 기반으로 Apple Silicon용 추론 엔진을 제공한다.

2026년에는 장시간 Agent 작업에서 KV Cache를 체크포인트하는 방식으로 MLX 엔진을 개선하기도 했다. LM Studio가 공개한 자체 테스트에서는 일부 Agent 워크로드에서 추가 RAM 사용량 감소와 처리량 개선 효과가 보고됐다.

따라서 단순히

MLX = 빠름

LM Studio = 느린 GUI

라고 구분하는 것도 현재는 정확하지 않다.

LM Studio 자체가 MLX를 사용할 수 있기 때문이다.

결국 셋의 관계는 이렇게 보는 게 가장 정확하다

개인적으로는 다음과 같이 이해하는 것이 가장 쉬웠다.

MLX / MLX-LM

엔진룸을 직접 여는 방식

직접 모델을 제어하고 측정하고 실험한다.

Ollama

개발자를 위한 편한 실행기

명령어와 API 중심으로 모델을 빠르게 실행한다.

LM Studio

GUI와 개발 기능을 함께 제공하는 통합 도구

모델 검색부터 채팅, API 서버까지 화면에서 관리한다.

세 가지를 다시 비교하면

항목MLX / MLX-LMOllamaLM Studio

중요한 것은 Apple Silicon 성능 항목이다.

현재 Ollama와 LM Studio 모두 MLX 기반 엔진을 사용할 수 있기 때문에 단순히 제품 이름만 가지고 어느 것이 무조건 더 빠르다고 말하기 어렵다.

모델 형식, 양자화, Context Length, 런타임 버전과 설정에 따라 결과가 달라질 수 있다.

M4 Mac mini 24GB에서는 무엇을 사용할까?

내가 현재 사용하고 있는 M4 Mac mini 24GB를 기준으로 생각하면 목적별로 선택할 것 같다.

모델을 처음 찾아볼 때

LM Studio

GUI에서 모델 크기와 정보를 확인하기 편하고 메모리 사용량도 예측할 수 있기 때문이다.

개발하면서 로컬 API가 필요할 때

Ollama

CLI와 API가 단순하고 개발 도구 연결이 편하다.

Claude Code / Codex에서 로컬 모델을 사용할 때

Ollama 또는 LM Studio

둘 다 현재 상당히 잘 지원한다.

M4와 M1 Max 성능을 직접 비교할 때

MLX-LM

Prompt TPS, Generation TPS, Peak Memory 같은 데이터를 직접 측정하기에 적합하다.

하나만 설치한다면?

이것도 사용자에 따라 다르다.

일반 사용자라면

LM Studio

가장 쉽게 시작할 수 있다.

개발자라면

나는 Ollama부터 설치할 것 같다.

모델 실행부터 API, Coding Agent 연결까지 활용 범위가 상당히 넓다.

Apple Silicon의 성능 자체를 연구하고 싶다면

MLX-LM

이 가장 적합하다.

그런데 사실 하나만 선택할 필요가 없다

이게 최종적으로 내린 결론이다.

MLX, Ollama, LM Studio는 서로 완전히 대체하는 프로그램이 아니다.

Mac에

Ollama + LM Studio + MLX-LM

을 모두 설치해서 목적에 따라 사용해도 된다.

예를 들어

LM Studio에서 모델을 찾아보고,

Ollama에서 개발 프로젝트에 연결하고,

MLX-LM에서 정확한 성능을 측정하는 식이다.

각각의 역할이 다르기 때문에 의외로 이 방식이 가장 자연스럽다.

2026년에는 차이가 점점 줄어들고 있다

특히 흥미로운 것은 Ollama와 LM Studio가 모두 Apple MLX를 적극적으로 활용하기 시작했다는 점이다.

Ollama는 Apple Silicon MLX 엔진을 제공하고 있고, 2026년 6월 업데이트에서는 추가적인 Metal 커널 최적화와 Agent용 캐시 개선을 발표했다.

LM Studio 역시 자체 MLX Engine을 제공하며 Agentic Workflow를 위한 KV Cache 개선 등을 진행하고 있다.

결국 앞으로는

어떤 프로그램이 MLX를 쓰느냐

보다

어떤 인터페이스와 개발 환경이 나에게 편한가

가 더 중요한 선택 기준이 될 가능성이 높아 보인다.

내 경우에는 이렇게 사용할 것 같다

현재 가지고 있는 장비는

M4 Mac mini 24GB

와

M1 Max MacBook Pro 64GB

다.

두 장비에서 로컬 LLM을 계속 테스트한다면 다음처럼 사용할 생각이다.

LM Studio

모델 탐색과 빠른 테스트

Ollama

개발 프로젝트와 Claude Code, Codex 연동

MLX-LM

M4와 M1 Max의 직접적인 성능 비교

이렇게 역할을 나누면 상당히 효율적일 것 같다.

특히 다음에는 같은 모델을

MLX-LM

Ollama MLX

LM Studio MLX

환경에서 각각 실행해서 실제 Token 생성 속도와 메모리 사용량 차이가 얼마나 나는지도 한번 비교해보고 싶다.

결론

처음에는 MLX, Ollama, LM Studio 가운데 무엇이 가장 좋은지 선택해야 하는 문제라고 생각했다.

하지만 자료를 정리해보니 질문 자체가 조금 달랐다.

MLX는 Apple Silicon에 최적화된 머신러닝 프레임워크다.

그리고

Ollama와 LM Studio는 로컬 모델을 훨씬 쉽게 사용하는 환경이다.

더구나 2026년에는 Ollama와 LM Studio 모두 MLX를 활용하고 있다.

따라서 단순하게

MLX vs Ollama vs LM Studio

의 승자를 고르는 것보다는

무엇을 하려는가

를 먼저 정하는 것이 맞다.

로컬 LLM을 처음 경험해보고 싶다면 LM Studio.

개발과 자동화, API, Coding Agent가 목적이라면 Ollama.

Apple Silicon에서 모델을 직접 다루고 분석하거나 Fine-tuning까지 하고 싶다면 MLX-LM.

현재로서는 이렇게 구분하는 것이 가장 현실적이라고 생각한다.

참고자료

이 글을 작성하면서 다음 공식 자료를 참고했다.

1. Apple MLX 공식 문서 — Unified Memory

Apple Silicon에서 CPU와 GPU가 동일한 메모리 풀에 접근하고 MLX가 이 구조를 활용하는 방식을 참고했다.

2. Apple MLX 공식 문서 — 설치 및 시스템 요구사항

Apple Silicon에서 MLX를 사용하기 위한 macOS와 Python 요구사항 및 설치 방법을 참고했다.

3. MLX-LM 공식 프로젝트

MLX를 이용한 LLM 생성, Fine-tuning, 양자화, 서버 및 성능 측정 기능을 참고했다.

4. Ollama — Apple Silicon MLX Engine

Ollama가 2026년부터 Apple Silicon에서 MLX를 활용하는 구조와 성능 개선 내용을 참고했다.

5. Ollama — ollama launch

Claude Code, OpenCode, Codex 등 Coding Agent를 로컬 또는 클라우드 모델에 연결하는 기능을 참고했다.

6. Ollama — Claude Code 및 Codex 연동

Anthropic 호환 API와 OpenAI Codex를 로컬 모델에 연결하는 방법을 참고했다.

7. LM Studio 공식 문서

LM Studio가 GGUF 기반 llama.cpp와 Apple Silicon용 MLX 모델을 모두 실행할 수 있다는 내용을 참고했다.

8. LM Studio — 로컬 API 서버

REST API, OpenAI 호환 API, Anthropic 호환 API 및 SDK 기능을 참고했다.

9. LM Studio — 메모리 사용량 예측

모델을 로딩하기 전 lms load --estimate-only를 이용해 메모리 요구량을 추정할 수 있는 기능을 참고했다.

10. LM Studio — Claude Code / Codex 연동

LM Studio의 Anthropic 호환 Messages API와 OpenAI-compatible Responses API를 통한 Coding Agent 연결 방법을 참고했다.

※ 각 도구의 성능은 사용 모델, 모델 형식, 양자화 방식, Context Length, 런타임 버전과 하드웨어에 따라 달라질 수 있다. 따라서 특정 도구가 항상 가장 빠르다고 단정하기보다는 같은 모델과 동일한 조건에서 직접 비교하는 것이 가장 정확하다.

M4 Mac mini를 구입할 때 기본형에서 메모리만 24GB로 구성했다.

처음에는 일반적인 개발 작업을 생각해서 선택한 구성이었지만, 최근에는 MLX, Ollama, LM Studio 등을 이용해 Mac에서도 로컬 LLM을 비교적 쉽게 실행할 수 있게 되면서 궁금한 점이 하나 생겼다.

M4 Mac mini 24GB에서는 어느 정도 크기의 로컬 LLM까지 현실적으로 사용할 수 있을까?

단순히 모델이 실행되는 것과 실제로 편하게 사용하는 것은 다르다.

이번 글에서는 Apple Silicon의 통합 메모리 구조와 현재 로컬 LLM 실행 환경을 기준으로 M4 Mac mini 24GB에서 어느 정도 크기의 모델이 현실적인지 정리해봤다.

M4 Mac mini 24GB의 기본 사양

내가 사용하고 있는 모델은 기본형 M4 Mac mini에 통합 메모리를 24GB로 구성한 제품이다.

M4 기본형의 주요 사양은 다음과 같다.

항목M4 Mac mini

Apple의 공식 기술 사양에 따르면 기본형 M4는 120GB/s의 메모리 대역폭을 제공하고, 16GB 기본 메모리에서 24GB 또는 32GB로 구성할 수 있다.

로컬 LLM 관점에서 중요한 부분은 CPU 코어 수보다도 24GB 통합 메모리다.

Apple Silicon은 일반 PC와 메모리 구조가 다르다

일반적인 PC에서는 CPU가 사용하는 시스템 RAM과 GPU의 VRAM이 별도로 존재한다.

Apple Silicon에서는 CPU와 GPU가 하나의 Unified Memory, 통합 메모리를 공유한다.

Apple의 MLX 역시 이 구조를 적극적으로 활용한다.

MLX 배열은 CPU용 메모리와 GPU용 메모리를 별도로 복사할 필요 없이 동일한 통합 메모리 공간에서 CPU와 GPU가 접근할 수 있도록 설계되어 있다.

그래서 24GB Apple Silicon Mac은 단순히

RAM 24GB + GPU VRAM 몇 GB

라는 구조가 아니라,

CPU와 GPU가 함께 사용하는 24GB 메모리

라고 이해하는 것이 맞다.

이것이 Mac에서 로컬 LLM을 실행할 때 상당히 큰 장점이 된다.

하지만 24GB를 전부 LLM에 사용할 수 있는 것은 아니다

여기서 가장 많이 오해하는 부분이 있다.

24GB Mac이라고 해서 24GB짜리 모델을 그대로 실행할 수 있는 것은 아니다.

macOS 자체가 메모리를 사용하고 있으며,

Safari나 Chrome, Xcode, VS Code, Claude Code 같은 프로그램도 메모리를 사용한다.

LLM 역시 단순히 모델 Weight만 메모리에 올리는 것이 아니다.

추론 과정에서는 추가로 다음과 같은 메모리가 필요하다.

• 모델 Weight
• KV Cache
• Context
• 런타임 버퍼
• 토큰 처리용 임시 메모리
• MLX / llama.cpp 등의 실행 오버헤드

특히 Context Length가 커질수록 KV Cache가 차지하는 메모리가 증가한다.

LM Studio도 모델을 로드할 때 Context Length와 Flash Attention 등의 조건까지 포함해 예상 메모리 사용량을 계산한다.

즉,

모델 파일이 18GB니까 24GB Mac에서 문제없이 실행되겠지

라고 판단하면 안 된다.

4bit 양자화를 기준으로 생각해보면

로컬 LLM에서는 일반적으로 4bit 양자화 모델을 많이 사용한다.

아주 단순하게 계산하면 4bit에서는 파라미터 하나당 약 0.5byte가 필요하다.

따라서 이론적으로는

8B 모델 → 약 4GB

14B 모델 → 약 7GB

20B 모델 → 약 10GB

30B 모델 → 약 15GB

정도의 Weight가 필요하다.

하지만 이것은 순수 Weight에 가까운 이론적인 최소값일 뿐이다.

실제 MLX나 GGUF 모델 파일은 양자화 방식에 따라 크기가 달라지고, 실행 시에는 KV Cache와 기타 메모리가 추가된다.

따라서 실제 사용 가능 범위는 조금 더 보수적으로 보는 것이 좋다.

M4 Mac mini 24GB에서는 어느 정도가 현실적일까?

대략적인 체감 구간을 나누면 다음과 같이 볼 수 있다.

모델 크기24GB Mac에서의 현실성평가

물론 이 표는 절대적인 기준은 아니다.

Dense 모델인지 MoE 모델인지, 몇 bit로 양자화했는지, Context Length를 얼마로 사용하는지에 따라 결과가 상당히 달라진다.

8B급 모델은 상당히 편하다

M4 Mac mini 24GB에서 가장 부담 없이 사용할 수 있는 영역이다.

4bit 기준 Weight 자체가 크지 않기 때문에 macOS와 다른 앱을 같이 실행하면서도 비교적 여유가 있다.

Context를 어느 정도 길게 사용하더라도 24GB 메모리의 장점을 활용할 수 있다.

간단한 채팅이나 번역, 문서 요약, 가벼운 코딩 보조 같은 용도라면 굳이 더 큰 모델을 사용할 필요가 없는 경우도 많다.

12B~14B가 개인적으로는 가장 현실적인 구간

24GB Mac에서 품질과 자원 사용량 사이의 균형이 상당히 좋은 구간이다.

최근 로컬 모델들은 12B~14B 정도에서도 상당히 좋은 성능을 제공하고 있다.

2026년 Ollama의 Apple Silicon용 MLX 최적화 자료에서도 Gemma 계열 12B 모델을 주요 테스트 대상으로 사용하고 있다.

이 정도 크기라면 로컬 AI 비서나 개발 보조, 문서 작업 등에 활용하면서 동시에 다른 프로그램을 실행하기에도 상대적으로 부담이 적다.

그래서 단순히

“24GB Mac에서 가장 큰 모델이 무엇인가?”

보다는

“24GB에서 가장 편하게 사용할 수 있는 모델이 무엇인가?”

를 묻는다면 나는 12B~14B급을 먼저 살펴볼 것 같다.

20B급부터 조금 재미있어진다

20B 정도가 되면 24GB Mac에서도 충분히 실행 가능한 영역이지만 메모리를 조금 더 신경 써야 한다.

특히 Xcode, Chrome, Docker 등을 동시에 실행한다면 상황이 달라질 수 있다.

그래도 4bit 계열의 양자화 모델이라면 상당수 20B급 모델은 현실적으로 사용할 수 있다.

LM Studio의 최신 문서에서도 gpt-oss-20b 같은 모델을 로컬 모델 예시로 사용하고 있다.

24GB Mac에서 로컬 LLM을 적극적으로 활용하고 싶다면 개인적으로 20B 전후가 성능과 메모리 사이에서 가장 흥미로운 구간이라고 생각한다.

27B~30B부터는 '실행 가능'과 '편하게 사용'을 구분해야 한다

이 부분부터는 조금 다르다.

실행 자체는 가능할 수 있다.

하지만 문제는 남은 메모리다.

예를 들어 27B급 4bit 모델의 Weight가 14GB 안팎이라고 하더라도,

여기에

Context
KV Cache
런타임 메모리
macOS
다른 애플리케이션

이 추가된다.

따라서 24GB 환경에서는 모델 하나만 실행할 때는 사용할 수 있지만 개발 환경을 동시에 사용하면 메모리 압박이 생길 수 있는 구간이다.

30B급 MoE 모델은 조금 다르게 봐야 한다

최근에는 MoE, Mixture of Experts 구조의 모델도 많이 사용된다.

대표적인 예가 Qwen3-30B-A3B 같은 모델이다.

이 모델은 전체 파라미터가 약 30.5B지만 실제 토큰 하나를 처리할 때 활성화되는 파라미터는 약 3.3B다.

그래서 계산량 측면에서는 일반적인 30B Dense 모델보다 유리할 수 있다.

하지만 중요한 점이 있다.

활성 파라미터가 3.3B라고 해서 모델 전체 Weight가 메모리에서 사라지는 것은 아니다.

Qwen3-30B-A3B 역시 전체 모델 Weight를 로딩해야 한다.

따라서 24GB Mac에서는 양자화 방식과 Context 설정에 따라 사용할 수는 있지만 상당히 경계선에 가까워진다.

35B급부터는 24GB가 확실히 부족해진다

2026년 Ollama는 Apple Silicon에서 MLX 기반 엔진을 적극적으로 사용하기 시작했다.

Ollama는 Qwen3.5-35B-A3B 모델을 MLX로 실행하는 공식 예제를 제공하면서 32GB를 초과하는 통합 메모리를 가진 Mac을 권장하고 있다.

이것은 24GB Mac의 위치를 이해하는 데 상당히 좋은 기준이 된다.

M4 Mac mini 24GB가 로컬 LLM용으로 약한 것은 아니지만, 최신 30B 후반~대형 모델까지 모두 실행하는 시스템은 아니다.

그 영역으로 올라가면 48GB 또는 64GB 이상 메모리를 가진 Apple Silicon Mac이 훨씬 현실적이다.

Context Length도 생각보다 중요하다

같은 모델이라고 해서 메모리 사용량이 항상 같은 것은 아니다.

예를 들어 Context를

4K

8K

16K

32K

64K

로 올리면 KV Cache가 차지하는 메모리도 증가한다.

특히 코드베이스 전체를 입력하거나 긴 문서를 분석하거나 AI Coding Agent를 사용할 때는 Context 사용량이 상당히 커질 수 있다.

Ollama 역시 큰 문서를 처리하기 위해 Context Length를 높이면 더 많은 메모리가 필요하다고 공식적으로 안내한다.

따라서 24GB Mac에서 큰 모델을 사용할 때는 무조건 긴 Context를 사용하는 것보다 실제 필요한 수준으로 제한하는 것이 좋다.

MLX, Ollama, LM Studio 중 무엇을 사용할까?

Mac에서 로컬 LLM을 실행할 때 대표적으로 많이 사용하는 방법은 세 가지다.

MLX

Apple Silicon에 가장 직접적으로 최적화된 환경이다.

Apple의 Machine Learning Research 팀이 개발했으며 Unified Memory 구조를 적극적으로 활용한다.

성능 테스트나 직접 모델을 제어하고 싶다면 가장 흥미로운 선택이다.

다만 명령어와 Python 환경에 익숙하지 않다면 처음에는 조금 어렵게 느껴질 수 있다.

Ollama

개인적으로 가장 편하게 사용할 수 있는 방법 중 하나다.

명령어 몇 개만으로 모델을 다운로드하고 실행할 수 있고 API 서버로 사용하는 것도 간단하다.

특히 2026년부터 Apple Silicon에서 MLX 기반 엔진이 본격적으로 적용되면서 성능도 크게 향상됐다.

Ollama는 Claude Code나 Codex 같은 Coding Agent와 로컬 모델을 연결하는 기능도 강화하고 있다.

그래서

개발 + 로컬 LLM

조합이라면 상당히 매력적이다.

LM Studio

GUI 기반으로 모델을 검색하고 다운로드하고 실행하기에는 가장 편하다.

특히 좋은 기능이 하나 있다.

모델을 실제로 실행하기 전에 필요한 메모리를 예측할 수 있다.

CLI에서는 다음과 같은 방식으로 확인할 수 있다.

lms load --estimate-only 모델명

이 기능은 Context Length, GPU Offload, Flash Attention 등의 조건을 고려해 메모리 사용량을 추정한다.

24GB처럼 메모리 한계가 분명한 Mac에서는 상당히 유용한 기능이다.

24GB Mac이라면 모델 선택을 이렇게 할 것 같다

현재 기준으로 내가 M4 Mac mini 24GB에서 모델을 선택한다면 다음과 같이 접근할 것 같다.

빠른 일상 작업

3B~8B

속도를 우선으로 사용한다.

문서 작업 / 일반 AI 비서

12B~14B

품질과 메모리 사용량의 균형을 본다.

개발 / 코딩 / 조금 더 복잡한 작업

14B~20B 전후

24GB에서 가장 적극적으로 테스트해볼 만한 영역이라고 생각한다.

성능 우선 테스트

24B~27B

다른 애플리케이션 사용을 줄이고 Context를 적절히 제한한다.

30B 이상

실행 가능 여부 자체를 목표로 하기보다는 메모리 사용량을 먼저 확인한다.

24GB에서 Swap을 사용하면 더 큰 모델도 돌릴 수 있지 않을까?

가능할 수는 있다.

macOS는 메모리가 부족하면 SSD를 이용한 Swap을 사용한다.

따라서 물리 메모리를 조금 초과하는 상황에서도 프로그램이 바로 종료되지는 않을 수 있다.

하지만 로컬 LLM에서는 이것을 정상적인 운용 방법이라고 보기 어렵다.

메모리 접근 속도가 떨어지고 전체 시스템 반응성이 크게 낮아질 수 있다.

따라서

“돌아간다”

와

“실제로 쓸 만하다”

를 구분할 필요가 있다.

결국 M4 Mac mini 24GB는 어느 정도일까?

정리하면 개인적으로 이렇게 평가하고 싶다.

8B급

매우 편안하다.

12B~14B급

24GB 구성에서 가장 균형이 좋다.

20B급

충분히 실용적이다.

27B급

사용 가능하지만 메모리 관리가 필요하다.

30B급

양자화와 Context에 따라 경계선이다.

32B 이상

모델마다 차이가 크며 24GB에서는 추천하기 어렵다.

35B 이상

최근 모델 기준으로는 32GB 이상, 가능하면 48GB 이상의 Mac을 보는 것이 현실적이다.

24GB를 선택한 것이 아쉬운가?

개인적으로는 그렇지 않다.

M4 Mac mini 24GB는 일반 개발 머신이면서 동시에 꽤 많은 로컬 LLM을 실행할 수 있는 시스템이다.

특히 8B~20B 사이의 모델을 사용하는 데는 상당히 좋은 환경이다.

다만 로컬 LLM을 메인 용도로 사용하면서 30B 이상의 모델을 지속적으로 실행하고 싶다면 이야기가 달라진다.

그때는 32GB보다도 48GB나 64GB 구성을 고려하는 것이 훨씬 현실적이다.

결국 중요한 것은

“가장 큰 모델을 실행할 수 있는가?”

가 아니라

“내가 필요한 모델을 얼마나 편하게 실행할 수 있는가?”

라고 생각한다.

M4 Mac mini 24GB는 그 기준에서는 여전히 상당히 괜찮은 위치에 있다.

한 가지 더 흥미로운 점

현재 나는 M4 Mac mini 24GB 외에도 M1 Max 64GB MacBook Pro를 가지고 있다.

M1 Max는 CPU 세대는 오래됐지만 64GB 통합 메모리와 400GB/s 메모리 대역폭이라는 특징이 있다.

그래서 실제 로컬 LLM에서는

최신 M4 24GB

와

구형 M1 Max 64GB

사이에 상당히 재미있는 결과가 나올 가능성이 있다.

다음에는 두 시스템에 동일한 모델을 설치해서

• 모델 로딩 시간
• Prompt Processing 속도
• Token 생성 속도
• 실제 메모리 사용량
• Swap 발생 여부
• 발열과 소비전력

등을 직접 비교해볼 예정이다.

공식 스펙만으로 판단하는 것보다 실제 로컬 LLM을 돌려보면 두 Mac의 성격 차이가 훨씬 명확하게 나타날 것 같다.

참고자료

이 글을 작성하면서 다음의 공식 자료와 모델 문서를 참고했다.

1. Apple Support — Mac mini (2024) 기술 사양

M4 Mac mini의 10코어 CPU, 10코어 GPU, 16코어 Neural Engine, 24GB·32GB 통합 메모리 구성과 120GB/s 메모리 대역폭을 확인했다.

2. Apple MLX — Unified Memory 문서

Apple Silicon에서 CPU와 GPU가 동일한 통합 메모리 공간을 사용하며, MLX가 이 구조를 활용하는 방식을 참고했다.

3. LM Studio — 모델 로딩 및 메모리 추정 문서

lms load --estimate-only를 통해 모델을 실제로 로드하기 전에 Context Length와 GPU 설정 등을 고려한 예상 메모리 사용량을 확인할 수 있다는 내용을 참고했다.

4. Ollama — Apple Silicon MLX 지원

Apple Silicon에서 MLX 기반 실행 엔진과 Unified Memory를 활용하는 최신 Ollama 환경을 참고했다.

5. Ollama — Qwen3.5 35B MLX 실행 안내

Qwen3.5 35B급 모델을 실행하기 위해 32GB를 초과하는 Unified Memory를 가진 Mac을 권장하는 내용을 24GB Mac의 현실적인 상한선을 판단하는 자료로 참고했다.

6. Qwen 공식 모델 카드 — Qwen3-30B-A3B

Qwen3-30B-A3B가 약 30.5B의 전체 파라미터와 토큰당 약 3.3B의 활성 파라미터를 사용하는 MoE 구조라는 점을 참고했다.

※ 모델의 실제 메모리 사용량과 생성 속도는 양자화 방식, Context Length, 런타임 버전, macOS 상태 및 동시에 실행하는 애플리케이션에 따라 달라질 수 있다. 따라서 본문의 모델 크기별 평가는 절대적인 실행 가능 여부가 아니라 M4 Mac mini 24GB에서의 현실적인 사용 범위를 판단하기 위한 참고 기준으로 보는 것이 좋다.

최근 Apple이 M6와 M5 Pro를 탑재한 새로운 Mac mini를 출시했다.

현재 내가 사용하고 있는 Mac은 크게 두 대다.

MacBook Pro M1 Max / 64GB 통합 메모리 / 1TB SSD

그리고

Mac mini M4 기본형 / 24GB 통합 메모리

이다.

M1 Max MacBook Pro는 2021년에 출시된 모델이다. 어느새 5년 전 제품이 됐다. 반면 M4 Mac mini는 비교적 최신 제품이고, 이제는 M6와 M5 Pro를 탑재한 Mac mini까지 등장했다.

그래서 궁금해졌다.

5년 된 M1 Max 64GB는 이제 정말 구형일까?

특히 요즘처럼 Claude Code, Codex 같은 AI 코딩 도구와 MLX, Ollama, LM Studio를 이용한 로컬 LLM 활용이 늘어난 상황에서는 단순 CPU 벤치마크만 보고 판단하기 어렵다.

이번 글에서는 M1 Max 64GB MacBook Pro와 M4 24GB Mac mini를 기준으로 최신 M6 Mac mini와 M5 Pro Mac mini를 비교해봤다.

네 모델의 기본 사양부터 비교해보자

핵심적인 부분만 정리하면 다음과 같다.

모델CPU / GPU통합 메모리메모리 대역폭

M1 Max는 2021년 제품임에도 최대 64GB 통합 메모리와 400GB/s라는 상당히 높은 메모리 대역폭을 가지고 있다. 반면 M4 기본형 Mac mini의 메모리 대역폭은 120GB/s다.

M6 Mac mini는 16GB 구성에서 153GB/s, 24GB 또는 32GB 구성에서는 최대 170GB/s의 메모리 대역폭을 제공한다. M5 Pro는 307GB/s이며 최대 64GB 통합 메모리를 선택할 수 있다.

이 숫자만 보면 재미있는 부분이 하나 있다.

5년 전 M1 Max의 메모리 대역폭이 최신 M5 Pro보다도 높다.

물론 이것만으로 M1 Max가 M5 Pro보다 빠르다는 뜻은 아니다.

CPU와 GPU 아키텍처, AI 가속기, Neural Engine 등 많은 부분이 달라졌기 때문이다.

하지만 로컬 LLM에서는 이 숫자를 무시하기 어렵다.

CPU 성능은 역시 최신 Mac이 빠르다

공개된 Geekbench 6 결과 중 비슷한 버전을 기준으로 살펴보면 대략 다음과 같은 차이를 볼 수 있다.

모델Single CoreMulti Core

공개 Geekbench 결과는 운영체제, 발열 상태, 메모리 구성 등에 따라 차이가 있기 때문에 절대적인 성능표라기보다는 세대 간 차이를 보는 참고 자료로 보는 것이 좋다.

그래도 방향은 상당히 명확하다.

싱글코어 성능에서는 M6가 M1 Max보다 크게 앞선다.

즉 Xcode를 실행하고, 코드를 편집하고, 작은 프로젝트를 컴파일하고, 여러 일반 애플리케이션을 사용하는 일상적인 개발 환경에서는 M6가 훨씬 빠르고 반응성이 좋을 가능성이 높다.

M4 역시 싱글코어 성능만 보면 M1 Max보다 상당히 빠르다.

실제로 내가 사용하는 두 제품도 이런 특성 차이를 가지고 있다.

M4 Mac mini는 작고 빠른 최신 CPU를 가진 머신이고, M1 Max MacBook Pro는 상대적으로 오래된 CPU지만 훨씬 큰 메모리와 GPU 자원을 가진 머신이다.

대규모 작업에서는 M5 Pro가 확실히 다르다

M5 Pro의 특징은 멀티코어 성능이다.

상위 M5 Pro는 18코어 CPU와 20코어 GPU를 구성할 수 있다. Apple 역시 M5 Pro Mac mini를 앱 개발, 영상 제작, 3D, 과학 연산과 같은 무거운 작업용으로 포지셔닝하고 있다.

공개 Geekbench 6 결과에서도 18코어 M5 Pro는 약 28,900점의 멀티코어 성능을 기록한다. 이는 M1 Max의 약 13,200점과 비교하면 상당히 큰 차이다.

따라서 대형 Xcode 프로젝트를 빌드하거나 여러 작업을 동시에 수행한다면 M5 Pro 쪽이 훨씬 유리하다.

Claude Code, Codex, Xcode, 브라우저, Docker, 로컬 서버 등을 동시에 실행하는 개발 환경에서도 CPU 코어 수와 64GB 메모리를 동시에 확보할 수 있는 M5 Pro가 가장 균형이 좋다.

그런데 로컬 LLM에서는 이야기가 조금 달라진다

여기부터가 이번 비교에서 가장 흥미로운 부분이다.

로컬 LLM에서 중요한 것은 단순 CPU 점수만이 아니다.

특히 다음 두 가지가 중요하다.

얼마나 큰 모델을 메모리에 올릴 수 있는가?

그리고

메모리에 올라간 모델의 데이터를 얼마나 빠르게 처리할 수 있는가?

이 관점에서 다시 보면 순위가 바뀐다.

M4 Mac mini 24GB

내가 가지고 있는 M4 Mac mini는 기본형 M4 칩에 24GB 통합 메모리를 사용한다.

작은 모델이나 중간 크기의 양자화 모델을 실행하기에는 충분하지만, 모델의 크기가 올라가면서 메모리 한계가 빠르게 나타날 수밖에 없다.

macOS와 다른 애플리케이션도 같은 통합 메모리를 사용하기 때문이다.

M6 Mac mini

M6는 AI 성능이 크게 개선됐다.

GPU 코어마다 Neural Accelerator가 추가됐으며 Apple은 특정 LM Studio 테스트에서 M4 Mac mini 대비 최대 4.8배 높은 LLM prompt processing 성능을 제시하고 있다.

다만 주의할 점이 있다.

Apple이 이야기하는 것은 특정 모델과 조건에서 측정한 prompt processing 성능이다.

LLM의 지속적인 토큰 생성 속도와 완전히 같은 의미는 아니다.

그리고 M6 Mac mini의 가장 큰 제한은 최대 메모리가 32GB라는 것이다.

성능은 상당히 좋아졌지만 40GB, 50GB 이상의 메모리가 필요한 모델은 애초에 실행하기 어렵다.

M1 Max 64GB가 아직 재미있는 이유

여기에서 M1 Max의 존재감이 다시 커진다.

CPU만 보면 M6보다 훨씬 느리다.

하지만 내가 가지고 있는 M1 Max 모델에는 64GB 통합 메모리가 있다.

여기에 메모리 대역폭도 400GB/s다.

이는 M4의 120GB/s보다 약 3.3배 높고, M6 24/32GB 구성의 최대 170GB/s보다도 2배 이상 높다. 심지어 M5 Pro의 307GB/s보다도 수치상 높다.

LLM의 토큰 생성은 모델과 구현 방식에 따라 메모리 대역폭의 영향을 크게 받을 수 있다.

따라서 M1 Max는 최신 CPU가 아님에도 큰 양자화 모델을 메모리에 올려 지속적으로 추론하는 용도에서는 여전히 상당히 흥미로운 하드웨어다.

물론 400GB/s라는 숫자만으로 M1 Max가 M5 Pro보다 LLM에서 무조건 빠르다고 말할 수는 없다.

최신 GPU 아키텍처와 Neural Accelerator, MLX 최적화, 모델 구조, 양자화 방식, Context 길이 등의 영향을 모두 받기 때문이다.

하지만 적어도

“M1 Max는 오래됐으니 M6보다 무조건 느릴 것이다.”

라고 단순하게 판단하기는 어렵다.

로컬 LLM에서는 RAM 용량이 생각보다 중요하다

M6가 아무리 빠르더라도 최대 메모리는 32GB다.

반면 M1 Max와 M5 Pro는 최대 64GB를 사용할 수 있다.

예를 들어 어떤 모델이 실행에 35~40GB 이상의 메모리를 필요로 한다면 M6에서는 성능 비교 자체가 의미가 없다.

실행할 수 없기 때문이다.

이 점 때문에 로컬 LLM용 Mac을 고를 때는 CPU 세대보다 먼저

“어떤 크기의 모델을 사용할 것인가?”

를 생각하는 것이 맞다고 본다.

작은 모델을 빠르게 실행한다면 M6가 매력적이다.

큰 모델을 실행하는 것이 중요하다면 64GB M1 Max나 64GB M5 Pro가 훨씬 유리해진다.

Apple 역시 M5 Pro의 64GB 통합 메모리와 307GB/s 대역폭을 소개하면서 더 큰 로컬 AI 모델을 실행할 수 있다는 점을 강조하고 있다.

Xcode 개발 기준이라면?

일반적인 iOS 앱 개발에서는 M4 Mac mini 24GB도 여전히 충분히 빠르다.

특히 작은 프로젝트에서는 M1 Max보다 M4의 높은 싱글코어 성능이 유리할 수 있다.

M6로 가면 이 차이는 더 커진다.

반면 대형 프로젝트에서 여러 Target을 빌드하거나 Swift Package가 많고, 동시에 시뮬레이터와 Docker, AI Agent까지 실행한다면 M5 Pro가 가장 좋은 구성이 될 가능성이 높다.

정리하면 이런 느낌이다.

작업상대적으로 유리한 모델

Metal과 GPU 작업은?

이 부분 역시 M1 Max를 단순히 구형이라고 보기 어려운 이유다.

M1 Max는 구성에 따라 24코어 또는 32코어 GPU를 가지고 있다.

반면 기본형 M4 Mac mini는 10코어 GPU다.

물론 최신 M6 GPU는 아키텍처 자체가 크게 발전했고 GPU 코어마다 Neural Accelerator까지 포함한다. 따라서 단순 GPU 코어 개수만 가지고 성능을 비교해서는 안 된다.

그래도 기존 M1 Max를 가지고 있다면 Metal 기반 앱 개발이나 GPU 메모리를 많이 사용하는 작업 때문에 무조건 M4 기본형으로 옮겨야 할 이유는 크지 않다.

오히려 두 장비의 성격이 다르다고 보는 게 맞다.

내가 가지고 있는 두 Mac은 역할이 꽤 다르다

현재 내가 가지고 있는 구성만 생각하면 의외로 조합이 괜찮다.

M4 Mac mini 24GB

최신 CPU 성능이 좋고 소비전력이 낮으며 데스크톱으로 계속 켜두기 좋다.

Xcode, 일반 개발, Claude Code나 Codex 같은 클라우드 기반 AI 코딩 도구, 작은 로컬 LLM을 실행하기에 좋은 머신이다.

반대로

M1 Max MacBook Pro 64GB

CPU는 상대적으로 오래됐지만 메모리가 64GB이고 대역폭이 400GB/s다.

따라서 메모리를 많이 사용하는 로컬 LLM이나 GPU 작업을 테스트하기 좋은 환경이다.

결국 한쪽이 다른 한쪽을 완전히 대체하는 관계는 아니다.

M6가 나오면서 M1 Max가 쓸모없어졌을까?

내 결론은 아니다.

일반적인 CPU 작업에서는 세대 차이가 상당히 커졌다.

특히 M6의 싱글코어 성능은 M1 Max와 상당한 차이가 있으며, M5 Pro의 멀티코어 성능 역시 M1 Max와 비교하기 어려울 정도로 발전했다.

하지만 로컬 LLM이라는 새로운 사용 목적이 등장하면서 M1 Max의 64GB 통합 메모리와 400GB/s 메모리 대역폭이 다시 의미를 갖게 됐다.

5년 전에는 영상 편집이나 3D 작업을 위해 선택했던 사양이 지금은 로컬 AI를 돌리는 데 꽤 좋은 조건이 된 셈이다.

그래서 지금 가지고 있는 M1 Max 64GB를 단순히 오래된 Mac이라고 생각하고 교체하기보다는, 먼저 MLX나 LM Studio 등을 이용해서 어느 정도의 모델까지 실제로 사용할 수 있는지 테스트해 볼 생각이다.

다음에는 직접 테스트해볼 예정

이번 글에서는 공식 사양과 공개 벤치마크를 중심으로 비교했다.

하지만 로컬 LLM에서는 Geekbench보다 실제 모델 테스트가 훨씬 중요하다.

따라서 다음에는 내가 가지고 있는

M1 Max 64GB MacBook Pro

와

M4 24GB Mac mini

에서 동일한 MLX 모델을 실행해서 비교해보려고 한다.

확인해보고 싶은 것은 단순하다.

모델 로딩 시간, Prompt 처리 속도, 초당 생성 토큰 수, 메모리 사용량, CPU/GPU 사용률, 발열 등을 동일한 조건에서 비교하면 두 장비의 차이가 훨씬 명확하게 보일 것이다.

특히 7B급의 작은 모델뿐 아니라 14B, 30B 이상의 모델에서도 차이가 어떻게 나타나는지 확인해보면 재미있을 것 같다.

어쩌면 최신 M4 Mac mini가 훨씬 빠를 수도 있고,

반대로 M1 Max의 64GB 메모리와 400GB/s 대역폭이 예상보다 강력할 수도 있다.

그 결과는 다음 글에서 직접 확인해볼 예정이다.

결론

2026년 기준으로 Apple Silicon의 성능은 M1 Max 시절과 비교해 상당히 발전했다.

M6는 높은 싱글코어 성능과 새로운 AI 가속 기능을 가지고 있고, M5 Pro는 최대 18코어 CPU와 64GB 메모리를 이용해 개발과 AI 작업 모두에서 강력한 성능을 제공한다.

그렇다고 M1 Max 64GB가 의미 없는 구형 Mac이 된 것은 아니다.

특히 로컬 LLM에서는 단순 CPU 성능보다 메모리 용량과 메모리 대역폭이 중요해질 수 있기 때문이다.

현재 내 장비를 기준으로 보면,

M4 Mac mini 24GB는 빠르고 효율적인 일상 개발 머신

이고,

M1 Max 64GB MacBook Pro는 대용량 메모리가 필요한 AI와 GPU 작업용 머신

이라는 역할 분담이 가능하다.

그리고 M5 Pro 64GB는 이 두 역할을 한 시스템에 합칠 수 있는 최신 선택지에 가깝다.

무엇보다 재미있는 건 2021년에 구입한 64GB M1 Max가 2026년에 전혀 다른 이유로 다시 가치가 생기고 있다는 점이다.

5년 전의 고용량 통합 메모리가 로컬 AI 시대에는 꽤 쓸 만한 자산이 됐다.

다음 웹소설 에피소드를 웹툰으로 요청해 보았습니다. 

https://opendev4u.tistory.com/190

그랬더니....

 웹툰으로 통으로 나오긴 하지만 한글 표시가 이상해서 아래와 같이 제안해 주어서 

제안을 수락하니 아래와 같이 나오긴 하네요 크게 2가지 컨셉으로 나왔습니다. 

좀 더 작업하면 웹툰도 금방 나올 것 같습니다.