2026/08/27

Mac Studio M3 Ultra vs M5 Ultra — 어떤 기기를 사야 하는가

분류: 로컬AI



2025년 3월, Apple은 Mac Studio에 M3 Ultra 칩을 탑재해 출시했습니다. 그리고 2026년, M5 Ultra가 등장하며 로컬 AI 커뮤니티의 관심이 다시 한 번 모이고 있어요. 두 칩은 모두 "데스크탑에서 프론티어급 LLM을 로컬로 실행한다"는 목표를 공유하지만, 아키텍처와 성능은 크게 다릅니다.

스펙과 벤치마크를 기반으로 어떤 기기가 당신의 사용 사례에 맞는지 기술적으로 분석합니다.


스펙 비교 — 핵심은 메모리 대제폭

항목Mac Studio M3 UltraMac Studio M5 Ultra
CPU32코어 (24 Performance + 8 Efficiency)약 36코어 (12 Super + 24 Performance)
GPU80코어80코어 + Neural Accelerators
유니파이드 메모리최대 512GB최대 768GB (테스트)
메모리 대제폭819 GB/s약 1.2 TB/s (예상)
Neural Engine32코어GPU 코어당 Neural Accelerator
공정3nm (N3E)3nm 3세대
ThunderboltThunderbolt 5Thunderbolt 5
Geekbench 6 멀티약 28,169약 42,864 (예상)

CPU 성능 — 세대차의 실체

M3 Ultra는 이미 32코어 CPU와 80코어 GPU로 데스크톱 최상위권을 달렸습니다. Geekbench 6 멀티스코어 약 28,169점은 M2 Ultra(21,241) 대비 약 33% 향상된 수치예요.

M5 Ultra는 아키텍처를 재설계했어요. 기존 "Performance 코어"가 "Super 코어"로 개명되고, 그 아래 새로운 "Performance 코어" 계층이 추가된 3단계 구조입니다. 이로 인해 CPU 코어 수가 약 36코어로 증가했고, 멀티코어 성능은 약 42,864로 M3 Ultra 대비 약 52% 향상될 것으로 예상됩니다.

GPU와 AI 연산 — Neural Accelerator의 등장

두 칩 모두 80코어 GPU를 제공하지만, M5 Ultra의 가장 큰 변화는 GPU 코어당 독립된 Neural Accelerator가 추가되었다는 점이에요. M5 이전 세대는 별도의 Neural Accelerator가 없어 FP16 연산이 GPU ALU에만 의존했지만, M5는 독립된 가속기로 인해 FP16 총산량이 크게 향상됩니다.

로컬 AI/LLM 추론에 가장 중요한 것은 메모리 대제폭입니다. 동일 메모리 용량이라도 대제폭이 높을수록 초당 생성 토큰(tok/s)이 증가하기 때문이에요. M3 Ultra의 819 GB/s도 충분하지만, M5 Ultra가 약 1.2 TB/s에 접근한다면 동일 405B 모델 추론 속도가 30% 이상 향상될 가능성이 있습니다.

메모리 용량 — M5 Ultra의 한계

M3 Ultra는 최대 512GB까지 확장 가능한 것이 가장 큰 강점이에요. 512GB면 405B 모델(Q4 양자화)을 여유 있게 로드할 수 있어요. 반면 M5 Ultra는 현재 768GB까지 지원될 예정이지만, 실제 가격과 Supply 상황이 확인되지 않은 상태예요.

결론 — 누구에게 어떤 기기가 맞을까

사용 목적추천 기기
초대형 모델(405B+) 로컬 추론M3 Ultra (512GB)
최대 CPU/GPU 성능, 차세대 AIM5 Ultra (예상)
가성비, 현재 즉시 구매M3 Ultra

M5 Ultra가 출시된다면 CPU/GPU 성능과 Neural Accelerator로 인한 AI 연산 향상은 확실히 매력적이에요. 다만 메모리 대제폭과 최종 가격이 확정되기 전까지는, 지금 즉시 512GB 대용량이 필요하다면 M3 Ultra가 여전히 현명한 선택입니다.

로컬 AI를 본격적으로 다루는 사용자라면, 두 기기의 출시 일정과 가격을 주시하면서 자신의 모델 크기와 메모리 요구사항에 맞춰 결정하는 것이 좋겠어요.

Mac Studio M5 Ultra vs NVIDIA DGX Spark — 로컬 AI 기준으로 무엇을 사야 하는가

분류: 로컬AI

2026년 8월 25일, Apple은 Mac Studio에 M5 Max와 M5 Ultra 칩을 탑재한 신제품을 발표했다. 이미 2025년 10월 출시되어 로컬 AI 커뮤니티에서 화제를 모았던 NVIDIA DGX Spark와 직접 비교할 시점이 되었다.

두 기기 모두 "데스크탑에서 프론티어급 LLM을 로컬로 실행한다"는 목표를 공유하지만, 아키텍처와 접근 방식이 완전히 다르다. 스펙과 벤치마크를 기반으로 어떤 기기가 당신의 사용 사례에 맞는지 기술적으로 분석한다.




스펙 비교 — 핵심은 메모리 대역폭

항목Mac Studio M5 UltraNVIDIA DGX Spark
CPU36코어 (12 Super + 24 Performance)20코어 ARM (10 Cortex-X925 + 10 A725)
GPU최대 80코어 + Neural AcceleratorsBlackwell 6,144 CUDA 코어 + 5세대 Tensor Core
유니파이드 메모리최대 512GB128GB LPDDR5x
메모리 대역폭1.2 TB/s273 GB/s
TDP~70W240W (GPU 140W)
OSmacOS 27Ubuntu 24.04 (DGX OS)
AI 프레임워크MLX, Core ML, Ollama (Metal)CUDA, TensorRT-LLM, NeMo
ストレ지최대 8TB SSD4TB NVMe
가장 낮은 구성 가격$5,499 (96GB / 1TB)$4,699 (128GB / 4TB)
최고 사양 가격~$20,000+ (512GB / 8TB)$4,699 (단일 SKU)

가장 결정적인 차이는 메모리 용량과 대역폭이다. M5 Ultra 최고사양은 512GB 메모리에 1.2TB/s 대역폭을 제공하며, DGX Spark의 약 4배의 메모리 용량과 4.4배의 대역폭을 가진다.


LLM 추론 성능 — 실제 벤치마크

Llama 3.3 70B (Q4 양자화)

메트릭M5 Ultra (MLX)DGX Spark
Prefill (tok/s)1,510 (단일 디바이스)약 200-300
Decode (tok/s)21.1 (단일) / 27.3 (TP=2)약 3-5
p99 Latency26.6초약 60초+
메모리 사용52GB약 45GB

