이 기사는 8개의 NVIDIA B300 GPU가 장착된 단일 서버에서 Kimi-K3를 배포하고 벤치마킹한 내용을 기록합니다. 64K 및 200K 롱 컨텍스트 (long-context) 워크로드 하에서 vLLM과 SGLang을 비교합니다. 핵심 결과는 명확합니다: 64K에서는 vLLM이 더 빠르지만, 200K에서는 DCP를 사용하는 SGLang이 이를 앞섭니다. 이러한 차이는 주로 Prefill이 아닌 Decode 단계에서의 KV 액세스에서 발생합니다.

Kimi-K3는 복잡한 추론과 롱 컨텍스트 (long-context) 워크로드를 위해 설계된 전문가 혼합 (Mixture-of-Experts, MoE) 모델입니다. 이번 테스트에서는 GPUStack을 사용하여 vLLM과 SGLang 모두를 통해 단일 8×NVIDIA B300 서버에 모델을 배포했습니다. 투기적 디코딩 (speculative decoding)을 위한 초안 모델 (draft model)로 Kimi-K3-DSpark를 활성화했습니다.

가장 중요한 결과는 다음과 같습니다:

• 64K 입력, 동시성 (concurrency) 10: vLLM은 워크로드를 100.5초 만에 완료한 반면 SGLang은 150.8초가 소요되어, vLLM이 약 1.5배 더 빨랐습니다.
• 200K 입력, 동시성 (concurrency) 10: SGLang은 워크로드를 225.3초 만에 완료한 반면 vLLM은 295.2초가 소요되어, SGLang이 약 1.31배 더 빨랐습니다.
• 64K에서 200K로 증가할 때, 안정적인 디코드 (Decode) 처리량 (throughput)은 vLLM에서 3.29배 저하되었으나 SGLang에서는 1.25배만 저하되었습니다.
• 성능 역전의 주요 원인은 SGLang은 --dcp-size=8로 실행된 반면, vLLM은 decode_context_parallel_size=1을 사용했기 때문입니다.
• 프리필 (Prefill) 성능은 대체로 비슷했습니다. 대부분의 격차는 디코드 (Decode) 중에 나타났습니다.
• Random 데이터셋은 매우 낮은 DSPARK 수락률 (acceptance rates)을 생성했으므로, 투기적 디코딩 (speculative-decoding) 결과를 실제 운영 트래픽에 직접적으로 확장하여 해석해서는 안 됩니다.

중요: 이것은 엄격하게 통제된 A/B 테스트가 아니었습니다. 두 엔진은 DCP, 메모리 할당, 커널 백엔드 (kernel backends) 및 수락 기준 (acceptance criteria)에서 차이가 있었습니다. 이 결과는 절대적인 승자를 선언하기 위한 것이 아니라, 병목 현상과 배포 시의 트레이드오프 (trade-offs)를 이해하는 데 가장 유용합니다.

테스트 환경 (Test Environment)

모델 가중치 준비 (Preparing the Model Weights)

ModelScope에서 Kimi-K3 메인 모델과 DSpark 초안 모델 (draft models)을 다운로드하세요.

Kimi-K3 메인 모델 (MXFP4)

modelscope download \
  --model moonshotai/Kimi-K3 \
  --local_dir ./Kimi-K3

vLLM용 DSpark 초안 모델

modelscope download \
  --model skyai/Kimi-K3-DSpark \
  --local_dir ./Kimi-K3-DSpark

SGLang용 DSpark 초안 모델

modelscope download \
  --model skyai/sglang-Kimi-K3-DSpark \
  --local_dir ./Kimi-K3-DSpark

추론 이미지 가져오기 (Pulling the Inference Images)

vLLM

docker pull vllm/vllm-openai:kimi-k3

SGLang

docker pull lmsysorg/sglang:kimi-k3

이미지를 가져온 후, GPUStack의 추론 백엔드(Inference Backends) 섹션에 사용자 지정 vLLM 및 SGLang 버전을 추가하세요.

GPUStack을 이용한 vLLM 배포 (Deploying vLLM with GPUStack)

GPUStack에서 사용자 지정 vLLM 백엔드를 생성하고, Kimi-K3 모델과 모든 8개의 B300 GPU를 선택하며, 필요한 환경 변수를 구성하세요.

vLLM 사용자 지정 백엔드 및 모델 설정은 아래에 나와 있습니다.

vLLM 환경 변수 (vLLM Environment Variables)

VLLM_ENABLE_K3_LATENT_MOE_TAIL_FUSION=1
VLLM_ALLREDUCE_USE_FLASHINFER=1
VLLM_ENGINE_READY_TIMEOUT_S=3600
...

vLLM 시작 매개변수 (vLLM Startup Parameters)

--trust-remote-code
--load-format fastsafetensors
--moe-backend auto
...

이 테스트에서는 --gpu-memory-utilization 0.95가 KV 풀을 초과 할당(overcommitted)하여 런타임 OOM 재시작을 유발했습니다. 더 안전한 구성은 나중에 논의됩니다.

GPUStack을 이용한 SGLang 배포 (Deploying SGLang with GPUStack)

SGLang 사용자 지정 백엔드를 생성하고, 모든 8개의 B300 GPU를 선택하며, 모델 및 시작 매개변수를 구성하세요.

아래에 SGLang 사용자 지정 백엔드 및 모델 설정이 표시됩니다.

SGLang 시작 매개변수 (Startup Parameters)

--trust-remote-code
--model-path <Kimi-K3 모델 경로>
--tp-size 8
...

GPUStack은 서비스가 시작된 후 실시간 서비스 로그, 처리량(throughput), 그리고 KV Cache 상태를 노출합니다.

동시성 10개, 입력 64K / 출력 3K

