Kimi K3 가중치 공개: 1.56TB 모델은 어떻게 서빙할까?

Kimi K3 96개 safetensors의 실제 용량과 정밀도 구성을 확인하고 104.2B 활성 파라미터, KDA·MLA 캐시와 현실적인 서빙 조건을 분석했습니다.

Jul 28, 2026

Contents

2.78T인데 왜 파일은 1.56TB인가?104.2B는 토큰마다 움직이는 모델의 크기다 1M 컨텍스트는 왜 더 많은 연산이 필요한가?가속기 64장은 최소 사양이 아니다 vLLM과 SGLang은 첫날부터 지원하지만 손볼 곳이 있다 성능과 라이선스는 따로 판단해야 한다 Kimi K3를 자체 서빙할 때 먼저 정할 것 함께 읽을 글 주요 참고 자료

Kimi K3의 가중치가 2026년 7월 27일 Hugging Face에 공개됐습니다. 96개 safetensors 파일을 합친 체크포인트는 1.561TB입니다. 2.8T 파라미터 전체를 4bit로 단순 환산한 1.4TB보다 큽니다.

왜 차이가 날까요? Kimi K3는 모든 가중치를 4bit로 저장하지 않기 때문입니다. MoE의 routed expert는 MXFP4로 양자화했지만 attention, shared expert와 router는 더 높은 정밀도로 남겼습니다.

이제 Kimi K3는 발표 자료가 아니라 실제 파일과 실행 코드로 검증할 수 있는 모델이 됐습니다. 공개된 체크포인트를 직접 확인해 보니 자체 서빙을 판단할 때 봐야 할 숫자는 세 개였습니다.

2.78T: 전체 expert pool의 규모. 토큰마다 일부 expert만 선택해도 요청에 따라 어느 expert든 쓸 수 있어야 합니다.
104.2B: 토큰 하나를 처리할 때 연산에 참여하는 파라미터. 기본적인 토큰 처리량과 계산 비용에 영향을 줍니다.
1.561TB: 배포된 체크포인트의 실제 용량. 가중치를 저장하고 옮기고 가속기 메모리에 올리는 데 필요한 용량의 출발점입니다.

세 숫자는 서로 다른 질문에 답합니다. 1.561TB는 가중치를 몇 장의 가속기에 나눠 올려야 하는지, 104.2B는 토큰마다 기본적으로 얼마나 계산해야 하는지를 판단할 때 씁니다. 여기에 컨텍스트 길이에 따라 달라지는 캐시와 어텐션 연산을 더해야 동시 요청 수와 응답시간을 계산할 수 있습니다.

흰 작업대 위 철가루가 Kimi K3를 상징하는 형태로 퍼져 있는 공식 대표 이미지 — 그림 1. Kimi K3 공식 대표 이미지. 출처: Moonshot AI, Kimi K3 Tech Blog

2.78T인데 왜 파일은 1.56TB인가?

Kimi K3는 토큰마다 896개 routed expert 가운데 16개를 고르는 MoE 모델입니다. 한 토큰이 모든 expert를 거치지는 않지만 요청마다 선택되는 expert가 달라집니다. CPU로 일부를 내리는 별도 구성을 쓰지 않는다면 전체 가중치를 가속기 메모리에서 사용할 수 있어야 합니다.

따라서 104.2B만 보고 “100B급 모델과 비슷한 메모리면 된다”고 계산할 수 없습니다. 104.2B는 주로 연산량을 설명하고, 메모리에는 2.78T 전체가 영향을 줍니다.

공개된 96개 safetensors 파일의 메타데이터를 읽어 저장 용량을 나누면 다음과 같습니다.

체크포인트 구성	저장 용량	주된 정밀도
Routed experts	1.446TB	MXFP4를 담은 packed U8
Attention	72.4GB	BF16·일부 F32
Shared experts	24.3GB	BF16
MoE router·latent projection	10.6GB	BF16·일부 F32
Embedding·LM head·dense layer·vision encoder 등	7.1GB	주로 BF16
합계	1.561TB

