| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
| 31 |
- docker
- kotlin coroutine
- 오블완
- 코틀린 코루틴의 정석
- CKA 기출문제
- 바이브코딩
- 공부
- go
- Kubernetes
- Claude
- aws
- Java
- LLM
- CloudWatch
- tucker의 go 언어 프로그래밍
- SRE
- 기록으로 실력을 쌓자
- kotlin
- 티스토리챌린지
- HARNESS
- MySQL
- golang
- AWS EKS
- Spring
- Rag
- minikube
- AI
- 정보처리기사 실기 기출문제
- CKA
- PETERICA
- Today
- Total
피터의 개발이야기
[온디바이스AI] 로컬 LLM에서 중요한 것은 CPU가 아니라 메모리다 - 맥미니와 모델 크기의 관계 본문

TL;DR
로컬 LLM 환경에서 가장 먼저 부딪히는 벽은 연산 성능보다 메모리다.
작은 모델은 “문장을 생성”하지만,
큰 모델은 “컨텍스트를 유지하며 추론”한다.
결국 로컬 AI 머신의 핵심은 CPU 속도가 아니라,
얼마나 큰 모델과 Context를 메모리에 안정적으로 올릴 수 있는가에 가깝다.
ㅁ 들어가며
오늘 한 크루가 맥미니를 구매해서 로컬 LLM 기반 서비스를 직접 만들어 보고 싶다고 이야기했다.
그러면서 자연스럽게 이런 질문이 나왔다.
“맥미니를 산다면 CPU가 중요할까, GPU가 중요할까?”
처음에는 보통 코어 수나 GPU 성능을 먼저 보게 된다.
그런데 실제로 로컬 LLM을 구성해보면 병목은 생각보다 다른 곳에서 먼저 나타난다.
좀 더 자세한 글) [AI] GPU vs PIM vs NPU - 내 시스템의 병목은 연산인가, 메모리인가
모델이 커질수록 가장 먼저 부족해지는 것은 연산 성능보다 메모리다.
특히 Apple Silicon은 통합 메모리 구조이기 때문에 이 특징이 더 강하게 드러난다.
ㅁ 로컬 LLM은 왜 메모리를 많이 먹는가
일반적인 PC에서는 CPU 메모리와 GPU VRAM이 분리되어 있다.
하지만 Apple Silicon은 다르다.
CPU, GPU, Neural Engine이 모두 같은 메모리를 공유한다.
즉 로컬 LLM을 실행할 때 메모리는 단순히 “프로그램 실행 공간”이 아니다.
다음 요소들이 모두 메모리를 사용한다.
문제는 모델이 커질수록 단순히 저장 공간만 늘어나는 것이 아니라,
“계속 읽어와야 하는 데이터”가 급격히 증가한다는 점이다.
특히 추론(decode) 단계에서는:
- 이전 토큰 상태를 계속 참조하고
- KV Cache를 반복적으로 읽고
- 긴 Context를 유지해야 한다.
즉 AI 추론은 생각보다 “계산”보다 “메모리 접근” 비용이 더 커진다.
그래서 로컬 LLM에서는 CPU 성능보다 메모리 용량과 대역폭이 훨씬 중요하게 체감된다.
ㅁ 작은 모델은 왜 쉽게 맥락을 잃는가
처음 로컬 LLM을 접하면 7B~8B 모델만으로도 꽤 놀랍다.
번역도 되고,
요약도 되고,
코드도 어느 정도 작성한다.
하지만 조금만 복잡한 작업을 시키면 한계가 드러난다.
예를 들면:
- 이전 조건을 잊는다
- 긴 문서를 읽다가 핵심을 놓친다
- 여러 제약을 동시에 유지하지 못한다
- Agent 흐름이 쉽게 무너진다
처음에는 “프롬프트를 잘못 준 것 아닐까?”라고 생각했는데, 계속 사용하다 보니 단순 프롬프트 문제가 아니었다.
작은 모델은 “문장을 생성”하는 능력은 괜찮지만, 긴 흐름을 유지하며 추론하는 능력은 제한적이다.
즉 말은 자연스럽지만, 생각의 지속성이 약하다.
ㅁ 모델 크기가 커질수록 달라지는 점
14B~16B 정도부터는 확실히 느낌이 달라진다.
이 구간부터는:
- 여러 조건을 동시에 유지하고
- 문서 구조를 이해하려 하고
- 이전 Context를 덜 잊는다.
특히 RAG와 연결했을 때 차이가 크다.
7B에서는 검색된 문서 일부만 참고하다가 핵심을 놓치는 경우가 많았는데,
16B급부터는 “문서를 기반으로 답하려는 느낌”이 생긴다.
그리고 32B 구간부터는 체감이 더 커진다.
이 시점부터는:
- 장기 Context 유지
- 설계 reasoning
- Multi-Agent 흐름
- 코드 구조 이해
같은 작업이 꽤 안정적으로 동작한다.
개인적으로는 이 구간부터 로컬 LLM이 단순 장난감이 아니라 “도구”처럼 느껴진다.
실사용 관점으로 정리하면 대략 이런 느낌이다.
| 모델급 | 권장 메모리 | 체감 능력 | |
| 7B~8B | 16GB | 번역, 요약, 단순 코드 보조, 짧은 질답 | 추론 깊이가 얕음. 긴 대화에서 맥락 손실 잦음 |
| 14B~16B | 24~32GB | 간단한 추론, 문서 구조 이해, 기본 Agent 가능 | 여러 조건 비교/장기 계획 약함 |
| 32B | 64GB | “생각하는 느낌”이 생김. RAG 활용 안정화 | 복합 추론에서 아직 실수 존재 |
| 70B | 128GB+ | 클라우드 모델에 가까운 품질 체감 | 비용/속도 부담 큼 |
| MoE 대형 모델 | 128GB~256GB | 특정 영역 매우 강력 | 로컬 운영 난이도 매우 높음 |
ㅁ 결국 맥미니에서 중요한 것은 메모리다
흥미로운 점은 로컬 LLM 환경에서는 CPU 업그레이드보다 메모리 업그레이드 체감이 훨씬 크다는 점이다.
실제로는 다음처럼 느껴진다.
여기서 중요한 점은 “실행 가능”과 “안정적으로 운용 가능”은 완전히 다르다는 것이다.
메모리가 부족하면 일부 데이터를 SSD swap으로 넘기게 되는데, 이 순간부터 응답 속도가 급격히 느려진다.
그리고 단순히 느려지는 것을 넘어서, 추론 흐름 자체가 끊기는 느낌이 발생한다.
ㅁ 마무리 — 로컬 LLM의 병목은 결국 메모리다
처음에는 로컬 AI 머신이라고 하면 CPU나 GPU 성능을 먼저 떠올리게 된다.
하지만 실제로 계속 실험해보면 생각보다 더 중요한 것은
“얼마나 큰 모델과 Context를 메모리에 안정적으로 유지할 수 있는가”
였다.
결국 로컬 LLM 환경에서 중요한 것은 단순 FLOPS가 아니라,
Context를 잃지 않고 계속 유지할 수 있는 메모리 구조에 더 가까운 것 같다.
'AI > RAG' 카테고리의 다른 글
| 어디서든 브라우저 VS Code로 마크다운만 떨어뜨리면 LLM 이 개인 위키로 자동 정리 - silva-omnium (0) | 2026.04.28 |
|---|---|
| [온디바이스AI] 청크는 쌓는 게 아니라 덜어내는 일 — 약한 청크 25개를 덜어내 MRR이 0.15 올랐다 (0) | 2026.04.23 |
| [온디바이스AI] LiteRT-LM — 온디바이스 LLM을 실제로 “돌리게” 만드는 런타임 (0) | 2026.04.23 |
| [온디바이스AI] 처음 만드는 온디바이스 RAG — 핵심원칙 10가지 (0) | 2026.04.22 |
| [온디바이스AI] 내 폰으로 나만의 RAG 만들기(온디바이스 RAG 최소 아키텍처) (0) | 2026.04.21 |