청크드 프리필 대 분리 서빙: 디코드 지연 대조

청크 크기를 조정하는 것과 프리필·디코드를 분리하는 것, 어느 쪽이 디코드 지연을 더 확실히 줄이는가?

청크드 프리필은 같은 GPU 안에서 간섭을 완화하는 조정책이고, 프리필·디코드 분리는 간섭 자체를 구조적으로 제거하는 선택이다. L40S 2장 측정에서 콜로케이티드 구성의 p99 ITL은 169ms였지만 분리 구성은 29ms였다. 다만 분리는 KV 캐시 전송이라는 새 비용을 요구하므로, 어느 쪽이 나은지는 SLO와 네트워크 조건에 달려 있다.

• 청크드 프리필은 vLLM V1의 기본 동작으로 긴 프리필을 쪼개 디코드 대기를 줄이지만, 같은 GPU에서 실행되는 한 메모리 대역폭 경합은 남는다 vLLM 공식 문서
• 프리필 KV 길이를 2,000토큰에서 10,000토큰으로 늘리면 디코드 지연이 36% 증가한다 관련 연구
• L40S 2장, 0.4 req/s 조건에서 콜로케이티드 p99 ITL은 169ms, 분리 구성은 29ms다
• 같은 조건에서 중앙값 ITL은 21~24ms로 비슷해, 차이는 p99 tail에서만 뚜렷이 드러난다
• 분리는 KV 전송 비용을 새로 지불하므로 모든 상황에서 더 빠른 것은 아니다

두 선택지를 나란히 놓으면 구도가 명확해진다. 하나는 단일 GPU 풀 안에서 max_num_batched_tokens와 청크 크기를 조정하는 운영 수준의 해법이고, 다른 하나는 프리필 전담 인스턴스와 디코드 전담 인스턴스로 물리적으로 나누는 아키텍처 수준의 해법이다. 전자는 설정 변경만으로 적용 가능하지만 근본 원인인 자원 경합을 남기고, 후자는 경합을 없애지만 운영 복잡도와 네트워크 의존성을 더한다.

프리필과 디코드가 같은 GPU를 쓰면 정확히 무엇이 충돌하는가?

프리필은 계산 집약적이고 디코드는 메모리 대역폭 집약적이어서, 둘이 같은 GPU에서 겹치면 서로 다른 자원을 놓고 경쟁한다. Microsoft의 POD-Attention 연구는 청크드 프리필이 TTFT는 낮추지만 새 요청의 프리필이 진행 중인 디코드를 멈추게 해 TBT를 높일 수 있다고 설명한다 POD-Attention 논문. 실제로 프리필의 KV 읽기 규모가 커질수록 디코드의 지연 민감한 메모리 접근이 뒤로 밀린다. 2025년 연구의 측정에서는 프리필 KV 길이를 2,000토큰에서 10,000토큰으로 늘렸을 때, 디코드 작업 자체는 동일한 조건인데도 지연이 36% 증가했다. 이 결과는 프리필 어텐션의 대규모 KV 읽기와 디코드의 순차적 메모리 접근이 같은 대역폭을 다투기 때문으로 분석된다. 즉 문제는 스케줄링 순서만이 아니라 하드웨어 자원의 물리적 공유에 있다.

청크 크기를 조정하는 것만으로 간섭을 없앨 수 있는가?

완전히 없애지는 못한다. 청크 크기는 간섭의 강도를 조절할 뿐, 같은 GPU에서 실행되는 한 경합 자체는 남는다. vLLM 문서는 작은 청크(예: 2,048토큰)가 디코드 ITL을 줄이는 경향이 있고, 큰 청크는 TTFT와 처리량에 유리하다고 설명하며, 소형 모델·대형 GPU에서는 최적 처리량을 위해 max_num_batched_tokens > 8192를 권장한다 vLLM 공식 문서. 문제는 이 둘이 상충한다는 점이다. 청크가 크면 한 엔진 스텝 동안 디코드가 기다리는 시간이 늘어 ITL과 tail latency가 악화되고, 청크가 작으면 디코드 간섭은 줄지만 프리필 스케줄링·커널 실행 효율이 떨어진다. 따라서 max_num_batched_tokens는 고정된 최적값이 아니라 입력 길이, 동시성, TTFT/ITL SLO에 맞춰 반복적으로 재튜닝해야 하는 변수다.

