Mixture-of-Experts 라우팅은 로컬 모델의 연산량을 어떻게 바꿀까요?
Mixture-of-Experts 라우팅은 모든 전문가를 활성화하는 대신 각 토큰을 소수의 전문가 피드포워드 네트워크 하위 집합에만 통과시켜 로컬 모델의 연산 방식을 바꿉니다.
따라서 대규모 MoE 모델은 홈 서버에서 독특한 특성을 보입니다. 전체 체크포인트는 매우 클 수 있지만, 한 토큰에 수행되는 전문가 연산은 훨씬 작은 활성 모델과 비슷할 수 있습니다. 장점은 메모리가 공짜로 절약되는 것이 아니라 희소 연산이 가능하다는 데 있습니다. 전문가 가중치는 여전히 저장해야 하며, 여러 장치에 걸친 라우팅은 절약된 연산의 일부를 통신 비용으로 바꿀 수 있습니다.
밀집 트랜스포머는 모든 토큰에 동일한 피드포워드 파라미터를 활성화합니다
일반적인 밀집 트랜스포머 레이어에서는 모든 토큰이 동일한 피드포워드 네트워크를 통과합니다. 따라서 피드포워드 파라미터 수를 늘리면 모델 크기와 각 토큰에 필요한 연산량이 모두 증가합니다.
Switch Transformer는 이를 희소 활성화 Mixture-of-Experts 레이어와 대비합니다. 이 구조에서는 토큰마다 서로 다른 파라미터 하위 집합을 선택할 수 있습니다.
로컬 추론에서는 이것이 MoE의 첫 번째 구분을 만듭니다. 전체 파라미터 수는 저장해야 하는 모델 상태의 양을 결정하고, 활성화된 파라미터 수는 토큰별 전문가 연산량의 상당 부분을 결정합니다.
라우터는 각 토큰을 사용 가능한 전문가와 비교해 점수를 계산합니다
MoE 레이어에서는 작은 라우터가 토큰 표현을 분석해 후보 전문가에 대한 점수 또는 확률을 생성합니다. 그런 다음 런타임이 아키텍처에 따라 일반적으로 top-1 또는 top-k 방식으로 제한된 수의 전문가를 선택합니다.
NVIDIA Megatron Core에는 각 토큰이 전달될 전문가를 결정하는 라우터가 제공됩니다. 이 라우팅 결정에 따라 해당 토큰을 처리할 전문가 행렬이 달라집니다.
따라서 동일한 프롬프트 안의 두 토큰도 어텐션 및 모델의 다른 밀집 부분은 공유하면서 서로 다른 전문가 가중치를 활성화할 수 있습니다.
희소 활성화는 전문가 연산을 줄이지만 전체 가중치 저장량은 줄이지 않습니다
한 레이어에 8명의 전문가가 있고 각 토큰이 2명을 선택한다면, 해당 토큰에 대해서는 선택된 전문가의 연산만 수행됩니다. 나머지 전문가 행렬은 그 단계에서 유휴 상태가 됩니다.
Expert Choice 연구는 MoE가 파라미터 수를 늘리면서도 토큰당 연산량을 비교적 제한된 수준으로 유지한다고 설명합니다. 이 때문에 MoE 체크포인트는 전체 파라미터 수는 매우 크지만 활성 파라미터 수는 훨씬 작다고 표시될 수 있습니다.
런타임이 전문가를 스트리밍하거나 오프로딩하지 않는 한, 홈 서버는 전체 전문가 가중치를 어딘가에서 사용할 수 있도록 준비해야 합니다. 희소 연산은 희소 저장과 같은 의미가 아닙니다.
전문가 배치는 라우팅을 장치 간 통신으로 바꿀 수 있습니다
GPU 한 장에서는 전문가를 선택하는 일이 주로 로컬 가중치 블록 중 어떤 것을 읽을지 바꾸는 데 그칩니다. 여러 GPU에 걸쳐 실행할 때는 전문가가 분산 배치될 수 있으므로, 토큰 표현이 선택된 전문가를 보유한 장치로 이동한 뒤 기본 레이어 흐름으로 돌아와야 할 수 있습니다.
DeepSpeed의 MoE 추론 설계는 GPU 간 전문가 병렬 처리를 사용해 전문가 그룹을 할당합니다. 따라서 라우팅에는 행렬 곱셈뿐 아니라 통신도 포함됩니다.
그러므로 소형 홈 멀티 GPU 서버는 각 토큰의 연산이 희소하더라도 인터커넥트에 의해 성능이 제한될 수 있습니다. PCIe 토폴로지와 피어 투 피어 지원은 활성 파라미터 수만으로 예상하는 것보다 더 중요합니다.
불균형한 라우팅은 특정 전문가에 부하를 몰고 유휴 용량을 만듭니다
실제 프롬프트가 토큰을 반드시 균등하게 분배하는 것은 아닙니다. 많은 토큰이 동일한 전문가를 선택하면 해당 장치나 커널에 병목이 생기는 반면, 다른 전문가들은 대기하게 됩니다.
MoETuner는 불균형한 토큰 라우팅과 전문가 활성화를 실제 서빙 병목으로 지적합니다. 일부 장치에 다른 장치보다 더 많은 라우팅 작업과 통신이 몰릴 수 있기 때문입니다.
로컬 추론에서는 컨텍스트 길이와 모델 크기가 비슷하더라도 프롬프트마다 토큰 지연 시간이 달라지는 형태로 불균형한 라우팅이 나타날 수 있습니다. 모델이 동적으로 서로 다른 연산 경로를 선택하기 때문입니다.
로컬 MoE 용량은 전체 가중치와 활성 경로를 나누어 계획해야 합니다
유용한 하드웨어 추정에서는 전체 모델 가중치 크기, 토큰당 활성 전문가 수, 밀집 레이어 비용, KV 캐시, 양자화 여부, 그리고 전문가가 단일 가속기·여러 GPU·CPU RAM·스토리지 중 어디에 상주하는지를 기록해야 합니다.
ZimaSpace의 로컬 AI 메모리 및 가속기 계획 관련 글은 홈 서버 용량을 이해하는 데 필요한 broader context를 제공합니다. MoE에서는 상주 용량과 활성 연산을 한 번 더 구분해야 합니다.
서로 다른 작업의 프롬프트로 벤치마크를 수행해야 합니다. 라우팅 패턴은 달라질 수 있기 때문입니다. 광고된 활성 파라미터 수가 전체 시스템 성능을 예측한다고 가정하지 말고 초당 토큰 수, 장치별 사용률, 전문가 부하, 통신 트래픽, 메모리 상주 상태를 측정하세요.
특히 대규모 로컬 체크포인트의 경우 ZimaSpace의 대규모 모델 배포 분석이 관련 용량 문제를 다룹니다. 라우팅은 활성 연산량을 바꾸지만, 전체 가중치 상주량과 장치 간 배치가 여전히 모델의 실용성을 결정합니다.
추천 제품
기술 및 AI 허브
더 읽어보기
홈 카메라는 클라우드 시간 서비스 없이 이벤트를 동기화할 수 있나요?
클라우드 없이 카메라 시간을 동기화하는 메커니즘 우선 설명, 공유 리소스의 트레이드오프, 쿼리 팬아웃 관련 자주 묻는 질문 3가지, 그리고 실용적인 검증 프로토콜.
로컬 AI 서비스가 추론 전에 손상된 모델 레이어를 감지할 수 있나요?
손상된 모델 계층 감지에 대한 메커니즘 중심 설명, 공유 리소스의 트레이드오프, 쿼리 팬아웃 관련 자주 묻는 질문 3가지, 그리고 실용적인 검증 프로토콜.
모든 임베딩을 다시 생성하지 않고 RAG 시스템을 복원할 수 있을까요?
재임베딩 없이 RAG를 복원하는 메커니즘 중심 설명, 공유 리소스의 트레이드오프, 쿼리 팬아웃 관련 자주 묻는 질문 3가지, 그리고 실용적인 검증 프로토콜.
