LLM 응답 지연: 긴 입력을 나눠 처리하면 무엇이 달라지는가

LLM의 프리필과 디코드가 공유 서버에서 서로 지연시키는 원리를 살펴본다. Sarathi-Serve와 vLLM의 chunked prefill을 바탕으로 긴 문서와 짧은 질문이 함께 들어오는 업무의 응답 시간을 설계하는 방법을 제안한다.

AI로 생성한 개념 이미지이며, 실제 서버의 실행 화면이나 성능 측정 결과가 아니다.

여러 사람이 사내 문서 도우미를 함께 쓰는 상황을 가정해 보자. 한 사람은 짧은 규정 질문의 답변을 읽는 중이고, 다른 사람은 긴 회의록을 넣어 요약을 요청한다. 새 요청이 들어온 뒤 먼저 나오던 답변이 중간에서 멈칫한다. 서버가 멈춘 것은 아니고, 잠시 뒤 문장이 다시 이어진다. 이런 지연을 모두 모델의 추론 능력이나 네트워크 탓으로 돌리면, 함께 실행되는 요청들이 계산 자원을 어떻게 나누는지 놓칠 수 있다.

LLM 서비스의 속도에는 서로 다른 기다림이 섞여 있다. 요청을 보낸 뒤 첫 토큰이 나올 때까지의 시간과, 답변이 시작된 뒤 다음 토큰을 기다리는 시간은 다르다. 긴 문서를 빨리 읽게 만드는 설정이 이미 답변을 읽고 있는 사람에게는 불편을 줄 수도 있다. 한 요청의 속도만 측정해서는 여러 사람이 함께 쓰는 환경을 판단하기 어렵다.

2024년 OSDI 논문 《Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve》는 이 문제를 입력 처리와 출력 생성의 스케줄링으로 다룬다. 긴 입력의 계산을 작은 단위로 나누고, 진행 중인 생성과 같은 배치에 넣는 방식이다. 현재 vLLM V1의 최적화 문서에서도 이 원리인 chunked prefill을 확인할 수 있다. 모델을 다시 학습시키지 않고도 업무의 대기 시간을 바꿀 수 있다.

입력을 읽는 계산과 답변을 잇는 계산

여기서 다루는 범위는 일반적인 자기회귀 Transformer의 텍스트 생성이다. 먼저 모델은 입력 토큰들을 처리하고 이후 생성에 필요한 상태를 준비한다. 이를 프리필(prefill)이라고 한다. 이어 앞서 처리한 내용과 이미 생성한 토큰을 바탕으로 다음 토큰을 만드는 디코드(decode)가 반복된다. 토큰은 모델이 처리하는 단위이며, 한국어의 글자나 단어 하나와 항상 일치하지 않는다.

프리필은 여러 입력 토큰을 병렬로 처리할 수 있어 GPU의 계산 능력을 활용하기 좋다. 반면 일반적인 디코드 한 단계는 요청마다 새 토큰 하나를 다루므로, 작은 배치에서는 계산량에 비해 가중치와 KV 캐시를 읽는 부담이 크다. Sarathi-Serve 논문은 이 차이를 프리필의 계산 중심 성격과 디코드의 메모리 중심 성격으로 설명한다.[1] 실제 병목은 모델 구조, 문맥 길이와 배치 크기, 장비에 따라 달라질 수 있으므로 모든 실행을 이 구분 하나로 진단해서는 안 된다.

서버는 여러 요청을 한 번에 묶어 처리하는 배칭으로 자원을 더 효율적으로 쓸 수 있다. 디코드 단계에서 여러 요청을 함께 처리하면 가중치를 읽는 비용을 나눌 수 있다. 다만 각 요청의 입력과 출력 길이는 다르다. 묶음 전체가 끝날 때까지 새 요청을 받지 않으면, 먼저 끝난 요청의 빈자리를 활용하지 못한다.

