llm-d 1.0이 바꾸는 Kubernetes LLM 추론 인프라, 핵심 기술과 성능은?

사용자는 같은 질문을 했다고 생각하는데, 어떤 요청은 거의 즉시 답변을 받고 어떤 요청은 한참을 기다립니다. GPU 사용률도 높고 서버도 충분히 늘렸는데 말입니다. 이때 원인은 단순히 GPU 성능 부족이 아닐 수 있습니다.

핵심은 요청이 이전 대화의 맥락을 기억하지 못하는 서버로 흩어진다는 데 있습니다.

LLM은 답변을 생성하기 전에 사용자의 프롬프트와 대화 이력을 먼저 읽어야 합니다. 이 과정에서 만들어지는 중간 상태가 바로 KV 캐시(Key-Value Cache) 입니다. 같은 대화의 다음 요청이 이전 요청을 처리했던 서버로 다시 전달되면, 이미 저장된 KV 캐시를 재사용할 수 있습니다. 반대로 다른 서버로 이동하면 이전 맥락을 다시 계산해야 합니다.

일반적인 로드 밸런싱

사용자 요청 A → Replica 1
사용자 요청 B → Replica 2
사용자 요청 C → Replica 3

이 방식은 서버 간 부하를 고르게 분산하는 데는 효과적입니다. 그러나 Agent처럼 여러 번 대화를 이어 가거나, 긴 문서를 반복해서 참조하는 환경에서는 문제가 생깁니다. Replica 1에 이미 계산된 대화 맥락이 있어도, 다음 요청이 Replica 2로 전달되면 GPU는 같은 프롬프트를 다시 처리해야 합니다.

그 결과는 명확합니다.

• 첫 토큰이 나오기까지의 시간, 즉 TTFT(Time to First Token) 가 길어집니다.
• GPU 연산과 메모리가 중복 사용됩니다.
• 긴 컨텍스트일수록 낭비가 커집니다.
• 일부 서버는 캐시를 보유한 채 한가하고, 다른 서버는 재계산 때문에 과부하가 걸릴 수 있습니다.
• 사용자는 서비스 품질이 들쭉날쭉하다고 느끼게 됩니다.

이 문제는 기존 Kubernetes Service나 일반적인 round-robin 로드 밸런서가 해결하기 어려운 영역입니다. 이들은 대체로 “어느 서버가 살아 있는가”, “어느 서버의 부하가 낮은가”를 기준으로 요청을 나눕니다. 하지만 LLM 추론에서는 한 가지 질문이 더 필요합니다.

이 요청의 맥락을 이미 가지고 있는 서버는 어디인가?

2026년 10월 공개된 llm-d 1.0은 바로 이 질문을 중심에 둡니다. llm-d는 vLLM이나 SGLang 같은 모델 실행 엔진을 대체하는 제품이라기보다, 여러 모델 서버와 GPU·TPU 풀을 하나의 지능적인 추론 시스템으로 묶는 Software Infra control plane입니다.

llm-d의 라우터는 단순히 빈 서버를 찾는 대신 다음 정보를 함께 고려합니다.

• 동일한 프롬프트 prefix를 보유한 KV 캐시 위치
• 같은 Agent 또는 사용자 세션의 이전 처리 위치
• 각 replica의 현재 부하
• 예상 응답 지연 시간
• 테넌트별 우선순위와 서비스 정책
• GPU·TPU 등 가속기 풀의 구성과 상태

llm-d의 캐시 인식 라우팅

Agent Turn 1 → Replica A
Agent Turn 2 → Replica A  ← 기존 KV 캐시 재사용
Agent Turn 3 → Replica A  ← 대화 맥락 유지

단, Replica A가 포화 상태라면
Agent Turn 3 → Replica B  ← 응답 실패 방지를 위해 재배치

중요한 점은 llm-d가 무조건 세션 고정만 고집하지 않는다는 것입니다. 캐시 재사용은 빠르지만, 특정 replica가 과부하 상태라면 오히려 전체 응답성이 나빠질 수 있습니다. 따라서 llm-d는 캐시 지역성(cache locality) 과 클러스터 전체의 부하 균형 사이에서 최적의 선택을 시도합니다.

