Kimi K3 초희소 MoE: 활성 파라미터로 추론 비용을 설계하는 법

Kimi K3의 초희소 MoE 구조를 중심으로 활성 파라미터, 전문가 라우팅, 메모리와 통신 병목, 오픈웨이트 서빙 판단 기준을 정리한다.

2026-08-31 · 최초 발행 2026-07-28

Moonshot AI는 2026년 7월 말 Kimi K3 전체 가중치를 공개했다. 총 2.8T 파라미터 모델이지만, 토큰 하나를 처리할 때 실제로 활성화하는 파라미터는 104.2B다. 초희소 MoE(Mixture of Experts)는 모델이 담을 수 있는 지식의 폭과 추론 비용을 별개의 축으로 다루게 만든다.

Kimi K3는 2026년 7월 16일 발표됐고, 전체 가중치는 7월 26~27일에 공개됐다. 사전 공지된 7월 27일보다 하루 앞선 배포였다. 공개 당시 최대 규모 오픈웨이트 모델로 소개됐으며, 자체적으로는 “세계 최초 3T급 오픈 시스템”으로 규정됐다.

Kimi Delta Attention(KDA)과 Attention Residuals(AttnRes)를 아키텍처 혁신으로 내세웠고, 1M 토큰 컨텍스트와 네이티브 멀티모달 입력을 지원한다. 자체 평가에서는 Claude Fable 5와 GPT-5.6 Sol에는 미치지 못했지만, 코딩·에이전틱 벤치마크의 다른 평가 대상 모델을 상회했다고 제시했다. MXFP4 양자화 배포판과 vLLM Day-0 지원도 함께 제공됐다.

활성화되는 전문가가 추론 비용을 정한다

MoE 레이어의 라우터는 입력 토큰마다 전문가 적합도를 계산하고 상위 k개 전문가를 선택한다. Kimi K3는 896개 전문가 풀에서 토큰당 16개를 활성화한다. 이 구조의 희소도는 약 1.8%다.

라우터 자체는 전체 모델에서 차지하는 비중이 작지만, 품질에는 큰 영향을 준다. 학습이 불안정하면 토큰이 일부 전문가에 몰리는 라우팅 붕괴가 생긴다. 반대로 전문가 사용량을 지나치게 균등화하면 각 전문가의 전문성이 약해져 품질이 떨어질 수 있다. 로드 밸런싱 손실의 계수는 품질과 자원 효율 사이의 교환점을 정하는 값이다.

k는 품질 목표만으로 정할 값이 아니다. k를 늘리면 품질은 오르지만 활성 파라미터와 지연도 비례해 증가한다. 서빙 환경에서는 목표 토큰당 지연, 허용 FLOPs, 활성 파라미터 상한, k 순서로 예산을 역산해야 한다.

상위 16용량 초과쏠림 감지정상입력 토큰라우터 게이트 (896 전문가점수화)top-k 선택 (k=16)토큰 디스패치 (all-to-all)토큰 드롭 · 재배치GPU 노드 A: 전문가 그룹1(상주)GPU 노드 B: 전문가 그룹2(상주)CPU · NVMe: 저빈도 전문가(오프로딩)가중 합산 (combine)전문가 사용 분포 점검라우팅 붕괴 경보 · 밸런싱 조정출력: 활성 파라미터 104.2B연산

전문가를 여러 GPU와 노드에 나누면, 토큰은 선택된 전문가가 위치한 장치로 이동한다. 이때 all-to-all 통신이 발생하며 통신량은 배치 크기와 k에 비례한다. 노드 간 대역폭이 부족하면 연산 성능보다 통신이 먼저 병목이 된다.

자주 호출되지 않는 전문가는 CPU 메모리나 NVMe에 두고 필요할 때 적재할 수 있다. 상주 GPU 메모리는 줄지만 첫 호출 지연이 생긴다. 이 전략의 효과는 전문가 호출 분포에 달려 있으며, 사용량이 균등 분포에 가까울수록 오프로딩 이득은 작다. 운영 중에는 전문가별 호출 빈도를 계속 계측해 분포 이상과 라우팅 쏠림을 찾아야 한다.

2.8T 가중치를 운영 환경에 배치하는 문제

활성 파라미터가 104.2B라고 해도 2.8T 전체 가중치는 어딘가에 적재돼 있어야 한다. 초희소 MoE 서빙에서 제약이 되는 지점은 연산보다 메모리다.

배치 설계는 전량 적재에 필요한 용량을 먼저 산정하고, 양자화 수준과 노드 수를 정한 뒤 전문가를 분산 배치하는 흐름으로 잡는다. 마지막으로 오프로딩할 전문가를 선별한다.

MXFP4 배포판이 제공되므로 저비트 적재는 기본 선택지가 된다. 다만 라우터와 어텐션 계층은 양자화 민감도가 높아 별도 정밀도를 유지해야 할 수 있다. 양자화 후에는 자체 평가셋으로 품질 하한을 확인하고, 하한에 미달하면 계층별 정밀도를 되돌릴 절차가 필요하다.

전체 파인튜닝은 2.8T 규모에서 현실적이지 않다. LoRA류 어댑터를 어텐션 계층에 적용하거나 특정 전문가 그룹만 갱신하는 방식이 실무적인 선택지가 된다. 전문가 일부만 바꿔도 라우팅 분포가 달라져 다른 전문가의 동작에 영향을 줄 수 있으므로, 갱신 뒤에는 전체 회귀 평가가 필요하다.

