IntBMoE는 거대한 AI 모델을 효율적으로 키우는 방법인 'Mixture-of-Experts(전문가 혼합, 이하 MoE)'가 안고 있던 오래된 딜레마를 정면으로 푼 연구다. 기존 MoE는 '전문가를 얼마나 참여시킬지', '얼마나 실제로 계산할지', '얼마나 많은 파라미터를 저장할지'라는 세 가지를 따로따로 조절할 수 없었다. IntBMoE는 이 셋을 분리(decouple)해서, 모든 전문가가 지식에 기여하면서도 계산과 메모리는 낮게 유지한다. 실제로 이 기술은 중국 지도 서비스 AMap의 생성형 추천 시스템에 배포되어 수억 명 사용자에게 60ms 이내로 서비스되고 있으며, 온라인 A/B 테스트에서 UVCTR(사용자당 클릭률) 2.4% 상대 상승을 기록했다.
MoE를 요리사 군단에 비유해 보자. 손님(입력 토큰)이 들어오면, 여러 전문 요리사(전문가) 중 누구를 부를지 정한다. 문제는 이 '요리사 운영'에 세 가지 서로 다른 비용이 걸려 있다는 점이다.
논문은 이 셋을 명확히 구분한다.
이상적으로는 "모든 요리사가 지식을 보태되(참여는 최대), 실제 손은 몇 명만 움직이고(실행은 최소), 창고에 새로 쌓는 세트도 적게(저장도 최소)"가 좋다. 그런데 기존 방식들은 이 셋을 독립적으로 설정하지 못했다.
| 기존 방식 | 참여 | 실행(계산) | 저장(materialization) |
|---|---|---|---|
| 희소 라우팅(Sparse routing) | 적음(줄어듦) | 낮음 | 낮음 |
| 밀집 출력 혼합(Dense output-mixing) | 가득 참 | 전문가 수만큼 커짐 | - |
| 파라미터 병합(Parameter-merging) | - | 전문가 1개로 유지 | 라우팅 결정 수만큼 커짐 |
즉 어느 하나를 잡으면 다른 하나가 새는 구조였다. 이 삼중 딜레마가 논문이 겨냥한 문제다.
IntBMoE(Integrating Block-Level Conditioning, 블록 수준 조건화)의 핵심은 '밀집한 전문가 구성'과 '희소한 블록 실행'을 짝지어 세 축을 동시에 떼어내는 것이다. 요리 비유를 이어가 보자.
1) 정해진 블록 목록표(코드북)를 둔다. IntBMoE는 기존 전문가를 작은 조각으로 쪼개지 않는다. 대신 학습된 소형 코드북(codebook, 정해진 블록 목록표)이 쓸 수 있는 '블록'의 목록을 정하고, 코드북의 한 칸이 블록 하나에 대응한다. 각 블록은 한 층에 갇힌 조각이 아니라 여러 내부 층에 걸친 다층 구조이며, 층마다 그 층의 전체 전문가 기반을 합성해 만들어진다(다음 항목). 중요한 건 블록의 개수를 입력이 아니라 코드북이 고정한다는 점이다. 손님이 아무리 다양해도 실행 중에 새로 만들어 들고 있어야 할 합성 블록의 수는 코드북 크기로 묶여 있다. 그래서 저장(합성 비용)이 한계 안에 갇힌다(bounded).
2) 매 층마다 즉석에서 전문가 한 명을 조립한다. 각 내부 층에서, 가벼운 하이퍼네트워크(hypernetwork, 다른 네트워크의 파라미터를 만들어 주는 작은 네트워크)가 그 층의 풀(pool)에 있는 모든 전문가 기반(expert bases)을 하나의 합성 전문가(composed expert)로 병합한다. 이렇게 만들어진 합성 전문가는 풀 전체를 끌어다 쓰므로, 참여가 가득 찬다(full). 모든 요리사의 지식이 한 명의 즉석 조립 요리사 안에 녹아드는 셈이다.
3) 라우터는 소수의 블록만 실제로 계산한다. 참여는 가득 찼지만, 라우터(router)는 각 토큰을 몇 개의 블록에만 보낸다. 그래서 실행(계산)은 여전히 희소하게 유지된다. 지식은 전부 반영되지만 실제로 손이 가는 조각은 몇 개뿐이라는 얘기다.
이 세 장치의 조합 덕분에 참여(가득)·실행(희소)·저장(제한)이 서로 얽히지 않고 각각 정해진다.
여기에 하나 더, 이중 경로 잔차 게이팅(Dual-Path Residual Gating, DPRG) 이 얹힌다. 독립적으로 구성된 두 개의 경로를 곱셈 게이팅(multiplicative gating, 한쪽 신호로 다른 쪽을 문처럼 여닫아 곱해 주는 방식)으로 결합한다. 서로 다르게 조립된 두 요리를 단순히 섞는 게 아니라, 한쪽이 다른 쪽을 조절하도록 엮어 표현력을 끌어올리는 장치로 볼 수 있다.
초록이 밝히는 성과는 다음과 같다. 구체적 수치가 제시된 항목만 그대로 옮긴다.
여기서 눈여겨볼 대목은, 이 방법이 논문 벤치마크에만 머문 게 아니라 엄격한 지연 제약(60ms)을 가진 대규모 실서비스에서 실제 지표를 끌어올렸다는 점이다. MoE 연구가 종종 "정확도는 올랐지만 배포 비용은?"이라는 질문에 막히는데, IntBMoE는 실행·저장을 의도적으로 낮게 묶는 설계 덕에 그 질문에 대한 답을 서비스로 보여준 셈이다. 코드도 공개되어 있다(github.com/AMAP-ML/DreamX-Rec).
초록만으로 판단할 때 솔직히 다음은 아직 열려 있다.
요컨대 "설계 철학과 실서비스 성과"는 분명하지만, "각 장치의 정량적 기여와 일반화 폭"은 본문을 읽어야 채워지는 부분이다.
온틀(ONTLE)은 반복 업무에 지친 소기업과 1인 창업가의 일손을 메우는 'AI 프로젝트 매니저 파견형' 제품을 지향한다. 그래서 우리에게 중요한 건 '똑똑함'과 '운영 비용'을 동시에 잡는 설계다. IntBMoE의 문제의식은 여기에 곧바로 닿는다.
첫째, '참여·실행·저장의 분리'는 제품 아키텍처의 은유로도 유효하다. 에이전트 시스템에서도 비슷한 삼중 딜레마가 있다. 여러 전문 에이전트(또는 도구)의 '지식을 다 반영하고 싶다(참여)', '그러나 매 요청마다 다 호출하면 느리고 비싸다(실행)', '모든 전문 모델을 상시 띄워두면 메모리·비용이 폭증한다(저장)'. IntBMoE는 이 셋을 굳이 같이 묶지 말고 각자 다른 장치로 통제하라는 힌트를 준다. 우리 라우팅(요청→적절한 소수 도구만 실행)과 지식 통합(전체 컨텍스트 반영)을 별개 레이어로 설계하는 근거가 된다.
둘째, '60ms 예산에서의 실배포'라는 규율이다. 온틀 같은 실서비스는 데모 정확도가 아니라 지연·비용 안에서의 실효 지표(클릭·완료·재방문)로 평가된다. IntBMoE가 실행·저장을 설계 단계에서 상수로 묶어둔 접근은, RAG나 에이전트 파이프라인에서 "품질을 올리되 응답 시간과 인프라 비용은 예산 안에 고정"하는 우리 원칙과 맞닿는다.
셋째, 순차 추천으로의 일반화는 온틀이 다루는 개인화·추천성 기능(무엇을 다음에 처리·제안할지)에 참고점이 된다. 다만 위 한계에서 짚었듯, 도입 판단은 우리 도메인 데이터로 소규모 검증을 거친 뒤가 맞다. 좋은 논문을 '바로 도입'이 아니라 '설계 원리를 빌리고 실측으로 검증'하는 순서를 지키는 것이 온틀의 방식이다.
Mixture-of-Experts(전문가 혼합)는 하나의 거대한 신경망 대신 여러 개의 작은 전문가 네트워크를 두고, 입력마다 적절한 일부만 골라 쓰는 구조입니다. 모델 용량(capacity)을 키우면서도 매번 전부 계산하지 않아 효율적이라 대형 모델에서 널리 쓰입니다.
기존 MoE는 이 셋이 서로 묶여 있어, 참여를 늘리면 계산이 커지고, 계산을 줄이면 참여가 줄거나(희소 라우팅) 실행 중 합성 파라미터가 불어났습니다(파라미터 병합). IntBMoE는 밀집 구성(모든 전문가 반영)과 희소 실행(소수 블록만 계산), 코드북 기반 고정 저장을 짝지어 세 축을 각각 독립적으로 조절합니다.
초록에 따르면 AMap의 생성형 추천 시스템에 완전히 배포되어 수억 명 사용자에게 60ms 지연 예산 안에서 서비스되고 있으며, 온라인 A/B 테스트에서 UVCTR(사용자당 클릭률) 2.4% 상대 상승을 기록했습니다. 이미지 분류·언어 모델링에서도 일관된 향상을 보고합니다(구체 수치는 초록에 없음).
네, 초록에 공개 저장소가 명시되어 있습니다: github.com/AMAP-ML/DreamX-Rec. 아래 참고자료의 arXiv/HuggingFace 링크도 함께 확인하세요.