이 변화는 LLM 인프라를 바라보는 관점 자체를 바꿉니다. 과거에는 “더 빠른 모델 서버를 띄우는 방법”이 중요했다면, 이제는 “클러스터 전체에서 이미 계산한 맥락을 어떻게 재사용하고, 어떤 요청을 어느 가속기로 보낼 것인가”가 핵심이 됩니다.

GPU가 바쁜데도 답변이 늦다면, GPU를 더 추가하기 전에 먼저 살펴봐야 할 것이 있습니다. 현재 요청이 가장 빠른 서버가 아니라, 가장 많은 맥락을 기억하는 서버로 가고 있는지입니다.

Software Infra: 요청을 보내는 곳부터 달라진다 — KV Cache를 아는 라우팅

가장 한가한 서버에 요청을 보내는 것이 항상 가장 빠를까요?

LLM 추론에서는 꼭 그렇지 않습니다. 특히 여러 차례 대화를 이어 가는 agent 환경에서는, 이전 대화의 문맥을 이미 처리해 둔 서버가 조금 더 바쁘더라도 훨씬 유리할 수 있습니다. 해당 서버의 GPU 메모리에는 이전 prompt를 처리하며 생성한 KV cache가 남아 있기 때문입니다.

기존 Kubernetes 환경의 일반적인 로드 밸런싱은 대개 다음처럼 동작합니다.

요청 1 → Replica A
요청 2 → Replica B
요청 3 → Replica C

이 방식은 서버 간 부하를 고르게 나누는 데는 효과적입니다. 하지만 요청 2가 요청 1과 같은 agent session의 후속 대화라면 문제가 생깁니다. Replica A에는 이미 필요한 context의 KV cache가 있는데도, Replica B는 이를 알지 못합니다. 결국 B는 긴 대화 이력을 다시 읽고 prompt를 다시 계산해야 합니다.

그 결과는 명확합니다.

• 첫 토큰이 나오기까지의 시간, 즉 TTFT(Time to First Token) 증가
• GPU 연산량과 메모리 사용량 증가
• 긴 context가 많은 환경에서 처리량 저하
• agent의 다음 작업이 늦어지며 전체 작업 흐름 지연

llm-d의 핵심은 이 지점에서 시작합니다. 이 플랫폼은 단순히 “현재 가장 덜 바쁜 replica”를 찾는 대신, 어느 replica에 어떤 prefix와 session context가 남아 있는지를 라우팅 판단에 반영합니다.

Agent Turn 1 → Replica A
Agent Turn 2 → Replica A  ← 기존 KV cache 재사용
Agent Turn 3 → Replica A  ← 대화 문맥의 연속성 유지

이 접근은 흔히 prefix-cache-aware routing 또는 session-aware routing이라고 불립니다. 라우터는 요청의 prefix, session 정보, cache 위치를 확인한 뒤 기존 cache를 가장 잘 활용할 수 있는 endpoint를 우선 선택합니다.

하지만 cache가 있다고 해서 무조건 같은 서버로 보내지는 않습니다. Replica A가 과도하게 포화된 상태라면, cache를 재사용하는 이점보다 대기열에서 지연되는 비용이 더 커질 수 있습니다. 따라서 llm-d의 라우팅은 다음 요소를 함께 비교합니다.

판단 요소	라우팅에서의 의미
Prefix cache 위치	기존 prompt 계산 결과를 재사용할 수 있는가
Session affinity	같은 agent의 이전 turn을 처리한 서버인가
현재 부하	요청 큐, GPU 포화도, 처리 중인 작업량은 어떤가
예상 latency	cache 재사용 이득과 대기 시간을 함께 고려할 때 어디가 빠른가
Tenant priority	premium, standard, batch 등 서비스 정책상 우선순위는 무엇인가
Accelerator topology	GPU·TPU 종류와 pool 특성에 적합한 요청인가

즉, llm-d는 “cache가 있는 서버”와 “가장 한가한 서버” 중 하나만 기계적으로 고르지 않습니다. cache locality로 얻는 계산 절감 효과와 현재 부하로 인한 대기 시간을 함께 계산해 더 나은 선택을 찾는 것이 핵심입니다.

