들어가며

vLLM이나 SGLang을 실행하면 GPU 한 대 또는 여러 GPU에 모델을 올리고 OpenAI 호환 API로 추론 요청을 받을 수 있습니다. 여기까지는 모델 서버가 잘 해결합니다. 그러나 같은 모델 서버를 여러 Pod로 늘리는 순간 문제의 성격이 달라집니다.

• 어떤 Pod는 긴 요청을 처리하느라 큐가 밀려 있고 다른 Pod는 한가할 수 있습니다.
• 이전 요청의 prefix KV 캐시가 특정 Pod에만 남아 있을 수 있습니다.
• 같은 수의 요청을 처리 중이어도 남은 생성 토큰과 GPU 메모리 압력은 다를 수 있습니다.
• Prefill과 Decode를 서로 다른 하드웨어와 워커로 분리할 수 있습니다.
• Pod가 증감하거나 모델 버전이 바뀌는 동안에도 요청을 안전하게 보내야 합니다.
• 평균 지연시간뿐 아니라 P95·P99 tail latency와 SLO를 지켜야 합니다.

일반적인 Kubernetes Service나 round-robin 로드 밸런서는 이런 추론 상태를 알지 못합니다. llm-d는 각 모델 서버의 부하, KV 캐시 지역성, 역할과 정책을 보고 요청마다 더 적합한 Endpoint를 선택합니다. 여기에 검증된 배포 레시피, KV 캐시 관리, 분리 서빙, 오토스케일링과 관측성을 결합해 단일 모델 서버를 프로덕션 분산 추론 서비스로 확장합니다.

llm-d란 무엇인가

llm-d는 Kubernetes를 중심으로 설계된 오픈소스 분산 추론 서빙 스택입니다. vLLM, SGLang 같은 모델 서버를 여러 노드와 가속기에 걸쳐 운영하면서 지능형 라우팅과 캐시 재사용, 확장과 관측성 문제를 해결합니다.

프로젝트는 2025년 5월 Red Hat, Google Cloud, IBM Research, CoreWeave와 NVIDIA의 공동 작업으로 공개됐습니다. 2026년 3월 CNCF Sandbox 프로젝트로 합류했으며, 현재는 오픈 거버넌스 아래에서 여러 하드웨어·클라우드·추론 엔진 커뮤니티가 함께 개발합니다.

llm-d의 목표는 특정한 모델이나 GPU 조합 하나를 위한 제품을 만드는 것이 아닙니다. 공식 표현인 “any model, any accelerator, any cloud”처럼, 모델 서버와 하드웨어 위에 재사용할 수 있는 분산 추론 패턴을 제공하려는 프로젝트입니다.

다만 이 문구를 모든 조합이 동일한 수준으로 검증됐다는 의미로 받아들이면 안 됩니다. 실제 지원 수준과 성능은 엔진, 모델, 가속기, 네트워크와 릴리스별 Well-Lit Path를 확인해야 합니다.

llm-d는 추론 엔진이 아니다

llm-d와 vLLM의 역할을 먼저 구분해야 합니다.

llm-d는 더 빠른 attention kernel을 제공하거나 직접 토큰을 생성하는 엔진이 아닙니다. 이미 잘 동작하는 모델 서버를 감싸고, 여러 인스턴스를 하나의 분산 추론 시스템으로 운영하는 상위 계층입니다.

Model Server도 llm-d에 종속될 필요가 없습니다. 독립적으로 배포한 vLLM이나 SGLang Pod를 라벨로 InferencePool에 묶으면 Router가 후보 Endpoint로 발견합니다. 모델 서버는 OpenAI 호환 API와 health endpoint, 큐 깊이와 KV 캐시 사용률 같은 메트릭을 제공하고 실제 추론을 담당합니다.

왜 일반 로드 밸런싱으로는 부족한가

웹 서버의 요청 처리 비용이 대체로 비슷하다면 round-robin이나 least-request도 좋은 출발점입니다. 그러나 LLM 요청은 입력 context와 출력 길이에 따라 처리 비용이 크게 달라집니다. 특히 autoregressive Decode는 요청마다 종료 시점이 달라 Pod의 부하가 빠르게 불균형해집니다.

