MoE 모델과 전문가 병렬의 실전 운용

"큰데 가벼운" 모델이라는 착각

MoE, 즉 Mixture of Experts 모델을 처음 보면 이상한 숫자가 눈에 들어옵니다. DeepSeek-R1은 전체 파라미터가 671B, 즉 6,710억 개 수준인데 토큰 하나를 처리할 때 활성화되는 파라미터는 약 37B라고 알려져 있습니다. Qwen 계열 MoE에서도 "35B-A3B"처럼 전체는 350억 개지만 실제 계산에 참여하는 양은 30억 개 수준이라는 식의 표기를 볼 수 있습니다. 숫자만 보면 이런 생각이 듭니다.

"활성 파라미터가 37B라면, 70B Dense 모델보다 가볍게 돌릴 수 있는 것 아닌가?"

절반만 맞는 말입니다. 계산량 관점에서는 맞습니다. 그러나 VRAM 관점에서는 조심해야 합니다. MoE 모델은 매 토큰마다 일부 expert만 사용하지만, 어떤 expert가 선택될지는 라우터가 입력을 보고 결정합니다. 즉, 추론 중에는 여러 expert가 언제든 선택될 수 있어야 합니다. 그래서 빠른 GPU 추론을 하려면 대부분의 경우 전체 expert 가중치가 VRAM 또는 적어도 GPU가 빠르게 접근할 수 있는 메모리 공간에 올라가 있어야 합니다. MoE가 "계산은 sparse"하지만 "메모리는 dense에 가깝게" 요구하는 이유가 여기에 있습니다.

MoE 모델은 일반적인 Dense 모델처럼 모든 토큰이 같은 FFN을 통과하지 않습니다. 토큰은 먼저 attention 블록을 지나고, 그다음 라우터 또는 게이팅 네트워크가 "이 토큰은 몇 번 expert와 몇 번 expert에게 보내자"라고 결정합니다. 선택된 expert의 출력은 다시 가중합되어 다음 레이어로 넘어갑니다. NVIDIA는 MoE를 설명하면서 expert, expert sparsity, gating network, output combination을 핵심 구성 요소로 정리합니다.¹

이 구조 덕분에 MoE는 거대한 지식 저장고를 갖고 있으면서도 매 토큰의 계산량은 줄일 수 있습니다. 하지만 멀티 GPU에서 MoE를 다룰 때는 단순히 "TP를 몇으로 줄까?"만 고민해서는 부족합니다. expert를 어디에 둘지, 토큰을 어떻게 보내고 다시 모을지, 인기 expert가 한 GPU에 몰리지 않게 할지까지 함께 설계해야 합니다.

라우터, expert, top-k를 메모리 관점에서 보기

MoE 레이어를 작은 택배 분류장으로 상상해봅시다. 입력 토큰은 택배 상자입니다. 라우터는 상자에 붙은 주소를 읽고 어느 expert 창구로 보낼지 결정하는 분류기입니다. expert는 각자 다른 종류의 작업에 특화된 창구입니다. 어떤 토큰은 수학 창구로, 어떤 토큰은 코드 창구로, 어떤 토큰은 일반 언어 창구로 향합니다. 물론 실제 모델의 expert가 이렇게 명확한 이름표를 갖는 것은 아니지만, 학습 과정에서 특정 패턴에 더 민감하게 반응하는 방향으로 역할이 나뉘는 경향이 있습니다.

여기서 중요한 개념이 top-k 활성화입니다. 라우터는 모든 expert를 다 쓰지 않고 점수가 높은 k개의 expert만 고릅니다. Mixtral 8x7B처럼 8개 expert 중 2개를 고르는 구조도 있고, DeepSeek 계열처럼 훨씬 많은 expert 중 일부를 고르는 구조도 있습니다. k가 2라면 각 토큰은 두 expert로 보내지고, k가 8이라면 여덟 expert로 보내집니다.

이때 전체 파라미터와 활성 파라미터의 차이가 생깁니다. 전체 파라미터는 모델 파일에 들어 있는 모든 가중치입니다. 활성 파라미터는 토큰 하나가 forward pass에서 실제로 사용한 가중치입니다. 추론 비용을 계산할 때 이 둘을 구분하지 않으면 판단이 흔들립니다.

VRAM을 잡아먹는 주된 항목은 다음과 같이 나눌 수 있습니다.

• 모델 가중치: attention, embedding, router, shared expert, routed expert 등 모델 자체의 파라미터입니다.

• KV 캐시: 이전 토큰들의 key와 value를 저장해 다음 토큰 생성 때 attention 계산을 줄이는 메모리입니다.