반복 계산 단계마다 완료된 요청을 빼고 새 요청을 받아들이는 연속 배칭은 이 빈자리를 줄인다. 그래도 새 입력을 언제 얼마나 처리할지는 남는다. 긴 입력의 프리필을 한꺼번에 우선 실행하면 기존 요청의 디코드가 밀릴 수 있다. 반대로 진행 중인 디코드가 모두 끝날 때까지 새 입력을 미루면 새 이용자의 첫 응답이 늦어지고 배치도 작아질 수 있다. 연속 배칭이라는 이름만으로 이 절충이 사라지지는 않는다.

논문에서 비교한 당시 vLLM의 스케줄링과 오늘의 vLLM V1은 구분해야 한다. 논문은 당시 비교 시스템의 긴 프리필로 인한 생성 정체를 분석했다. 이를 현재 vLLM 전체의 결함이라고 옮기면 잘못된 설명이 된다. 현재 문서는 가능한 경우 chunked prefill을 기본으로 사용하며 디코드를 우선 배치한다고 안내한다.[2]

프리필을 나누되 문맥은 이어 둔다

Chunked prefill은 긴 프리필을 여러 계산 단계로 나눠 실행한다. 문서의 일부를 버리거나 앞부분을 요약해 대체하는 방식은 아니다. 뒤쪽 조각을 처리할 때도 앞쪽 조각의 KV 상태를 참조한다. 입력의 계산 순서를 나눠 다른 요청과 자원을 공유하는 것이지, 각 조각을 서로 독립적인 문서로 읽게 하는 것이 아니다.

이 점에서 RAG의 문서 청킹과 다르다. RAG 청킹은 검색할 자료의 단위를 정하고 어떤 구간을 모델에 줄지 결정한다. Chunked prefill은 그렇게 최종 입력이 정해진 뒤, 그 입력의 계산을 서버가 어떻게 배치할지 다룬다. 검색용 청크를 작게 만든다고 자동으로 추론 서버의 프리필 스케줄이 바뀌는 것은 아니다.

Sarathi-Serve의 스케줄러는 매 단계에 처리할 토큰 예산을 둔다. 진행 중인 디코드를 먼저 넣고, 아직 끝나지 않은 프리필을 이어 처리한 뒤, 남은 예산과 메모리 조건 안에서 새 요청을 받아들인다. 새 요청의 긴 프리필도 그 단계에 들어갈 만큼만 나눈다. 논문은 이런 혼합 배치를 stall-free batching이라고 부른다.[1]

예를 들어 규정 답변이 계속 생성되는 동안 회의록의 앞부분만 함께 계산하고, 다음 단계에는 규정 답변을 이어 생성하면서 회의록의 다음 부분을 처리할 수 있다. 회의록 전체의 프리필이 끝나야 그 요청의 답변 생성이 시작되지만, 그동안 다른 요청의 디코드를 통째로 밀어낼 필요는 줄어든다. 이는 원리를 설명하기 위한 가상 예시이며 실제 처리 기록은 아니다.

여기서 stall-free를 지연이 전혀 없다는 뜻으로 읽어서는 안 된다. 혼합 배치에도 실행 시간이 들고, 프리필 조각을 크게 잡으면 기존 답변의 토큰 간격이 길어질 수 있다. 설계의 목적은 새 입력 하나가 긴 독점 계산을 만들어 진행 중인 생성을 막는 현상을 줄이는 데 있다. 사용자가 느끼는 모든 멈춤이나 서버의 모든 대기열을 없애는 보장은 아니다.

앞부분 계산을 재사용하는 prefix caching과도 역할이 다르다. 캐싱은 동일한 입력 앞부분의 계산을 다시 쓰는 방법이고, chunked prefill은 지금 필요한 입력 계산을 나눠 배치하는 방법이다. 두 기법을 함께 사용할 수 있지만, 서로 다른 문서를 처리해 캐시가 잘 맞지 않아도 스케줄링 문제는 남는다. 속도가 달라졌다면 재사용 덕분인지 배치 순서 덕분인지 나눠 확인해야 한다.

