메모리 역설: VRAM에는 전체, FLOPs에는 활성

37B만 계산해도 671B는 올려야 해

DeepSeek-V3는 전체 671B 가운데 토큰마다 약 37B를 활성화해. 토큰당 연산량은 671B Dense의 약 5.5%지만 필요한 가중치 메모리는 전체 모델에 가까워. 다음 토큰이 어떤 전문가를 고를지 모르므로 서로 다른 671B 가중치를 모두 준비해 둬야 해.

메모리는 왜 활성을 따라 줄지 않을까

라우터의 결정은 입력과 토큰마다 달라. 미리 필요한 전문가만 골라 적재할 수 없어서 모두 대기해야 해. 연산은 선택된 전문가에게만 일어나지만 메모리는 선택될 수 있는 전문가 전체를 품어. 메모리는 닿을 수 있는 것, 연산은 실제로 닿은 것이라고 생각하면 돼.

서빙 비용의 세 축

VRAM 비용은 전체 파라미터를 따라가. 전체 모델을 담을 장비가 필요해.
토큰당 FLOPs는 활성 파라미터를 따라가. 전체 크기가 같은 Dense보다 같은 연산량으로 더 많은 토큰을 처리할 수 있어.
처리량은 배치 구성에도 흔들려. 많은 토큰이 같은 전문가를 고르면 특정 GPU가 몰리고, 선택이 고르게 퍼지면 병렬화가 잘돼.

로컬 운영이 어려운 이유

80GB H100 한 장에는 FP8 DeepSeek-V3가 들어가지 않아. 대략 700GB가 필요하고 4비트 양자화도 약 170GB야. 프런티어급 MoE가 여러 GPU나 여러 노드를 전제로 하는 이유지. 비슷한 토큰당 연산량을 가진 37B Dense라면 H100 한 장의 일부만 써.

가격표도 메모리를 무시하지 않아

API 제공자는 토큰당 FLOPs뿐 아니라 메모리와 장비 활용률을 포함한 전체 서빙 비용으로 가격을 잡아. 671B-A37B가 연산량만 비슷하다고 70B Dense보다 무조건 몇 배 싸지는 않아. 활성 숫자 하나가 아니라 전체 장비 구성을 봐야 해.

Code

MoE 메모리와 연산량 추정·python

def memory_gb_bf16(total_B):           # weights only; +KV cache on top
    return total_B * 2

def memory_gb_fp8(total_B):
    return total_B * 1.0

def memory_gb_int4(total_B):
    return total_B * 0.5

# DeepSeek-V3 has 671B total, ~37B active.
print("BF16:", memory_gb_bf16(671), "GB")  # ~1342 GB
print("FP8:",  memory_gb_fp8(671),  "GB")  # ~671 GB
print("INT4:", memory_gb_int4(671), "GB")  # ~336 GB

# Per-token FLOPs (very rough; just FFN portion)
flops_per_token = 2 * 37 * 1e9             # ~74 GFLOP/token

Exercise

DeepSeek-V3를 BF16, FP8, INT4로 호스팅할 때 필요한 메모리를 계산해. 그다음 80GB H100 한 장, 4장, 8장, 192GB 통합 메모리의 Mac Studio M2 Ultra에 각각 어떤 정밀도가 들어가는지 따져 봐. 이런 냅킨 계산이 아키텍처 문해력의 일상 작업이야.