llm-d 기반 EKS 분산 추론 배포 가이드

📌 현재 버전: llm-d v0.4 (2025). 본 문서의 배포 예시는 Intelligent Inference Scheduling well-lit path 기준입니다.

📅 작성일: 2026-02-10 | 수정일: 2026-03-16 | ⏱️ 읽는 시간: 약 10분

개요

llm-d는 Red Hat이 주도하는 Apache 2.0 라이선스의 Kubernetes 네이티브 분산 추론 스택입니다. vLLM 추론 엔진, Envoy 기반 Inference Gateway, 그리고 Kubernetes Gateway API를 결합하여 대규모 언어 모델의 지능적인 추론 라우팅을 제공합니다.

기존 vLLM 배포가 단순한 Round-Robin 로드 밸런싱에 의존하는 반면, llm-d는 KV Cache 상태를 인식하는 지능적 라우팅을 통해 동일한 prefix를 가진 요청을 이미 해당 KV Cache를 보유한 Pod로 전달합니다. 이를 통해 Time To First Token(TTFT)을 크게 단축하고 GPU 연산을 절약할 수 있습니다.

llm-d는 EKS의 다양한 노드 관리 방식에서 배포할 수 있으며, 모델 크기와 GPU 활용 전략에 따라 최적의 배포 방식이 달라집니다. 본 문서에서는 EKS Auto Mode 환경을 기본 배포 예시로 다루되, Karpenter 자체 관리 환경과의 차이점과 선택 기준도 함께 안내합니다.

배포 전략 선택: Auto Mode vs Karpenter

llm-d의 핵심 가치인 KV Cache-aware 라우팅은 배포 환경에 관계없이 동일하게 동작합니다. 그러나 GPU 리소스 분할(MIG, Time-Slicing) 이 필요한 경우에는 EKS Auto Mode가 아닌 Karpenter + GPU Operator 환경을 선택해야 합니다.

기준	EKS Auto Mode	Karpenter + GPU Operator
적합한 모델 크기	70B+ (GPU 전체 활용)	7B~30B (MIG로 분할 가능)
GPU 드라이버 관리	AWS 자동 관리	직접 설치 (GPU Operator)
MIG / Time-Slicing	불가	가능
운영 복잡도	낮음	중간
GPU 비용 효율	대형 모델에 최적	소형 모델에 최적

모델 크기별 상세 비용 분석과 의사결정 플로차트는 EKS GPU 노드 전략을 참조하세요.

llm-d Inference Gateway ≠ 범용 Gateway API 구현체

llm-d의 Envoy 기반 Inference Gateway는 LLM 추론 요청 전용으로 설계된 특수 목적 게이트웨이입니다. NGINX Ingress Controller를 대체하는 범용 Gateway API 구현체(AWS LBC v3, Cilium, Envoy Gateway 등)와는 목적과 스코프가 다릅니다.

llm-d Gateway: InferenceModel/InferencePool CRD 기반, KV Cache-aware 라우팅, 추론 트래픽 전용
범용 Gateway API: HTTPRoute/GRPCRoute 기반, TLS/인증/Rate Limiting, 클러스터 전체 트래픽 관리

프로덕션 환경에서는 범용 Gateway API 구현체가 클러스터 진입점을 담당하고, llm-d는 그 하위에서 AI 추론 트래픽을 최적화하는 구조를 권장합니다. 범용 Gateway API 구현체 선택은 Gateway API 도입 가이드를 참조하세요.

주요 목표

llm-d 아키텍처 이해: Inference Gateway와 KV Cache-aware 라우팅의 동작 원리
배포 전략 선택: Auto Mode vs Karpenter 환경별 장단점 비교
EKS Auto Mode GPU 구성: p5.48xlarge 노드 자동 프로비저닝 설정
Qwen3-32B 배포: helmfile 기반 통합 배포 및 검증
추론 테스트: OpenAI 호환 API를 통한 추론 요청 및 스트리밍
운영 최적화: 모니터링, 비용 최적화, 트러블슈팅

