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

📅2026-02-10 작성·🔄2026-07-17 수정·⏱17분 읽기

현재 버전: llm-d v0.8+ (CNCF Sandbox, 2026.03)

개요

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 배포 YAML, helmfile 명령어, 클러스터 생성 등 실전 배포는 커스텀 모델 배포 가이드를 참조하세요.

llm-d Inference Gateway =/= 범용 Gateway API 구현체

llm-d의 Envoy 기반 Inference Gateway는 LLM 추론 요청 전용으로 설계된 특수 목적 게이트웨이입니다.

• llm-d Gateway: InferencePool/InferenceObjective CRD 기반 (Gateway API Inference Extension v1.0+), KV Cache-aware 라우팅, 추론 트래픽 전용
• 범용 Gateway API: HTTPRoute/GRPCRoute 기반, TLS/인증/Rate Limiting, 클러스터 전체 트래픽 관리

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

llm-d의 3가지 Well-Lit Path

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

llm-d의 3가지 Well-Lit Path

Intelligent Inference Scheduling권장

KV Cache-aware 라우팅으로 지능적 요청 분배

📌 범용 LLM 서빙 (본 가이드)

Prefill/Decode Disaggregation

Prefill과 Decode 단계를 분리하여 처리

📌 대규모 배치, 긴 컨텍스트 처리

Wide Expert-Parallelism

MoE 모델의 Expert를 여러 노드에 분산

📌 MoE 모델 (Mixtral, DeepSeek 등)

---

아키텍처

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

llm-d vs 기존 vLLM 배포 비교

llm-d vs 기존 vLLM 배포 비교

특성	기존 vLLM 배포	llm-d 배포 ✨
라우팅 방식	Round-Robin / Random	KV Cache-aware Intelligent Routing
Gateway 통합	별도 Ingress/Service 구성	Gateway API 네이티브 통합
스케일링 관리	수동 HPA 구성	InferencePool 기반 자동 관리
KV Cache 활용	Pod별 독립적 관리	Cross-pod prefix 재사용으로 TTFT 단축
설치 방식	개별 Helm chart 조합	helmfile 통합 배포 (원커맨드)
모델 정의	Deployment YAML 직접 작성	InferenceModel CRD 선언적 관리

Gateway API CRD

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

설치되는 CRD

Gateway

Envoy 기반 프록시 인스턴스 정의

HTTPRoute

라우팅 규칙 정의

InferencePool

vLLM Pod 그룹 (서빙 엔드포인트 풀) 정의

InferenceModel

모델 이름과 InferencePool 매핑

기본 배포 구성

기본 배포 구성

설정	기본값	설명
모델	Qwen/Qwen3-32B	Apache 2.0, BF16 ~65GB VRAM
vLLM 버전	v0.6+	CUDA 12.x 지원, H100/H200 최적화
Tensor Parallelism	TP=2	replica당 2 GPU 사용
Replicas	8	총 16 GPU (2× p5.48xlarge)
Max Model Length	32,768	최대 컨텍스트 길이
GPU Memory Utilization	0.90	KV Cache 할당 비율

Qwen3-32B 모델 선정 이유

Qwen3-32B 모델 선정 이유

모델명

Qwen/Qwen3-32B

파라미터

32B (Dense)

라이선스

Apache 2.0

정밀도

BF16 (~65GB VRAM)

컨텍스트

최대 32,768 토큰

특징

llm-d 공식 기본 모델, 다국어 지원 우수, 오픈소스 LLM 중 최고 인기

Qwen3-32B 선정 배경

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

---

KV Cache-aware 라우팅

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

라우팅 동작 원리

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

KV Cache-aware 라우팅의 효과

KV Cache-aware 라우팅의 효과

지표	Cache Miss (기존 방식)	Cache Hit (llm-d)	개선 효과
TTFT (Time To First Token)	높음 (전체 prefill 필요)	낮음 (prefill 스킵)	50-80% 단축
GPU 연산량	전체 prompt 처리	새로운 토큰만 처리	연산 절약
처리량 (Throughput)	기본	향상	1.5-3x 향상

Cache Hit Rate 극대화

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

---

EKS Auto Mode 통합

Auto Mode의 장점과 제한사항

장점:

• GPU 드라이버 자동 관리: NVIDIA GPU 드라이버를 AWS가 자동으로 설치하고 업데이트
• NodeClass 자동 선택: default NodeClass를 사용하면 Auto Mode가 최적의 AMI와 드라이버 버전을 자동 선택
• 운영 단순화: 드라이버 설치, CUDA 버전 관리, 드라이버 호환성 검증 등의 운영 부담 제거
• GPU Operator 설치 가능: Device Plugin만 레이블로 비활성화, DCGM/NFD/GFD 정상 동작

