How Long Prompts Block Other Requests - Optimizing LLM Performance | Article 정리

🖼️ 인포그래픽

How Long Prompts Block Other Requests - Optimizing LLM Performance 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

💡 한 줄 요약

긴 프롬프트가 포함된 요청은 프리필 대기열과 동시 디코딩을 지연시키며, 요청 병렬 프리필은 첫 토큰 지연을 줄이고 프리필·디코드 분리 구조는 토큰 생성 간섭을 완화한다.

📌 핵심 요약

LLM 추론에서 프리필은 전체 프롬프트를 병렬 처리해 GPU 연산을 포화시킬 수 있지만, 디코드는 출력 토큰을 하나씩 순차적으로 생성하므로 두 단계를 동시에 처리할 때 세심한 스케줄링이 필요하다.
기본 청크 프리필에서는 서로 다른 요청의 프리필이 순차적으로 처리되므로, 긴 프롬프트 하나가 뒤에 도착한 요청들의 시작을 막아 첫 토큰 생성 시간을 크게 늘릴 수 있다.
vLLM의 요청 병렬 프리필은 동시에 처리할 요청 수와 긴 프롬프트 수를 제한해 짧은 요청에 빠른 경로를 제공하며, 특히 첫 토큰 생성 시간을 줄인다.
그러나 프리필과 디코드를 같은 GPU 연산에서 수행하는 한, 긴 프롬프트의 프리필은 이미 디코딩 중인 모든 요청의 토큰 생성 속도를 떨어뜨리며 병렬 프리필도 이 근본 문제를 없애지는 못한다.
프리필과 디코드를 서로 다른 GPU의 vLLM 배포로 분리하면 직접적인 간섭을 크게 줄일 수 있지만, 추가 GPU와 KV 캐시 전송, 불균형한 자원 활용, 실험적 구현의 제약을 감수해야 한다.

🧩 주요 포인트

LLM 추론에서 프리필은 전체 프롬프트를 병렬 처리해 GPU 연산을 포화시킬 수 있지만, 디코드는 출력 토큰을 하나씩 순차적으로 생성하므로 두 단계를 동시에 처리할 때 세심한 스케줄링이 필요하다.
기본 청크 프리필에서는 서로 다른 요청의 프리필이 순차적으로 처리되므로, 긴 프롬프트 하나가 뒤에 도착한 요청들의 시작을 막아 첫 토큰 생성 시간을 크게 늘릴 수 있다.
vLLM의 요청 병렬 프리필은 동시에 처리할 요청 수와 긴 프롬프트 수를 제한해 짧은 요청에 빠른 경로를 제공하며, 특히 첫 토큰 생성 시간을 줄인다.
그러나 프리필과 디코드를 같은 GPU 연산에서 수행하는 한, 긴 프롬프트의 프리필은 이미 디코딩 중인 모든 요청의 토큰 생성 속도를 떨어뜨리며 병렬 프리필도 이 근본 문제를 없애지는 못한다.
프리필과 디코드를 서로 다른 GPU의 vLLM 배포로 분리하면 직접적인 간섭을 크게 줄일 수 있지만, 추가 GPU와 KV 캐시 전송, 불균형한 자원 활용, 실험적 구현의 제약을 감수해야 한다.

🧠 상세 정리

1. 대규모 자체 호스팅 환경에서 드러난 지연 문제

TNG는 24개의 H100 GPU로 여러 대규모 언어 모델을 자체 호스팅하며 50개가 넘는 애플리케이션에 추론 서비스를 제공한다. 이 환경에서는 하루에 1억 개가 넘는 입력 토큰을 처리하고 1천만 개가 넘는 출력 토큰을 생성하기 때문에, 개별 요청의 처리 방식이 전체 서비스 품질에 큰 영향을 미친다. 특히 새 요청에 빠르게 응답하면서도 이미 실행 중인 요청의 토큰 생성을 원활하게 유지하려면 프리필과 디코드 사이의 균형을 정교하게 조정해야 한다. 글은 이 동시 처리 과정에서 나타나는 두 문제를 구분하는데, 하나는 긴 프롬프트가 프리필 대기열을 막는 비교적 해결 가능한 문제이고 다른 하나는 동시 프리필이 디코딩을 늦추는 구조적 문제다.