이를 단순화하면 다음과 같은 흐름으로 이해할 수 있습니다.

새 요청 도착
   ↓
동일 prefix 또는 session의 KV cache 보유 replica 탐색
   ↓
후보 replica의 queue·부하·예상 latency 확인
   ↓
cache 재사용 이득과 대기 비용 비교
   ↓
가장 유리한 endpoint로 요청 전달

이 방식은 특히 긴 system prompt를 공유하는 서비스, 코드베이스 전체를 문맥으로 사용하는 coding agent, 수십 turn 이상 이어지는 업무 자동화 agent에서 효과가 큽니다. 매 요청마다 수만 token의 대화 이력을 다시 prefill하는 대신, 이미 계산된 상태를 최대한 가까운 곳에서 이어 쓸 수 있기 때문입니다.

물론 session affinity는 절대적인 규칙이 아닙니다. 특정 replica가 장애 상태이거나, 대기열이 길어지거나, 높은 우선순위 요청을 처리해야 한다면 llm-d는 affinity를 일부 포기하고 다른 replica로 요청을 이동시킬 수 있습니다. 이때는 cache hit보다 요청 실패 방지와 서비스 응답성을 우선합니다.

이러한 균형 감각이 기존 로드 밸런서와 llm-d의 차이입니다. 전통적인 Software Infra가 서버의 연결 가능 여부와 트래픽 분산에 집중했다면, llm-d는 LLM 요청 안에 담긴 문맥의 가치와 계산 상태의 위치까지 이해하려 합니다.

결국 추론 시스템에서 중요한 질문은 더 이상 “어느 서버가 비어 있는가?”만이 아닙니다.

“이 요청의 문맥을 이미 알고 있는 서버는 어디이며, 그 서버가 지금도 처리할 여유가 있는가?”

llm-d의 KV cache 인지형 라우팅은 바로 이 질문에 답하기 위해 설계된 분산 추론 제어 계층입니다.

Software Infra 관점에서 본 Prefill과 Decode의 분리

긴 질문을 읽는 일과 답변을 한 토큰씩 써 내려가는 일은 같은 종류의 작업이 아닙니다. 그런데도 많은 LLM 서비스는 지금까지 두 작업을 하나의 replica, 하나의 GPU 자원 전략 안에서 처리해 왔습니다.

이 방식은 단순하지만, 긴 context를 가진 agent 요청과 실시간 대화 요청이 함께 몰리는 순간 병목이 드러납니다. llm-d의 disaggregated serving은 이 문제를 해결하기 위해 추론 과정을 Prefill과 Decode로 나누고, 각 단계에 맞는 별도 pool을 운영합니다.

기존 방식

하나의 Replica
 ├─ Prompt 처리(Prefill)
 └─ Token 생성(Decode)
      ↓
  하나의 GPU 자원을 함께 사용

llm-d 분리 방식

Prefill Pool ─────▶ Decode Pool
  계산 집약적            메모리·지연시간 집약적

Prefill: 긴 입력을 읽고 KV Cache를 만드는 단계

Prefill은 사용자가 보낸 prompt 전체를 모델에 입력하는 과정입니다. 예를 들어 50,000-token짜리 문서, 코드 저장소 맥락, 이전 대화 기록을 처리해야 한다면 모델은 입력 token을 한 번에 분석하고 attention 연산을 수행해야 합니다.

이 단계의 특징은 다음과 같습니다.

• 긴 prompt일수록 계산량이 급격히 증가합니다.
• GPU의 높은 연산 처리량이 중요합니다.
• 대규모 batch 처리와 병렬화 효율이 큰 영향을 줍니다.
• 처리 결과로 이후 생성에 필요한 KV Cache가 만들어집니다.

문제는 긴 prompt의 prefill 작업이 들어올 때입니다. 같은 replica에서 이미 실시간 응답을 생성하고 있다면, 무거운 prefill이 GPU 자원을 점유하면서 진행 중인 대화의 응답 속도까지 떨어뜨릴 수 있습니다. 사용자는 답변이 멈춘 것처럼 느끼고, 서비스 운영자는 P95·P99 latency 악화를 경험하게 됩니다.

