LLM 서빙 prefill·decode 분리 (2) - 오케스트레이션 레이어

들어가며

1편에서는 prefill과 decode를 왜 분리해야 하는지 살펴봤습니다. 둘을 분리하면 새 prefill 요청 때문에 decode가 멈추는 일을 줄일 수 있습니다. 대신 한 가지 일이 새로 필요합니다. prefill 워커가 만든 KV 캐시를 decode 워커로 옮겨야 합니다.

분리된 워커는 따로 실행하는 것만으로 충분하지 않습니다. 요청을 어느 워커로 보낼지 정해야 합니다. prefill 워커와 decode 워커의 수를 따로 조절해야 합니다. KV 캐시도 워커 사이로 옮겨야 합니다. 이 일을 맡는 층을 오케스트레이션 레이어라고 합니다.

이 글에서는 대표적인 오케스트레이션 레이어 두 가지를 비교합니다. 하나는 NVIDIA가 만든 Dynamo입니다. 다른 하나는 Kubernetes 기반의 llm-d입니다.

 

1. 오케스트레이션 레이어가 하는 일

prefill과 decode를 분리하면 관리해야 할 일이 세 가지로 늘어납니다.

첫째는 라우팅입니다. 들어온 요청을 어느 워커로 보낼지 정해야 합니다.

둘째는 스케일링입니다. prefill 워커와 decode 워커를 각각 몇 개씩 둘지 정해야 합니다. 입력이 긴 요청이 많으면 prefill 쪽이 더 바빠집니다. 출력이 긴 요청이 많으면 decode 쪽이 더 바빠집니다. 그래서 두 워커의 비율은 계속 바뀝니다.

셋째는 전송입니다. prefill 워커가 만든 KV 캐시를 decode 워커로 옮겨야 합니다. 이 전송이 느리면 분리로 얻은 이득이 사라집니다.

오케스트레이션 레이어는 이 세 가지를 자동으로 처리합니다. Dynamo와 llm-d는 같은 문제를 서로 다른 계층에서 해결합니다.

 

2. NVIDIA Dynamo

Dynamo는 NVIDIA가 만든 추론 전용 프레임워크입니다. prefill 워커와 decode 워커를 나누고 요청 라우팅과 KV 캐시 전송까지 함께 다룹니다. 아래 그림이 전체 구조입니다.

 

2-1. prefill 워커와 decode 워커를 나눈다

Dynamo는 prefill 워커와 decode 워커를 서로 다른 서비스로 둡니다. prefill 워커는 프롬프트 처리를 맡습니다. decode 워커는 토큰 생성을 맡습니다. 두 워커는 따로 늘리고 줄일 수 있습니다.

 

2-2. KV-aware Router

KV-aware Router는 요청을 알맞은 워커로 보내는 부분입니다. 보통의 로드밸런서는 부하가 낮은 워커를 고릅니다. KV-aware Router는 한 가지를 더 봅니다. 어느 decode 워커가 이미 관련 KV 캐시를 들고 있는지 확인합니다. 그리고 가능한 한 그 워커로 요청을 보냅니다. 이렇게 하면 같은 KV 캐시를 다시 만들지 않아도 됩니다.

 

2-3. GPU Planner

GPU Planner는 prefill 워커와 decode 워커의 비율을 정하는 부분입니다. GPU 사용 패턴을 계속 봅니다. 입력이 긴 요청이 많으면 prefill 워커를 늘립니다. 출력이 긴 요청이 많으면 decode 워커를 늘립니다.

 

2-4. NIXL

NIXL은 KV 캐시를 워커 사이로 옮기는 전송 라이브러리입니다. 정식 이름은 NVIDIA Inference Xfer Library입니다.

KV 캐시는 크기가 큽니다. 그래서 전송이 느리면 분리로 얻은 이득이 줄어듭니다. 그런데 워커를 잇는 연결은 환경마다 다릅니다. 같은 서버 안의 GPU는 NVLink로 연결될 수 있습니다. 다른 서버의 GPU는 InfiniBand로 연결될 수 있습니다. 그 밖에 PCIe나 SSD도 경로에 들어갈 수 있습니다.

NIXL은 이렇게 다른 연결을 하나의 방식으로 다룹니다. 그래서 상위 코드는 연결 종류를 직접 다루지 않고 KV 캐시 전송을 요청할 수 있습니다.

실제 추론은 Dynamo가 직접 하지 않습니다. TensorRT-LLM과 vLLM 그리고 SGLang 같은 엔진을 백엔드로 씁니다.

 

3. llm-d

