Kimi K3를 로컬에서 어떻게 배포하나요?

TL;DR

Kimi K3는 오픈 웨이트이지만 워크스테이션 규모 모델은 아니다. 네이티브 모델 서빙에는 데이터센터급 GPU와 분산 메모리가 필요하다. 프로덕션으로 가장 직행하려면 vLLM을, 토폴로지·전문가 병렬화·캐시 제어가 중요하면 SGLang을 쓰자. 커뮤니티 GGUF 빌드는 하드웨어 문턱을 낮추지만, 여전히 대략 500 GB에서 1 TB+의 주소 지정 가능한 메모리가 필요하며, 현실성을 위해 속도 또는 품질을 희생한다. 일반 PC와 Mac에서는 우선 호스팅 API로 테스트하고, 프라이버시·지속적 활용·인프라 통제가 비용을 정당화할 때만 자체 호스팅하라.

What Is Kimi K3?

Kimi K3는 장기 지평 코딩, 에이전트형 지식 작업, 추론, 시각 이해를 위한 Moonshot AI의 오픈 웨이트 네이티브 멀티모달 플래그십 모델이다.

Moonshot은 이를 세계 최초의 오픈 3T급 모델로 설명한다. 아키텍처는 Kimi Delta Attention and Attention Residuals와, 토큰마다 일부 전문가만 선택하는 스파스 MoE 설계를 결합한다.

규모는 프런티어 모델 기준으로도 이례적이다. 모든 2.8T 파라미터를 매 토큰마다 활성화하는 대신, K3는 896개 라우팅 전문가 중 16개와 공유 전문가를 선택한다. 이는 토큰당 연산을 크게 줄이지만, 추론 시스템 어딘가에는 모든 모델 가중치가 여전히 상주해야 한다.

K3는 저정밀 서빙을 단순 사후 압축 단계로 보지 않고, SFT 단계부터 양자화 인지형 학습을 적용한다.

따라서 아키텍처는 초대형 규모 서빙에 최적화되어 있지만, “스파스 연산”이 “작은 메모리 풋프린트”를 의미하는 것은 아니다. 매 토큰에 네트워크의 일부만 계산하더라도, 전체 전문가 풀에 접근 가능해야 한다.

How Does Kimi K3 Perform?

Moonshot의 공식 Kimi K3 벤치마크 모음은, 특히 장기 지평 소프트웨어 엔지니어링과 에이전트 워크로드에서 모델을 선도적 클로즈드 프런티어 모델에 근접하게 위치시킨다.

다음은 추론, 코딩, 에이전트, 비전을 다룬 발췌다. 아래 모든 점수는 높을수록 좋다.

공식 점수는 Kimi K3를 추론, 코딩, 에이전트, 비전 전반에서 GPT-5.6 Sol, Claude Fable 5, Claude Opus 4.8에 근접하게 놓는다. 이 공급자 보고 결과는 보편적 순위가 아니라 능력의 맥락으로 받아들이자. 상세 벤치마크 분석은 별도로 다룬다. 이 가이드의 운영 측면 포인트는, 자체 호스팅이 프런티어급 능력과 인프라 통제를 제공하지만 저비용 데스크톱 지름길은 아니라는 점이다.

Can You Actually Run Kimi K3 Locally?

가능하다. 다만 “로컬”에는 매우 다른 두 의미가 있다.

로컬 서버/프라이빗 데이터센터: 현실적.

일반 데스크톱 또는 노트북: 커뮤니티의 공격적 양자화 빌드로 기술적으로 실험 가능하지만, 대화형 사용에는 일반적으로 비현실적.

현재 vLLM Kimi K3 레시피는 매우 높은 기준선을 제시한다:

• NVIDIA: 최소 8× GB300
• AMD ROCm: 최소 8× MI355X 또는 MI350X
• NVIDIA 드라이버: 현재 CUDA 13 K3 이미지용 R580+
• 실제 프로덕션 트래픽에는 멀티 노드 인프라 권장

오리지널 vLLM 데이-0 가이드는 8-GPU B300 또는 8-GPU MI355X 퀵스타트 경로도 시연했다. 신규 프로덕션 배포에서는 출시일 최적화 이후의 서빙 스택을 반영한 최신 레시피를 따르자.

