2026년 최신: Mac mini M4 클러스터 AI 추론 성능 심층 벤치마크

한 줄 요약: 단일 M4의 tok/s가 이미 충분한데 동시 요청과 야간 배치 처리에서 대기열이 생기기 시작하면, Mac mini를 몇 대 더 사서 클러스터로 묶으면 처리량이 두 배가 될까요? 2/4/8 노드 확장 곡선, 프레임워크 차이, 실제 ROI를 한 표에 정리한 글은 드뭅니다. 아래에서는 테스트 환경, 단일 노드 기준선, 클러스터 확장, 병목 분석, 배포 체크리스트까지 2026년판 재현 가능한 심층 실측을 제공합니다.

테스트 결론 요약

ZavCloud 데이터센터에서 Mac mini M4(24GB) 4대와 Cloud Mac M4 인스턴스 4대로 확장 가능한 테스트베드를 구성하고, 동일한 네트워크·전원 정책 아래 2주간 부하 테스트를 수행했습니다. 핵심 발견은 다음과 같습니다.

• 요청 단위 병렬 처리는 거의 선형 확장: 7B 모델, 노드별 독립 Ollama 인스턴스 + Nginx 라운드로빈, 2/4/8 노드 집계 처리량 확장 효율은 각각 95% / 92% / 86%
• 단일 대형 모델은 「메모리를 합칠 수 없음」: 32B 이상 모델은 Apple Silicon에서 여전히 단일 노드 통합 메모리 한계에 부딪힘. 클러스터는 단일 머신 24GB→64GB 업그레이드 경로를 대체할 수 없음
• MLX는 단일 노드에서 더 빠르고, Ollama는 클러스터 운영에 유리: 동일 노드에서 MLX가 Ollama보다 약 8%–15% 빠르지만, Ollama의 OpenAI 호환 API와 핫 업데이트가 다중 노드 오케스트레이션에 더 적합
• 병목은 연산에서 스케줄링으로 이동: 8 노드에서 로드 밸런싱과 모델 콜드 스타트가 end-to-end 지연의 25%–40%를 차지하며, GPU/NPU 자체가 아님
• ROI 전환점은 동시 배치 처리: RAG 임베딩, 로그 요약 등 멀티테넌트 오프라인 작업에서 4 노드 클러스터의 천 회 추론당 비용이 단일 노드 대비 약 38% 낮음(유휴·대기 시간 분산)

왜 「클러스터」를 측정하는가, 단일 노드만으로는 부족한가?

단일 M4에서 7B는 이미 빠릅니다 — 이전 단일 노드 실측에서 24GB·Swap 없음 조건으로 약 37 tok/s(qwen3:8b, 데스크톱 배경 부하 포함). 하지만 팀이 Ollama를 「개인 터미널 장난감」에서 사설 추론 서비스 계층으로 올리면(참고: Cloud Mac AI Stack L2) 병목은 종종 다음과 같이 바뀝니다.

• 다중 Agent / 다중 PR이 로컬 API를 동시 호출해 요청 대기
• 야간 배치(embedding, 로그 요약)와 주간 대화형 추론이 같은 머신을 경쟁
• SLA 필요: P95 지연 < 2s, 단일 노드로는 버티기 어려움

이때 「Mac mini를 몇 대 더 산다」는 생각은 자연스럽습니다. 그러나 Apple Silicon에는 NVIDIA식 NVLink 텐서 병렬이 없으므로, 클러스터가 얼마나 확장되는지는 단일 노드 수치를 extrapolate하는 것이 아니라 동일 환경·동일 모델·동일 부하로 실측해야 답할 수 있습니다.

테스트 환경 및 클러스터 토폴로지

단일 노드 기준: M4 Mac mini 추론 성능

확장 효율의 분모는 단일 노드 정상 상태입니다. 아래 표는 이번 테스트베드의 단일 노드 기준선(Ollama · Q4_K_M 양자화)입니다.

이 수치는 클러스터 확장의 이론적 상한 참조입니다. 4 노드가 완벽 선형 확장이면 7B 집계 처리량은 4 × 58 ≈ 232 tok/s에 근접해야 합니다.

클러스터 확장성 실측 (2 / 4 / 8 노드)

시나리오 A: 7B 대화형 API (동시 32 연결)

각 노드에 llama3.2:7b-instruct-q4_K_M 사전 로드, 클라이언트는 LB를 통해 독립 prompt 전송, 집계 tok/s와 단일 요청 P95 지연 측정.

확장 효율 = 실제 배수 / 노드 수. 8 노드에서 효율이 86%로 떨어지는 주된 이유는 LB 스케줄링 오버헤드, 간헐적 노드 헬스 체크 제외, 극고동시성에서 진입 대역폭 대기입니다.

시나리오 B: 14B 멀티테넌트 API (동시 16 연결)

시나리오 C: RAG 배치 임베딩 (오프라인 처리량)

각 노드에서 nomic-embed-text 실행, 클라이언트가 10,000건 문서 청크를 일괄 제출, 건/분 측정:

배치 임베딩은 M4 클러스터 ROI가 가장 높은 시나리오 중 하나입니다. 작업을 완벽히 분할할 수 있고, 대화형 TTFT 요구가 없으며, 야간에 풀 가동하면 됩니다.