llm-d는 Kubernetes 위에서 동작하는 추론 플랫폼입니다. 목표는 여러 종류의 GPU가 섞여 있고 여러 사용자가 함께 쓰는 클라우드 환경에서 prefill과 decode 분리를 운영하는 것입니다. 아래 그림이 전체 구조입니다.

3-1. Inference Gateway

Inference Gateway는 요청이 가장 먼저 도착하는 입구입니다. Kubernetes의 표준 Gateway를 추론에 맞게 확장한 것입니다.

보통의 Gateway는 HTTP 경로나 헤더를 보고 라우팅합니다. Inference Gateway는 여기에 추론 정보를 더 봅니다. 요청이 어떤 모델을 부르는지 확인합니다. 관련 KV 캐시가 어디에 있는지도 확인합니다.

 

3-2. Inference Scheduler

Inference Scheduler는 요청을 어느 pod로 보낼지 정하는 부분입니다. 먼저 각 pod의 상태를 모읍니다. 다음으로 각 pod에 점수를 매깁니다. 마지막으로 부적합한 pod를 걸러냅니다.

이 과정에서 워커의 부하를 봅니다. 관련 KV 캐시가 어디에 있는지도 봅니다. 요청이 prefill인지 decode인지도 함께 고려합니다.

 

3-3. LeaderWorkerSet

LeaderWorkerSet은 여러 pod를 하나의 단위로 다루는 도구입니다. 큰 모델은 GPU 하나에 모두 올라가지 않습니다. 그래서 여러 노드에 나눠서 실행해야 합니다. 이때 여러 pod가 하나의 단위로 함께 동작합니다.

llm-d는 prefill 그룹과 decode 그룹을 각각 하나의 LeaderWorkerSet으로 관리합니다.

 

3-4. Variant Autoscaler

Variant Autoscaler는 prefill 워커와 decode 워커의 수를 자동으로 조절하는 부분입니다. 판단 기준이 일반적인 오토스케일러와 다릅니다. CPU나 메모리 사용량만 보지 않습니다. KV 캐시 사용률과 큐 길이를 봅니다. 앞에서 본 TTFT와 TPOT도 함께 봅니다.

 

3-5. 이기종 GPU를 섞어 쓴다

llm-d는 한 클러스터에 여러 종류의 가속기를 섞어 둘 수 있습니다. 예를 들어 NVIDIA H100과 Google TPU와 AMD MI300X를 함께 쓸 수 있습니다. prefill은 연산 성능이 강한 장비에 배치할 수 있습니다. decode는 메모리 대역폭이 큰 장비에 배치할 수 있습니다.

 

4. 둘은 무엇이 다른가

Dynamo와 llm-d는 같은 일을 합니다. 둘 다 prefill 워커와 decode 워커를 나눕니다. 둘 다 KV 캐시 위치를 보고 라우팅합니다. 둘 다 두 워커를 따로 스케일링합니다.

차이는 기반 계층입니다. Dynamo는 추론 전용 프레임워크입니다. NVIDIA 하드웨어에서 높은 성능을 내는 데 집중합니다. llm-d는 Kubernetes 위에 올라갑니다. 일반적인 클라우드 운영 방식과 잘 맞게 만드는 데 집중합니다.

 

주도	NVIDIA	Red Hat·Google·IBM
기반	추론 전용 프레임워크	Kubernetes 네이티브 플랫폼
설정 방식	프레임워크 구성	Kubernetes manifest
강점	NVIDIA 하드웨어 최적화·성능	클라우드 운영·멀티테넌트
잘 맞는 환경	대규모 NVIDIA GPU 클러스터	여러 GPU가 섞인 일반 클라우드

 

정리

오케스트레이션 레이어는 분리된 워커를 관리합니다. 요청을 알맞은 워커로 보냅니다. 워커 수를 워크로드에 맞춰 조절합니다. KV 캐시를 워커 사이로 옮깁니다.

Dynamo와 llm-d는 이 일을 서로 다른 방식으로 해결합니다. Dynamo는 NVIDIA 하드웨어 성능에 집중합니다. llm-d는 Kubernetes 운영에 집중합니다. 두 방식 모두 prefill과 decode 분리를 전제로 설계되어 있습니다.

이 레이어 아래에는 또 다른 층이 있습니다. KV 캐시를 어디에 저장하고 어떻게 여러 워커가 나눠 쓰는지를 다루는 스토리지 레이어입니다. LMCache와 Mooncake가 대표적입니다. 이 주제는 다음 기회에 따로 다루겠습니다.

 

 

출처

• Hao AI Lab, "Disaggregated Inference: 18 Months Later" — https://haoailab.com/blogs/distserve-retro/
• NVIDIA Dynamo — https://github.com/ai-dynamo/dynamo · docs
• llm-d — https://llm-d.ai/