KV 캐시는 문제를 더 상태 지향적으로 만듭니다. 같은 system prompt나 문서 prefix를 가진 요청을 캐시가 있는 Pod로 보내면 Prefill 계산을 재사용할 수 있지만, 다른 Pod로 보내면 같은 연산을 다시 수행해야 합니다. 즉 겉으로 같은 모델 Pod라도 요청마다 가장 유리한 목적지가 달라집니다.

일반 Kubernetes Service가 나쁘다는 뜻은 아닙니다. Service는 안정적인 가상 IP와 기본적인 Endpoint 분산이라는 문제를 해결합니다. llm-d는 그 위에서 **“어느 Pod가 연결 가능한가”가 아니라 “이 추론 요청을 지금 어느 Pod가 처리하는 것이 가장 유리한가”**를 판단합니다.

llm-d의 설계 방향

Kubernetes-native

llm-d는 Gateway, HTTPRoute, InferencePool과 Pod label 같은 Kubernetes API를 중심으로 구성됩니다. 모델 서버가 스케일 인·아웃되거나 readiness가 바뀌면 후보 Endpoint 목록도 갱신됩니다. 기존 Gateway와 서비스 메시 구현을 활용하므로 TLS 종료, 연결 관리와 일반적인 L7 기능을 다시 구현하지 않습니다.

프로젝트의 주 운영 모델은 Kubernetes이지만 Router에는 Proxy와 EPP를 같은 Pod 또는 호스트에 두는 Standalone Mode도 있습니다. 테스트, 기존 Ingress 환경, 배치 추론이나 RL 파이프라인처럼 Gateway API 전체가 필요하지 않은 경우에 사용할 수 있습니다. 따라서 “Kubernetes-native”와 “모든 구성 요소가 반드시 Kubernetes에서만 동작한다”는 말은 구분해야 합니다.

Engine- and hardware-agnostic

llm-d는 특정 엔진을 포크하는 대신 표준 API, 메트릭과 KV cache connector를 통해 vLLM, SGLang 등의 모델 서버와 결합합니다. 하드웨어도 NVIDIA와 AMD GPU, Intel XPU, Google TPU와 여러 가속기용 배포 경로를 확장하고 있습니다.

이식성이 공짜로 생기는 것은 아닙니다. Prefill/Decode 분리나 KV 전송처럼 하드웨어와 네트워크에 민감한 기능은 엔진과 가속기별 connector, RDMA 구성과 검증된 이미지가 필요합니다. 실제 도입에서는 해당 조합의 Well-Lit Path와 CI 검증 범위를 확인해야 합니다.

조합 가능한 모듈

llm-d는 하나의 거대한 추론 서버가 아니라 여러 오픈소스 구성 요소를 조합합니다. Gateway provider, 모델 서버, KV 캐시 계층, autoscaler와 관측성 도구를 환경에 맞게 선택할 수 있습니다. 이 구조는 교체 가능성을 높이지만, 각 컴포넌트의 호환 버전을 맞추는 운영 책임도 함께 만듭니다.

핵심 아키텍처

llm-d의 기본 구조는 Router, InferencePool, Model Server 세 가지로 이해할 수 있습니다.

llm-d Router

llm-d Router는 추론 요청의 지능형 진입점입니다. 하나의 프로세스 이름이 아니라 다음 두 기능을 합친 용어입니다.

Proxy

Proxy는 실제 요청 경로에 있는 고성능 L7 프록시입니다. 클라이언트의 OpenAI 호환 요청을 받고 TLS, 연결 관리, 요청 전달과 응답 스트리밍을 담당합니다. llm-d가 전체 프록시를 새로 구현하는 대신 Istio, Agent Router, agentgateway, GKE Gateway 같은 Gateway API·Inference Extension 호환 구현체를 사용할 수 있습니다.

일부 llm-d 문서와 예제에는 과거 이름인 Envoy AI Gateway가 남아 있을 수 있습니다. 현재 프로젝트 이름은 Agent Router지만 CRD와 API 이름은 유지되므로 기존 통합 개념은 그대로 연결됩니다.

llm-d Endpoint Picker, EPP

