Kimi K3 로컬 실행: vLLM, DSpark & 실제 하드웨어 청구서

고급

Moonshot은 2026년 7월 27일 Kimi K3 — 2.8조 파라미터 Mixture-of-Experts 모델 — 를 오픈소스화했습니다. 며칠 만에 r/LocalLLaMA의 "집에서 16× DGX Spark 클러스터로 실행되는 전체 K3" 스레드가 800 업보트를 넘었습니다. 댓글은 감탄과 공황의 혼합이었습니다: 이것이 스턴트인지, 실제 레시피인지, 하드웨어 트랩인지 아무도 알 수 없었습니다.

이 페이지가 그 레시피입니다. 오늘 유일하게 작동하는 로컬 서빙 경로(vLLM), 처리량을 견딜 만하게 만드는 speculative decoding 트릭(DSpark), 실제로 필요한 최소 하드웨어, 정확한 serve 명령, 첫 시도에서 물릴 함정, 그리고 그냥 Moonshot이나 Runpod의 호스팅 엔드포인트를 호출하는 것에 대한 손익분기 계산을 다룹니다. 모델 자체 — 아키텍처, 벤치마크, 가격 — 는 Kimi K3: 세계 최대 오픈 웨이트 모델 참조.

What you'll learn

• 전체 K3의 최소 필수 하드웨어 파악 (1× DGX B300 노드 또는 16× B200 — 오늘 그 아래 경로는 없음)
• DSpark를 한 문단으로 이해: block-diffusion 드래프팅, ~3.14배 스피드업, 스텝당 7 speculative 토큰
• vLLM으로 두 명령으로 K3 서빙 — 대부분의 가이드가 잊는 플래그와 함께
• prefill/decode 비대칭에 직면: 16× DGX Spark 클러스터에서 읽기 750 tok/s vs 쓰기 21 tok/s
• 손익분기 계산: 셀프 호스팅이 $0.95/M 호스팅을 이길 때, 그리고 확실히 그렇지 않을 때

한 문단 버전

오늘 K3를 위한 유일한 프로덕션 준비 서빙 스택은 vLLM으로, 2026년 7월 27일에 DSpark라는 새로운 speculative decoder와 함께 Day-0 지원을 추가했습니다. 최소 하드웨어는 한 개의 8× B300 노드(또는 16× B200); 영웅적인 커뮤니티 셋업은 집에서 16× DGX Spark (GB10) 클러스터로 전체 모델을 실행하며 ~$64k+ 자재 청구서를 내고 대략 디코드 21 tok/s와 prefill 750 tok/s를 제공합니다. 호스팅 추론(Runpod, Moonshot 자체 API)은 입력 $0.95/M, 출력 $4/M입니다 — 거의 모든 팀에게 이것이 옳은 답이며, 특별히 온프렘에 웨이트가 필요하지 않다면 그렇습니다.

1단계 — 사이징 벽 이해

K3는 2.8조 파라미터. Moonshot이 배송하는 형식인 MXFP4 웨이트 양자화에서도, 원시 웨이트는 KV 캐시를 할당하기 전에 약 ~1.4 TB VRAM 주소 지정 메모리에 앉습니다. 그 숫자가 다른 모든 것을 결정합니다.

What you'll learn

• 단일 컨슈머 GPU, Mac Studio, H100 두 개짜리 워크스테이션에서 전체 K3를 실행할 경로는 없음. 사이징은 계단 모양이지 매끄럽지 않음.
• vLLM 가이드는 명확함: 최소 한 개의 8× B300 (또는 GB300 NVL72) 노드가 필요; 16× B200도 지원됨.
• 양자화된 커뮤니티 디스틸(Q2/Q3 또는 전문가 프루닝 배리언트)은 시간이 지나면서 이 바를 낮출 것 — 그러나 2026년 8월 기준 작동하는 레시피는 모두 프론티어 데이터센터 실리콘의 전정밀도 MXFP4.

하드웨어 프로필	현실적 사용	대략 자본비/운영비
1× DGX B300 (8× B300)	프로덕션 셀프 호스팅, 단일 노드	Runpod에서 ~$59/hr; 구매가 6자리
16× B200	이전 세대 셀프 호스팅	Runpod에서 ~$94/hr
16× DGX Spark (GB10) 클러스터	열성가 / 랩	자본비 ~$64k–$75k + 스위치 + 피크 2.3 kW
그 아래는 없음	—	호스팅 API 호출 중