Kimi K3 체크포인트 1.561TB 가운데 routed experts가 1.446TB이고 나머지 114.4GB는 attention과 shared experts 등 높은 정밀도 가중치인 구성도 — 그림 2. 공개된 safetensors 96개의 저장 용량을 구성 요소별로 집계했습니다.

기술 보고서도 routed MoE expert weight만 MXFP4로 양자화했다고 설명합니다. Attention projection, latent MoE projection, shared expert와 router는 더 높은 정밀도를 유지합니다. 모델 카드의 “MXFP4 weights”만 읽으면 모든 가중치가 4bit라고 받아들이기 쉬운 대목입니다.

1.561TB는 가중치만 놓고 본 출발점입니다. 실제 서빙에는 엔진의 작업 공간, KDA state와 MLA KV cache도 필요합니다. 가속기 메모리의 합이 체크포인트 용량을 조금 넘는다는 이유만으로 충분한 동시 요청을 처리할 수 있다고 판단하면 안 됩니다. 가중치를 올리고도 요청을 처리할 여유 메모리가 남아야 합니다.

104.2B는 토큰마다 움직이는 모델의 크기다

전체 가중치는 2.78T지만 토큰 하나를 처리할 때 모든 파라미터가 계산에 참여하지는 않습니다. Kimi K3는 토큰마다 약 104.2B 파라미터를 활성화합니다.

계산량을 어림할 때는 활성 파라미터 하나마다 곱셈 한 번과 덧셈 한 번이 필요하다고 봅니다. 그래서 104.2B × 2, 즉 토큰당 약 208.4 GFLOPs를 기본 계산량으로 잡습니다. GFLOPs/token은 토큰 하나를 만들 때 몇십억 번의 부동소수점 연산이 필요한지를 나타내는 단위입니다.

이 계산은 출력 토큰을 만들 때마다 반복됩니다. 예를 들어 출력 100토큰을 만든다면 컨텍스트를 살펴보는 어텐션 연산을 빼고도 약 20.8조 회의 부동소수점 행렬 연산이 필요합니다. 활성 파라미터가 크면 같은 가속기에서 처리할 수 있는 토큰 수가 줄고 비용이 늘어나는 경향이 있습니다.

다만 208.4 GFLOPs만으로 실제 속도를 예측할 수는 없습니다. 메모리 대역폭, 가속기 사이의 통신, 커널과 동시 요청 수가 함께 영향을 줍니다. 컨텍스트가 길어지면 어텐션 연산도 추가됩니다.

Kimi K3가 69개 KDA 레이어와 24개 Gated MLA 레이어를 섞은 이유가 여기 있습니다.

KDA는 과거 토큰 전체의 KV를 보관하는 대신 고정 크기의 recurrent state를 갱신합니다.
Gated MLA는 토큰마다 압축된 KV를 저장하고 과거 컨텍스트를 조회합니다.

BF16에서 MLA KV cache는 토큰당 27KiB입니다. 1,048,576토큰을 한 요청이 채우면 약 27GiB가 됩니다. FP8 KV cache를 쓰면 토큰당 13.5KiB, 전체 약 13.5GiB로 줄어듭니다. vLLM과 SGLang은 모두 Kimi K3의 FP8 KV cache 실행 방법을 공개했습니다.

여기에 KDA state가 더해집니다. SGLang은 TP8 구성에서 69개 KDA 레이어의 state slot 하나를 약 54MB로 설명합니다. 실제 요청은 prefix cache와 speculative decoding 설정에 따라 여러 slot을 쓸 수 있습니다. 그래서 “KV cache가 토큰당 27KiB”라는 숫자만으로 동시 요청 수를 정하면 안 됩니다.

SGLang이 Kimi K3의 큰 KDA state block과 작은 MLA KV block을 두 개의 pool 또는 하나의 unified memory pool에서 관리하는 방식을 비교한 도면 — 그림 3. SGLang이 제안한 unified memory는 KDA state와 MLA KV cache가 같은 여유 공간을 나눠 쓰게 합니다. 출처: SGLang, Kimi K3 Day-0 Support