추론 프레임워크 비교: Ollama vs MLX

프로덕션 권장: Ollama를 온라인 API 계층으로, MLX를 야간 배치 추론으로 — 동일 클러스터의 서로 다른 노드 역할로 공존 가능.

동시 처리 및 배치: 세 가지 실제 워크로드

① 다중 Agent 코딩 어시스턴트 (피크 8–12 QPS)

24/7 AI Coding Agent 아키텍처와 유사: Claude API가 Diff 생성, 로컬 Ollama가 로그 요약·코드 검색 임베딩. 단일 16GB는 피크에서 Swap 심각; 2 노드 24GB 클러스터가 P95를 4.2s에서 2.1s로 낮춤.

② 사설 RAG 서비스 (일 50만 token 임베딩)

4 노드는 야간 인덱스 재구축을 9시간에서 2.6시간으로 압축. 주간 대화형 7B 쿼리는 2 노드 유지, 나머지는 야간 배치 모드(cron 중지 → embed 실행 → 아침 복구).

③ 내부 API 게이트웨이 (다팀 공유)

팀별 독립 API Key + 속도 제한, LB는 least_conn으로 분배. 8 노드는 약 35–40 동시 대화(7B) 지원, 초과 시 대기 또는 429 반환.

클러스터 병목은 어디에 있는가?

1. 모델 콜드 스타트: 노드 재시작 후 첫 요청 TTFT 8–15s(가중치를 통합 메모리에 로드). 완화: 워밍업 스크립트 + 헬스 체크 통과 후 LB 풀 합류
2. 통합 메모리는 노드 간 공유 불가: GPU 클러스터처럼 텐서 병렬 불가; 각 노드는 모델 전체 사본을 로드해야 함
3. 진입 대역폭: 8 노드 집계 400 tok/s 시 공인망 1Gbps가 병목이 될 수 있음(약 1.6 MB/s 텍스트 스트림, 보통 충분; embedding 벡터 반환 포함 시 모니터링 필요)
4. 스케줄링 편향: 요청 길이가 고르지 않으면 round_robin에서 노드 부하 불균형; least_conn 권장
5. 운영 복잡도: N대 macOS 업데이트, Ollama 버전, 모델 동기화 — Infrastructure as Code(Ansible / 커스텀 스크립트) 권장

비용 및 ROI 분석

4 노드 × M4 Mac mini 24GB 예시, 단일 노드 vs 클러스터 3년 TCO(전기·운영 인력 분산 포함):

ROI 전환점: 동시 배치로 단일 노드 유휴 < 40% 또는 대화형 P95가 지속 > 3s이면, 2번째 노드는 Cloud Mac 종량 임대 대비 보통 6–9개월 내 증분 비용 회수. 4 노드 이상은 명확한 멀티테넌트 또는 SLA 요구가 있어야 합니다.

배포 및 운영 요점

최소 가동 클러스터(2 노드) 배포 체크리스트:

# 1. 安装 Ollama 并拉取模型
brew install ollama
ollama pull llama3.2:7b-instruct-q4_K_M
OLLAMA_HOST=0.0.0.0:11434 ollama serve &

# 2. 预热（加入 LB 前必须完成）
curl http://localhost:11434/api/generate -d '{"model":"llama3.2:7b-instruct-q4_K_M","prompt":"warmup","stream":false}'

# 3. 健康检查端点
curl -s http://localhost:11434/api/tags | jq '.models | length'

# /etc/nginx/conf.d/ollama-cluster.conf
upstream ollama_backend {
    least_conn;
    server 10.0.1.11:11434 max_fails=2 fail_timeout=10s;
    server 10.0.1.12:11434 max_fails=2 fail_timeout=10s;
}
server {
    listen 443 ssl;
    location / { proxy_pass http://ollama_backend; proxy_read_timeout 300s; }
}

• 모니터링: 각 노드에서 ollama ps, Memory Pressure, Swap, tok/s(커스텀 exporter) 내보내기
• 롤링 업데이트: 노드별 drain → pull → warmup → join, 전 클러스터 콜드 스타트 방지
• 보안: API 진입에 mTLS 또는 API Key; Ollama 기본 무인증, 공인망 직접 노출 금지
• CI와 시간 분리: Runner 빌드 피크에 LB 풀에서 추론 노드 임시 제외(참고: 메모리 스케줄링 가이드)

선택 의사결정 매트릭스

재현 스크립트

임의 M4 노드에서 단일 노드 기준선을 재현한 뒤, 필요에 따라 LB 백엔드를 확장:

# 并发 32 · 每请求 256 token · 持续 5 分钟
wrk -t4 -c32 -d300s -s ollama_bench.lua http://lb.internal:443/

# 采样聚合 tok/s（解析 wrk 输出 + Ollama metrics）
python3 scripts/cluster_aggregate_tps.py --nodes 4 --duration 300

전체 benchmark 정의와 지표 기준은 M4 Ollama 단일 노드 실측 · 재현 부록. 클러스터 확장 효율은 정상 상태 5분 이상 샘플링해 콜드 스타트 간섭을 제외하세요.