llm-d의 3가지 Well-Lit Path

llm-d는 세 가지 검증된 배포 경로를 제공합니다.

llm-d's 3 Well-Lit Paths

Intelligent Inference SchedulingRECOMMENDED

Intelligent request distribution with KV Cache-aware routing

📌 General-purpose LLM serving (this guide)

Prefill/Decode Disaggregation

Separates Prefill and Decode stages for processing

📌 Large batch processing, long context handling

Wide Expert-Parallelism

Distributes MoE model Experts across multiple nodes

📌 MoE models (Mixtral, DeepSeek, etc.)

아키텍처

llm-d의 Intelligent Inference Scheduling 아키텍처는 다음과 같이 구성됩니다.

llm-d vs 기존 vLLM 배포 비교

llm-d vs Traditional vLLM Deployment Comparison

Feature	Traditional vLLM Deployment	llm-d Deployment ✨
Routing Method	Round-Robin / Random	KV Cache-aware Intelligent Routing
Gateway Integration	Separate Ingress/Service configuration	Native Gateway API integration
Scaling Management	Manual HPA configuration	Automatic management via InferencePool
KV Cache Utilization	Independent management per Pod	Cross-pod prefix reuse for reduced TTFT
Installation Method	Combining individual Helm charts	Unified helmfile deployment (single command)
Model Definition	Writing Deployment YAML directly	Declarative management via InferenceModel CRD

Qwen3-32B 모델 선정 이유

Why Qwen3-32B Was Selected

Model Name

Qwen/Qwen3-32B

Parameters

32B (Dense)

License

Apache 2.0

Precision

BF16 (~65GB VRAM)

Context

Up to 32,768 tokens

Features

Official default model for llm-d, excellent multilingual support, most popular among open-source LLMs

Qwen3-32B 선정 배경

Qwen3-32B는 llm-d의 공식 기본 모델이며, Apache 2.0 라이선스로 상업적 사용이 자유롭습니다. BF16 기준 약 65GB VRAM이 필요하여 TP=2 (2× GPU)로 H100 80GB에서 안정적으로 서빙할 수 있습니다.

사전 요구사항

Prerequisites

Item	Requirement	Notes
AWS Account	p5.48xlarge quota approved	Service Quotas → Running On-Demand P instances ≥ 192
eksctl	>= 0.200.0	Version supporting EKS Auto Mode
kubectl	>= 1.33	Compatible with EKS 1.33/1.34
Helm	>= 3.0	For Helm chart deployment
helmfile	Latest version	llm-d unified deployment tool
yq	>= 4.0	YAML processing tool
HuggingFace Token	Access to Qwen3-32B	https://huggingface.co/settings/tokens
AWS CLI	v2 latest	Credentials configured

클라이언트 도구 설치

# eksctl 설치 (macOS)
brew install eksctl

# helmfile 설치
brew install helmfile

# yq 설치
brew install yq

# 버전 확인
eksctl version
kubectl version --client
helm version
helmfile --version
yq --version

p5.48xlarge 쿼터 확인

p5.48xlarge는 192 vCPU를 사용합니다. AWS Service Quotas에서 Running On-Demand P instances 한도가 최소 192 이상인지 확인하세요. 쿼터 증가 요청은 승인까지 1-3 영업일 소요될 수 있습니다.

# 현재 P 인스턴스 쿼터 확인
aws service-quotas get-service-quota \
  --service-code ec2 \
  --quota-code L-417A185B \
  --region us-west-2 \
  --query 'Quota.Value'

배포 전략 선택: Auto Mode vs Karpenter

llm-d 자체는 Kubernetes 표준 리소스(Deployment, Service, CRD)를 사용하므로 노드 관리 방식에 독립적입니다. 그러나 GPU 리소스 활용 효율은 배포 환경에 따라 크게 달라집니다.

Auto Mode가 적합한 경우

