TEN
|
AI 인프라

Disaggregated Inference란? LLM 추론 GPU를 분리해 운영하는 이유

2026년 7월 16일

Disaggregated Inference란? LLM 추론 GPU를 분리해 운영하는 이유

같은 GPU에서 처리하던 LLM 추론을 왜 굳이 여러 GPU로 나눠야 할까요?

LLM 추론 성능이 기대만큼 나오지 않을 때, 문제는 단순히 GPU가 부족해서가 아닐 수 있습니다. 성격이 전혀 다른 두 작업을 하나의 GPU에서 동시에 처리하고 있다는 점이 병목의 원인일 수 있습니다. 이 문제를 해결하기 위해 등장한 구조가 Disaggregated Inference, 즉 분리형 추론입니다.

Disaggregated Inference는 LLM 추론의 Prefill과 Decode 단계를 서로 다른 GPU 또는 GPU 풀에서 처리하는 아키텍처입니다. NVIDIA Dynamo, llm-d, SGLang, LMCache, vLLM 연동 환경, AWS SageMaker HyperPod 등 주요 LLM 서빙 기술과 클라우드 환경으로 빠르게 확산되고 있습니다.


LLM 추론은 Prefill과 Decode로 나뉩니다

Disaggregated Inference를 이해하려면 먼저 LLM 추론이 성격이 다른 두 단계로 구성된다는 점을 알아야 합니다.

구분

Prefill

Decode

주요 역할

입력 프롬프트 전체 처리

출력 토큰 순차 생성

처리 방식

다수의 입력 토큰을 병렬 연산

토큰을 하나씩 자기회귀적으로 생성

주요 결과

첫 번째 토큰과 KV 캐시 생성

KV 캐시를 활용한 후속 토큰 생성

주요 병목

연산 처리량

메모리 대역폭과 용량

핵심 지표

TTFT

TPOT · 토큰 간 지연

Prefill: 입력을 처리하는 단계

Prefill은 사용자가 입력한 프롬프트 전체를 처리해 첫 번째 토큰과 KV 캐시(Key-Value Cache)​를 만드는 단계입니다.

  • KV 캐시: LLM이 이전 토큰을 처리하면서 계산한 정보를 임시로 저장하는 메모리로, 다음 토큰을 생성할 때 같은 계산을 반복하지 않도록 해 추론 속도를 높입니다.

긴 문서나 대규모 컨텍스트를 한꺼번에 연산해야 하므로, Prefill은 높은 연산 처리량이 필요한 연산 집약적(compute-bound) 작업에 가깝습니다. Prefill 성능은 질문을 입력한 뒤 첫 응답이 나오기까지 걸리는 시간인 TTFT(Time to First Token)​에 영향을 줍니다.

Decode: 답변을 이어서 생성하는 단계

Decode는 Prefill에서 생성한 KV 캐시를 활용해 출력 토큰을 하나씩 생성하는 단계입니다. 토큰을 생성할 때마다 모델 가중치와 KV 캐시를 반복적으로 읽기 때문에 GPU 메모리 대역폭과 접근 속도가 중요합니다. 일반적으로 메모리 대역폭 집약적(memory-bandwidth-bound) 작업으로 분류됩니다. Decode 성능은 답변이 얼마나 빠르고 매끄럽게 이어지는지를 나타내는 TPOT(Time per Output Token)​에 영향을 줍니다.

정리하면 Prefill은 “답변이 얼마나 빨리 시작되는가”를, Decode는 “답변이 얼마나 빠르게 이어지는가”를 결정합니다.


Prefill과 Decode를 왜 분리할까요?

통합형과 분리형 추론 구조 비교도. 통합형은 한 GPU가 Prefill과 Decode를 함께 처리해 상호 간섭이 발생하고, 분리형은 두 단계를 별도 GPU 풀로 나눠 간섭을 없애고 단계별로 독립 확장·최적화한다.

기존 통합형 추론 구조에서는 하나의 GPU 워커가 Prefill과 Decode를 모두 처리합니다.

  • GPU 워커: 모델을 실행하고 실제 추론 요청을 처리하는 GPU 단위입니다. 같은 역할을 수행하는 여러 GPU 워커를 묶은 구성을 GPU 풀이라고 합니다.

통합형 구조는 구성이 단순하지만, 성격이 다른 두 작업이 같은 GPU 자원을 두고 경쟁하면서 비효율이 발생합니다. 바로 이것이 두 단계를 분리하는 이유입니다.