작은 조각이 언제나 유리한 것은 아니다

2026-09-15에 확인한 vLLM V1 문서는 max_num_batched_tokens를 배치의 토큰 예산으로 설명한다. 디코드를 우선 넣고 남은 예산에 프리필을 배치하며, 프리필이 예산에 들어가지 않으면 나눠 처리한다. 이 값은 한 요청에 허용하는 전체 문맥 길이나 결과의 최대 출력 길이와 같은 설정이 아니다.[2]

문서는 예산이 작을수록 한 배치의 프리필 부담을 줄여 토큰 간 지연인 ITL에 유리하고, 예산이 클수록 더 많은 입력을 한 번에 처리해 첫 토큰까지의 시간인 TTFT에 유리할 수 있다고 설명한다. 그러나 이를 모든 모델과 요청 분포에 통하는 고정 처방으로 사용해서는 안 된다. 짧은 질문 위주인지 긴 문서가 섞이는지, 요청이 얼마나 자주 도착하는지에 따라 선택이 달라진다.

조각을 지나치게 작게 나눠도 비용이 생긴다. Sarathi-Serve 논문은 뒤쪽 조각을 계산할 때 앞쪽 조각의 KV 캐시를 다시 읽어야 하므로 메모리 읽기가 늘고, 작은 계산마다 커널 실행 같은 고정 비용이 붙을 수 있다고 설명한다. 너무 작은 배치는 GPU의 계산 능력을 충분히 활용하지 못할 수도 있다. 논문은 목표로 하는 토큰 간 지연과 장비, 병렬 실행 구성을 함께 보고 토큰 예산을 정한다.[1]

메모리 부족은 별도의 제약이다. 더 많은 요청을 동시에 유지하면 KV 캐시 공간이 모자랄 수 있다. vLLM 문서는 이때 요청을 선점해 공간을 확보하고 나중에 다시 계산하는 경로를 설명하며, 선점과 재계산이 전체 지연에 악영향을 줄 수 있다고 적는다.[2] 배치 예산만 바꾸고 선점 횟수를 보지 않으면, 스케줄링 개선과 메모리 압박이 뒤섞인 결과를 얻는다.

논문의 성능 수치에도 범위가 있다. 연구진은 Mistral-7B, Yi-34B, LLaMA2-70B, Falcon-180B와 정해진 GPU 구성에서 대화·논문 요약 요청을 사용해 평가했다. 핵심 지표는 일정한 지연 목표를 지키면서 감당할 수 있는 요청량이었다. 당시 기준 시스템보다 높은 처리 용량을 보고했지만, 그 배율은 오늘의 vLLM이나 한국어 조직 문서에 그대로 적용되지 않는다. 이 글에서도 별도의 추론 성능 실험을 수행하지 않았다.

AKM 업무에서는 긴 문서와 짧은 질문을 함께 시험한다

AKM 같은 지식 관리 환경에 이 원리를 가져온다면, 검색을 끝낸 뒤 모델에 건네는 입력의 길이와 요청이 겹치는 시점을 함께 기록할 수 있다. 다음은 특정 조직의 운영 성과나 공개되지 않은 구현이 아니라 DEXA의 적용 제안이다. 검색 정확도와 근거의 신뢰도를 프리필 설정으로 해결한다는 뜻도 아니다.

시험 장면은 단일 요청의 최고 속도보다 실제 업무의 혼합에 맞춘다. 짧은 규정 질의만 들어오는 경우를 먼저 보고, 같은 질의가 진행되는 동안 긴 회의록 요약을 넣었을 때 무엇이 달라지는지 비교한다. 모델과 엔진 버전, 하드웨어, 검색된 원문과 생성 설정을 고정하고, 바꾸는 스케줄링 설정을 명시한다. Prefix caching이 켜져 있다면 캐시 상태도 함께 남겨야 한다. 이미 채워진 캐시의 결과를 스케줄러의 개선으로 잘못 읽지 않기 위해서다.