제한사항:

• MIG/Time-Slicing 불가: Auto Mode의 NodeClass는 AWS 관리형(read-only)이므로 GPU 분할 설정 불가
• 커스텀 AMI 불가: 특정 CUDA 버전이나 드라이버 핀 필요 시 대응 불가

Auto Mode vs Karpenter + GPU Operator 비교

Auto Mode는 GPU 드라이버 관리 부담 없이 대형 모델 서빙에 적합하며, Karpenter는 MIG/Time-Slicing 등 고급 GPU 기능이 필요한 워크로드에 유리합니다.

상세 비교표 및 비용 분석: EKS GPU 노드 전략 — 노드 타입별 특성 비교 참조

GPU 인스턴스 사양

p5.48xlarge 인스턴스 사양

GPU

8× NVIDIA H100 80GB HBM3

GPU 메모리

총 640GB

vCPU

192

시스템 메모리

2,048 GiB

GPU 인터커넥트

NVSwitch (900 GB/s)

네트워크

EFA 3,200 Gbps

스토리지

8× 3.84TB NVMe SSD

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

GPU

8× NVIDIA H200 141GB HBM3

GPU 메모리

총 1,128GB

vCPU

192

시스템 메모리

2,048 GiB

GPU 인터커넥트

NVSwitch (900 GB/s)

네트워크

EFA 3,200 Gbps

스토리지

8× 3.84TB NVMe SSD

인스턴스 선택 가이드

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

llm-d + DRA 사용 시 Karpenter 버전 제약

llm-d ModelService가 DRA (ResourceClaim) 방식으로 GPU를 요청하는 경우, Karpenter 버전과 배포 방식에 따라 지원 여부가 갈립니다.

• Self-managed Karpenter v1.14.0+: DRA를 지원합니다 (AWS Provider v1.14.0이 코어 v1.14.0의 DRA allocator 포함, consumable capacity·partitionable devices 지원). v1.13 이하는 spec.resourceClaims Pod를 skip합니다.
• EKS Auto Mode: 현재 DRA 미지원 — AWS 관리형 내부 Karpenter라 사용자가 v1.14+로 올릴 수 없습니다. Auto Mode 사용 시 Managed Node Group + Cluster Autoscaler가 권장 방식입니다.

상세: EKS GPU 노드 전략 — DRA 워크로드를 위한 MNG 하이브리드

---

llm-d v0.5+ 주요 기능

기능	설명	상태
Prefill/Decode Disaggregation	Prefill과 Decode를 별도 Pod 그룹으로 분리, 대규모 배치와 긴 컨텍스트 처리량 극대화	Well-lit path
Expert Parallelism (Wide EP)	MoE 모델(Mixtral, DeepSeek)의 Expert를 여러 노드에 분산 서빙	Well-lit path
LoRA 어댑터 지원	단일 기본 모델에 여러 LoRA 어댑터를 동적 로드, LoRA-aware 스케줄링 지원	Experimental
멀티 모델 서빙	하나의 클러스터에서 여러 모델을 InferenceModel CRD로 동시 서빙	Stable
Gateway API Inference Extension	InferencePool (v1 GA), InferenceModel (deprecated → InferenceObjective v1alpha2)	v1/v1alpha2

Disaggregated Serving 개념

Disaggregated Serving은 LLM 추론의 두 단계를 분리하여 각각 독립적으로 최적화합니다:

단계	특성	최적화 방향
Prefill	프롬프트 전체를 한 번에 처리 (compute-bound)	GPU 컴퓨팅 집중, 높은 TP
Decode	토큰을 하나씩 자동회귀 생성 (memory-bound)	GPU 메모리 집중, 낮은 TP

NIXL (NVIDIA Inference Xfer Library): Dynamo, llm-d, production-stack, aibrix 등 대부분의 프로젝트가 사용하는 공통 KV 전송 엔진. GPU 간 직접 통신(NVLink/RDMA)으로 KV Cache를 초고속 전송합니다.

EKS Auto Mode에서의 Disaggregated Serving

Auto Mode에서는 MIG 파티셔닝이 불가능하므로, 인스턴스(노드) 단위로 Prefill/Decode 역할을 분리합니다.

Prefill NodePool (compute-heavy):
  p5.48xlarge x N대 -> Prefill Pod (각 TP=4, GPU 4개)

Decode NodePool (memory-heavy):
  p5.48xlarge x N대 -> Decode Pod (각 TP=2, GPU 2개 x 4 Pod/노드)