• 런타임 버퍼: 라우팅 결과, 토큰 재배열, all-to-all 통신 버퍼, GEMM 작업 공간, CUDA graph용 임시 공간 등이 포함됩니다.

MoE에서 "활성 파라미터가 작다"는 말은 주로 계산량에 유리하다는 뜻입니다. 하지만 모델 가중치 전체가 작아진다는 뜻은 아닙니다. vLLM 문서도 메모리 부족과 KV 캐시 preemption을 설명하면서, tensor parallel size나 pipeline parallel size를 늘리면 모델 가중치가 분산되어 KV 캐시 공간을 더 확보할 수 있지만 동기화나 지연 비용이 생긴다고 설명합니다.² MoE 모델에서는 여기에 expert 배치와 토큰 라우팅 비용이 추가됩니다.

DeepSeek-R1 같은 대형 MoE가 특히 흥미로운 이유는 이 차이가 극단적으로 크기 때문입니다. 공개적으로 자주 인용되는 DeepSeek-R1의 구조는 전체 671B 파라미터, 토큰당 약 37B 활성 파라미터입니다.³ 계산량만 보면 37B급처럼 보이지만, 가중치를 저장하는 쪽에서는 671B급 모델을 상대해야 합니다. 그래서 "MoE니까 VRAM을 적게 쓴다"는 말은 위험한 단순화입니다. 실제로 많은 VRAM 계산기와 배포 가이드는 MoE 모델도 빠른 추론을 위해 전체 expert 가중치를 메모리에 둬야 한다고 경고합니다.⁴

MoE의 병목은 어디에서 생기는가

Dense 모델의 멀티 GPU 병목은 비교적 익숙합니다. 레이어 내부 행렬을 나누면 GPU 사이에 reduce나 gather가 필요합니다. 레이어를 나누면 pipeline bubble이 생깁니다. 요청을 복제하면 메모리는 더 들지만 처리량이 늘어납니다.

MoE는 여기에 한 가지 복잡한 동작을 더합니다. 토큰이 expert가 있는 GPU로 이동해야 합니다. 토큰이 expert에서 계산된 뒤 다시 원래 순서에 맞게 모여야 합니다. 이 과정에서 all-to-all 통신이 자주 등장합니다. all-to-all은 이름 그대로 여러 GPU가 서로에게 데이터를 흩뿌리고 다시 받는 통신입니다. 한두 번이면 괜찮지만, MoE 레이어가 수십 개 있고 decode 단계에서 토큰을 하나씩 계속 생성한다면 이야기가 달라집니다.

MoE 추론의 한 스텝은 대략 이렇게 움직입니다. 먼저 attention을 계산합니다. 라우터가 각 토큰의 expert 선택 결과를 만듭니다. 토큰을 expert별로 묶습니다. expert가 다른 GPU에 있으면 토큰을 보냅니다. 각 GPU는 자신이 가진 expert에 해당하는 토큰 묶음을 GroupGEMM 같은 방식으로 계산합니다. 마지막으로 결과를 다시 원래 GPU 또는 다음 레이어가 기대하는 위치로 모읍니다.

이 흐름에서 성능을 흔드는 병목은 대체로 세 가지입니다.

첫째, expert 가중치 로딩 압박입니다. 한 GPU가 너무 많은 expert를 들고 있으면, 각 expert의 가중치를 on-chip 메모리와 캐시에 올리는 비용이 커집니다. NVIDIA의 Wide-EP 설명은 대규모 expert parallelism이 GPU당 expert 수를 줄여 weight-loading 압박을 낮추고 GroupGEMM의 효율을 높일 수 있다고 설명합니다.⁵

둘째, 토큰 이동 비용입니다. expert가 여러 GPU에 흩어질수록 토큰 dispatch와 combine에 필요한 통신이 늘어납니다. 특히 decode 단계는 한 번에 처리하는 토큰 수가 적어지기 쉬워 통신 지연이 더 도드라질 수 있습니다.

셋째, load imbalance입니다. 모든 expert가 똑같이 인기 있는 것은 아닙니다. 어떤 expert는 특정 프롬프트나 도메인에서 자주 선택되고, 어떤 expert는 거의 선택되지 않습니다. 인기 expert가 한 GPU에 몰리면 그 GPU는 바쁘고 다른 GPU는 놀게 됩니다. 이른바 hot expert 문제입니다.

왜 TP만으로는 부족한가

이전 장에서 vLLM을 사용해 단일 노드 멀티 GPU 서빙을 다루었다면, 자연스럽게 "그럼 MoE도 tensor parallel size를 GPU 수만큼 주면 되는 것 아닌가?"라는 생각이 들 수 있습니다. 작은 MoE나 단순 테스트에서는 실제로 그렇게 시작해도 됩니다. 그러나 DeepSeek 계열처럼 expert 수가 많고 활성 expert 수가 큰 모델에서는 TP만으로는 아쉬운 장면이 나옵니다.