EPP는 Proxy가 매 요청마다 상담하는 라우팅 엔진입니다. 현재 InferencePool의 상태를 보고 KV 캐시 지역성, 부하, 우선순위와 설정된 정책에 따라 최적의 Model Server Pod를 선택합니다.

Proxy와 EPP를 분리하면 각자의 책임이 선명해집니다.

• Proxy는 검증된 네트워크 데이터 플레인을 제공합니다.
• EPP는 LLM에 특화된 선택 로직에 집중합니다.
• 스케줄링 정책을 확장해도 Proxy 코어를 포크할 필요가 없습니다.
• Gateway 구현체를 바꿔도 EPP의 판단 모델을 재사용할 수 있습니다.

InferencePool

InferencePool은 같은 base model을 제공하는 Model Server Pod들을 label selector로 묶는 중앙 리소스입니다. Kubernetes Service와 비슷해 보이지만, 단순한 네트워크 Endpoint 목록이 아니라 Gateway와 EPP를 연결하는 LLM 최적화 Service에 가깝습니다.

InferencePool은 두 가지 역할을 합니다.

1. EPP에 어떤 Pod가 후보이고 어느 포트로 요청해야 하는지 알려줍니다.
2. Gateway Controller에 어떤 EPP를 ext_proc로 연결해야 하는지 알려줍니다.

Pod가 추가·삭제되거나 Ready 상태가 바뀌면 EPP의 후보 목록도 갱신됩니다. HTTPRoute가 InferencePool을 backendRef로 사용하면 해당 경로의 요청만 EPP를 통한 추론 인지형 라우팅을 거칩니다. 같은 Gateway의 일반 Service 트래픽은 기존 방식으로 처리할 수 있습니다.

Variant

Variant는 InferencePool 안에서 공통 특성을 가진 Model Server의 논리적 부분집합입니다. 별도 리소스가 아니라 Pod label로 표현합니다.

• prefill, decode, encode 같은 서빙 역할
• 비용이나 가속기 종류
• 처리량 또는 지연시간 프로필
• 모델 revision이나 배포 세대

EPP는 Variant를 이용해 요청의 단계와 정책에 맞는 후보만 남길 수 있습니다.

Model Server

Model Server는 llm-d 스택의 실제 실행 계층입니다. 모델을 GPU·TPU·XPU 등에 올리고 토큰을 생성합니다. 대표적인 엔진은 vLLM과 SGLang이며, 통합 경로에 따라 다른 서버도 사용할 수 있습니다.

EPP가 지능적으로 판단하려면 Model Server에서 최소한 다음 상태를 얻을 수 있어야 합니다.

• 대기 중인 요청 수
• 실행 중인 요청 수
• KV 캐시 사용률
• health와 readiness
• 선택적으로 block size, GPU block 수와 LoRA 상태

엔진마다 실제 metric 이름은 다르므로 llm-d Data Layer가 이를 공통 Endpoint 속성으로 정규화합니다.

요청 하나가 처리되는 과정

llm-d Router는 연결을 한 번 분배하고 끝나는 대신 요청마다 EPP에 Endpoint 선택을 묻습니다.

1. 클라이언트가 Proxy로 추론 요청을 보냅니다.
2. Proxy는 요청을 잠시 보류하고 ext_proc 프로토콜로 EPP를 호출합니다.
3. EPP의 Request Handler가 OpenAI 요청을 내부 표현으로 파싱합니다.
4. Data Layer와 Data Producer가 Endpoint 상태, prefix 일치와 예측 지연시간 같은 판단 자료를 준비합니다.
5. Flow Control이 풀이 포화 상태인지 확인하고 필요하면 큐에 대기시키거나 요청을 거부합니다.
6. Request Scheduler가 후보를 Filter → Score → Pick 순서로 평가합니다.
7. EPP가 선택한 Endpoint 주소를 Proxy에 돌려줍니다.
8. Proxy가 원래 요청을 해당 Model Server Pod로 전달합니다.
9. 모델 응답은 Proxy를 거쳐 클라이언트로 스트리밍되고, EPP는 완료와 사용량 상태를 갱신합니다.

EPP가 Endpoint를 고르는 방법

Data Layer: 판단 근거 수집

