레이블이 Apple Silicon인 게시물을 표시합니다. 모든 게시물 표시
레이블이 Apple Silicon인 게시물을 표시합니다. 모든 게시물 표시

2026/06/16

MacBook Pro M4 Max + Mac Studio M4 Max => RDMA 클러스터로 로컬 LLM 실행하기

서문

Apple Silicon Mac 두 대를 연결하면 강력한 로컬 LLM 클러스터를 구축할 수 있습니다. MacBook Pro M4 Max 64GB와 Mac Studio M4 Max 64GB를 Thunderbolt 케이블로 연결하고, Apple의 MLX 프레임워크에서 제공하는 JACCL 백엔드(RDMA over Thunderbolt)를 활용하면 두 기기의 GPU 성능을 합쳐 70B급 대형 모델을 로컬에서 실행할 수 있습니다.

이 가이드는 하드웨어 준비부터 SSH 설정, Thunderbolt RDMA 활성화, MLX 분산 추론 환경 구축, 그리고 mlx-lm을 통한 LLM 실행까지 전 과정을 단계별로 설명합니다.


1. 하드웨어 구성

사용 장비

두 기기의 주요 스펙은 다음과 같습니다.

구분 MacBook Pro M4 Max Mac Studio M4 Max
CPU 16코어 (12P+4E) 16코어 (12P+4E)
GPU 40코어 40코어
RAM 64GB 64GB
메모리 대역폭 546GB/s 546GB/s
Thunderbolt Thunderbolt 5 × 3 (최대 120Gb/s) Thunderbolt 5 × 4 (최대 120Gb/s)
이더넷 없음 (Thunderbolt 네트워크 사용) 10Gb Ethernet 내장
Wi-Fi Wi-Fi 6E Wi-Fi 6E

총 합산 메모리: 128GB, 총 GPU 코어: 80코어, 합산 메모리 대역폭: 1,092GB/s

이 사양은 70B급 모델을 4bit 양자화하여 두 기기에 분산 배치하기에 충분한 성능을 제공합니다.

필요한 장비

  • Thunderbolt 5 케이블 1개 (양쪽 USB-C to USB-C, 120Gb/s 지원)
  • 두 Mac 모두 같은 로컬 네트워크에 연결되어 있어야 함 (SSH 설정용)
  • Mac Studio: 10Gb Ethernet 포트가 있으므로 이더넷 케이블로도 연결 가능


2. 사전 준비

macOS 버전 확인

JACCL 백엔드(RDMA over Thunderbolt)를 사용하려면 macOS 26.2 (Sequoia 26.2) 이상이 필요합니다. 현재 macOS 버전을 확인하세요:

sw_vers

macOS 26.2 미만인 경우 Ring 백엔드(Thunderbolt over TCP)를 사용할 수 있습니다. 두 방식 모두 이 가이드에서 다룹니다.

SSH 키 설정 (비밀번호 없는 상호 인증)

두 Mac 간에 비밀번호 없이 SSH로 접속할 수 있어야 합니다. MacBook Pro에서 Mac Studio로, Mac Studio에서 MacBook Pro로 양방향 설정이 필요합니다.

MacBook Pro에서 실행

# SSH 키 생성 (아직 없다면)
ssh-keygen -t ed25519 -C "macbook-pro"

# Mac Studio의 IP 또는 호스트명으로 복사
ssh-copy-id user@mac-studio.local

# 연결 테스트
ssh mac-studio.local "hostname"
exit

Mac Studio에서 실행

# SSH 키 생성 (아직 없다면)
ssh-keygen -t ed25519 -C "mac-studio"

# MacBook Pro의 IP 또는 호스트명으로 복사
ssh-copy-id user@macbook-pro.local

# 연결 테스트
ssh macbook-pro.local "hostname"
exit

⚠️ 양방향 연결이 모두 정상 동작하는지 반드시 확인하세요. 양쪽 기기에서 서로의 호스트명으로 SSH 접속이 비밀번호 없이 되어야 합니다.


3. Thunderbolt RDMA 활성화 (JACCL용)

macOS 26.2 이상에서 RDMA over Thunderbolt를 활성화하려면 Recovery Mode에서 설정해야 합니다. 이 작업은 각 Mac에서 개별적으로 진행합니다.

  • Mac을 Recovery Mode로 부팅하기: 전원을 끈 후, 전원 버튼을 길게 누르고 '로딩 옵션을 표시하는 중...'이 나타날 때까지 유지한 후 놓기
  • 설정에서 현재 사용자의 디스크 암호 인증을 진행 (Apple Silicon은 이 단계 필요)
  • 메뉴 바에서 Utilities → Terminal 클릭
  • 터미널에서 다음 명령어 실행:
  • rdma_ctl enable
  • 정상적으로 실행되면 재부팅
# Recovery Mode 터미널에서 실행
rdma_ctl enable

# 재부팅 후 일반 macOS에서 확인
ibv_devices

성공 시 M4 Max 칩에서 다음과 같은 출력이 표시됩니다:

device         	node GUID
------         	----------------
rdma_en2       	8096a9d9edbaac05
rdma_en3       	8196a9d9edbaac05
rdma_en4       	8296a9d9edbaac05
rdma_en5       	8396a9d9edbaac05

⚠️ ibv_devices가 아무것도 출력하지 않거나 명령을 찾을 수 없다면 RDMA 활성화가 제대로 되지 않았습니다. Recovery Mode에서 다시 시도하세요.


