MoE 모델 고르기, 활성 파라미터로 VRAM·속도·GPU 비용 계산하는 법

모델 카드에 "30B-A3B", "117B 중 5.1B 활성" 같은 숫자가 적혀 있으면 어느 쪽 숫자를 보고 GPU를 사야 할지 헷갈리시죠? 결론부터 말하면 GPU 장수는 전체 파라미터로, 한 사용자가 느끼는 속도는 활성 파라미터로, 많은 요청을 처리할 때의 토큰당 비용은 활성 파라미터의 연산량으로 따로 계산해야 해요. 세 숫자가 서로 다른 비용을 정하기 때문에 하나만 보고 고르면 메모리가 모자라거나 기대한 속도가 안 나와요.

이 글은 라우터 원리 대신 직접 띄울지, 무엇을 띄울지, API를 쓸지 정하는 숫자만 다뤄요. 파일 크기는 Hugging Face 저장소에서 직접 합산했고, 요금은 2026-10-25에 공식 가격표에서 확인했어요.

MoE 모델 숫자 읽는 법 — 전체 파라미터와 활성 파라미터

MoE 모델 이름에는 보통 두 숫자가 들어 있어요. Qwen3-30B-A3B의 30B는 전체, A3B는 토큰 하나당 켜지는(활성) 파라미터예요. 모델 카드에서 직접 확인한 값을 모으면 이래요.

활성 비율(활성 ÷ 전체)로 바꾸면 모델마다 성격이 꽤 달라요.

Mixtral은 4분의 1 넘게 켰지만 최근 모델은 5% 안팎만 켜요. 비율이 낮을수록 "메모리는 큰 모델, 속도는 작은 모델"에 가까워져요.

GPU 메모리는 전체 파라미터로 계산해요

어느 전문가가 불릴지 미리 모르니 모든 전문가가 GPU 메모리에 올라가 있어야 해요. 그래서 VRAM 견적은 전체 파라미터로 내고, 추정식보다 정확한 실제 파일 크기를 써요. Hugging Face 저장소 API로 .safetensors 크기를 합산했어요(10⁹바이트 = 1GB).

여기서 읽을 점이 있어요.

• 양자화 형식이 모델 선택을 바꿔요. gpt-oss-120b는 117B인데 65.2GB이고, Mixtral은 47B인데 bf16이라 93.4GB예요. 파라미터가 두 배 넘게 많은 쪽이 GPU는 덜 먹어요. 모델 카드도 gpt-oss-120b가 H100 같은 80GB GPU 한 장에, gpt-oss-20b는 16GB 메모리 안에서 돈다고 적었어요.
• KV 캐시 몫을 빼고 봐야 해요. H100 SXM은 NVIDIA 사양표 기준 80GB예요. gpt-oss-120b를 올리면 약 15GB가 남고, 여기서 CUDA 그래프·활성값 몫을 빼고 남는 게 KV 캐시예요. 동시 요청 수가 여기서 정해져요. 계산 방법은 vLLM KV 캐시 용량 계산에 정리해 두었어요.
• "딱 맞는" 장수는 피해요. DeepSeek-V4-Flash 159.6GB는 H100 두 장(160GB)에 숫자로는 들어가지만 KV 캐시 자리가 없어요.

GPU 메모리를 GB로 적느냐 GiB로 적느냐에 따라 같은 카드도 숫자가 약 7% 달라 보여요(1GiB = 1.074GB). 파일 크기와 GPU 표기의 단위가 섞이면 데이터 용량 변환기로 1000·1024 기준을 맞춰서 비교하면 헷갈리지 않아요.

응답 속도는 활성 파라미터로 계산해요

토큰을 한 개씩 만드는 디코딩 단계는 대개 메모리 대역폭이 병목이에요. 토큰 하나를 만들 때 필요한 가중치를 메모리에서 읽어 오는 시간이 계산 시간보다 길어요. 그래서 동시 요청이 하나일 때 속도의 이론 상한은 이렇게 잡아요.

초당 토큰 상한 ≈ GPU 메모리 대역폭 ÷ 토큰 하나에 읽는 가중치 바이트

MoE는 토큰마다 고른 전문가만 읽으니 분모에 활성 파라미터가 들어가요. H100 SXM의 대역폭 3.35TB/s, bf16(파라미터당 2바이트)으로 계산하면 이래요.

32B 밀집과 Qwen3-30B-A3B는 메모리가 거의 같은데 상한은 약 10배 차이예요. 지연이 중요한 서비스라면 이게 MoE를 고르는 가장 큰 이유예요.

이 표는 상한이에요. 실제로는 KV 캐시 읽기, 어텐션, 커널 오버헤드가 붙어 더 낮아요. 속도를 더 줄이고 싶다면 MoE 위에 투기적 디코딩을 겹치는 방법도 있는데, 이것도 동시 요청이 적을 때 효과가 커서 성격이 비슷해요.