TP는 레이어의 행렬 연산을 여러 GPU로 쪼갭니다. attention projection, MLP projection 같은 큰 행렬을 분할하는 데 강합니다. Dense 모델에서는 이 방식이 직관적입니다. 모든 토큰이 모든 레이어를 지나가기 때문입니다. 하지만 MoE 레이어에서는 모든 expert를 모든 GPU가 조금씩 나눠 갖는 방식이 항상 효율적이지 않습니다.

예를 들어 TP=8로 MoE 모델을 올렸다고 합시다. 각 expert의 가중치가 8개 GPU에 쪼개져 있으면, 어떤 토큰이 expert 42로 라우팅될 때도 8개 GPU가 모두 그 expert 계산에 참여해야 합니다. 토큰 수가 충분히 많고 GPU 사이가 NVLink로 빠르게 연결되어 있으면 괜찮을 수 있습니다. 하지만 decode 단계에서 배치가 작거나 expert 선택이 흩어지면, 작은 계산을 위해 매번 여러 GPU가 동기화하는 모양이 됩니다. 계산량은 줄었는데 통신은 촘촘해지는 역전 현상이 생길 수 있습니다.

또 다른 문제는 KV 캐시입니다. attention 부분은 MoE가 아니라 Dense transformer와 비슷하게 동작합니다. 일부 구현에서는 병렬 그룹을 어떻게 구성하느냐에 따라 KV 캐시가 복제되거나, 반대로 너무 잘게 shard되어 통신 비용이 커질 수 있습니다. DeepSeek 계열은 Multi-head Latent Attention처럼 KV 캐시를 줄이는 구조를 사용해 이 부담을 완화하지만, 그렇다고 병렬화 선택이 사라지는 것은 아닙니다. KV 캐시는 요청 수, 컨텍스트 길이, batch 크기에 따라 빠르게 커지며, vLLM에서도 KV 캐시 부족 시 preemption과 recomputation이 발생할 수 있다고 설명합니다.²

TP만 쓰는 전략은 다음 상황에서 특히 불리해질 수 있습니다. expert 수가 많고 top-k가 큰데 GPU 간 연결이 PCIe 중심일 때, decode batch가 작아 all-reduce와 all-to-all의 고정 지연이 두드러질 때, 그리고 모델 가중치 분산으로 확보한 VRAM을 KV 캐시가 금방 다시 채워버릴 때입니다. 이럴 때는 expert 자체를 나누는 EP를 함께 고려해야 합니다.

EP는 expert를 "모델 안의 작은 서버들"처럼 배치한다

Expert Parallelism, 줄여서 EP는 expert를 GPU들에 나눠 배치하는 전략입니다. TP가 하나의 행렬을 여러 GPU가 함께 계산하는 방식이라면, EP는 expert 단위로 "이 expert들은 0번 GPU, 저 expert들은 1번 GPU"처럼 배치합니다. 토큰은 라우터의 선택에 따라 해당 expert가 있는 GPU로 이동합니다.

DeepSpeed-MoE는 MoE 추론에서 non-expert 파라미터에는 data parallelism과 tensor slicing을, expert 파라미터에는 expert parallelism과 expert slicing을 조합한다고 설명합니다.⁶ 이 구분이 핵심입니다. MoE 모델에는 두 종류의 몸체가 있습니다. 하나는 attention, embedding, router, shared layer처럼 모든 토큰이 지나가는 공통 부분입니다. 다른 하나는 선택된 토큰만 지나가는 expert 부분입니다. 두 몸체를 같은 방식으로만 쪼개면 손해가 생깁니다.

EP를 쓰면 전체 expert 가중치를 여러 GPU의 VRAM에 나눠 담을 수 있습니다. GPU당 expert 수가 줄어들기 때문에 메모리 압박이 낮아지고, 특정 expert에 모인 토큰을 한 번에 묶어 GroupGEMM으로 처리하기 쉬워집니다. NVIDIA NeMo Automodel 자료에서도 DeepEP token dispatcher와 GroupedGEMM을 MoE 확장의 핵심 최적화로 설명합니다. DeepEP는 효율적인 all-to-all과 토큰 permutation 융합을 목표로 하고, GroupedGEMM은 여러 expert 계산을 묶어 GPU 활용률을 높이는 방식입니다.⁷