4. MLX 및 mlx-lm 설치

두 Mac 모두에서 동일한 환경으로 설치해야 합니다. Python 가상 환경을 사용하는 것을 권장합니다.

# 두 Mac 모두에서 실행

# Python 가상 환경 생성
python3 -m venv ~/mlx-cluster
source ~/mlx-cluster/bin/activate

# MLX 및 mlx-lm 설치
pip install --upgrade pip
pip install mlx-lm

# 설치 확인
python -c "import mlx.core as mx; print(mx.__version__)"
mlx_lm.chat --help

⚠️ 두 기기의 MLX 버전이 정확히 동일해야 합니다. pip freeze로 버전 차이 없는지 확인하세요.


5. 클러스터 설정

두 가지 백엔드를 사용할 수 있습니다:

  • JACCL (권장): RDMA over Thunderbolt — 초저지연, 최대 성능
  • Ring: TCP over Thunderbolt — macOS 26.2 미만에서도 사용 가능

6. JACCL 백엔드 설정 (권장)

6-1. Thunderbolt 케이블 연결

MacBook Pro와 Mac Studio를 Thunderbolt 5 케이블로 직접 연결합니다. JACCL은 완전 연결(mesh) 토폴로지를 요구하므로, 2대의 경우 서로 1개 케이블로 충분합니다.

6-2. 연결 확인 및 자동 설정

MLX에서 제공하는 mlx.distributed_config 유틸리티로 연결을 확인하고 자동으로 설정할 수 있습니다. MacBook Pro에서 다음 명령어를 실행하세요:

# 연결 시각화 (GraphViz 필요)
mlx.distributed_config --verbose \
    --hosts macbook-pro.local,mac-studio.local \
    --over thunderbolt --dot | dot -Tpng | open -f -a Preview

# 자동 설정 + hostfile 생성
mlx.distributed_config --verbose \
    --hosts macbook-pro.local,mac-studio.local \
    --over thunderbolt --backend jaccl \
    --auto-setup --output cluster-jaccl.json

⚠️ --auto-setup 사용 시 sudo 비밀번호 없이 실행 가능해야 합니다. sudoers 설정이 되어 있지 않으면 명령어를 수동으로 따라야 합니다.

6-3. 수동 설정 (sudo 비밀번호 없는 경우)

--auto-setup 없이 실행하면 각 노드에서 실행해야 할 명령어가 표시됩니다. 각 Mac에서 해당 명령어를 sudo로 실행한 후 생성된 hostfile을 사용합니다.

# 자동 설정 없이 실행 → 명령어 출력
mlx.distributed_config --verbose \
    --hosts macbook-pro.local,mac-studio.local \
    --over thunderbolt --backend jaccl --output cluster-jaccl.json

6-4. 생성된 hostfile 확인

cluster-jaccl.json은 다음과 같은 구조를 가집니다:

[
    {
        "ssh": "macbook-pro.local",
        "ips": ["192.168.1.100"],
        "rdma": [null, "rdma_en2"]
    },
    {
        "ssh": "mac-studio.local",
        "ips": [],
        "rdma": ["rdma_en2", null]
    }
]

rdma 배열은 각 노드가 서로 어떤 RDMA 인터페이스로 연결되는지를 정의합니다. null은 자기 자신을 의미합니다.


7. Ring 백엔드 설정 (대안)

macOS 26.2 미만이거나 RDMA 활성화가 어려운 경우 Ring 백엔드를 사용할 수 있습니다. Ring은 TCP 소켓을 사용하므로 설정이 더 간단합니다.

# Thunderbolt over TCP 자동 설정
mlx.distributed_config --verbose \
    --hosts macbook-pro.local,mac-studio.local \
    --over thunderbolt --backend ring \
    --auto-setup --output cluster-ring.json

# 또는 Ethernet만 사용 (Thunderbolt 케이블 없이)
mlx.distributed_config --verbose \
    --hosts macbook-pro.local,mac-studio.local \
    --over ethernet --backend ring --output cluster-ring.json

Ring 백엔드는 JACCL보다 대역폭이 낮지만, 10Gb Ethernet이나 Thunderbolt over TCP로도 충분한 성능을 낼 수 있습니다.


8. 클러스터 테스트

실제 LLM을 실행하기 전에 클러스터 통신이 정상인지 테스트하세요.

import mlx.core as mx

world = mx.distributed.init()
x = mx.distributed.all_sum(mx.ones(10))
print(f"Rank {world.rank()}: all_sum result = {x}")

JACCL로 테스트

source ~/mlx-cluster/bin/activate
mlx.launch --verbose --backend jaccl \
    --hostfile cluster-jaccl.json \
    --env MLX_METAL_FAST_SYNCH=1 -- \
    python test_cluster.py

Ring으로 테스트

source ~/mlx-cluster/bin/activate
mlx.launch --verbose --backend ring \
    --hostfile cluster-ring.json \
    python test_cluster.py

두 노드 모두에서 Rank 0: all_sum result = [2, 2, 2, ..., 2]Rank 1: all_sum result = [2, 2, 2, ..., 2]가 출력되면 성공입니다.


9. 분산 LLM 추론 실행

9-1. mlx-lm을 통한 추론