Prefill과 Decode를 분리하면 다음과 같은 이점이 생깁니다.

1. 작업 간 상호 간섭을 줄일 수 있습니다

Decode가 토큰을 생성하는 도중 긴 프롬프트의 Prefill 요청이 들어오면, Prefill 연산이 GPU 자원을 점유하면서 진행 중이던 Decode가 지연될 수 있습니다. 사용자 입장에서는 답변이 시작된 뒤 토큰 생성 속도가 갑자기 느려지거나 끊기는 현상으로 나타납니다.

Prefill과 Decode를 서로 다른 GPU 풀로 분리하면 이러한 간섭을 줄일 수 있습니다. Prefill 풀은 TTFT를 중심으로, Decode 풀은 TPOT를 중심으로 각각 최적화할 수 있어 응답 속도를 보다 안정적으로 유지할 수 있습니다.

2. 병목이 발생한 단계만 확장할 수 있습니다

Prefill은 높은 연산 처리량이 중요하고, Decode는 메모리 대역폭과 용량이 중요합니다. 하지만 통합형 구조에서는 실제 병목이 어느 단계에서 발생했는지와 관계없이 동일한 GPU 워커를 함께 늘려야 합니다. 이 과정에서 필요 이상의 GPU 비용이 발생할 수 있습니다.

분리형 구조에서는 입력 토큰이 증가하면 Prefill 워커를, 동시 사용자와 출력 토큰이 증가하면 Decode 워커를 확장할 수 있습니다. 전체 GPU 구성을 동일하게 늘리는 대신 실제 부하가 발생한 단계에만 자원을 추가하는 방식입니다.

3. 단계별 하드웨어 전략을 적용할 수 있습니다

Prefill과 Decode를 분리하면 각 단계의 특성에 맞는 GPU와 병렬화 전략을 적용할 수 있습니다. Prefill에는 높은 연산 처리량을 제공하는 GPU를, Decode에는 높은 메모리 대역폭과 충분한 메모리 용량을 갖춘 GPU를 배치하는 이기종 구성도 검토할 수 있습니다.

즉 서로 다른 작업을 하나의 GPU 구성에 맞추는 대신, 각 작업에 적합한 자원을 배치해 GPU 활용률과 비용 효율을 높일 수 있습니다.


Disaggregated Inference는 어떻게 동작할까요?

LLM 분리형 추론의 KV 캐시 전송 흐름도. 사용자 프롬프트가 Prefill 워커(연산 집약)에서 첫 토큰과 KV 캐시를 생성한 뒤, 고속 인터커넥트로 Decode 워커(메모리 집약)에 전송되어 토큰을 순차 생성하고 응답을 스트리밍한다.

분리형 추론의 기본 흐름은 다음과 같습니다.

  1. Prefill 워커가 입력 프롬프트를 처리합니다.

  2. 첫 번째 토큰과 KV 캐시를 생성합니다.

  3. KV 캐시를 Decode 워커로 전달합니다.

  4. Decode 워커가 후속 토큰을 생성합니다.

이 구조에서는 Prefill과 Decode 자원을 각각 독립적으로 배치하고 확장할 수 있습니다.

다만 두 단계가 완전히 독립적인 것은 아닙니다. Decode를 시작하려면 Prefill에서 생성된 KV 캐시가 필요하기 때문입니다.

따라서 분리형 추론의 성능은 GPU를 나누는 것뿐 아니라, KV 캐시를 얼마나 빠르게 전달하느냐에 따라 달라집니다. 멀티노드 환경에서는 InfiniBand, RoCE, EFA와 같은 고속 네트워크와 RDMA, GPUDirect RDMA 등이 활용됩니다.

RDMA: CPU의 개입을 줄이고 서로 다른 서버의 메모리 사이에서 데이터를 직접 전송하는 기술입니다. GPUDirect RDMA는 GPU 메모리 간 데이터를 직접 전송해 지연을 줄이는 방식입니다.


어떤 워크로드에 적합할까요?

Disaggregated Inference는 다음과 같이 입력이 길거나 동시 요청이 많고, 지연 시간의 일관성이 중요한 환경에서 효과가 커질 수 있습니다.

  • 대규모 문서 분석과 장문 RAG

  • 긴 코드베이스를 다루는 코딩 에이전트

  • 실시간 스트리밍이 필요한 AI 챗봇

  • 동시 사용자가 많은 LLM 추론 API

  • 여러 차례 LLM을 호출하는 멀티턴·에이전틱 AI

