새로운 오픈웨이트 모델을 보다 보면 이런 문장을 자주 만납니다.
125B total
6B active
여기서 자연스럽게 이런 생각이 듭니다.
그러면 실제로는 6B 모델처럼 가벼운 건가?
절반만 맞습니다.
Active Parameter는 주로 한 token을 처리할 때 실제 계산 경로에 참여하는 파라미터 규모를 설명하는 숫자이지, 모델 전체 weights가 6B라는 뜻은 아닙니다.
Qwen3.8-Flash-Next가 좋은 예입니다.
Qwen3.8-Flash-Next 숫자부터 보겠습니다
공식 자료 기준 main model은 약 125B parameter이고, 여기에 51B N-gram embedding과 4B MTP가 추가됩니다.
한 token을 처리할 때는 main model 기준 약 6B parameter가 activated됩니다.
Main model
125B total
↓
한 token 처리
↓
약 6B activated
왜 이런 일이 가능할까요?
MoE는 모든 Expert를 동시에 쓰지 않습니다
일반적인 dense model은 모든 token이 대부분의 model weight를 거칩니다.
Token
↓
전체 Dense Layer
↓
전체 Dense Layer
↓
...
Mixture-of-Experts(MoE)는 큰 expert pool을 만들어두고 router가 일부 expert만 선택합니다.
┌─ Expert 1
├─ Expert 2 ← 선택
Token → Router ──────────┼─ Expert 3
├─ Expert 4 ← 선택
└─ Expert 5
따라서 모델 전체 capacity는 크게 유지하면서 token당 계산량은 제한할 수 있습니다.
이것이 total parameter와 active parameter가 분리되는 이유입니다.
Total Parameter는 무엇을 말할까?
Total parameter는 모델이 가지고 있는 전체 weight 규모에 가깝습니다.
모델이 더 많은 expert를 가진다면 더 많은 패턴과 기능을 여러 expert에 나눠 저장할 수 있습니다.
하지만 그 weights는 어딘가에 저장돼 있어야 합니다.
그래서 total parameter는:
checkpoint size
GPU/CPU memory
multi-GPU distribution
loading time
storage
와 밀접합니다.
Active Parameter는 무엇을 말할까?
Active parameter는 한 token의 forward pass에서 실제 계산에 참여하는 경로의 크기를 이해하는 데 더 유용합니다.
따라서 다음과 더 관련이 있습니다.
FLOPs / token
추론 compute
일부 latency 특성
training compute
하지만 active parameter만으로 latency를 정확히 예측할 수는 없습니다.
Expert routing, memory bandwidth, communication, batch size, KV cache, parallelism 방식이 모두 영향을 줍니다.
가장 흔한 오해: "6B Active니까 6B GPU 메모리면 된다"
이건 틀린 해석입니다.
125B의 expert weights를 가진 모델이라면, 특정 token이 6B만 계산하더라도 전체 expert weight를 사용할 가능성이 있으므로 weights는 GPU cluster나 CPU memory 등의 저장 계층에 존재해야 합니다.
특히 token마다 다른 expert가 선택될 수 있습니다.
Token A → Expert 2 + 7
Token B → Expert 1 + 9
Token C → Expert 5 + 8
그러므로 active parameter는 모델 weight residency와 동일한 숫자가 아닙니다.
CodeBridge Mini Lab: Weight-only 크기와 Active Compute를 따로 계산해보기
다음 계산은 실제 VRAM 요구량이 아닙니다.
optimizer, activation, KV cache, framework overhead를 모두 제외한 weight-only rough estimate입니다.
def weight_gb(params_billion, bits):
bytes_per_param = bits / 8
return params_billion * 1e9 * bytes_per_param / 1e9
for bits in [16, 8, 4]:
total = weight_gb(125, bits)
active = weight_gb(6, bits)
print(
f"{bits:>2}-bit | "
f"125B total weights ≈ {total:>6.1f} GB | "
f"6B active path ≈ {active:>5.1f} GB-equivalent"
)
BF16/FP16 기준으로만 단순 계산하면:
125B weights
→ 약 250GB
6B worth of parameters
→ 약 12GB
하지만 여기서 두 번째 숫자를 보고 "12GB GPU에서 실행된다"고 결론 내리면 안 됩니다.
12GB는 6B개의 16-bit parameter가 차지하는 weight 크기를 단순 환산한 값일 뿐입니다.
실제 inference 환경은 전체 expert weight 배치 방식과 cache, activation, framework가 결정합니다.
Qwen의 51B N-gram Embedding은 또 다른 층입니다
Qwen3.8-Flash-Next에는 main MoE 외에도 51B N-gram embedding parameter가 있습니다.
흥미로운 점은 lookup 위치를 미리 계산할 수 있어 이 embedding을 host memory에 두고 비동기 prefetch할 수 있도록 설계했다는 것입니다.
즉 모델 용량을 키우는 방식도 하나가 아닙니다.
Dense matrix parameters
MoE expert parameters
Lookup embedding parameters
는 계산 비용과 memory-access 특성이 서로 다릅니다.
그래서 앞으로 모델을 비교할 때 단순한 "총 몇 B"만 보면 놓치는 것이 많아집니다.
2.4T 모델도 같은 원리로 읽을 수 있습니다
Alibaba가 공개한 Qwen3.8-2.4T-A95B는 이름 그대로 약 2.4T total parameter, 약 95B activated라는 구조입니다.
이 숫자를 볼 때도:
2.4T
→ 전체 capacity와 weight storage 규모
95B active
→ token당 선택되는 계산 경로 규모
로 분리해서 읽는 것이 좋습니다.
"2.4T니까 매 token마다 2.4T 계산"도 아니고,
"95B active니까 95B checkpoint"도 아닙니다.
왜 MoE가 계속 커질까?
MoE의 매력은 비교적 직관적입니다.
더 많은 expert
→ capacity 증가
활성 expert 수 제한
→ token당 계산량 억제
Qwen3.8-Flash-Next도 큰 expert pool을 두면서 routed expert 수를 작게 유지하는 ultra-sparse MoE 방식을 사용합니다.
물론 공짜는 아닙니다.
- router가 잘못 선택할 수 있음
- expert load balancing 필요
- multi-GPU 통신 비용
- weight storage 부담
- serving architecture 복잡도
가 따라옵니다.
결론: '몇 B 모델인가?'보다 두 숫자를 같이 보세요
MoE 모델을 볼 때는 최소한 다음을 함께 확인하는 편이 좋습니다.
Total Parameters
Active Parameters
Number of Experts
Experts per Token
Quantization
Context Length
KV Cache 구조
특히 6B active 같은 숫자는 계산 효율을 이해하는 단서이지 모델 전체 크기를 대체하는 숫자가 아닙니다.
그래서 다음부터 "125B인데 6B active"라는 설명을 보면 이렇게 읽으면 됩니다.
125B의 capacity를 가지고 있지만, 한 token을 계산할 때는 그중 일부 경로만 선택한다.