[온프레미스 AI Assistant 아키텍처 — Qwen3·Qwen3-VL 14일 설계] 3/14화: Mac Studio MLX vs CUDA vLLM, Qwen3 서빙 전략

이 글은 「온프레미스 AI Assistant 아키텍처 — Qwen3·Qwen3-VL 14일 설계」 시리즈 3일차로, Mac Studio MLX 추론과 CUDA vLLM 서빙 전략을 비교합니다.

어제 한 줄 회상 — 2회에서는 Qwen3의 Dense vs MoE 구조, Instruct vs Thinking 에디션 차이, 양자화 포맷(FP16·FP8·AWQ·GGUF·MLX)별 메모리-속도-정확도 트레이드오프를 분석하고, ‘어떤 변형을 어디에 배치할지’ 결정 트리를 완성했습니다. 모델 변형을 확정했다면 다음 질문은 하나입니다. “이 모델을 어떤 하드웨어에서 돌릴 것인가?”

오늘의 핵심 3가지

• LLM 디코드는 메모리 대역폭 바운드 — 토큰 생성 속도(tok/s)는 GPU 연산력이 아니라 메모리에서 가중치를 얼마나 빨리 읽어오느냐가 결정합니다. 하드웨어 스펙 시트의 ‘TFLOPS’보다 ‘GB/s’를 먼저 볼 것.
• Apple Silicon UMA vs NVIDIA VRAM — 트레이드오프지 우열이 아니다 — Mac Studio는 최대 512 GB 통합 메모리로 대형 모델 적재에 압도적이고, NVIDIA GPU는 높은 대역폭(1,008~3,350 GB/s)과 배치 동시성에서 앞섭니다.
• MoE 모델은 Mac Studio의 숨겨진 킬러 유스케이스 — Qwen3-30B-A3B는 30 B 전체 파라미터를 메모리에 올려야 하지만 토큰당 활성 파라미터는 3 B뿐입니다. “메모리는 크게, 대역폭 요구는 작게” — Mac Studio의 UMA 특성과 정확히 맞물립니다.

하드웨어 선택이 아키텍처를 결정한다

1회에서 그린 레이어 지도를 기억하시나요. LLM 추론 서버는 그 지도의 최하단 계층입니다. 이 계층에서 어떤 하드웨어를 쓰느냐에 따라 위쪽의 서빙 프레임워크, 양자화 포맷, 동시성 모델, 심지어 게이트웨이 라우팅 전략까지 연쇄적으로 달라집니다.

온프레미스에서 Qwen3 계열을 서빙할 때 현실적인 선택지는 두 트랙으로 나뉩니다.

• 트랙 A — Apple Silicon (Mac Studio): 통합 메모리 + MLX + Metal GPU 가속
• 트랙 B — NVIDIA CUDA (GPU 서버): 전용 VRAM + vLLM/TensorRT-LLM + CUDA Tensor Core

이 두 트랙은 상충하는 강점을 가집니다. 어느 한쪽이 모든 면에서 우월하다면 고민이 없겠지만, 실제로는 모델 크기, 동시 사용자 수, 전력·소음 제약, 예산에 따라 최적 선택이 갈립니다. 이 글의 목표는 그 분기점을 정확히 짚는 것입니다.

LLM 추론의 두 병목 — 왜 메모리 대역폭인가

하드웨어를 비교하기 전에, LLM이 토큰을 생성할 때 어디서 느려지는지를 이해해야 합니다. 추론(inference)은 크게 두 단계로 나뉩니다.

프리필(Prefill) — 연산 바운드

사용자의 프롬프트(입력 토큰)를 한꺼번에 처리하는 단계입니다. 입력 토큰들이 병렬로 행렬 곱셈을 거치기 때문에, 이 구간의 속도는 GPU의 부동소수점 연산 성능(TFLOPS)이 좌우합니다. 프롬프트가 길수록 — 예를 들어 RAG로 4,000 토큰짜리 문맥을 붙일 때 — 프리필 시간이 눈에 띄게 늘어납니다.

디코드(Decode) — 메모리 대역폭 바운드