2. 프리필과 디코드의 상이한 계산 특성

첫 번째 출력 토큰을 만들기 위한 프리필 단계에서는 요청에 포함된 전체 프롬프트를 처리해야 한다. 프롬프트 토큰은 효율적으로 병렬 계산할 수 있어 하나의 프리필만으로도 GPU 연산 자원을 포화시킬 수 있다. 반면 이후의 디코드 단계에서는 매번 추가 토큰 하나만 처리하므로 개별 연산량은 작지만, 앞에서 생성된 결과에 의존해 순차적으로 실행해야 한다. 처리량을 높이기 위해 여러 요청의 디코드를 배치할 수는 있지만, 새 요청의 프리필까지 기존 디코드와 함께 실행하면 연산량이 큰 프리필이 토큰 생성 흐름에 영향을 준다. 따라서 낮은 지연 시간을 목표로 하는 서버는 새 요청의 빠른 시작과 진행 중인 요청의 안정적인 디코딩을 동시에 고려해야 한다.

3. 긴 프롬프트가 프리필 대기열을 막는 방식

vLLM의 기본 청크 프리필 전략에서는 다른 요청의 디코드가 동시에 진행될 때 각 프리필 청크에 한 요청의 프롬프트 토큰만 담긴다. 단일 요청의 프리필만으로도 GPU가 포화될 수 있기 때문에 서로 다른 요청의 프리필은 기본적으로 차례대로 실행된다. 이때 매우 긴 프롬프트가 먼저 프리필 대기열에 들어오면 뒤따르는 요청은 그 작업이 끝날 때까지 자신의 프리필을 시작하지 못한다. 결과적으로 뒤의 요청이 짧더라도 첫 출력 토큰을 받을 때까지 긴 시간을 기다리게 된다. 마지막 프리필 청크에 여유가 있으면 다음 요청의 일부를 함께 처리할 수 있지만, 긴 프롬프트가 대기열을 선점한다는 핵심 문제는 그대로 남는다.

4. 우선순위 스케줄링만으로 해결할 수 없는 이유

이 대기열 차단은 vLLM 내부의 우선순위 스케줄링이나 상위 계층의 정교한 요청 스케줄러만으로는 해결하기 어렵다. 긴 프롬프트 요청이 도착한 시점에 뒤따를 요청이 아직 존재하지 않을 수 있기 때문이다. 스케줄러는 미래에 짧고 중요한 요청이 들어올지 알 수 없으므로, 현재의 긴 요청을 보류할 근거 없이 즉시 실행할 수밖에 없다. 이후 짧은 요청이 도착하더라도 이미 시작된 긴 프리필 뒤에서 기다리게 된다. 즉, 문제는 단순히 대기 중인 요청들의 순서를 잘못 정한 데서 발생하는 것이 아니라, 연산이 시작된 뒤에는 미래 요청을 고려해 선제적으로 자리를 비워 둘 수 없다는 실행 구조에서 비롯된다.

5. 요청 병렬 프리필과 짧은 프롬프트의 빠른 경로

직관적인 대응은 서로 다른 요청의 프리필 청크를 병렬로 처리해 뒤의 짧은 요청이 앞선 긴 요청의 완료를 기다리지 않도록 하는 것이다. 그러나 두 개의 긴 프롬프트를 함께 배치하면 이미 연산 집약적인 프리필끼리 경쟁해 처리 속도가 심각하게 떨어질 수 있다. 이를 보완한 vLLM 전략은 병렬로 프리필할 요청 수와 그중 긴 프롬프트로 허용할 요청 수를 각각 제한한다. 예를 들어 네 요청의 프리필을 함께 처리하되 1만 토큰을 넘는 요청은 하나만 허용하면, 긴 요청들은 계속 순차적으로 실행하면서 짧은 요청은 빈 병렬 슬롯을 이용할 수 있다. 이 빠른 경로는 짧은 요청의 대기 시간을 줄여 첫 토큰 생성 시간 지표를 뚜렷하게 개선한다.

