Kimi K3는 2.8조 파라미터 MoE지만 토큰마다 896개 라우팅 전문가 중 16개를 효과적으로 활성화한다. 이는 추론 때 모든 파라미터를 동시에 계산한다는 뜻은 아니지만, 거대한 전체 가중치를 어디에 두고 활성 전문가로 얼마나 빨리 보내느냐는 메모리·통신 문제를 없애지 않는다. 공식 자료는 학습 GPU 모델·수량·HBM 세대를 공개하지 않았으므로, K3를 특정 GPU나 HBM 제품의 학습 수요로 환산할 근거는 없다.
확인된 구조와 숫자
[confirmed·2026-08-22 업데이트] Kimi Team 기술보고서는 총 2.8T 파라미터, 토큰당 104B 활성 파라미터, 네이티브 비전, 100만 토큰 컨텍스트를 명시한다. Stable LatentMoE는 토큰마다 896개 라우팅 전문가 중 16개를 효과적으로 활성화한다. Kimi 공식 블로그는 SFT 단계부터 양자화 인지 학습을 적용해 MXFP4 가중치와 MXFP8 활성값을 사용한다고 설명한다. 이 정밀도 표기는 배포 형식과 연산 경로에 관한 것이지, 학습 GPU의 HBM 종류를 밝힌 문장이 아니다.
공식 권고는 추론 배포에서 64개 이상 가속기를 묶은 supernode다. 이유도 “더 큰 고대역폭 통신 도메인”이 추론 효율에 유리하다는 것이다. 블로그의 NVIDIA Hopper GPU 커널 실험, H20 보정 SWE-Marathon과 H20에서 실행한 PostTrain Bench 역시 평가 환경이다. 이를 사전학습 클러스터의 장비 목록으로 읽으면 평가와 학습을 혼동한다.
HBM과 캐시에 주는 의미
[inference] 희소 활성화는 토큰당 연산량을 줄이지만 전체 가중치의 저장 용량 문제와 전문가 라우팅 때의 데이터 이동은 남는다. 가중치를 여러 가속기에 나누면 가속기당 HBM 용량, HBM에서 연산기로 공급하는 대역폭, 가속기 사이 all-to-all 통신 도메인이 함께 처리량을 제한할 수 있다. 다만 성능 향상은 모델 구조·학습법·소프트웨어·통신·메모리의 합성 결과다. Kimi가 말한 K2 대비 약 2.5배 ‘전체 scaling efficiency’를 HBM 성능 2.5배로 바꿔 읽을 수 없다.
1M 컨텍스트는 동시 요청과 실제 사용 길이에 따라 KV 캐시 용량 압력을 키울 수 있다. KDA는 기존 prefix caching에 새 과제를 만들었고 Kimi는 prefill cache 구현을 공개 배포 경로에 연결했다. 공식 Kimi API의 코딩 워크로드에서 cache hit rate가 90%를 넘었다는 발표는 반복 prefix를 재사용한 해당 서비스 관측치다. 모든 고객·길이·배치에서 90%를 보장하거나 HBM 사용량이 90% 감소한다는 뜻은 아니다. 용량·대역폭·오프로딩의 층별 차이는 HBM과 계층형 메모리에 정리돼 있다.
학습 기반에서 말할 수 없는 것
[unknown] 사전학습과 후학습에 쓴 GPU 모델, GPU 수, 클러스터 위치, HBM 세대·용량, 총 학습 토큰과 전력은 두 공식 자료만으로 확인되지 않는다. 따라서 H100·H20 등 특정 장비 수량이나 HBM3·HBM3E 물량을 역산하지 않는다. Moonshot AI는 비상장(private) 회사이며 ticker는 null이다. 이 글은 투자 권유·목표주가나 GPU·HBM 구매량 추정이 아니다.
반증 조건과 다음 확인 숫자
현재 구분은 Kimi가 학습 클러스터 명세를 공식 공개하거나 기술보고서 개정본이 장비·HBM 구성을 밝히면 수정한다. 추론 해석은 실측에서 가속기 수를 늘려도 처리량이 개선되지 않거나 병목이 HBM·통신이 아닌 연산·소프트웨어로 확인되면 약해진다. 다음 확인 숫자는 ① 가속기별 배치 가능 최소 HBM 용량 ② 64개 전후 prefill·decode 처리량과 지연 ③ expert all-to-all 통신량 ④ 컨텍스트 길이·동시성별 KV/prefix cache 바이트와 적중률 ⑤ 학습 GPU·수량·HBM의 공식 공개 여부다.
공식 근거
이 리포트는 AI가 작성했고 발주자가 사후 검수합니다.
밑줄 친 말은 용어 위키로 이어집니다.