항목	Auto Mode (노드 분리)	Karpenter + GPU Operator (MIG 분리)
분리 단위	인스턴스(노드)	GPU 단위 (MIG 파티션)
GPU 활용률	Decode Pod TP=2 x 4개/노드로 최적화 가능	MIG로 한 GPU 내 분할, 높은 활용률
운영 복잡도	낮음	중간 (GPU Operator + MIG 설정)
스케일링	Prefill/Decode 독립 스케일링 용이	노드 내 MIG 재설정 시 중단 발생

GPU 유휴 최소화

권장 전략: Auto Mode로 먼저 검증한 후, 비용 최적화가 필요하면 Karpenter + GPU Operator + MIG로 전환하세요.

---

llm-d vs NVIDIA Dynamo

llm-d와 NVIDIA Dynamo는 모두 LLM 추론 라우팅/스케줄링을 제공하지만 접근 방식이 다릅니다. 상세 비교는 NVIDIA GPU 스택 — llm-d vs Dynamo를 참조하세요.

항목	llm-d	NVIDIA Dynamo
주도	Red Hat (Apache 2.0)	NVIDIA (Apache 2.0)
아키텍처	Aggregated + Disaggregated	Aggregated + Disaggregated (동등 지원)
KV Cache 전송	NIXL (네트워크도 지원)	NIXL (NVLink/RDMA 초고속)
KV Cache 인덱싱	Prefix-aware 라우팅	Flash Indexer (radix tree 기반)
라우팅	Gateway API + Envoy EPP	Dynamo Router + 자체 EPP (Gateway API 통합)
Pod 스케줄링	K8s 기본 스케줄러	KAI Scheduler (GPU-aware Pod 배치)
오토스케일링	HPA/KEDA 연동	Planner (SLO 기반: profiling -> autoscale) + KEDA/HPA
GPU Operator 필요	선택사항 (Auto Mode 호환)	필요 (Dynamo Platform 설치 전제조건; KAI Scheduler는 멀티노드용 선택 컴포넌트)
복잡도	낮음	높음
강점	K8s 네이티브, 경량, 빠른 도입	Flash Indexer, KAI Scheduler, Planner SLO 오토스케일링

선택 가이드

• EKS Auto Mode + 빠른 시작: llm-d (GPU Operator 선택사항)
• 소규모~중규모 (GPU 16개 이하): llm-d
• 대규모 (GPU 16개+), 최대 처리량: Dynamo (Flash Indexer + Planner)
• 긴 컨텍스트 (128K+): Dynamo (3-tier KV Cache: GPU->CPU->SSD)
• K8s Gateway API 표준 준수: llm-d

llm-d와 Dynamo는 상호보완적 관계입니다. 두 프로젝트는 NIXL(KV 전송 라이브러리)과 Gateway API를 공유하는 독립 병렬 스택이며, llm-d는 NIXL을 KV Cache 전송에 활용합니다. llm-d로 시작하여 규모가 커지면 Dynamo로 전환하는 것이 현실적입니다.

마이그레이션 경로

단계별 전환 경로:

Phase	구성	적합 대상
Phase 1	Auto Mode + llm-d	PoC, 개발 환경, GPU 16개 이하
Phase 1.5	Auto Mode + GPU Operator + llm-d	모니터링/스케줄링 강화
Phase 2a	Karpenter + llm-d Disaggregated	중규모 프로덕션, MIG 활용
Phase 2b	MNG + DRA + llm-d	P6e-GB200, DRA 필수 환경
Phase 3	Karpenter + Dynamo	대규모 (GPU 16개+), 최대 성능

전환 시 주의사항

Auto Mode와 Karpenter 자체 관리는 동일 클러스터에서 혼용이 가능합니다. Phase 1.5에서 GPU Operator Device Plugin 충돌을 방지하려면 Helm 설치 시 devicePlugin.enabled=false로 설정하거나, ClusterPolicy에서 daemonsets.nodeSelector/affinity로 Auto Mode 노드(eks.amazonaws.com/compute-type: auto)를 제외합니다. NodePool 레이블 방식(nvidia.com/gpu.deploy.device-plugin: "false")은 GPU Operator가 레이블을 true로 덮어쓰므로 동작하지 않습니다.

---

모니터링

주요 모니터링 메트릭

주요 모니터링 메트릭

메트릭	설명	정상 범위
vllm_num_requests_running	현재 처리 중인 요청 수	워크로드에 따라 다름
vllm_num_requests_waiting	대기 중인 요청 수	< 50
vllm_gpu_cache_usage_perc	GPU KV Cache 사용률	60-90%
vllm_avg_generation_throughput_toks_per_s	초당 생성 토큰 수	모델/GPU에 따라 다름
vllm_avg_prompt_throughput_toks_per_s	초당 프롬프트 처리 토큰 수	모델/GPU에 따라 다름
vllm_e2e_request_latency_seconds	요청 전체 지연시간	P95 < 30s