Decode: 한 토큰씩 응답을 생성하는 단계

Decode는 prefill 이후, 모델이 다음 token을 예측하고 생성하는 반복 과정입니다. “안녕하세요”라는 짧은 응답부터 수백 줄의 코드 생성까지, 출력 token 하나하나가 이 단계에서 만들어집니다.

Decode는 prefill과 자원 특성이 다릅니다.

• token을 순차적으로 생성하므로 낮은 지연시간이 중요합니다.
• 이미 생성된 KV Cache를 반복적으로 읽습니다.
• 순수 연산 성능보다 HBM 용량과 memory bandwidth의 영향이 큽니다.
• 사용자 경험은 첫 token 이후의 끊김 없는 생성 속도에 크게 좌우됩니다.

즉, prefill이 “대량의 문서를 빠르게 읽는 작업”이라면, decode는 “메모를 계속 참고하며 한 문장씩 작성하는 작업”에 가깝습니다. 둘을 같은 자원에 묶으면 서로의 성능 특성이 충돌할 수밖에 없습니다.

llm-d가 두 단계를 분리하는 방식

llm-d는 DisaggregatedSet을 통해 prefill pool과 decode pool을 하나의 논리적 배포 단위로 관리합니다. 운영자는 두 pool을 독립적으로 구성하고, 각 workload에 맞춰 scale 전략을 다르게 적용할 수 있습니다.

Client Request
      │
      ▼
llm-d Router
      │
      ├─ 긴 Prompt 처리 → Prefill Pool
      │                      │
      │                      └─ KV Cache 전달
      │
      └────────────────────▶ Decode Pool
                               │
                               ▼
                         Streaming Response

이 구조에서 router는 단순히 요청을 전달하는 역할에 머물지 않습니다. 요청의 session, prefix cache 위치, 현재 pool 부하, 예상 latency를 고려해 적절한 endpoint를 선택합니다. Prefill에서 생성된 KV Cache 역시 decode 단계에서 활용할 수 있도록 전달·배치 전략이 필요합니다.

이를 위해 Software Infra 계층에서는 GPU HBM뿐 아니라 host RAM, SSD, 외부 storage까지 포함하는 KV cache tiering 전략이 함께 중요해집니다. 단순히 서버를 두 개로 나누는 문제가 아니라, 계산과 상태를 분리하면서도 context locality를 유지하는 문제이기 때문입니다.

독립적인 확장이 만드는 운영상 이점

Prefill과 decode를 분리하면 트래픽 패턴에 따라 서로 다른 방식으로 확장할 수 있습니다.

상황	기존 단일 Replica 구조	llm-d 분리 구조
긴 문서·긴 context 요청 급증	전체 replica가 느려질 수 있음	Prefill pool 중심으로 확장
짧은 질의와 긴 응답 급증	GPU 자원 경쟁 발생	Decode pool 중심으로 확장
실시간 API와 batch 작업 혼재	실시간 요청이 밀릴 가능성	QoS 정책으로 pool·priority 분리
GPU 종류가 혼합됨	배포 구성이 복잡해짐	단계별 accelerator 전략 적용 가능
모델 업데이트	구성 요소별 호환성 관리 필요	coordinated rollout으로 전환 관리

예를 들어, 사내 coding agent가 대형 코드베이스를 반복적으로 읽는 환경에서는 prefill 부하가 매우 커질 수 있습니다. 반대로 고객 상담 챗봇처럼 짧은 입력 뒤에 긴 답변을 생성하는 서비스는 decode latency가 더 중요한 지표가 될 수 있습니다.

llm-d는 이런 차이를 하나의 평균적인 GPU utilization 수치로 뭉뚱그리지 않습니다. Prefill에는 계산 처리량 중심의 자원을, decode에는 메모리 대역폭과 응답 안정성 중심의 자원을 배치하는 방향을 제시합니다.

분리가 항상 정답은 아니다