하지만 EP가 만능은 아닙니다. expert가 멀리 흩어질수록 토큰을 보내고 받는 비용이 커집니다. 따라서 EP는 GPU 간 연결이 빠를수록 빛납니다. 같은 서버 안의 NVLink, HGX/HGX B200, GB200 NVL72 같은 고대역폭 도메인에서는 훨씬 유리합니다. 반대로 PCIe만 있는 소비자용 멀티 GPU 워크스테이션에서는 EP의 통신 비용이 계산 절감 효과를 잡아먹을 수 있습니다.

DP+EP, TP+EP, Hybrid ETP, Wide-EP 비교

MoE 모델을 여러 GPU에 올릴 때 자주 만나는 조합은 DP+EP, TP+EP, Hybrid ETP, Wide-EP입니다. 이름만 보면 복잡하지만, 질문은 단순합니다. "공통 부분은 어떻게 나누고, expert는 어떻게 나눌 것인가?"입니다.

DP+EP는 처리량을 늘리고 싶을 때 자연스럽습니다. 예를 들어 16개 GPU가 있고, 모델 하나를 8개 GPU EP로 구성할 수 있다면, 8GPU짜리 replica를 2개 만들어 요청을 나눠 받을 수 있습니다. 각 replica 안에서는 expert가 분산되고, replica 사이에는 요청 단위 병렬성이 생깁니다. 사용자가 많고 요청이 계속 들어오는 API 서버에 잘 맞습니다.

TP+EP는 모델의 공통부도 큰 경우에 필요합니다. DeepSeek-R1처럼 전체 모델이 매우 크고 attention 및 shared 부분도 만만치 않다면, expert만 나눠서는 부족할 수 있습니다. 이때 attention은 TP로 나누고, MoE 레이어는 EP로 나눕니다. vLLM 문서에 따르면 enable_expert_parallel=True를 설정하면 MoE 레이어에 대해 tensor parallel 대신 expert parallel을 사용하며, 병렬도는 설정된 tensor parallel 크기를 기준으로 동작합니다.² 또한 data parallel과 결합할 경우 MoE layer sharding이 TP와 DP 크기의 곱에 따라 달라질 수 있으므로, 단순히 플래그 하나만 켜고 끝내기보다 실제 GPU 그룹 구성을 확인해야 합니다.

Hybrid ETP는 expert tensor parallelism을 섞는 방식으로 이해하면 됩니다. expert 하나가 크거나, expert 수보다 GPU 수가 많거나, 특정 모델 구조상 expert를 통째로 한 GPU에 두는 것이 비효율적일 때 사용합니다. DeepSpeed-MoE의 expert slicing 개념도 이런 상황과 맞닿아 있습니다. expert 수보다 GPU 수가 많으면 expert 자체를 세로 또는 가로로 더 쪼개야 GPU를 놀리지 않을 수 있습니다.⁶

Wide-EP는 최근 대형 MoE 추론에서 특히 주목받는 방향입니다. NVIDIA는 TensorRT-LLM Wide-EP를 설명하면서 DeepSeek-R1처럼 256개 expert와 671B 파라미터를 가진 모델을 다룰 때, expert를 넓은 GPU 도메인에 분산해 GPU당 expert 수를 줄이고 weight-loading 병목을 완화한다고 설명합니다.⁵ 단, Wide-EP가 제대로 작동하려면 GPU 사이의 통신망이 아주 빨라야 합니다. NVL72처럼 랙 전체가 하나의 거대한 NVLink 도메인처럼 움직이는 환경을 겨냥한 이유가 여기에 있습니다.

hot expert는 조용히 처리량을 무너뜨린다

MoE를 처음 올렸을 때 벤치마크가 기대보다 낮다면, 단순히 "GPU가 느린가?"라고 생각하기 쉽습니다. 하지만 MoE에서는 특정 expert가 지나치게 많이 선택되는 hot expert 문제가 자주 숨어 있습니다.

라우터는 모든 expert를 균등하게 선택하지 않습니다. 자연어 입력은 균등하지 않고, 사용자의 서비스 트래픽도 균등하지 않습니다. 코딩 서비스라면 코드 관련 expert가 자주 선택될 수 있고, 수학 풀이 서비스라면 특정 reasoning 패턴을 담당하는 expert가 자주 선택될 수 있습니다. 만약 인기 expert 여러 개가 같은 GPU에 배치되어 있다면 그 GPU만 줄이 길게 늘어섭니다. 나머지 GPU는 계산할 토큰이 없어 기다립니다.

이 현상은 평균 GPU 사용률만 보면 잘 보이지 않을 수 있습니다. 전체 평균은 60~70%인데 p95 latency가 튀는 식으로 나타납니다. decode 단계에서는 더 심각합니다. 한 토큰씩 순차 생성해야 하므로, 한 레이어에서 hot expert GPU가 늦어지면 전체 토큰 생성이 멈춥니다. 가장 느린 GPU가 전체 속도를 결정하는 셈입니다.

