2.8조 파라미터 Kimi K3의 공개와 오픈 웨이트 스펙

2.8조 개의 파라미터를 가진 초거대 AI 모델의 가중치가 공개되면서 기업이 외부 API 의존 없이 자체 서버에 모델을 올려 운영할 수 있는 범위가 확장되었다. 그동안 3조 개 수준의 파라미터를 가진 모델은 대부분 폐쇄형으로 제공되어 데이터 보안이나 커스텀 최적화에 제약이 컸다. Kimi K3는 이 규모의 모델 중 처음으로 오픈 웨이트(Open Weights, 모델의 학습 결과물인 가중치를 공개하는 방식) 형태로 배포되어 자체 호스팅의 길을 열었다. 이제 기업은 민감한 데이터를 외부로 전송하지 않고 내부 인프라에서 모델을 구동하며, 지연 시간 제어와 하드웨어 최적화를 직접 수행하는 선택지를 갖게 되었다.

Moonshot AI는 2026년 7월 27일 Kimi K3를 공식 출시했다. 이 모델은 MoE(Mixture of Experts, 전체 파라미터 중 일부 전문가 네트워크만 선택적으로 사용하는 구조) 방식을 채택해 2.8조 개의 파라미터를 구현했다. MoE 구조는 모델의 전체 크기를 확장해 지식 저장 용량을 극대화하면서도, 실제 추론 시에는 입력된 토큰에 적합한 일부 전문가 네트워크만 활성화해 연산 비용을 관리하는 방식이다. 모델 가중치는 허깅페이스(Hugging Face, AI 모델 공유 플랫폼)의 `moonshotai/Kimi-K3` 저장소를 통해 배포되어 누구나 다운로드하여 사용할 수 있다.

Kimi K3는 복잡한 추론과 에이전트 워크플로우(Agentic Workflows, AI가 목표 달성을 위해 스스로 계획을 세우고 도구를 사용하는 흐름), 장기 코딩 작업에 특화된 성능을 보인다. 특히 다단계 문제 해결을 위해 상시 생각 모드(Thinking Mode)를 지원하여, 최종 답변을 내놓기 전 내부적으로 추론 단계를 거치며 논리적 오류를 스스로 수정하는 능력을 강화했다. 또한 네이티브 도구 호출(Native Tool Calling, 외부 함수나 API를 모델이 직접 선택해 호출하는 기능)과 구조화된 출력 기능을 통해 외부 시스템과의 정밀한 상호작용이 가능하다.

이러한 기능적 특성은 Kimi K3가 단순한 대화형 AI를 넘어 복잡한 소프트웨어 엔지니어링이나 기업용 자동화 에이전트로 활용될 수 있는 기술적 기반이 된다. 특히 구조화된 출력 지원은 JSON과 같은 특정 형식을 엄격히 준수해야 하는 백엔드 시스템과의 연동 효율을 높여 데이터 파이프라인 구축의 복잡도를 낮춘다. 2.8조 개의 파라미터라는 규모는 모델이 학습한 방대한 지식과 복잡한 논리 구조를 처리하는 능력을 뒷받침한다. 이를 오픈 웨이트로 제공함으로써 엔지니어가 모델의 성능을 직접 검증하고 특정 도메인 데이터로 미세 조정할 수 있는 환경이 마련되었으며, 이는 폐쇄형 모델이 제공하지 못하는 투명성과 제어권을 제공한다.

MXFP4 양자화와 vLLM 기반의 추론 최적화

