Mac Studio M5 Ultra(통합 메모리 1.2TB/s)를 로컬 LLM 용도로 고르면서 정리한 내용입니다. 핵심은 "메모리 용량이 어느 모델까지 열어주는가, 그 모델로 실제 어떤 일을 맡길 수 있는가"입니다. 4bit MLX 양자화 기준이며, 모델은 2026년 상반기까지 검증된 것들이라 이후 나온 후속 모델은 같은 체급의 최신판으로 바꿔 읽으면 됩니다.
0. 먼저 알아둘 두 가지 규칙
- 속도 = 메모리 대역폭 ÷ 활성 파라미터 크기. 1.2TB/s에서 70B dense 4bit(~40GB)는 20~25 tok/s, 22B만 활성인 MoE 235B는 35~45 tok/s. 같은 모델을 M5 Max(614GB/s)에서 돌리면 절반입니다.
- macOS는 통합 메모리의 약 75%만 GPU에 줍니다.
sudo sysctl iogpu.wired_limit_mb=86016(96GB 기준 ≈84GB)처럼 올릴 수 있고, 재부팅 시 초기화되니 launchd로 고정합니다. 개발 도구·브라우저 몫(20GB 안팎)을 빼면 96GB의 실질 모델 예산은 60~70GB입니다.
1. 96GB — "보조·대량 처리" 티어
120B급 MoE까지가 상한입니다. 이 구간의 로컬 모델은 스펙이 확정된 실행·반복·대량 작업을 비용 0으로 맡기는 용도이고, 판단이 필요한 일은 여전히 클라우드 최상위 모델의 몫입니다.
| 모델 (4bit 메모리) | 잘하는 작업 | 한계 | 이렇게 씁니다 |
|---|---|---|---|
| Qwen3-Coder-30B-A3B (~18GB, 100+ tok/s) | 코드 생성·리팩터·테스트 작성, 툴 호출(에이전트 루프), 셸/SQL 생성 | 대형 코드베이스 전체를 아우르는 설계 판단은 약함 | 보일러플레이트·값 교체·대량 변환 등 "기계적 코딩"의 로컬 대체 |
| Qwen3-32B / DeepSeek-R1-Distill-Qwen-32B (~19GB, ~45 tok/s) | 단계적 추론, 수학, 논리 검증, 한국어 이해 | 30B-A3B보다 2배 느림 | 파서 버그 원인 추론, 견적·계산 검토 |
| Gemma 3 27B (~17GB, 비전 포함) | 한국어 작문·번역·요약 품질이 이 체급 최상급, 이미지 이해(스크린샷·표·OCR) | 툴 호출·코딩은 Qwen 계열보다 약함 | 블로그·전자책 초안, SEO 문안, 스크린샷 판별, 사진 속 텍스트 추출 |
| EXAONE 4.0 32B (LG, ~18GB) | 한국어 특화 — 존댓말·업무 문서·행정 문체 | 영어권 생태계가 작음 | 국내 고객용 제안서·계약서 문구 |
| Devstral / Mistral Small 3.x 24B (~14GB, 비전) | 에이전틱 코딩(파일 탐색→수정) | 한국어 약함 | OpenHands·Cline 같은 로컬 에이전트 백엔드 |
| Llama 3.3 70B (~40GB, ~22 tok/s) | 일반 지식, 긴 영문 문서 종합 | 한국어 보통, 느린 편 | 영문 기술문서 독해·요약 |
| Qwen2.5-VL-72B / Qwen3-VL (~42GB) | 고난도 이미지 분석 — UI 스크린샷의 요소·수치, 문서 레이아웃 | 느림 | UI 검증, 스캔 문서 구조화 |
| GPT-OSS-120B (~63GB, 50~80 tok/s) | 로컬 최상위 추론·툴 호출, 다단계 계획, 영어 코딩 | 한국어 작문은 Gemma/Qwen보다 밋밋, 96GB에선 컨텍스트 32k 내외 | 클라우드에 보내기 전 1차 판단, 버그 원인 가설 세우기 |
| GLM-4.5-Air (106B-A12B) / Llama 4 Scout (~60GB) | 에이전트 작업(GLM), 초장문 컨텍스트·비전(Scout) | 96GB에선 단독 실행 | 긴 코드베이스를 한 번에 읽고 질의 |
| Whisper large-v3 (mlx-whisper, ~3GB) | 한국어 음성→텍스트, 회의록·강의 전사 | 화자 분리는 별도 도구 | 미팅 녹음 → 요구사항 정리 |
| bge-m3 / multilingual-e5 (~1GB) | 다국어 임베딩(검색·군집·중복 판정) | 생성 불가 | 크롤링 결과 중복 제거, 키워드 군집, 사내 문서 RAG |
| Flux.1 dev/schnell (12~24GB) | 이미지 생성(썸네일·OG 이미지·배너) | 한글 텍스트 렌더링 약함 | 표지·히어로 이미지 |
작업 → 모델 빠른 매핑
- 대량 데이터 정제·분류·JSON 추출(수천~수만 건): Qwen3-Coder-30B-A3B 또는 Qwen3-30B-A3B. 100 tok/s면 하루 수만 건을 무료로 처리.
- 한국어 글쓰기·번역·요약: Gemma 3 27B → EXAONE 32B(격식 문서) → Qwen3-32B.
- 코딩 에이전트: Qwen3-Coder-30B-A3B(속도) / GPT-OSS-120B(품질). 도구는 Continue, Cline, OpenHands, Zed + LM Studio/Ollama 서버.
- 스크린샷·이미지 판단: Gemma 3 27B(빠름) → Qwen-VL-72B(정밀).
- 복잡한 원인 추론·계획: GPT-OSS-120B(reasoning high) 또는 R1-Distill-32B.
- RAG: bge-m3 임베딩 + Gemma 3 27B 또는 Qwen3-32B.
96GB면 30B-A3B 코더(18GB) + Gemma 27B 비전(17GB) + Whisper(3GB) + 임베딩(1GB) ≈ 40GB를 동시에 상주시키고도 개발 작업 메모리가 남습니다. 120B급을 띄울 땐 그것만 단독으로. 파인튜닝은 MLX LoRA로 7B~32B까지 무리 없고, 70B QLoRA는 가능하지만 느립니다.
2. 256GB — "프론티어-1세대" 티어
오픈 모델의 최상위 한 단계 아래가 통째로 들어옵니다. 로컬 모델이 판단이 필요한 일의 절반쯤을 흡수하기 시작하는 구간입니다. 체감으로는 "2025년 상반기 최상위 클라우드 모델을 무제한·무료로 쓰는" 수준.
| 모델 | 메모리 | 속도 | 무엇이 달라지나 |
|---|---|---|---|
| Qwen3-235B-A22B (Instruct/Thinking) | ~130GB | 35~45 tok/s | 오픈 모델 중 한국어 최상급, 코딩·추론이 GPT-4.1/Claude Sonnet 3.7급. 여러 파일에 걸친 에이전트 코딩을 실수 적게 완주하고, 긴 한국어 문서를 클라우드 품질에 근접하게 씀 |
| GLM-4.5 (355B-A32B) | ~200GB | 25~30 tok/s | 에이전틱 코딩 특화 — 도구 호출·장기 작업 계획이 Claude Sonnet 4에 근접한다고 보고됨. 컨텍스트는 32k 내외 |
| Llama 4 Maverick (400B-A17B) | ~220GB | ~50 tok/s | 초장문 컨텍스트·비전. 평가는 엇갈려 235B가 대체로 우선 |
| Mistral Large 123B 8bit / 70B bf16 | 130~140GB | 15~20 tok/s | 양자화 손실 없는 원본 정밀도 — 평가·파인튜닝·재현성 |
| GPT-OSS-120B + 128k 컨텍스트 | 63GB + KV 수십GB | 그대로 | 96GB에선 32k에 묶였던 컨텍스트를 풀로 — 코드베이스 통째 투입 |
| 동시 상주 | 235B + 30B 코더 + Gemma 비전 | — | "판단용 큰 모델 + 실행용 빠른 모델" 2단 구조를 로컬에서 재현 |
| 파인튜닝 | 70B LoRA 여유, 235B QLoRA 가능 | — | 자사 문체·도메인을 큰 모델에 학습 |
3. 512GB — 오픈 프론티어급
DeepSeek V3/R1(671B) 4bit ~380GB, Kimi K2(1T) ~550GB, Qwen3-Coder-480B ~270GB는 256GB에도 안 들어갑니다. 2bit로 욱여넣으면 품질 손실이 커서 235B 4bit만 못합니다. 이 체급은 512GB 구성의 영역입니다.
4. 소설·창작 글쓰기는 96GB로 되나
됩니다. 창작은 메모리보다 한국어 문장 품질과 긴 맥락의 일관성이 관건인데, 그 용도의 최적 모델이 전부 30B 안팎(~18GB)이라 96GB에서 컨텍스트 128k까지 열어도 여유가 있습니다.
- 모델: Gemma 3 27B(한국어 문장이 가장 자연스러움, 1순위) → EXAONE 4.0 32B(존댓말·정서 표현) → Qwen3-32B(플롯 논리·설정 검증). 4bit 27B는 ~45 tok/s라 5,000자 한 화가 3~4분. 로맨스처럼 감정선이 중요한 장르는 초안은 Gemma, 퇴고·설정 모순 검사는 Qwen으로 교차하면 품질이 올라갑니다.
- 워크플로우: 스토리 바이블(인물·관계·세계관·금지 설정) + 직전 화 요약을 매 요청 컨텍스트에 넣고 화 단위로 생성 → 별도 프롬프트로 문체 통일 퇴고. 도구는 LM Studio 서버 + Novelcrafter/SillyTavern(인물·설정 관리) 또는 Obsidian.
- 진짜 레버는 파인튜닝: 웹소설 특유의 문체(짧은 호흡, 대사 위주, 1인칭 내면 묘사)는 범용 모델이 밋밋하게 씁니다. 본인 원고나 공개 코퍼스로 MLX LoRA를 27~32B에 학습하면(96GB에서 수 시간) 문체가 확 달라집니다.
- 한계: 클라우드 최상위 모델이 뉘앙스·복선 회수에서 여전히 앞섭니다. 로컬의 장점은 무제한·무료·비공개(원고 유출 없음)와 검열 완화. 256GB로 가면 Qwen3-235B가 들어와 한국어 장문 일관성이 눈에 띄게 좋아집니다.
5. 어느 구성을 고를까
- 96GB: 클라우드 API를 병행하면서 대량·반복 작업을 로컬로 내리는 용도. 120B급 상한.
- 256GB(+$4,000, 약 ₩5~6M): 클라우드 지출이 월 ₩30만 이상이면 1.5~2년 내 회수. 긴 프롬프트 처리(prefill)는 GPU 연산 비례라 36코어/80코어 GPU 구성이 에이전트 작업에서 체감이 큽니다.
- MacBook Pro M5 Max 128GB는 235B급이 안 들어가는 건 96GB Ultra와 같으면서 대역폭이 절반(614GB/s)이라, 이동이 필요 없다면 Studio 96GB가 더 빠르고 쌉니다.
런타임은 MLX(mlx-lm, LM Studio의 MLX 백엔드)가 Apple Silicon에서 가장 빠르고 llama.cpp Metal이 차선입니다. 모델은 Hugging Face에서 "MLX 4bit" 변환본 기준으로 고르면 됩니다.