M5 Ultra는 MLX의 Tensor Parallelism (TP=2)을 활용할 때 70B 모델에서 약 30-40% 더 빠른 디코드 속도를 제공한다. DGX Spark는 273 GB/s의 대역폭 한계로 인해 70B 클래스 모델에서 토큰 생성 속도가 매우 낮다.

Mistral Large 2 (120B, Q4 양자화)

메트릭M5 Ultra 512GB (TP=2)DGX Spark
Prefill (tok/s)980실행 불가 (메모리 부족)
Decode (tok/s)12.4OOM — 128GB로는 로드 불가
메모리 사용88GB

120B 클래스 모델은 M5 Ultra 512GB에서만 실행 가능하다. DGX Spark의 128GB 메모리는 70B 모델까지만 수용 가능하며, 120B MoE는 메모리 부족으로 실행 불가이다. (NVIDIA의 "200B까지 지원" 주장은 FP4 sparse 양자화 기준이며, 실제 사용 가능한 품질의 모델은 70B 수준이다.)


멀티 사용자 서빙 — 50인 팀 기준

M5 Ultra의 강력한 점은 단일 기기에서 동시에 여러 사용자를 서빙할 수 있다는 것이다. MLX의 continuous batching + paged KV cache를 활용하면:

  • 70B 모델, 동시 4명: 사용자당 13.2 tok/s — 코딩 어시스턴트 수준으로 충분
  • 70B 모델, 동시 8명: 사용자당 8.4 tok/s — 여전히 사용 가능
  • 27B 모델, 동시 16명: 사용자당 14.2 tok/s — 배치 처리에 적합

DGX Spark는 273 GB/s 대역폭 한계로 인해 동시 다수 사용자 서빙이 실질적으로 불가능하다. 단일 요청에서도 70B 모델의 토큰 생성이 3-5 tok/s 수준이며, 동시 요청 시 급격히 저하된다.


파인튜닝

DGX Spark의 강점은 CUDA 생태계다. LoRA/QLoRA 파인튜닝에서 DGX Spark는 Unsloth 프레임워크를 통해 Llama 8B 기준 53,658 tok/s의 피크 속도를 달성한다. M5 Ultra는 MLX 기반 파인튜닝이 제한적이며, Full fine-tuning은 작은 모델에 한정된다.

하지만 DGX Spark의 128GB 메모리 한계로 인해 70B 모델 QLoRA는 5,079 tok/s에 그치며, M5 Ultra의 MLX 파인튜닝이 70B급에서 더 나은 경험을 제공할 수 있다.


가격 대비 성능

M5 Ultra 96GB ($5,499): 70B Q4 모델 실행 가능. 메모리 대역폭 1.2TB/s로 DGX Spark 대비 4배 빠른 추론 속도. MLX 생태계가 빠르게 성장 중.

M5 Ultra 192GB (~$7,499): 70B 모델 + 충분한 KV 캐시 여력. 50인 팀 코딩 어시스턴트용 단일 서버로 적합.

M5 Ultra 512GB (~$20,000+): 120B 모델 실행 가능. DGX Spark로 불가능한 영역. 하지만 405B급 모델은 여전히 클라우드 GPU 클러스터가 필요.

DGX Spark ($4,699): CUDA 생태계 + TensorRT-LLM 최적화. 70B 이하 모델 파인튜닝이 주 용도. 단일 사용자, 연구/개발 환경에 적합.


결론 — 무엇을 사야 하는가

M5 Ultra를 선택해야 할 경우:

  • 70B 이상 모델을 추론하고, 응답 속도가 중요할 때
  • 120B급 모델을 로컬에서 실행해야 할 때 (512GB 구성 필요)
  • 동시 다수 사용자를 서빙하는 내부 AI 서버로 활용 시
  • macOS 생태계 + MLX 프레임워크를 선호할 때
  • 프로 워크플로우 (영상 편집, 3D 렌더링)와 AI를 동시에 필요로 할 때

DGX Spark를 선택해야 할 경우:

  • CUDA/TensorRT-LLM 생태계 기반 파인튜닝이 주 목적일 때
  • 70B 이하 모델의 LoRA/QLoRA 파인튜닝 성능이 최우선일 때
  • Linux 기반 환경과 NVIDIA AI Enterprise 스택을 필요로 할 때
  • $4,699 단일 가격에 128GB 메모리 + 4TB SSD가 매력적일 때
  • 단일 사용자 연구/개발 환경이며 모델 크기가 70B 이하로 제한될 때

최종 판단: 로컬 AI 추론 성능과 확장성 측면에서 M5 Ultra가 압도적이다. 특히 1.2TB/s 메모리 대역폭은 DGX Spark의 약 4.4배로, 같은 모델 크기의 추론 속도에 결정적인 차이를 만든다. DGX Spark의 강점은 CUDA 생태계와 파인튜닝 최적화이며, 이 분야에 특화된 사용자에게만 추천된다.

M5 Ultra Mac Studio는 2026년 9월 22일 배송 시작. 512GB 구성은 10월 말 출시 예정.


출처: Apple Newsroom (2026.08.25), Contra Collective MLX benchmark, NVIDIA DGX Spark review (GPUSmith, IntuitionLabs), Compute Market comparison

2026/08/15

Qwen3.8-27B — 17GB로 돌리는 멀티모달 AI Agent (스펙, 벤치마크, 로컬 실행 가이드)

Qwen3.8-27B — 2026년 8월 14일, 데스크톱에서 구동되는 멀티모달 AI 모델

분류: AI/LLM



2026년 8월 14일 밤12시 신상 Qwen3.8-27B 모델이 출시 되었다.
출시 하자마다 다운로드 걸우두고 취침~
oMLX 에서 128k 벤치마크 돌리고 있는데 프리필 남은 시간이 10분...


시작은 10분남짓 이었으나 현재 진행중 대략 20분 걸릴듯함

프리필 진행중 100k 지점에서 메모리 부족으로 중지됨 


Qwen3.6 27B vs Qwen3.8 27B

oMLX - LLM inference, optimized for your Mac
https://github.com/jundot/omlx
Benchmark Model: Qwen3.6-27B-MLX-4bit
Engine: Auto
Context: Code (Python)
================================================================================


Single Request Results
--------------------------------------------------------------------------------
Test                                TTFT(ms)    TPOT(ms)        pp TPS        tg TPS      E2E(s)    Throughput    Peak Mem
pp1024/tg128                          4057.4       35.16   252.4 tok/s    28.7 tok/s       8.541   134.9 tok/s    15.85 GB
pp4096/tg128                         18389.1       39.41   222.7 tok/s    25.6 tok/s      23.426   180.3 tok/s    17.01 GB