1M 컨텍스트는 왜 더 많은 연산이 필요한가?

앞에서 계산한 27GiB는 이전 토큰을 저장하는 데 필요한 메모리입니다. 저장해 둔 내용을 다음 토큰을 만들 때 얼마나 많이 읽고 계산해야 하는지는 별개의 문제입니다.

Kimi K3의 어텐션 레이어는 두 종류입니다.

69개 KDA 레이어는 이전 내용을 고정 크기의 state로 압축합니다. 컨텍스트가 길어져도 이 부분의 계산량은 크게 늘지 않습니다.
24개 Gated MLA 레이어는 새 토큰을 만들 때 앞서 저장한 토큰을 다시 살펴봅니다. 4,096토큰보다 1M토큰을 살펴볼 때 계산할 대상이 훨씬 많습니다.

Kimi K3는 컨텍스트 길이와 관계없이 모델 자체를 통과하는 데 토큰당 약 208 GFLOPs가 듭니다. 여기에 24개 MLA 레이어가 이전 토큰을 살펴보는 계산이 더해집니다.

입력 컨텍스트	모델 자체의 계산	MLA가 더하는 계산	Kimi K3 합계	GLM-5.2 합계
4,096토큰	약 208 GFLOPs	약 6 GFLOPs	약 214 GFLOPs/token	약 91 GFLOPs/token
131,072토큰	약 208 GFLOPs	약 193 GFLOPs	약 402 GFLOPs/token	약 93 GFLOPs/token
1,048,576토큰	약 208 GFLOPs	약 1,547 GFLOPs	약 1,755 GFLOPs/token	약 113 GFLOPs/token

4,096토큰에서는 모델 자체의 계산이 대부분을 차지합니다. 1M토큰에서는 24개 MLA 레이어가 이전 토큰을 살펴보는 계산이 훨씬 커집니다. Kimi K3가 KV cache를 작게 만든 것과 1M 컨텍스트를 적은 연산으로 처리하는 것은 같은 이야기가 아닙니다.

GLM-5.2의 증가 폭이 작은 이유는 DSA가 레이어마다 전체 컨텍스트 대신 관련도가 높은 2,048개 토큰을 골라 보기 때문입니다. 다만 이 숫자로 두 모델의 실제 속도를 비교할 수는 없습니다. 메모리 이동, GPU 사이의 통신, 커널 효율과 동시 요청 수는 포함하지 않은 행렬 연산의 어림값이기 때문입니다. 표는 긴 컨텍스트에서 두 모델의 계산량이 어떻게 달라지는지 설명하기 위한 값으로 봐야 합니다.

운영에서는 다음과 같은 차이가 생깁니다.

모델 전체를 기준으로 Kimi K3의 BF16 MLA KV cache는 4,096토큰에서 약 108MiB지만 1M토큰에서는 약 27GiB입니다. 실제로는 여러 가속기에 나눠 저장하더라도 긴 요청 하나가 차지하는 전체 메모리는 같습니다. 같은 서빙 복제본에서 동시에 처리할 수 있는 요청 수가 줄어듭니다.
다음 토큰 하나의 이론상 행렬 연산량은 4,096토큰에서 약 214 GFLOPs, 1M토큰에서 약 1,755 GFLOPs입니다. 약 8.2배의 차이입니다. 실제 응답시간이 정확히 8.2배가 된다는 뜻은 아니지만, 긴 요청일수록 출력 토큰 하나에 더 많은 GPU 시간과 비용이 듭니다.
따라서 모든 요청에 1M 컨텍스트를 열어 두기보다 실제 입력 길이를 먼저 측정해야 합니다. 긴 요청을 별도의 대기열이나 서빙 복제본으로 나눌지 검토하고, 1M이 필요하지 않은 서비스는 최대 컨텍스트를 낮춰 동시 처리량과 비용의 상한을 관리할 수 있습니다.

가속기 64장은 최소 사양이 아니다

가중치 공개 전 글에서는 Moonshot AI가 권장한 “가속기 64장 이상”을 중심으로 Kimi K3의 규모를 살펴봤습니다. 공개 후 나온 실행 자료를 보면 이 문장은 최소 사양과 구분해야 합니다.