다만 disaggregated serving은 모든 서비스에 필요한 구조는 아닙니다. Prefill pool과 decode pool 사이에서 KV Cache를 이동·공유해야 하므로 네트워크, storage, cache transfer 계층의 복잡성이 추가됩니다. pool별 autoscaling, 장애 처리, 버전 호환성까지 고려해야 합니다.

따라서 다음과 같은 환경에서 특히 효과를 기대할 수 있습니다.

• 긴 context를 사용하는 agent 서비스
• 대규모 multi-turn session
• interactive traffic과 batch inference가 공존하는 환경
• 수십~수백 대 이상의 GPU/TPU fleet
• prefill과 decode 부하 편차가 큰 서비스
• P95·P99 응답 지연을 엄격하게 관리해야 하는 API

반대로 단일 모델, 소수 replica, 짧고 안정적인 요청 위주의 서비스라면 일반적인 vLLM 배포가 더 단순하고 효율적일 수 있습니다.

결국 llm-d의 prefill/decode 분리는 “GPU를 더 많이 쓰는” 접근이 아닙니다. 서로 다른 성격의 추론 작업을 구분해 배치함으로써, 같은 accelerator fleet에서 더 예측 가능한 latency와 더 높은 자원 효율을 얻으려는 Software Infra 전략입니다.

GPU를 나눠 쓰는 시대, 우선순위와 공정성도 스케줄링한다 | Software Infra

프리미엄 API, 코딩 agent, 배치 추론, RL rollout이 하나의 GPU fleet을 함께 사용한다면 어떤 요청을 먼저 처리해야 할까요?

단순한 FIFO(First In, First Out) 큐에서는 먼저 들어온 요청이 우선입니다. 문제는 한 tenant가 갑자기 대량의 요청을 보내면 발생합니다. 낮은 우선순위의 배치 작업이 GPU 큐를 점유하고, 그 뒤에 들어온 실시간 사용자 요청까지 지연될 수 있습니다. 결국 한 팀의 burst가 전체 서비스의 TTFT와 P95 latency를 악화시키는 noisy neighbor 문제로 번집니다.

llm-d 1.0은 이 문제를 단순한 GPU 자원 배분이 아니라, 추론 요청 자체를 정책적으로 스케줄링하는 Software Infra 문제로 다룹니다.

같은 GPU라도 요청의 중요도는 다르다

하나의 accelerator cluster에는 성격이 전혀 다른 workload가 공존할 수 있습니다.

트래픽 유형	일반적인 요구사항	우선순위 예시
Premium API	낮은 TTFT, 엄격한 SLO	높음
일반 사용자 요청	균형 잡힌 응답 속도	보통
Coding agent	다중 turn, burst 발생 가능	중간~높음
Batch inference	높은 처리량, 지연 허용 가능	낮음
RL rollout	유휴 자원 활용, 대량 실행	낮음

FIFO만으로는 이 차이를 표현할 수 없습니다. 예를 들어 RL rollout이 수천 건의 긴 요청을 먼저 넣었다고 해서, 결제 고객의 실시간 API 요청까지 뒤로 밀려서는 안 됩니다.

llm-d는 요청에 단순한 순번 대신 다음과 같은 flow key를 부여해 정책을 적용합니다.

• Fairness ID: 어떤 tenant 또는 사용자 그룹의 요청인지 식별
• Priority Band: 서비스 등급에 따른 우선순위 구분
• Workload 또는 Program ID: 요청이 어느 애플리케이션·업무 흐름에 속하는지 식별

이 정보는 router가 “다음 요청을 어느 replica로 보낼지”뿐 아니라 “지금 이 요청을 backend로 흘려보낼지”까지 판단하는 기준이 됩니다.

우선순위만 높이면 공정하지 않다

높은 우선순위만 강조하면 다른 문제가 생깁니다. Premium traffic이 지속적으로 몰리는 상황에서는 일반 tenant가 사실상 처리 기회를 얻지 못할 수 있습니다. 반대로 모든 요청을 완전히 동일하게 취급하면 중요한 실시간 서비스의 SLO를 보장하기 어렵습니다.

llm-d의 flow control은 이 두 목표를 함께 다룹니다.