Continuous Batching
pp1024 / tg128
--------------------------------------------------------------------------------
Batch           tg TPS   Speedup        pp TPS    pp TPS/req    TTFT(ms)      E2E(s)
1x          28.7 tok/s     1.00x   252.4 tok/s   252.4 tok/s      4057.4       8.541
2x          43.9 tok/s     1.53x   204.3 tok/s   102.2 tok/s     10024.1      15.861
4x          61.5 tok/s     2.14x   204.3 tok/s    51.1 tok/s     19879.3      28.376



oMLX - LLM inference, optimized for your Mac
https://github.com/jundot/omlx
Benchmark Model: Qwen3.8-27B-nvfp4
Engine: Auto
Context: Code (Python)
================================================================================


Single Request Results
--------------------------------------------------------------------------------
Test                                TTFT(ms)    TPOT(ms)        pp TPS        tg TPS      E2E(s)    Throughput    Peak Mem
pp1024/tg128                          4024.5       22.92   254.4 tok/s    44.0 tok/s       6.942   165.9 tok/s    16.94 GB
pp4096/tg128                         18836.7       27.85   217.4 tok/s    36.2 tok/s      22.407   188.5 tok/s    18.09 GB

Continuous Batching
pp1024 / tg128
--------------------------------------------------------------------------------
Batch           tg TPS   Speedup        pp TPS    pp TPS/req    TTFT(ms)      E2E(s)
1x          44.0 tok/s     1.00x   254.4 tok/s   254.4 tok/s      4024.5       6.942
2x          31.3 tok/s     0.71x   205.7 tok/s   102.8 tok/s      9956.2      18.126
4x          51.9 tok/s     1.18x   210.6 tok/s    52.6 tok/s     19304.2      29.306

1. 개요

Qwen3.8-27B는 Alibaba(알리바바)의 Qwen 팀이 2026년 8월 14일에 공개한 27B(270억) 파라미터의 오픈웨이트 다중모달(multimodal) 모델이다. Qwen3.5 아키텍처 기반으로 Qwen 오픈모델 계열에서 가장 강력한 세대인 Qwen3.8의 컴팩트 모델이다.

핵심 특징은 다음과 같다:

  • Dense 모델: MoE가 아닌 순수 Dense 구조 (27B 파라미터, 64 레이어)
  • 멀티모달: 이미지 + 영상(최대 시간 단위) 이해 지원 — STEM 도표, 문서, 시간급 영상
  • 262K 네이티브 컨텍스트: YaRN 스케일링 시 최대 1,000,000 토큰까지 확장 가능
  • Apache 2.0 라이선스: 상업적 사용 포함 완전 오픈
  • 하이브리드 어텐션: Gated DeltaNet(선형 어텐션) + Gated Attention(전통적 트랜스포머 어텐션) 혼합
  • MTP(Multi-Token Prediction): 체크포인트 내장, 추론 속도 향상
  • Thinking Mode 기본 활성화: reasoning_effort로 추론 깊이 조절 (xhigh / medium / low)

2. 아키텍처 상세

Qwen3.8-27B는 Qwen3.5의 하이브리드 어텐션 백본을 계승한다. 64개 레이어는 16 x (3x(Gated DeltaNet → FFN) → 1x(Gated Attention → FFN)) 구성으로, 매 4개 레이어 중 3개가 효율적인 선형 어텐션(DeltaNet), 1장이 고품질 Gated Attention을 담당한다.

항목
파라미터 수27B (HF에서 28B로 표기)
Hidden Dimension5,120
레이어 수64
Token Embedding / LM Output248,320 (Padded)
Gated DeltaNetV: 48 heads, QK: 16 heads, head dim 128
Gated AttentionQ: 24 heads, KV: 4 heads, head dim 256, RoPE dim 64
FFN Intermediate Dim17,408
MTPMulti-step training 완료, 체크포인트 내장
네이티브 컨텍스트262,144 tokens
최대 확장 컨텍스트 (YaRN)1,000,000 tokens
텐서 형식 (공개)BF16
라이선스Apache 2.0

이 하이브리드 설계의 핵심 장점은 KV 캐치 효율이다. DeltaNet 레이어는 컨텍스트가 길어질수록 KV 캐치가 거의 증가하지 않아, 262K~1M 컨텍스트에서도 VRAM 사용량이 전통적 트랜스포머보다 훨씬 적다.

3. 벤치마크 성능

텍스트 성능 (Coding / Agent / General)

벤치마크Qwen3.8-27BQwen3.6-27BQwen3.7-PlusMuse Glimmer-30B
Coding
Terminal Bench 2.1 (Agentic terminal)73.063.464.051.7
SWE-bench Pro (Agentic coding)61.753.557.651.2
NL2Repo-Bench (Repo-level code gen)42.336.241.1--
DeepSWE 1.1 (Agentic coding)42.213.314.2--
QwenSWEBench (Software engineering)79.049.359.2--
Agent
CoWorkBench (Long-horizon office work)70.761.065.1--
JobBench (Professional job tasks)33.421.827.6--
Agents' Last Exam (Pass@1 / Score)20.4 / 42.910.6 / 27.313.2 / 33.6--
General
IFBench (Instruction following)79.569.179.177.0
GPQA Diamond (Scientific reasoning)89.287.890.383.5
HLE (Multidisciplinary reasoning)30.824.034.722.0
LiveCodeBench v6 (Competitive coding)90.383.989.6--

Qwen3.8-27B는 같은 27B 크기의 Qwen3.6-27B 대비 거의 모든 벤치마크에서 큰 폭의 향상을 기록했다. 특히 SWE-bench Pro(61.7 vs 53.5), QwenSWEBench(79.0 vs 49.3), DeepSWE 1.1(42.2 vs 13.3)에서 두드러진다.

Vision-Language (VL) 성능

벤치마크Qwen3.8-27BQwen3.6-27B
Agentic Multimodal
OSWorld-Verified (Computer use)84.363.9
WebArena-Verified (Browser use)64.848.8
AndroidWorld (Mobile use)81.970.3
RecreationBench (Application recreation)47.129.8
SWE-MM (Multimodal SW engineering)38.625.7
General Multimodal
MathVision (With CI)94.685.1
BabyVision (With CI)85.670.4
CharXiv RQ (With CI)90.285.9
OmniDocBench 1.5 (Document intelligence)91.189.4
RealWorldQA (Real-world perception)85.984.1

OSWorld-Verified(84.3)와 WebArena-Verified(64.8) 점수는 27B 크기의 오픈웨이트 모델로선 전례 없는 수준이다. 특히 전작 대비 OSWorld가 63.9에서 84.3으로 약 20점 점프했다.

4. 로컬 실행 — VRAM/RAM 요구사항