핵심 포인트: K3는 오픈 웨이트이지만, 소비자 규모의 오픈 모델은 아니다.

Official Weights vs Community GGUF Quantizations

하드웨어 문턱을 낮추는 또 다른 방법은 커뮤니티 양자화다.

현재 Unsloth K3 저장소는 llama.cpp 호환 소프트웨어로 구동 가능한 여러 GGUF 변형을 제공한다.

통합 비교. 주소 지정 가능한 메모리 수치는 계획 추정치(다운로드 크기 + 약 10–15% 런타임 여유)이며 보장은 아니다. 컨텍스트, 캐시, 비전, 오프로딩 설정에 따라 더 많이 필요할 수 있다.

이 구분은 일부 초기 로컬 배포 기사에서 594 GB가 언급된 이유도 설명한다. 현재 594 GB는 커뮤니티 UD-IQ1_S GGUF 빌드에 해당하며, 최신 네이티브 체크포인트 전체를 유용하게 설명하는 수치가 아니다.

466–649 GB 모델은 원래 배포 풋프린트보다 훨씬 작지만, 워크스테이션 기준으로는 여전히 거대하다. 또한 런타임 상태, 컨텍스트, 캐시, 비전 프로젝터, 운영체제 프로세스 및 기타 오버헤드를 위한 메모리를 남겨야 한다.

디스크 용량은 추론 메모리와 동일하지 않다. 1 TB SSD가 있다고 해서 64 GB RAM 머신에서 600 GB 모델이 빠르게 실행되는 것은 아니다. SSD 오프로딩은 극단적 실험을 기술적으로 가능하게 만들지만, 토큰 생성은 매우 느려질 수 있다.

How to Deploy Kimi K3 with vLLM

진지한 자체 호스팅에는 vLLM이 가장 직관적인 출발점이다.

Moonshot은 현재 vLLM을 K3 추론 엔진 권장 대상 중 하나로 제시하며, vLLM은 KDA, MXFP4 MoE, 리즈닝 파싱, 도구 호출, 프리픽스 캐싱, 분산 배포에 대한 K3 모델 전용 지원을 제공한다.

Check the prerequisites

NVIDIA 프로덕션 배포의 경우, 현재 검증된 레시피는 vllm/vllm-openai:kimi-k3 컨테이너를 사용한다.

GPU 확인:

nvidia-smi

Docker 확인:

docker --version

NVIDIA Container Toolkit이 가속기를 인식하는지 확인:

docker run --rm --gpus all nvidia/cuda:13.0.0-base-ubuntu24.04 nvidia-smi

마지막 명령이 모든 GPU를 보지 못한다면, 수 TB급 모델을 다운로드하기 전에 호스트/컨테이너 GPU 런타임을 먼저 수정하라.

Set your Hugging Face token

모델 저장소 인증이 필요한 경우, 스크립트에 하드코딩하지 말고 환경 변수에 토큰을 저장하라.

export HF_TOKEN="YOUR_HUGGING_FACE_TOKEN"

Pull the K3 vLLM container

docker pull vllm/vllm-openai:kimi-k3

현재 레시피는 CUDA 13 빌드와 R580 이상 NVIDIA 드라이버를 지정한다.

Launch Kimi K3

현재 Blackwell TP8 시작 템플릿(vLLM 레시피 2026-09-10 업데이트): 이를 기준으로 사용한 뒤, 실제 하드웨어와 트래픽에 맞춰 프로파일을 재생성하거나 벤치마크하라.

docker run --rm \
  --gpus all \
  --ipc=host \
  -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -e HF_TOKEN="$HF_TOKEN" \
  -e VLLM_USE_V2_MODEL_RUNNER=1 \
  vllm/vllm-openai:kimi-k3 \
  --model moonshotai/Kimi-K3 \
  --tensor-parallel-size 8 \
  --gpu-memory-utilization 0.95 \
  --kv-cache-dtype fp8 \
  --attention-backend TOKENSPEED_MLA \
  --attention-config '{"use_prefill_query_quantization":true,"mla_prefill_backend":"TOKENSPEED_MLA"}' \
  --prefix-match-unit 128 \
  --enable-prefix-caching \
  --max-model-len 131072 \
  --enable-auto-tool-choice \
  --tool-call-parser kimi_k3 \
  --reasoning-parser kimi_k3

