MoE expert를 개별 점수가 아니라 쌍 상호작용까지 고려해 잘라내는 2차 프루닝, HOPE

무엇인가

이 논문이 다루는 문제는 Mixture-of-Experts(MoE) 언어 모델의 메모리 병목이다. MoE는 토큰마다 소수의 expert만 활성화하지만 전체 expert 풀은 GPU 메모리에 상주해야 한다. 논문이 든 예로 Qwen3.5-122B-A10B의 122B 파라미터 중 116B가 expert MLP이며 약 240GB를 차지한다. 양자화는 각 파라미터를 줄일 뿐 중복 expert를 없애지 못하므로, expert를 통째로 제거하는 프루닝이 직교적인 해법이 된다. 문제는 기존 프루닝 방법들이 모두 1차(first-order)라는 점이다. Frequency, EAN, MAN, REAP 모두 expert마다 스칼라 중요도 S_k를 독립적으로 매겨 하위 expert를 잘라낸다. 그러나 실제 MoE 추론에서 각 토큰은 top-K expert 그룹을 동시에 활성화해 출력을 합치고, 특정 expert 쌍은 우연보다 훨씬 자주 함께 선택된다. expert A를 자르면 A가 참여하던 협력 회로가 끊기고, A와 자주 co-selection되던 파트너 expert의 조합이 어긋나면서 A 하나를 뺀 것 이상의 손실이 날 수 있다는 것이 저자들의 진단이다.

어떻게 동작하나

제안 방법 HOPE(Higher-Order Pruning of Experts)는 이 협력 구조를 프루닝 결정에 직접 넣는다. 절차는 다음과 같다. 캘리브레이션 셋을 한 번 forward pass 하면서 각 토큰의 활성 expert, 게이트 값, expert 출력을 기록하고, 두 expert가 동시에 활성화된 토큰들에 대해 상호작용 항까지 수집한다. 레이어마다 E×E 크기의 F 행렬을 만들며, 원소는 F_i,j = (1/N) Σ_{x∈X_i,j} g_i(x) g_j(x) ||f_i(x)||_2 ||f_j(x)||_2 이다. 대각 성분은 개별 expert 기여도, 비대각 성분은 두 expert가 함께 쓰일 때의 상호 기여도를 담는다. 목적함수는 프루닝으로 생기는 대체 오차(substitution error)의 상한 Z = [Σ_{j∈P∩T(x)} g_j(x)·||f_j(x)||_2]^2 를 최소화하는 것이다. 논문의 Theorem 1은 제곱 대체 오차가 (1+ρ)^2 · Z 이하로 유계됨을 보이고(ρ는 레이어 내 expert 출력 노름의 최대/최소 비), Theorem 2는 이 최소화가 이진 결정 변수 p에 대해 p^T F p 를 최소화하는 이차계획(QP), 즉 Σp_k = |P| 제약 아래의 문제와 동치임을 보인다. 구현에서는 레이어별 QP를 연속 완화로 풀고 상위 |P|개로 반올림하며, 레이어당 1~2초가 추가로 든다고 밝힌다.

무엇과 다른가

REAP과의 관계가 이 논문의 핵심 논점이다. HOPE의 F 대각은 F_k,k = E[(g_k(x)||f_k(x)||)^2]이고, REAP 점수의 제곱은 (S_k^REAP)^2 = E[g_k(x)||f_k(x)||]^2 로, 두 식은 활성 토큰에 대한 기여도의 분산만큼만 다르다. 실제로 비대각을 0으로 두면 REAP과 같은 prune-set이 나온다고 논문은 보고한다. 즉 HOPE는 REAP을 특수 케이스로 포함하는 일반화이며, REAP 대비 성능 향상은 전적으로 비대각 상호작용 항에서 나온다.

어떻게 쓰나