배치가 커지면 MoE의 속도 이득이 줄어드는 이유

동시 요청을 묶어 처리하면 배치 안 토큰들이 저마다 다른 전문가를 골라요. 한 층에서 어떤 전문가라도 한 토큰이 고르면 그 전문가의 가중치 전체를 읽어야 하니, 배치가 커질수록 "고른 전문가만 읽는다"는 이점이 사라져요.

라우팅이 균등하고 토큰끼리 독립이라고 가정하면, 전문가 E개 중 k개를 고르는 층에서 배치 B개 토큰이 건드리는 전문가 비율의 기댓값은 1 − (1 − k/E)^B 예요. 세 가지 구성으로 직접 계산했어요.

Mixtral은 배치 8이면 전문가 90%를 읽어 47B 밀집 모델과 거의 같아져요. 잘게 쪼갠 Qwen3·DeepSeek 계열도 배치 64면 90% 안팎이에요.

그렇다고 큰 배치에서 MoE가 손해인 건 아니에요. 배치가 커지면 병목이 메모리에서 연산으로 넘어가고, 연산량은 여전히 활성 파라미터에 비례해요. 순전파는 파라미터 하나당 약 2FLOP이라 토큰 하나에 Qwen3-30B-A3B는 약 6.6GFLOP, 32B 밀집은 약 64GFLOP이 들어요. 그래서 정리하면 이래요.

• 동시 요청이 적을 때: 읽는 바이트가 적어 지연 이득
• 동시 요청이 많을 때: 연산이 적어 처리량·비용 이득
• 그 사이 구간: 전문가는 거의 다 읽는데 연산은 놀아서 이득이 가장 작아요. 실제 서비스 부하가 여기 걸리는 경우가 많아요.

여러 장이면 전문가를 장마다 나눠 두는 전문가 병렬도 선택지예요. vLLM 전문가 병렬 배포 문서는 --enable-expert-parallel로 켜고 데이터 병렬과 함께 쓸 때 더 효율적이라고 적었어요. 장 사이 토큰 이동(all-to-all)이 붙으니 한 장에 들어가면 쓸 일이 없어요.

직접 띄울까, API를 쓸까 — 손익분기 토큰 수

자체 GPU는 쓰든 안 쓰든 시간으로, API는 토큰만큼 돈이 나가요. 기준은 "몇 토큰을 처리해야 GPU 월세가 API 요금과 같아지나"예요.

• GPU: Lambda 가격표의 H100 SXM 80GB 1장 시간당 4.29달러, 8장 인스턴스 시간당 31.92달러(세금 별도). 한 달을 730시간으로 잡으면 각각 약 3,132달러, 약 23,302달러예요.
• API: DeepSeek API 가격표의 deepseek-flash 100만 토큰당 단가. 피크(평일 UTC 01~04시·06~10시)는 캐시 미스 입력 0.3달러·출력 1.2달러, 그 외 시간은 절반이에요. 가격표는 이 모델명이 현재 DeepSeek-V4.1-Flash-1017로 서비스된다고 적고 있어요. 공개 가중치 V4-Flash(284B·활성 13B)와 같은 계열이지만 버전은 달라요.

입력:출력을 3:1로 두면 섞은 단가는 피크 (3×0.3 + 1.2) ÷ 4 = 100만 토큰당 0.525달러, 그 외 시간 0.2625달러예요.

월 10억 토큰이면 API는 피크 단가로도 약 525달러라, H100 한 장 월세의 6분의 1이에요.

손익분기는 GPU 월세 ÷ 섞은 단가예요.

• H100 1장: 피크 단가면 월 약 60억 토큰, 24시간 내내 초당 약 2,270토큰이에요. 비피크 단가면 그 두 배(초당 약 4,540토큰)예요.
• H100 8장: 피크 단가면 월 약 444억 토큰, 초당 약 16,900토큰이에요.

이 처리량이 나오는지는 직접 재야 해요. 트래픽이 밤낮으로 출렁이면 평균이 낮아 손익분기가 더 멀어져요. 캐시 적중 입력은 100만 토큰당 0.006달러(피크)라 시스템 프롬프트가 길수록 API가 더 유리해요.

데이터 반출 불가·파인튜닝·버전 고정처럼 비용이 아닌 이유로 직접 띄운다면 손익분기보다 "가진 GPU에 어느 모델이 들어가나"가 먼저예요. 한국어 서비스라면 토크나이저에 따라 같은 글도 토큰 수가 달라서 위 단가 비교가 흔들려요. 한국어 LLM 토큰 비용 비교에서 1,000자당 토큰 수를 먼저 확인해 두세요.

품질 — MoE라서 생기는 차이와 아닌 것