최종 검증: 2026-08-06. 이 페이지에는 시간이 지나면 바뀌는 사실이 인용되어 있습니다 — 위의 날짜를 최신성의 기준으로 삼으세요. 다음에서 확인하세요: 공식 출처.

2단계 — DSpark, 한 문단으로

DSpark는 K3와 함께 배송되고 vLLM에서 네이티브로 지원되는 block-diffusion speculative decoder입니다. 한 번에 한 speculative 토큰을 드래프팅하는 대신(MEDUSA나 EAGLE처럼), DSpark는 5계층 비인과적 어텐션 백본을 사용해 하나의 병렬 패스에서 7 토큰을 드래프트한 다음 K3 타겟에 대해 블록 단위로 그것들을 검증합니다. 저랭크 마르코프 헤드가 블록 내 종속성을 모델링하고, 신뢰도 헤드가 수용 가능성을 예측해 스케줄러가 드래프팅이 가치 있을 때를 결정할 수 있게 합니다.

vLLM 블로그의 구체적 수치:

• DSpark 없이: 배치=1에서 118 tok/s (TP16)
• DSpark로: 배치=1에서 370 tok/s (TP16) — 3.14배 스피드업
• 평균 수용 길이: (14 벤치마크에 걸쳐) 3.85 토큰, 코딩에서 스텝당 4.73 토큰으로 상승, 크리에이티브 라이팅에서 2.61로 하락
• 드래프트-타겟 호환성: DSpark는 K3의 토큰당 576 요소 MLA 잠재를 공유하므로 드래프트 페이지가 타겟 KV 캐시와 통합됨 — 별도 페이지 포맷 없음, 두 번째 캐시를 위한 VRAM 세금 없음

DSpark speculator 웨이트는 Hugging Face의 Inferact/Kimi-K3-DSpark에 있으며; vLLM의 --speculative-config 플래그가 그 모델을 가리킵니다.

3단계 — vLLM으로 K3 서빙

vLLM ≥ 0.11.1이 필요합니다 (K3는 그 릴리스에서 Day-0 지원으로 착륙). 두 명령: 하나는 speculation 없음(움직이는 부품 적음, 스모크 테스트에 유용), 하나는 DSpark 있음(프로덕션에서 실제로 원하는 것).

스모크 테스트 — 순수 K3

DSpark 없이 K3 서빙 (베이스라인)

vllm serve moonshotai/Kimi-K3 \
--tensor-parallel-size 8 \
--enable-prefix-caching \
--trust-remote-code

사람들이 놓치는 두 플래그: **--enable-prefix-caching**은 vLLM에서 기본으로 꺼져 있으며, K3 워크로드(특히 에이전틱 코딩)는 감당할 수 있게 되려면 캐시 히트에 의존합니다 — 이것을 끄면 첫 프롬프트가 매 턴마다 재처리됩니다. **--trust-remote-code**는 K3가 아직 스톡 transformers에 없는 커스텀 모델 코드(KDA 어텐션, LatentMoE 라우팅)를 배송하기 때문에 필수입니다.

프로덕션 — K3 + DSpark

DSpark speculative decoding으로 K3 서빙

vllm serve moonshotai/Kimi-K3 \
--tensor-parallel-size 16 \
--enable-prefix-caching \
--trust-remote-code \
--speculative-config '{"method": "dspark", "model": "Inferact/Kimi-K3-DSpark", "num_speculative_tokens": 7, "attention_backend": "FLASHINFER_MLA", "draft_sample_method": "probabilistic", "rejection_sample_method": "block"}'

num_speculative_tokens: 7은 DSpark speculator의 학습된 블록 크기와 일치 — 낮추지 마세요, block-diffusion 드래프팅의 요점을 낭비하게 됩니다. attention_backend: FLASHINFER_MLA는 MLA 네이티브 드래프트가 타겟과 캐시 페이지를 공유하려면 필수입니다. 결정적 샘플링을 원하면 draft_sample_method를 "greedy"로 전환하고 클라이언트 측에서 temperature=0을 설정하세요.

4단계 — 아무도 경고하지 않는 prefill/decode 비대칭