첫 번째 비교에서는 입력 64K, 출력 3K, 그리고 동시 요청 10개를 사용했습니다.

vLLM 결과

SGLang 결과

해당 추론 로그는 아래에 표시됩니다.

[

다양한 입력 길이에 따른 결과

컨텍스트(Context)의 증가가 TTFT, TPOT, ITL 및 엔드 투 엔드(end-to-end) 지연 시간에 어떤 영향을 미치는지 관찰하기 위해 추가적인 입력 길이를 테스트했습니다.

vLLM

SGLang

핵심 결과: 64K와 200K 사이에서 성능 역전 발생

한 줄 요약: vLLM은 DCP 통신 오버헤드를 피할 수 있기 때문에 짧은 컨텍스트에서 더 빠릅니다. 컨텍스트가 커짐에 따라 KV 대역폭(bandwidth)이 지배적인 요소가 되며, SGLang의 DCP=8은 KV 읽기 작업을 8개의 GPU로 분산합니다.

소스 검사 결과, 이는 단순히 vLLM 플래그가 누락된 것이 아님을 보여줍니다. vLLM은 DCP와 DSPARK를 동시에 활성화하는 것을 명시적으로 금지합니다. SGLang은 이들이 공존하는 것을 허용하지만, 추측적 디코딩(speculative decoding)이 비적응형 검증 모드(non-adaptive verification mode)로 전환됩니다. 이는 설정상의 실수가 아닌 아키텍처 측면의 트레이드오프(trade-off)입니다.

성능 역전이 발생하는 이유

1. 디코딩 확장성(Decode Scalability)이 결정적 요인

10개의 요청이 모두 디코딩(Decode) 단계에 진입한 후 안정적인 처리량(throughput)을 측정했습니다.

엔진 보고 로그를 기반으로 한, 안정적인 10개 요청 단계 동안의 총 디코딩 처리량 (tokens/s).

vLLM (DCP=1)

• 64K에서 안정적인 처리량(throughput)은 약 439–537 tok/s였으며, 최고치는 537 tok/s였습니다.
• 요청당 수치는 약 53.7 tok/s, 즉 18.6 ms/token입니다.
• 200K에서 안정적인 처리량은 약 157.8–166.6 tok/s였으며, 평균은 약 163 tok/s였습니다.
• 요청당 수치는 약 16.3 tok/s, 즉 61.3 ms/token입니다.
• 컨텍스트 길이(Context length)가 약 3.1배 증가하는 동안 디코딩(Decode) 성능은 3.29배 하락하여, 거의 선형적인 성능 저하를 보였습니다.

SGLang (DCP=8)

• 64K에서 안정적인 처리량은 약 313–418 tok/s였으며, 평균은 약 335 tok/s였습니다.
• 요청당 수치는 약 33.5 tok/s, 즉 29.9 ms/token입니다.
• 200K에서 안정적인 처리량은 약 252–288 tok/s였으며, 평균은 약 268 tok/s였습니다.
• 요청당 수치는 약 26.8 tok/s, 즉 37.3 ms/token입니다.
• 컨텍스트 길이가 약 3.1배 증가하는 동안 디코딩 성능은 1.25배만 하락했습니다.

64K에서는 DCP 통신 오버헤드(communication overhead)가 KV 읽기 감소량보다 크기 때문에 vLLM이 더 빠릅니다. 200K에서는 KV 대역폭(bandwidth)이 주요 병목(bottleneck)이 되며 SGLang의 DCP 이점이 나타납니다.

2. Prefill 성능은 대체로 유사함

두 엔진 모두 32,768-토큰의 프리필(Prefill) 예산을 사용했습니다. 안정적인 총 프리필 처리량은 약 19K–23K tok/s였으며, 이는 8×B300 환경에서 MoE + MLA 프리필 능력이 유사함을 나타냅니다.

vLLM의 64K 실행은 8개의 GPU 전반에 걸쳐 32회의 소프트 OOM(Out of Memory) 재시도와 4개 커널의 런타임 JIT 컴파일(JIT compilation) 영향을 받았습니다. 이러한 이벤트는 테스트 초기에 발생하여 vLLM의 첫 번째 배치 TTFT(Time To First Token)를 더 나쁘게 보이게 만들었습니다. 200K 실행에서는 재현되지 않았으며, SGLang은 일치하는 OOM 또는 JIT 이벤트를 보고하지 않았습니다.

3. SGLang 로그를 통해 드러난 롱 컨텍스트(Long-Context) 프리필 저하

단일 200K 요청에 대해, SGLang은 6개의 청크(chunk) 동안 다음과 같은 처리량을 보고했습니다:

22265 → 21064 → 19628 → 18475 → 17243 → 16408 tok/s

다음 요청이 시작되었을 때 처리량(Throughput)은 약 22K tok/s로 돌아왔습니다. 이는 캐시된 컨텍스트(cached context)가 증가함에 따라 어텐션 비용(attention cost)이 상승함을 직접적으로 보여줍니다. vLLM은 10초 단위의 더 거친(coarser) 집계 프롬프트 처리량(aggregate prompt throughput)을 보고하므로, 로그에서는 동일한 패턴이 덜 명확하게 나타납니다.

DSPARK Speculative Decoding은 큰 가치를 더하지 못함

Random 데이터셋은 사실상 예측 불가능하여, 초안 모델(draft model)이 연속적인 수락 토큰(accepted tokens)을 생성하기 어렵게 만듭니다. 두 엔진 모두 7개의 투기적 토큰(speculative tokens)을 사용하는 Kimi-K3-DSpark를 사용했으나, 200K에서의 평균 수락 길이(average accepted length)는 1에 가까운 상태를 유지했습니다: