맥 UMA에서 120B MoE가 26B Dense에게 진 이유 — 메모리 대역폭 병목 원리
결론부터 말한다. 맥 스튜디오 M4 Max 128GB에서 gpt-oss:120b(MoE, 활성 5.1B)가 gemma4:26b(Dense) 대비 절반 속도다. 실측은 47 tok/s 대 85 tok/s. 직관과 결과가 정반대다. 활성 파라미터만 보면 5.1B가 26B를 앞서야 맞다. 이 글은 왜 반대 결과가 나오는지, 원리를 분석한다. 벤치마크는 증거로만 쓴다. 같은 원리는 다른 Apple Silicon과 다른 모델 조합에서도 재현된다.
이 글의 대상: Mac에서 로컬 LLM 추론 환경을 운영 중이거나 준비 중인 중급 이상 개발자. 모델 선택 기준을 파라미터 수가 아닌 메모리 구조로 세우려는 독자.
Apple Silicon UMA가 VRAM과 뭐가 다른가
"VRAM 16GB면 16GB 모델까지 돌아간다"는 일반 GPU 규칙이 맥에선 성립하지 않는다. Apple Silicon은 UMA(Unified Memory Architecture, 통합 메모리 구조)를 쓴다. CPU와 GPU가 같은 물리 메모리 풀을 공유한다. 별도 VRAM 개념이 없다.
- 일반 NVIDIA GPU: VRAM 24GB(RTX 4090) → 모델 + KV 캐시(이전 토큰의 key/value 저장소) + 활성 파라미터 전부 여기 들어가야 함. GDDR6X 대역폭 1TB/s 내외.
- Apple M4 Max 128GB: 통합 메모리 128GB → CPU/GPU 공유. LPDDR5X 대역폭 546GB/s.
용량은 Apple 쪽이 크다. 대역폭은 NVIDIA 쪽이 두 배다. 로컬 LLM 추론에서 속도를 결정하는 것은 용량이 아니라 대역폭이다. 이 한 줄이 이 글의 축이다.
로컬 LLM 추론 속도 = 대역폭 ÷ 토큰당 읽어야 할 파라미터
토큰 하나 생성할 때마다 모델이 필요한 파라미터를 메모리에서 읽어 계산한다. 생성 속도는 대략 이렇게 풀린다.
이론 상한(tok/s) ≈ 메모리 대역폭 ÷ 토큰당 읽어야 할 파라미터 크기
이 공식은 절대치 예측이 아니라 상대 순위 추론용이다. 실제 속도는 여기에 양자화·캐시·SIMD 최적화 계수가 곱해진다. 중요한 건 분모. 분모가 작으면 순위가 올라가고, 분모가 크면 순위가 떨어진다.
Dense 모델은 매 토큰마다 전체 파라미터를 읽는다. 접근이 선형적. 캐시 친화적. MoE 모델은 매 토큰마다 활성 전문가만 읽는다. 이론적으로 활성 파라미터 크기만 읽으면 됨. 5.1B 활성이면 26B Dense 대비 5배 빨라야 맞다.
현실은 다르다.
MoE가 이론 기대를 달성하지 못하는 이유
MoE의 "전문가"는 토큰마다 바뀐다. 토큰 A는 전문가 3번, 토큰 B는 전문가 17번. 활성만 읽어도 되지만, 어느 전문가가 활성될지 사전에 모르기 때문에 전체 모델이 메모리에 상주해야 한다. 65GB짜리 gpt-oss:120b는 통째로 램에 올라가 있어야 한다.
여기까지는 용량 문제고, 실측 속도 역전은 그다음 단계에서 생긴다. MoE의 메모리 접근이 비국소적(non-local)이다. 토큰마다 전문가가 램의 다른 위치에 있다. 메모리 컨트롤러의 순차 예측, 프리페치(prefetch, 다음 필요한 데이터 미리 읽기), CPU 캐시 라인 재사용 — 전부 깨진다. 이론 활성 파라미터가 5.1B여도 실효 대역폭은 전체 65GB를 훑는 수준으로 확장된다.
반면 Dense 26B는 26GB 모델(Q8 기준)을 매번 순서대로 훑는다. 메모리 컨트롤러가 예측하기 쉽다. LPDDR5X의 546GB/s를 실제로 거의 다 쓴다.
이론 상한 vs 실측 — 실효 효율 계수
이론 상한이 실측과 다른 이유는 양자화와 최적화 계수가 있기 때문이다. Ollama 내부 최적화 3가지가 실측을 끌어올린다.
mmap기반 OS 페이지 캐시 활용 — 디스크에서 모델을 메모리로 바로 매핑, 중복 복사 제거- SIMD 명령어로 Q4 역양자화 병렬 처리 — 4-bit 압축을 벡터 유닛이 일괄 복원
- KV 캐시 재사용 — 이미 생성된 토큰의 계산 결과 보존, 토큰당 새로 읽어야 하는 양 감소
실측/이론 상한 비율을 모델별로 뽑아보면 패턴이 드러난다.
| 모델 | 읽어야 하는 실효 크기 | 이론 상한 | 실측 | 실측/이론 |
|---|---|---|---|---|
gpt-oss:120b (MoE) |
~65GB 전수 훑음 | 8.4 tok/s | 47 tok/s | 5.6× |
gemma4:26b (Dense Q4) |
~17GB | 32 tok/s | 85 tok/s | 2.7× |
gemma4:latest (Dense 9B Q4) |
~6GB | 91 tok/s | 88 tok/s | 0.97× |
읽을 때:
- MoE는 상한의 5.6배를 실측으로 찍는다. 비국소 접근 페널티가 큰 대신 KV 캐시와 SIMD가 이를 부분적으로 상쇄.
- Dense 26B는 상한의 2.7배. 양자화 효율이 주요 상승 요인.
- Dense 9B는 이미 실효 크기가 작아 상한에 거의 닿음(0.97×).
요점: 공식 분모(읽어야 할 파라미터)가 MoE는 활성 5.1B가 아니라 실제론 전체 65GB급. 이걸 인정해야 순위가 실측과 맞는다.
실측으로 확인 — 4-way 벤치마크
같은 하드웨어, 같은 Ollama 0.20.7, 같은 프롬프트 3종(짧은 한국어, 짧은 수학, 긴 코드)으로 측정.
| 모델 | 구조 | 디스크 | 활성 파라미터 | 생성 속도 |
|---|---|---|---|---|
gpt-oss:120b |
MoE 117B | 65GB | 5.1B | 47 tok/s |
qwen3.6:35b-a3b-q8_0 |
MoE 35B | 38GB | ~3B | 25 tok/s |
gemma4:26b |
Dense 26B (Q4) | 17GB | 26B | 85 tok/s |
gemma4:latest |
Dense 9B (Q4) | 9.6GB | 9B | 88 tok/s |
세 가지가 드러난다.
- MoE 두 모델이 하단. 활성 파라미터 3~5B인데 Dense 9B보다 느리다. 비국소 접근이 이론 기대를 먹는다.
- 26B Dense가 9B Dense와 거의 동률. 파라미터 3배 차이가 속도에 거의 반영 안 됨. 양자화(Q4)가 실효 크기를 절반 이하로 줄이기 때문.
- 속도의 지배 요인: 파라미터 수가 아니라 읽어야 할 실효 GB.
원리의 일반화 — 다른 Mac/다른 모델에 적용되나
이 원리는 Apple Silicon의 물리적 속성(UMA + LPDDR)에서 나온다. 따라서:
- M4 Pro 48GB: 대역폭 273GB/s (M4 Max의 절반). 모든 모델이 대략 절반 속도. Dense 우위 순위 유지.
- M2 Ultra 192GB: 대역폭 800GB/s. 대역폭 여유가 커 MoE 격차가 좁아지지만 Dense 우세 유지.
- M5 추정: Apple이 M2 Max→M4 Max에서 대역폭을 400→546GB/s로 37% 올렸다. 같은 추세면 M5 Max는 약 750GB/s. NVIDIA HBM3(3TB/s)과의 4배 격차는 여전함. MoE가 역전하려면 대역폭보다 메모리 컨트롤러가 비국소 접근에 특화돼야 함. 공개된 로드맵엔 그 신호 없음.
요약하면 이 속도 역전은 Apple Silicon 전반의 구조적 특성이고, 적어도 M4 세대까지는 유효하다.
MoE가 이기는 예외 조건
MoE가 항상 진다는 얘기는 아니다. 세 조건에서는 MoE가 Dense를 앞선다.
- NVIDIA 데이터센터 GPU: HBM3 대역폭 3TB/s 이상. 비국소 접근 페널티를 대역폭이 덮는다.
- 크기가 Dense로는 메모리에 못 올라가는 구간: 120B Dense는 Mac 128GB로도 추론 어려움. MoE가 "느리지만 돌아는 가는" 유일 옵션.
- 활성 전문가 수가 매우 적은 구조: 활성 1B 이하의 희소 MoE는 접근 패턴이 캐시에 들어가 이론값 근접.
Apple Silicon 128GB 급에서는 이 세 조건 중 어느 것도 해당 안 됨. 그래서 Dense가 이긴다.
자주 묻는 질문
gpt-oss:120b는 왜 ollama에서 65GB인데 활성이 5.1B라고 하나?
총 파라미터는 117B이고, MoE는 라우터가 토큰마다 몇 개 전문가를 활성화한다. 활성 5.1B는 토큰 한 개를 만드는 계산량 기준. 파일 크기 65GB는 전체 전문가 풀을 전부 저장해야 하기 때문.
num_ctx를 32768로 올리면 이 속도 역전이 바뀌나?
아니다. num_ctx는 KV 캐시 크기에 영향을 주지만 모델 자체의 메모리 접근 패턴은 바꾸지 않는다. Dense vs MoE의 상대 속도는 컨텍스트 길이와 무관하게 유지된다.
양자화를 더 세게 쓰면 MoE가 Dense를 이길 수 있나?
이론상 가능. MoE 전체 풀을 Q2까지 떨어뜨리면 실효 읽기량이 대폭 줄어든다. 하지만 Q2는 출력 품질이 무너진다. 실사용 가능한 Q4 이상에서는 역전 안 남.
직접 확인하려면
본인 맥에서 같은 비교를 하려면 3단계.
- 현재 로드된 모델 메모리 점유 확인:
ollama ps— 각 모델의 SIZE와 PROCESSOR(CPU/GPU/100% GPU) 확인. MoE는 SIZE가 크고 Dense는 작아야 정상. - 같은 프롬프트 3종으로 측정: 짧은 한국어, 짧은 수학, 긴 코드 생성.
curl -s http://localhost:11434/api/generate -d '{...}' | jq '.eval_count / .eval_duration * 1e9'로 tok/s 추출. - 같은 모델 Q4 vs Q8로 교체 측정: 양자화가 분모에 미치는 영향 확인. Q4 → Q8로 바꾸면 실효 크기 2배 → 속도 절반이 맞는지 체크.
세 측정값을 본 글의 표와 비교하면 본인 맥의 대역폭 활용 효율이 나온다. M4 Max가 아닌 다른 세대라면 비율이 달라질 수 있지만 순위는 유지된다.
관련 시리즈
- 맥 스튜디오 128GB로 120B 로컬 LLM 돌려봤더니 가장 빠른 건 120B가 아니었다
- OpenClaw 디스코드 멀티봇 7개 자율 협업 — 1박 2일 시도 끝 결론
댓글
댓글 쓰기