출력 토큰을 하나씩 순차 생성하는 단계입니다. 매 토큰을 만들 때마다 모델의 전체 가중치를 메모리에서 읽어와야 합니다. batch=1(단일 요청)인 경우, GPU의 연산 유닛은 대부분 놀고 있고 메모리 버스가 병목이 됩니다. 사용자가 체감하는 ‘응답 속도’는 이 디코드 단계의 tok/s입니다.

핵심 공식은 놀랍도록 단순합니다.

이론적 최대 tok/s (batch=1) = 메모리 대역폭(GB/s) ÷ 모델 가중치 메모리(GB)

예를 들어 RTX 4090(1,008 GB/s)에서 Qwen3-14B Q4(약 8.5 GB)를 돌리면:

1,008 ÷ 8.5 ≈ 119 tok/s (이론 최대)
실측: 약 55~75 tok/s (KV 캐시·프레임워크 오버헤드 차감)

실측이 이론의 50~65% 수준인 이유는 KV 캐시 읽기, 어텐션 연산, 프레임워크 스케줄링 오버헤드 때문입니다. 하지만 하드웨어 간 상대 비교에서는 이 공식이 잘 들어맞습니다. 따라서 하드웨어 스펙 시트에서 가장 먼저 봐야 할 숫자는 TFLOPS가 아니라 메모리 대역폭(GB/s)입니다.

MoE 모델의 특수한 대역폭 프로필

2회에서 다룬 Qwen3-30B-A3B를 떠올려 봅시다. 전체 파라미터는 30 B이지만, 토큰당 활성 파라미터는 3 B입니다. 여기서 중요한 구분이 생깁니다.

• 메모리 용량: 30 B 전체 가중치를 올려야 합니다. Q4 양자화 기준 약 17 GB.
• 토큰당 메모리 읽기: 라우터가 선택한 활성 전문가(expert)의 가중치만 읽습니다. 약 3 B × 0.56 bytes/param ≈ 1.7 GB.

따라서 tok/s 공식의 분모에는 17 GB가 아니라 ~1.7 GB가 들어갑니다. 같은 메모리를 차지하는 Dense 모델(예: Qwen3-14B Q4 ≈ 8.5 GB)보다 MoE 모델이 tok/s에서 훨씬 유리한 이유입니다. 이 특성이 뒤에서 하드웨어 매핑을 크게 바꿉니다.

트랙 A: Apple Silicon — Mac Studio의 구조적 강점

통합 메모리 아키텍처(UMA)의 의미

NVIDIA GPU는 시스템 RAM과 분리된 전용 VRAM(GDDR6X 또는 HBM)을 사용합니다. 모델 가중치는 반드시 이 VRAM에 올라가야 하고, VRAM 용량이 적재 가능한 모델의 상한을 결정합니다. RTX 4090의 VRAM은 24 GB — Qwen3-32B FP16(약 64 GB)은 물리적으로 올릴 수 없습니다.

Apple Silicon은 근본적으로 다릅니다. CPU, GPU, Neural Engine이 하나의 물리 메모리 풀을 공유합니다. Mac Studio M2 Ultra는 최대 192 GB, M4 Ultra는 최대 512 GB의 통합 메모리를 제공합니다. GPU가 접근하는 메모리와 CPU가 접근하는 메모리가 같기 때문에 CPU→GPU 데이터 전송(PCIe 복사) 자체가 없습니다. 모델 로딩이 사실상 ‘메모리에 한 번 올리면 끝’입니다.

이 구조적 차이가 대형 모델 서빙에서 결정적입니다. Qwen3-235B Q4(약 135 GB)를 단일 NVIDIA GPU에 올릴 방법은 없지만, Mac Studio M2 Ultra(192 GB)에는 올라갑니다. 멀티 GPU 없이, NVLink 없이, 텐서 병렬 설정 없이, 그냥 mlx_lm.generate 한 줄로 실행됩니다.

MLX와 Metal — Apple 네이티브 추론 스택

MLX는 Apple이 만든 머신러닝 프레임워크로, Apple Silicon의 통합 메모리를 네이티브로 활용합니다. PyTorch 스타일의 API를 제공하면서도 Metal GPU 셰이더로 가속하며, 메모리 복사 없이 GPU 연산을 수행합니다.