mlx-lm은 MLX의 분산 기능을 자동으로 활용합니다. mlx.launch로 실행하면 각 노드의 GPU에 모델이 분산 배치됩니다.

# JACCL 백엔드로 70B 모델 분산 추론
source ~/mlx-cluster/bin/activate

mlx.launch --verbose --backend jaccl \
    --hostfile cluster-jaccl.json \
    --env MLX_METAL_FAST_SYNCH=1 -- \
    python -m mlx_lm chat \
    --model mlx-community/Meta-Llama-3.1-70B-Instruct-4bit

9-2. 권장 모델

128GB 총 메모리(64GB × 2) 환경에서 실행 가능한 모델:

모델 양자화 크기 비고
Llama 3.1 70B Instruct 4bit ~42GB 안정적 실행 가능
Qwen 2.5 72B Instruct 4bit ~43GB 한국어 지원 우수
Mistral Large 2 4bit ~46GB 고성능 추론
Llama 3.3 70B 4bit ~42GB 하이브리드 아키텍처
DeepSeek R1 0528 4bit ~47GB 추론형 모델

9-3. HTTP API 서버 실행

OpenAI 호환 API 서버를 클러스터에서 실행할 수 있습니다:

source ~/mlx-cluster/bin/activate

mlx.launch --verbose --backend jaccl \
    --hostfile cluster-jaccl.json \
    --env MLX_METAL_FAST_SYNCH=1 -- \
    python -m mlx_lm serve \
    --model mlx-community/Meta-Llama-3.1-70B-Instruct-4bit

서버가 시작되면 http://localhost:8080/v1/chat/completions 엔드포인트로 OpenAI 호환 API를 사용할 수 있습니다.

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Llama-3.1-70B-Instruct",
    "messages": [
      {"role": "user", "content": "안녕하세요!介绍一下你自己"}
    ],
    "max_tokens": 512
  }'

10. 성능 최적화 팁

  • MLX_METAL_FAST_SYNCH=1 필수 설정: CPU-GPU 간 동기화 속도를 높여 분산 통신 성능을 크게 개선
  • 모델은 mlx-community에서 4bit 양자화된 버전을 사용: 메모리 효율이 가장 좋음
  • MacBook Pro는 전원에 연결한 상태로 실행: 성능 제한 방지
  • --max-kv-size 4096 또는 더 큰 값을 설정하여 긴 컨텍스트 처리 성능 향상
  • 모델을 로컬에 미리 다운로드: mlx_lm.download --model ~로 사전 다운로드

wired_limit_mb 설정 (대형 모델용)

모델 크기가 시스템 RAM을 초과할 수 있는 경우 macOS의 wired memory 제한을 늘려야 합니다:

# 현재 제한 확인
sysctl iogpu.wired_limit_mb

# 64GB Mac에서 55GB로 설정 (모델 + 캐치 용량 고려)
sudo sysctl iogpu.wired_limit_mb=56320

이 설정은 재부팅 시 초기화되므로 ~/.zshrc에 추가하거나 launchd plist로 영구 설정할 수 있습니다.


11. 문제 해결

SSH 연결 실패

mlx.launch가 SSH 연결에 실패하면 다음을 확인하세요:

  • 양방향 SSH 키 인증이 설정되었는지 확인 (ssh hostname 테스트)
  • .ssh/config에 각 Mac의 호스트명 설정이 올바른지 확인
  • 방화벽 설정에서 SSH 포트(22)가 열려 있는지 확인

JACCL 초기화 실패

  • ibv_devices가 RDMA 장치를 표시하는지 확인
  • Thunderbolt 케이블이 양쪽 포트에 제대로 연결되었는지 확인
  • mlx.distributed_config --hosts ~ --over thunderbolt --dot으로 연결 상태 시각화
  • macOS 26.2 이상인지 확인 (sw_vers)

모델 로드 실패

  • iogpu.wired_limit_mb가 모델 크기보다 충분한지 확인
  • 모델 파일이 두 기기에 모두 동일한 경로에 있는지 확인
  • mlx_lm.download로 모델을 사전 다운로드

Ring 백엔드에서 느린 성능

  • --connections-per-ip 4 이상으로 설정하여 TCP 연결 수 증가
  • 10Gb Ethernet 포트가 있다면 --over ethernet으로 설정
  • JACCL로 전환하는 것이 가장 확실한 해결책

12. 전체 아키텍처

┌─────────────────────────────┐         Thunderbolt 5          ┌─────────────────────────────┐
│    MacBook Pro M4 Max       │         (120Gb/s)              │    Mac Studio M4 Max        │
│    64GB RAM / 40-core GPU   │◄──────────────────────────────►│    64GB RAM / 40-core GPU   │
│                              │         JACCL (RDMA)           │                              │
│  ┌──────────────────────┐   │   ┌─────────────────────────┐  │  ┌──────────────────────┐   │
│  │   mlx.launch (rank 0)│   │   │                         │  │  │   mlx.launch (rank 1)│   │
│  │                      │   │   │   mlx.distributed       │  │  │                      │   │
│  │  mlx_lm.chat         │   │   │   init(backend="jaccl") │  │  │  mlx_lm.chat         │   │
│  │  --model 70B-4bit    │   │   │                         │  │  │  --model 70B-4bit    │   │
│  └──────────┬───────────┘   │   │  all_sum / all_gather  │  │  └──────────┬───────────┘   │
│             │               │   │  all_reduce / broadcast │  │             │              │
│    Metal GPU│               │   └─────────────────────────┘  │    Metal GPU│              │
│   (40 cores)│               │                                 │   (40 cores)│              │
└─────────────┘               └─────────────────────────────────┘  └─────────────┘
                           │
              ┌────────────┴────────────┐
              │   hostfile.json         │
              │   cluster-jaccl.json    │
              └─────────────────────────┘