프리필과 디코드를 아예 분리하면 간섭이 사라지는가?

분리는 간섭의 메커니즘 자체를 제거하지만 항상 더 빠른 결과를 보장하지는 않는다. L40S 48GB PCIe 2장, Qwen2.5-7B-Instruct, 약 8,000토큰 입력 조건에서 0.4 req/s 부하 시 콜로케이티드 구성의 p99 ITL은 169ms였고, 프리필·디코드 분리 구성은 29ms로 측정 범위 내 52ms 이하를 유지했다 vLLM 분리 서빙 가이드. AMD MI300X 8-GPU 노드에서 Qwen3-235B-A22B-FP8을 8 req/s로 서빙했을 때는, TTFT 1초와 ITL 50ms를 동시에 만족한 요청이 분리 구성에서 100건 중 73건, 콜로케이티드 구성에서 30건이었다. 그러나 반대 사례도 있다. H100 2장, Qwen3-8B를 다룬 2025년 연구는 1P+1D 분리 구성이 프리필 GPU 한 장만 사용하기 때문에 프리필 자체가 병목이 될 수 있는 반면, 집계형 청크드 프리필은 두 GPU가 함께 프리필을 수행해 프리필 처리량에서 오히려 유리할 수 있다고 보고했다 arXiv 2511.04791. 분리가 간섭을 없애는 것은 맞지만, GPU 배분 비율이 맞지 않으면 다른 종류의 병목을 만든다.

실측 수치로 비교하면 차이는 얼마나 되는가?

규모와 조건에 따라 격차가 크게 달라진다. 아래는 공개된 측정값을 조건과 함께 정리한 것이다.

출처: vLLM 분리 서빙 가이드

중앙값만 보면 두 구성이 거의 같아 보이지만, 긴 프리필이 디코드와 섞이는 순간 p99가 급격히 벌어진다. 평균이나 중앙값 지표만으로 간섭 여부를 판단하면 실제 사용자 체감 지연을 놓칠 수 있다는 점이 이 비교의 핵심이다.

분리 구성으로 옮기면 실제로 무엇이 추가로 드는가?

프리필이 생성한 KV 캐시를 디코드 인스턴스로 전달하는 과정이 새로운 비용으로 추가된다. 프리필과 디코드를 다른 GPU로 나누면 긴 프리필이 디코드 스트림을 직접 멈추지는 않지만, 그 대신 KV 캐시 전송이라는 단계가 생긴다. 이 전송 비용은 컨텍스트 길이가 길수록 커지며, 네트워크 대역폭이 충분하지 않으면 TTFT 개선분을 상쇄할 수 있다 분리 프리필·디코드 아키텍처 설명. 또한 분리는 프리필 전담 GPU 풀과 디코드 전담 GPU 풀을 별도로 운영해야 하므로, GPU 배분 비율을 트래픽 패턴에 맞춰 재조정하는 작업이 뒤따른다. 2026년 기준 공개된 사례들은 대부분 프리픽스 캐싱을 끈 상태에서 측정됐다는 점도 주의할 조건이다. 캐시 적중률이 높은 환경에서는 프리필 작업량 자체가 줄어 간섭의 절대 크기가 달라지므로, 캐시 적중률과 재사용 토큰 수를 분리 전환 평가에 반드시 포함해야 한다.

그래서 청크 크기 튜닝과 분리 구성 중 무엇을 먼저 해야 하는가?