Moonshot AI는 넓은 고대역폭 통신 영역에서 추론 효율이 좋아지므로 64장 이상의 supernode를 권장했습니다. 반면 vLLM과 SGLang은 더 작은 구성에서도 실행할 수 있는 레시피를 공개했습니다.

가속기	공개된 시작 구성	확인한 자료
NVIDIA B300	8장	vLLM·SGLang
AMD MI350X·MI355X	8장	SGLang
NVIDIA B200·GB200	16장	vLLM·SGLang
NVIDIA H200	16장	SGLang
NVIDIA H100	32장	SGLang

vLLM은 모델 전체가 DGX B300 한 대에 간신히 들어간다고 설명합니다. B200·GB200은 최소 16장이 필요합니다. SGLang의 구성 예시도 B300 8장과 B200·H200 16장부터 시작합니다. 다만 SGLang cookbook에는 일부 구성을 다시 측정하라는 경고가 남아 있습니다. 실행 가능한 시작점이지 처리량 보장치는 아닙니다.

8장 또는 16장으로 실행할 수 있다는 것과 효율적인 서비스를 만들 수 있다는 것도 다릅니다. 동시 요청 수와 컨텍스트 길이가 늘면 가중치 외에 KDA state와 MLA KV cache를 둘 메모리가 필요합니다. 노드를 넘는 expert parallelism에는 NVLink나 RDMA 같은 고속 연결과 그에 맞는 통신 설정도 필요합니다.

vLLM과 SGLang은 첫날부터 지원하지만 손볼 곳이 있다

Moonshot AI는 vLLM, SGLang과 TokenSpeed를 권장 엔진으로 안내합니다. vLLM과 SGLang은 가중치 공개 당일 실행 코드와 구성 예시를 내놨습니다.

두 엔진이 공개한 동시 요청 하나(batch size 1) 결과에서는 DSpark speculative decoding을 적용했을 때 디코드 속도가 크게 올랐습니다. vLLM은 GB300에서 118 tok/s가 370 tok/s로, SGLang은 약 113 tok/s가 약 423 tok/s로 높아졌다고 보고했습니다. 측정 조건이 같지 않으므로 두 숫자로 엔진의 승자를 정할 수는 없습니다. Kimi K3 같은 새 구조에서는 모델 자체만큼 커널, 통신과 speculative decoding 구현이 중요하다는 증거로 보는 편이 맞습니다.

vLLM이 GB300에서 Kimi K3의 batch size 1 디코드 처리량을 TP8과 TP16으로 측정한 결과, DSpark 적용 시 111에서 331 tok/s와 118에서 370 tok/s로 높아진 그래프 — 그림 4. vLLM의 GB300 측정 결과. DSpark를 쓰지 않은 결과는 임의 8K 입력과 1K 출력, DSpark 결과는 SPEED-Bench의 low-entropy subset으로 측정해 두 막대의 입력 조건도 다릅니다. 출처: vLLM, Kimi K3 Day-0 Support

가중치를 내려받아 엔진에서 실행했다는 사실만으로 서비스 준비가 끝나는 것은 아닙니다. 일반적인 API로 제공한다면 다음 세 가지를 먼저 확인해야 합니다.