1. 우선순위가 높은 요청을 먼저 처리합니다.
2. 같은 우선순위 안에서는 tenant 간 공정성을 적용합니다.
3. backend queue가 과도하게 쌓이기 전에 router 단계에서 요청 흐름을 제어합니다.
4. 용량이 부족하면 낮은 우선순위 workload를 지연하거나 일부 요청을 제한합니다.

즉, “가장 중요한 요청을 먼저” 처리하되, 동일한 등급 안에서는 특정 tenant가 GPU를 독점하지 않도록 설계합니다. 이는 Kubernetes에서 CPU·메모리 quota를 설정하는 것과 비슷해 보이지만, 실제로는 token 생성 속도, KV cache 점유, 예상 latency 같은 LLM 추론 특성을 고려해야 한다는 점에서 더 복잡합니다.

과부하에서는 모두를 기다리게 하지 않는다

LLM inference에서 가장 위험한 상황은 요청이 처리 가능한 속도보다 빠르게 유입되는 경우입니다. 큐가 길어질수록 사용자는 응답을 오래 기다리고, timeout 이후 재시도를 시작합니다. 재시도는 다시 부하를 키우며 장애를 증폭시킬 수 있습니다.

llm-d는 이런 상황에서 probabilistic admission control을 활용할 수 있습니다. 모든 요청을 무조건 backend에 전달하는 대신, 시스템 포화 수준에 따라 일부 낮은 우선순위 요청을 완만하게 지연하거나 제한하는 방식입니다.

낮은 부하
요청 → Router → Backend queue → GPU

높은 부하
Premium 요청 → 우선 처리
Standard 요청 → 공정성 정책에 따라 대기
Batch/RL 요청 → 지연, 제한 또는 shedding

이 접근의 목적은 일부 요청을 희생해서라도 전체 시스템이 무너지는 것을 막는 데 있습니다. 특히 실시간 API와 배치 작업이 같은 GPU pool을 공유하는 조직이라면, 이는 단순한 성능 최적화가 아니라 서비스 연속성을 위한 운영 정책입니다.

정책은 기본값이 아니라 운영자가 설계해야 한다

llm-d의 고급 QoS는 자동으로 모든 문제를 해결하지 않습니다. 기본 동작은 기존 환경과의 호환성을 위해 비교적 first-come-first-served 방식에 가깝고, 실제 priority·fairness·quota 정책은 운영자가 정의해야 합니다.

도입 전에는 최소한 다음 질문에 답할 수 있어야 합니다.

• Premium 고객의 P95 TTFT 목표는 얼마인가?
• batch inference는 몇 분까지 지연되어도 되는가?
• tenant별 최대 동시 요청 수와 token budget은 얼마인가?
• agent workload가 burst를 일으킬 때 어느 수준까지 허용할 것인가?
• GPU가 포화될 때 어떤 요청을 먼저 늦추거나 거절할 것인가?

결국 llm-d가 제공하는 것은 “공정한 답” 하나가 아니라, 조직의 비즈니스 우선순위를 추론 인프라 정책으로 구현할 수 있는 제어 계층입니다.

GPU를 공동 자원으로 쓰는 시대에는 utilization만 높다고 좋은 시스템이 아닙니다. 중요한 요청이 제때 처리되고, 특정 tenant의 급격한 트래픽이 다른 서비스까지 멈추게 하지 않으며, 남는 자원은 배치·RL 작업이 효율적으로 활용해야 합니다. llm-d의 multi-tenant QoS는 바로 이 균형을 Software Infra 수준에서 다루기 위한 핵심 기능입니다.

Software Infra 관점에서 본 추론 운영체제의 가능성과 도입 전 확인할 것

벤치마크에서 throughput이 몇 배 향상됐다는 발표만으로 도입을 결정해도 될까요? 답은 신중해야 합니다. llm-d의 핵심 가치는 모델 서버 하나의 속도를 높이는 데 있지 않습니다. GPU·TPU·스토리지·라우터·큐·캐시를 묶어, 클러스터 전체를 하나의 추론 시스템처럼 운영하게 만드는 데 있습니다.