70B+ 대형 모델: Qwen3-32B(TP=2), Llama-3-70B(TP=4), DeepSeek-V3(TP=8) 등 GPU를 충분히 활용하는 모델
빠른 프로토타이핑: GPU 드라이버·AMI 관리 없이 바로 배포하고 싶은 경우
운영 단순화 우선: GPU Operator 설치·업데이트 부담을 줄이고 싶은 경우

Karpenter + GPU Operator가 적합한 경우

7B~13B 소형 모델: MIG로 H100을 7개 인스턴스로 분할하여 비용 75% 절감
멀티테넌시: 팀별로 GPU 슬라이스를 격리 할당해야 하는 경우
DCGM 모니터링: GPU 레벨 세밀한 메트릭 수집이 필요한 경우
커스텀 AMI/드라이버: 특정 CUDA 버전이나 드라이버 핀이 필요한 경우

Karpenter 배포 예시

Karpenter + GPU Operator 환경에서의 llm-d 배포는 본 문서의 Auto Mode 예시에서 다음 부분만 변경하면 됩니다:

클러스터 생성: autoModeConfig 대신 Karpenter를 직접 설치
NodePool: nodeClassRef를 EC2NodeClass로 변경 (커스텀 AMI, GPU Operator userData 포함)
GPU Operator 설치: helm install gpu-operator nvidia/gpu-operator

상세 구성은 EKS GPU 노드 전략 — Karpenter + GPU Operator를 참조하세요.

EKS Auto Mode 클러스터 생성

클러스터 구성 파일

# cluster-config.yaml
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: llm-d-cluster
  region: us-west-2
  version: "1.33"
autoModeConfig:
  enabled: true

# 클러스터 생성 (약 15-20분 소요)
eksctl create cluster -f cluster-config.yaml

# 클러스터 상태 확인
kubectl get nodes
kubectl cluster-info

GPU NodePool 생성

EKS Auto Mode에서 p5.48xlarge 인스턴스를 자동 프로비저닝하기 위한 Karpenter NodePool을 생성합니다.

# gpu-nodepool.yaml
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu-p5
spec:
  template:
    spec:
      requirements:
        - key: eks.amazonaws.com/instance-family
          operator: In
          values: ["p5"]
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["on-demand"]
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default
      taints:
        - key: nvidia.com/gpu
          effect: NoSchedule
  limits:
    cpu: "384"
    memory: 4096Gi
    nvidia.com/gpu: "16"
  disruption:
    consolidationPolicy: WhenEmpty
    consolidateAfter: 30s

kubectl apply -f gpu-nodepool.yaml

# NodePool 상태 확인
kubectl get nodepool gpu-p5

EKS Auto Mode의 GPU 지원

EKS Auto Mode는 NVIDIA GPU 드라이버를 자동으로 설치하고 관리합니다. 별도의 GPU Operator나 NVIDIA Device Plugin 설치가 필요 없습니다. NodeClass default를 사용하면 Auto Mode가 최적의 AMI와 드라이버 버전을 자동 선택합니다.

제약사항: Auto Mode의 NodeClass는 AWS 관리형(read-only)이므로 MIG, Time-Slicing 등 GPU 분할 설정이 불가능합니다. 소형 모델(7B~13B)에서 GPU 효율이 낮아질 수 있습니다. GPU 분할이 필요하면 Karpenter + GPU Operator 전략을 참조하세요.

p5.48xlarge 인스턴스 사양

p5.48xlarge Instance Specifications

GPU

8× NVIDIA H100 80GB HBM3

GPU Memory

640GB total

vCPU

192

System Memory

2,048 GiB

GPU Interconnect

NVSwitch (900 GB/s)

Network

EFA 3,200 Gbps

Storage

8× 3.84TB NVMe SSD

p5e.48xlarge 인스턴스 사양 (H200)

p5e.48xlarge Instance Specifications (H200)

GPU

8× NVIDIA H200 141GB HBM3

GPU Memory

1,128GB total

vCPU

192

System Memory

2,048 GiB

