AWS의 Deploying Kimi K3 on AWS는 Kimi K3 배포 경로를 두 가지로 제시합니다.
Kimi K3는 2.8 trillion 파라미터 MoE이며, 토큰마다 16개 전문가만 활성화합니다.
실무에서는 모델 크기보다
ml.p6-b300.48xlarge예약 용량이 먼저입니다.
AWS의 「Deploying Kimi K3 on AWS」는 Kimi K3 배포 방법을 설명합니다. 원문은 Kimi K3가 3 trillion 파라미터 급에 도달한 첫 공개 가중치 시스템이라고 밝힙니다. 원문은 경로를 두 가지로 나눕니다.
하나는 Amazon SageMaker HyperPod입니다. 다른 하나는 Amazon EKS 클러스터입니다. 원문은 공개 가중치가 Hugging Face의 moonshotai/Kimi-K3로 제공된다고 밝힙니다.
원문은 HyperPod의 Inference Operator가 클러스터 생성 과정에서 자동 설치된다고 말합니다. 배포의 핵심은 모델 공개 여부보다 필요한 용량과 서빙 방식입니다.
AWS는 Kimi K3를 어떤 경로로 배포하게 하나요
원문은 Kimi K3 배포를 두 방식으로 정리합니다. 하나는 Amazon SageMaker HyperPod입니다. 다른 하나는 Amazon EKS 클러스터입니다.
원문은 HyperPod의 Inference Operator가 자동으로 설치된다고 말합니다. 또한 컨테이너 오케스트레이션, 모델 적재, 엔드포인트 관리를 추상화한다고 설명합니다.
원문이 말하는 요지는 단순합니다. Kimi K3는 공개되었지만, 가벼운 환경에 바로 올릴 수 있는 모델은 아닙니다. 배포 방식부터 정해야 합니다.
그다음에 GPU 용량과 서빙 엔진을 맞춰야 합니다.
2.8 trillion 파라미터 중 실제로 활성화되는 값은 무엇인가요
아래 표는 원문에서 확인된 값만 정리한 것입니다.
| 항목 | 원문 값 | 이 값이 재는 것 |
|---|---|---|
| 총 파라미터 수 | 2.8 trillion | 모델 전체 크기입니다. |
| 전문가 수 | 896 | 분산된 전문가 집합의 개수입니다. |
| 토큰당 활성 전문가 수 | 16 | 토큰 하나를 처리할 때 켜지는 전문가 수입니다. |
| 활성 파라미터 수 | 104 billion | 한 번의 순전파에서 실제로 활성화되는 파라미터 수입니다. |
| 스케일 효율 개선 | 2.5x | Kimi K2 대비 확장 효율 개선 폭입니다. |
| 컨텍스트 윈도 | 1 Million Tokens | 한 번에 다루는 문맥 길이입니다. |
| 공개일 | July 27, 2026 | 원문이 밝힌 공개 날짜입니다. |
원문은 다음과 같이 직접 말합니다.
This means approximately 104 billion parameters are active during any single forward pass
이 문장은 MoE 구조의 핵심을 보여줍니다. 전체 크기와 실제 연산량은 같은 값이 아닙니다. 모델 전체는 2.8 trillion 파라미터이지만, 한 번의 순전파에서 활성화되는 값은 약 104 billion입니다.
원문은 이 설계가 Kimi K2 대비 2.5x 확장 효율 개선으로 이어진다고 밝힙니다.
MoE 구조는 왜 배포 판단을 바꾸나요
Kimi K3는 896개 전문가를 두고, 토큰마다 16개만 활성화합니다. 그래서 모델 설명을 읽을 때는 총 파라미터 수만 보면 안 됩니다. 실제 추론 비용은 활성화되는 전문가 수와 서빙 병렬화 방식에 더 가깝습니다.
원문이 강조하는 것도 바로 이 차이입니다.
이 점은 실무 판단을 바꿉니다. 모델이 크다고 해서 모든 배포 병목이 메모리만은 아닙니다. 어떤 전문가가 언제 활성화되는지, 그리고 그 경로를 어떤 엔진이 처리하는지가 중요합니다.
원문은 vLLM이 MoE 구조, 텐서 병렬 처리, MXFP4 형식을 지원한다고 설명합니다. 그래서 Kimi K3의 권장 서빙 엔진으로 vLLM을 제시합니다.
원문은 또 Kimi K3가 장기 코딩 작업과 에이전트형 워크플로, 복잡한 추론에 강하다고 말합니다. 즉, 모델의 용도는 넓지만 배포 조건은 더 엄격합니다. 성능 서술과 인프라 요구를 분리해서 봐야 합니다.
p6-b300 예약 용량을 먼저 잡아야 하는 이유는 무엇인가요
원문은 Kimi K3 배포에 ml.p6-b300.48xlarge 인스턴스가 필요하다고 밝힙니다. 이 인스턴스는 8 NVIDIA B300 Blackwell Ultra GPUs를 제공합니다. 또한 원문은 이 인스턴스 유형이 reserved capacity를 요구한다고 말합니다.
즉, 용량을 먼저 확보하지 않으면 배포 단계에서 막힐 수 있습니다.
AWS는 용량 확보 수단으로 Flexible Training Plans와 Capacity Blocks를 제시합니다. 원문은 Flexible Training Plan이 Blackwell GPU 노드에 대한 확약된 용량 예약을 제공한다고 설명합니다. 또한 일반 온디맨드 풀과 경쟁하지 않도록 p6-b300 인스턴스를 확보하게 해준다고 말합니다.
Amazon EKS 워크로드는 이 예약 용량을 대상으로 사용합니다.
실무에서는 다음 순서로 점검하면 됩니다.
- 모델 식별자가
moonshotai/Kimi-K3인지 확인합니다. - 서빙 컨테이너가
vllm/vllm-openai:kimi-k3인지 확인합니다. - 클러스터 용량 소스가 Training plan인지 확인합니다.
- 워커 그룹 인스턴스가
ml.p6-b300.48xlarge인지 확인합니다. - 타깃 가용 영역이 예약 용량과 같은지 확인합니다.
원문은 Kimi K3를 서빙하려면 vLLM 초기 추론 컨테이너가 필요하다고 말합니다. 원문 시점의 컨테이너는 vllm/vllm-openai:kimi-k3입니다. 원문은 vLLM이 MoE 구조와 텐서 병렬 처리, MXFP4 형식을 지원한다고 설명합니다.
이 때문에 서빙 엔진 선택도 인프라 계획의 일부가 됩니다.
이 체크리스트는 복잡해 보이지만 방향은 단순합니다. 모델을 먼저 고르는 것이 아니라, 먼저 돌릴 수 있는 용량을 확보해야 합니다. 그다음에 배포 경로를 HyperPod 또는 EKS로 맞추면 됩니다.
자주 묻는 질문
Kimi K3는 AWS에서 어떤 경로로 배포합니까?
원문은 Amazon SageMaker HyperPod와 Amazon EKS 두 경로를 제시합니다. 둘 중 하나를 고르는 문제가 아니라, 클러스터 운영 방식에 맞춰 선택하는 문제입니다.
Kimi K3를 돌리려면 어떤 인스턴스가 필요합니까?
원문은 ml.p6-b300.48xlarge 인스턴스가 필요하다고 밝힙니다.
이 인스턴스는 8 NVIDIA B300 Blackwell Ultra GPUs를 제공합니다.
왜 예약 용량이 필요합니까?
원문은 ml.p6-b300.48xlarge가 reserved capacity를 요구한다고 밝힙니다.
Flexible Training Plan은 일반 온디맨드 풀과 경쟁하지 않도록 용량을 예약해 줍니다.