Ollama 패키지 크기는 약 17~18GB(BF16 기준 24.6 GiB, FP8/NVFP4 양자화 시 더 작음). 즉:

  • 17GB RAM/VRAM: GGUF Q4~Q5 양자화로 실행 가능 (Unsloth, LM Studio, Ollama)
  • 24GB VRAM: BF16 풀 정밀도 또는 FP8 양자화로 실행 가능 (RTX 4090, RTX PRO 6000)
  • AMD Radeon GPU: Day 0 지원 — LM Studio + ROCm
  • DGX Spark / RTX 5090 / H200: SGLang 공식 지원
  • CPU only (32GB+ RAM): llama.cpp GGUF로 실행 가능, 속도는 느림

하드웨어별 VRAM 가이드 (추천):

양자화파일 크기 (약)VRAM/RAM 요구
BF16 (풀 정밀도)~54 GB2x24GB GPU 또는 1x48GB+ GPU
FP8 / NVFP4 W4A4~27 GB1x24GB GPU (RTX 3090/4090)
GGUF Q6_K~24 GB1x24GB GPU + 32GB RAM
GGUF Q4_K_M (Ollama)~17 GB32GB RAM 또는 16GB+ VRAM GPU

5. 서비스/배포 방법

공식 지원되는 인퍼런스 프레임워크:

  • SGLang: BF16/FP8/NVFP4, MTP 내장 — H200, RTX PRO 6000, RTX 5090, DGX Spark
  • vLLM: YaRN 1M 컨텍스트 확장 지원, video frame sampling 가능
  • Ollama / LM Studio: GGUF 양자화 기반 로컬 실행 (17GB RAM/VRAM)
  • TokenSpeed: Alibaba 자체 인퍼런스 엔진
  • Hugging Face Transformers: Python 코드에서 직접 로딩 가능
  • Qwen Cloud API: 호스티드 서비스 (1M 컨텍스트 기본, 공식 도구 내장) — 공개 예정

추천 샘플링 파라미터

모드temperaturetop_ptop_kpresence_penalty
Thinking Mode (기본)1.00.95200.0
Instruct / Non-thinking0.70.80201.5

추가로 reasoning_effort 파라미터를 통해 추론 깊이를 조절할 수 있다:

  • xhigh (기본): 복잡한 태스크, 철저한 분석 필요 시
  • medium: 정확도-속도 균형
  • low: 속도/비용 최적화 (단, agent 태스크에서 오히려 실패율 증가 가능)

6. 사용시 유의사항

  • 1M 컨텍스트 사용 시: YaRN 설정이 필수. rope_parameters를 변경하거나 vLLM/SGLang CLI 인자로 전달. 단, 짧은 텍스트에서 성능 저하가 발생할 수 있으므로 factor 값을 상황에 맞게 조절 (524K 컨텍스트면 factor=2.0 권장)
  • 타임 단위 영상: video_preprocessor_config.json의 longest_edge를 469,762,048(약 224K video tokens)로 설정해야 고프레임 샘플링이 동작
  • preserve_thinking: 기본 활성화. 대화 전체의 사고 블록을 유지하여 agent 시나리오에서 의사결정 일관성 + KV 캐치 효율 향상. 필요시 False로 비활성화 가능
  • Agentic 태스크에서 reasoning_effort=low: 단일 턴은 빠지만, 불충분한 분석 → 실패 → 재시도 → 총 지연/토큰 소모 증가할 수 있음. 공식 문서에서 경고
  • Hacker Note: VRAM 효율이 Gemma 4나 Muse Glimmer보다 낮은 편이라는 커뮤니티 피드백 있음 (32K 컨텍스트에 2.5GB VRAM)

7. Qwen3.8 시리즈 전체 구성

모델타입파라미터특징
Qwen3.8-Max (API)2.4T MoE2,400B (MoE)Coding + Cowork 최상위, 2026.8.3 출시
Qwen3.8-27B (오픈웨이트)Dense + Vision27B (28B 표기)본 글 주인공. 17GB로 로컬 실행

Qwen3.8-Max API는 2026년 8월 3일에 먼저 출시되었고, 11일 뒤인 8월 14일에 27B 오픈웨이트가 공개되었다. Max의 오픈웨이트는 "이번 주"라는 공식 발표가 있었으나 27B 공개 시점 기준 아직 미공개 상태이다 (커뮤니티에서 지연 우려 보도 있음).

8. 커뮤니티 반응

  • r/LocalLLaMA: "2026년 가장 중요한 로컬 AI 릴리스 중 하나" — 17GB로 27B 멀티모달이 돌아간다는 점이 화제
  • Hacker News: 추론 과정이 Qwen3.8은 명시적(explicit), Gemma 4는 암시적(implicit)이라는 비교. VRAM 효율이 다른 모델보다 낮은 점 지적
  • AMD 공식 블로그: Ryzen AI Max + Radeon GPU Day 0 지원 — LM Studio로 즉시 실행 가능
  • Unsloth: NVFP4, GGUF 양자화 버전 공식 공개. 17GB RAM/VRAM 환경 실행 안내
  • NxCode (한국): "18GB가 가장 실용적인 숫자" — Ollama 패키지 크기를 강조하며 노트북/데스크톱에서도 최신 멀티모달 모델을 불러올 수 있다고 평가

9. 요약 — Qwen3.8-27B를 선택해야 할 경우

  • 로컬/엣지에서 27B급 다중모달 agent를 돌리고 싶을 때 (17~24GB VRAM/RAM)
  • Coding + Computer use(OSWorld 84.3) + Browser use를 한 모델로 처리하고 싶을 때
  • Apache 2.0 라이선스로 상업적 내장 필요
  • 262K~1M 장문 컨텍스트를 VRAM 부담 없이 처리할 때 (하이브리드 어텐션의 KV 캐치 효율)
  • AMD GPU + LM Studio 생태계와 완벽하게 호환 (Day 0)

참고 출처

이 포스트는 2026년 8월 15일 기준 Qwen3.8-27B 공식 문서와 커뮤니티 정보를 기반으로 작성되었습니다.

2026/07/13

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

분류: 증시분석

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

지난 7월 10일, SK하이닉스가 미국 나스닥에 미국주식예탁증서(ADR)를 상장했다. 공모가 149달러로 상장한 하이닉스 ADR은 첫 거래일인 13일 기준 약 168달러에 거래되며 약 13%의 프리미엄을 기록했다. 미국 투자자들이 달러로 SK하이닉스에 직접 투자할 수 있게 된 역사적인 순간이었다.

하지만 이 같은 호재성 뉴스에도 불구하고, 한국 증시는 예상과 달리 급격한 하락을 겪었다. SK하이닉스 주가는 14.57% 폭락하며 200만원 선을 무너뜨렸고, 코스피 지수도 2.52% 하락한 7475.94에 장을 마감했다. 이번 급락의 배경에는 어떤 요인들이 작용했을까?