실험은 3개 MoE 모델(Qwen3.5-122B-A10B: 256 expert, top-8, 48 MoE 레이어, Qwen3.5-35B-A3B: 256 expert, top-8, 40 레이어, GLM-4.5-Air: 128 expert, top-8 + 공유 expert 1개, 45 레이어, 공유 expert는 프루닝하지 않음), 2개 캘리브레이션 셋(Evol-CodeAlpaca-v1 코딩 중심, SWE-Bench verified 트래젝터리 agentic 중심), 6개 프루닝률(10, 20, 25, 30, 40, 50%, SWE-Bench Pro는 10/25/50%만), 벤치마크 Tulu3 Dev suite(GSM8K, MATH, IFEval, MMLU, BBH, TruthfulQA, PopQA, LiveCodeBench)와 SWE-Bench Pro로 총 54개 구성을 돌렸다. 베이스라인은 REAP, EAN, MAN, Frequency다. 전체 조건에서 HOPE의 평균 순위는 2.07로 가장 좋았고 top-1 비율 39%, top-2 비율 67%, 일대일 비교 평균 승률 73%를 기록했다. 40~50% 고프루닝 구간에서는 평균 순위 1.58(차선인 REAP은 2.42)이었고, agentic 벤치마크에서 고프루닝 조건 전 실험에서 REAP을 이겼으며 평균 격차 +2.8%, 최대 +6.1%였다. 태스크별 최대 향상은 LiveCodeBench +19.6%, BBH +11.7%, SWE-bench Pro +2.0%였고, PopQA 같은 단순 회상 과제에서는 이득이 작았다. HOPE가 최하위를 기록한 조건은 54개 중 1개(20% 프루닝 Qwen3.5-122B-A10B)뿐이며 그 격차도 -1.7%였고, 단일 조건 최악 격차는 -4.5%다. 반면 REAP은 5회, Frequency는 43회 최하위를 기록했다.

전제와 한계

F 행렬 구조 분석도 제시된다. 비대각 원소들은 잡음이 아니라 뚜렷한 하위 구조를 보이며 평균 크기가 대각의 33%에 달한다. HOPE가 1차 방법과 판단이 갈릴 때, HOPE는 다른 생존 expert와의 상호작용 점수가 더 강한 expert를 우선적으로 남기고, REAP이 남기지만 HOPE가 자르는 expert는 개별 중요도는 높지만 상호작용 점수가 낮은 경우였다. HOPE의 prune-set은 출력 기반 방법인 REAP, MAN과 가장 유사하고, 불일치는 네트워크 전 레이어에 분포한다. 캘리브레이션 안정성은 3회 랜덤 시행에서 Jaccard 유사도 0.95 이상이었고, 캘리브레이션 셋을 바꿨을 때의 Jaccard는 HOPE 0.60, REAP 0.61로 HOPE가 더 민감하지 않았다. 추가로 Qwen3.5-122B-A10B의 REAP/HOPE 프루닝 체크포인트에 LiveCodeBench 트레이스로 10억 토큰 SFT를 했을 때도 HOPE가 계속 앞섰는데, 파인튜닝이 격차를 좁히지만 없애지는 못했다.

개발자 관점에서 이 논문의 실용적 함의는 명확하다. 프루닝은 one-shot이고 재학습이 필요 없으며 양자화와 조합 가능하다. 논문이 든 예처럼 Qwen3.5-122B를 50% 프루닝하면 풋프린트가 125GB로 줄어 115GB를 추가 컨텍스트, 툴 호출, 긴 추론 트레이스에 쓸 수 있다. 이득이 가장 큰 지점은 프루닝률이 높고(40~50%) 여러 expert 조합이 긴 시퀀스에 걸쳐 동원되는 agentic·코딩·복합 추론 워크로드이므로, 메모리가 빠듯해 공격적 압축이 필요한 서빙 환경에서 우선 검토할 만하다. 도입 시 확인할 것은 세 가지다. 캘리브레이션 데이터의 도메인(코딩 중심인지 agentic 트래젝터리인지)이 실제 서비스 트래픽과 맞는지, 레이어별 QP를 풀 솔버와 연속 완화·반올림 파이프라인을 감당할 수 있는지, 그리고 프루닝 후에도 라우터가 남은 expert를 독립적으로 조절한다는 전제가 자신의 모델 계열에서 성립하는지다.

저자들이 밝힌 한계는 다음과 같다. HOPE의 캘리브레이션은 이차항을 다루기 때문에 시간과 메모리가 더 드는데, 같은 크기 캘리브레이션 셋에서 REAP보다 약 6~7% 오래 걸린다. F 행렬 저장 메모리는 expert 수가 128~256 수준일 때 무시할 만하다. 데이터도 조금 더 필요한데, 동일 prune-set에 99% 일치하기까지 REAP은 8k 프롬프트, HOPE는 10k 프롬프트가 필요했다(Qwen3.5-122B-A10B, Evol-CA 캘리브레이션, 50% 프루닝). 또한 다른 대부분의 방법과 마찬가지로 레이어별로 독립적으로 프루닝하며 레이어 간 상호작용은 고려하지 않는다. 상호작용도 2차(쌍)까지만 다루며, 더 높은 차수의 상호작용은 조합적으로 정량화가 어렵다고 밝힌다. 향후 과제로 cross-layer HOPE를 통한 레이어별 비균일 프루닝 예산 배분을 제시하지만, 협력 구조가 약한 레이어를 과도하게 자르는 예산 배분 불안정성이 생길 수 있어 추가 제약이 필요할 수 있다고 덧붙인다.