Kimi K3는 896개의 전문가 모델 중 토큰당 16개만 선택적으로 활성화하는 구조를 갖췄다. 이는 전문가 혼합(Mixture of Experts, MoE) 방식의 일종으로, 전체 파라미터 규모와 상관없이 한 번의 순전파 연산 과정에서 실제로 작동하는 파라미터는 약 1,040억 개 수준으로 제한된다. 여기에 Kimi Delta Attention(KDA, 키미 델타 어텐션)과 Gated Multi Head Latent Attention(MLA, 게이트 다중 헤드 잠재 어텐션), 그리고 Stable LatentMoE 프레임워크를 함께 적용했다. 이 세 가지 아키텍처 요소는 연산 효율을 높이고 메모리 병목을 줄이는 핵심 기제로 작동한다. 결과적으로 Kimi K3는 이전 모델인 Kimi K2와 비교해 스케일링 효율을 2.5배 향상시켰다.

모델 가중치는 MXFP4(Microscaling Floating Point 4-bit, 마이크로스케일링 4비트 부동소수점) 포맷으로 배포된다. MXFP4는 데이터의 정밀도를 4비트로 낮추어 메모리 점유율을 줄이면서도, 작은 단위의 블록마다 스케일링 인자를 부여해 수치적 정확도를 보전하는 양자화 방식이다. 대규모 추론 배포 환경에서는 모델의 품질을 유지하면서 메모리 효율을 극대화하는 것이 필수적이다. MXFP4 포맷을 통해 가중치 크기를 압축함으로써 제한된 GPU 메모리 내에서 더 높은 처리량을 확보했다. 이는 하드웨어 자원 소모를 줄이면서도 모델의 추론 성능 저하를 최소화하여 배포 비용을 낮추는 전략이다.

추론 엔진으로는 vLLM을 사용하며, 현재는 Kimi K3 전용 커밋이 포함된 전용 컨테이너 이미지를 통해 배포해야 한다. vLLM은 고성능 LLM 서빙을 위한 추론 라이브러리로, 메모리 관리와 처리량 최적화에 특화되어 있다. Kimi K3 전용 기능들이 메인 컨테이너에 병합되기 전까지는 아래의 전용 이미지를 사용한다.

vllm/vllm-openai:kimi-k3

vLLM은 MoE 아키텍처를 네이티브로 지원하며, 모델의 가중치를 여러 GPU에 분산 배치하는 텐서 병렬 처리(Tensor Parallelism) 기능을 제공한다. 특히 MXFP4 양자화 포맷을 직접 지원하므로 별도의 변환 단계 없이 가중치를 로드해 즉시 추론에 활용할 수 있다. 이러한 엔진 최적화는 2.8조 개의 거대 파라미터를 가진 모델을 실제 서비스 수준의 속도로 구동하는 기술적 기반이 된다.

기존 방식과 달라진 지점

Kimi K3를 구동하려면 NVIDIA B300 Blackwell Ultra GPU 8장이 탑재된 `ml.p6-b300.48xlarge` 인스턴스가 필요하다. 이 인스턴스는 대규모 전문가 풀 전체에서 효율적인 텐서 병렬 추론(모델의 연산을 여러 GPU에 나누어 처리하는 방식)을 수행하는 데 필수적인 고대역폭 상호 연결망을 제공한다. 다만 해당 인스턴스 타입은 예약된 용량이 필요하므로 Flexible Training Plan(FTP, 유연한 훈련 계획)을 통해 B300 GPU 노드를 미리 확보해야 한다. 사용자는 SageMaker 콘솔에서 일정과 인스턴스 수를 기반으로 FTP 블록을 선택하여 훈련 계획을 생성하거나 연결한다. 이는 일반 온디맨드 풀의 자원 경쟁 없이 클러스터에 인스턴스를 안정적으로 공급받기 위한 필수 제약 사항이다.

인프라 구축의 복잡성은 SageMaker HyperPod와 Inference Operator(추론 운영 도구)가 추상화한다. Inference Operator는 클러스터 생성 단계에서 자동으로 설치되며 컨테이너 오케스트레이션(컨테이너의 배치와 관리), 모델 로딩, 엔드포인트 관리를 통합 수행한다. 기존 방식에서는 쿠버네티스 설정과 모델 가중치 배포, 네트워크 엔드포인트 설정을 개별적으로 수행해야 했으나 이 도구가 이를 자동화한다. 관리자가 개별 컨테이너의 상태를 수동으로 확인하거나 모델 파일을 서버에 직접 배치하는 물리적 과정이 생략된다. 인프라 설정의 세부 사항을 소프트웨어 계층이 대신 처리함으로써 모델 배포까지의 소요 시간을 단축한다.