mlx-lm은 MLX 위에서 LLM 추론을 제공하는 라이브러리입니다. MLX 포맷(4-bit 양자화)으로 변환된 모델을 로드하고, OpenAI 호환 HTTP 엔드포인트를 제공합니다. Qwen3 모델은 Hugging Face의 mlx-community 조직에서 사전 변환된 MLX 포맷을 바로 내려받을 수 있습니다.

MLX의 현재 제약도 명확합니다.

• 배치 처리 한계: vLLM의 continuous batching(연속 배치)이나 PagedAttention 같은 고급 스케줄링이 없습니다. 동시 요청을 여러 개 보내면 사실상 순차 처리됩니다.
• 텐서 병렬 불가: Apple Silicon은 단일 SoC 아키텍처이므로 여러 대를 묶어 분산 추론하는 것이 불가합니다.
• 생태계 크기: CUDA 생태계 대비 모델 지원 범위, 최적화 기법, 서드파티 도구가 아직 적습니다.

Mac Studio 라인업별 스펙 비교 — M4 Max·Ultra 메모리와 대역폭

핵심 포인트: M4 Ultra는 M2 Ultra 대비 메모리 대역폭이 약 36% 향상되었고, 최대 메모리가 512 GB로 늘어 Qwen3-235B Q4(~135 GB)를 KV 캐시까지 여유 있게 수용합니다. 다만 가격도 그만큼 올라가므로, Qwen3-30B-A3B 이하 모델만 쓴다면 M2 Ultra 192 GB가 여전히 합리적입니다.

Apple Silicon이 빛나는 시나리오

• 대형 모델 단일 노드: 멀티 GPU 없이 32B~235B 모델을 올릴 수 있는 유일한 소비자급 하드웨어.
• MoE 모델: 메모리 용량은 크게 필요하지만 토큰당 대역폭 요구가 적은 구조 — UMA와 궁합 최적.
• 저소음·저전력 환경: 사무실, 홈 오피스, 소규모 팀. 시스템 전체 370 W는 RTX 4090 GPU 하나(450 W)보다 적습니다.
• 단일 사용자 또는 소수 동시 접속: 배치 처리 최적화가 덜 중요한 환경.
• 긴 컨텍스트: KV 캐시가 커져도 통합 메모리 풀에서 유연하게 수용.

트랙 B: NVIDIA CUDA — GPU 서버의 구조적 강점

전용 VRAM과 HBM의 대역폭 우위

NVIDIA GPU의 최대 강점은 메모리 대역폭입니다. RTX 4090의 GDDR6X는 1,008 GB/s, RTX 5090의 GDDR7은 1,792 GB/s, 데이터센터급 H100의 HBM3는 3,350 GB/s에 달합니다. Mac Studio M2 Ultra(800 GB/s)와 비교하면 RTX 4090이 이미 26% 빠르고, H100은 4.2배 빠릅니다.

디코드 공식을 다시 떠올려 보겠습니다. 같은 모델을 서빙할 때, 대역폭이 높은 GPU가 그만큼 빠르게 토큰을 생성합니다. Qwen3-14B Q4(~8.5 GB)의 이론적 tok/s를 비교하면:

실측 보정 계수 0.55는 KV 캐시 읽기, 어텐션 연산, 프레임워크 스케줄링을 반영한 경험적 근사입니다. 실제 값은 컨텍스트 길이, 배치 크기, 프레임워크 버전에 따라 달라지지만, 하드웨어 간 상대 비교에는 충분합니다.

CUDA + vLLM — 검증된 서빙 생태계

vLLM은 현재 오픈소스 LLM 서빙 프레임워크의 사실상 표준입니다. NVIDIA CUDA 위에서 동작하며, 두 가지 핵심 최적화로 처리량을 극대화합니다.

• PagedAttention: KV 캐시를 고정 크기 페이지 단위로 관리합니다. OS의 가상 메모리처럼 비연속 메모리 블록을 연결하여 KV 캐시 메모리 낭비를 90% 이상 줄입니다. 동시 요청이 많을수록 효과가 커집니다.
• Continuous Batching(연속 배치): 기존 방식은 배치 내 가장 긴 시퀀스가 끝날 때까지 전체가 대기했습니다. vLLM은 개별 요청이 끝나는 즉시 새 요청을 슬롯에 넣습니다. GPU 활용률이 비약적으로 올라갑니다.