같은 실행 환경을 다시 만들 수 있어야 합니다. Kimi K3 지원 코드는 공개 직후에도 빠르게 바뀔 수 있습니다. 테스트에 성공한 Docker 이미지 태그와 vLLM·SGLang, PyTorch, CUDA·ROCm 버전을 기록해 두면 문제가 생겼을 때 검증했던 환경으로 돌아갈 수 있습니다. 내용이 계속 바뀌는 latest 이미지는 피하는 편이 안전합니다.
실제 요청 길이와 동시 사용자 수로 용량을 측정합니다. 1M토큰은 요청 하나에 넣을 수 있는 최대 길이이지, 여러 사용자를 동시에 처리할 수 있다는 뜻이 아닙니다. 평소 요청이 8K인지 128K인지, 한 번에 몇 건을 처리할 것인지에 따라 필요한 캐시 메모리와 응답시간이 달라집니다. 최대 길이보다 실제 트래픽을 닮은 조건으로 가속기 수를 정해야 합니다.
프리픽스 캐시는 검증한 뒤 선택합니다. 프리픽스 캐시는 여러 요청에서 되풀이되는 시스템 프롬프트나 도구 설명을 다시 계산하지 않고 재사용하는 기능입니다. 반복되는 앞부분이 길수록 첫 토큰이 나오기까지의 시간을 줄일 수 있지만 캐시 메모리도 사용합니다. vLLM은 공식 Quick Start와 성능 재현 명령에서 --enable-prefix-caching을 사용합니다. 다만 Kimi K3의 하이브리드 캐시 구현이 계속 바뀌고 있어 현재 기본값은 꺼져 있습니다. 운영에 적용하기 전에는 검증한 Docker 이미지에서 캐시를 켠 경우와 끈 경우의 응답 오류, 장시간 실행 안정성, 메모리 사용량, 캐시 적중률과 첫 토큰 응답시간을 비교해야 합니다. 공통으로 반복되는 앞부분이 짧거나 드물다면 굳이 켤 이유가 없습니다.

에이전트에 연결할 때는 두 가지를 더 확인해야 합니다. Kimi K3는 답변과 별도로 생각한 내용을 reasoning_content에, 검색이나 함수 실행 요청을 tool_calls에 담습니다. 여러 차례 대화하거나 도구 실행 결과를 다시 모델에 보낼 때는 직전 응답에서 답변만 떼어내지 말고 이 두 필드를 포함한 응답 전체를 대화 기록에 남겨야 합니다. 그래야 모델이 앞서 어떤 판단으로 어떤 도구를 요청했는지 이어갈 수 있습니다.

도구 요청은 그대로 실행하지 않고 함수 이름과 인자가 미리 정한 형식에 맞는지 검사해야 합니다. vLLM은 Kimi K3가 낸 도구 요청을 해석하지 못해 tool_calls가 비어 있는 사례가 있을 수 있다고 안내합니다. 도구를 쓰는 서비스라면 이런 응답을 오류로 처리하고 다시 요청하거나 다른 경로로 넘기는 절차가 필요합니다. 단순한 질의응답 API라면 이 두 항목은 해당하지 않습니다.

성능과 라이선스는 따로 판단해야 한다

Artificial Analysis에서 Kimi K3는 2026년 7월 28일 기준 Intelligence Index 57점을 기록했습니다. 공개 모델 가운데 높은 수준이지만 공식 벤치마크 표와 독립 평가는 평가 도구와 설정이 다릅니다. 특정 업무에 도입할 때는 자체 프롬프트와 에이전트 환경에서 품질, 응답시간과 비용을 함께 재야 합니다.

Kimi K3 License는 가중치의 사용, 수정과 배포를 폭넓게 허용합니다. 다만 Model as a Service 사업자의 연속 12개월 합산 매출이 2,000만 달러를 넘으면 상업적 이용 전에 Moonshot AI와 별도 계약을 맺어야 합니다. Kimi K3를 쓴 제품이나 서비스가 월간 활성 사용자 1억 명 또는 월 매출 2,000만 달러를 넘으면 화면에 모델 이름을 표시해야 합니다. 내부 사용에는 이 두 조건이 적용되지 않습니다. 상용 서비스라면 도입 전에 원문과 적용 범위를 법무 검토해야 합니다.

Kimi K3를 자체 서빙할 때 먼저 정할 것

가중치 공개로 Kimi K3는 직접 검증할 수 있는 모델이 됐습니다. 그렇다고 1.56TB 파일을 GPU에 올리는 것으로 준비가 끝나지는 않습니다.

먼저 실제 요청의 입력 길이, 동시 사용자 수와 응답시간 목표를 정해야 합니다. 그다음 API 비용과 자체 인프라 비용을 비교하고, 자체 서빙이 맞다면 가속기 구성과 엔진 recipe를 고르는 순서가 좋습니다. 특히 1M 컨텍스트가 필요하지 않다면 최대 길이를 낮추는 것만으로도 캐시 용량과 운영 난도가 크게 줄어듭니다.

