모델 서빙 & 추론 인프라
개요
이 문서는 GPU/가속기 위에서 LLM을 배포·서빙하는 방법을 다루는 모델 서빙 & 추론 인프라 카테고리의 진입 문서입니다. LLM 추론(Inference)이 인프라 레벨에서 어떻게 동작하는지를 요청 경로 전체에 걸쳐 설명하고, 각 계층에서 무엇을 튜닝할 수 있는지를 한 장의 지도로 정리합니다. 대상 독자는 EKS 위에 추론 플랫폼을 설계·운영하는 플랫폼 엔지니어입니다.
추론 최적화는 단일 기술이 아니라 여러 계층의 조합으로 달성됩니다. GPU 노드 배치부터 서빙 엔진의 메모리 관리, 분산 토폴로지, 클러스터 내 라우팅, 게이트웨이 정책, 캐시 계층까지 각 단계마다 고유한 튜닝 레버가 존재합니다. 이 문서는 그 레버를 계층별로 나열하고 연결하는 지도 역할을 하며, 각 주제의 상세 내용은 전용 심화 문서로 연결됩니다. 본문은 개념과 연결 관계에 집중하고, 구현·배포 절차는 링크된 문서에서 다룹니다.
카테고리 구성
- 가속 컴퓨팅 인프라 계층: Kubernetes 위에서 GPU·AWS 커스텀 가속기(Trainium/Inferentia) 인스턴스·드라이버·스케줄러·파티셔닝을 관리하는 계층. 어느 노드에 어떻게 가속기를 할당할지 결정합니다.
- 추론 프레임워크 계층: 확보된 GPU 위에서 실제로 모델을 서빙·분산 추론·파인튜닝하는 AI 프레임워크 계층. vLLM·llm-d·MoE·NeMo 가 여기 속합니다.
- 추론 최적화 & 라우팅 계층: KV cache·Disaggregated Serving·LMCache·캐시 히트 전략과 게이트웨이 라우팅으로 성능과 비용을 최적화하는 계층.
아래 지도로 전체 그림을 잡은 뒤 가속 컴퓨팅 인프라 → 추론 프레임워크 → 추론 최적화 & 라우팅 순으로 읽는 것이 자연스럽습니다. 가속 컴퓨팅 인프라에서 "어떤 노드·파티셔닝·드라이버 스택을 쓸 것인가" 를 결정하고, 추론 프레임워크에서 "그 위에 vLLM·llm-d 를 어떻게 배포할 것인가" 를, 추론 최적화 & 라우팅에서 "어떻게 성능·비용을 최적화하고 트래픽을 라우팅할 것인가" 를 다룹니다.
추론 요청의 전체 경로
LLM 추론 요청은 클라이언트에서 GPU 연산까지 여러 계층을 통과합니다. 각 계층은 서로 다른 책임을 가지며, 어느 계층에서 어떤 결정을 내리느냐에 따라 지연 시간(Latency)과 처리량(Throughput), 비용이 달라집니다.
각 계층의 역할은 다음과 같습니다.
- L4 게이트웨이: 외부 트래픽 진입(Tier 1)과 모델 추상화·Cascade·캐싱(Tier 2 ②)을 담당합니다.
- L3 추론 라우팅: 자체 호스팅 모델에서 어느 Pod로 보낼지를 KV cache·부하를 고려해 결정합니다. 결정은 ext-proc로 게이트웨이(프록시)에 위임되며, EPP는 선택한 엔드포인트 주소만 돌려주고 실제 요청 전달은 게이트웨이가 수행합니다.
- L2·L1 서빙/분산: 실제 토큰을 생성하는 계층으로, prefill/decode 처리와 KV cache 관리가 일어납니다.
- L0 GPU/가속기: 연산이 실행되는 물리 계층으로, 노드 선택·파티셔닝·드라이버 스택을 다룹니다.
두 종류의 라우팅 — 라우팅 ≠ 추론
추론 인프라에는 성격이 다른 두 개의 라우팅 결정이 존재하며, 이 둘을 혼동하면 게이트웨이 선택이 어긋납니다.
- across-model 라우팅 (Tier 2 ②): "어느 모델로 보낼 것인가"를 결정합니다. 복잡도 기반 Cascade, 비용 추적, 외부 프로바이더 폴백이 여기에 속합니다. Bifrost·LiteLLM 같은 LLM API Gateway가 담당합니다.
- within-model 라우팅 (Tier 2 ①): "같은 모델의 여러 Pod 중 어느 Pod로 보낼 것인가"를 결정합니다. KV cache 위치와 부하를 실시간 메트릭으로 보고 고릅니다. Gateway API Inference Extension(InferencePool·EPP)이 담당합니다.
두 레이어의 정의와 대응 관계는 티어드 게이트웨이 아키텍처와 라우팅 전략 — 두 개의 라우팅 레이어에서 상세히 다룹니다.
레이어드 튜닝 모델
추론 성능을 좌우하는 튜닝 레버를 계층별로 정리하면 다음과 같습니다. 각 레버의 상세 동작과 설정은 우측 심화 문서를 참조하세요.
| 계층 | 주요 튜닝 레버 | 영향 지표 | 심화 문서 |
|---|---|---|---|
| L0 GPU/가속기 | 인스턴스 선택 · MIG · Time-Slicing · DRA · Neuron | GPU 활용률 · 비용 | GPU 리소스 관리 |
| L1 서빙 엔진 | PagedAttention · Continuous Batching · FP8 KV · Prefix Caching · Chunked Prefill · Speculative Decoding · 양자화 · TP/PP/EP | TTFT · TPS · 메모리 | vLLM 모델 서빙 · KV Cache 최적화 |
| L2 분산 토폴로지 | Prefill/Decode 분리 · NIXL · LWS 멀티노드 | 대형 모델 처리량 | Disaggregated Serving |
| L3 추론 라우팅 | KV cache-aware · prefix-cache scorer (같은 모델 내 Pod 선택) | 캐시 적중률 · P99 | KV Cache-Aware Routing |
| L4 게이트웨이 | 모델 Cascade · context-aware(모델 선택) · 비용 추적 · Rate Limit · L7 한계 보완 | 비용 · 가용성 | 티어드 게이트웨이 · 라우팅 전략 |
| L5 캐시 계층 | KV/prefix cache · prompt cache · semantic cache · LMCache | 캐시 적중률 · 비용 | LMCache · 캐시 히트 전략 |
하위 계층(L0 GPU)부터 상위 계층(L4 게이트웨이)으로 읽으면 인프라 관점에서, 요청 경로 순서(L4 → L0)로 읽으면 트래픽 관점에서 이해하기 쉽습니다. 성능 지표(TTFT·TPS·캐시 적중률)와 3-Tier 권장 구성은 추론 최적화 개요를 참조하세요.
추론 게이트웨이의 역할과 기능
"추론 게이트웨이(Inference Gateway)"는 단일 컴포넌트가 아니라 서로 다른 책임을 가진 여러 계층의 묶음입니다. 플랫폼 전역에서는 클러스터 내 추론 Pod 라우팅과 외부 LLM 프로바이더 프록시를 명시적으로 구분합니다.
| 계층 | 역할 | 대표 구현체 |
|---|---|---|
| Tier 1 Ingress | 외부 트래픽 수신, TLS 종료, 인증, Rate Limiting | kgateway · AWS LBC · Envoy Gateway |
| Tier 2 ① Inference Routing | 클러스터 내 추론 Pod 선택(KV·부하 인지) | Gateway API Inference Extension |
| Tier 2 ② LLM API Gateway | 모델 추상화, Cascade, 비용 추적, Semantic Caching | Bifrost · LiteLLM · OpenRouter |
각 계층의 역할 정의와 솔루션 선정 기준은 티어드 게이트웨이 아키텍처에, 솔루션 비교와 Cascade·Semantic 전략은 라우팅 전략에 정리되어 있습니다.
기존 L7 게이트웨이의 한계
범용 L7 게이트웨이를 기본값(요청 수 기반 분배)으로만 사용하면, LLM 추론 트래픽의 특성을 반영하지 못해 다음과 같은 한계가 나타납니다. 이는 L7 게이트웨이 자체의 한계라기보다, 추론에 맞게 설정·확장하지 않은 구성의 한계입니다.
- 설정되지 않은 Round-Robin은 prefix cache 재사용을 떨어뜨림: 동일 시스템 프롬프트를 공유하는 요청이 매번 다른 Pod로 분배되면, 각 Pod가 같은 prefill 연산을 반복할 수 있습니다. 다만 여러 Pod가 이미 같은 prefix로 워밍업되어 있으면 round-robin에서도 재사용이 일어나므로, 효과는 복제본 수·캐시 보유 상태에 따라 달라집니다.
- 기본 설정은 토큰 단위 비용·스트리밍을 반영하지 못함: 요청 수만으로 부하를 판단하는 기본 구성은 토큰 길이에 비례하는 실제 연산 비용을 반영하지 못합니다. 토큰·스트리밍 인지는 플러그인이나 ext-proc 확장으로 추가할 수 있는 선택적 기능입니다.
- 모델 서버 메트릭 미연동: KV cache 사용량, 대기 큐 깊이(queue depth) 같은 추론 엔진 내부 상태를 연동하지 않은 구성은 부하가 몰린 Pod로도 요청을 보낼 수 있습니다.
이 한계는 캐시 지역성(locality)과 부하 분산 사이의 트레이드오프로 요약됩니다. 지역성만 좇으면 특정 Pod에 쏠리고, 부하만 좇으면 캐시 재사용이 줄어듭니다. KV·부하를 함께 보는 별도의 추론 라우팅 계층(Tier 2 ①)이나, L7 게이트웨이에 ext-proc·prefix scorer 플러그인을 더하는 방식으로 이 트레이드오프를 조정합니다. 상세 근거는 KV Cache 최적화 — 기존 문제: Round-Robin의 한계와 라우팅 전략 — 두 개의 라우팅 레이어를 참조하세요.
prefill / decode / Disaggregated Serving
LLM 추론은 입력 프롬프트를 처리하는 prefill 단계와, 토큰을 하나씩 생성하는 decode 단계로 나뉩니다. 두 단계는 연산 특성이 달라 일반적으로 prefill은 연산 집약적, decode는 메모리 대역폭 집약적인 경향을 보입니다. 같은 GPU에 함께 두면 서로 간섭해 지연이 늘 수 있으나, 정도는 배치·시퀀스 길이·트래픽 패턴에 따라 다릅니다. 또한 긴 프롬프트는 chunked prefill로 여러 스텝에 나눠 처리해 decode와의 간섭을 줄일 수 있어, prefill이 반드시 "한 번에" 처리되는 것은 아닙니다.
Disaggregated Serving은 prefill과 decode를 별도의 GPU 그룹으로 분리하고, 그 사이의 KV cache를 NIXL 같은 전송 엔진으로 옮기는 아키텍처입니다. 분리는 KV cache 전송·배치 비용을 수반하므로, 이득은 워크로드에서 측정해 판단해야 하는 선택적 설계입니다. 대형 MoE 모델은 단일 노드에 담기 어려울 때 LWS(LeaderWorkerSet) 기반 멀티노드 배포와 결합할 수 있습니다. 상세 아키텍처와 GLM-5 배포 예제는 Disaggregated Serving에, AWS 관리형 구현은 HyperPod Inference Operator — Disaggregated Prefill/Decode에 정리되어 있습니다.
Context-aware routing
context-aware 라우팅은 요청의 내용·복잡도를 보고 적절한 모델·경로를 고르는 전략입니다. 단순 질의는 경량 모델로, 복잡한 추론은 대형 모델로 보내 비용과 품질을 균형 잡습니다.
- LLM Classifier: 요청을 복잡도 티어로 분류해 라우팅
- RouteLLM: MF(Matrix Factorization) 분류기로 모델 선택
- vLLM Semantic Router: 의미 기반 라우팅
상세 구현과 평가 결과는 Request Cascading — 지능형 모델 라우팅을 참조하세요. 의미 기반 캐시와의 관계는 Semantic Caching 전략에서 다룹니다.
KV cache-aware routing
KV cache-aware 라우팅은 같은 모델의 여러 Pod 중에서 요청의 prefix와 일치하는 KV cache를 이미 보유한 Pod로 보내는 전략입니다. prefill 재연산을 피하면 TTFT를 줄일 수 있지만, 항상 더 빠른 것은 아닙니다. 캐시를 가진 Pod가 이미 과부하이거나 해당 캐시가 축출(eviction)되었다면 지역성 이득이 사라지므로, 실제 효과는 지역성·부하·축출 상태의 균형에 달려 있습니다.
- prefix-cache scorer: 각 Pod의 prefix 캐시 보유 상태를 점수화
- EPP(Endpoint Picker): ext-proc로 위임받아 최적 Pod 선택
- llm-d vs NVIDIA Dynamo: 구현 방식과 KV 오프로딩 계층이 다름
상세 비교는 KV Cache 최적화 — KV Cache-Aware Routing과 라우팅 전략 — EPP 정확한 정의를 참조하세요.
LMCache
LMCache는 KV cache를 GPU 메모리 너머 CPU·디스크 계층으로 오프로딩하고, 여러 추론 인스턴스 간에 공유하는 KV cache 계층입니다. vLLM의 in-GPU prefix cache는 하나의 추론 엔진(TP/PP로 여러 Pod·노드에 걸칠 수 있는 복제본) 범위 안에서만 유효한 반면, LMCache는 그 범위를 넘어 여러 복제본·노드 간에 KV cache를 재사용할 수 있는 외부 공유 계층을 제공합니다. 다만 이 외부 공유가 라우팅과 자동으로 연동되는 것은 아니며, kvaware 라우팅과 결합하려면 메모리 호환성과 연동 설정을 별도로 맞춰야 합니다.
개념·계층 구조·vLLM/NIXL과의 관계는 LMCache 문서에서 다룹니다.
캐시 히트 전략
추론 캐시는 단일 계층이 아니라 세 계층으로 나뉘며, 각각 적중 조건과 효과가 다릅니다. 아래 "완전 동일 요청"·"유사 요청"은 캐시 적중의 필요조건일 뿐이며, 재사용이 안전하려면 테넌트·인증 주체·모델·도구 정의·데이터 신선도가 함께 일치해야 합니다.
| 캐시 계층 | 적중 조건 | 효과 |
|---|---|---|
| KV / Prefix Cache | 동일 prefix(시스템 프롬프트 등) — 프로바이더 prompt caching 포함 | prefill 재연산 회피, 입력 토큰 비용·TTFT 감소 (전체 추론을 건너뛰지는 않음) |
| Response (Exact) Cache | 테넌트·모델·도구·데이터가 같은 완전 동일 요청 | 저장된 응답을 그대로 반환해 추론 자체를 회피 |
| Semantic Cache | 의미적으로 유사한 요청(임베딩 유사도) + 보정된 동치 임계값 | 유사 질의 추론 회피 (임계값·오탐 관리 필요) |
여기서 KV/Prefix Cache와 OpenAI·Anthropic 등의 prompt caching은 프롬프트 prefix를 재사용해 입력 토큰 비용과 TTFT를 줄이는 것이지, 응답을 통째로 반환하는 것이 아닙니다. 응답을 통째로 반환하는 것은 별도의 exact 응답 캐시 계층이며, Semantic Cache는 유사도만으로 적중시키면 다른 답을 돌려줄 수 있으므로 임계값을 보정하고 응답 동치 기준을 함께 정의해야 합니다.
각 계층의 히트율을 어떻게 높이고 어디서 측정하는지를 통합한 의사결정 프레임은 캐시 히트 전략에서 다룹니다. semantic cache의 임계값 설계는 Semantic Caching 전략을, prefix cache 효과는 KV Cache 최적화를 참조하세요.
참고 자료
공식 문서
- Gateway API Inference Extension — 클러스터 내 추론 라우팅(InferencePool·EPP) 표준
- vLLM Documentation — vLLM 서빙 엔진 공식 가이드
논문 / 기술 블로그
- PagedAttention (SOSP 2023) — vLLM KV cache 관리 논문
- DistServe (OSDI 2024) — Prefill/Decode 분리(Disaggregated Serving) 연구
관련 문서 (내부)
- 추론 최적화 개요 — TTFT·TPS 등 핵심 지표와 3-Tier 권장 구성
- 티어드 게이트웨이 아키텍처 — 게이트웨이 계층 단일 정의
- KV Cache 최적화 — vLLM 심화와 KV Cache-Aware Routing