DSpark 활성화된 **16× DGX Spark (GB10)**에서 전체 K3를 실행하며 MikroTik CRS804-4DDQ 네트워킹과 2.3 kW 피크의 4×400→4×100 Gb 브레이크아웃 케이블을 사용한 커뮤니티 운영자가 게시한 실제 수치:

워크로드	처리량	피크
4k 컨텍스트 @ Prefill	655 tok/s	8,288 tok/s
4k 컨텍스트 @ Decode	21.7 tok/s	37 tok/s
16k 컨텍스트 @ Prefill	759 tok/s	21,457 tok/s
16k 컨텍스트 @ Decode	25.4 tok/s	38 tok/s

읽기가 쓰기보다 30~40배 빠릅니다. 실용적으로 그것은:

• 큰 코드 리포나 리서치 코퍼스에 대한 롱 컨텍스트 Q&A가 아름답게 작동 — 벽 시간 분당 거의 백만 토큰으로 코퍼스를 수집.
• 롱폼 생성, 스트리밍 어시스턴트, 채팅 스타일 UI가 느껴짐 — 25 tok/s는 견딜 만하지만 호스팅 Sonnet/Fable 클래스 모델보다 눈에 띄게 뒤처짐.
• 모델이 긴 도구 호출 체인을 생성하는 에이전틱 루프는 디코드 병목을 확대. 더 간결한 추론 스타일과 구조화된 출력을 고려.
• 배칭이 prefill보다 decode를 더 돕는다 — 동시 요청이 증가하면서 GPU 초당 처리량이 급격히 상승 (vLLM 블로그는 높은 동시성에서 GPU 초당 2K+ 토큰을 보고).

최종 검증: 2026-08-06. 이 페이지에는 시간이 지나면 바뀌는 사실이 인용되어 있습니다 — 위의 날짜를 최신성의 기준으로 삼으세요. 다음에서 확인하세요: 공식 출처.

5단계 — 첫 주 운영 스레드의 다섯 함정

Guided walkthrough1 of 5

1. vLLM 블로그를 제외한 모든 서빙 가이드가 이것을 잊음. --enable-prefix-caching 없이는 K3의 90% 이상 실제 캐시 히트율이 0%가 되고 매 턴마다 전체 프롬프트가 재처리됨. 비용과 지연 시간 둘 다 폭발. 한 번 설정, 영원히.

6단계 — 셀프 호스팅해야 할까?

대부분의 팀에게 정직한 답은 아니오입니다. 워크로드별로 손익분기 계산을 하세요:

경로	비용	이길 때
Moonshot API	입력 $3.00/M, 캐시 히트 $0.30/M, 출력 $15/M	프로토타이핑, 저볼륨, 비민감 데이터
Runpod 호스팅 K3	입력 $0.95/M, 출력 $4/M	꾸준한 중간 볼륨, OpenAI 호환 엔드포인트 필요, 컴퓨트가 어디서 실행되는지 상관 없음
Runpod 8× B300 시간당	$59.12/hr	갑작스러운 실행, 서빙 설정 제어 필요, 여전히 자본비 원치 않음
하드웨어 소유	자본비 $80k–$500k+	엄격한 데이터 상주성, 24/7 포화, 또는 경쟁 추론 제품 구축 중

16× GB10 클러스터의 디코드 ~21 tok/s에서, 한 노드는 시간당 ~76k 출력 tok를 생산. Runpod-K3 호스팅 가격으로 그것은 시간당 $0.30의 출력 토큰. $59/hr 호스팅 요금을 이기려면 높은 배치에서 시간당 ~15M 출력 토큰에 가까운 처리량과 100%에 가까운 활용도가 필요 — 동시성으로 달성 가능하지만, 실제로 그만큼의 수요가 있어야 함. 그 아래로는 호스팅이 자릿수로 이깁니다.

2026년 K3를 셀프 호스팅할 올바른 이유:

• 데이터 상주성 / 규제 — 프롬프트와 완성이 VPC를 떠날 수 없음.
• 지속적 포화 — 24/7 실행되는 에이전트 함대가 있고 캐시 히트 가격이 여전히 아픔.
• 모델 수정 — 커스텀 DSpark speculator 학습, MoE 전문가에서 LoRA 파인튜닝, 또는 라우팅 변경 실험.
• 학습 가치 — 랩이나 프론티어 MoE 서빙을 메탈에서 특별히 이해하고 싶은 팀.