┌──────────────────────────────────────────────────────────────────┐
│                    클러스터 통신 흐름                              │
│                                                                    │
│  사용자 → MacBook Pro (rank 0)                                     │
│    ↓                                                                │
│  mlx_lm.chat (交互式 REPL)                                         │
│    ↓  tensor parallelism                                           │
│  Layer 0-N → MacBook Pro GPU    Layer N+1-End → Mac Studio GPU   │
│    ↓                          RDMA 통신                          ↓
│  MacBook Pro GPU ◄──────────────────────────────────► Mac Studio GPU
│    ↓                                                                │
│  all_reduce (gradient / attention)                                  │
│    ↓                                                                │
│  생성된 토큰 → 사용자에게 반환                                      │
└──────────────────────────────────────────────────────────────────┘

13. 요약

  • JACCL 백엔드는 RDMA over Thunderbolt를 사용하며, Ring 백엔드 대비 10배 낮은 지연 시간 제공
  • macOS 26.2 이상 필요 (Recovery Mode에서 rdma_ctl enable 필수)
  • mlx.distributed_config로 자동 설정 가능 (--auto-setup 사용 시 sudo 비밀번호 없이 실행 필요)
  • mlx.launch --backend jaccl로 분산 추론 실행, MLX_METAL_FAST_SYNCH=1 필수
  • 두 Mac의 총 128GB 메모리로 70B급 모델을 4bit 양자화하여 분산 실행 가능
  • Ring 백엔드는 macOS 26.2 미만에서도 사용 가능 (TCP over Thunderbolt/Ethernet)

참고 링크

  • MLX 공식 문서: https://ml-explore.github.io/mlx/
  • mlx-lm GitHub: https://github.com/ml-explore/mlx-lm
  • mlx-examples (분산 예제): https://github.com/ml-explore/mlx-examples
  • MLX Community Hugging Face: https://huggingface.co/mlx-community
  • Apple Support - Recovery Mode: https://support.apple.com/en-us/102518

이 가이드에서 설명한 설정은 로컬 환경에서 대규모 LLM을 실행하는 가장 효율적인 방법 중 하나입니다. 클라우드 GPU 대여 비용 없이 Apple Silicon Mac 두 대로 70B급 모델을 실시간 추론할 수 있습니다.

2026/06/05

Gemma 4 12B IT 완전 분석: 기존 모델과 무엇이 달라졌나, M4 Max에서는 얼마나 빠른가

솔직히 말하면, 구글이 Gemma 3을 출시했을 때만 해도 '그래, 이 정도면 준수하지'라는 반응이 많았다. 그런데 Gemma 4 12B가 나오고 나서 상황이 좀 달라졌다. 특히 12B 모델이 코딩 벤치마크에서 이전 세대 27B 모델을 훌쩍 뛰어넘는 수치를 보여주니, 이걸 그냥 지나치기가 어렵다.

이번 글에서는 Gemma 4 12B IT(Instruction-Tuned) 모델이 기존 모델들과 구체적으로 어떻게 다른지, 그리고 Apple M4 Max 같은 로컬 하드웨어에서 실제로 어떤 성능이 나오는지를 정리해봤다.


Gemma 4 12B가 기존과 다른 이유

가장 큰 변화: 인코더 없는 통합 멀티모달 아키텍처

Gemma 4 12B의 공식 명칭은 '12B Unified'다. 여기서 Unified가 핵심이다. 기존 Gemma 3나 다른 멀티모달 모델들은 이미지 처리용 비전 인코더(약 550M 파라미터)와 오디오 처리용 인코더를 LLM 앞단에 붙이는 구조였다. 그런데 12B Unified는 이 별도 인코더를 완전히 제거했다.

대신 이미지 패치와 오디오 파형을 가벼운 선형 레이어(Linear Layer)를 통해 직접 LLM의 임베딩 공간으로 투영한다. 결과적으로 텍스트, 이미지, 오디오가 하나의 디코더 전용 트랜스포머 안에서 처리된다. 이 방식의 이점은 두 가지다. 멀티모달 추론 지연시간이 줄어들고, 파인튜닝 시 전체 모델을 한 번에 학습할 수 있다.

하이브리드 어텐션과 256K 컨텍스트 윈도우

아키텍처 내부를 보면 로컬 슬라이딩 윈도우 어텐션과 글로벌 풀 컨텍스트 어텐션을 교차 배치(Interleave)하는 구조를 쓴다. 12B 모델 기준 슬라이딩 윈도우는 1024 토큰이며, 마지막 레이어는 항상 글로벌 어텐션이다. 덕분에 컨텍스트 윈도우가 256K 토큰까지 늘어났다. 이는 Gemma 3 12B의 128K에서 정확히 두 배다. 전체 레이어 수는 48개, 파라미터는 11.95B다.

Per-Layer Embeddings (PLE) — 레이어별 개별 임베딩