이 두 최적화 덕분에 NVIDIA GPU는 다중 동시 사용자 환경에서 Apple Silicon과 격차가 벌어집니다. batch=1에서 차이가 26%라면, batch=16에서는 vLLM 쪽 처리량이 10배 이상 앞서는 것이 일반적입니다.

텐서 병렬과 멀티 GPU 확장

NVIDIA GPU는 여러 장을 묶어 하나의 큰 모델을 분산 로드할 수 있습니다. vLLM의 --tensor-parallel-size 옵션 하나로 설정됩니다.

• RTX 4090 × 2 (PCIe): 48 GB VRAM. Qwen3-32B FP8(~32 GB) 적재 가능.
• RTX 5090 × 2 (PCIe): 64 GB VRAM + 3,584 GB/s 합산 대역폭.
• A100 × 2 (NVLink): 160 GB + NVLink 600 GB/s 인터커넥트로 GPU 간 통신 병목 최소화.
• H100 × 4 (NVLink): 320 GB. Qwen3-235B FP8(~235 GB) 적재 가능.

단, 멀티 GPU는 인터커넥트 대역폭이라는 새로운 병목을 만듭니다. PCIe 4.0 x16은 약 32 GB/s로, 텐서 병렬 시 GPU 간 올-리듀스(all-reduce)가 이 대역폭에 묶입니다. NVLink(A100: 600 GB/s, H100: 900 GB/s)를 쓰면 해소되지만, 소비자용 RTX 시리즈에는 NVLink가 없다는 점을 기억해야 합니다.

GPU 라인업별 스펙 비교

NVIDIA가 빛나는 시나리오

• 다중 동시 사용자: 10명 이상이 동시에 요청을 보내는 팀·부서 규모. vLLM의 continuous batching이 GPU 활용률을 극대화.
• 고속 토큰 생성: 코드 생성, 실시간 채팅 등 지연 시간(latency)이 중요한 워크로드.
• 중소형 모델 고처리량: Qwen3-8B, 14B를 FP8로 올리면 RTX 4090 한 장으로 충분하고, 가격 대비 처리량이 최적.
• 스케일 아웃: 수요 증가 시 GPU 추가로 텐서 병렬 확장.
• 광범위한 생태계: vLLM, TensorRT-LLM, NVIDIA Triton, NCCL 등 검증된 도구 스택.

7대 축 비교 매트릭스

두 트랙의 특성을 7가지 축으로 정리합니다. 각 축에서 우위를 가진 쪽을 표시했습니다.

요약: Apple Silicon은 용량·전력·소음에서 우위, NVIDIA는 대역폭·연산·동시성·확장에서 우위. 어느 쪽이 ‘좋다’가 아니라, 어떤 워크로드에 쓸 것인가가 정답을 결정합니다.

Qwen3 모델 → 하드웨어 매핑

이제 2회에서 정리한 Qwen3 모델 변형들을 각 하드웨어에 얹어 보겠습니다.

메모리 요구량 산출

모델을 하드웨어에 올리려면 두 가지를 확인해야 합니다.

1. 적재 가능성: 모델 가중치 + KV 캐시 + 프레임워크 오버헤드 ≤ 가용 메모리
2. 추론 속도: 디코드 tok/s가 사용 사례에 충분한가

아래 공식으로 가중치 메모리를 추정합니다.

가중치 메모리(GB) = 파라미터 수(B) × 바이트/파라미터(quant별)

양자화별 바이트/파라미터:
  FP16  → 2.0 bytes
  FP8   → 1.0 bytes
  Q4    → ~0.56 bytes (4-bit + 그룹 스케일 오버헤드)

여기에 KV 캐시(컨텍스트 32K, batch=1 기준 보통 1~5 GB)와 프레임워크 오버헤드(0.5~1 GB)를 더하면 총 런타임 메모리가 됩니다.

모델별 가중치 메모리 & 하드웨어 적합성

표에서 몇 가지 패턴이 보입니다.