6. 첫 토큰 지연 개선과 전체 완료 시간의 한계

요청 병렬 프리필을 사용하면 새 요청은 앞선 요청의 프리필이 모두 끝나기 전에 자신의 프리필을 시작할 수 있다. 따라서 특히 뒤늦게 도착한 짧은 요청의 첫 토큰 생성 시간은 순차적 부분 프리필을 사용할 때보다 크게 줄어든다. 하지만 긴 프리필과 디코드가 같은 GPU 연산에서 계속 경쟁하므로 출력 토큰 하나를 생성하는 데 걸리는 시간은 여전히 증가한다. 측정에서도 세 번째 요청의 첫 토큰은 훨씬 빨리 나타났지만, 전체 완료 시간의 개선 폭은 작았다. 요청 병렬 프리필은 대기열 진입 문제를 완화하는 방법이지, 동시 프리필이 디코딩 처리량을 떨어뜨리는 현상까지 제거하는 해결책은 아니다.

7. 동시 프리필이 기존 토큰 생성을 늦추는 근본적 결함

서로 다른 요청의 프리필과 디코드를 하나의 GPU 작업에서 실행하면, 격리된 디코드만 수행할 때보다 각 연산에 더 긴 시간이 걸린다. 그 결과 긴 프롬프트 요청 하나만 새로 들어와도 이미 디코드 단계에 있는 모든 요청의 토큰 생성이 일시적으로 끊기거나 느려질 수 있다. 긴 요청을 낮은 우선순위로 미루는 방법은 해당 요청의 지연을 늘리고, 부하가 높을 때는 합리적인 시간 안에 실행되지 못하게 할 위험이 있다. 긴 프롬프트용 추론 서버를 별도로 두는 방법도 가능하지만 추가 GPU가 필요하며, 긴 요청이 없을 때 큰 서버의 자원을 활용할 수 있도록 복잡한 라우터를 설계해야 한다. TNG는 배치 요청을 매우 낮은 우선순위로 처리하는 유사 전략을 구현했지만, 이는 근본 원인을 제거하는 방식은 아니다.

8. 프리필·디코드 분리 구조의 효과와 비용

분리형 프리필은 여러 vLLM 배포를 조합해 일부 워커는 프리필만, 다른 워커는 디코드만 수행하도록 구성한다. 프리필이 끝나면 KV 캐시를 디코드 워커로 전송하므로 소규모 통신 비용이 발생하지만, 두 단계가 서로 다른 GPU에서 실행되어 프리필이 디코드를 직접 방해하지 않는다. 이 방식은 총처리량 자체보다 지연 목표를 충족하는 요청의 비율인 굿풋을 높이는 데 초점이 있으며, 개별 요청의 지연에 민감하지 않은 서비스에는 GPU 자원을 효율적으로 쓰는 선택이 아닐 수 있다. 긴 컨텍스트를 지원하는 Llama-3.3-70B 사례에서는 프리필 워커와 디코드 워커에 각각 네 개의 H100이 필요할 수 있고, 두 단계의 계산 특성이 달라 GPU 활용률도 불균형해질 수 있다. 또한 당시 vLLM 구현은 실험 단계여서 컨텍스트 길이 제한과 CUDA 그래프 활용 부족 등의 제약이 있었지만, 글은 이를 구조적 장애가 아니라 향후 개선 가능한 구현 성숙도의 문제로 본다.

🧾 핵심 주장 / 시사점

사용자가 체감하는 응답성은 전체 완료 시간만으로 판단하기 어렵고, 첫 토큰 생성 시간과 토큰별 생성 지연을 분리해 측정해야 한다.
요청 병렬 프리필은 짧은 요청의 대기열 차단을 완화하지만, 같은 GPU에서 프리필과 디코드를 병행하는 한 기존 요청의 생성 속도 저하는 남는다.
분리형 프리필은 지연 목표를 우선하는 시스템에 적합하며, 도입 여부는 총처리량보다 굿풋, 추가 GPU 비용, 실제 프리필·디코드 부하 비율을 기준으로 판단해야 한다.