GPU Interconnect

NVSwitch (900 GB/s)

Network

EFA 3,200 Gbps

Storage

8× 3.84TB NVMe SSD

인스턴스 선택 가이드

p5e.48xlarge (H200): 100B+ 파라미터 모델, 최대 메모리 활용
p5.48xlarge (H100): 70B+ 파라미터 모델, 최고 성능
g6e family (L40S): 13B-70B 모델, 비용 효율적 추론

llm-d 배포

5.1 네임스페이스 및 시크릿 생성

export NAMESPACE=llm-d
kubectl create namespace ${NAMESPACE}

# HuggingFace 토큰 시크릿 생성
kubectl create secret generic llm-d-hf-token \
  --from-literal=HF_TOKEN=<your-huggingface-token> \
  -n ${NAMESPACE}

# 시크릿 생성 확인
kubectl get secret llm-d-hf-token -n ${NAMESPACE}

5.2 llm-d 저장소 클론

git clone https://github.com/llm-d/llm-d.git
cd llm-d/guides/inference-scheduling

디렉토리 구조:

guides/inference-scheduling/
├── helmfile.yaml          # 통합 배포 정의
├── values/
│   ├── vllm-values.yaml   # vLLM 서버 설정
│   ├── gateway-values.yaml # Gateway 설정
│   └── ...
└── README.md

5.3 Gateway API CRD 설치

llm-d는 Kubernetes Gateway API와 Inference Extension CRD를 사용합니다.

# Gateway API 표준 CRD 설치 (v1.2.0+)
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.0/standard-install.yaml

# Inference Extension CRD 설치 (InferencePool, InferenceModel)
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/releases/download/v0.3.0/manifests.yaml

Gateway API v1.2.0+ 기능

Gateway API v1.2.0은 다음과 같은 향상된 기능을 제공합니다:

HTTPRoute 개선: 더 유연한 라우팅 규칙
GRPCRoute 안정화: gRPC 서비스 라우팅 지원
BackendTLSPolicy: 백엔드 TLS 설정 표준화
Kubernetes 1.33+ 통합: Topology-aware routing 지원

설치되는 CRD:

Installed CRDs

Gateway

Defines Envoy-based proxy instances

HTTPRoute

Defines routing rules

InferencePool

Defines vLLM Pod groups (serving endpoint pools)

InferenceModel

Maps model names to InferencePools

# CRD 설치 확인
kubectl get crd | grep -E "gateway|inference"

5.4 Gateway 컨트롤 플레인 설치

# Istio 기반 Gateway 컨트롤 플레인 설치
helmfile apply -n ${NAMESPACE} -l component=gateway-control-plane

5.5 llm-d 전체 배포

# 전체 컴포넌트 배포 (vLLM + Gateway + InferencePool + InferenceModel)
helmfile apply -n ${NAMESPACE}

기본 배포 구성:

Default Deployment Configuration

Setting	Default Value	Description
Model	Qwen/Qwen3-32B	Apache 2.0, BF16 ~65GB VRAM
vLLM Version	v0.6+	CUDA 12.x support, H100/H200 optimized
Tensor Parallelism	TP=2	2 GPUs per replica
Replicas	8	16 GPUs total (2× p5.48xlarge)
Max Model Length	32,768	Maximum context length
GPU Memory Utilization	0.90	KV Cache allocation ratio

리소스 조정

기본 설정은 8 replicas × 2 GPU = 16 GPU를 사용합니다. 테스트 목적이라면 helmfile.yaml에서 replicaCount를 줄여 비용을 절감할 수 있습니다. 예를 들어 4 replicas로 설정하면 단일 p5.48xlarge (8 GPU)로 운영 가능합니다.

5.6 배포 확인

# Helm 릴리즈 확인
helm list -n ${NAMESPACE}

# 전체 리소스 확인
kubectl get all -n ${NAMESPACE}

# InferencePool 상태 확인
kubectl get inferencepool -n ${NAMESPACE}