• RTX 4090 (24 GB): Qwen3-14B까지는 Q4로 쾌적. 30B-A3B는 Q4로 적재 가능하나 KV 캐시 여유가 적어 컨텍스트 길이를 제한해야 할 수 있습니다.
• RTX 5090 (32 GB): Qwen3-30B-A3B FP8이 편안하게 들어갑니다. 이 한 장의 대역폭(1,792 GB/s)은 Mac Studio M2 Ultra(800 GB/s)의 2.2배입니다.
• Mac Studio M2 Ultra (192 GB): Qwen3-235B Q4까지 단일 노드로 올릴 수 있는 유일한 소비자급 옵션입니다.
• MoE의 이점: Qwen3-30B-A3B Q4(16.8 GB)와 Qwen3-32B Q4(17.9 GB)는 메모리 점유가 비슷하지만, 디코드 속도에서 MoE가 압도적으로 빠릅니다 (활성 파라미터 3 B vs 32 B).

디코드 속도 추정: 모델 × 하드웨어 매트릭스

아래 표는 각 모델-양자화-하드웨어 조합의 추정 디코드 tok/s(batch=1, 32K 컨텍스트)입니다. 이론값에 보정 계수 0.55를 적용한 값이며, 실측 환경(프레임워크 버전, OS, 메모리 상태)에 따라 ±30% 편차가 있을 수 있습니다. MoE 모델은 활성 파라미터 기준으로 계산했습니다.

눈에 띄는 수치: Qwen3-30B-A3B Q4는 RTX 5090에서 이론상 ~580 tok/s를 기록합니다. 같은 메모리를 차지하는 Qwen3-32B Q4(~55 tok/s)의 10배입니다. MoE 아키텍처의 추론 효율이 극단적으로 드러나는 대목입니다. 물론 이론값이고 실측에서는 MoE 라우팅 오버헤드, 캐시 미스 등으로 절대 수치는 낮아지지만, 상대적 격차는 유의미합니다.

또 한 가지: Qwen3-235B Q4는 Mac Studio에서만 동작합니다. NVIDIA 단일 GPU로는 불가능하고, H100 × 2(160 GB)로도 Q4 기준 부족합니다. Mac Studio M2 Ultra(192 GB)가 이 모델의 최저 비용 진입점입니다.

하드웨어 선택 결정 트리

아래 다이어그램은 Qwen3 모델 크기와 운영 조건에 따라 하드웨어를 선택하는 흐름입니다.

하이브리드 전략 — 두 트랙을 하나의 시스템으로

실전에서는 ‘하나만 고르기’보다 두 트랙을 조합하는 것이 더 강력합니다. 서로 다른 강점을 가진 하드웨어에 서로 다른 역할의 모델을 배치하고, 앞단의 게이트웨이가 요청을 라우팅합니다.

하이브리드 아키텍처 다이어그램

왜 이 조합이 효과적인가

이 패턴의 핵심은 80%의 요청은 NVIDIA 노드에서 빠르게 처리하고, 나머지 20%의 복잡한 요청만 Mac Studio로 라우팅하는 것입니다. NVIDIA 노드는 가격 대비 처리량이 최적이고, Mac Studio는 대형 모델을 올릴 수 있는 유일한 단일 노드입니다. 6회에서 이 게이트웨이(LiteLLM 등)를 구체적으로 설계합니다.

실전 도구: 하드웨어 플래닝 스크립트

아래 Python 스크립트를 실행하면 Qwen3 모델별로 각 하드웨어에서의 적재 가능성과 추정 tok/s를 즉시 확인할 수 있습니다. 환경에 맞게 하드웨어 목록을 수정해서 사용하세요.

#!/usr/bin/env python3
"""qwen3_hw_planner.py — Qwen3 모델-하드웨어 적합성 매트릭스 생성기

실행: python qwen3_hw_planner.py
     python qwen3_hw_planner.py --ctx 65536
"""
import argparse
from dataclasses import dataclass


@dataclass(frozen=True)
class Model:
    name: str
    total_b: float     # 전체 파라미터 (십억)
    active_b: float    # 토큰당 활성 파라미터 (Dense=total, MoE=활성)
    is_moe: bool = False


@dataclass(frozen=True)
class HW:
    name: str
    mem_gb: float      # 가용 메모리 (GB)
    bw_gbs: float      # 메모리 대역폭 (GB/s)