그중 아무것도 적용되지 않으면, API를 호출하고 저장된 엔지니어링 시간을 더 나은 프롬프트, 더 나은 evals, 더 나은 컨텍스트 엔지니어링으로 라우팅하세요.

7단계 — 어떤 경로를 선택하든 최소 Python 클라이언트

vLLM은 OpenAI 호환 엔드포인트를 노출하므로, 같은 클라이언트가 자체 랙, Runpod의 호스팅 K3, 또는 Moonshot의 API에 대해 작동합니다.

OpenAI Python SDK로 K3 엔드포인트 호출

from openai import OpenAI

client = OpenAI(
  base_url="http://localhost:8000/v1",   # or Runpod / Moonshot base URL
  api_key="EMPTY",                        # self-hosted vLLM ignores keys
)

resp = client.chat.completions.create(
  model="moonshotai/Kimi-K3",
  messages=[
      {"role": "system", "content": "You are a terse coding assistant."},
      {"role": "user",   "content": "Explain DSpark speculative decoding in three bullets."},
  ],
  max_tokens=8192,
  temperature=0.2,
)

print(resp.choices[0].message.content)

플래시카드 — 차갑게 알아야 할 수치

아직 카드가 없습니다 — 추가해서 학습을 시작하세요. 🃏

퀴즈

Check yourself

0/4

1. 1분석가가 200k 토큰 리서치 코퍼스와 대화하게 하는 내부 도구를 초안 작성 중입니다. 첫 토큰 지연 시간이 중요하고 사용자당 토큰 볼륨은 낮습니다. K3를 셀프 호스팅해야 합니까?
2. 2첫 프로덕션 K3 서빙에 가장 안전한 vLLM 플래그 조합은?
3. 3DSpark는 하나의 병렬 패스에서 7 토큰을 드래프트합니다. 실제로 그 7 중 몇 개가 스텝당 K3에 의해 일반적으로 수용됩니까?
4. 416× DGX Spark 박스를 책상에 둡니다. 사용자에게 기대하라고 말해야 할 처리량 프로필은?

대신 호스팅 경로를 잡을 때

• 프로토타이핑과 데모 — Moonshot의 API 또는 Runpod 사용. 지연 시간과 가격 둘 다 괜찮음.
• 비용 민감 고볼륨 — Moonshot의 캐시 히트 입력 $0.30/M 가격은 워크로드가 실제로 캐시할 때 이길 수 없음.
• Claude Code나 다른 하니스로 에이전틱 코딩 — AI 게이트웨이 (LiteLLM / OpenRouter / Portkey)를 통해 K3를 꽂고 하니스 변경 없이 모델 교체.
• 모델 비교 작업 — K3가 옳은 선택일 때 vs Anthropic에 남을 때는 모델 선택과 Claude 사용자를 위한 Kimi K3 참조.

최종 검증: 2026-08-06. 이 페이지에는 시간이 지나면 바뀌는 사실이 인용되어 있습니다 — 위의 날짜를 최신성의 기준으로 삼으세요. 다음에서 확인하세요: 공식 출처.

출처 및 추가 자료

• Kimi K3 Is Here: Efficient Day-0 Support on vLLM — vLLM Blog (2026-07-27) — 표준 서빙 가이드와 DSpark 벤치마크.
• Inferact/Kimi-K3-DSpark — Hugging Face 모델 카드 — 드래프트 모델 아키텍처, 계층 선택 세부사항, 샘플링 플래그.
• 16× GB10 클러스터에서 실행되는 전체 Kimi K3 — NVIDIA 개발자 포럼 — 위에서 인용한 커뮤니티 처리량 수치와 네트워킹 레시피.
• Runpod에 Kimi K3 배포 — 호스팅 K3 가격과 B300/B200 시간당 요금.
• Moonshot AI — Kimi K3 블로그 — 공식 모델 카드, MoE 구성, MXFP4 양자화 노트.
• Kimi K3: 세계 최대 오픈 웨이트 모델 — 모델의 아키텍처, 벤치마크, 가격 계산을 다루는 동반 AILmanac 페이지.