# InferenceModel 상태 확인
kubectl get inferencemodel -n ${NAMESPACE}

# vLLM Pod 상태 확인 (GPU 할당 포함)
kubectl get pods -n ${NAMESPACE} -o wide

# Pod가 Ready 상태가 될 때까지 대기 (모델 로딩에 5-10분 소요)
kubectl wait --for=condition=Ready pods -l app=vllm \
  -n ${NAMESPACE} --timeout=600s

모델 로딩 시간

Qwen3-32B (BF16, ~65GB)는 HuggingFace Hub에서 최초 다운로드 시 네트워크 속도에 따라 10-20분이 소요될 수 있습니다. 이후 배포에서는 노드의 로컬 캐시를 활용하여 로딩 시간이 크게 단축됩니다.

추론 요청 테스트

6.1 포트 포워딩

# Inference Gateway 포트 포워딩
kubectl port-forward svc/inference-gateway -n ${NAMESPACE} 8080:8080

6.2 curl 기본 테스트

curl -s http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Qwen/Qwen3-32B",
    "messages": [
      {
        "role": "user",
        "content": "Kubernetes란 무엇인가요? 간단히 설명해주세요."
      }
    ],
    "max_tokens": 256,
    "temperature": 0.7
  }' | jq .

예상 응답 구조:

{
  "id": "chatcmpl-...",
  "object": "chat.completion",
  "model": "Qwen/Qwen3-32B",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "Kubernetes는 컨테이너화된 애플리케이션의 배포, 스케일링..."
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 15,
    "completion_tokens": 128,
    "total_tokens": 143
  }
}

6.3 Python 클라이언트

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8080/v1",
    api_key="not-needed"  # llm-d는 별도 인증 불필요
)

response = client.chat.completions.create(
    model="Qwen/Qwen3-32B",
    messages=[
        {"role": "system", "content": "당신은 클라우드 네이티브 전문가입니다."},
        {"role": "user", "content": "EKS Auto Mode의 장점을 3가지 설명해주세요."}
    ],
    max_tokens=512,
    temperature=0.7
)
print(response.choices[0].message.content)

6.4 스트리밍 응답 테스트

stream = client.chat.completions.create(
    model="Qwen/Qwen3-32B",
    messages=[
        {"role": "user", "content": "llm-d의 KV Cache-aware 라우팅이 어떻게 동작하나요?"}
    ],
    max_tokens=512,
    stream=True
)

for chunk in stream:
    if chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="", flush=True)
print()

6.5 모델 목록 확인

curl -s http://localhost:8080/v1/models | jq .

OpenAI 호환 API

llm-d는 OpenAI 호환 API를 제공합니다. 기존 OpenAI SDK를 사용하는 애플리케이션에서 base_url만 변경하면 바로 사용할 수 있습니다. /v1/chat/completions, /v1/completions, /v1/models 엔드포인트를 지원합니다.

KV Cache-aware 라우팅 이해

llm-d의 핵심 차별점은 KV Cache 상태를 인식하는 지능적 라우팅입니다.

라우팅 동작 원리

요청 수신: 클라이언트가 Inference Gateway로 추론 요청 전송
Prefix 분석: Gateway가 요청의 prompt prefix를 해시하여 식별
Cache 조회: 각 vLLM Pod의 KV Cache 상태를 확인하여 해당 prefix를 보유한 Pod 탐색
지능적 라우팅: Cache hit 시 해당 Pod로 라우팅, miss 시 부하 기반 로드 밸런싱
응답 반환: vLLM이 추론 결과를 Gateway를 통해 클라이언트에 반환

KV Cache-aware 라우팅의 효과

Effects of KV Cache-aware Routing

Metric	Cache Miss (Traditional)	Cache Hit (llm-d)	Improvement
TTFT (Time To First Token)	High (full prefill required)	Low (prefill skipped)	50-80% reduction
GPU Computation	Full prompt processing	Only new tokens processed	Computation savings
Throughput	Baseline	Improved	1.5-3x improvement