MODELS = [
    Model("Qwen3-4B",       4.0,   4.0),
    Model("Qwen3-8B",       8.0,   8.0),
    Model("Qwen3-14B",     14.0,  14.0),
    Model("Qwen3-30B-A3B", 30.0,   3.0, True),
    Model("Qwen3-32B",     32.0,  32.0),
    Model("Qwen3-235B",   235.0,  22.0, True),
]

HARDWARE = [
    HW("RTX 4090",       24, 1008),
    HW("RTX 5090",       32, 1792),
    HW("A100 80G",       80, 2039),
    HW("H100 80G",       80, 3350),
    HW("M2 Ultra 192G", 192,  800),
    HW("M4 Ultra 512G", 512, 1092),
]

QUANT = {"FP16": 2.0, "FP8": 1.0, "Q4": 0.56}
EFFICIENCY = 0.55  # 실측 보정 계수


def runtime_gb(total_b: float, bpp: float, ctx: int) -> float:
    """가중치 + KV 캐시(batch=1) + 오버헤드 추정"""
    weight = total_b * bpp
    kv_cache = total_b * 5e-5 * ctx   # 간이 KV 캐시 근사
    return weight + kv_cache + 0.5


def main() -> None:
    ap = argparse.ArgumentParser()
    ap.add_argument("--ctx", type=int, default=32768,
                    help="컨텍스트 길이 (기본: 32768)")
    args = ap.parse_args()

    sep = "─" * 110
    print(f"\n  Qwen3 하드웨어 플래닝 — ctx={args.ctx:,}, batch=1\n")

    for m in MODELS:
        tag = "MoE" if m.is_moe else "Dense"
        active_info = (f", 활성 {m.active_b}B"
                       if m.is_moe else "")
        print(sep)
        print(f"  {m.name}  ({tag}, 총 {m.total_b}B{active_info})")
        print(sep)

        header = f"  {'양자화':<6} {'가중치':>7} {'런타임':>7}  "
        for hw in HARDWARE:
            header += f"| {hw.name:^18} "
        print(header)

        for qname, bpp in QUANT.items():
            w = m.total_b * bpp
            rt = runtime_gb(m.total_b, bpp, args.ctx)
            line = f"  {qname:<6} {w:>6.1f}G {rt:>6.1f}G  "

            for hw in HARDWARE:
                if rt > hw.mem_gb:
                    line += f"| {'❌ OOM':^18} "
                else:
                    active_w = m.active_b * bpp
                    tps = (hw.bw_gbs / active_w) * EFFICIENCY
                    line += f"| {'✅ ~' + str(int(tps)) + ' tok/s':^18} "
            print(line)
        print()


if __name__ == "__main__":
    main()

실행 결과 예시 (발췌):

──────────────────────────────────────────────────────────────────────────────
  Qwen3-30B-A3B  (MoE, 총 30.0B, 활성 3.0B)
──────────────────────────────────────────────────────────────────────────────
  양자화  가중치  런타임  | RTX 4090          | RTX 5090          | M2 Ultra 192G
  FP16   60.0G  61.0G  | ❌ OOM             | ❌ OOM             | ✅ ~73 tok/s
  FP8    30.0G  31.0G  | ❌ OOM             | ✅ ~329 tok/s      | ✅ ~147 tok/s
  Q4     16.8G  17.6G  | ✅ ~330 tok/s      | ✅ ~587 tok/s      | ✅ ~262 tok/s

스크립트의 EFFICIENCY = 0.55는 경험적 보정 계수입니다. 실제 환경에서 mlx_lm.generate --verbose 또는 vLLM 로그의 tok/s를 측정한 뒤 이 값을 조정하면 예측 정확도가 올라갑니다.

하드웨어 정보 확인 명령어

자신의 장비 스펙을 확인할 때 사용하는 명령어입니다.

# ── macOS (Apple Silicon) ──
# 칩 / 메모리 확인
system_profiler SPHardwareDataType | grep -E "Chip|Memory"

# 총 메모리 (바이트)
sysctl -n hw.memsize

# Metal GPU 정보
system_profiler SPDisplaysDataType | grep -A5 "Metal"