실제 배포는 GitHub 저장소에서 제공하는 설정 파일을 통해 이루어진다. 터미널에서 아래 명령어를 입력하면 `kimi-k3.yaml` 파일의 전용 구성이 즉시 적용된다.

kubectl apply -f kimi-k3.yaml

배포가 완료되면 OpenAI 호환 API가 제공되어 기존 애플리케이션과의 연동이 용이하다. 개발자는 모델의 내부 구조나 인프라 환경에 관계없이 표준화된 인터페이스를 통해 추론 요청을 보낼 수 있다. 이는 API 규격을 새로 설계하는 비용을 없애고 기존에 구축된 LLM 워크플로우를 그대로 유지하며 모델만 교체할 수 있게 한다. 사용하지 않는 자원은 비용 발생을 막기 위해 배포 후 즉시 삭제하는 관리가 필요하다.

Amazon EKS 기반의 자율형 인프라 구축

EC2 Capacity Blocks를 통해 특정 기간 동안 `p6-b300.48xlarge` 인스턴스를 예약하여 독립적인 GPU 자원을 확보한다. 이는 장기 계약이라는 제약 없이 필요한 시점에만 B300 GPU 8장이 탑재된 고성능 연산 자원을 점유하는 방식이다. AI on EKS 프로젝트에서 제공하는 Terraform(테라폼, 코드로 인프라를 정의하고 프로비저닝하는 도구) 모듈을 활용하면 VPC(가상 사설 클라우드) 네트워크 구성부터 관리형 노드 그룹, GPU 워크로드 전용 IAM(식별 및 액세스 관리) 역할과 정책까지 자동으로 생성한다. 특히 VPC 네트워크 설정을 통해 GPU 노드 간의 고속 통신을 위한 최적의 경로를 확보한다. 인프라 전체를 코드로 관리함으로써 수동 설정 과정에서 발생하는 휴먼 에러를 제거하고 동일한 환경의 클러스터를 신속하게 복제하여 운영 효율을 높인다.

노드 그룹에 NVIDIA 디바이스 플러그인과 GPU 드라이버를 설치하여 쿠버네티스가 물리적 GPU 자원을 인식하고 스케줄링하는 환경을 구축한다. 디바이스 플러그인은 하드웨어의 세부 상태를 쿠버네티스 API에 노출하여, 특정 파드가 요청한 수의 GPU를 정확히 할당받도록 제어하는 역할을 수행한다. 이 설정이 완료되면 클러스터 내의 B300 GPU 8장이 추론 엔진의 연산 자원으로 즉시 활용 가능한 상태가 된다. NVIDIA 드라이버는 B300 Blackwell Ultra GPU의 최신 아키텍처를 커널 수준에서 지원하여 연산 효율을 극대화한다. 하드웨어 인식과 드라이버 최적화 단계가 선행되어야만 대규모 모델의 분산 추론을 위한 메모리 맵핑과 연산 할당이 물리적으로 가능해진다.

Helm(헬름, 쿠버네티스용 패키지 관리 도구) 차트를 통해 vLLM 컨테이너를 배포하며, 설정 파일에서 텐서 병렬 크기를 8로 지정하고 MXFP4 로드 포맷을 적용한다. 텐서 병렬 처리는 단일 모델의 가중치를 여러 GPU에 분산 배치하여 연산량을 나누는 기술로, B300 GPU 8장의 성능을 최대로 끌어올리기 위한 필수 설정이다. 모델 가중치 파일은 Amazon S3(확장 가능한 객체 저장소)에 동기화하여 로딩 속도를 최적화한다. S3에서 노드로 데이터를 직접 전송하는 구조는 외부 저장소 접근 시 발생하는 네트워크 병목을 최소화하여 모델 로딩 시간을 단축하고 서비스 가동 시간을 앞당긴다.