현재 레시피는 K3 CUDA 13 이미지와 R580 이상 NVIDIA 드라이버를 요구한다. FP8 KV 캐시는 호환되는 MLA prefill/decode 백엔드와 함께 사용해야 한다. 주의 구성은 변경 전에 대안을 벤치마크하라.

출처: vLLM Kimi K3 레시피. 이는 이전 데이-0 커맨드를 현재 프로덕션 레시피로 대체한다.

초기 검증 실행에서는 전체 1,048,576 토큰 능력을 즉시 잡지 말고, 최대 모델 길이를 제한하는 것을 고려하라. 현재 vLLM 레시피는 워크로드에 맞게 max-model-len 조정을 명시적으로 권장한다.

예:

--max-model-len 131072

이는 K3의 아키텍처적 컨텍스트 한계를 바꾸지 않는다. 단지 초기 테스트용으로 서빙 엔진에 더 관리 가능한 운용 범위를 부여한다.

Test the local endpoint

vLLM은 8000 포트에서 OpenAI 호환 API를 노출한다.

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "moonshotai/Kimi-K3",
    "messages": [
      {
        "role": "user",
        "content": "Explain the difference between tensor parallelism and expert parallelism."
      }
    ],
    "max_tokens": 512
  }' 

또는 OpenAI Python SDK를 사용:

Python

from openai import OpenAI

 client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="EMPTY",
    timeout=3600,
 )

response = client.chat.completions.create(
    model="moonshotai/Kimi-K3",
    messages=[
        {
            "role": "user",
            "content": "Write a Python function that validates a JSON schema.",
        }
    ],
    max_tokens=1024,
 )

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

공식 vLLM 레시피도 동일한 localhost OpenAI 호환 패턴을 사용하므로, 애플리케이션을 로컬과 호스팅 추론 사이에서 비교적 쉽게 전환할 수 있다.

How to Deploy Kimi K3 with SGLang

SGLang은 Moonshot이 공식 권장하는 또 다른 주요 배포 경로다.

분산 서빙, 전문가 병렬화, 하드웨어 특화 커널, 복잡한 프로덕션 토폴로지에 더 깊은 통제가 필요할 때 특히 유용하다.

전용 SGLang Kimi K3 Cookbook을 사용해 하드웨어별 토폴로지를 선택하라. 아래는 cookbook에서 검증된 단일 노드 8×B300 Unified/Balanced 프로파일이며, SGLang v0.5.18(커밋 71de97b2)에서 측정되었다.

K3 호환 빌드 설치:

pip install --upgrade pip
pip install uv
uv pip install --prerelease=allow sglang

검증된 B300 TP8/DCP8 프로파일 실행:

sglang serve \
  --trust-remote-code \
  --model-path moonshotai/Kimi-K3 \
  --tp-size 8 \
  --dcp-size 8 \
  --mem-fraction-static 0.85 \
  --mamba-full-memory-ratio <value-from-official-calculator> \
  --reasoning-parser kimi_k3 \
  --tool-call-parser kimi_k3 \
  --host 0.0.0.0 \
  --port 30000

--mamba-full-memory-ratio는 워크로드 의존적이다. 공식 cookbook에서 평균 입력+출력 길이에 따라 계산하라. 이 B300 토폴로지를 H100/H200, GB200/GB300, AMD, 멀티 노드 배포에 복사하지 말라. 해당 환경은 서로 다른 TP/PP/DCP/EP 레이아웃을 사용한다.

서버 테스트:

curl http://localhost:30000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "moonshotai/Kimi-K3",
    "messages": [{"role": "user", "content": "Give me a five-step debugging plan for a distributed Python application."}]
  }'

실제 배포에서는 의도한 정확한 SGLang 버전, 토폴로지, 컨텍스트 길이, 트래픽 믹스에서 용량, 출력 품질, 장애 복구를 검증하라.

vLLM vs SGLang vs llama.cpp

추론 엔진 선택은 주로 하드웨어와 배포 목적에 좌우된다.

8-GPU Blackwell/MI35x급 서버를 보유했다면 vLLM부터 시작하라.

특화된 분산 추론 클러스터를 설계하며 더 저수준의 서빙 제어가 필요하다면 SGLang도 평가하라.assistant_message

