Deoks: MoE가 덜 계산해도, 전문가 가중치는 어디에 둘까

요즘 MoE 연구를 따라가다 보면 ‘활성 파라미터가 작다’는 말이 먼저 눈에 들어온다.

MoE는 토큰마다 일부 전문가만 골라 계산하니, 처음엔 메모리 부담도 함께 줄어드는 구조처럼 보인다.

그런데 선택받지 않은 전문가의 가중치까지 사라지는 것은 아니다. 필요해지는 순간을 맞추려면, 결국 어딘가에 보관해 두고 제시간에 가져와야 한다.

AI 추론에서 다음 병목은 연산량보다 ‘전문가 가중치를 언제 옮길 수 있나’가 될 수도 있겠다는 생각이 든다.

이전 Tech(KR) 글: KV 캐시 재사용, HBM은 덜 필요할까

핵심 요약

MoE는 한 토큰에서 일부 전문가만 활성화해 계산량을 낮출 수 있지만, 모델 전체의 전문가 가중치를 보관해야 하는 문제까지 자동으로 없애지는 않는다.
HBM에 자주 쓰는 전문가만 남기고 나머지를 DRAM이나 SSD 같은 다른 계층에 둘 수는 있지만, 그때 병목은 용량에서 전송 지연과 대역폭으로 옮겨간다.
중요한 것은 단순 캐시 적중률보다 필요한 전문가 가중치가 다음 연산 시점 전에 도착했는지다. 이를 위해 예측·프리페치·퇴출 정책이 함께 필요해진다.
최근 SeqMoE, Edge0, MoRE 같은 연구는 서로 다른 답을 제시하지만, 각 실험 결과를 모든 모델·모든 데이터센터에 그대로 적용할 수는 없다.

전체 전문가 가중치 풀과 GPU HBM에 상주하는 일부 전문가, 서버 저장 계층에서 제시간에 프리페치되는 경로와 늦게 도착해 GPU가 기다릴 수 있는 경로를 표현한 개념도. — 전문가 가중치를 모두 GPU에 올리지 않을 때는 필요한 데이터를 연산 전에 가져오는 시간이 중요해진다.

적게 계산하는 모델과 크게 보관해야 하는 모델은 다르다

MoE(Mixture of Experts)는 모든 파라미터를 매번 동시에 계산하는 대신, 라우터가 토큰별로 일부 전문가를 선택해 처리하는 구조다. 그래서 활성 파라미터만 보면 계산 효율이 좋아 보인다. 하지만 서비스가 다음 토큰에서 어떤 전문가를 부를지 미리 확신할 수 없다면, 선택되지 않은 전문가 가중치도 완전히 잊어버릴 수는 없다.

여기서 HBM은 GPU 가까이에 두고 바로 꺼내 쓸 수 있는 작업 공간에 가깝다. 모든 전문가를 HBM에 상주시킬 수 있다면 단순하겠지만, 모델의 전체 용량과 여러 요청의 동시 처리까지 생각하면 공간은 제한된다. 반대로 서버 DRAM이나 SSD로 일부를 내리면 더 많은 가중치를 보관할 여지는 생기지만, 다음 연산에 맞춰 GPU로 되돌리는 시간이 새 변수로 들어온다.

그래서 MoE의 메모리 문제는 “가중치를 어디에 넣을까”에서 끝나지 않는다. 어떤 전문가는 계속 쓰고, 어떤 전문가는 오랫동안 안 쓰다가 갑자기 필요해진다. 이 불규칙한 재사용 패턴 때문에 용량, 링크 대역폭, 전송 지연, GPU의 대기 시간이 한 덩어리로 묶인다.

프리페치는 적중보다 도착 시간이 중요하다

전문가 오프로딩은 HBM에서 비활성 가중치를 비워 공간을 만드는 방법이다. 대신 GPU가 다음 전문가를 요청한 뒤에야 가져오기 시작하면 늦을 수 있다. 이 경우 GPU는 연산할 데이터를 기다리고, 사용자 입장에서는 토큰이 이어지는 속도가 느려질 수 있다.

그래서 프리페치는 ‘다음에 필요할 전문가’를 조금 먼저 예측해 옮겨두는 방식이다. 잘 맞히면 HBM을 모두 채우지 않고도 필요한 가중치를 제시간에 준비할 수 있다. 반대로 예측이 빗나가면 링크를 쓴 만큼의 전송이 낭비되고, 정작 필요한 전문가는 늦게 도착할 수 있다.

이 차이는 생각보다 크다. 캐시가 맞았다는 기록만으로는 충분하지 않고, 추론의 마감 시점 안에 도착했는지를 봐야 한다. 서버 DRAM이나 SSD의 표기 대역폭만 보고 실제 토큰 지연을 계산하기 어려운 이유도 큐 대기, 경로 구성, 다른 요청과의 경합, 실행 환경이 모두 끼어들기 때문이다.

SeqMoE·Edge0·MoRE는 같은 해법이 아니다

9월 11일 arXiv에 등록된 SeqMoE 사전공개 논문은 전문가 선택의 순서를 예측하고, 필요한 가중치를 마감 시간에 맞춰 미리 가져오는 관리 방식을 다룬다. 핵심은 전체 전문가를 항상 HBM에 올려두기보다, 다음 연산 그래프에 맞춰 이동을 겹치게 하는 데 있다. 저자들은 45% 상주 조건에서 평균 96.97% 적중률과 전체 전문가를 GPU 메모리에 상주시킨 경우 대비 80.22% 성능을 보고했지만, 이는 논문의 특정 설정에서 나온 값이지 특정 서비스의 성능 보장은 아니다.