1. 글로벌 AI 과잉 우려와 메모리 반도체 투매

이번 급락의 가장 핵심적인 원인은 글로벌 AI 인프라 과잉 투자 우려에서 비롯되었다. 세계 각국이 AI 데이터센터 건설에 막대한 자금을 투입하는 가운데, 일부 분석가들은 이것이 2000년 닷컴버블 수준의 위험 신호라고 경고했다.

미국 증시에서는 메모리 반도체 주식이 대규모 매도세에 휩싸였다. 마이크론(Micron)이 10.57% 급락하며 메모리 반도체 섹터 전체에 투매가 확산되었고, 이는 한국 증시의 SK하이닉스에 직접적인 영향을 미쳤다. 글로벌 반도체 사이클의 정점 피크아웃(peak-out) 우려가 해소되지 못한 상태였기 때문이다.

2. 45조 원 규모 유상증자의 희석 효과

SK하이닉스의 ADR 상장은 단순한 해외 증시 진출을 넘어 약 45조 원 규모의 유상증자를 수반했다. 이는 외국기업 최대규모의 ADR 상장이라는 기록을 세웠지만, 동시에 국내 주주들에게는 지분 희석으로 받아들여졌다.

대규모 자금 조달은 장기적으로 AI 반도체 연구개발 및 설비투자에 활용될 것으로 기대되지만, 단기적으로는 다음과 같은 부정적 심리가 작용했다:

  • 지분 희석 우려: 기존 주주들의 보유 지분 가치가 감소할 것이라는 전망
  • 물량 공급 증가: ADR 발행으로 인한 증시 유동성 압박
  • 공모가 할인 심리: ADR 가격이 국내 본주보다 낮게 형성될 경우 부담감 증대

3. ADR 상장 오버행(Overhang) 효과

오버행(Overhang)이란, 대규모 주식 발행이 예정되어 있음에도 아직 시장에서 거래되지 않은 상태를 말한다. SK하이닉스의 경우 ADR 상장 및 유상증자 규모가 극대화되면서, 투자자들은 공모 이후 ADR이 시장에서 매도될 것이라는 우려를 품었다.

ADR 첫 거래에서 프리미엄이 형성되었다는 점은 긍정적 신호였으나, 이 같은 호재가 이미 사전에 주가에 반영되어 있었기 때문에 "호재성 실증"으로 작용하며 오히려 매도세를 촉발했다.

4. 중동 지정학적 리스크 재부각

ADR 상장 직후인 13일, 중동 지역 포격 재개라는 지정학적 리스크가 다시 부각되었다. 이는 글로벌 위험 회피 심리를 자극하며 한국 증시의 하락을 가속화하는 요인으로 작용했다. 하이닉스 지분 영향으로 함께 상승했던 SK스퀘어는 9% 이상 급락하며 시장 불안을 극대화했다.

5. 환율 및 미국 금리 정책 불확실성

ADR 상장 과정에서 원-달러 환율 변동성과 미국 연준의 금리 정책 방향에 대한 불확실성도 시장 심리에 부정적 영향을 미쳤다. ADR이 달러화로 거래되면서 환율 변동에 따른 손실 우려가 외국인 투자자들의 매수 심리를 위축시켰다.

시장 반응 및 향후 전망

급락 이후 시장에서는 다양한 분석이 나오고 있다. DS투자증권은 ADR 상장 이벤트만으로 본주 8~18% 상승효과가 기대된다고 분석하기도 했으며, 하이닉스 ADR은 공모가 대비 15.7% 프리미엄을 형성하며 미국 기관들의 관심을 끌고 있다.

또한 SK하이닉스 ADR과 연계한 레버리지 ETF가 5개사 이상 잇따라 출시되며, 미국 증시에서의 관심은 오히려 강화되고 있다. 다만 단기적으로는 메모리 반도체 업황의 사이클 피크아웃 우려와 글로벌 AI 과잉 투자 논란이 해소될 때까지 변동성이 클 것으로 전망된다.

결론

SK하이닉스 ADR 상장은 장기적으로는 코리아 디스카운트 해소, 글로벌 밸류에이션 재평가, MSCI 지수 편입 기대 등 긍정적인 효과를 가져올 것으로 보인다. 그러나 단기적으로는 글로벌 AI 과잉 우려, 대규모 유상증자의 희석 효과, 오버행 심리, 지정학적 리스크 등이 복합적으로 작용하며 급락을 초래했다.

투자자들은 이번급락을 단기 조정으로 볼 것인지, 아니면 반도체 사이클 전환의 시작점으로 해석할 것인지를 신중하게 판단해야 할 시점이다.

2026/07/12

Apple Silicon LLM 추론: omlx vs vLLM Metal 성능 비교 분석

Apple Silicon LLM 추론: omlx vs vLLM Metal 성능 비교 분석

Apple Silicon 환경에서 LLM을 로컬에서 돌릴 때, 어떤 추론 엔진을 써야 할지 고민하는 개발자가 많습니다. omlx(continuous batching 기반)와 vLLM Metal(vLLM 공식 Apple Silicon 플러그인)은 가장 핫한 두 옵션인데, 실제 성능과 아키텍처 차이는 생각보다 큽니다.

2026년 7월 기준으로 최신 벤치마크 데이터와 아키텍처 차이를 비교 분석했습니다.


둘의 정체

omlx(GitHub, 17.6k stars)는 Apple Silicon 전용 LLM 추론 서버입니다. continuous batchingSSD 기반 KV 캐시가 핵심이며, OpenAI 호환 API를 제공해 기존 코드 변경 없이 바로 쓸 수 있습니다. macOS 메뉴 바에서 관리되는 네이티브 애플리케이션 형태로도 제공됩니다.

vLLM Metal(GitHub)은 vLLM 프로젝트의 공식 Apple Silicon 하드웨어 플러그인입니다. CUDA 환경에서 검증된 vLLM의 아키텍처(PagedAttention 등)를 Metal 백엔드로 이식하려는 시도이며, 2026년 4월 v0.2.0에서 Unified paged varlen Metal kernel이 기본 attention 백엔드로 채택되었습니다.

아키텍처 비교

두 프로젝트의 근본적인 차이를 먼저 정리합니다.

omlx 아키텍처:

  • continuous batching: 여러 요청을 하나의 forward pass로 묶어 실행 — Apple Silicon에서 실제 batching이 동작하는 유일한 백엔드
  • SSD KV 캐시: 긴 컨텍스트에서 메모리 압력을 SSD로 오프로드 — 32k 토큰 입력에서도 throughput 유지
  • MLX 기반: Apple의 MLX 프레임워크 위에서 동작하며 Metal GPU를 직접 활용
  • OpenAI 호환 API: localhost:8000에서 HTTP SSE 스트리밍 제공
  • macOS 네이티브 앱: 메뉴 바에서 모델 시작/종료, 설정 관리