목표가 “내가 가진 하드웨어에서 K3가 실행됨을 증명”이라면, 머신에 정말 예외적 수준의 메모리가 있다는 전제하에 GGUF + llama.cpp가 훨씬 접근하기 쉽다.

How to Run a Quantized Kimi K3 with llama.cpp or Ollama

커뮤니티 Kimi K3 GGUF 저장소는 이제 llama.cpp 호환 변형을 제공한다.

이 경로는 데이터센터 네이티브 웨이트 배포에 비해 진입 장벽을 크게 낮추지만, “크게”는 상대적이다. 작은 빌드조차 수백 기가바이트다.

Install llama.cpp on macOS or Linux

현재 GGUF 모델 카드는 다음을 제공한다:

curl -LsSf https://llama.app/install.sh | sh

Windows:

winget install llama.cpp

Start an OpenAI-compatible server

저장소는 현재 UD-Q4_K_XL을 예시로 문서화한다:

llama serve \
  -hf unsloth/Kimi-K3-GGUF:UD-Q4_K_XL

CLI를 직접 실행할 수도 있다:

llama cli \
  -hf unsloth/Kimi-K3-GGUF:UD-Q4_K_XL

이 명령은 현재 Kimi K3 GGUF 모델 카드에서 그대로 가져왔다.

하지만 UD-Q4_K_XL은 약 1.51 TB이므로, 대부분의 워크스테이션 사용자가 시작할 변형은 아니다. 우선순위가 품질 보존보다 메모리 요구량 축소라면, 더 작은 1비트/2비트 변형부터 확인하라.

예:

llama serve \
  -hf unsloth/Kimi-K3-GGUF:UD-IQ1_M

현재 UD-IQ1_M 디렉토리는 대략 649 GB다.

649 GB 모델도 일반적인 노트북용은 아니다. 자주 접근되는 모델 상태는 이상적으로 빠른 메모리에 상주해야 한다. 무거운 SSD 오프로딩은 극단적 실험을 기술적으로 가능하게 만들 수 있지만, 대화형 작업에는 유용하지 않을 수 있다.

Run the Same GGUF Build with Ollama

Ollama는 동일한 GGUF 배포 경로를 위한 편의 레이어일 뿐, 네 번째 독립적인 자체 호스팅 방법이 아니다.

K3 GGUF 저장소는 Ollama 경로도 제공한다.

예:

bash

ollama run hf.co/unsloth/Kimi-K3-GGUF:UD-Q4_K_XL

Ollama는 모델 관리와 API 경험을 단순화하지만, K3의 메모리 요구사항을 바꾸지는 않는다.

런처를 llama.cpp에서 Ollama로 바꾼다고 해서 수백 GB 양자화 모델이 24 GB GPU 모델로 변하는 것은 아니다. 기본 모델 데이터는 여전히 저장·접근되어야 한다.

이런 이유로, Ollama는 하드웨어 우회가 아니라 편의성 중심 런타임 래퍼로 보는 것이 적절하다.

Which Kimi K3 Quantization Should You Choose?

실험 목적이라면 선택은 주로 모델 크기와 충실도 간의 절충이다.

Important Kimi K3 Serving Behavior

간과하기 쉬운 K3 전용 구현 세부사항이 하나 있다.

K3는 보존된 사고 기록을 사용한다. Moonshot은 멀티턴 대화와 도구 호출 워크플로에서, reasoning_content와 tool_calls를 포함한 이전 assistant 메시지 전체를 모델에 다시 전달할 것을 권장한다. 보이는 content만 유지하는 방식은 권장되지 않는다.

단순화된 애플리케이션 패턴은 다음과 같다:

messages = [
    {
        "role": "user",
        "content": "Inspect this project and propose a migration plan.",
    }
 ]

first = client.chat.completions.create(
    model="moonshotai/Kimi-K3",
    messages=messages,
    max_tokens=2048,
 )

assistant_message = first.choices[0].message

 # Preserve the whole message object, not just assistant_message.content.
 messages.append(
    assistant_message.model_dump(exclude_none=True)
 )

messages.append(
    {
        "role": "user",
        "content": "Now identify the riskiest part of that plan.",
    }
 )