과거 발표 자료에서는 각 Pod의 상태를 읽는 구성 요소를 Scraper라고 설명하기도 했습니다. 현재 아키텍처에서는 이 기능을 더 넓은 Data Layer로 설명합니다.

Data Layer는 Kubernetes API와 Model Server 메트릭, Endpoint 생명주기 이벤트와 KV cache event를 수집해 Endpoint별 속성으로 저장합니다. 여기서는 자료를 수집하고 정규화할 뿐, 실제 라우팅 결정은 Request Scheduler가 내립니다.

Flow Control: 언제 보낼 것인가

LLM 요청은 일단 GPU에 전달하면 다른 Pod로 옮기기 어렵습니다. 긴 context 요청 하나가 많은 KV 캐시와 실행 시간을 차지할 수도 있습니다. Flow Control은 포화 상태에서 무작정 요청을 디스패치하지 않고 중앙 큐에서 대기시키며 우선순위와 공정성을 적용합니다.

이 계층은 세 가지 질문을 다룹니다.

• 지금 Model Server Pool이 새 요청을 받을 수 있는가?
• 같은 우선순위 안에서 어느 tenant 또는 flow를 먼저 처리할 것인가?
• 같은 flow 안에서는 FCFS, deadline, SLO 중 어떤 순서를 사용할 것인가?

v0.9에서는 queue TTL과 최대 요청 수에 안전한 기본값이 추가되고, backpressure와 빈 Endpoint Pool을 서로 다른 상태 코드로 구분하는 등 프로덕션 보호 기능이 강화됐습니다.

Request Scheduler: 어디로 보낼 것인가

Flow Control을 통과한 요청은 다음 세 단계를 거칩니다.

Filter

요청을 처리할 수 없는 후보를 제거합니다.

• 필요한 LoRA adapter나 label이 없는 Endpoint
• Prefill 또는 Decode 역할이 맞지 않는 Endpoint
• KV 캐시나 GPU 사용률이 임계값을 넘은 Endpoint
• 요청의 SLO를 충족할 여지가 없는 Endpoint

Score

남은 후보마다 여러 신호를 점수로 계산합니다.

• prefix cache 일치 길이
• KV 캐시 사용률
• queue depth와 실행 중인 요청·토큰 수
• 예측 TTFT·TPOT와 SLO headroom
• session affinity와 LoRA affinity

여러 scorer의 점수에 weight를 적용해 합산할 수 있습니다. 예를 들어 반복되는 긴 system prompt가 중요한 workload는 prefix 점수를 높이고, 짧은 대화형 요청은 latency와 queue 점수를 높일 수 있습니다.

Pick

최종 점수를 이용해 Endpoint를 하나 선택합니다. 가장 높은 점수를 고르거나, 점수를 확률로 사용하는 weighted random 같은 전략을 사용할 수 있습니다. Prefill/Decode 분리에서는 역할별 Scheduling Profile을 각각 실행해 두 Endpoint를 선택합니다.

llm-d의 핵심 확장 기능

Prefix-cache-aware Routing

동일하거나 공통 prefix가 긴 요청을 이미 관련 KV 캐시를 가진 Pod로 보냅니다. 캐시가 적중하면 이전 token의 Prefill 계산을 반복하지 않아도 되므로 TTFT와 연산량을 줄일 수 있습니다.

llm-d는 두 수준의 접근을 제공합니다.

• 근사 방식: EPP가 이전 라우팅과 prompt hash를 바탕으로 캐시 위치를 추정합니다. 가볍지만 실제 eviction과 차이가 날 수 있습니다.
• 정밀 방식: Model Server의 KV event와 정확한 token block 정보를 이용해 Pool 전체의 캐시 위치를 추적합니다. 정확하지만 tokenizer, event 전달과 index 운영이 필요합니다.

Cache affinity만 가장 높게 적용하면 특정 Pod에 요청이 몰릴 수 있습니다. 실제 정책은 캐시 재사용 이익과 현재 부하를 함께 평가해야 합니다. 이를 요약한 것이 “sticky until saturated”, 즉 캐시가 있는 Endpoint를 선호하되 포화되면 다른 Endpoint로 분산하는 방식입니다.

KV-Cache Indexing과 Offloading