측정에서는 첫 응답의 기다림과 생성 중의 끊김을 분리한다. TTFT는 요청을 보낸 뒤 첫 토큰을 받을 때까지로, ITL은 출력 토큰 사이의 간격으로 정의할 수 있다. 논문은 토큰 사이 시간을 TBT라고 부른다. 측정 도구마다 정의가 다를 수 있으므로, 서버 내부 시간인지 이용자가 실제로 받은 시간인지부터 맞춘다. 검색과 네트워크, 화면의 출력 버퍼링이 포함되면 같은 이름의 지표도 다른 구간을 잴 수 있다.

평균만 보면 소수의 긴 멈춤이 가려질 수 있다. 토큰 간격의 분포와 긴 지연이 나타난 요청을 확인하고, 목표 지연을 넘긴 비율과 그때의 동시 요청 수를 연결한다. 처리량은 초당 토큰 수만이 아니라 정한 응답 조건 안에서 끝난 업무 요청 수로도 살펴볼 수 있다. 어떤 기준을 썼는지 기록해야 서로 다른 설정의 수치를 비교할 수 있다.

사용자가 답변을 읽으며 다음 질문을 하는 상담형 업무라면 생성 중 긴 멈춤을 줄이는 것이 중요할 수 있다. 반대로 밤에 모아 처리하고 아침에 확인하는 요약 업무는 토큰이 매끄럽게 나타나는 것보다 완료 시한과 총처리량이 중요할 수 있다. 같은 모델을 쓰더라도 두 업무에 같은 지연 목표를 강제할 이유는 없다. 먼저 업무별 허용 대기를 정한 뒤 그 조건을 만족하는 설정을 고른다.

스케줄링을 바꾼 뒤에도 결과의 근거와 누락 검사는 남는다. Chunked prefill은 지식이나 모델 가중치를 바꾸기 위한 기법이 아니지만, 실행 설정이 달라졌다는 이유로 출력의 동일성까지 가정할 수는 없다. 속도 시험과 함께 원문 근거, 부정과 예외 조건, 중단된 요청의 처리 여부를 확인한다. 더 많은 요청을 받았는데 취소와 재시도가 늘었다면 운영상 이득은 작을 수 있다.

호스팅 API를 사용하는 팀은 이런 내부 스케줄러를 직접 조절하지 못할 수도 있다. 그 경우 공급자가 chunked prefill을 쓴다고 추정하는 대신, 입력 길이와 동시 요청 수준별 응답 시간을 관찰하고 서비스의 공개된 제한을 확인한다. 직접 서버를 운영한다면 문서가 설명하는 기능이 설치한 버전과 모델에서 실제로 활성화됐는지부터 확인한다. 설정 이름의 존재와 실행 중 적용은 다른 증거다.

첫 실험을 준비할 때는 AX 실무 가이드의 업무 선정과 평가 사례집을 함께 참고할 수 있다. 짧은 질의와 긴 문서가 만나는 작은 시험을 만들고, 어느 요청의 어떤 기다림을 줄일지 적는 것부터 시작한다. LLM의 속도를 모델 하나의 특성으로만 보지 않으면, 모델 교체 전에 고칠 수 있는 요청 처리 방식이 드러난다.

참고 자료

• [1] Amey Agrawal 외, Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve, OSDI 2024. 프리필·디코드와 배칭은 2–3절, chunked prefill과 토큰 예산은 4.1–4.3절, 평가 범위는 5절을 기준으로 읽었다.
• [2] vLLM, Optimization and Tuning, 2026-09-15 확인. V1의 Chunked Prefill과 Preemption 설명을 사용했다. stable 문서는 갱신될 수 있으므로 실제 운영에서는 설치 버전과 지원 조건을 다시 확인해야 한다.