MoE 구조가 품질을 정하지는 않아요. 비교는 "같은 계산(활성)의 밀집 모델보다 낫나"와 "같은 메모리(전체)의 밀집 모델보다 낫나"로 나눠 봐야 해요.

Mixtral 논문은 활성 13B로 Llama 2 70B·GPT-3.5와 모든 평가 벤치마크에서 넘거나 비슷했다고 보고했어요. 다만 옛 모델끼리의 비교라, 지금은 후보를 자기 작업의 평가 세트로 같이 돌려 보는 수밖에 없어요.

MoE를 직접 다룰 때 따로 챙길 점은 이래요.

• 양자화는 배포본 구성을 따라요. gpt-oss·DeepSeek-V4-Flash 공식 배포본은 전문가 가중치만 4비트로 내리고 나머지는 더 높은 정밀도로 남겼어요.
• 파인튜닝은 정규화를 더 세게. Hugging Face의 MoE 해설은 희소 모델이 과적합되기 쉬워 정규화를 더 세게 잡아 볼 만하다고 적었어요.

상황별 추천 — 어떤 MoE를 어디에 띄울까

도입 체크리스트

1. 가중치는 저장소 파일 크기로 확인해요. 양자화 형식에 따라 두세 배 차이가 나요.
2. KV 캐시 몫을 남겨요. 목표 동시 요청 수 × 문맥 길이가 남은 메모리에 들어가는지 계산해요.
3. 엔진 지원을 확인해요. MXFP4·FP4 같은 형식을 쓰는 서빙 엔진 버전과 GPU 세대가 지원하는지 먼저 봐요.
4. 배치 1과 피크 배치에서 둘 다 재요. 토큰 간 지연 p50·p99와 초당 토큰을 기록해요. 한 점만 재면 판단이 틀려요.
5. 손익분기는 하루 평균 처리량과 비교해요. API 단가도 실제 시간대·캐시 적중 비율로 섞어요.
6. 여러 장이면 텐서 병렬과 전문가 병렬을 같은 부하로 비교해요.
7. 품질은 자기 평가 세트로. 후보 MoE와 같은 메모리의 밀집 모델을 함께 돌리고, 양자화 뒤에 다시 돌려요.

자주 묻는 질문

활성 파라미터가 3B면 3B 모델만큼의 GPU로 돌릴 수 있나요?

아니요. 다음 토큰이 어느 전문가로 갈지 미리 알 수 없어서 전체 가중치가 메모리에 올라 있어야 해요. Qwen3-30B-A3B는 활성 3.3B지만 bf16 가중치가 61.1GB예요. 활성 파라미터가 정하는 건 메모리가 아니라 속도와 연산량이에요.

같은 메모리라면 MoE와 밀집 모델 중 무엇이 빠른가요?

동시 요청이 적을 때는 MoE가 크게 빨라요. H100 기준 이론 상한이 32B 밀집은 초당 약 52토큰, Qwen3-30B-A3B는 약 508토큰이에요. 동시 요청이 늘면 배치 안 토큰들이 전문가를 거의 다 읽게 되어 차이가 줄고, 그 뒤로는 연산량 차이로 처리량 이득이 남아요.

gpt-oss-120b는 정말 H100 한 장에 들어가나요?

가중치가 65.2GB라 들어가고, 모델 카드도 80GB GPU 한 장에서 돈다고 적었어요. 다만 KV 캐시 자리가 15GB 미만이라 긴 문맥·많은 동시 요청이면 두 장이 필요할 수 있어요.

API 대신 직접 띄우면 언제부터 싸지나요?

H100 한 장 월세(Lambda 기준 약 3,132달러)를 DeepSeek API 피크 단가로 나누면 입력:출력 3:1에서 월 약 60억 토큰, 하루 종일 초당 약 2,270토큰이에요. 비피크 단가면 그 두 배가 필요해요. 이 처리량을 실제로 낼 수 있는지 재 보고, 낼 수 없으면 API가 싸요.

정리

• GPU 장수는 전체 파라미터(실제 파일 크기)로, 한 명 응답 속도는 활성 파라미터를 읽는 바이트로, 많은 요청의 토큰당 비용은 활성 파라미터의 연산량으로 따로 계산해요.
• MoE의 지연 이득은 동시 요청이 적을 때 가장 커요. 균등 라우팅 가정에서 128개 중 8개를 고르는 모델도 배치 32면 전문가의 87%를 읽어요.
• H100 한 장에 gpt-oss-120b·Qwen3-30B-A3B가 들어가지만 남는 메모리가 15~19GB뿐이에요.
• 직접 띄우는 비용이 API보다 싸지려면 H100 한 장 기준으로도 하루 종일 초당 수천 토큰이 필요해요. 규정상 직접 띄워야 하는 게 아니라면 API부터 견적을 내 보세요.