# ── Linux (NVIDIA GPU) ──
# GPU 이름, VRAM 총량, 사용 가능 VRAM
nvidia-smi --query-gpu=name,memory.total,memory.free \
           --format=csv,noheader

# GPU 간 토폴로지 (NVLink 여부 확인)
nvidia-smi topo -m

# CUDA 버전
nvcc --version

# vLLM에서 사용 가능한 GPU 확인
python -c "import torch; print(torch.cuda.device_count())"

운영 함정 (Pitfall) — Mac Studio의 OOM은 조용히 온다

함정: Mac Studio에서 대형 모델을 올릴 때 “어차피 192 GB니까 넉넉하겠지”라고 방심하면 OS가 예고 없이 프로세스를 죽입니다(OOM kill).

원인: Apple Silicon의 통합 메모리는 GPU 전용이 아닙니다. macOS 커널, 시스템 서비스, 디스플레이 프레임버퍼, Finder, Spotlight 인덱싱 등이 동시에 메모리를 점유합니다. 192 GB 시스템에서 실제로 LLM에 할당 가능한 메모리는 160~170 GB 수준입니다. 여기에 KV 캐시가 컨텍스트 길이에 비례해서 커지므로, 긴 대화가 이어지면 메모리가 점진적으로 차오릅니다.

NVIDIA GPU에서는 VRAM OOM이 발생하면 torch.cuda.OutOfMemoryError가 즉시 발생하고, vLLM이 이를 잡아서 요청을 거부합니다. 로그에 명확하게 남습니다. 반면 macOS의 메모리 압축기(memory compressor)는 메모리 부족을 최대한 늦게까지 숨기다가, 임계점을 넘으면 Jetsam(iOS/macOS OOM 킬러)이 프로세스를 강제 종료합니다. 로그는 /var/log/system.log에 남지만, 터미널에는 아무 에러 없이 프로세스가 사라집니다.

대응:

• 모델 로딩 후 memory_pressure 명령으로 시스템 여유 메모리를 확인합니다.
• KV 캐시 최대 토큰 수를 명시적으로 제한합니다(mlx-lm의 --max-kv-size 옵션).
• 총 모델 가중치 + 예상 KV 캐시가 물리 메모리의 85%를 넘지 않도록 여유를 둡니다.
• 배포 시 watchdog 프로세스를 두어, mlx-lm 서버가 죽으면 자동 재시작하도록 구성합니다(launchd plist 또는 crontab).

# macOS 메모리 압력 확인
memory_pressure
# 출력 예: "System-wide memory free percentage: 23%"
# → 이 값이 15% 아래로 떨어지면 Jetsam 개입 위험

# mlx-lm KV 캐시 제한 (32K 토큰으로 상한 설정)
mlx_lm.server --model mlx-community/Qwen3-30B-A3B-4bit \
              --max-kv-size 32768 \
              --port 8080

4회·5회 분기점 — 내일부터 두 트랙

오늘 3회에서 두 트랙의 구조적 강약점을 비교하고, 모델별 최적 하드웨어 매핑을 그렸습니다. 내일부터는 각 트랙을 깊이 있게 실습합니다.

• 4회 (내일): MLX로 Qwen3 서빙하기 — mlx-lm 설치, 모델 로드, OpenAI 호환 엔드포인트 구성, 통합 메모리 활용 한계, 동시성·지연 실측 결과까지. Apple Silicon 사용자를 위한 완전한 핸즈온.
• 5회: vLLM으로 Qwen3 서빙하기 — PagedAttention·continuous batching 실전, FP8 양자화 적용, 텐서 병렬, KV 캐시 튜닝, 실제 운영 장애 케이스와 안정화 패턴. NVIDIA 사용자를 위한 핸즈온.

두 회차를 읽고 나면, 6회에서 두 트랙을 하나의 하이브리드 게이트웨이로 통합합니다. 오늘 그린 하이브리드 아키텍처 다이어그램이 실제 동작하는 시스템으로 구현되는 과정입니다.

내일 예고 — 4회: mlx-lm으로 Qwen3-30B-A3B를 Mac Studio에 올리고, 첫 번째 토큰이 나오기까지의 전체 과정을 코드와 함께 걸어갑니다. “설치 → 로드 → 서빙 → 벤치마크”까지 15분 핸즈온.