KV-Cache Indexer는 어느 Model Server가 어떤 prefix block을 보유하는지 event 기반으로 추적합니다. 이 전역 cache view가 정밀한 prefix-cache-aware routing의 판단 근거가 됩니다.

Offloading은 GPU HBM에만 머물던 KV block을 CPU DRAM, 로컬 SSD 또는 공유 스토리지 계층으로 옮깁니다. 캐시 용량을 늘리고 재계산을 줄일 수 있지만, 저장·복원 지연과 네트워크 대역폭이 새 병목이 될 수 있으므로 workload별 측정이 필요합니다.

Prefill/Decode Disaggregation

Prefill은 긴 입력을 병렬로 계산하는 compute-intensive 단계이고, Decode는 토큰을 하나씩 생성하며 메모리 대역폭의 영향을 크게 받습니다. llm-d는 두 단계를 서로 다른 Worker Pool과 하드웨어에서 처리하도록 분리할 수 있습니다.

Router는 Prefill과 Decode Endpoint를 각각 선택하고, 두 단계 사이의 KV 캐시 전송을 조율합니다. 자원을 단계별로 독립 확장할 수 있지만 KV 전송, 네트워크 topology, 모델 revision 호환성과 장애 처리가 추가됩니다. v0.9에서는 rolling update와 topology-aware routing 등 분리 서빙의 운영 안전성이 강화됐습니다.

Predicted-latency Scheduling

현재 queue depth만 보는 대신 요청 특성과 Endpoint 상태를 이용해 TTFT와 TPOT를 예측하고, SLO를 만족할 여유가 큰 Endpoint를 선택할 수 있습니다. 예측기는 강력하지만 학습 데이터가 workload와 맞지 않으면 오히려 잘못된 선택을 할 수 있으므로 실제 트래픽에서 오차와 drift를 함께 관찰해야 합니다.

Autoscaling과 관측성

EPP는 queue depth, in-flight request, token backlog, KV cache pressure와 SLO 관련 신호를 Pool 수준 metric으로 노출할 수 있습니다. v0.9부터는 KEDA를 중심으로 autoscaling 경로를 정리하고 있으며, 부하가 이미 임계값을 넘은 뒤 반응하는 방식뿐 아니라 predicted latency를 이용한 SLO-aware scaling도 발전시키고 있습니다.

요청 경로가 Proxy, EPP, Prefill Worker, KV 전송과 Decode Worker로 길어지면 단일 서비스 metric만으로 병목을 찾기 어렵습니다. llm-d는 OpenTelemetry trace context를 전체 P/D 경로로 전달하고 scheduler plugin의 소요시간까지 관찰하는 방향으로 확장되고 있습니다.

Batch, Multimodal과 RL Workload

llm-d의 지능형 라우팅과 캐시 재사용은 온라인 채팅만을 위한 기능이 아닙니다. OpenAI 호환 Batch API와 비동기 처리, 이미지·비디오 입력을 포함하는 multimodal serving, 이미지 생성 backend, RL rollout generation 같은 workload로 범위가 넓어지고 있습니다.

모든 기능의 성숙도가 같지는 않습니다. v0.9의 plugin lifecycle은 Alpha, Beta, Stable을 구분하며 실험적 plugin은 명시적으로 허용해야 사용할 수 있습니다. 소개 문서의 기능 목록보다 실제 릴리스의 안정성 등급과 Well-Lit Path 상태를 우선 확인해야 합니다.

Well-Lit Paths

llm-d는 소프트웨어 컴포넌트만 제공하지 않고, 검증·벤치마크된 배포 레시피인 Well-Lit Paths를 제공합니다. 처음부터 분산 추론 구조를 설계하는 대신 재현 가능한 기준점에서 시작하게 하는 것이 목적입니다.

각 Well-Lit Path에는 일반적으로 다음이 포함됩니다.

• 배포 가능한 Helm chart와 Kustomize manifest
• 모델, 엔진과 하드웨어 조합
• 성능 조정에 중요한 설정값
• baseline과 비교할 sample workload·benchmark
• metrics, dashboard와 troubleshooting 정보

대표적인 출발점은 Optimized Baseline이며, 이후 prefix-cache routing, P/D disaggregation, KV offloading, autoscaling, batch와 workload별 경로를 선택할 수 있습니다.

