AI가 긴 문서를 읽는 동안 다른 사람에게 보내던 답변까지 느려진다면, 서버는 일을 어떻게 나눠야 할까. NVIDIA Dynamo의 분리 서빙은 입력을 처리하는 프리필과 출력을 생성하는 디코드의 자원 요구가 다르다는 데서 출발한다. 두 단계를 별도 처리 집단으로 운영해 각각 필요한 만큼 자원을 배분하는 구조다. 핵심은 GPU를 더 많이 쓰는 것보다 입력 처리와 출력 생성의 부담을 구분하는 데 있다.
Dynamo가 맡는 일
Dynamo는 생성형 AI 모델을 여러 GPU에 걸쳐 서비스하기 위한 오픈소스 추론 프레임워크다. 추론은 학습된 모델이 입력을 받아 결과를 계산하는 과정이고, 서빙은 그 계산을 이용자 요청에 맞춰 제공하는 운영 과정이다. Dynamo는 요청을 보낼 곳을 정하고, 메모리를 관리하며, 처리에 필요한 데이터를 옮기는 역할을 맡는다. 실제 모델 계산을 담당하는 SGLang, TensorRT-LLM, vLLM 같은 추론 엔진도 지원한다. 따라서 Dynamo를 새로운 언어 모델로 이해하면 역할을 놓친다. 관심을 둘 부분은 모델의 지식을 늘리는 기능이 아니라, 여러 엔진과 GPU가 요청을 나눠 처리하도록 연결하는 방식이다. 분리 서빙에서는 프리필용 워커 풀과 디코드용 워커 풀을 따로 둔다. 워커 풀은 같은 역할을 수행하는 처리 단위들의 집합이다. 두 집단의 규모와 자원 크기, 배치 위치를 독립적으로 조정할 수 있으므로 입력 처리 수요가 커졌을 때 출력 생성 쪽까지 같은 비율로 늘릴 필요가 줄어든다.
입력 처리와 출력 생성의 차이
프리필(prefill)은 입력 프롬프트를 처리하고 초기 KV 캐시를 만드는 단계다. KV 캐시는 모델이 앞서 처리한 내용을 다음 계산에 재사용할 수 있도록 남겨 둔 중간 데이터다. 외부 지식을 모아 둔 검색 저장소나 답변 정확도를 높이는 별도 기능과는 역할이 다르다. 디코드(decode)는 이 캐시를 이용해 출력 토큰을 생성한다. 토큰은 모델이 텍스트를 다루는 단위다. 입력 내용을 처리하는 작업과 그 내용을 바탕으로 출력을 이어 가는 작업은 같은 추론에 속하지만, 하드웨어에 주는 부담이 같지 않다. NVIDIA의 구조 설명에서 프리필은 연산 중심, 디코드는 메모리 중심으로 구분된다. 프리필에서는 입력을 계산하는 능력이, 디코드에서는 생성 과정에 필요한 데이터를 메모리에서 다루는 능력이 주요 고려 대상이라는 뜻이다. 디코드에 연산이 없거나 프리필에 메모리가 필요 없다는 의미는 아니다. 이 차이 때문에 한 가지 자원 배분으로 두 단계를 함께 최적화하기 어렵다. 분리 서빙은 역할별로 자원을 조정할 여지를 만든다. 다만 이런 설계상의 이점만으로 특정 GPU 조합이 항상 가장 효율적이라고 결론 내릴 수는 없다.
무엇이 길어지는지부터 구분한다
프리필의 확장 수요를 살필 때는 입력 길이, 프롬프트 재사용, 컨텍스트 크기가 중요하다. 같은 요청 수라도 처리할 입력이 길어지면 입력 단계의 부담이 달라진다. 이미 처리한 프롬프트를 재사용할 수 있는지도 함께 봐야 하므로, 입력 길이 하나만으로 필요한 자원을 계산할 수는 없다. 디코드에서는 동시 처리 수, 출력 길이, 활성 KV 메모리가 주요 요인이다. 활성 KV 메모리는 현재 처리 중인 요청들이 사용하는 캐시 메모리를 뜻한다. 짧은 답을 내는 요청과 긴 답을 이어 가는 요청은 출력 단계에서 자원을 사용하는 양상이 다르다. 동시에 생성 중인 답변이 많아지는 상황도 별도로 살펴야 한다. 따라서 ‘요청이 늘었다’는 설명만으로 어느 쪽을 확장할지 정하기 어렵다. 긴 문서를 입력하는 요청이 늘어난 것인지, 여러 이용자가 동시에 긴 출력을 생성하는 것인지에 따라 먼저 살필 처리 집단이 달라진다. 입력 길이와 출력 길이를 구분하는 이유가 여기에 있다. 긴 입력의 프리필이 진행 중인 디코드를 막는 상황도 분리의 중요한 배경이다. 전용 프리필 엔진이 긴 입력을 맡으면 디코드 엔진은 기존 요청의 출력을 이어 가도록 운영할 수 있다. 긴 문서 한 건을 처리하는 문제와 이미 시작한 여러 답변을 계속 생성하는 문제를 따로 다루는 셈이다.
나눈 뒤에는 캐시를 연결해야 한다
분리 실행의 기본 흐름은 프리필 계산과 KV 캐시 생성, 디코드 엔진으로의 캐시 전송, 디코드 계산으로 이어진다. 처리 장소를 나눠도 앞 단계의 계산 결과는 뒤 단계에 필요하다. 두 엔진을 배치하는 것만으로 작업이 완성되지 않는 이유다. Dynamo의 개발 문서는 NIXL을 이용해 프리필 엔진의 GPU 메모리에서 디코드 엔진의 GPU 메모리로 KV 캐시를 직접 전송하는 방식을 설명한다. 이 전송은 비차단 방식이라, 전송 중에도 GPU가 다른 요청의 계산을 계속할 수 있도록 한다. 이는 데이터 이동 시간이 사라진다는 뜻이 아니라 전송과 다른 요청의 계산을 겹쳐 진행할 수 있다는 뜻이다. 라우팅도 함께 필요하다. 라우팅은 들어온 요청을 어느 처리 장치로 보낼지 정하는 작업이다. 캐시가 어디에 있는지 고려하면 이미 계산한 내용을 불필요하게 다시 처리하는 일을 줄일 수 있다. 처리 단계를 나눌수록 연산 자원의 위치뿐 아니라 재사용할 데이터의 위치도 운영에 중요해진다. 메모리 관리는 당장 쓰지 않는 데이터를 다른 저장 계층으로 옮겼다가 필요할 때 다시 가져오는 역할을 맡는다. 결국 분리 서빙은 독립적인 자원 배분과 함께 낮은 지연의 전송, 캐시 위치를 고려한 라우팅, 메모리 관리가 맞물려야 하는 구조다.
성능 숫자를 읽는 기준
이 구조를 알면 AI 기술동향 기사에서 ‘추론 성능이 좋아졌다’는 표현을 더 구체적으로 읽을 수 있다. 긴 입력을 처리하는 능력을 개선했는지, 여러 답변의 출력을 이어 가는 능력을 개선했는지 먼저 구분할 수 있기 때문이다. 같은 성능 설명이라도 어떤 요청을 처리했는지가 빠지면 내 서비스와 비교하기 어렵다. 비교할 때는 입력·출력 길이와 동시 처리 수를 놓고, 프리필과 디코드에 자원을 어떻게 나눴는지 살펴야 한다. 이어서 두 단계 사이의 KV 캐시 전송 조건을 봐야 한다. 자원을 독립적으로 조정할 수 있는 이점과 데이터를 옮겨야 하는 부담이 함께 있기 때문이다. 여기서 다룬 내용은 NVIDIA가 설명하는 설계와 작동 원리다. 개발 문서에 제시된 전송 방식은 특정 정식 버전 전체의 동작을 보장하는 설명과 구분해야 하며, 구조 설명 자체가 독립적인 성능 측정 결과를 대신하지도 않는다. Dynamo의 성능 수치를 접했다면 먼저 자신이 비교하려는 작업의 입력 길이, 출력 길이, 동시 처리 수를 적어 두자. 그 조건에 맞는 자원 배분과 전송 환경에서 나온 결과가 실제 판단의 출발점이다.
참고자료
참고 1: NVIDIA Developer · NVIDIA Dynamo https://developer.nvidia.com/DYNAMO 참고 2: NVIDIA Docs · Disaggregated Serving https://docs.nvidia.com/dynamo/user-guides/disaggregated-serving 참고 3: NVIDIA Docs · Disaggregated Serving 시스템 아키텍처 https://docs.nvidia.com/dynamo/dev/knowledge-base/concepts/system-architecture/disaggregated-serving 참고 4: NVIDIA · What Is Disaggregated Serving? https://www.nvidia.com/en-eu/glossary/disaggregated-serving/