Cache Hit Rate 극대화

동일한 시스템 프롬프트를 사용하는 애플리케이션에서 KV Cache-aware 라우팅의 효과가 극대화됩니다. 예를 들어 RAG 파이프라인에서 동일한 컨텍스트 문서를 반복 참조하는 경우, 해당 prefix의 KV Cache를 재사용하여 TTFT를 크게 단축할 수 있습니다.

모니터링 및 검증

8.1 vLLM 메트릭 확인

# vLLM Pod의 메트릭 엔드포인트 접근
VLLM_POD=$(kubectl get pods -n ${NAMESPACE} -l app=vllm -o jsonpath='{.items[0].metadata.name}')
kubectl port-forward ${VLLM_POD} -n ${NAMESPACE} 9090:9090

# 메트릭 조회
curl -s http://localhost:9090/metrics | grep -E "vllm_"

주요 모니터링 메트릭

Key Monitoring Metrics

Metric	Description	Normal Range
vllm_num_requests_running	Number of currently processing requests	Varies by workload
vllm_num_requests_waiting	Number of waiting requests	< 50
vllm_gpu_cache_usage_perc	GPU KV Cache utilization	60-90%
vllm_avg_generation_throughput_toks_per_s	Tokens generated per second	Varies by model/GPU
vllm_avg_prompt_throughput_toks_per_s	Prompt tokens processed per second	Varies by model/GPU
vllm_e2e_request_latency_seconds	End-to-end request latency	P95 < 30s

8.2 GPU 활용률 확인

# 특정 vLLM Pod에서 nvidia-smi 실행
kubectl exec -it ${VLLM_POD} -n ${NAMESPACE} -- nvidia-smi

# 실시간 GPU 모니터링 (1초 간격)
kubectl exec -it ${VLLM_POD} -n ${NAMESPACE} -- nvidia-smi dmon -s u -d 1

8.3 Gateway 로그 확인

# Inference Gateway 로그 확인
kubectl logs -f deployment/inference-gateway -n ${NAMESPACE}

# InferencePool 상태 상세 확인
kubectl describe inferencepool -n ${NAMESPACE}

8.4 Prometheus ServiceMonitor 구성

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: llm-d-vllm-monitor
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: vllm
  endpoints:
    - port: metrics
      path: /metrics
      interval: 15s
  namespaceSelector:
    matchNames:
      - llm-d

운영 고려사항

9.1 S3 모델 캐싱

HuggingFace Hub에서 매번 모델을 다운로드하면 Cold Start 시간이 길어집니다. S3에 모델 가중치를 캐싱하여 로딩 시간을 단축할 수 있습니다.

# vLLM 환경 변수에 S3 캐시 경로 추가
env:
  - name: VLLM_S3_MODEL_CACHE
    value: "s3://your-bucket/model-cache/qwen3-32b/"

Expected Time by Model Loading Method

Loading Method	Expected Time	Notes
HuggingFace Hub (initial)	10-20 min	Varies by network speed
S3 Cache	3-5 min	Loading from same-region S3
Node Local Cache	1-2 min	When redeploying on the same node

9.2 HPA (Horizontal Pod Autoscaler) 구성

vLLM 대기 요청 수 기반으로 자동 스케일링을 구성할 수 있습니다.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: vllm-hpa
  namespace: llm-d
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: vllm-deployment
  minReplicas: 2
  maxReplicas: 8
  metrics:
    - type: Pods
      pods:
        metric:
          name: vllm_num_requests_waiting
        target:
          type: AverageValue
          averageValue: "5"
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 60
      policies:
        - type: Pods
          value: 2
          periodSeconds: 120
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Pods
          value: 1
          periodSeconds: 180

HPA와 Karpenter 연동

HPA가 vLLM replica를 증가시키면, 추가 GPU가 필요한 경우 Karpenter가 자동으로 새로운 p5.48xlarge 노드를 프로비저닝합니다. EKS Auto Mode에서는 이 과정이 완전히 자동화됩니다.