활성 파라미터가 작아도 인프라는 작아지지 않는다

구분 초희소 MoE (활성 104.2B) 동급 품질 밀집 모델
추론 FLOPs 활성 파라미터에 비례 전체 파라미터에 비례
메모리 적재량 전량 필요 (2.8T) 파라미터 규모만큼
병목 지점 메모리·통신 연산
배치 확장성 all-to-all 통신 제약 선형 확장
단가 구조 낮은 단가·높은 초기 투자 균형
적합 상황 고트래픽 자체 서빙 소규모·단순 배치

동일 품질을 기준으로 보면 초희소 MoE는 추론 단가에서 유리하고 메모리 소요에서는 불리하다. 트래픽이 충분하면 단가 우위가 메모리 투자비를 상쇄할 수 있지만, 저트래픽 환경에서는 유휴 GPU 메모리 비용이 남는다. 활성 파라미터가 작다는 이유만으로 비용이 낮다고 판단하면 실제 청구액과 어긋날 수 있다.

전문가 수와 활성 전문가 수는 다른 문제다. 전문가 수 896을 늘리면 모델 용량과 메모리 사용량은 커지지만 지연은 거의 그대로다. k=16을 늘리면 품질은 오르지만 지연과 단가도 비례해 증가한다. 지식 폭이 부족하면 전문가 수를, 추론 정합성이 부족하면 k를 조정하는 방향이 맞다.

자체 서빙과 상용 API의 총비용 구조도 다르다. 자체 서빙에는 GPU 감가, 전력, 운영 인력, 장애 대응이 고정비로 들어가고 토큰당 한계비용은 낮다. 상용 API는 고정비가 없고 토큰당 단가가 높다. 두 방식의 교차점은 조직의 일 토큰 처리량으로 결정된다. 데이터 주권 요구가 있다면 교차점과 무관하게 자체 서빙이 강제될 수 있다.

오픈웨이트 채택 전에 확인할 운영 조건

오픈웨이트 채택 판단에는 데이터 주권, 커스터마이징 필요성, 자체 서빙의 규모의 경제를 함께 놓아야 한다. 외부 API로 데이터를 보낼 수 없는 환경인지, 파인튜닝이나 디코딩 개입이 필요한지, 자체 서빙 손익분기점에 도달할 트래픽이 있는지가 기준이 된다. 이 조건 가운데 어느 것도 해당하지 않으면 상용 API가 총비용 면에서 유리한 경우가 많다. 오픈웨이트는 무료 모델이 아니라 운영비가 이전되는 구조다.

라이선스도 별도로 검토해야 한다. 오픈웨이트는 오픈소스와 같지 않다. 상업적 이용 범위, 파생 모델 배포 조건, 출처 표기 의무, 사용자 수 임계 조항을 개별적으로 확인해야 한다. 검토 결과는 모델 카탈로그에 남겨야 이후 재검토 비용을 줄일 수 있다.

비용은 GPU 시간보다 처리 토큰당 원가로 계산해야 한다. 유휴율까지 포함해야 상용 API 단가와 비교할 수 있다. 모델 버전, 가중치 해시, 양자화 설정은 형상관리 대상으로 등록해야 자체 서빙 환경에서 감사 대응이 가능하다.

인프라 용량과 기술 주권의 관점

초희소 MoE 도입은 단순한 모델 선택이 아니라 인프라 용량계획 문제다. 활성 파라미터로 연산량을 산정하고, 총 파라미터로 메모리 용량을 계산하는 이중 모델이 필요하다. all-to-all 트래픽은 기존 서버 용량 산정표에 없던 통신 대역폭이라는 새 축도 추가한다.

자체 서빙 전환은 API 과금이라는 변동비를 GPU 자산이라는 고정비로 바꾸는 결정이다. 수요 변동성이 큰 조직에서는 이 전환이 오히려 위험을 키울 수 있다. 토큰당 원가와 유휴율을 함께 보고해야 경영 판단에 사용할 수 있다.

가중치 공개는 모델 동작을 검증할 수 있게 하고 장기 가용성을 높인다. 벤더의 모델 종료 공지로 서비스가 중단될 위험도 줄어든다. 다만 가중치를 보유하더라도 이를 서빙할 GPU를 확보하지 못하면 기술 주권은 명목에 그친다. 주권은 가중치 보유뿐 아니라 조달 능력과 함께 검토해야 한다.

오픈웨이트 서빙 경쟁이 향하는 방향

파라미터 총량과 활성 파라미터를 나눠 공시하는 방식은 오픈웨이트 모델의 표준 표기법으로 정착할 전망이다. 경쟁은 전문가 수를 늘리고 k를 유지해 희소도를 더 낮추는 방향으로 이동하며, 메모리 계층 설계가 서빙 기술의 중심 주제로 부상한다.

저비트 양자화 배포판을 모델 공개와 동시에 제공하는 관행도 확산될 전망이다. 이 환경에서는 추론 엔진의 Day-0 지원이 채택률을 좌우한다. 데이터 주권 요구가 있는 공공·금융 부문에서는 오픈웨이트 자체 서빙이 우선 채택되고, 일반 기업은 관리형 서비스를 경유하는 이원화 구도가 다수를 차지할 전망이다.

Sources

Kimi K3Mixture of Experts오픈웨이트LLM 서빙전문가 라우팅