Kubernetes Service의 LoadBalancer(부하 분산기) 또는 Ingress(외부 진입점 제어기) 설정을 통해 8000번 포트로 vLLM 서버를 외부로 노출한다. 이를 통해 외부 애플리케이션은 `/v1/chat/completions` 엔드포인트를 호출하여 Kimi K3 모델의 추론 결과값을 수신한다. 해당 엔드포인트는 OpenAI API와 호환되는 인터페이스를 제공하므로, 기존에 구축된 LLM 애플리케이션의 코드 수정 없이 엔드포인트 주소만 변경하여 즉시 적용할 수 있다. 인프라 예약부터 API 노출까지의 전 과정이 자동화된 레시피로 연결되어 엔지니어가 관리해야 할 운영 오버헤드를 최소화한다.

한국 AI 실무자를 위한 인프라 선택 기준

vLLM의 Kimi K3 전용 커밋이 메인 컨테이너에 병합되기 전까지는 전용 이미지인 `vllm/vllm-openai:kimi-k3`를 사용해야 한다. vLLM 메인 컨테이너의 병합 여부를 확인하는 것은 전용 이미지 의존성을 제거하고 표준 런타임으로 전환하는 시점을 결정하는 핵심 신호가 된다. 실무자는 vLLM 공식 저장소의 커밋 로그를 통해 Kimi K3 관련 최적화 코드가 메인 브랜치에 반영되었는지 주기적으로 확인해야 한다.

배포가 완료된 Kimi K3 엔드포인트는 OpenAI 호환 채팅 완성 API를 제공한다. 이는 기존에 OpenAI API를 사용하던 애플리케이션의 코드 수정 없이 엔드포인트 URL만 변경하여 즉시 통합할 수 있음을 의미한다. OpenAI 파이썬 SDK를 활용하거나 아래의 curl 명령어를 통해 API 응답 상태를 즉시 검증할 수 있다.

curl -X POST <ENDPOINT_URL>/v1/chat/completions

인프라 선택은 운영 주체의 성격과 제어 범위에 따라 결정한다. 빠른 배포와 관리 편의성이 우선인 조직은 SageMaker HyperPod를 선택한다. HyperPod는 복잡한 클러스터 설정 과정을 관리형 서비스로 제공하여 모델 서빙까지의 진입 장벽을 낮춘다. 반면 세밀한 네트워크 구성이나 IAM 권한 제어가 필수적인 보안 환경이라면 Amazon EKS를 선택한다. EKS는 쿠버네티스 기반의 자율형 환경을 제공하므로 조직 내 인프라 엔지니어링 역량을 투입해 네트워크 토폴로지를 직접 설계할 수 있다.

비용 효율화는 리소스 삭제 시점을 엄격히 관리하는 것에서 시작한다. ml.p6-b300.48xlarge 인스턴스는 매우 높은 비용이 발생하는 고성능 자원이므로 사용 종료 즉시 HyperPod 및 EKS 리소스를 삭제해야 한다. 특히 Flexible Training Plan이나 Capacity Blocks를 통해 확보한 B300 GPU 노드는 예약된 시간 윈도우가 종료되기 전 효율적으로 사용하고 반납하는 절차가 필수적이다.

운영 조직이 쿠버네티스 클러스터를 직접 제어하고 네트워크를 최적화할 기술적 역량을 갖췄다면 EKS를, 인프라 관리 공수를 최소화하고 모델의 빠른 서비스 적용에 집중해야 한다면 HyperPod를 선택하는 것이 최적의 실행 기준이다.