9월 17일 수정본이 올라온 Edge0 사전공개 논문은 조금 다른 방향이다. SSD 계층을 쓰는 전문가 서빙을 위해 다음 레이어의 라우팅을 한 토큰 앞서 prerouter로 예측하고, 이를 실제 route로 쓰며 회복용 LoRA까지 학습한다. 저자들이 제시한 것은 35B 4-bit 모델을 단일 24GB 소비자용 장비에서 다룬 실험으로, 초당 20 token·GPU 메모리 3GiB라는 결과도 그 조건에 묶여 있다. 이것은 단순히 캐시를 잘 비우고 채우는 접근보다 모델의 라우팅과 품질 조건을 함께 바꾸는 설계다. 따라서 일반적인 무손실 오프로딩과 같은 선에서 비교하기보다, 품질 회귀와 운영 복잡도까지 함께 봐야 한다.

MoRE 사전공개 논문은 레이어마다 분리해 두던 전문가 풀을 공유하는 방식으로 접근한다. 다만 이 연구의 실험 범위는 1억1400만~11억5000만 파라미터 규모로 제시돼 있다. 훨씬 큰 최전선 모델에서도 같은 효율이 난다고 단정하기보다, 메모리 제약이 모델 구조 자체를 바꾸게 할 수 있다는 사례로 보는 편이 맞다.

투자 체크포인트

실제 서비스에서 HBM에 상주하는 expert working set이 어느 정도인지
예측한 전문가를 제시간에 준비한 비율과, 불필요하게 옮긴 전송의 비율이 어떻게 달라지는지
링크 사용률, 토큰 지연의 p95·p99, GPU당 동시 처리 요청이 함께 개선되는지
라우팅이나 공유 expert pool 도입이 정확도·안전성·운영 복잡도에 어떤 비용을 남기는지
가속기·메모리·스토리지 업체가 실제 고객 도입, 제품 인증, 출하와 관련한 근거를 공식 자료로 제시하는지

특히 이 분야에서는 ‘적중률이 높다’는 한 숫자보다 실패했을 때의 지연이 더 중요할 수 있다. 드문 miss가 길게 이어지면 평균 처리량이 좋아도 체감 품질은 나빠질 수 있기 때문이다. 이 글은 매수·매도 추천이 아니라, AI 추론과 메모리 공급망을 읽기 위한 정보다.

효율 개선이 메모리 수요를 한 방향으로 정하지 않는 이유

MoE 오프로딩과 프리페치가 좋아질수록 한 GPU에서 더 큰 모델을 다룰 수 있거나, 같은 장비에서 더 많은 요청을 처리할 가능성은 생긴다. 하지만 그 결과가 HBM, DRAM, SSD 중 어느 한쪽의 수요를 일괄적으로 키우거나 줄인다고 말할 수는 없다. 모델 구조, 요청 길이, 동시성, 서버 구성, 서비스 사업자의 투자 결정이 모두 다르기 때문이다.

오히려 지금 단계에서는 메모리 한계가 소프트웨어를 바꾸고, 바뀐 소프트웨어가 다시 어떤 메모리 계층을 얼마나 쓰게 만드는지의 순환을 보는 편이 흥미롭다. MoE가 덜 계산하는 모델이라는 설명 뒤에는, ‘모든 전문가를 어느 순간까지 어디에 둘 것인가’라는 더 현실적인 서버 문제가 남아 있다.

Appendix. MoE expert offloading은 무엇을 옮기는 기술일까

MoE expert offloading은 현재 GPU HBM에 꼭 필요하지 않은 전문가 가중치를 서버 DRAM이나 SSD 등 다른 저장 계층에 두었다가, 필요할 때 GPU 쪽으로 가져오는 운영 방식이다. 입력 문맥을 저장하는 KV 캐시와는 대상이 다르다. 이 글의 초점은 대화 상태가 아니라, 모델 안의 전문가 가중치와 그 이동 시간에 있다.

좋은 오프로딩은 단지 많은 가중치를 밖으로 내보내는 것이 아니다. 다음에 쓰일 가능성이 높은 전문가를 예측하고, 필요한 시점보다 앞서 옮기며, 잘못 옮긴 비용과 늦게 도착한 비용을 함께 줄이는 일에 가깝다.

출처 및 확인일

SeqMoE: Toward Full-Load Performance via Predictive and Graph-Compatible MoE Offloading — 2026-09-11 제출, arXiv 사전공개 논문이며 동료심사 또는 상용 배포의 근거는 아님, 2026-09-28 확인
The Other Half of the Memory Wall: Serving 35B MoEs from SSD with Trained Routing Prediction (Edge0) — 2026-09-16 제출·2026-09-17 v2, arXiv 사전공개 논문, 2026-09-28 확인
MoRE: Mixture of Reused Experts — 2026-09-16 제출·2026-09-17 v2, arXiv 사전공개 논문(COLM 2026 채택 표기), 2026-09-28 확인
NVIDIA TensorRT MoE 추론 공식 문서 — 발행일 미표시, 2026-09-28 확인
AMD Instinct MI350 공식 제품 페이지 — 발행일 미표시, 2026-09-28 확인
SK hynix 2026년 2분기 실적 자료 — 2026-07-29, 2026-09-28 확인
Samsung Electronics 2026년 2분기 실적 발표 — 2026-07-30, 2026-09-28 확인
Samsung PM1763 SSD 공식 발표 — 2026-07-08, 2026-09-28 확인

MoE가 덜 계산해도, 전문가 가중치는 어디에 둘까