해결책은 크게 세 방향입니다.

• expert load balancing: 라우터 학습 또는 serving 시점의 expert 배치를 조정해 expert별 토큰 수를 균등하게 만듭니다.

• expert replication: 인기 expert를 여러 GPU에 복제해 요청을 나눠 처리합니다.

• expert remapping: 실제 트래픽 통계를 보고 hot expert와 cold expert를 섞어 GPU별 부하를 평평하게 만듭니다.

NVIDIA의 Wide-EP 자료는 Expert Parallel Load Balancer가 hot expert와 cold expert가 한쪽에 몰리지 않도록 expert-to-GPU mapping을 재분배한다고 설명합니다. 정적 방식은 과거 트래픽을 기반으로 배치를 미리 정하고, 온라인 방식은 실행 중 트래픽 변화에 맞춰 expert 배치를 조정합니다.⁵

expert replication은 매우 현실적인 카드입니다. 모든 expert를 균등하게 한 번씩만 배치하는 대신, 자주 선택되는 expert를 두 개 이상의 GPU에 복제합니다. 그러면 hot expert로 가는 토큰을 여러 GPU로 분산할 수 있습니다. 대신 복제한 만큼 VRAM을 더 씁니다. MoE 운용의 전형적인 교환입니다. VRAM을 아끼면 통신과 지연이 늘고, 지연을 줄이면 VRAM을 더 씁니다.

all-to-all은 MoE의 고속도로다

MoE에서 all-to-all 통신은 피할 수 없는 고속도로입니다. 문제는 고속도로가 막히면 아무리 좋은 GPU를 써도 차가 움직이지 않는다는 점입니다.

토큰 dispatch는 expert별로 토큰을 묶어 해당 expert가 있는 GPU로 보내는 과정입니다. combine은 계산이 끝난 출력을 다시 원래 순서에 맞게 모으는 과정입니다. 이 둘이 매 MoE 레이어마다 발생합니다. 레이어가 많고 top-k가 크고 batch가 클수록 이동량은 커집니다. 반대로 batch가 너무 작으면 이동량은 작아도 통신 호출의 고정 지연이 부담됩니다.

그래서 MoE 서빙에서는 "큰 batch가 항상 좋다" 또는 "작은 batch가 항상 빠르다"라고 말하기 어렵습니다. prefill 단계는 입력 토큰이 많아 계산량이 크고 GPU를 채우기 쉽습니다. decode 단계는 토큰을 하나씩 만들기 때문에 메모리 대역폭과 통신 지연에 민감합니다. MoE에서는 decode 단계의 expert dispatch가 특히 까다롭습니다.

TensorRT-LLM과 NVIDIA Blackwell 관련 자료는 DeepSeek-R1 추론 성능 향상 요인 중 하나로 all-to-all 통신 primitive 최적화를 언급합니다. 특히 receiver 쪽 중간 버퍼를 줄이는 식의 낮은 수준 최적화가 실제 처리량에 큰 영향을 줄 수 있습니다.⁸ 이 말은 반대로, 일반적인 분산 통신만으로는 대형 MoE의 잠재 성능을 끌어내기 어렵다는 뜻이기도 합니다.

소비자용 워크스테이션에서는 여기서 냉정해져야 합니다. RTX 4090 두 장이나 네 장을 PCIe로 연결한 환경은 총 VRAM은 늘어나지만, NVLink가 있는 데이터센터 GPU 서버와 같은 통신 특성을 기대하기 어렵습니다. expert를 너무 잘게 흩뿌리면 PCIe 왕복이 병목이 됩니다. 이런 환경에서는 EP를 공격적으로 키우기보다, 양자화로 모델을 줄이고, 가능한 한 GPU 간 이동을 줄이며, batch와 context를 현실적으로 잡는 편이 더 나을 때가 많습니다.

vLLM에서 MoE 병렬 옵션을 고를 때

vLLM은 MoE 모델을 비교적 쉽게 시작할 수 있게 해줍니다. 핵심은 --enable-expert-parallel입니다. 기본적으로 vLLM의 tensor parallel은 MoE 레이어에도 영향을 줄 수 있지만, expert parallel을 켜면 MoE 레이어는 expert 단위 분산을 사용합니다. 문서상 EP는 MoE 모델, 예를 들어 DeepSeekV3, Qwen3MoE, Llama-4 같은 모델에 적합하며, 설정한 tensor parallel 크기와 같은 병렬도를 사용합니다.²

