M4 Pro Mac Mini에서의 로컬 LLM 설정

Apple Silicon 기반 로컬 LLM 인프라

48GB 통합 메모리를 탑재한 M4 Pro Mac Mini에서 로컬 LLM 서버를 실행하면, 클라우드 API에 의존하지 않고 일상 업무의 약 80%를 처리할 수 있는 프라이빗하고 비용 예측이 가능한 AI 백엔드를 구축할 수 있습니다. 이 설정은 추론을 위해 oMLX를, 보안이 유지되는 기기 간 네트워킹을 위해 Tailscale을 사용하며, 추론의 깊이와 시스템 성능 사이의 균형을 맞추기 위해 Mixture-of-Experts (MoE) 모델과 Dense 모델을 혼합하여 사용합니다.

하드웨어 및 소프트웨어 스택

이 설정의 핵심은 항상 켜져 있는 서버 역할을 하는 M4 Pro Mac Mini (48GB RAM)입니다. 소프트웨어 스택은 신속한 배포와 기기 간 접근성을 위해 설계되었습니다:

Inference Server: oMLX, HuggingFace 브라우저가 내장된 관리 대시보드와 KV 캐시를 SSD에 저장하는 기능을 제공하여 에이전트 워크플로우의 재계산 시간을 단축합니다.
Networking: Tailscale, 공용 인터넷에 포트를 노출하지 않고 Mac Mini를 iPhone 및 MacBook과 연결하는 프라이빗 메쉬 네트워크(tailnet)를 생성합니다.
Primary Models:
- Qwen3.6-35B-A3B-OptiQ-4bit: 복잡한 추론과 깊이를 위해 사용됩니다. MoE 모델로서 총 35B 파라미터가 있지만 토큰당 활성 파라미터는 3B에 불과합니다.
- Gemma-4-E4B-it-OptiQ-4bit: 일상적인 포맷팅 및 간단한 채팅 작업에 사용되는 경량 모델입니다.
Client Interfaces:
- Hermes: Mac Mini에서 실행되는 에이전트 백엔드로, MacBook의 데스크톱 클라이언트와 iOS의 Telegram을 통해 접속합니다.
- Apollo (iOS): oMLX 엔드포인트를 통해 Claude와 유사한 빠른 일회성 질의를 수행하는 데 사용됩니다.
- Raycast AI: 기타 잡다한 작업을 위해 macOS에 통합되어 있습니다.
- Pi: 전용 코딩 에이전트로 활용됩니다.

로컬 모델을 위한 메모리 관리

효과적인 로컬 LLM 배포는 총 파라미터 수와 활성 파라미터 수의 차이를 이해하는 것에서 시작됩니다. 특히 Mixture-of-Experts (MoE) 아키텍처에서 이 차이가 중요합니다.

Dense 모델 vs. MoE 메모리 점유율

Dense 모델의 경우 모든 토큰에 대해 모든 파라미터가 활성화되므로, 4-bit 양자화된 27B 모델은 가중치만을 위해 약 14GB의 RAM이 필요합니다. 반면, Qwen3.6-35B-A3B와 같은 MoE 모델은 총 35B 파라미터가 있지만 토큰당 활성 파라미터는 3B뿐입니다. 35B 파라미터 전체가 통합 메모리에 상주해야 하지만(4-bit 기준 약 20GB), 추론 중 GPU/Media Memory 점유율은 6B Dense 모델과 유사하게 현저히 낮습니다.

하드웨어 호환성 체크리스트

특정 Apple Silicon 하드웨어에서 모델이 구동 가능한지 판단하려면 다음 계산법을 권장합니다:

Quantized File Size: 4-bit 모델의 크기는 대략 파라미터 수와 동일한 기가바이트 단위입니다 (예: 35B $\approx$ 17-20GB).
OS Overhead: macOS를 위해 6-8GB를 제외합니다.
Context Window: 긴 대화를 지원하기 위한 KV 캐시용으로 8-16GB를 할당합니다.
Buffer: 시스템이 SSD로 스와핑되어 성능이 심각하게 저하되는 것을 방지하기 위해 10-15%의 메모리 버퍼를 유지합니다.

로컬 추론의 전략적 이점

클라우드 API에서 로컬 컴퓨팅으로 전환하면 여러 운영 및 재무적 리스크를 해결할 수 있습니다:

AI 주권 및 프라이버시: 로컬 하드웨어는 제3자 데이터 노출 위험을 제거하고, 정부의 모델 제한이나 API 서비스 약관의 갑작스러운 변경으로부터 보호합니다.
비용 예측 가능성: 로컬 추론은 토큰당 변동되는 과금 방식 대신 고정된 하드웨어 구매 비용과 전기 요금으로 대체됩니다.
성능: 로컬 설정은 네트워크 왕복 시간을 제거하여 일상적인 작업에 더 낮은 지연 시간을 제공합니다. M4 Pro의 미디어 엔진은 대부분의 프롬프트에 대해 거의 즉각적인 응답을 가능하게 합니다.
제한 없는 사용: 로컬 컴퓨팅은 유료 API 티어에서 흔히 발생하는 속도 제한(Throttling)을 제거합니다.

커뮤니티 인사이트 및 성능 벤치마크

M4 Pro는 매우 강력하지만, 커뮤니티 논의에서는 성능과 하드웨어 한계에 관한 몇 가지 미묘한 차이가 강조됩니다.

성능 데이터

oMLX를 사용하여 M1 Max (32GB)에서 유사한 설정을 보고한 사용자들은 다음과 같은 토큰 생성(TG) 및 프롬프트 처리(PP) 속도를 기록했습니다:

Qwen3.6-35B-A3B-OptiQ-4bit: PP 342.6 tok/s, TG 44.4 tok/s.
Qwen3.6-35B-A3B-mxfp4: PP 389.6 tok/s, TG 47.6 tok/s.
Qwen3.8-27B-4bit: PP 66.3 tok/s, TG 11.8 tok/s.

반론 및 한계점

커뮤니티 구성원들은 이 설정을 시도하려는 사람들에게 다음과 같은 몇 가지 중요한 고려 사항을 제기했습니다:

"대형 모델을 로컬에서 실행하는 것은 결국 한 가지 문제로 귀결됩니다: 메모리에 실제로 얼마나 많은 RAM이 필요한가입니다. 하지만 이는 완전히 사실이 아닙니다. 메모리와 메모리 대역폭(Memory Bandwidth) 모두가 중요합니다. 1TB의 메모리가 있더라도 메모리 대역폭이 형편없다면 토큰 생성 속도(tok/s) 또한 느려질 것입니다."

다른 사용자들은 로컬 모델이 업무의 80%를에는 훌륭하지만, Apple Silicon의 Prefill 지연 시간은 전용 H100/B300 클러스터와 비교했을 때 여전히 병목 현상이 될 수 있다고 지적했습니다. 또한, 일부는 로컬 모델의 프론트엔드로 Telegram을 사용하는 것이 프라이버시 측면에서 이점이 있는지 의문(Telegram 봇 계정은 종단간 암호화가 되지 않기 때문)을 제기했습니다.