#MoE는 일부 전문가만 활성화하는데 왜 배포 시 메모리를 많이 먹나

← 전체 목차 · 이전: 메모리를 삼키는 주범 — KV Cache · 다음: 배치 처리로 처리량을 올렸는데 왜 P99 꼬리 지연은 나빠지나

이 문제의 핵심은 계산 희소성(Compute Sparsity)과 저장 희소성(Storage Dense)을 분리해서 말할 수 있는가이다.

각 Token이 소수의 전문가만 거치는 것은 1회 순전파의 계산량을 확실히 줄인다. 그러나 언제든 임의의 전문가로 라우팅할 수 있어야 하므로 배포 노드 또는 전문가 병렬 집합 전체는 여전히 대량의 전문가 가중치를 상주시켜야 한다. 그 위에 주의력 층, 라우터, 활성화, 통신 버퍼, KV Cache의 메모리 비용도 함께 치러야 한다.

즉 "활성화 파라미터가 적다"에서 "단일 카드 메모리가 작다"는 도출되지 않는다.

순전파:  계산 희소 (Compute Sparsity)
  각 Token이 소수의 전문가만 거침 → 이번 순전파의 계산량 감소

모델 저장:  저장은 희소하지 않음 (Storage Dense)
  언제든 다른 전문가로 라우팅할 수 있어야 하므로
  → 배포 노드 / 전문가 병렬 집합 전체가 여전히 대량의 전문가 가중치를 보관

#답변의 출발점은 결론이 아니라 "범위 정의"다

결론을 곧바로 던지는 대신 먼저 범위를 정의하고 네 종류의 점유를 나눠서 계산한다.

평가할 때 대입해야 할 세 입력 차원: 전문가 병렬, 배치(batch), 컨텍스트 길이 (그리고 전문가 분포).

결론: 활성화 파라미터만으로 추산해서는 안 된다.

#입력 조건을 말할 수 있는 예시

예컨대 각 Token이 두 전문가만 고르더라도, 서로 다른 요청이 서로 다른 전문가에 적중하면 **카드 간 이동(cross-card transfer)**과 메모리 피크가 발생한다.

이것이 합격 답안의 형태다 — 입력 조건과 검증 가능한 결과를 설명해야지, 결론 한 줄로 때우면 안 된다.

#가장 밟기 쉬운 함정과 원인 규명 순서

• 함정: 활성화 파라미터가 적다는 것으로 메모리 요구가 작다고 곧바로 추론한다.
• 결과: 멀티테넌트, 롱컨텍스트 시나리오에서 OOM이 발생한다.
• 원인 규명 순서:
  1. 입력, 설정 또는 모델 버전, 중간 결과를 보존한다.
  2. 처음으로 예상에서 벗어난 노드를 먼저 찾는다.
  3. 그다음에 파라미터 조정, 재시도, 다운그레이드 중 무엇을 할지 결정한다.
• 금지 동작: 모델에게 한 번 더 추측하게 하는 것. 어떤 입력 조건도 바꾸지 않으므로 복구 전략이 아니다.

#통신 병목과 메모리 절감 수단의 대가

메모리 절감 수단은 공짜가 아니다.

• 양자화, 전문가 오프로딩 → 메모리를 절약할 수 있다.
• 대가 → 정밀도 손실 또는 지연 증가.

#"매번 전문가 몇 개"만 외우지 말 것

암기식 답변 대신 세 가지를 설명해야 한다.

1. 가중치가 어디에 놓이는가 (가중치 저장 토폴로지)
2. Token이 어떻게 라우팅되는가 (Token 라우팅 전략)
3. 동시성이 올라가면 어느 부분이 먼저 상한에 닿는가 (동시성 병목 분석)

#검증 가능한 결과로 수렴시키기

0. 먼저 고정
   모델 설정 / 입력 길이 / 데이터 버전
1. 대조 실험 1조
   방안 수정 전후 각각 1회 실행
2. 네 가지 변화 비교
   정확성 / 경계 샘플 / 지연 / 메모리 또는 Token 비용

어떤 최적화든 대조가 있어야 한다 — 입력·데이터·버전을 고정하고 주요 변수를 하나만 바꾼 뒤 정확성·지연·비용·리스크 지표를 비교한다.

#핵심 통찰

