1.6조 파라미터인데 실제로는 48B만 쓴다고?
LongCat-2.0은 중국 메이투안(Meituan)이 내놓은 초대형 언어 모델이에요. 숫자만 보면 좀 어리둥절할 수 있는데요, 전체 파라미터(모델이 학습으로 갖게 된 가중치, 쉽게 말하면 '뇌세포 사이의 연결선' 같은 거예요)가 무려 1.6조(1.6T)개나 돼요. 그런데 정작 답을 한 번 만들어낼 때 실제로 켜서 쓰는 건 48B, 그러니까 480억 개뿐이라고 하거든요. 전체의 3% 정도만 일을 하는 셈이죠. 머릿속엔 어마어마한 지식을 담고 있으면서, 막상 한 문제를 풀 땐 그중 꼭 필요한 부분만 꺼내 쓰는 거예요. 어떻게 이런 게 가능할까요?
MoE, 전문가를 잔뜩 모아두고 필요한 사람만 부르는 구조
핵심은 MoE(Mixture of Experts), 우리말로 '전문가 혼합'이라는 구조에 있어요. 이게 뭐냐면, 모델 안에 작은 전문가 신경망을 수백 개 만들어 두고, 입력이 들어올 때마다 '라우터(router)'라는 교통정리 담당이 '이 질문엔 이 전문가 몇 명이면 충분해' 하고 일부만 골라서 일을 시키는 방식이에요. 회사로 치면 직원은 수백 명인데 한 건의 업무엔 담당자 두세 명만 투입되는 거랑 비슷하죠. 모든 직원을 매번 회의에 부르면 인건비가 감당이 안 되니까, 안건마다 담당자만 부르는 거예요.
그래서 뭐가 좋냐면, 모델이 품고 있는 '지식의 총량'은 1.6조 파라미터만큼 어마어마하게 크면서도, 실제로 답을 만들 때 드는 계산 비용(돈, 전기, 응답 속도)은 48B짜리 작은 모델 수준으로 확 낮출 수 있다는 거예요. 거대한 도서관을 통째로 들고 다니는 대신, 질문이 들어올 때마다 필요한 책장만 펼쳐 보는 거랑 같은 이치죠. 덩치는 거인인데 움직임은 날렵한, 그런 모델을 만들 수 있는 거예요.
요즘 거대 모델들이 다 이 길로 가는 이유
사실 이 방향은 LongCat만의 발상은 아니에요. DeepSeek-V3는 6710억 파라미터 중 370억만 활성화하는 구조를 택했고, 프랑스 미스트랄의 Mixtral도 일찍부터 MoE로 좋은 효율을 보여줬거든요. 모델을 무작정 키우면(모든 파라미터를 매번 다 쓰는 dense 방식) 성능은 오르지만 추론 비용이 감당 안 될 만큼 불어나는데, MoE는 그 딜레마를 푸는 현실적인 답으로 자리를 잡았어요.
LongCat-2.0이 눈길을 끄는 건, 활성 파라미터를 48B 수준으로 눌러두면서도 전체 규모를 1.6T까지 끌어올렸다는 점이에요. 한 토큰을 만들 때 켜지는 전문가 비율이 아주 낮은, 극단적으로 '희소한(sparse)' 설계인데요. 라우터가 엉뚱한 전문가를 부르거나 특정 전문가에게만 일이 몰리면 성능이 와르르 무너지기 때문에, 이렇게 희소하게 설계할수록 학습을 안정시키는 기술이 진짜 실력 차이를 만들어요. 큰 숫자를 자랑하는 것보다, 그 큰 구조를 안정적으로 굴리는 노하우가 훨씬 어려운 부분이거든요.
한국 개발자에게 주는 시사점
당장 1.6T 모델을 직접 돌릴 일은 거의 없겠지만, 흐름은 알아둘 가치가 충분해요. 첫째, 이제 모델을 평가할 땐 '전체 파라미터'보다 '활성 파라미터'를 봐야 서빙 비용을 제대로 가늠할 수 있어요. 광고 문구의 큰 숫자에 속지 않으려면 이 둘을 구분하는 눈이 필요하죠. 둘째, MoE 모델은 메모리에는 전체를 다 올려야 해서 VRAM(그래픽카드 메모리)은 많이 먹지만 연산은 적게 드는 독특한 특성이 있어요. 그래서 자체 호스팅을 고민한다면 GPU 메모리 용량이 가장 먼저 병목이 되기 쉽다는 점을 기억해 두세요. 중국·유럽발 오픈 가중치 모델들이 이렇게 효율 경쟁을 벌이는 덕분에, 우리가 골라 쓸 수 있는 선택지도 점점 넓어지고 있고요.
한 줄 정리: 모델의 '덩치'와 '한 번에 쓰는 힘'을 분리하는 MoE 설계가 이제 초거대 모델의 표준 문법이 되어가고 있어요. 여러분이라면 같은 비용으로 똑똑한 dense 모델과 거대한 MoE 모델 중 무엇을 서빙하시겠어요?
🔗 출처: Hacker News