9.3 비용 최적화

Cost Optimization Strategies

Strategy	Description	Estimated Savings
Savings Plans	1-year/3-year Compute Savings Plans commitment	30-60%
Off-Peak Scale Down	Reduce replicas during nights/weekends (using CronJob)	40-60%
Model Quantization	Reduce GPU count with INT8/INT4	50% GPU cost
Spot Instances	Apply to fault-tolerant workloads (risk of interruption)	60-90%
TP Optimization	Use minimum TP value appropriate for model size	Avoid unnecessary GPUs

비용 주의

p5.48xlarge는 시간당 약 $98.32 (us-west-2 On-Demand 기준)입니다. 2대 운영 시 월 약 $141,580입니다. 테스트 완료 후 반드시 리소스를 정리하세요.

# 리소스 정리
helmfile destroy -n ${NAMESPACE}
kubectl delete namespace ${NAMESPACE}
kubectl delete nodepool gpu-p5

# 클러스터 삭제 (필요 시)
eksctl delete cluster --name llm-d-cluster --region us-west-2

트러블슈팅

일반적인 문제와 해결 방법

Common Issues and Solutions

Symptom	Cause	Solution
GPU node not provisioning	Insufficient Service Quotas	Check and request increase for P instance quota in AWS Console
Pod stuck in Pending state	NodePool configuration error or insufficient GPUs	Check events with `kubectl describe pod`, verify instance-family in NodePool
CUDA OOM (Out of Memory)	Insufficient GPU memory	Increase TP value or lower `gpu-memory-utilization` (0.85)
Model loading timeout	Slow HuggingFace download	Enable S3 model caching, increase `initialDelaySeconds`
Gateway routing failure	CRDs not installed	Verify Gateway API CRD and Inference Extension CRD installation
HuggingFace token error	Secret not created or insufficient permissions	Check `kubectl get secret -n llm-d`, verify HF token permissions
NCCL communication error	Inter-GPU communication issue	Add `NCCL_DEBUG=INFO` environment variable, verify EFA support
InferencePool not Ready	vLLM Pods not ready	Check Pod status, wait for model loading to complete

디버깅 명령어 모음

# Pod 상태 및 이벤트 확인
kubectl describe pod <pod-name> -n llm-d

# vLLM 로그 확인 (최근 100줄)
kubectl logs <vllm-pod> -n llm-d --tail=100

# GPU 상태 확인
kubectl exec -it <vllm-pod> -n llm-d -- nvidia-smi

# InferencePool 상태 상세 확인
kubectl describe inferencepool -n llm-d

# InferenceModel 상태 확인
kubectl describe inferencemodel -n llm-d

# Gateway 로그 확인
kubectl logs -f deployment/inference-gateway -n llm-d

# 노드 GPU 리소스 확인
kubectl get nodes -o custom-columns=\
  NAME:.metadata.name,\
  GPU:.status.allocatable.nvidia\\.com/gpu,\
  STATUS:.status.conditions[-1].type

# Karpenter 로그 확인 (노드 프로비저닝 문제)
kubectl logs -f deployment/karpenter -n kube-system

NCCL 디버깅

멀티 GPU 통신 문제가 발생하면 다음 환경 변수를 추가하여 상세 로그를 확인하세요:

env:
  - name: NCCL_DEBUG
    value: "INFO"
  - name: NCCL_DEBUG_SUBSYS
    value: "ALL"

다음 단계

본 가이드에서는 llm-d의 Intelligent Inference Scheduling path를 다루었습니다. 다음 단계로 고급 기능을 탐색할 수 있습니다.