기존 트랜스포머는 토큰마다 입력 시 하나의 임베딩 벡터를 부여하고, 이를 모든 레이어가 공유했다. PLE는 각 디코더 레이어에 별도의 작은 임베딩을 추가해 레이어별로 토큰 특정 정보를 조절할 수 있게 한다. 두 가지 신호를 결합한다: 토큰 ID 기반 조회값과, 메인 임베딩의 학습된 프로젝션. 파라미터 오버헤드 대비 레이어별 전문화 효과가 큰 방식이다.

Shared KV Cache — 메모리 절약

모델 후반부 N개 레이어가 자체적인 K-V 프로젝션을 계산하지 않고, 이전 레이어의 K-V 텐서를 재사용하는 방식이다. 품질 저하를 최소화하면서 긴 컨텍스트에서 메모리와 연산을 아낄 수 있다. 특히 온디바이스 실행 시 실질적인 이득을 준다.

시스템 프롬프트 네이티브 지원 + 함수 호출

Gemma 4는 기존 Gemma 3에서 없던 시스템 역할(system role)을 네이티브로 지원한다. 구조화된 대화와 에이전틱 워크플로우 구성이 훨씬 자연스러워졌다. 함수 호출(Function Calling)도 네이티브로 지원해 Tool Use 기반 에이전트 구성에 적합하다.

사고 모드(Thinking Mode) 내장

enable_thinking=True 옵션 하나로 답변 전 내부 추론 과정을 거치는 체인 오브 소트(Chain-of-Thought) 스타일의 추론이 가능하다. 수학, 코딩, 논리 문제에서 추가 성능 향상을 기대할 수 있다. 멀티턴 대화에서는 이전 턴의 thinking 내용을 히스토리에 포함하지 않아야 한다는 점에 유의해야 한다.

벤치마크: 이전 세대 27B를 압도하는 12B

공식 발표된 벤치마크 수치다(Instruction-Tuned 기준). 비교 기준은 Gemma 3 27B(사고 모드 없음)다.

추론 및 지식

MMLU Pro: Gemma 4 12B 77.2% vs Gemma 3 27B 67.6% — 10%p 이상 차이

AIME 2026 수학 올림피아드(도구 없음): 77.5% vs 20.8% — 세 배 이상

GPQA Diamond(박사급 과학 문제): 78.8% vs 42.4% — 거의 두 배

MMMLU(다국어 지식): 83.4% vs 70.7%

BigBench Extra Hard: 53.0% vs 19.3%

코딩

LiveCodeBench v6: 72.0% vs 29.1%

Codeforces ELO: 1659 vs 110 — 사실상 다른 리그

비전

MMMU Pro(멀티모달 이해): 69.1% vs 49.7%

MATH-Vision: 79.7% vs 46.0%

OmniDocBench 1.5(문서 파싱, 낮을수록 우수): 0.164 vs 0.365

오디오 (12B 전용)

CoVoST 음성 번역: 38.5점, FLEURS 음성 인식 오류율: 0.069(중국어 제외)

한 줄 요약: Gemma 4 12B는 거의 모든 벤치마크에서 기존 Gemma 3 27B를 앞선다. 더 작은 모델이 더 큰 구세대 모델을 이기는 것이다.

Apple M4 Max에서 돌리면 어떨까

하드웨어 스펙과 메모리 사정

M4 Max는 Apple Silicon의 현행 최고 사양이다. 메모리 대역폭 546GB/s, 통합 메모리 최대 128GB(기본 36GB 또는 48GB), Neural Engine 38코어, GPU 40코어다. LLM 로컬 실행에서 토큰 생성 속도를 결정하는 핵심은 메모리 대역폭인데, 이 수치는 현존 소비자 하드웨어 중 최상위권이다.

메모리 요구량

BF16 풀 정밀도(원본): 약 24GB. M4 Max 36GB 모델이라면 여유 있게 로드 가능하다.

4비트 양자화(Q4): MLX Community 공식 4비트 양자화 버전 기준 약 11GB(비전 임베더 포함). 16GB 메모리에서도 실행 가능한 수준이다.

8비트 양자화(Q8): 약 12~13GB. 품질과 속도의 균형점으로 M4 Max에 최적화된 선택지다.

추정 토큰 생성 속도

2026년 6월 현재 Gemma 4 12B M4 Max에 대한 공개 벤치마크 데이터는 제한적이다. 다만 M4 Max에서의 유사 크기 모델 MLX 추론 사례와 이전 Gemma 3 12B M3 Max 성능 데이터를 토대로 추정하면:

Q4_K 양자화 기준 약 25~40 토큰/초를 기대할 수 있다. M4 Max는 M3 Max 대비 메모리 대역폭이 약 30% 높아, 전 세대에서 측정된 수치보다 개선될 가능성이 높다.

BF16 풀 정밀도는 10~15 토큰/초 수준으로 예상된다.

주의: mlx-lm 지원 이슈 (2026년 6월 기준)

