2026년 7월 17일, Moonshot AI는 2.8조 개의 파라미터를 자랑하는 플래그십 모델인 Kimi K3를 발표했으며, 2026년 7월 27일까지 오픈 웨이트 (open weights)를 공개하겠다고 약속했습니다. 이러한 행보는 이전에는 폐쇄형 소스(closed-source)의 독점적 API에만 국한되었던 규모로 오픈 웨이트 (open-weights) 아키텍처를 확장시킵니다.

헤드라인에 등장하는 파라미터 수는 경이롭지만, 저의 목표는 마케팅적인 소음을 넘어 살펴보는 것입니다. 실무자들에게 2.8조 파라미터 모델은 거대한 아키텍처, 인프라 및 운영상의 과제를 안겨줍니다. 저는 Kimi K3가 여러분의 인프라 로드맵에 무엇을 의미하는지, 이 정도 규모의 모델을 서빙하기 위해 어떻게 현실적으로 준비할 수 있는지, 그리고 멀티 트릴리언(multi-trillion) 파라미터 수준에서 오픈 웨이트 (open-weights) 모델을 채택할 때의 전략적 트레이드오프 (trade-offs)가 무엇인지 분석하고자 합니다.

🏗️ 아키텍처 규모와 인프라의 현실

2.8조 파라미터 규모에서 밀집형 모델 (dense model)을 실행하는 것은 거의 모든 기업 환경에서 경제적, 물리적으로 불가능합니다. 이 규모를 실행 가능하게 만들기 위해 Kimi K3는 전문가 혼합 (Mixture of Experts, MoE) 아키텍처를 활용합니다. MoE 설정에서는 총 파라미터 수가 2.8T라 할지라도, 추론 (inference) 시 토큰당 파라미터의 일부(활성 파라미터, active parameters)만 활성화됩니다.

하지만 토큰당 활성 연산을 제한하는 MoE 아키텍처를 사용하더라도, 라우팅 (routing) 과정에서 치명적인 지연 시간 (latency) 병목 현상을 피하려면 2.8T 전체 가중치 세트가 반드시 고대역폭 메모리 (high-bandwidth memory, HBM)에 상주해야 합니다. 실제 메모리 계산을 나누어 살펴보겠습니다. FP16 정밀도 (precision)에서 2.8T 모델은 동시 요청 서빙에 필요한 KV 캐시 (KV cache)를 제외하고 가중치를 로드하는 데만 약 5.6 테라바이트 (terabytes)의 VRAM이 필요합니다. FP8 정밀도에서도 기본 메모리 요구 사항은 2.8 TB입니다.

이를 이해하기 쉽게 설명하자면, 8개의 80GB GPU를 탑재한 표준 HGX H100 노드는 640GB의 VRAM을 제공합니다. 오프로딩 (offloading) 없이 FP8로 Kimi K3를 호스팅하려면, 단 하나의 모델 인스턴스만을 위해서도 최소 56개의 HGX H100 노드(4048개의 GPU)가 상호 연결된 클러스터가 필요합니다. 차세대 NVIDIA H200 (141GB VRAM) 또는 B200 (192GB VRAM) 시스템을 사용할 계획이라면 노드 점유 면적 (node footprint)은 줄어들겠지만, 전문가 라우팅 (expert routing) 과정에서 발생하는 막대한 노드 간 통신 오버헤드를 처리하기 위해 네트워크 인터커넥트 (network interconnect, InfiniBand 또는 RoCE)는 여전히 매우 중요합니다.

Moonshot AI는 2.8조 파라미터 규모의 오픈 웨이트 (open-weights) 플래그십 모델인 Kimi K3를 발표했습니다. 이 기술 분석에서는 인프라 요구 사항, MoE 아키텍처의 영향, 양자화 전략을 탐구합니다.

2.8T의 운영화: 양자화 및 서빙 전략

Kimi K3를 기업용 배포 환경에서 사용할 수 있게 하려면, 공격적인 양자화 (quantization)는 선택 사항이 아니라 필수 전제 조건입니다. FP16에서 FP8 또는 FP4로 전환하는 것만이 하드웨어 점유 면적을 관리 가능한 수준으로 줄일 수 있는 유일한 실행 가능한 경로입니다.

유사한 MoE 아키텍처에 대한 저의 분석에 따르면, 양자화는 라우팅 안정성 측면에서 무시할 수 없는 과제를 안겨줍니다. MoE 모델에서 토큰을 특정 전문가 (experts)에게 전달하는 게이팅 네트워크 (gating network)는 정밀도 손실에 매우 민감합니다. 라우팅 레이어를 양자화하면 최적화되지 않은 전문가 선택으로 이어질 수 있으며, 이는 표준 밀집 모델 (dense model)의 양자화보다 모델 정확도를 훨씬 더 크게 저하시킵니다. 따라서 저는 라우팅 레이어와 핵심 어텐션 블록 (attention blocks)은 FP16 또는 FP8로 유지하고, 거대한 전문가 피드포워드 네트워크 (FFNs)를 INT4 또는 FP4로 양자화할 것을 권장합니다.