vLLM Metal 아키텍처:

  • vLLM 공식 플러그인: UC Berkeley에서 개발한 vLLM 생태계와 통합
  • PagedAttention 이식 시도: v0.2.0에서 Unified paged varlen Metal kernel 도입 — v0.1.0 대비 83배 TTFT 개선, 3.6배 throughput 향상
  • MLX + PyTorch 통합 lowering: MLX와 PyTorch를 단일 경로로 통합
  • 텍스트 전용: 현재 텍스트 모델만 지원 (멀티모달 미지원)
  • ARM64 네이티브 Python 3.12: Rosetta 없이 동작

벤치마크 결과 (Qwen3.5-9B, 4-bit)

Latent Space의 5종 백엔드 벤치마크(출처)와 vLLM Metal 공식 데이터를 종합했습니다.

단일 요청 Throughput

Qwen3.5-9B 모델을 4-bit 양자화로 실행한 결과입니다.

MLX (직접 호출): 25.06 tok/s — 라이브러리 직접 호출이라 HTTP 오버헤드 없음

omlx: ~20 tok/s — continuous batching 스케줄러 오버헤드 포함

vLLM Metal: MLX 범위 추적 — 단일 요청에서는 MLX와 유사한 수준

llama.cpp Metal: 15.34 tok/s

Ollama: 13.76 tok/s

단일 요청에서는 raw MLX가 가장 빠르고, omlx는 약 20% 정도 느립니다. omlx의 overhead는 continuous batching 스케줄러 큐 + SSE 프레이밍에서 옵니다.

TTFT (Time To First Token)

llama.cpp Metal: 196ms — 가장 빠름

MLX: 396ms

Ollama: 470ms

omlx: 968ms — continuous batching 큐 대기 + SSE 오버헤드

TTFT는 단일 요청에서 omlx가 가장 느립니다. 하지만 이 overhead는 동시 요청이 늘어날 때 batching 효율로 상쇄됩니다.

Concurrency (동시 요청)

여기서 진짜 차이가 납니다.

MLX, llama.cpp, Ollama는 동시 요청이 늘어나도 aggregate throughput이 거의 변하지 않습니다. NUM_PARALLEL은 큐 깊이를 제어할 뿐, 실제 batching을 하지 않기 때문입니다.

omlx만 실제 batching이 동작합니다:

512-token 입력: 15.6 to 21.9 tok/s (concurrency 1 to 4, 1.40배)

2048-token 입력: 11.2 to 14.4 tok/s (concurrency 1 to 4, 1.29배)

vLLM Metal v0.2.0:

Unified paged varlen Metal kernel 도입으로 v0.1.0 대비 83배 TTFT 개선, 3.6배 throughput 향상. 하지만 Apple Silicon에서 vLLM GPU 버전의 batching 이점을 완전히 재현하지는 못하고 있습니다. MLX-managed KV cache를 사용하며, CUDA 버전의 PagedAttention과는 다른 구현입니다.

긴 컨텍스트 (Long Context)

512 to 32k 토큰 입력에서 decode throughput 변화:

MLX / llama.cpp / Ollama: 512~8k까지는 안정적 — 32k에서 약 절반으로 급감. KV 캐시가 커지면서 unified memory 대역폭 압력이 증가합니다.

omlx: 512~32k 토큰에서 약 20 tok/s로 일정 유지. SSD 기반 KV 캐시가 긴 컨텍스트에서도 일관된 성능을 보장합니다.

vLLM-MLX: 하이브리드 접근

vllm-mlx(독립 프로젝트)는 또 다른 옵션입니다. MLX 위에 vLLM과 유사한 CLI/API를 제공하는 프로젝트로, M4 Max에서 464 tok/s(Qwen3-0.6B)를 기록했습니다. arXiv 논문(2601.19139)에 따르면 M4 Max에서 Qwen3-0.6B 텍스트 모델로 최대 525 tok/s, Qwen3-VL-4B로 143 tok/s를 달성했으며, mlx-lm과 llama.cpp 모두를 상회합니다.

하지만 Reddit 커뮤니티(출처)에서는 "실제 vLLM이 아니라 vLLM과 유사한 인터페이스를 제공하는 MLX 기반 프로젝트"라고 지적합니다. PagedAttention 같은 vLLM의 핵심 최적화를 구현하지 않았다는 평가입니다.

언제 무엇을 써야 할까?

단일 사용자 / 로컬 개발 (IDE, CLI):

MLX 직접 호출. 25 tok/s, 서버 프로세스 없이 라이브러리만 import 하면 됨. Python 기반이라면 가장 빠른 선택입니다.

다중 사용자 / 서버 환경:

omlx. Apple Silicon에서 유일하게 batching이 실제 동작하는 백엔드. 동시 요청 4개에서 aggregate throughput이 1.29~1.40배 향상되며, OpenAI 호환 API로 기존 코드와의 통합도 쉽습니다.

vLLM 생태계 통합:

vLLM Metal. CUDA 환경에서 테스트한 vLLM 워크플로우를 Apple Silicon으로 이식할 때 유용합니다. v0.2.0에서 Metal kernel이 크게 개선되었지만, 아직 CUDA 버전의 batching 성능에는 미치지 못합니다.

편의성:

Ollama. ollama pull 한 줄로 모델 다운로드부터 serving까지. throughput은 최적이 아니지만 운영 편의성이 최고입니다.

결론

Apple Silicon에서 LLM 추론을 돌릴 때 "무조건 vLLM"이라는 공식은 통하지 않습니다. CUDA GPU와 달리 Apple Silicon의 unified memory 아키텍처에서 vLLM Metal은 아직 batching 이점을 충분히 실현하지 못하고 있습니다.

실제 batching이 필요한 서버 환경에서는 omlx가 현재 가장 확실한 선택입니다. continuous batching + SSD KV 캐시 조합이 Apple Silicon의 unified memory 특성에 가장 잘 맞고, OpenAI 호환 API로 기존 코드와의 통합도 쉽습니다.

단일 사용자라면 raw MLX가 여전히 가장 빠릅니다. HTTP 서버 계층 없이 라이브러리 직접 호출이라 오버헤드가 거의 없습니다.

vLLM Metal은 v0.2.0에서 큰 걸음을 내딛었지만, Apple Silicon 환경에서는 아직 omlx가 앞선다고 보는 것이 현실적입니다. 다만 vLLM Metal이 CUDA 버전의 PagedAttention을 완전히 재현하면 게임 체인저가 될 잠재력은 분명히 있습니다.