Prefill/Decode Disaggregation: Prefill과 Decode 단계를 별도 Pod 그룹으로 분리하여 대규모 배치 처리와 긴 컨텍스트 워크로드의 처리량을 극대화
Expert Parallelism: MoE 모델(Mixtral, DeepSeek 등)의 Expert를 여러 노드에 분산하여 초대규모 모델 서빙
LoRA 어댑터 핫스왑: 단일 기본 모델에 여러 LoRA 어댑터를 동적으로 로드/언로드하여 다중 태스크 서빙
Prometheus + Grafana 대시보드: vLLM 메트릭 기반 실시간 모니터링 대시보드 구성
멀티 모델 서빙: 하나의 llm-d 클러스터에서 여러 모델을 InferenceModel CRD로 동시 서빙

개요​

주요 목표​

llm-d의 3가지 Well-Lit Path​

아키텍처​

llm-d vs 기존 vLLM 배포 비교​

Qwen3-32B 모델 선정 이유​

사전 요구사항​

클라이언트 도구 설치​

배포 전략 선택: Auto Mode vs Karpenter​

Auto Mode가 적합한 경우​

Karpenter + GPU Operator가 적합한 경우​

EKS Auto Mode 클러스터 생성​

클러스터 구성 파일​

GPU NodePool 생성​

p5.48xlarge 인스턴스 사양​

p5e.48xlarge 인스턴스 사양 (H200)​

llm-d 배포​

5.1 네임스페이스 및 시크릿 생성​

5.2 llm-d 저장소 클론​

5.3 Gateway API CRD 설치​

5.4 Gateway 컨트롤 플레인 설치​

5.5 llm-d 전체 배포​

5.6 배포 확인​

추론 요청 테스트​

6.1 포트 포워딩​

6.2 curl 기본 테스트​

6.3 Python 클라이언트​

6.4 스트리밍 응답 테스트​

6.5 모델 목록 확인​

KV Cache-aware 라우팅 이해​

라우팅 동작 원리​

KV Cache-aware 라우팅의 효과​

모니터링 및 검증​

8.1 vLLM 메트릭 확인​

주요 모니터링 메트릭​

8.2 GPU 활용률 확인​

8.3 Gateway 로그 확인​

8.4 Prometheus ServiceMonitor 구성​

운영 고려사항​

9.1 S3 모델 캐싱​

9.2 HPA (Horizontal Pod Autoscaler) 구성​

9.3 비용 최적화​

트러블슈팅​

일반적인 문제와 해결 방법​

디버깅 명령어 모음​

다음 단계​

관련 문서​

참고 자료​

개요

주요 목표

llm-d의 3가지 Well-Lit Path

아키텍처

llm-d vs 기존 vLLM 배포 비교

Qwen3-32B 모델 선정 이유

사전 요구사항

클라이언트 도구 설치

배포 전략 선택: Auto Mode vs Karpenter

Auto Mode가 적합한 경우

Karpenter + GPU Operator가 적합한 경우

EKS Auto Mode 클러스터 생성

클러스터 구성 파일

GPU NodePool 생성

p5.48xlarge 인스턴스 사양

p5e.48xlarge 인스턴스 사양 (H200)

llm-d 배포

5.1 네임스페이스 및 시크릿 생성

5.2 llm-d 저장소 클론

5.3 Gateway API CRD 설치

5.4 Gateway 컨트롤 플레인 설치

5.5 llm-d 전체 배포

5.6 배포 확인

추론 요청 테스트

6.1 포트 포워딩

6.2 curl 기본 테스트

6.3 Python 클라이언트

6.4 스트리밍 응답 테스트

6.5 모델 목록 확인

KV Cache-aware 라우팅 이해

라우팅 동작 원리

KV Cache-aware 라우팅의 효과

모니터링 및 검증

8.1 vLLM 메트릭 확인

주요 모니터링 메트릭

8.2 GPU 활용률 확인

8.3 Gateway 로그 확인

8.4 Prometheus ServiceMonitor 구성

운영 고려사항

9.1 S3 모델 캐싱

9.2 HPA (Horizontal Pod Autoscaler) 구성

9.3 비용 최적화

트러블슈팅

일반적인 문제와 해결 방법

디버깅 명령어 모음

다음 단계

관련 문서

참고 자료