즉, llm-d는 단순한 serving 도구가 아니라 LLM workload를 위한 Software Infra 운영 계층에 가깝습니다. 하지만 더 많은 제어권은 더 많은 운영 책임을 의미합니다.

Software Infra가 얻는 변화: 서버 운영에서 추론 시스템 운영으로

기존에는 vLLM 또는 SGLang replica를 늘리고, Kubernetes Service로 트래픽을 분산하는 방식이 일반적이었습니다. 이 구조는 단순하고 빠르게 시작할 수 있지만, agent workload와 긴 context가 늘어날수록 한계가 드러납니다.

llm-d는 다음 질문에 인프라 차원에서 답하려고 합니다.

• 이 요청은 어느 replica에 보내야 KV cache를 재사용할 수 있는가?
• 긴 prompt를 처리하는 prefill 작업이 실시간 decode 응답을 방해하고 있지 않은가?
• Premium tenant의 요청이 batch inference에 밀리지 않도록 어떻게 보장할 것인가?
• GPU HBM이 부족할 때 KV cache를 어디까지 이동시킬 수 있는가?
• 같은 agent session을 계속 같은 실행 위치로 연결할 수 있는가?

이 관점에서 llm-d는 Kubernetes 위에 구축되는 일종의 추론 운영체제입니다. CPU 사용률이나 pod 수만 보는 것이 아니라, prefix-cache hit rate, queue saturation, TTFT, session locality, tenant priority까지 운영 신호로 활용합니다.

특히 여러 팀이 하나의 GPU fleet을 공유하는 환경이라면 효과가 커질 수 있습니다. 단순한 round-robin 방식으로는 고가의 accelerator를 충분히 활용하기 어렵기 때문입니다.

Software Infra 도입 효과를 판단할 핵심 지표

llm-d의 성능은 “tokens/sec가 증가했다”는 단일 수치로 평가하면 부족합니다. 실제 도입 판단에서는 사용자 경험, 비용, 안정성을 함께 측정해야 합니다.

검증 항목	확인해야 할 질문
TTFT	첫 token이 생성되기까지의 시간이 실제로 줄었는가?
P95/P99 latency	평균이 아니라 혼잡 상황의 지연 시간이 개선됐는가?
Prefix-cache hit rate	session affinity와 prefix-aware routing이 실제 cache 재사용으로 이어지는가?
Inter-token latency	생성 중 token 간 지연이 안정적인가?
GPU utilization	GPU 사용률이 높아졌지만 latency 희생은 없는가?
GPU-hour당 비용	처리량 증가가 실제 비용 절감으로 연결되는가?
Queue delay	router와 backend queue에서 요청이 얼마나 오래 대기하는가?
Failover 시간	router 또는 worker 장애 시 요청 손실과 복구 시간이 허용 범위인가?
Cache eviction 빈도	HBM 부족으로 인한 cache eviction storm이 줄었는가?

공식 발표의 성능 수치는 참고할 만하지만, 모델 크기·prompt 길이·GPU 종류·스토리지 속도·트래픽 패턴에 따라 결과가 크게 달라집니다. 예를 들어 긴 multi-turn agent workload에서는 cache-aware routing의 효과가 클 수 있지만, 짧고 독립적인 질의가 대부분이라면 복잡한 routing layer의 이점이 제한적일 수 있습니다.

Software Infra 복잡성: 얻는 제어권만큼 늘어나는 책임

llm-d를 도입하면 운영 대상은 모델 서버에서 분산 추론 플랫폼으로 확장됩니다. 일반적인 Kubernetes + vLLM 구성에 비해 관리해야 할 요소가 많아집니다.

• Router와 endpoint picker의 고가용성
• Prefix cache index 및 session affinity 정책
• Prefill·decode pool의 용량 계획
• HBM, CPU RAM, SSD, 외부 스토리지 간 KV cache tiering
• tenant별 priority, fairness, quota 정책
• KEDA, HPA, Kueue 등 autoscaling·queue 연동
• accelerator topology와 네트워크 대역폭 설계
• Prometheus, OpenTelemetry 기반 관측성
• rolling upgrade 시 prefill·decode 간 버전 호환성