가장 단순한 단일 노드 예시는 다음과 같습니다.

vllm serve deepseek-ai/DeepSeek-V3 \
  --tensor-parallel-size 8 \
  --enable-expert-parallel \
  --gpu-memory-utilization 0.90 \
  --max-model-len 32768

이 명령이 항상 최적이라는 뜻은 아닙니다. 출발점일 뿐입니다. 실제로는 모델 구조와 GPU 수를 먼저 맞춰봐야 합니다. 확인해야 할 것은 다음과 같습니다.

• expert 수가 GPU 수 또는 TP×DP 크기와 어떻게 나누어지는가

• top-k가 몇이며, 토큰 하나가 동시에 몇 expert로 흩어지는가

• shared expert가 있는가, 있다면 shared expert가 어느 GPU에 어떻게 배치되는가

• attention 구조가 MLA, GQA, MHA 중 무엇이며 KV 캐시 요구량이 어느 정도인가

• FP8, INT8, INT4, AWQ, GPTQ 등 사용할 quantization을 엔진이 해당 모델 구조에서 안정적으로 지원하는가

• GPU 간 연결이 NVLink인지 PCIe인지, 멀티 노드라면 InfiniBand/RDMA가 준비되어 있는가

vLLM에서 data parallel까지 결합하면 처리량 확장에 유리합니다. 예를 들어 16개 GPU가 있고 모델을 8GPU EP로 올릴 수 있다면, DP=2로 두 replica를 구성하는 식입니다. 그러나 vLLM 문서가 설명하듯 DP는 전체 모델 replica를 여러 GPU 집합에 복제해 서로 다른 batch를 처리하는 방식입니다.² replica가 늘면 KV 캐시도 replica별로 필요합니다. "GPU가 두 배니까 무조건 동시 사용자 두 배"가 아니라, 각 replica가 확보할 수 있는 KV 캐시 공간과 요청 길이 분포를 같이 봐야 합니다.

MoE 모델에서 vLLM을 튜닝할 때는 max_num_batched_tokens, max_num_seqs, gpu_memory_utilization, max_model_len을 함께 조정해야 합니다. 긴 컨텍스트를 크게 잡으면 KV 캐시 예약량이 늘어 동시 요청 수가 줄어듭니다. 반대로 동시 요청을 늘리면 hot expert와 all-to-all 트래픽이 증가할 수 있습니다. MoE는 모델이 sparse하다고 해서 서빙 시스템 전체가 자동으로 가벼워지지 않습니다.

TensorRT-LLM에서 MoE를 고를 때

TensorRT-LLM은 NVIDIA GPU, 특히 Hopper와 Blackwell 계열에서 MoE 추론을 강하게 최적화하려는 경우 중요한 선택지입니다. vLLM이 비교적 빠른 실험과 범용 서빙에 강하다면, TensorRT-LLM은 엔진 빌드, kernel 최적화, FP8/NVFP4, all-to-all 최적화, disaggregated serving 같은 NVIDIA 스택과 맞물릴 때 강점을 보입니다.

TensorRT-LLM의 Wide-EP는 특히 랙 스케일 환경을 염두에 둔 전략입니다. NVIDIA는 GB200 NVL72가 72개 Blackwell GPU를 NVLink Switch로 연결해 대형 MoE에 필요한 빈번한 expert 데이터 교환을 처리하도록 설계되었다고 설명합니다.⁸ DeepSeek-R1 같은 모델에서 expert를 넓게 펼치면 GPU당 expert 수가 줄어 GroupGEMM의 weight-loading 부담이 낮아지지만, 그 대신 dispatch와 gather 통신이 폭발할 수 있습니다. NVL72 같은 고대역폭 도메인이 중요한 이유입니다.

TensorRT-LLM 계열을 검토할 때는 다음 질문을 던져야 합니다. 내가 가진 GPU가 FP8 또는 NVFP4를 실질적으로 가속하는가? 모델 checkpoint가 TensorRT-LLM이 기대하는 MoE 구조로 변환 가능한가? expert 수와 GPU 수가 Wide-EP 구성에 적합한가? 운영 환경이 단일 노드인가, 랙 스케일인가, 아니면 여러 노드의 느슨한 클러스터인가? prefill과 decode를 분리하는 disaggregated serving까지 고려할 만큼 트래픽이 큰가?

작은 팀이 4~8개 GPU로 DeepSeek, Mixtral, Qwen MoE를 실험한다면 vLLM으로 시작하는 편이 대체로 빠릅니다. 이미 NVIDIA H100/H200/B200 클러스터가 있고, 일정한 대규모 트래픽을 받으며, latency와 throughput을 끝까지 밀어붙여야 한다면 TensorRT-LLM을 검토할 가치가 큽니다. 특히 Wide-EP는 "GPU가 많으니 한번 켜보자"가 아니라, 통신 토폴로지와 expert load balancing까지 함께 맞춰야 의미가 있습니다.

