Mac Mini M4를 사기 전에 가장 많이 검색하는 것은 M4 Mac Mini 로컬 LLM이 어디까지 실용적인지, 16GB 대 24GB 차이가 얼마나 큰지, Mac Mini에서 LLM을 돌리면 swap이 자주 나는지입니다. 2026년에는 Qwen2.5, 라마 3.1 등의 가중치를 Ollama로 Apple Silicon에서 돌릴 수 있습니다. 병목은 보통 통합 메모리이며, 디스크리트 GPU 유무가 아닙니다.
7B와 14B만 고르시나요? 결정 Spoke M4 Mac Mini: 7B vs 14B 실사용 차이 (2026 실측)(플로차트, Agent TTFT, §8.4 선택표). 이 Hub는 방법론·실패 샘플·raw dump용입니다.
이 글은 「모델 목록 정리」가 아닙니다. 실패 샘플과 raw dump가 있는 Lab 로그(2026-05-20 ~ 06-02)입니다. 산출물: 샘플-벤치마크-run.log, 원시 VM-stat-dump.txt, ollama-디버그-excerpt.log.
프레임워크 비교는 MLX vs Ollama 실측, 통합 메모리 원리는 통합 메모리와 LLM 추론을 참고하세요.
1. 시스템 인과 모델 및 하드 제약
기본 Mac Mini M4(Pro 아님)에는 다음이 함께 제공됩니다.16GB, 24GB 또는 32GB통합 메모리, 10코어 GPU, 그리고 대략120GB/초메모리 대역폭(M4 Pro ~273GB/s). 아래의 모든 tok/s, 스왑 및 TTFT 번호는 이에 매핑됩니다.3계층 리소스 모델-이해하다why먼저 §3~§5에서 무슨 일이 일어났는지 읽어보세요.
M4 로컬 LLM 추론: 3계층 리소스 인과 모델
| Layer | 통제 수단 | 인과 메커니즘 | 이 기사의 관측 앵커 |
|---|---|---|---|
| L1 용량 메모리 용량 |
탑재 가능 여부, OOM 여부 | 점유 ≈ 가중치 + KV cache(∝ num_ctx) + OS/포그라운드. 물리 메모리 초과 → 압축 → swap → runner 종료 |
14B @ 16GB OOM;num_ctx=65536자동 시간 초과 |
| L2 대역폭 메모리 대역폭 |
청정 상태 tok/s 한도 | 각 디코드 토큰은 전체 가중치 스트림을 읽습니다.tok/s ≒ 유효 대역폭 ¼ 토큰당 이동된 바이트. 동일한 칩, 동일한 모델: L2는 GB 수만 고려하지 않고 기준을 ~29 tok/s로 설정합니다. | 16GB 클린 8B 중앙값 28.8; 24GB 동일 모델 51.2(§1.4 참조) |
| L3 압력 압력 / 논쟁 |
비선형 성능 붕괴 | 유선 상승 → 압축기 활성 → 메모리 상태 경고/위험 → 스왑인 → GPU 페이지 오류 →톡/스 절벽(비선형, §5 2~3단계 참조) | Swapins 8421 → 3.4 tok/s; 중요 @ 14.8GB 유선 |
인과 사슬(로그를 읽을 때):구성 변경 → 어떤 레이어가 먼저인가요? 더 큰 모델/ctx → L1; 동일한 로드 16GB 대 24GB → 종종 L1 헤드룸이 L3 실행 여부를 결정합니다. 열 −12% → L2 유효 대역폭 감소; Metal이 없는 Ollama → L2 경로가 CPU로 대체됩니다.
1.1 L1 용량: 가중치 + KV가 통합 메모리에 맞아야 합니다.
추론 점유 ≈ 양자화 가중치 + KV 캐시(num_ctx에 비례) + macOS와 포그라운드 앱. L1에 여유가 있는 동안 L3는 발화하지 않습니다—baseline 28.8 tok/s의 전제입니다. L1이 한계에 닿으면 시스템은 「균일하게 느려지지」 않고 §5 Phase 2/3에 들어갑니다. 경험상 모델 관련 점유는 총 RAM의 약 70% 미만으로；16GB에서 Xcode + Chrome + Ollama를 동시에 열면 실효 여유는 10GB대 초반까지 줄어듭니다.
1.2 L2 대역폭: 클린 상태 tok/s에 한계가 있는 이유
자동회귀 디코드는 일반적으로 다음으로 제한됩니다.통합 메모리에서 GPU 컴퓨팅 유닛으로 가중치 이동. Llama 3.1 8B Q4 가중치 ~4.9GB; M4 @ 120GB/s는 ~25~35tok/s 대역에 속하며 측정된 중앙값 28.8과 일치합니다. Warm Machine 25.1과 Outlier 31.1은 L3 스왑이 아닌 L2 노이즈(스로틀/GC)입니다. §3~§7 원시 로그를 참조하세요.
1.3 L1 전제조건: 양자화가 적합성을 결정합니다.
기본 Ollama 태그는 대부분 Q4(GGUF, 참조)입니다.라마.cpp). 8B: Q4_K_M ~5GB, Q8_0 ~8GB - 16GB는 Q8 8B를 실행할 수 있지만 KV 헤드룸은 작고 L3 트리거가 더 쉽습니다. 이 기사에서는 다음과 같이 가정합니다.Q4_K_M언급되지 않는 한.
1.4 24GB가 "비선형" 업그레이드인 이유
24GB는 L2 대역폭을 두 배로 늘리지 않습니다.동일한 M4 다이, 유사한 L2 천장. 24GB 8B 중앙값 51.2의 주된 이유는가중치 + KV는 L3 경합 없이 GPU 친화적인 상주 상태로 유지됩니다., Ollama/Metal은 더 큰 배치와 안정적인 버퍼를 사용할 수 있습니다. 깨끗한 16GB 8B는 이미 L1 가장자리 근처에 있습니다. 모든 Chrome 탭이 1단계를 추진합니다. 16GB→24GB 구매L1 헤드룸 → 지연된 L3, "+8GB = +8 tok/s" 선형 확장이 아닙니다.
2. 기준선: 첫 번째 클린 시스템 실행
이후의 모든 비교를 위한 기준: Mac Mini M416GB, 터미널 + Ollama 전용, 라마 3.1 8B Q4, 512 프롬프트 / 256 gen, 온도=0.2. 머신 IDm4-16gb-lab-01, 맥OS 15.4.
| Metric | 2026-05-28 첫 번째 기준선 | Notes |
|---|---|---|
| 톡/초(5회 실행) | 28.1 / 29.8 / 27.2 / 20.8* / 31.1 | *run4에는 Chrome이 있었습니다. 제외된 |
| 중앙값 / 평균 | 28.8 / 29.05 | 비단조적; §3 참조 |
| TTFT 벽시계 | 1.82 / 2.61 / 1.94 / 2.08초 | run2 지터를 2.61초로 |
| Swapins | 0 | vm_stat 스냅샷 |
| Metal | ggml_metal_init: Apple M4 | 디버그 로그를 참조하세요 |
이것은 "하나의 벤치마크 다음 요약"이 아닙니다.3주 엔지니어링 로그; 동일한 구성의 중앙값은 여러 날짜에 걸쳐 27.9~29.2로 이동할 수 있습니다(§6.3).
3. 로그 및 원시 시스템 덤프 실행
아래에는 선별되지 않은 실험실 아티팩트가 있습니다(요약 아님). 전체 벤치마크:리소스/샘플-벤치마크-run.log; 시스템 덤프:리소스/원시 VM-stat-dump.txt; 올라마 디버그:리소스/ollama-디버그-excerpt.log.
3.1 벤치마크 스크립트 출력(발췌)
--- run 2 / 5 --- (machine warm, fan ~4200rpm)
eval_count=256 elapsed=8.6s tok/s=29.8 TTFT_wall=2.61s
--- run 5 / 5 --- (outlier: GC pause mid-decode)
eval_count=256 elapsed=8.0s tok/s=31.1 TTFT_wall=2.08s
중앙값 톡/초: 28.8
mean: 29.05
p90: 30.43.2 vm_stat + 기억 상태(실행 3과 동일한 창)
Pages wired down: 201888.
Pages stored in compressor: 94208.
Swapins: 0.
# 14B failure session later same day:
기억 상태: pressure level 4 (비판적인)
기억 상태: killing_low_priority_processes전체 덤프에는 다음이 포함됩니다.상단 -l 1 and 로그 쇼… 메모리 상태; see 원시 VM-stat-dump.txt.
3.3 시스템 수준 잡음(비모델 요인)
| 소음원 | 관찰 | 톡/초에 미치는 영향 |
|---|---|---|
| 발열/팬 4200rpm | ~20분 연속 실행 | 29.8 → 25.1 (~-12%),제외되지 않음 |
| TTFT 지터 | 1.82 → 2.61 → 1.94초 | 상담원의 첫 번째 턴 느낌 |
| 메모리 압축기 | 94208 페이지 압축 | 사전 스왑; 아직 사용 가능 |
| 금속 버퍼 재 할당 | 디버그에 WARN 줄 1개 | 단일 실행 -3~5%, 치명적이지 않음 |
| 오후 주변 | 2026-06-02 14:00 재테스트 | 중앙값 27.9, 이상값 24.3 |
3.4 재현
chmod +x 리소스/benchmark-m4-mac-mini-ollama.sh
./리소스/benchmark-m4-mac-mini-ollama.sh 라마3.1:8b
# recommended second terminal:
log stream --predicate 'subsystem == "com.apple.기억 상태"' --level debug4. 자원 고갈 분류(실패 귀인)
§3 원시 로그는 연대순입니다. 이 섹션에서는 다음으로 분류합니다.피로 유형—실패한 경우 L1, L2 또는 L3 중 무엇인지 물어보십시오.
| Type | Layer | 전형적인 증상 | 이 기사의 사례 | 방향 고정 |
|---|---|---|---|---|
| E1 용량 소진 용량 소진 |
L1 | OOM 로드, 러너 종료, 모델이 맞지 않음 | qwen2.5:14b @ 16GB →신호: 죽었어 (으음?) |
소형 모델 / RAM ~ 24GB |
| E2 압력 붕괴 압력붕괴 |
L3 → L2를 드래그 | Swapins 스파이크, tok/s 절벽, TTFT 5s+ | 스왑핀 8421 → 11.2→3.4 tok/s | 낮은 ctx / 배경 닫기 / §5 2~3단계 |
| E3 대역폭 경로 저하 대역폭 경로 저하 |
L2 | 스왑은 없지만 초당 토큰이 매우 낮습니다. 금속이 로드되지 않음 | Ollama 0.5.13 세션 전체에 ggml_metal_init 없음 → 4.2 tok/s |
올라마를 업그레이드하세요. 금속 경고를 확인하세요 |
| E4 지연 시간만 발생한 실패 지연 시간만 발생한 실패 |
L1 에지 + L3 전구체 | 로드 OK, 첫 번째 토큰 60초+; 일정한 tok/s 이전에는 사용할 수 없습니다. | num_ctx=65536+ 14B @ 16GB |
낮은 ctx; 24GB 동일 구성 TTFT ~2.8s |
| E5 총체적 피로 총체적 소진 |
L1 + L3 | 단일 경로 OK; 다중 에이전트/mmap 대형 모델 사용 불가 | 에이전트 5명 + 14B; 70B mmap <3톡/초 | 분할 노드; 70B에는 M4 Pro 48GB 이상이 필요합니다. |
4.1 E2 예: 스왑 기반 압력 붕괴(qwen2.5:14b @ 16GB)
time=2026-05-29T11:03:12 level=WARN msg="model requires more memory than available, offloading to CPU"
time=2026-05-29T11:03:44 level=ERROR msg="llama runner process has terminated: 신호: 죽었어 (으음?)"
# causal: L1 full → L3 swap → L2 GPU waits on pages → E2
# run sequence: 11.2 → 8.4 → 3.4 → 2.9 tok/s
Swapins: 8421 (then > 20k)4.2 E3 예: 금속 경로 손실(Ollama 0.5.13, 2026-04-18)
# entire session: NO ggml_metal_init → L2 path = CPU only
eval rate=4.2 token/s
# fix:업그레이드하다0.6.2 → Metal restored, median back to ~294.3 E4 예: num_ctx 65536 + 14B 자동 시간 초과
로드 성공, 첫 번째 토큰 60초 이상 응답 없음—L1은 안정적으로 측정 가능한 tok/s 전에 KV 치수에 도달합니다.. 24GB 동일 구성 TTFT ~2.8초: 로드 가능 ≠ 매일 사용 가능.
4.4 E5 및 기타 경계(요약)
- E1+E5:70B mmap, 토크/초 < 3 - 용량 계층이 부족함
- E1+E5:동시 에이전트 5명 + 14B, 스택형 KV OOM
- E2 전구체:Xcode CI + 14B 동일한 머신, DerivedData는 L1을 사용하여 워크로드 분할
- L2 소음(E 클래스 고장 아님): Metal
버퍼 재할당경고, 단일 실행 -3~5%, §3.3 참조
5. 3단계 collapse 모델
§1 L3 압력에 대한 구체적인 추상화: 동일한 M4 16GB, 라마 3.1 8B Q4. 유선 메모리가 증가함에 따라 tok/s는 선형적으로 떨어지지 않고 3단계로 나뉩니다. 16GB의 14B는 3단계에 더 빠르게 진입합니다. 이는 단순히 "매개변수가 더 많다"는 것이 아니라 "14B가 더 느리다"는 이유를 설명합니다.
5.1 위상 정의(8B Q4, 점진적 부하)
| Phase | 기억 상태 | 대략 유선. | 80억 톡/초 | 14B 톡/초 | 메커니즘(레이어) |
|---|---|---|---|---|---|
| Phase 1 선형 저하 |
NORMAL | 11.8 → 14.1GB | 28.8 → 22.1 | — → 6.2 | L1 헤드룸이 줄어듭니다. L2 대역폭이 여전히 지배적입니다.대략 선형 |
| Phase 2 경합지대 |
경고 → 중요 | 14.1 → 14.8GB | 22.1 → 18.6 | 6.2 → 3.4 | L3 시작: 압축기가 활성화되고 GPU가 회수를 기다립니다.가파른 경사 |
| Phase 3 스왑 축소 |
스왑 활성 | 15.2GB 이상 | 9.1 → 3.2 | 2.9 | L3 전체: Swapins 8421+,비선형 절벽; E2 실패 |
판독값:1단계 - 모델이 더 작거나 탭 수가 더 적은 경우가 많습니다. 2단계—삭제해야 함num_ctx또는 RAM을 추가하세요. 3단계 - 부하가 적거나 RAM이 더 많습니다. 온도 조정은 아무 작업도 수행하지 않습니다.
5.2 측정된 스냅샷(교차 위상)
| 시스템 상태 | 붕괴 단계 | tok/s | TTFT | Swapins |
|---|---|---|---|---|
| 깨끗한 기준선 | — (L2 안정) | 28.8메드(28.1–31.1) | ~1.99s | 0 |
| 따뜻하게 20분 | — (L2 잡음) | 25.1 | 2.4s | 0 |
| 크롬 + Xcode | 1단계 후반 | 20.8 | 2.38s | 0 |
| 16GB + 14B 실행 1–2 | Phase 2 | 11.2 / 8.4 | ~2.8s | 0→1204 |
| 스왑 활성 + 14B | Phase 3 | 3.4 → 2.9 | 5.8s | 8421+ |
| 24GB 클린 + 8B | — (큰 L1 헤드룸, Phase 1 없음) | 51.2메드 | ~1.6s | 0 |
5.3 원시 데이터 점진적 로드(16GB, 유선 + 익명)
1:1을 1단계→3단계로 매핑합니다. 재현할 때 신뢰기억 상태GB 단독이 아닌 단계:
| 유선 + 익명 약. | 기억 상태 | Phase | 80억 톡/초 | 14B 톡/초 |
|---|---|---|---|---|
| 11.8 GB | NORMAL | — | 28.8 | — |
| 13.2 GB | NORMAL | Phase 1 | 26.4 | 10.8 |
| 14.1 GB | WARN | 1단계→2단계 | 22.1 | 6.2 |
| 14.8 GB | 비판적인 | Phase 2 | 18.6 | 3.4 |
| 15.2GB 이상 | 스왑 활성 | Phase 3 | 9.1 | 2.9 |
5.4 스왑이 "비선형 중단점"인 이유
1단계에서는 여전히 디코딩됩니다.mostlyL2 대역폭 경로를 따릅니다. 2단계에 진입하면 macOS의 공격적인 회수 + 압축기로 인해 GPU 버퍼 할당이 대기하게 됩니다. 3단계 각 토큰은 스왑으로 인해 페이지 오류가 발생할 수 있습니다.대기 시간은 µs에서 ms로 변경됩니다.. tok/s ~20 → ~3은 "20% 느림"이 아닙니다. 그것은경로 스위치. §4 E2 Swapins 8421은 3단계 지문입니다.
6. TTFT, 컨텍스트 및 시간/버전 드리프트
6.1 TTFT 및 상담원의 느낌
| 대본 | TTFT 샘플 | Notes |
|---|---|---|
| 모델 레지던트 | 0.41 / 0.58 / 0.52 | 받아들일 수 있는 |
| 풀 후 콜드 스타트 | 1.82 / 2.61 / 1.94 / 2.08 | 시스템 웨이크 지터 |
| 스왑 + 14B | 4.5 / 5.8 / 6.2 | 쓸 수 없는 |
6.2 num_ctx 붕괴(8B Q4)
| num_ctx | 16GB 토크/초 실행 | 24GB 토크/초 실행 |
|---|---|---|
| 2048 | 28.1 / 29.8 / 27.2 / 31.1 | 51.2 / 54.6 / 49.8 / 52.1 |
| 8192 | 24.1 / 26.3 / 22.7 | 47.8 / 50.1 / 48.6 |
| 32768 | 14.6 / 13.8(스왑 엣지) | 38.2 / 36.9 |
6.3 시간 드리프트: 동일한 시스템, 동일한 스크립트, 다른 날짜
| Date | Ollama | 중앙값 톡/초 | 실행 범위 | Notes |
|---|---|---|---|---|
| 2026-05-20 | 0.6.1 | 29.2 | 26.8~31.4 | 이전 할당자 |
| 2026-05-28 | 0.6.2 | 28.8 | 27.2~31.1 | 이 글의 기준 |
| 2026-06-02 | 0.6.2 | 27.9 | 24.3~30.1 | 오후 더위, 특이치 24.3 |
0.6.1 → 0.6.2 중앙값 델타 ~1.4 tok/s,일일 ±12% 변동보다 작음—버전 간 비교에는 고정 날짜와 실내 온도가 필요합니다.
6.4 Ollama 마이너 버전 비교(동일 머신/모델, 2026-05-29)
| Version | 중앙값 톡/초 | Metal |
|---|---|---|
| 0.6.1 | 29.2 | OK |
| 0.6.2 | 28.8 | 좋아요; 가끔 버퍼 realloc 경고 |
| 0.6.3 | 29.6 | 좋아요; realloc 감소 경고 |
7. 통제된 실험(3개의 반직관적인 세트)
7.1 적당한 부하: 가벼운 것과 무거운 것(다양한 목표)
"8B의 24GB가 14B의 16GB보다 더 부드럽게 느껴집니다"not동일한 품질 비교. 동일한 벽시계 500개 토큰:
| Config | Model | 중앙값 톡/초 | ~500 토큰 | 품질 등급 |
|---|---|---|---|---|
| 16GB 클린 | gemma3:4b | 39.8 | ~12.6 s | light |
| 16GB 클린 | 라마3.1:8b | 28.8 | ~17.4 s | general |
| 16GB 로드됨 | qwen2.5:14b | 3.4(스왑 후) | ~147 s | 품질은 좋았으나 실패 |
| 24GB 클린 | qwen2.5:14b | 15.8 | ~31.6 s | 코딩의 최적점 |
조건부 결론:14B 품질이 필요한 경우 24GB는 어려운 수준입니다. 속도만 필요한 경우 16GB + 8B이면 충분합니다.no"더 나은 가치를 위해 16GB에 14B를 강제 적용합니다."
7.2 동일 머신 A/B: 스왑 오프 vs 온(8B; §5 1단계→3)
| 상태 | run1 | run2 | run3 |
|---|---|---|---|
| 교환하다, 청소하다 | 28.1 | 29.8 | 27.2 |
| 인위적인 부하를 임계로 | 18.6 | 9.1 | 3.2 |
7.3 MLX 대 Ollama(동일한 프롬프트/ctx/디코드)
라마 3.1 8B 4비트, 512/256, num_ctx=2048, temp=0.2, 16GB 정리:
| 뼈대 | 시퀀스 실행 토크/초 | median | TTFT 샘플 |
|---|---|---|---|
| 올라마 0.6.2 | 28.1 / 29.8 / 27.2 / 31.1 | 28.8 | 1.82 / 2.61 / 1.94초 |
| mlx-lm 0.22.x | 30.4 / 29.1 / 31.6 / 28.3 | 29.8 | 1.71 / 2.10 / 1.88초 |
MLX 비슷한 실행 지터로 ~3~8% 더 빠릅니다. 에이전트 전달은 여전히 Ollama HTTP를 선호합니다. 심층 분석:관련 글.
8. M4 Mac Mini LLM 메모리 매트릭스(16GB/24GB/32GB 측정)
§1 인과 모델 및 §4~§7 측정(공식 사양 아님)을 통한 엔지니어링 판단.
| 모델(Q4_K_M) | 무게 약. | 16GB | 24GB | 32GB |
|---|---|---|---|---|
| Qwen2.5 / Qwen3 7B | ~4.5 GB | ✅ 추천 | ✅ 추천 | ✅ 추천 |
| 라마 3.1 8B | ~4.9 GB | ✅ 추천 | ✅ 추천 | ✅ 추천 |
| DeepSeek-R1-증류 8B | ~5.5 GB | ✅ 추천 | ✅ 추천 | ✅ 추천 |
| 젬마 3 4B / Phi-4-mini | ~3 GB | ✅ Fast | ✅ Fast | ✅ Fast |
| Qwen2.5-코더 14B | ~9 GB | ⚠️ 경계선 | ✅ 추천 | ✅ 추천 |
| 라마 3.1 13B / 피-4 14B | ~8–9 GB | ⚠️ 경계선 | ✅ 추천 | ✅ 추천 |
| Qwen2.5 32B | ~20 GB | ❌ | ⚠️ 경계선 | ✅ 사용 가능 |
| 라마 3.1 70B | ~40 GB | ❌ | ❌ | ❌ |
70B는 M4 프로 48GB+가 필요합니다. M4 Pro 로컬 LLM 배포 가이드를 참고하세요.
9. 시나리오별 모델 선정
9.1 일상 대화·이메일 요약
16GB: 라마3.1:8b or qwen2.5:7b일반 영어의 경우; 강력한 다국어qwen2.5:7b. 24GB:업그레이드하다qwen2.5:14b더 어려운 지침을 따르고 더 긴 스레드를 위해.
9.2 코딩과 Claude Code 로컬 에이전트
Agent에는 안정적인 HTTP와 긴 컨텍스트가 필요합니다. 올라마 API의 serve 하나로 Claude Code에 연결할 수 있습니다. 16GB는 qwen2.5-코더:7b, 24GB는 qwen2.5-코더:14b. 로컬 AI Agent 설정과 API 비용은 M4 Mac Mini 로컬 AI Agent 실측을 참고하세요.
9.3 추론/수학/생각의 연쇄
DeepSeek-R1 증류는 8B에서 빛을 발합니다.deepseek-r1:8b(16GB) 또는deepseek-r1:14b(24GB). R1은 더 긴 추론 체인을 방출합니다. 동일한 tok/s는 더 긴 벽시계를 의미합니다. 이는 모델 동작이지 Mac 결함이 아닙니다.
9.4 다국어 및 오픈 소스 생태계
라마 3.18B/13B에는 가장 많은 툴링 및 Modelfile 문서가 있습니다. 팀이 이미 Llama 기반 RAG를 실행하고 있는 경우 Llama를 유지하면 마이그레이션 비용이 줄어듭니다.
9.5 초경량 보조자
gemma3:4b클린 실행: 38.2 / 41.0 / 36.7 / 39.6 tok/s(중앙값 39.4, 정수가 아님).
10. 최소한의 Ollama 설정
새로운 Mac Mini M4에서 검증된 명령; Ollama는 수동 GPU 플래그 없이 Metal을 자동으로 사용합니다.
10.1 설치 및 확인
curl -fsSL https://ollama.com/install.sh | sh
ollama --version
ollama run qwen2.5:7b "통합 메모리가 로컬 LLM에 중요한 이유를 세 문장으로 설명해 주세요"첫 run에서 모델을 pull합니다(약 4–5GB). SSD 여유 공간 20GB 이상을 확보하세요. 로그에 ggml_metal_init가 보이면 Metal 백엔드가 로드된 것입니다.
10.2 메모리 계층별로 가져오기
# — 16GB Mac Mini M4 —
ollama pull qwen2.5:7b
ollama pull qwen2.5-코더:7b
ollama pull 라마3.1:8b
ollama pull deepseek-r1:8b
# — 24GB Mac Mini M4 —
ollama pull qwen2.5:14b
ollama pull qwen2.5-코더:14b
ollama pull llama3.1:13b
# — 32GB: optional 32B (slower) —
ollama pull qwen2.5:32b10.3 팀 공유 API
OLLAMA_HOST=0.0.0.0:11434 ollama serve고객을 가리킨다http://<mac-ip>:11434LAN에서. 프로덕션 환경에서는 방화벽이나 Tailscale을 사용하세요. 공용 인터넷에 11434를 노출하지 마세요.
10.4 벤치마크 및 diff 원시 로그 실행
ollama pull 라마3.1:8b
./리소스/benchmark-m4-mac-mini-ollama.sh 라마3.1:8b 2>&1 | tee my-run.log
diff -u 리소스/샘플-벤치마크-run.log my-run.log11. 16GB → 24GB → M4 Pro 결정
| 기본 목표 | 권장 구성 | 이론적 해석 |
|---|---|---|
| 개인체험판, 7B채팅/라이트코딩 | M4 16GB | 최저 비용, 완전한 8B Q4 경험 |
| 클로드 코드 에이전트, 14B 코딩, 소규모 팀 공유 | M4 24GB | 꾸준한 14B + API 헤드룸, 최고의 가치 |
| 32B를 로컬에서 실행해야 하며 긴 ctx 실험을 실행해야 합니다. | M4 32GB 또는 M4 Pro 48GB | 32GB 기본 실행이 가능하지만 느립니다. Pro의 대역폭은 더 높습니다. |
| 70B, 빠른 32B, 다중 모델 동시성 | M4 프로 48GB+ | 대역폭 및 메모리 듀얼 게이트; 프로 기사 참조 |
확실하지 않은 경우:깨끗한 시스템, 스왑 피크 및 §5 3단계 collapse를 기록한 다음 최대 사양을 미리 구매하는 것보다 저렴하게 24GB와 M4 Pro를 결정합니다.
12. 실험적 차이 노트
동일한 구성, 동일한 스크립트:중앙값은 날짜별로 ±12% 다를 수 있습니다.—실패한 실행이 아닌 로컬 LLM 벤치마크의 경우 정상입니다.
| 변하기 쉬운 | 관찰된 범위 | 보고 원칙 |
|---|---|---|
| 날짜/실내 온도 | 중앙값 27.9–29.2(8B 16GB) | 보고 간격 + 원시 실행(단일 지점이 아님) |
| 올라마 0.6.1→0.6.3 | ~±1톡/초 | 일 변동보다 작습니다. 음반 버전 |
| 발열/팬 | 29.8 → 25.1 (−12%) | 로그에 보관하고 제외하지 마세요 |
| GC / 금속 재 할당 | 단일 실행 특이치 31.1 또는 −5% | 중앙값뿐만 아니라 p90을 보고합니다. |
| 크롬 배경 | 20.8톡/초 | 기준선에 없는 별도의 행 |
중앙값이 이 기사와 15% 이상 다른 경우 먼저 정렬하세요. Ollama 버전,num_ctx, 온도, 교환 예/아니요, 열. 원시 파일:샘플-벤치마크-run.log, 원시 VM-stat-dump.txt, ollama-디버그-excerpt.log.
We 의도적으로 유지웜 실행(25.1 tok/s) 및 오후 이상값(24.3) - 예쁜 중앙값만으로는 잘못된 구성으로 인한 노이즈를 구분할 수 없습니다. 이것이 바로 실험실 노트와 마케팅 벤치마크 사이의 경계입니다.
FAQ
M4 Mac Mini 16GB가 70B를 실행할 수 있습니까?
70B Q4의 무게는 16GB 물리적 RAM을 초과하는 ~40GB 이상입니다. "16GB는 70B를 실행합니다" mmap 트릭은 SSD를 RAM으로 사용합니다. 톡/초는 일반적으로 < 3—실용적이지 않습니다.
24GB가 16GB보다 얼마나 빠르나요?
동일 8B, 클린: 16GB 5런 중앙값28.8톡/초, 중앙값 24GB51.2. Chrome을 사용하면 한 번에 16GB가 20.8로 떨어질 수 있습니다.백그라운드 로드는 종종 느낌 면에서 RAM 계층을 능가합니다..
올라마 또는 MLX?
API, Claude Code, 다중 모델 전환 → Ollama. Python 평가, 사용자 정의 샘플링 → MLX. 둘 다 설치할 수 있습니다. 두 개의 대형 모델을 동시에 상주하지 마십시오.
Q4 대 Q8 양자화?
16GB: Q4_K_M을 시작합니다. 8B의 24GB는 품질을 위해 Q8을 사용해 볼 수 있습니다. 14B는 여전히 Q4입니다. 24GB의 Q8 14B는 메모리 한도에 가까워졌습니다.
교환 여부를 어떻게 알 수 있나요?
활동 모니터 → 메모리 → 스왑 성장을 지켜보세요. 또는sysctl vm.swapusage. §5 단계 3(한 자리 숫자)의 Swapins >0 및 tok/s는 E2 압력 붕괴입니다. 즉, 초매개변수 조정이 아닌 더 작은 모델 또는 더 많은 RAM입니다.
24GB가 16GB보다 훨씬 빠른 이유는 무엇입니까?
두 배로 확장되지 않은 대역폭(동일한 M4 다이, 유사 L2) —더 많은 L1 헤드룸, L3이 실행되지 않음: 16GB 클린 8B 중앙값 ~28.8, 24GB ~51.2. §1.4 및 §5.2를 참조하십시오.
베이스 M4 대 M4 Pro?
동일한 8B Q4, 클린: M4 24GB 중앙값 51.2, M4 Pro 48GB 중앙값 75.9(동일 랩 스크립트). Pro는 동시 배치에서 더 많은 승리를 거두었습니다. 단일 사용자 에이전트에는 Pro가 필요하지 않을 수 있습니다.
상담원: tok/s 또는 TTFT?
첫 번째 차례에서는 TTFT(§6.1)에 관심을 둡니다. 긴 답글은 톡/초에 신경쓰세요. 스왑 시 TTFT는 1.82초 → 5.8초가 될 수 있습니다. 프레임워크를 전환하기 전에 메모리를 수정하세요.
팀에 실제 Mac이 없나요?
전용 macOS 호스트에 Ollama를 배포합니다. 멤버들은 LAN에서 이 명령을 쳤습니다. 여기와 동일한 명령이 있습니다. 원격 macOS에서 §5 축소 및 §4 오류를 재현하려면 아래의 "실험실 환경 공개"를 참조하세요.
Summary
M4 Mac Mini 로컬 LLM 제한은 L1 용량 + L2 대역폭 + L3 압력으로 설정됩니다.16GB 컴포트 존 7B–8B(L2 안정 중앙값 ~29 tok/s); 24GB 일반 14B(~16톡/초); 32B 이전에는 32GB; 70B에는 M4 Pro가 필요합니다(E1 용량 소진).
조건부 조언:단일 사용자 에이전트, 7B~14B 범위 - 8B에서 24GB가 16GB에서 14B를 강제하는 것보다 나은 경우가 많습니다(§7.1 공정 로드 표). 다중 동시성 또는 일괄 추론에는 더 많은 노드 또는 Pro가 필요합니다. 하드웨어에서 §1 인과 모델 + §3 원시 로그 + §5 1~3단계를 사용하여 재검증합니다.중앙값만 복사하지 마세요..
참고자료
- 올라마 문서— 설치, API, Metal 백엔드
- Apple Metal 문서— GPU 추론 기본 사항
- 메타라마 3.1— 모델 사양 및 라이센스
- Qwen2.5 릴리스 노트— 7B / 14B 기능 범위
- 애플 MLX 프로젝트— 프레임워크 비교 참조
- 라마.cpp— Ollama 엔진 및 GGUF 양자화
이 글은3주 엔지니어링 로그, 일회성 스냅샷이 아닙니다. 원시 아티팩트:
리소스/샘플-벤치마크-run.log— 벤치마크 출력리소스/원시 VM-stat-dump.txt— vm_stat / top / 기억 상태리소스/ollama-디버그-excerpt.log— Ollama 장황함 + 실패 세션리소스/benchmark-m4-mac-mini-ollama.sh— 재생 스크립트
연구실 환경 공개(인프라 공개)
벤치마크는 계속 실행되었습니다.실제 Mac Mini M4하드웨어: 일부 Macstripe 전용 임대 노드(시끄러운 이웃 가상화 없음), 일부 실험실 벤치 시스템; macOS 15.4, 올라마 0.6.2. Macstripe은 M4 Mac Mini 원격 임대를 제공합니다. 여기서 결론의존하지 마십시오특정 공급업체에서 - 자신의 하드웨어에서 재현할 수 있습니다.
원격 macOS(예: 로컬 Mac이 없는 팀)에서 §5 축소 및 §4 실패 분류를 재현하려면Macstripe 홈—선택적 인프라이지 이 기사 결과의 전제 조건은 아닙니다.
관련 읽기(주제 클러스터)
이 기사에서는 적합한 모델과 실험실 원시 데이터를 다룹니다. 컴패니언은 분할 프레임워크, Pro 계층 및 에이전트 롤아웃을 게시하므로 한 페이지가 늘어나지 않습니다.
- M4 Mac Mini: 7B vs 14B 실측 (결정 Spoke: TL;DR + TTFT)
- MLX vs Ollama: Apple Silicon 추론 프레임워크(기술)
- M4 Pro 로컬 LLM 배포 가이드(70B / 32B 등급)
- M4 Mac Mini 로컬 AI 에이전트 설정 및 API 비용(전개)
- 통합 메모리가 LLM 추론에 미치는 영향(이론)