gemma4_unified 모델 타입이 mlx-lm에서 공식 지원되지 않는 문제가 보고됐다(GitHub ml-explore/mlx-lm PR #1349, 진행 중). 'ValueError: Model type gemma4_unified not supported' 오류가 발생할 수 있다. 해당 PR이 머지되기 전까지는 직접 패치를 적용하거나 llama.cpp 기반 GGUF 버전을 사용하는 것이 낫다.

반면 llama.cpp는 이미 Gemma 4를 지원하며, GGUF 양자화 모델이 65개 이상 공개되어 있다. LM Studio나 Ollama를 통해 즉시 실행 가능하다.

M4 Max 최적 실행 방법 정리

1. llama.cpp / LM Studio: GGUF Q4_K_M 또는 Q8_0 양자화 버전 사용. 현재 가장 빠른 경로.

2. mlx-lm: PR 머지 후 mlx-community/gemma-4-12B-it-4bit 모델 사용. 현재는 패치 필요.

3. Transformers(HuggingFace): pip install -U transformers 최신 버전에서 AutoModelForMultimodalLM으로 로드 가능. MPS 백엔드 지원.

IT(Instruction-Tuned)란 무엇인가

모델 이름 끝의 '-it'는 Instruction-Tuned를 뜻한다. 프리트레이닝된 베이스 모델(google/gemma-4-12B)을 지시사항 따르기 및 대화 형식으로 추가 학습한 버전이다. 일반 사용자 대화, 코딩 어시스턴트, 에이전트 태스크에는 반드시 IT 버전을 써야 한다. 베이스 모델은 프롬프트 텍스트 완성용이지 지시사항 수행용이 아니다.

라이선스

Apache 2.0 라이선스다. 상업적 사용, 수정, 배포 모두 허용된다. Google DeepMind가 저자로, Hugging Face에서 공식 배포 중이다.

결론

Gemma 4 12B IT는 기존 12B급 오픈소스 모델의 벤치마크 기준점을 완전히 갈아엎었다. 이전 세대 27B 모델을 코딩에서는 완전히 압도하고, 수학에서는 비교가 무의미할 정도다. 여기에 256K 컨텍스트, 오디오 포함 네이티브 멀티모달, 인코더 없는 통합 아키텍처까지 더하면 사실상 새로운 카테고리를 열었다고 봐도 과언이 아니다.

M4 Max 환경에서는 Q4 양자화로 약 25~40 토큰/초, Q8으로 10~20 토큰/초 수준을 기대할 수 있다. mlx-lm의 공식 지원이 완료되면 Apple Silicon에서의 실용적 사용성은 더 올라갈 것이다. 당장 사용하고 싶다면 LM Studio + GGUF 조합이 가장 빠른 경로다.

출처: HuggingFace Model Card (google/gemma-4-12B-it) | HuggingFace Blog 'Welcome Gemma 4' (2026.04.02) | mlx-community/gemma-4-12B-it-4bit | GitHub ml-explore/mlx-lm PR #1349

2026/06/03

oMLX — 맥에서 로컬 LLM을 제대로 쓰기 위한 추론 서버

맥에서 LLM을 로컬로 돌려본 사람이라면 한 번쯤 Ollama를 설치했을 거다. 설치는 쉽고, 모델도 잘 받아지고 — 근데 조금 쓰다 보면 뭔가 아쉽다. 동시에 여러 요청을 보내면 버벅이고, 한 번 세션이 끊기면 컨텍스트를 처음부터 다시 읽어야 하고, 모델 여러 개를 관리하려면 터미널을 뒤적여야 한다. 맥이 이 정도 하드웨어인데, 좀 더 잘 쓸 방법이 없나 싶었다.

oMLX가 그 답에 가장 가까운 도구다. GitHub 스타 15,700개. Apple Silicon 전용 추론 서버인데, 단순히 빠른 것 이상의 것들을 해준다. 직접 설치해서 쓰면서 정리해봤다.


oMLX가 뭔가

oMLX는 Apple의 MLX 프레임워크 위에 올라가는 LLM 추론 서버다. 코어 추론 엔진은 Apple이 공식으로 관리하는 mlx-lm을 쓰고, 그 위에 프로덕션 서빙에 필요한 것들을 다 쌓아올렸다. 멀티 모델 관리, 티어드 KV 캐시, 연속 배칭, macOS 메뉴바 앱까지.

만든 사람의 말을 그대로 인용하면:

"Every LLM server I tried made me choose between convenience and control. I wanted to pin everyday models in memory, auto-swap heavier ones on demand, set context limits - and manage it all from a menu bar."

그래서 직접 만들었다는 거다. 요구사항이 명확하고 아키텍처가 그걸 실제로 구현하고 있다.

왜 MLX 기반이 빠른가 — 유니파이드 메모리 이야기

llama.cpp나 Ollama가 느리다는 게 아니다. 그쪽도 Apple Silicon에서 Metal 백엔드를 쓴다. 근데 MLX는 한 단계 더 간다.

Apple Silicon의 핵심은 CPU와 GPU가 메모리를 공유한다는 거다. MLX는 이걸 적극 활용해서 배열 연산 결과를 CPU→GPU, GPU→CPU로 복사하지 않는다. 제로 카피(zero-copy). LLM 추론은 메모리 대역폭에 병목이 걸리는 작업인데, 불필요한 복사가 없으면 그만큼 유리하다.

실제 커뮤니티 경험으로는 같은 모델, 같은 하드웨어에서 MLX 기반이 llama.cpp/Ollama 대비 생성 속도(TG)가 10~30% 빠른 경우가 많다고 한다. 컨텍스트 처리(PP)도 대용량에서 더 유리하다.

벤치마크 수치들

oMLX 공식 사이트에 커뮤니티 벤치마크 25,000개 이상이 모여 있다. 실측치들을 보면:

M3 Ultra 512GB · Qwen3.5-122B-A10B 4bit · 32k 컨텍스트

→ 프롬프트 처리 765 tok/s, 생성 42.4 tok/s

M2 Max 64GB · Qwen3.6-35B-A3B 4bit · 16k 컨텍스트

→ 프롬프트 처리 728 tok/s, 생성 66.8 tok/s

M4 Max 64GB · Qwopus3.6-27B 8bit · 4k 컨텍스트

→ 프롬프트 처리 241.8 tok/s, 생성 16.4 tok/s

연속 배칭(Continuous Batching) 효과도 인상적이다. 동시 요청 수에 따라 처리량이 선형 이상으로 오른다:

동시 1개: 56.6 tok/s → 동시 2개: 92.1 tok/s → 동시 4개: 135.1 tok/s → 동시 8개: 190.2 tok/s (3.36배)

에이전트 루프나 여러 도구가 동시에 LLM을 호출하는 상황에서 이게 의미 있는 차이다.

설치 방법

요구 사항: macOS 15 (Sequoia) 이상, Apple Silicon (M1 이상), Python 3.10+

방법 1 — macOS 앱 (GUI 선호하는 경우)

GitHub Releases 페이지에서 .dmg 파일을 받아서 Applications에 드래그하면 끝. 단, 이 방법은 터미널에서 쓰는 omlx CLI 명령이 설치되지 않는다.

방법 2 — Homebrew (CLI + 서비스 관리)

brew tap jundot/omlx https://github.com/jundot/omlx

brew install omlx

업그레이드:

brew update && brew upgrade omlx

백그라운드 서비스로 등록 (크래시 시 자동 재시작):

brew services start omlx

방법 3 — 소스 직접 설치

git clone https://github.com/jundot/omlx.git && cd omlx

pip install -e ".[all]"

MCP(Model Context Protocol) 지원이 필요하다면:

/opt/homebrew/opt/omlx/libexec/bin/pip install mcp

기본 사용법

서버 시작

omlx serve --model-dir ~/models

서버가 뜨면 http://localhost:8000/v1 에 OpenAI 호환 API가 열린다. 어드민 패널은 http://localhost:8000/admin.

모델 디렉토리 구조

~/models/ 아래에 MLX 포맷 모델 폴더를 그냥 넣으면 된다. HuggingFace에서 mlx-community 그룹 모델을 받거나, mlx-lm 툴로 직접 변환/양자화할 수 있다.

~/models/

├── Qwen3-27B-4bit/

├── Qwen3.6-35B-A3B-4bit/

└── bge-m3/

주요 옵션들

# SSD KV 캐시 활성화 (서버 재시작 후에도 캐시 유지)

omlx serve --model-dir ~/models --paged-ssd-cache-dir ~/.omlx/cache

# 메모리 한도 설정

omlx serve --model-dir ~/models --memory-guard-gb 48

# 동시 요청 수 늘리기

omlx serve --model-dir ~/models --max-concurrent-requests 16

# MCP 연동

omlx serve --model-dir ~/models --mcp-config mcp.json

티어드 KV 캐시 — 실제로 왜 중요한가

oMLX에서 가장 특이한 부분이 이거다. KV 캐시를 두 계층으로 나눈다.

핫 캐시 (RAM) — 자주 쓰이는 블록은 메모리에 상주한다.

콜드 캐시 (SSD) — 메모리가 부족해지면 safetensors 형식으로 SSD에 오프로드된다. 다음 요청에서 같은 프리픽스가 오면 복구해서 쓴다.

그리고 이 캐시가 서버 재시작 후에도 살아있다. Ollama는 서버를 껐다 켜면 기존 컨텍스트를 처음부터 다시 읽어야 하는데, oMLX는 이전 세션의 KV 블록이 SSD에 있으면 그냥 가져다 쓴다.

Claude Code 같은 코딩 에이전트로 큰 코드베이스 작업을 할 때 첫 번째 턴(TTFT, time-to-first-token)이 30~90초 걸리던 게 5초 이하로 줄어든다. 이건 실제로 써봐야 체감이 된다.

어떤 모델을 쓸 수 있나

mlx-lm이 지원하는 텍스트 LLM은 다 된다. Llama, Qwen, Mistral, Gemma, DeepSeek, GLM, Phi 계열이 포함된다.

VLM — Qwen3.5 시리즈, GLM-4V, Pixtral, mlx-vlm 지원 모델

OCR 모델 — DeepSeek-OCR, DOTS-OCR, GLM-OCR

임베딩 — BERT, BGE-M3, ModernBERT

리랭커 — ModernBERT, XLM-RoBERTa

툴 콜링은 주요 포맷을 전부 파싱한다. JSON, Qwen XML, Gemma, GLM, MiniMax, Mistral, Kimi K2, Longcat 포맷 모두 지원.

내 맥에서 어떤 모델 크기를 돌릴 수 있나

8GB (M1/M2 Base): 7B 4비트 모델. 느리지만 동작은 한다.

16GB: 7B 8비트 or 13B 4비트. 가벼운 작업에 무난.

32GB: 27B 4비트, 혹은 35B MoE 4비트 (Qwen3.6-35B-A3B 같은 MoE는 스파스 활성화라 메모리를 덜 먹는다). 코딩 작업에 실용적인 구간.

64GB: 70B 4비트, 35B 8비트. M3 Max나 M4 Max 영역. 대부분의 작업에서 GPT-4급 체감.

96GB+: M2/M3/M4 Ultra. 70B 8비트, 122B MoE 4비트. 가성비 좋은 로컬 추론의 최상단.

Claude Code, Codex 등 AI 에이전트와 연동

oMLX는 OpenAI 호환 API(/v1/chat/completions)와 Anthropic API(/v1/messages)를 둘 다 지원한다. Claude Code, OpenClaw, Cursor, Codex, Hermes Agent 등 대부분의 AI 코딩 도구를 그냥 endpoint만 바꿔서 쓸 수 있다.

에이전트 세션에서 컨텍스트 스케일링도 지원해서 Claude Code의 자동 컴팩트가 올바르게 트리거되도록 토큰 카운트를 조정해준다. 긴 prefill 동안 SSE keep-alive로 읽기 타임아웃도 막는다.

MCP 서버로도 사용 가능하다. omlx serve에 --mcp-config로 설정 파일을 넘기면 된다.

써볼 만한가

맥에서 LLM 쓰는 방법이 Ollama/LM Studio만 있는 게 아니다라는 걸 보여주는 프로젝트다. 단순히 빠르기만 한 게 아니라, 프로덕션 서빙을 고려한 설계 — 배칭, 티어드 캐시, 멀티모델 관리, 에이전트 최적화 — 가 다 들어가 있다.

현재 버전 v0.4.0, 커밋 1,400개 이상, 최근 커밋이 몇 시간 전. 오픈 이슈 372개는 많이 쓰인다는 신호다. Apache 2.0 라이선스.

M2 Max 이상 맥을 쓰고 있고, 로컬 LLM을 실제 워크플로우에 붙이고 싶다면 oMLX가 현재 가장 완성도 높은 선택이다. Homebrew 한 줄로 설치되고, 어드민 패널에서 모델 다운로드부터 관리까지 다 된다.

GitHub (⭐15.7k) | 벤치마크 대시보드 | mlx-lm (공식 Apple 추론 라이브러리) | omlx.ai

MacBook M4 Max vs Mac Studio M4 Max — 로컬 LLM 속도, 진짜 차이 있을까?

동일 칩, 동일 메모리, 동일 모델 — 근데 왜 속도가 다를까?

솔직히 처음엔 별 차이 없겠지 싶었다. M4 Max에 64GB RAM이면 두 기기 모두 스펙지에선 완전히 동일하다. 근데 실제로 LLM을 돌려보니 얘기가 달랐다.

테스트 환경

칩: Apple M4 Max (동일)

통합 메모리: 64 GB (동일)

SSD: 1 TB (동일)

런타임: LM Studio

모델: Qwen3 27B dense (quantized)

태스크: 단일 페이지 Kanban 보드 HTML 생성

결과: Mac Studio가 35.7% 빠르다

MacBook Pro M4 Max: 16.74 tok/s

Mac Studio M4 Max: 22.72 tok/s

차이: +5.98 tok/s, +35.7%

숫자만 보면 "같은 칩인데?" 싶지만, 체감상 35%는 결코 작은 차이가 아니다. 긴 코드 생성이나 장문 요약 태스크에선 누적 차이가 꽤 크게 느껴진다.

왜 차이가 날까?

이유는 폼 팩터 차이에 있다.

MacBook은 얇고 가벼운 노트북 바디에 M4 Max를 집어넣은 구조라 열 설계(thermal design)에 제약이 있다. TDP 한계 때문에 지속적인 고부하 작업에서는 클럭을 조금씩 낮춰 온도를 관리하게 된다.

반면 Mac Studio는 데스크탑 폼 팩터답게 방열 공간이 넉넉하다. 결과적으로 서스테인드 클럭(sustained clock)이 더 높게 유지되고, LLM 추론처럼 Neural Engine + GPU를 지속적으로 강하게 쓰는 작업에서 이 차이가 그대로 성능 격차로 나타난다.

그래서 뭘 사야 할까?

이동이 필요하다 → MacBook Pro

16.74 tok/s도 로컬 LLM 용도로는 충분히 쾌적한 속도다. Qwen3 27B를 이 속도로 돌릴 수 있다는 것 자체가 몇 년 전엔 상상도 못 할 얘기였다.

책상에서 AI 개발 or 에이전트 서버로 쓸 거다 → Mac Studio

35% 속도 차이는 반복 추론, 배치 처리, 에이전트 루프에서 체감이 확실하다. 같은 돈으로 이 속도 차이를 얻는다면 Mac Studio가 명확히 유리하다.

마치며

같은 칩이어도 패키징 방식이 성능을 결정한다는 걸 다시 확인했다. 로컬 LLM을 진지하게 쓸 생각이라면 폼 팩터 차이를 절대 무시하지 말자.

Runtime: LM Studio · Model: Qwen3-27B-dense · Task: kanban board generation

SK하이닉스 ADR 상장 이후 한국 증시 급락의 원인 분석

분류: 증시분석 SK하이닉스 ADR 상장 이후 한국 증시 급락의 원인 분석 지난 7월 10일, SK하이닉스가 미국 나스닥에 미국주식예탁증서(ADR)를 상장했다. 공모가 149달러로 상장한 하이닉스 ADR은 첫 거래일인 13일 기준 약 168달...