문서 분석이나 장문 RAG는 입력 토큰이 많아 Prefill 부하가 커질 수 있습니다. 반면 추론형 모델이나 AI 에이전트는 긴 출력을 생성하고 LLM 호출을 반복하기 때문에 Decode 부하가 커질 수 있습니다.

이처럼 입력과 출력의 비중이 워크로드마다 다르기 때문에, Prefill과 Decode 자원을 독립적으로 확장할 수 있는 구조가 유리할 수 있습니다.


분리형 추론, 도입 전 확인해야 할 두 가지

Disaggregated Inference가 모든 환경에서 통합형 추론보다 효율적인 것은 아닙니다.

요청량이 적거나 입력과 출력이 짧은 서비스에서는 GPU 풀을 분리하고 KV 캐시를 전달하는 비용이 더 클 수 있습니다. 또한 Prefill과 Decode 워커가 각각 모델 가중치를 보유해야 하므로, GPU 규모가 작은 환경에서는 메모리 효율이 떨어질 수 있습니다.

따라서 모델과 트래픽 특성, TTFT·TPOT 목표, GPU 규모를 기준으로 도입 여부를 판단해야 합니다.

1. KV 캐시를 충분히 빠르게 전송할 수 있는가

컨텍스트가 길고 모델 규모가 클수록 전달해야 하는 KV 캐시도 커집니다. 네트워크가 느리거나 혼잡하면 KV 캐시 전송 시간이 TTFT를 늘리면서 분리의 이점이 사라질 수 있습니다. GPU 성능뿐 아니라 네트워크 대역폭과 전송 방식까지 함께 검토해야 합니다.

2. Prefill과 Decode 자원 비율을 조정할 수 있는가

Prefill과 Decode의 적정 GPU 비율은 고정되어 있지 않습니다. 입출력 토큰 수, 동시 요청 수, 모델 종류와 서비스 시간대에 따라 필요한 자원이 달라집니다. 한쪽 워커가 부족하면 요청이 대기하고, 반대로 지나치게 많이 배치하면 GPU가 유휴 상태로 남습니다. 따라서 TTFT와 TPOT, 요청 대기열, GPU 사용률을 함께 모니터링하고 자원 비율을 조정해야 합니다.


결론: 분리의 핵심은 GPU가 아니라 운영입니다

Disaggregated Inference는 성격이 다른 Prefill과 Decode를 각각 적합한 GPU 자원에서 처리하는 구조입니다. 이를 통해 작업 간 간섭을 줄이고, 실제 병목에 따라 자원을 독립적으로 확장할 수 있습니다.

하지만 GPU를 나누는 것만으로는 충분하지 않습니다. Prefill과 Decode 풀을 얼마나 배치할지, KV 캐시를 어떤 경로로 전달할지, 요청을 어느 GPU로 보낼지, 트래픽 변화에 따라 자원을 어떻게 조정할지를 함께 관리해야 실제 성능과 비용 효율로 이어집니다. [6]

결국 중요한 것은 나뉜 GPU와 워크로드를 하나의 서비스로 안정적으로 운영하는 능력입니다. GPU 자원을 워크로드에 맞게 할당하고, 사용 현황과 성능을 실시간으로 추적하며, 여러 AI 워크로드를 안정적으로 운영하는 것. AIPub이 집중해 온 지점도 바로 이러한 AI 인프라 운영 계층입니다.

혼자 고민하지 마세요! 긴 컨텍스트와 AI 에이전트의 확산으로 LLM 추론 인프라는 점점 복잡해지고 있습니다. TEN의 전문가와 함께 우리 조직의 모델과 워크로드에 맞는 GPU 구성과 운영 방향을 설계해 보세요.

👉 AI Pub으로 통합 운영 전략 살펴보기

👉 RA:X 인프라 컨설팅 알아보기

📩 [전문가와 직접 상담하기]


참고 자료 (출처)

  1. NVIDIA, "[What Is Disaggregated Serving](1. [ https://www.nvidia.com/en-us/glossary/disaggregated-serving/](https://www.nvidia.com/en-us/glossary/disaggregated-serving/))?"
  2. AWS, "Disaggregated prefill and decode for LLM inference on SageMaker HyperPod"

함께 읽어보면 좋은 글