매니코어소프트는 오픈웨이트 모델의 가속기 산정, vLLM·SGLang 검증, 서버와 클러스터 구축 및 운영을 함께 지원합니다. Kimi K3의 자체 서빙이나 AI 인프라 도입을 검토하고 있다면 요구사항부터 함께 계산해 보시죠.

함께 읽을 글

주요 참고 자료

Contents

AI 동향

Kimi K3 가중치 공개: 1.56TB 모델은 어떻게 서빙할까?

Kimi K3 96개 safetensors의 실제 용량과 정밀도 구성을 확인하고 104.2B 활성 파라미터, KDA·MLA 캐시와 현실적인 서빙 조건을 분석했습니다.

MANYCORESOFT

Jul 28, 2026

Contents

2.78T: 전체 expert pool의 규모. 토큰마다 일부 expert만 선택해도 요청에 따라 어느 expert든 쓸 수 있어야 합니다.
104.2B: 토큰 하나를 처리할 때 연산에 참여하는 파라미터. 기본적인 토큰 처리량과 계산 비용에 영향을 줍니다.
1.561TB: 배포된 체크포인트의 실제 용량. 가중치를 저장하고 옮기고 가속기 메모리에 올리는 데 필요한 용량의 출발점입니다.

2.78T인데 왜 파일은 1.56TB인가?

공개된 96개 safetensors 파일의 메타데이터를 읽어 저장 용량을 나누면 다음과 같습니다.

체크포인트 구성	저장 용량	주된 정밀도
Routed experts	1.446TB	MXFP4를 담은 packed U8
Attention	72.4GB	BF16·일부 F32
Shared experts	24.3GB	BF16
MoE router·latent projection	10.6GB	BF16·일부 F32
Embedding·LM head·dense layer·vision encoder 등	7.1GB	주로 BF16
합계	1.561TB

104.2B는 토큰마다 움직이는 모델의 크기다

전체 가중치는 2.78T지만 토큰 하나를 처리할 때 모든 파라미터가 계산에 참여하지는 않습니다. Kimi K3는 토큰마다 약 104.2B 파라미터를 활성화합니다.

Kimi K3가 69개 KDA 레이어와 24개 Gated MLA 레이어를 섞은 이유가 여기 있습니다.

KDA는 과거 토큰 전체의 KV를 보관하는 대신 고정 크기의 recurrent state를 갱신합니다.
Gated MLA는 토큰마다 압축된 KV를 저장하고 과거 컨텍스트를 조회합니다.

1M 컨텍스트는 왜 더 많은 연산이 필요한가?

Kimi K3의 어텐션 레이어는 두 종류입니다.

69개 KDA 레이어는 이전 내용을 고정 크기의 state로 압축합니다. 컨텍스트가 길어져도 이 부분의 계산량은 크게 늘지 않습니다.
24개 Gated MLA 레이어는 새 토큰을 만들 때 앞서 저장한 토큰을 다시 살펴봅니다. 4,096토큰보다 1M토큰을 살펴볼 때 계산할 대상이 훨씬 많습니다.

입력 컨텍스트	모델 자체의 계산	MLA가 더하는 계산	Kimi K3 합계	GLM-5.2 합계
4,096토큰	약 208 GFLOPs	약 6 GFLOPs	약 214 GFLOPs/token	약 91 GFLOPs/token
131,072토큰	약 208 GFLOPs	약 193 GFLOPs	약 402 GFLOPs/token	약 93 GFLOPs/token
1,048,576토큰	약 208 GFLOPs	약 1,547 GFLOPs	약 1,755 GFLOPs/token	약 113 GFLOPs/token

운영에서는 다음과 같은 차이가 생깁니다.