오프로딩은 구원인가, 마지막 수단인가

MoE는 "선택된 expert만 쓴다"는 특성 때문에 오프로딩과도 잘 어울릴 것처럼 보입니다. 실제로 일부 시스템은 expert를 CPU RAM이나 NVMe에 두고 필요한 expert만 GPU로 가져오는 방식을 연구합니다. MoE-Infinity는 요청 단위 expert 활성화 패턴을 추적해 expert prefetching과 caching을 개선하는 방식으로, 제한된 GPU 자원에서 MoE 서빙 지연을 줄이려는 접근을 제안했습니다.⁹

이 아이디어는 매력적입니다. 모든 expert를 VRAM에 올릴 수 없다면, 자주 쓰는 expert만 GPU에 캐시하고 나머지는 필요할 때 가져오면 됩니다. 특히 한 요청 안에서는 특정 expert 그룹이 반복적으로 선택되는 경향이 있을 수 있어 prefetch가 잘 맞으면 효과가 납니다.

하지만 실전에서는 오프로딩을 "무료 VRAM 확장"으로 보면 안 됩니다. CPU RAM은 VRAM보다 대역폭과 지연에서 불리하고, PCIe 왕복은 decode 단계에서 바로 체감됩니다. NVMe 오프로딩은 더 느립니다. 오프로딩은 모델을 아예 못 올리는 상황에서 가능성을 열어주지만, 실시간 고처리량 서빙에서는 full-GPU 배치보다 불리한 경우가 많습니다.

소비자용 환경에서는 llama.cpp의 CPU-MoE 같은 방식이 흥미로운 선택지가 될 수 있습니다. 16GB나 24GB GPU에서 MoE expert 일부를 CPU RAM에 두고 실행하면, 속도는 떨어져도 더 큰 모델을 맛볼 수 있습니다. 다만 이 책의 주제인 "멀티 GPU로 대형 모델을 효율적으로 구동"한다는 관점에서는 오프로딩보다 먼저 양자화, context 제한, GPU 간 분산, 요청 batch 조정을 검토하는 편이 좋습니다.

모델별로 보는 병렬화 감각

Mixtral 8x7B는 MoE 입문용으로 좋습니다. 전체 파라미터는 8개의 7B expert 때문에 커 보이지만, top-2 라우팅으로 일부 expert만 활성화됩니다. GPU 수가 적어도 구조를 이해하기 쉽고, expert 수가 8개라 expert 배치도 직관적입니다. 다만 작은 MoE라고 해서 통신이 공짜는 아닙니다. 2GPU PCIe 환경에서는 단순 TP가 더 나을 때도 있고, expert를 나누는 것이 이득일 때도 있습니다. 반드시 벤치마크해야 합니다.

Qwen MoE 계열, 예를 들어 35B-A3B 같은 모델은 로컬 사용자에게 MoE의 장단점을 잘 보여줍니다. Q4 기준으로 24GB GPU에 간신히 들어가는 구성에서는 활성 파라미터가 작아 generation 속도는 빠를 수 있지만, KV 캐시와 긴 컨텍스트가 들어오면 VRAM 여유가 거의 사라집니다. Qwen3.6-35B-A3B 자료는 Q4에서 약 21GB 수준, Q8에서 37GB 이상을 요구하며, 1M context에서는 KV 캐시가 추가로 수십 GB까지 늘 수 있다고 설명합니다.¹⁰ 이 숫자는 MoE에서 "활성 파라미터가 작다"는 말과 "VRAM이 넉넉하다"는 말이 전혀 다르다는 사실을 잘 보여줍니다.

DeepSeek-V3/R1 계열은 대형 MoE 운영의 본격적인 영역입니다. 전체 가중치가 매우 크고 expert 수도 많습니다. 단일 8GPU 서버에서는 TP+EP 조합, FP8 또는 저비트 양자화, 짧거나 중간 context 제한, vLLM 또는 TensorRT-LLM 최적화가 필요합니다. 더 큰 처리량과 긴 context, 낮은 p95 latency를 동시에 원한다면 Wide-EP, disaggregated serving, expert load balancing 같은 데이터센터급 전략으로 넘어가야 합니다.

Llama 4 계열처럼 MoE 구조를 도입한 모델도 같은 원리로 봐야 합니다. 이름이 Llama라고 해서 Dense Llama처럼만 접근하면 안 됩니다. expert 수, top-k, shared expert, attention 구조, context window, quantization 지원 여부를 먼저 확인한 뒤 병렬화 전략을 정해야 합니다.