1. 희소성은 차원별로 나뉜다 — 연산력은 희소해질 수 있지만 저장은 그렇지 않다 — MoE의 Top-k 라우팅은 "이번에 얼마나 계산할까"만 압축했지 "이 기계가 언제든 준비해 두어야 할 양"은 압축하지 않았다. 라우팅이 임의의 전문가를 가리킬 수 있는 한 가중치는 상주해야 하며, 희소성은 저장 차원에서 실효한다.
2. "활성화 파라미터가 적다"는 계산 측 지표인데 이를 배포 측 지표로 오인하는 것이 이 문제의 함정 전부다 — 묻는 것은 MoE 원리가 아니라 학습/논문 시각을 배포 시각으로 전환할 수 있는가이다. 판단 기준은 시나리오를 먼저 다중 카드 추론으로 복원하는 것이다.
3. 메모리는 하나의 숫자가 아니라 하나의 구성표다 — 가중치, 활성화 피크, KV Cache, 통신 버퍼는 각각 증가 인자(전문가 수, 배치, 컨텍스트 길이, 병렬도)가 다르다. 하나의 총합으로 뭉개면 OOM이 어느 차원에서 났는지 설명할 수 없다.
4. MoE는 메모리 압박의 일부를 통신 압박으로 바꾼다 — 전문가가 여러 카드에 분산된 뒤 Token이 서로 다른 전문가에 적중하면 카드 간 이동이 생기고, All-to-All과 인기 전문가 과부하가 병목을 메모리에서 통신으로 옮긴다. 절약한 자원이 장소만 바꿔 다시 나타나는 경우가 많다.
5. 메모리를 절약하는 모든 수단은 대가와 함께 견적을 내야 한다 — 양자화와 전문가 오프로딩은 메모리를 압축하지만 정밀도 손실과 지연 증가가 동시에 발생한다. 수익만 보고하고 대가를 보고하지 않는 방안은 엔지니어링 리뷰에서 성립하지 않는다.
6. 답변의 신뢰도는 결론의 화려함이 아니라 입력 조건에서 온다 — "각 Token이 두 전문가만 고르지만 서로 다른 요청이 서로 다른 전문가에 적중한다"처럼 조건이 붙은 예시라야 "카드 간 이동 + 메모리 피크" 같은 검증 가능한 결과를 도출할 수 있다.
7. 엔지니어링 답변의 완전한 형태 = 판단 + 메커니즘 + 실패 경계 + 검증과 백스톱 — 실패 경로가 없는 방안은 출시할 수 없고, 검증 지표가 없는 방안은 효과를 증명할 수 없다.

#엔지니어링 실전 Tips

• 범위를 먼저 정하고 그다음에 계산할 것: 어떤 용량 문제든(MoE만이 아니라) 첫 단계는 "총 점유"를 서로 겹치지 않는 몇 항목으로 쪼갠 뒤 각각의 증가 인자를 찾는 것이다. 섞어서 계산한 결과로는 위치를 특정할 수 없다.
• 원인 규명은 첫 번째 이탈 지점에서 시작할 것: 입력·설정·모델 버전·중간 결과를 보존하고, 처음으로 예상에서 벗어난 노드를 찾은 뒤에 손을 댈 것. 최종 실패 지점에서 거꾸로 추측하지 말 것.
• 실패에 합법적 출구를 남길 것: 예상 이탈 시의 동작은 파라미터 조정·재시도·다운그레이드뿐이다. "모델에게 한 번 더 추측하게 하기"는 복구 전략이 아니다.
• 한 번에 주요 변수 하나만 바꿀 것: 입력·데이터·버전을 고정하지 않으면 정확성·지연·비용의 변화를 특정 변경에 귀인시킬 수 없다.
• "먼저 상한에 닿는 부분"을 설계 산출물로 삼을 것: 동시성이 올라가면 메모리가 먼저 터지는지, 통신이 먼저 차는지, 인기 전문가가 먼저 과부하되는지는 평가 시점에 답할 수 있어야 한다.
• 회귀는 고친 그 지점만 테스트하는 것이 아니다: 수정 후 인접 작업도 검사해 한 지점만 좋아지고 다른 시나리오가 퇴화하는 것을 막을 것.
• 지표와 버전을 같은 축에: 핵심 지표와 버전 배포를 같은 타임라인에 그려야 이상을 입력 분포 변화·설정 조정·모델 업그레이드·외부 의존 중 하나로 귀인할 수 있다.