second = client.chat.completions.create(
    model="moonshotai/Kimi-K3",
    messages=messages,
    max_tokens=2048,
 )

이는 코딩 에이전트, 도구 루프, 장시간 자율 세션에서 특히 중요하다.

K3는 리즈닝을 기본 활성화하며 low, high, max 리즈닝 노력을 지원한다. 서빙 레이어가 해당 파라미터를 노출한다면, 리즈닝 노력은 항상 최대화하기보다 지연/품질 제어 수단으로 다뤄라.

How to Optimize a Local Kimi K3 Deployment

1M 컨텍스트를 즉시 할당하지 말 것

K3는 1,048,576 토큰을 지원하지만, 최대 모델 능력과 합리적인 서버 구성은 별개다.

개발에서는 다음과 같이 시작하라:

--max-model-len 131072

이후 사용 가능한 메모리, 첫 토큰까지 시간, 처리량, 예상 동시성을 측정한 뒤 컨텍스트를 늘려라.

프리픽스 캐싱 활성화

코딩 에이전트는 저장소 지침, 도구 스키마, 시스템 프롬프트, 긴 프리픽스를 자주 재사용한다.

vLLM에서는:

--enable-prefix-caching

K3의 하이브리드 어텐션 아키텍처는 프리픽스 캐싱에 대한 특별 처리가 필요했고, vLLM은 모델 전용 지원을 구현했다.

K3 파서 사용

에이전트 워크로드에서는 다음을 포함하라:

--tool-call-parser kimi_k3 \
--reasoning-parser kimi_k3

이로써 도구 호출과 리즈닝 출력이 K3의 서빙 포맷과 정렬된다.

스토리지는 빠르게 유지

이 규모의 모델은 최초 다운로드, 체크포인트 로딩, 업데이트, 복구 중 로컬 스토리지에 비정상적 부하를 가한다.

NVMe 스토리지는 느린 네트워크 마운트 디스크보다 바람직하다. 여러 머신이 모델 파일을 공유하는 경우, 모델 캐시 토폴로지와 네트워크 대역폭은 단순 배포 세부가 아니라 추론 아키텍처의 일부가 된다.

GPU 활용도만 보지 말고 모니터링 범위를 확장

다음을 추적하라:

• HBM/VRAM 사용률
• CPU RAM
• 캐시 적중률
• 첫 토큰까지 시간
• 디코드 토큰/초
• 요청 대기열 깊이
• GPU 간 통신
• 노드 간 대역폭
• 도구 호출 파싱 실패
• 모델 로딩 시간

K3 규모에서는 겉보기 GPU 활용도가 토폴로지 효율을 보장하지 않는다.

Local Kimi K3 vs Hosted Kimi K3

자체 호스팅은 데이터 경로·런타임·모델 웨이트에 대한 최대 통제를 제공하는 반면, GPU 용량·스케일링·업그레이드·모니터링·복구 책임도 따른다. 호스팅 액세스는 대부분의 인프라 작업을 제거하며 평가나 변동 수요에 더 빠르다.

전체 하드웨어 및 손익분기 분석은 Kimi K3 Self-Hosting vs API를 읽어라. 토큰 가격, 캐싱, K2.7 비교는 Kimi K3 가격 가이드를 참고하라. 본 문서는 비교를 간략히 하고 배포 명령, 구성, 트러블슈팅에 집중한다.

Common Kimi K3 Local Deployment Problems

모델이 GPU 메모리에 맞지 않음

가장 예측 가능한 실패다.

메모리를 104B 활성화 파라미터로 계산하지 말라. 이 수치는 토큰당 연산을 설명할 뿐, 서빙 시스템이 접근 가능해야 하는 전문가 가중치 데이터 양을 의미하지 않는다.

지원되는 분산 토폴로지, 더 작은 GGUF 양자화, 또는 호스팅 서비스를 사용하라.

CUDA 또는 NVIDIA 드라이버 오류

현재 vLLM K3 이미지는 CUDA 13 기반이며 R580+ 호스트 드라이버가 필요하다.

호스트가 여전히 R575/CUDA 12.9 스택이라면, 업데이트하거나 컨테이너가 호스트 드라이버 비호환을 해결해줄 것이라 가정하지 말고 vLLM의 소스 빌드 경로를 따르라.