벤치마크 데이터 출처: Latent Space - Apple Silicon LLM Backends Benchmark, vLLM Metal GitHub, arXiv 2601.19139

딱딱하게 굳은 설탕, 먹어도 될까? 유통기한과 보관법

딱딱하게 굳은 설탕, 먹어도 될까?

주방에서 오래 보관해 둔 설탕이 딱딱하게 굳어 있는 모습을 본 적 있을 겁니다. 이건 상한 걸까, 버려야 할까?

결론부터 말하면, 딱딱하게 굳은 설탕은 먹어도 안전합니다.

왜 설탕이 굳을까?

설탕이 딱딱하게 굳는 현상은 결정화(crystallization) 때문입니다. 설탕 결정 표면에는 미세한 수분 또는 몰라싸스(흑설탕의 경우) 막이 있는데, 습도가 낮아지면 이 수분이 증발하면서 결정들이 서로 달라붙어 단단한 덩어리가 됩니다.

이는 설탕의 화학적 성질이 변한 것이 아니라, 순수한 물리적 변화일 뿐입니다. 따라서 안전성에 문제가 없습니다.

유통기한은?

설탕은 실질적으로 유통기한이 없습니다. 백설탕의 경우 밀폐 용기에 보관하면 영구적으로 보존이 가능합니다. 식품위생법에서도 설탕은 유통기한 표시를 면제하는 식품에 해당합니다.

  • 백설탕: 밀폐 보관 시 무기한 보존 가능
  • 흑설탕: 몰라싸스가 건조되면서 품질이 저하될 수 있어 1~2년 내 사용 권장
  • 가루설탕(파우더드 설탕): 수분 흡수 시 덩어리지므로 밀폐 보관 필수

굳은 설탕, 어떻게 사용하나?

굳은 설탕도 요리와 양조에 그대로 사용할 수 있습니다. 부드럽게 만드는 방법은 다음과 같습니다.

  • 전자레인지: 젖은 종이타월을 설탕 위에 덮고 30초간 가열
  • 빵 또는 사과: 밀폐 용기 안에 빵 조각이나 사과 한 조각과 함께 하룻밤 두면 수분이 이동하여 부드러워짐
  • 망치 또는 롤링핀: 덩어리를 직접 부수기
  • 식품처리기: 짧은 시간간 회전시켜 분쇄
  • 따뜻한 물에 녹이기: 레시피에서 설탕을 따뜻한 액체에 직접 녹여 사용

버려야 하는 경우

굳는 것 자체가 문제가 아니지만, 다음 상황에서는 버리는 것이 좋습니다.

  • 곰팡이가 피었을 때
  • 이물이나 벌레가 있을 때
  • 이상한 냄새가 날 때

올바른 보관법

설탕을 건조하고 서늘한 곳에 밀폐 용기에 보관하면 굳는 현상을 방지할 수 있습니다. 습기가 많은 주방에서는 실리콘 건조제와 함께 보관하는 것도 좋은 방법입니다.

또한 집에서 굴러다니는 식품용 실리카겔을 설탕통에 넣었는데 좋을거 같아요.

2026/07/11

M4 MacStudio Max 64GB + M4 MacBookPro Max 64 두대를 하나의 128GB 고성능 AI 서버로 활용하기

[Sovereign AI] M4 Max Mac Studio + MacBook Pro로 구축한 128GB 초고속 분산 AI 클러스터 결산 및 삽질기