특히 prefill/decode disaggregation은 강력하지만, 모든 조직에 필요한 구성은 아닙니다. prefill pool과 decode pool을 분리하면 각 단계에 맞춰 독립 확장이 가능하지만, pool 간 KV cache 전달과 네트워크 지연, 장애 처리, 버전 정합성까지 고려해야 합니다.

따라서 llm-d는 “설치하면 자동으로 비용이 절감되는 제품”이라기보다, 운영 성숙도가 있는 팀이 성능과 비용을 세밀하게 최적화할 수 있는 Software Infra입니다.

Software Infra 보안과 거버넌스에서 놓치기 쉬운 지점

KV cache에는 사용자의 prompt, 대화 이력, system prompt 등 민감한 문맥이 남을 수 있습니다. cache tiering을 적용해 CPU RAM, SSD, 외부 스토리지까지 데이터를 이동시키는 환경에서는 보안 설계가 더 중요해집니다.

도입 전에는 최소한 다음 항목을 점검해야 합니다.

• KV cache의 저장 위치와 암호화 방식
• tenant 간 cache 격리 정책
• cache retention 기간과 명시적 삭제 보장
• 리전 간 데이터 이동 여부
• 외부 스토리지 사용 시 접근 제어와 감사 로그
• 개인정보, 금융정보, 의료정보에 대한 데이터 residency 요구사항
• 장애·재시작·scale-down 상황에서 cache 데이터가 처리되는 방식

성능을 위해 cache 재사용률을 높이는 전략은 데이터 최소화 원칙과 충돌할 수 있습니다. 따라서 플랫폼 팀, 보안 팀, 데이터 거버넌스 담당자가 함께 cache lifecycle 정책을 설계해야 합니다.

Software Infra 도입에 적합한 환경과 신중해야 할 환경

llm-d는 다음과 같은 환경에서 우선 검토할 가치가 큽니다.

• 여러 tenant가 대규모 GPU 또는 TPU fleet을 공유하는 경우
• coding agent, research agent, customer-support agent처럼 multi-turn 요청이 많은 경우
• 긴 context와 반복되는 system prompt가 많은 경우
• vLLM 또는 SGLang을 이미 운영 중인 경우
• Premium·Standard·Batch workload의 SLO를 분리해야 하는 경우
• GPU 비용과 cache miss로 인한 재계산 비용이 큰 경우
• prefill과 decode를 별도 accelerator pool로 최적화할 필요가 있는 경우

반대로 단일 모델과 소수의 replica만 운영하고, 요청도 짧으며 session 재사용이 적다면 일반 Kubernetes Service와 vLLM 조합이 더 나을 수 있습니다. 이 경우 llm-d의 제어 기능은 필요 이상으로 복잡한 운영 계층이 될 가능성이 있습니다.

Software Infra 도입 전 권장하는 검증 방식

가장 현실적인 접근은 전체 전환이 아니라 제한된 workload를 대상으로 한 단계적 검증입니다.

먼저 기존 serving 환경의 기준선을 확보해야 합니다. TTFT, P95 latency, GPU utilization, cache hit rate, GPU-hour당 비용을 측정한 뒤, 동일 모델과 동일 트래픽을 llm-d 환경에서 비교합니다.

그다음에는 실제 운영 조건을 재현해야 합니다. 정상 상태의 평균 처리량뿐 아니라 다음 상황을 반드시 포함하는 것이 좋습니다.

• 긴 prompt가 동시에 유입되는 상황
• 특정 tenant의 burst traffic
• cache가 가득 차는 상황
• prefill pool 또는 decode pool 일부 장애
• router failover
• rolling upgrade
• 낮은 priority batch 작업과 고우선 interactive traffic의 동시 처리

결국 llm-d의 가치는 최고 throughput 숫자보다, 혼잡과 장애 상황에서도 중요한 요청의 latency와 비용을 얼마나 예측 가능하게 통제하는지에 있습니다. Software Infra의 역할은 GPU를 더 많이 쓰게 만드는 것이 아니라, 제한된 GPU 자원을 더 일관되고 정책적으로 사용하게 만드는 것입니다.