실전 선택 절차

MoE 모델을 멀티 GPU에 올릴 때는 다음 순서로 판단하면 실수가 줄어듭니다.

첫째, 모델 구조를 확인합니다. 전체 파라미터, 활성 파라미터, expert 수, top-k, MoE 레이어 수, shared expert 유무, attention 방식, context 길이를 봅니다. 모델 카드에 "A3B"나 "A17B"처럼 활성 파라미터가 적혀 있어도 전체 가중치 크기를 반드시 따로 확인해야 합니다.

둘째, VRAM 예산을 계산합니다. 가중치 크기만 보지 말고 KV 캐시와 런타임 버퍼를 더합니다. 긴 context를 지원하는 모델일수록 "지원 가능 context"와 "내 서버에서 동시 사용자와 함께 감당 가능한 context"가 다릅니다.

셋째, GPU 연결을 확인합니다. NVLink가 있으면 TP와 EP를 더 적극적으로 쓸 수 있습니다. PCIe만 있다면 expert를 무리하게 흩뿌리는 전략이 오히려 느릴 수 있습니다. 멀티 노드에서는 네트워크가 병렬화 전략의 상한선을 정합니다.

넷째, 작은 병렬도부터 벤치마크합니다. TP만, EP만, TP+EP, DP+EP를 각각 짧은 context와 긴 context, 작은 batch와 큰 batch로 시험합니다. MoE는 요청 분포에 따라 hot expert가 달라지므로, 무작위 프롬프트만으로는 실제 서비스를 대표하지 못합니다.

다섯째, p50보다 p95를 봅니다. MoE의 문제는 평균 속도가 아니라 튀는 지연에서 드러나는 경우가 많습니다. hot expert, all-to-all 지연, KV 캐시 preemption, batch scheduler의 병목은 꼬리 지연을 키웁니다.

작은 결론: MoE는 계산을 아끼지만 시스템을 어렵게 만든다

MoE 모델의 매력은 분명합니다. 전체 파라미터는 거대하게 키워 모델의 지식과 표현력을 확장하면서, 매 토큰의 계산량은 일부 expert만 활성화해 줄입니다. 그래서 DeepSeek-R1, Mixtral, Qwen MoE, Llama 4 계열 같은 모델들이 고성능 open-weight 모델의 중심에 서게 되었습니다.

하지만 MoE는 "공짜로 큰 모델을 쓰는 기술"이 아닙니다. VRAM에는 전체 expert 가중치가 필요하고, 긴 컨텍스트에서는 KV 캐시가 다시 발목을 잡습니다. 멀티 GPU에서는 TP만으로 부족할 수 있고, EP를 쓰면 all-to-all 통신과 hot expert 문제가 따라옵니다. Wide-EP는 강력하지만 고대역폭 interconnect와 load balancing 없이는 성능을 내기 어렵습니다.

실전의 감각은 이렇습니다. 작은 MoE는 vLLM에서 enable_expert_parallel을 켜고 시작해도 됩니다. 중간 규모 MoE는 TP+EP와 DP+EP를 비교하면서 KV 캐시 여유를 확인해야 합니다. DeepSeek급 대형 MoE는 GPU 수보다 GPU 사이의 연결, expert 배치, all-to-all 최적화, hot expert 대응이 더 중요해집니다.

MoE는 모델 구조의 문제가 아니라 시스템 설계의 문제입니다. 이 장을 지나면 이제 질문이 바뀝니다. "GPU 몇 장이면 올라가나요?"에서 "그 GPU들이 얼마나 빠르게 이야기할 수 있나요?"로 말입니다. 다음 장에서는 이 질문을 단일 노드 밖으로 확장해, 멀티 노드 GPU 클러스터에서 대형 언어모델을 어떻게 나눠 실행할지 살펴보겠습니다.

참고

¹NVIDIA Mixture of Experts 개요

²vLLM Optimization and Tuning 문서

³NVIDIA Blackwell 기반 DeepSeek-R1 MoE 추론 성능 설명

⁴APXML VRAM Calculator의 MoE 메모리 설명

⁵NVIDIA TensorRT-LLM Wide Expert Parallelism 설명

⁶DeepSpeed-MoE Inference 튜토리얼

⁷NVIDIA NeMo Automodel의 MoE 병렬화와 DeepEP 설명

⁸NVIDIA TensorRT-LLM 및 Blackwell MoE 최적화 설명

⁹MoE-Infinity: Offloading-Efficient MoE Model Serving

¹⁰Qwen3.6-35B-A3B VRAM 요구량 자료