다음은 FP8 양자화 (Quantization)를 사용하여 Kimi K3와 같은 거대한 MoE 모델을 여러 텐서 병렬 (Tensor-parallel) 및 파이프라인 병렬 (Pipeline-parallel) 도메인에 걸쳐 로드하기 위해 vLLM 또는 TensorRT-LLM과 같은 분산 추론 엔진을 어떻게 구성할 수 있는지 보여주는 개념적 설정 예시입니다:

# 분산 MoE 추론 서빙을 위한 개념적 설정
from vllm import LLM, SamplingParams

...

인프라 조달 계획을 세우는 데 도움이 되도록, 다양한 양자화 수준에서 Kimi K3를 서빙하는 데 필요한 최소 하드웨어 구성 추정치를 정리했습니다:

🏗️ 오픈 웨이트 (Open-Weights) 생태계의 전략적 변화

역사적으로 기업들은 오픈 모델과 클로즈드 모델 간의 성능 격차가 매우 컸기 때문에 클로즈드 소스 API를 선택해 왔습니다. Kimi K3의 출시는 구조적인 변화를 의미합니다. 2.8조 파라미터 모델이 오픈 웨이트로 공개되면, 원천적인 능력 격차는 현저히 줄어듭니다.

하지만 Kimi K3를 내부적으로 호스팅하는 것과 관리형 API를 통해 프런티어 모델 (Frontier models)을 사용하는 것 사이의 전략적 트레이드오프 (Trade-offs)를 반드시 고려해야 합니다:

• 데이터 주권 및 컴플라이언스 (Data Sovereignty and Compliance): 엄격한 규제 경계가 있는 산업군(금융, 의료, 국방)의 경우, 자체 가상 프라이빗 클라우드 (VPC) 또는 온프레미스 (On-premise) 데이터 센터 내에 2.8T 모델을 호스팅함으로써 데이터 유출 위험을 제거할 수 있습니다. 이는 이 정도 규모의 오픈 웨이트 (Open weights) 모델을 채택하게 만드는 주요 동인입니다.
• 총 소유 비용 (Total Cost of Ownership, TCO): 전용 32-GPU 클러스터를 24시간 내내 가동하는 것은 매우 비용이 많이 듭니다. 쿼리 (Query) 양이 적거나 변동성이 매우 크다면, 관리형 API 제공업체에 토큰당 비용을 지불하는 것이 훨씬 더 비용 효율적입니다. 내부 호스팅은 프로비저닝된 (Provisioned) 하드웨어를 완전히 활용할 수 있을 만큼 높고 지속적인 처리량 (Throughput)을 보유했을 때에만 경제적으로 실행 가능해집니다.
• 커스터마이징 및 미세 조정 (Customization and Fine-Tuning): 오픈 웨이트를 사용하면 매개변수 효율적 미세 조정 (Parameter-Efficient Fine-Tuning, PEFT) 또는 LoRA를 수행하여 Kimi K3를 독점적인 도메인 지식에 특화시킬 수 있습니다. 그러나 2.8T MoE 모델을 미세 조정하려면 전문적인 분산 학습 프레임워크 (Megatron-LM 등)와 상당한 엔지니어링 전문 지식이 필요합니다.

🎯 결론

Moonshot AI의 Kimi K3는 오픈 웨이트 모델이 AI 규모의 절대적인 프런티어 (Frontier)에서 경쟁할 수 있음을 증명합니다. 하지만 2.8조 개의 파라미터를 가진 모델의 엄청난 크기는 배포가 결코 사소한 작업이 아님을 의미합니다. 이는 메모리 할당, 고속 네트워크 인터커넥트 (Interconnects), 그리고 공격적인 양자화 (Quantization) 전략에 대한 엄격한 계획을 요구합니다.

엔지니어링 리더들을 위한 저의 권장 사항은 인프라 예산에 대한 냉철한 평가와 함께 Kimi K3에 접근하라는 것입니다. 데이터 보안 요구 사항이 이를 강제하거나, 토큰 사용량이 전용 GPU 클러스터의 막대한 자본 지출 (Capital expenditure)을 정당화할 정도가 아니라면 이 모델을 사내에 호스팅하기 위해 서두르지 마십시오. 먼저 테스트 환경에서 양자화된 FP8 또는 INT4 버전을 평가하고, 지연 시간 (Latency)과 정확도 사이의 트레이드오프 (Trade-offs)를 측정하며, 프로덕션 마이그레이션 (Production migration)을 결정하기 전에 분산 서빙 스택 (Distributed serving stack)이 완전히 최적화되었는지 확인하십시오.

🔗 원문 출처: ixuvo.com