배포 모드와 Gateway Provider

Standalone Mode

Proxy와 EPP를 같은 Pod 또는 호스트에 배치합니다. ext_proc 통신을 localhost로 처리하며 Gateway, HTTPRoute와 Gateway Controller가 없어도 됩니다. 빠른 평가, 레거시 Ingress, 배치 추론과 RL pipeline에 적합합니다.

Gateway Mode

프로덕션에서는 Kubernetes Gateway API와 Gateway API Inference Extension을 사용합니다. HTTPRoute가 InferencePool을 backend로 참조하면 Gateway가 EPP를 연결하고 요청별 Endpoint 선택을 적용합니다.

Gateway provider는 실제 네트워크 데이터 플레인을 구현합니다. llm-d 문서에는 Istio, GKE Gateway, agentgateway와 Agent Router 같은 구현 경로가 안내되어 있습니다. Provider마다 지원하는 Gateway API, ext_proc, 멀티클러스터와 운영 기능의 범위가 다르므로 호환성 표를 확인해야 합니다.

Agent Router와 llm-d Router는 무엇이 다른가

두 프로젝트는 모두 “Router”라는 이름을 쓰고 Envoy의 ext_proc를 활용할 수 있지만, 선택하는 대상이 다릅니다.

두 계층은 함께 사용할 수 있습니다.

Agent / Application
        │
        ▼
Agent Router
  인증 · 모델 가상화 · Provider/MCP 라우팅 · 전역 quota
        │
        ▼
llm-d Router
  KV cache · queue · latency · 역할 기반 Endpoint 선택
        │
        ▼
vLLM / SGLang Model Servers

Agent Router가 외부 공급자와 자체 호스팅 모델 사이의 상위 정책을 결정하고, 자체 호스팅 경로에서는 llm-d EPP가 실제 Model Server Pod를 고릅니다. 경쟁 제품이라기보다 서로 다른 해상도에서 라우팅하는 조합입니다.

llm-d를 도입할 때 먼저 확인할 질문

llm-d의 모든 기능을 한 번에 켜는 것보다 현재 병목에 맞는 기능부터 선택해야 합니다.

1. 단일 Model Server의 성능과 설정은 먼저 안정화됐는가?
2. workload의 반복 prefix 비율과 cache hit 가능성은 어느 정도인가?
3. 최적화 목표가 TTFT, TPOT, throughput, P99 또는 비용 중 무엇인가?
4. 일반 load balancing과 비교할 재현 가능한 baseline이 있는가?
5. Prefill/Decode를 분리했을 때 KV 전송 비용보다 얻는 이익이 큰가?
6. EPP 장애 시 FailOpen과 FailClose 중 어느 동작이 필요한가?
7. 사용할 엔진·가속기·Gateway provider 조합이 Well-Lit Path로 검증됐는가?
8. 실험적 plugin의 안정성 등급과 rollback 방법을 확인했는가?

마치며

llm-d를 한 문장으로 정의하면 모델 서버 위에서 동작하는 Kubernetes-native 분산 추론 제어·최적화 계층입니다.

핵심은 단순히 Pod 수를 늘리는 데 있지 않습니다. 각 요청의 token 특성과 각 Pod의 KV 캐시, queue, 역할과 SLO를 함께 보고 요청을 배치해야 확장이 실제 성능으로 이어집니다. llm-d Router는 Proxy와 EPP를 분리해 검증된 네트워크 데이터 플레인에 LLM 전용 의사결정을 결합하고, InferencePool은 동적으로 바뀌는 Model Server를 하나의 논리적 배포로 묶습니다.

이 기본 구조 위에 prefix-cache-aware routing, KV indexing과 offloading, Prefill/Decode disaggregation, predicted-latency scheduling, flow control, autoscaling과 end-to-end tracing이 조합됩니다. 그리고 Well-Lit Paths는 이러한 조합을 재현 가능한 배포와 benchmark에서 시작할 수 있게 합니다.

참고 자료

• llm-d Documentation
• llm-d Architecture
• llm-d Router
• llm-d Proxy
• llm-d InferencePool
• llm-d v0.9: Hardened for Scale
• llm-d Blog Archive
• CNCF: llm-d
• llm-d GitHub repository