안녕하세요! 최근 Apple이 WWDC에서 공개한 오픈소스 저수준 집합 통신 라이브러리인 JACCL(Jack and Angelos' Collective Communication Library) 백엔드와 macOS의 Thunderbolt RDMA 기술을 활용하여, 제가 보유한 두 대의 M4 Max 기기를 하나의 거대한 128GB AI 연산 머신으로 묶는 프로젝트를 진행했습니다.

NVIDIA의 데이터센터 인프라(NVLink/InfiniBand) 부럽지 않게, 방구석에서 썬더볼트 케이블 하나로 텐서 병렬(Tensor Parallel) 처리를 완수하기까지의 전체 세팅 과정, 성능 측정 결과, 그리고 눈물겨운 시행착오를 아주 디테일하게 기록해 둡니다.

※ 본 포스팅은 macOS 26.2 이상 환경을 기준으로 작성되었습니다.

1. 💻 하드웨어 구성 환경 및 물리 인프라

흔히 구성하는 메인보드 분할형 PC 클러스터와 달리, 애플 실리콘의 Unified Memory 구조 덕분에 두 기기를 묶는 순간 메모리 대역폭이 깎이지 않고 그대로 보존되는 대칭형 고성능 클러스터가 완성됩니다.

  • 마스터 노드 (홈서버): Mac Studio (M4 Max / 16코어 CPU / 40코어 GPU / 64GB Unified Memory)
  • 워커 노드 (물팟스): MacBook Pro 14 (M4 Max / 16코어 CPU / 40코어 GPU / 64GB Unified Memory)
  • 연결 인터페이스: 별도의 스위칭 허브 없이 Thunderbolt 케이블을 포트 대 포트로 1:1 직접 연결 (P2P Mesh Topology)
  • 클러스터 통합 스펙:128GB 통합 메모리 확보 (실질 GPU 할당 가능 메모리 약 110GB 내외)

2. 🛠️ 실전 구축 프로세스 4단계

[Step 1] macOS 복구 모드에서 RDMA 보안 게이트 해제

macOS 레벨에서 CPU 개입 없이 커널을 우회해 다른 기기의 메모리에 직접 접근하는 RDMA(Remote Direct Memory Access)를 허용해야 합니다. 두 기기를 각각 완전히 종료한 뒤 전원 버튼을 길게 눌러 복구 모드(Recovery Mode)로 진입합니다.

# 상단 메뉴 [유틸리티] -> [터미널]을 선택하고 아래 명령어 입력 후 재부팅
rdma_ctl enable

정상적으로 재부팅되었다면 일반 터미널에서 ibv_devices 명령을 실행해 봅니다. apple_thunderbolt_0와 같은 인터페이스명이 출력되면 하드웨어 준비는 끝난 것입니다.

[Step 2] 1:1 독립 서브넷 및 고정 IP 할당 (가장 중요)

macOS의 가상 네트워크인 'Thunderbolt 브릿지'가 켜져 있으면 JACCL이 개별 물리 포트의 RDMA 주소를 인식하지 못하는 치명적인 문제가 있습니다. 시스템 설정 -> 네트워크에서 Thunderbolt 브릿지를 비활성화(또는 삭제)한 뒤, 연결된 단일 썬더볼트 포트에 각각 수동 IP를 매핑합니다.

  • 맥 스튜디오 (홈서버): IP 192.168.10.1 / 서브넷 마스크 255.255.255.0
  • 맥북 프로 (물팟스): IP 192.168.10.2 / 서브넷 마스크 255.255.255.0

설정 후 맥 스튜디오에서 ping 192.168.10.2가 단일 자릿수 ms 이하의 극도로 낮은 지연 시간으로 가는지 테스트합니다.

[Step 3] SSH 무암호 인증 및 파이썬 환경 동기화

다행히 두 기기의 로컬 계정명이 mulpats로 완전히 일치하여 경로 지정이 무척 수월했습니다. 맥 스튜디오에서 SSH 키를 생성하여 맥북 프로로 밀어 넣어줍니다.

ssh-keygen -t rsa -b 4096
ssh-copy-id mulpats@192.168.10.2

이후 두 Mac 모두 가상환경(또는 로컬 환경)에 완벽히 동일한 버전의 라이브러리를 빌드합니다.

pip install mlx mlx-lm

추가로, 구동하려는 모델(예: Llama-3-70B) 파일을 두 기기의 완전히 일치하는 절대 경로(/Users/mulpats/models/...)에 똑같이 저장해 주어야 연산 노드가 꼬이지 않습니다.

[Step 4] 클러스터 설정 파일 (cluster_hosts.json) 작성

MLX 분산 컴파일러가 인식할 수 있도록 홈 디렉토리에 다음과 같이 링/메시 토폴로지용 JSON 파일을 생성했습니다.

{
  "version": 1,
  "nodes": [
    { "hostname": "192.168.10.1", "user": "mulpats", "port": 22, "rdma_device": "apple_thunderbolt_0" },
    { "hostname": "192.168.10.2", "user": "mulpats", "port": 22, "rdma_device": "apple_thunderbolt_0" }
  ]
}

3. ⚠️ 눈물 없인 볼 수 없는 시행착오 (Troubleshooting)

해외 포럼과 깃허브 이슈를 샅샅이 뒤져가며 해결한 핵심 에러 3가지를 정리합니다. 이 글을 보시는 분들은 부디 한 번에 성공하시길 바랍니다.

발생한 에러 현상 원인 분석 해결 방법 (Fix)
JACCL RTR errno 22 (EINVAL) 또는 노드 감지 실패 macOS 기본 기능인 'Thunderbolt 브릿지' 가상 어댑터가 활성화되어 있어 JACCL이 개별 인터페이스의 물리 고유 RDMA 주소를 찾지 못함. 시스템 설정 -> 네트워크 메뉴 하단에서 가상 'Thunderbolt 브릿지' 서비스를 과감히 삭제하고 1:1 다이렉트 수동 IP 할당으로 우회.
mlx.launch 실행 직후 아무 반응 없이 무한 프리징 mlx.launch 스크립트가 SSH를 통해 상대 노드에 처음 접근할 때, 호스트 키 확인(Are you sure you want to continue connecting (yes/no)?) 팝업 프롬프트 단계에서 입력 처리를 못 해 멈춤. 클러스터 가동 전, 맥 스튜디오에서 ssh mulpats@192.168.10.2 명령어로 원격 노드에 수동으로 최초 1회 직접 접속하여 Known_hosts 인증을 마쳐둠.
분산 처리 중 비정상적인 전송 딜레이 및 연산 속도 저하 NVIDIA의 NCCL 환경과 달리 GPU 연산 컨텍스트와 CPU-RDMA 버퍼 간의 컨텍스트 스위칭 동기화가 밀려 병목 현상 발생. 런처 실행 시 인라인 환경 변수로 애플 실리콘 최적화 옵션인 MLX_METAL_FAST_SYNCH=1 플래그를 반드시 강제 주입해 줌.

4. 🚀 대망의 최종 실행 및 성능 측정 결과

모든 트러블슈팅을 마치고 마스터 노드 터미널에서 JACCL 백엔드를 지정해 대형 양자화 모델인 Llama-3-70B-Instruct-4bit를 실행했습니다.

mlx.launch --backend jaccl --hostfile cluster_hosts.json --env MLX_METAL_FAST_SYNCH=1 \
python -m mlx_lm.generate \
--model /Users/mulpats/models/Meta-Llama-3-70B-Instruct-4bit \
--prompt "M4 Max 클러스터 구동을 축하하는 아주 멋진 기술 블로그 아웃트로 문장을 작성해줘." \
--max-tokens 256

📈 벤치마크 스코어 및 체감 성능

  • 수치적 결과: 단일 64GB 맥에서는 OOM(메모리 부족) 에러를 뿜으며 터지던 70B 모델이, 클러스터링 후 초당 약 22 ~ 26 토큰(Tokens per Second) 수준의 부드럽고 쾌적한 속도로 추론을 성공했습니다!
  • 네트워크 대역폭 확인: 추론 연산이 수행되는 동안 썬더볼트 대역폭은 실측 50 ~ 60 Gbps 수준을 꾸준히 유지했으며, 지연 시간은 마이크로초(μs) 단위를 유지해 병목을 거의 느낄 수 없었습니다.
  • 소음 및 발열: 풀 로드 상태에서도 고성능 PC나 GPU 워크스테이션처럼 이륙하는 팬 소음 없이, 아주 고요하고 정숙한 상태(정말 기분 좋은 맥 스튜디오 특유의 미미한 바람 소리 정도)로 작업이 완수되는 점이 대단히 만족스럽습니다.

💡 글을 마치며: 방구석 Sovereign AI의 가능성

수백, 수천만 원을 호가하는 NVIDIA의 H100/A100 클라우드 인프라를 매달 구독하지 않고도, 내가 가진 Apple Silicon 장비들을 정품 케이블 하나로 묶어 로컬에서 나만의 독립된 소형 AI 데이터센터를 소유할 수 있다는 사실이 온몸으로 체감되는 프로젝트였습니다.

M4 Max 칩셋의 강력한 전성비와 메모리 아키텍처, 그리고 Apple 개발진들이 칼을 갈고 만든 JACCL 라이브러리의 파괴력을 제대로 맛보았네요. 다음번에는 추론을 넘어 LoRA 분산 파인튜닝(Fine-Tuning) 학습까지 도전해 보고 그 결과를 공유하겠습니다. 궁금한 점이 있으시다면 댓글로 편하게 남겨주세요!


맥 두대 장비값만 천만원이 넘어간다는 사실... ㅡㅡ;

Mac Studio M3 Ultra vs M5 Ultra — 어떤 기기를 사야 하는가

분류: 로컬AI 2025년 3월, Apple은 Mac Studio에 M3 Ultra 칩을 탑재해 출시했습니다. 그리고 2026년, M5 Ultra가 등장하며 로컬 AI 커뮤니티의 관심이 다시 한 번 모이고 있어요. 두 칩은 모두 "데스크...