둘 중 어느 쪽도 보편적인 정답이 아니다. p99 ITL/TBT가 핵심 SLO이고 트래픽이 꾸준히 혼재된 프리필·디코드 패턴을 보인다면, 청크 크기 조정만으로는 한계가 있고 별도 프리필·디코드 풀 구성을 검토할 근거가 된다. 반대로 GPU 수가 적어 풀을 나누기 어렵거나, 네트워크 대역폭이 KV 전송을 감당하기 어렵거나, 입력 길이가 짧아 간섭 자체가 작다면 max_num_batched_tokens 재튜닝만으로 충분할 수 있다. 판단 전에는 모델·정밀도, GPU 모델과 수, NVLink 또는 PCIe 여부, 입출력 토큰 길이 분포, 도착률(req/s), 청크 크기, 프리픽스 캐시 적중률, 그리고 TTFT·평균/ p95/ p99 ITL·goodput을 함께 측정해 기록해야 한다. 이 조건들이 갖춰지지 않은 벤치마크 비교는 공개된 L40S·MI300X·H200 사례와 재현 가능한 형태로 맞춰보기 어렵다.

핵심 정리

• 청크드 프리필은 같은 GPU 안에서 간섭을 완화하지만 제거하지는 못한다. 프리필 KV 길이가 2,000→10,000토큰으로 늘면 디코드 지연이 36% 증가한다.
• 프리필·디코드 분리는 L40S 사례에서 p99 ITL을 169ms에서 29ms로, MI300X 사례에서 SLO 동시 만족률을 30%에서 73%로 끌어올렸다.
• 중앙값만 보면 두 구성 차이가 거의 없을 수 있다(21~24ms). 차이는 p99 tail에서 드러난다.
• 분리는 KV 캐시 전송 비용을 새로 더하며, 네트워크 대역폭이 부족하면 TTFT 개선분이 상쇄될 수 있다.
• max_num_batched_tokens는 고정값이 아니라 입력 길이·동시성·SLO에 맞춰 재튜닝할 변수이며, 분리 전환 여부는 GPU 가용성과 네트워크 조건을 함께 봐야 한다.

자주 묻는 질문

프리픽스 캐싱을 켜면 간섭 문제가 저절로 줄어드는가?

캐시 적중률이 높으면 반복되는 시스템 프롬프트나 대화 이력의 프리필 작업량 자체가 줄어 간섭의 절대 크기가 작아질 수 있다. 다만 공개된 L40S 측정은 프리픽스 캐싱을 꺼 둔 조건이므로, 그 수치를 캐시가 켜진 환경에 그대로 적용할 수 없다. 캐시 적중률, 재사용 토큰 수, 캐시 저장 위치를 별도 조건으로 기록해야 비교가 의미를 가진다.

max_num_batched_tokens는 얼마로 설정해야 하는가?

단일 정답은 없다. vLLM 문서는 소형 모델·대형 GPU에서 처리량 최적화를 위해 8,192 초과 값을 권장하지만, ITL이 민감한 서비스라면 2,048처럼 작은 값이 더 나을 수 있다. 입력 길이 분포와 동시성, TTFT/ITL SLO를 바꿀 때마다 재튜닝이 필요하다.

분리 구성이면 프리필 병목은 생기지 않는가?

아니다. 프리필 전담 GPU 한 장만 배정한 1P+1D 구성은 프리필 처리량 자체가 병목이 될 수 있다. H100 2장, Qwen3-8B 비교에서는 집계형 청크드 프리필이 두 GPU를 함께 써서 프리필 처리량 면에서 유리한 경우도 보고됐다.

KV 캐시 전송 지연은 어떻게 측정해야 하는가?

컨텍스트 길이별 전송 데이터량, 실제 네트워크 대역폭, 전송에 걸린 시간을 TTFT·ITL과 함께 기록해야 한다. 전송 지연이 크면 분리 구성의 p99 개선분이 상쇄될 수 있으므로, 벤치마크에는 반드시 KV 전송량과 전송 지연을 별도 항목으로 남겨야 한다.

더 알아보기

LLM 추론 서빙: 처리량과 지연의 트레이드오프를 보는 법 — 이 주제의 종합 가이드