MoE 전문가 라우팅과 부하 균형: 활성 파라미터 기반 추론 설계
MoE 모델의 전문가 라우팅, 활성 파라미터, 부하 균형, 통신 겹치기와 핫 전문가 복제를 실서빙 관점에서 정리한다.
2026-09-02 · 최초 발행 2026-08-05
활성 파라미터가 추론 비용을 결정하는 구조
AMD Instella-MoE-16B-A3B는 총 16B 파라미터 가운데 토큰당 2.8B를 활성화한다. 27레이어에 공유 전문가 2개를 두고, 라우팅 전문가 64개 중 6개를 선택하는 구성이다. 활성 비율은 약 17.5% 수준이다.
희소 활성 구조에서는 총 파라미터를 키우면서도 토큰별 연산량을 억제할 수 있다. 대신 실제 서빙의 처리량은 라우터가 선택한 전문가가 어느 장치에 놓였는지, 그리고 선택이 얼마나 고르게 분산되는지에 따라 달라진다. 특정 전문가에 요청이 몰리면 해당 장치가 전체 경로의 병목이 된다.
Gated Multi-head Latent Attention(Gated MLA)과 FarSkip-Collective는 전문가 병렬 통신을 연산과 겹치도록 결합한다. FarSkip-Collective는 사전학습을 12.7% 가속했고, SGLang 전문가 병렬 구성에서는 첫 토큰 생성 시간을 최대 39.2% 단축했다. 모델은 7.1T 사전학습 토큰으로 학습됐고 컨텍스트는 4K에서 64K로 확장됐으며, 베이스 평균은 76.7이다.
라우팅 분포를 서빙 병목으로 보아야 하는 이유
라우팅 전문가 64개를 장치에 어떻게 나누는지가 부하 분포를 좌우한다. 인접한 인덱스의 전문가를 한 장치에 집중시키면, 함께 활성화되는 경향이 있는 전문가가 같은 장치로 몰릴 수 있다. 학습 과정에서 관측한 공동 활성 패턴을 기준으로 배치하면 균형을 개선할 수 있다. 인덱스 순서대로 배치하는 방법은 최악은 아니지만 최적도 아니다.
학습에는 전문가 사용량을 평탄하게 만들기 위한 부하 균형 손실을 둘 수 있다. 이 항이 없으면 소수 전문가가 대부분의 토큰을 흡수할 수 있다. 반대로 가중치가 너무 크면 라우팅이 지나치게 균일해져 전문화의 이점이 약해진다. 품질과 균형 사이에 조정 지점이 생기는 이유다.
전문가별 처리 용량 상한도 함께 정해야 한다. 상한을 넘은 토큰을 드롭하면 품질이 떨어지고, 초과분을 계속 처리하면 해당 장치가 병목이 된다. 용량 계수를 높이면 드롭은 줄지만 메모리와 연산 여유가 낭비된다. 추론에서는 드롭보다 용량 여유를 확보하는 선택이 일반적이다.
통신 비용과 전문가 배치를 함께 설계하기
전문가 병렬에서는 토큰을 전문가가 있는 장치로 보내고, 계산 결과를 다시 되돌려야 한다. 이 통신은 매 레이어 두 번 발생하며 27레이어에서는 왕복이 54회다. 통신을 다음 연산과 겹치지 못하면 대기 시간이 지연을 지배한다.
노드 간 대역은 처리량 상한을 결정하는 조건이다. 노드 구성을 정하기 전에 대역 요건을 산정해야 하며, 단일 노드에 모든 전문가를 담을 수 있다면 노드 간 통신이 사라지는 구성이 가능한지도 먼저 확인할 필요가 있다.
선택 전문가 수를 늘리면 품질과 함께 토큰당 연산량, 통신량도 증가한다. 활성 파라미터 비율은 모델 품질만의 설정값이 아니라 추론 단가를 정하는 변수다. 공유 전문가는 모든 토큰이 통과하므로, 하나를 추가하는 비용은 라우팅 전문가 하나를 추가하는 비용보다 크다.
계측에서 시작하는 재배치와 복제
라우팅 문제를 모델 품질 문제로 오진하지 않으려면 전문가별 토큰 수, 장치별 대기 시간, 드롭률을 계속 수집해야 한다. 입력 도메인이 바뀌면 라우팅 분포도 달라질 수 있으므로 도메인 태그와 함께 분리 집계한다. 계측 자체가 추론 지연에 영향을 주지 않도록 표본 수집 비율도 정한다.
상위 전문가 점유율이 기준을 넘을 때의 대응은 미리 문서화해야 한다. 사후 분석만으로는 이미 처리량 손실이 발생한 뒤다. 재배치는 서비스 중단을 수반하므로 복제를 우선하고 배치 변경은 후순위로 두는 방식으로 단계를 나눌 수 있다.
지속적으로 사용 빈도가 높은 전문가는 여러 장치에 복제해 요청을 분산할 수 있다. 메모리를 더 사용하지만 병목을 완화한다. 복제 대상은 관측 통계로 골라야 하며, 부하 패턴이 달라지면 다시 선정해야 한다. 복제에 따른 메모리 증가는 용량 계획과 승인 절차에 반영한다.
처리량 목표는 초당 토큰과 첫 토큰 생성 시간을 분리해 둔다. 전문가 병렬 구성은 두 지표에 다르게 작용하며, FarSkip-Collective 유형의 겹치기 최적화 효과는 첫 토큰 생성 시간에서 두드러진다. 입력 분포 변화에 맞춰 분기 단위로 통계를 재검토하고, 모델 교체로 전문가 수나 선택 수가 바뀌면 기존 배치와 복제 구성도 다시 산정한다.
희소 활성과 밀집 모델의 운영상 차이
| 구분 | MoE 희소 활성 | 동급 밀집 모델 |
|---|---|---|
| 토큰당 연산 | 활성 파라미터만 | 전체 파라미터 |
| 메모리 요구량 | 총 파라미터 상주 | 총 파라미터 상주 |
| 노드 간 통신 | 레이어마다 발생 | 거의 없음 |
| 부하 균형 관리 | 필요 | 불필요 |
| 추론 단가 | 낮음 | 높음 |
| 배치 복잡도 | 높음 | 낮음 |
희소 활성은 총 16B 파라미터의 표현력을 유지하면서 토큰당 2.8B만 계산하므로 추론 단가를 낮추고, 같은 예산에서 더 큰 모델을 운용할 수 있다. 그러나 메모리에는 총 파라미터 전체가 상주해야 한다. 절약되는 자원은 메모리가 아니라 연산이다. 가속기 메모리가 제약인 환경에서는 기대한 이득이 나오지 않는다.
동급 밀집 모델은 라우팅이나 통신 스케줄이 없어 배치가 단순하고 처리량 예측도 쉽다. 부하 쏠림이라는 문제도 없다. 반면 토큰마다 전체 파라미터를 연산하므로 비용이 높고, 같은 예산으로 확보할 수 있는 모델 규모가 작다.
공유 전문가를 병용하면 공통 지식이 공유 전문가에 축적되고 라우팅 전문가는 특화된 역할에 집중할 수 있다. 라우팅 분포의 쏠림을 완화하고 라우터 학습을 안정시키는 대신, 공유 전문가는 활성 파라미터 예산에서 고정 비용이 된다. Instella-MoE의 공유 전문가 2개와 라우팅 전문가 6개 조합은 상시 비용을 25% 수준으로 제한하면서 쏠림 완화 효과를 취하는 절충으로 볼 수 있다.
핫 전문가 복제는 병목 완화와 메모리 점유 증가를 맞바꾸는 선택이다. 단일 배치는 메모리 효율이 높고 갱신도 단순하지만, 라우팅이 쏠리면 해당 장치에 전체 처리량이 묶인다. 통계상 부하가 안정적으로 편중됐을 때만 복제가 정당화되며, 계측 없이 선제적으로 복제하면 메모리만 낭비한다.
병렬 처리와 성능 관리에 남는 운영 원칙
전문가 병렬은 데이터 병렬이나 텐서 병렬과 다른 통신 패턴을 가진다. 레이어마다 전량 교환이 발생하므로 대역 요건을 별도로 산정해야 한다. 통신과 연산을 겹치는 방식은 파이프라인 은닉 기법의 적용이며, 겹치기에 실패하면 통신 대기가 임계 경로가 된다.
전체 처리량이 최저 성능 장치에 수렴하는 특성은 병목 이론의 전형적인 사례다. 부하 균형은 부수적인 최적화가 아니라 처리량 관리 자체다. 활성 파라미터 비율과 공유·라우팅 전문가의 구성은 품질 평가와 함께 단가 결정으로 다뤄야 한다.
MoE 모델 사양은 총 파라미터만 적는 방식에서 총·활성 파라미터를 함께 표기하는 흐름으로 바뀌고 있다. 전문가 병렬 통신을 겹치는 최적화는 추론 프레임워크의 기본 기능으로 편입되는 방향이며, 라우팅 부하 통계와 불균형 알림도 서빙 관측 지표의 표준 항목으로 포함되는 흐름이다. 단일 노드에 전문가를 모두 담을 수 있도록 총 파라미터 규모를 설계하려는 경향도 확산되고 있다.
Sources
- Introducing Instella-MoE: A State-of-the-Art Fully Open Mixture-of-Experts Language Model | ROCm Blogs
- AMD Releases Instella-MoE-16B-A3B | MarkTechPost
- Marktechpost on X: Instella-MoE architecture and efficiency
- amd/Instella-MoE-16B-A3B-Base | Hugging Face
- amd/Instella-MoE-16B-A3B-SFT | Hugging Face
- Instella MoE 16B A3B Think | There's An AI For That
- AMD unveils Instella-MoE trained on its own GPUs | GIGAZINE