모델 전체를 기준으로 Kimi K3의 BF16 MLA KV cache는 4,096토큰에서 약 108MiB지만 1M토큰에서는 약 27GiB입니다. 실제로는 여러 가속기에 나눠 저장하더라도 긴 요청 하나가 차지하는 전체 메모리는 같습니다. 같은 서빙 복제본에서 동시에 처리할 수 있는 요청 수가 줄어듭니다.
다음 토큰 하나의 이론상 행렬 연산량은 4,096토큰에서 약 214 GFLOPs, 1M토큰에서 약 1,755 GFLOPs입니다. 약 8.2배의 차이입니다. 실제 응답시간이 정확히 8.2배가 된다는 뜻은 아니지만, 긴 요청일수록 출력 토큰 하나에 더 많은 GPU 시간과 비용이 듭니다.
따라서 모든 요청에 1M 컨텍스트를 열어 두기보다 실제 입력 길이를 먼저 측정해야 합니다. 긴 요청을 별도의 대기열이나 서빙 복제본으로 나눌지 검토하고, 1M이 필요하지 않은 서비스는 최대 컨텍스트를 낮춰 동시 처리량과 비용의 상한을 관리할 수 있습니다.

가속기 64장은 최소 사양이 아니다

가속기	공개된 시작 구성	확인한 자료
NVIDIA B300	8장	vLLM·SGLang
AMD MI350X·MI355X	8장	SGLang
NVIDIA B200·GB200	16장	vLLM·SGLang
NVIDIA H200	16장	SGLang
NVIDIA H100	32장	SGLang

vLLM과 SGLang은 첫날부터 지원하지만 손볼 곳이 있다

Moonshot AI는 vLLM, SGLang과 TokenSpeed를 권장 엔진으로 안내합니다. vLLM과 SGLang은 가중치 공개 당일 실행 코드와 구성 예시를 내놨습니다.

같은 실행 환경을 다시 만들 수 있어야 합니다. Kimi K3 지원 코드는 공개 직후에도 빠르게 바뀔 수 있습니다. 테스트에 성공한 Docker 이미지 태그와 vLLM·SGLang, PyTorch, CUDA·ROCm 버전을 기록해 두면 문제가 생겼을 때 검증했던 환경으로 돌아갈 수 있습니다. 내용이 계속 바뀌는 latest 이미지는 피하는 편이 안전합니다.
실제 요청 길이와 동시 사용자 수로 용량을 측정합니다. 1M토큰은 요청 하나에 넣을 수 있는 최대 길이이지, 여러 사용자를 동시에 처리할 수 있다는 뜻이 아닙니다. 평소 요청이 8K인지 128K인지, 한 번에 몇 건을 처리할 것인지에 따라 필요한 캐시 메모리와 응답시간이 달라집니다. 최대 길이보다 실제 트래픽을 닮은 조건으로 가속기 수를 정해야 합니다.
프리픽스 캐시는 검증한 뒤 선택합니다. 프리픽스 캐시는 여러 요청에서 되풀이되는 시스템 프롬프트나 도구 설명을 다시 계산하지 않고 재사용하는 기능입니다. 반복되는 앞부분이 길수록 첫 토큰이 나오기까지의 시간을 줄일 수 있지만 캐시 메모리도 사용합니다. vLLM은 공식 Quick Start와 성능 재현 명령에서 --enable-prefix-caching을 사용합니다. 다만 Kimi K3의 하이브리드 캐시 구현이 계속 바뀌고 있어 현재 기본값은 꺼져 있습니다. 운영에 적용하기 전에는 검증한 Docker 이미지에서 캐시를 켠 경우와 끈 경우의 응답 오류, 장시간 실행 안정성, 메모리 사용량, 캐시 적중률과 첫 토큰 응답시간을 비교해야 합니다. 공통으로 반복되는 앞부분이 짧거나 드물다면 굳이 켤 이유가 없습니다.

성능과 라이선스는 따로 판단해야 한다

Kimi K3를 자체 서빙할 때 먼저 정할 것

가중치 공개로 Kimi K3는 직접 검증할 수 있는 모델이 됐습니다. 그렇다고 1.56TB 파일을 GPU에 올리는 것으로 준비가 끝나지는 않습니다.

함께 읽을 글

주요 참고 자료

Contents