Unified Memory는 CPU, 통합 GPU, NPU가 분리된 VRAM 대신 하나의 메모리 풀을 공유하는 구조다. 로컬 LLM에서는 70B급 모델을 “올릴 수 있느냐”를 바꾸는 장점이 있지만, “빠르게 생성하느냐”는 별도 문제다.
핵심 구조
일반 데스크톱은 시스템 RAM과 GPU VRAM이 나뉜다. 32GB VRAM GPU는 시스템 RAM이 256GB여도 GPU 위에서 40GB 모델을 실행할 수 없다. Unified Memory 머신은 64GB, 128GB, 512GB 같은 단일 풀을 모델에 할당할 수 있어 큰 quantized 모델을 로드할 수 있다.
문제는 대역폭이다. 토큰 생성(decode)은 매 토큰마다 모델 가중치를 거의 한 번 읽는 memory-bound 작업이다.
decode tokens/sec ≈ memory bandwidth ÷ bytes read per token예를 들어 4-bit dense 70B 모델이 토큰당 약 40GB를 읽는다면, 256GB/s급 unified memory 장비의 이론상 상한은 약 6 tokens/s 근처다. 반면 고급 discrete GPU는 900~1,800GB/s 대역폭을 갖지만 VRAM 용량이 부족할 수 있다.
prefill과 decode는 병목이 다르다
| 단계 | 병목 | 사용자 체감 |
|---|---|---|
| Prefill | compute | 긴 문서를 읽고 첫 토큰을 내기까지 걸리는 시간 |
| Decode | memory bandwidth | 답변이 한 토큰씩 생성되는 속도 |
Mini PC가 dense 70B를 “실행”할 수 있어도 긴 코드베이스나 문서를 넣으면 prefill이 느려질 수 있다. 반대로 MoE 모델은 전체 파라미터보다 활성 파라미터가 작아 토큰당 읽는 바이트가 줄어 unified memory 장비에서 훨씬 빠르게 느껴질 수 있다.
선택 기준
| 목표 | 적합한 하드웨어 |
|---|---|
| 큰 dense 모델을 천천히라도 로컬에서 실행 | 128GB 이상 unified memory |
| 30B급 MoE를 빠르게 실행 | 64~128GB unified memory 장비 |
| dense 70B를 빠르게 실행하거나 긴 prompt를 자주 처리 | 48GB 이상 discrete GPU 또는 클라우드 GPU |
| 작은 모델을 고속 서빙 | VRAM이 충분한 discrete GPU |
NPU에 대한 오해
NPU가 있어도 LLM decode 병목이 메모리 대역폭이면 같은 메모리 풀을 공유하는 한 속도 상한이 크게 오르지 않는다. 또한 llama.cpp, Ollama 같은 주류 로컬 LLM 런타임의 NPU 지원은 GPU 지원보다 제한적이다. NPU는 작은 상시 vision/audio 작업에는 유용하지만, 대형 챗봇 실행의 만능 해법은 아니다.
관련 문서
- local-slm — 내 컴퓨터에서 실행하는 소형 언어 모델 개요
- modular-max — Apple Silicon GPU에서 실행되는 AI 모델 서빙 스택
- glm-5-2-tutorial-local-unsloth — 대형 오픈 모델 로컬 실행 가이드
- vllm — 고처리량 LLM 추론·서빙 엔진
참고 자료
- Unified Memory, Explained — Vetted Consumer (2026-07)