모델 로딩 시간

모델 로딩 방식별 예상 시간

로딩 방식	예상 시간	비고
HuggingFace Hub (최초)	10-20분	네트워크 속도에 따라 다름
S3 캐시	3-5분	같은 리전 S3에서 로딩
노드 로컬 캐시	1-2분	동일 노드 재배포 시

비용 최적화

비용 최적화 전략

전략	설명	예상 절감
Savings Plans	1년/3년 Compute Savings Plans 약정	30-60%
비피크 시간 스케일 다운	야간/주말 replicas 축소 (CronJob 활용)	40-60%
모델 양자화	INT8/INT4로 GPU 수 절감	GPU 비용 50%
Spot Instances	내결함성 워크로드에 적용 (중단 위험 있음)	60-90%
TP 최적화	모델 크기에 맞는 최소 TP 값 사용	불필요한 GPU 절약

비용 주의

p5.48xlarge는 시간당 $55.04 (us-west-2 On-Demand 기준, 2025-06 AWS 가격 인하 반영)입니다. 2대 운영 시 월 약 $79,258 (720h 기준) ~ $80,360 (730h 기준)입니다. 테스트 완료 후 반드시 리소스를 정리하세요.

---

EKS Auto Mode GPU 인스턴스 지원 현황 (2026.04 검증)

인스턴스 지원 매트릭스

인스턴스 타입	GPU	VRAM (총합)	Auto Mode 지원	검증 상태
g5.xlarge~48xlarge	A10G	24~192GB	정상	프로비저닝 확인
g6.xlarge~48xlarge	L4	24~192GB	정상	프로비저닝 확인
g6e.xlarge~48xlarge	L40S	48~384GB	정상	프로비저닝 확인
p4d.24xlarge	A100 40GB x 8	320GB	정상	dry-run 확인
p5.48xlarge	H100 80GB x 8	640GB	정상	Spot 프로비저닝 확인 (us-east-2)
p5en.48xlarge	H200 141GB x 8	1,128GB	제한적	dry-run 통과, offering 매칭 실패 가능
p6-b200.48xlarge	B200 180GB x 8	1,440GB	정상 (2026-04-10부터 공식 지원)	NodePool instance-family: p6-b200 명시 필요

p6-b200 인스턴스 지원 (2026-04-10+)

EKS Auto Mode는 2026-04-10부터 p6-b200.48xlarge를 공식 지원합니다. NodePool requirements에서 eks.amazonaws.com/instance-family: p6-b200으로 명시해야 하며, 리전별 B200 용량 및 Capacity Block 가용성에 따라 실제 프로비저닝이 제한될 수 있습니다.

리전별 GPU 용량 가용성

리전	p5.48xlarge On-Demand	p5.48xlarge Spot	Spot 가격
ap-northeast-2 (서울)	InsufficientCapacity	미확인	--
us-east-2 (Ohio)	가용성 변동	확보 성공	$13~15/hr

Spot 가격 비교 (us-east-2, 2026.04 기준): p5 인스턴스는 Spot으로 약 7376% 비용 절감이 가능합니다 (On-Demand $55.04/hr 대비 Spot $1315/hr 관측치 기준). 상세 가격표는 GPU 리소스 관리 — 비용 최적화 전략를 참조하세요.

GPU 쿼타 주의사항

쿼타 이름	적용 인스턴스	AWS 기본값	계정별 적용값 예시
Running On-Demand P instances	p4d, p4de, p5, p5en	0 vCPU	384 (사용량에 따라 자동 증가)
Running On-Demand G and VT instances	g5, g6, g6e	0 vCPU	64 (사용량에 따라 자동 증가)

G 인스턴스 쿼타 함정

GPU NodePool에 instance-category: [g, p]를 함께 설정한 경우, Karpenter가 G 타입 인스턴스를 먼저 시도할 수 있습니다. P 타입만 사용하려면 instance-category: [p]로 명시적으로 지정하세요.

---

다음 단계

• EKS GPU 노드 전략 -- Auto Mode vs Karpenter vs Hybrid Node, 모델 크기별 비용 분석
• vLLM 기반 FM 배포 및 성능 최적화 -- vLLM 기본 개념 및 배포
• MoE 모델 서빙 가이드 -- Mixture of Experts 모델 서빙
• GPU 리소스 관리 -- GPU 클러스터 리소스 관리

---

참고 자료

• llm-d GitHub
• llm-d Deployer (Helm Charts)
• EKS Auto Mode 문서
• Gateway API Inference Extension
• vLLM 공식 문서
• Qwen3-32B HuggingFace