첫 요청이 매우 느림

체크포인트 로딩, 커널 컴파일, 캐시 워밍, 파일 풀링이 진행 중인지 확인하라.

수 TB급 에셋에서는 “서버 프로세스 시작”과 “모델이 프로덕션 트래픽 처리 가능”이 동일 상태가 아니다.

도구 호출이 간헐적으로 실패

현재 vLLM 레시피는 K3가 때때로 파서가 예상하지 않는 도구 호출 형태를 생성할 수 있음을 언급한다. 따라서 프로덕션 시스템은 생성된 호출을 맹신하지 말고 도구 호출 스키마를 검증하고 재시도를 구현해야 한다.

긴 대화가 덜 안정적이 됨

이후 K3 턴에 전체 assistant 메시지—리즈닝과 도구 정보 포함—를 반환하고 있는지 확인하라.

숨겨진 리즈닝 상태 필드를 누락하면, K3가 학습한 보존된 사고 기록 패턴이 깨질 수 있다.

So, What Is the Best Way to Deploy Kimi K3 Locally?

적합한 하드웨어를 가진 대부분의 조직에는 vLLM이 첫 배포 경로로 최선이다. K3 전용 지원, OpenAI 호환 API, 모델 전용 파서, 프리픽스 캐싱, 추측 디코딩 지원, 최신 하드웨어 레시피를 갖추고 있다.

분산 추론 엔지니어링과 미세한 서빙 제어가 최우선이라면 SGLang을 선택하라.

워크스테이션/서버 실험이 목적이고, 1비트 버전도 여전히 수백 GB임을 이해한다면, 커뮤니티 GGUF + llama.cpp를 선택하라.

일반 개발자 워크스테이션에서는 결론이 다르다. K3를 데스크톱에 억지로 올리기 위해 수백 GB RAM을 구매하지 말라. 먼저 CometAPI를 통해 Kimi K3를 테스트해 자체 과제에서의 효과를 정량화하고, 프라이버시·지속적 활용·인프라 통제가 경제성을 뒷받침할 때만 자체 호스팅으로 전환하라.

FAQ

Can Kimi K3 run on a single consumer GPU?

현실적이지 않다. 모델은 소비자 GPU의 VRAM 용량을 훨씬 상회한다. 커뮤니티 저비트 GGUF 양자화는 풋프린트를 크게 줄이지만, 현재 가장 작은 변형도 여전히 수백 기가바이트다.

Can I run Kimi K3 on a Mac?

GGUF와 스토리지 오프로딩을 통한 실험적 CPU/Apple Silicon 실행은 원칙적으로 가능하나, 대화형 성능과 메모리 용량이 한계다. 일반적인 MacBook은 실용적 K3 서빙 플랫폼으로 취급되어서는 안 된다.

Does Kimi K3 support Ollama?

커뮤니티 GGUF 빌드는 Ollama로 실행 가능하다. 런타임은 설정을 단순화하지만, 기본 메모리 요구사항을 바꾸지는 않는다.

Is vLLM or SGLang better for Kimi K3?

신규 프로덕션 배포에는 vLLM이 더 쉽다. 정교한 분산 서빙 토폴로지를 구축하는 팀에는 SGLang이 매력적이다. 둘 다 Moonshot의 K3 추론 엔진 권장 대상이다.

How much context does Kimi K3 support?

공식 모델 사양은 1,048,576 토큰을 지원한다. 로컬 서버가 전체 컨텍스트 창을 반드시 노출할 필요는 없다. 초기 배포와 높은 동시성에는 낮은 max-model-len이 더 실용적일 수 있다.

Is Kimi K3 open source?

보다 정확히는 오픈 웨이트다. Moonshot은 Kimi K3 License 하에 모델 웨이트를 공개했다. 상업적 재배포 등 라이선스가 중요한 사용 전에는 라이선스를 직접 검토하라.

What is the easiest way to use Kimi K3 without local GPUs?

호스팅 API가 가장 간단한 경로다. Kimi K3는 CometAPI에서 OpenAI 호환 chat-completions 인터페이스로 제공되므로, 애플리케이션 코드는 로컬 vLLM 또는 SGLang 서버를 대상으로 하는 것과 거의 동일하게 유지할 수 있다.