continuous batching: LLM 처리량을 높이는 원리와 지연 시간의 균형

연속 배칭(continuous batching)은 공유 GPU가 토큰 생성 단계 사이에 새 요청을 받아들이도록 하는 방식입니다. 덕분에 짧은 작업이 끝나고 남은 처리 자원을 긴 작업 때문에 놀리지 않아도 됩니다. 이 스케줄링 방식의 토대는 Yu 외 연구진이 2022년 OSDI에서 발표한 Orca 논문에 담겨 있습니다. 여러 요청이 동시에 들어올 때 서버 전체의 초당 토큰 처리량을 높일 수 있지만, 서버가 더 바쁘게 일한다고 해서 모든 사용자의 응답 속도가 빨라지는 것은 아닙니다.

공유 모델 서버에서 목표로 삼아야 할 것은 허용한 응답 시간 안에 더 많은 작업을 완료하는 것입니다. 지연 시간 목표가 빠진 처리량 그래프만으로는 서버가 쾌적하게 응대할 수 있는 고객 수를 알 수 없습니다.

아래에서 다루는 서버의 지원 기능과 제어 항목은 2026년 10월 25일 각 개발사의 당시 공식 문서를 기준으로 확인했습니다. 뒤에 나오는 스케줄링 예시는 원리를 설명하기 위한 것이며, 하드웨어 벤치마크가 아닙니다.

continuous batching은 어떻게 작동할까요?

연속 배칭은 토큰 생성이 진행되는 동안에도 실행 중인 요청 묶음을 바꿉니다. 완료된 요청은 빠지고, 스케줄러에 여유가 생기면 대기 중인 요청이 들어옵니다. 인플라이트 배칭(in-flight batching) 또는 *반복 단위 배칭(iteration-level batching)*이라고도 합니다.

대규모 언어 모델, 즉 LLM은 먼저 프리필(prefill) 단계에서 프롬프트를 처리한 뒤, 디코드(decode) 단계에서 이어질 내용을 생성합니다. 일반적인 자기회귀 디코딩에서는 실행 중인 각 요청이 생성 단계마다 텍스트 조각인 다음 토큰을 하나씩 만듭니다. 다음 단계에 어떤 요청을 참여시킬지는 스케줄러가 결정합니다. 각 단계에 대한 자세한 설명은 LLM 추론 가이드에서 확인할 수 있습니다.

여러 사람이 함께 쓰는 식탁을 떠올리면 이해하기 쉽습니다. 고정된 일행 단위로 손님을 받는다면, 지금 앉아 있는 사람들이 모두 식사를 마쳐야 다음 일행이 들어올 수 있습니다. 반면 빈자리가 생길 때마다 손님을 받는다면, 다른 사람이 식사 중이어도 새 손님이 앉을 수 있습니다. 식탁은 함께 쓰지만 각자의 식사는 따로 진행됩니다.

물론 이 비유만으로 모든 것을 설명할 수는 없습니다. GPU 스케줄러는 프롬프트 처리와 메모리 할당까지 고려해야 합니다. 빈 의자가 있다고 해서 대기 중인 모든 요청이 곧바로 들어올 수 있는 것은 아닙니다.

Orca 논문은 무엇을 바꿨을까요?

Orca는 요청 전체가 아니라 모델의 반복 실행 한 번을 스케줄링의 경계로 삼았습니다. Gyeong-In Yu 외 연구진의 OSDI 2022 논문은 실행 엔진을 호출해 모델을 한 차례 실행한 다음 배치 구성을 다시 판단하는 방식을 설명합니다.

함께 제안한 선택적 배칭(selective batching)은 일부 모델 연산을 배치로 묶으면서, 어텐션이 요청마다 서로 다른 이전 문맥을 참조할 수 있도록 합니다. 어텐션은 토큰을 그 앞의 문맥과 연결하는 연산입니다. 두 기법을 함께 쓰면 서빙 시스템이 길이가 다른 요청을 교차로 처리할 수 있습니다. 논문은 배치 크기와 사용 가능한 키-값 메모리도 스케줄링 제약으로 다룹니다. Orca 논문 읽기.

이 방식은 모델을 둘러싼 서빙 시스템을 바꾸는 것입니다. 모델이 하나의 대화에서 여러 사람에게 답하도록 새로 학습시킬 필요는 없습니다.

정적·동적·연속 배칭은 무엇이 다를까요?

핵심은 새 요청이 이미 진행 중인 작업에 언제 합류할 수 있느냐입니다. HTTP 연결을 동시에 받아들인다는 사실만으로 모델 실행에 연속 배칭을 사용한다고 볼 수는 없습니다.

NVIDIA의 Triton 배칭 문서는 배치 크기와 큐 대기 시간 제어를 포함해 일반적인 동적 배칭을 설명합니다. 이는 LLM이 토큰을 생성하는 도중에 배치 구성원을 교체하는 것과는 다른 스케줄링 문제입니다.

vLLM의 동적 배칭, 요청을 받아들이는 시점을 확인해야 합니다

LLM 서빙 엔진인 vLLM은 문서에서 연속 배칭을 지원한다고 명시합니다. 반면 ‘동적 배칭’이라는 명칭만으로는 정확한 방식을 알기 어렵습니다. Hugging Face도 연속 배칭 설명에서 생성 도중 처리가 끝난 프롬프트를 새 프롬프트로 교체하는 방식을 동적 스케줄링 또는 동적 배칭이라고 부릅니다. 명칭만 보고 판단하기보다, 엔진이 생성 단계 사이에 새 작업을 받아들이는지 확인해야 합니다.

스트리밍도 별개의 기능입니다. 서버는 실행 배치의 구성을 고정한 채로도 클라이언트에 토큰을 스트리밍할 수 있습니다. 여기서 다루는 이점은 완료된 요청이 내놓은 처리 자원을 새로 들어온 작업이 사용할 수 있다는 데 있습니다.

예시로 보는 요청 처리 순서

긴 작업이 계속 실행되는 동안에도 짧은 작업이 끝나면 활용할 수 있는 자원이 생깁니다. 디코드 슬롯이 두 개인 가상의 서버를 생각해 보겠습니다. 요청 A는 2단계, B는 4단계가 더 필요하고, 대기 중인 C는 2단계 분량의 작업을 해야 합니다. 이 예시에서는 프리필, 스케줄링 오버헤드, 단계별 소요 시간의 차이를 제외합니다.

구성원을 고정하는 방식에서는 A와 B가 함께 시작합니다. A가 먼저 끝나도 C는 B까지 완료된 뒤 다음 묶음이 시작될 때까지 기다립니다. 연속 배칭에서는 A가 끝난 자리에 C가 들어가 B와 나란히 작업을 진행할 수 있습니다.

이 예시는 새 요청을 더 일찍 받아들일 수 있음을 보여줄 뿐, 실측 속도 향상을 나타내지는 않습니다. 짧은 답변과 긴 요약 요청이 섞여 들어오는 고객 지원 챗봇에도 같은 스케줄링 기회가 있습니다. 실제 이득은 요청의 특성, 하드웨어, 서빙 설정에 따라 달라집니다.

처리량이 늘어나는 이유와 KV 캐시의 한계

배칭은 같은 양의 모델 가중치를 옮기는 동안 더 많은 유효 작업을 처리하게 합니다. 모델 가중치는 답을 계산하는 데 사용하는, 학습으로 얻은 수치 매개변수입니다. 같은 모델을 쓰는 여러 요청은 GPU 메모리에서 가중치를 가져오는 작업을 공유할 수 있어, 가용 연산 자원을 더 잘 활용하게 됩니다. 연속 스케줄링은 개별 요청이 끝나도 유용한 배치를 유지하도록 돕습니다. NVIDIA는 배칭, 메모리 이동, GPU 활용률의 관계를 설명합니다.

배치가 비효율적이어도 GPU는 계속 바쁘게 움직일 수 있습니다. 중요한 것은 활용률 그래프가 꽉 차 보이느냐가 아니라, 그 활동으로 실제 요청을 얼마나 유용하게 처리하느냐입니다.

다만 실행 중인 요청마다 작업용 메모리도 필요합니다. KV 캐시, 즉 키-값 캐시는 이미 처리한 토큰의 어텐션 상태를 저장합니다. 동시 요청이 늘고 문맥이 길어질수록 이 메모리에 부담이 커집니다. 이 상태 정보와 재사용 가능한 프롬프트 캐싱의 차이는 KV 캐시 설명에서 다룹니다.

PagedAttention은 메모리를 더 효율적으로 배치합니다

연속 배칭이 무엇을 실행할지 결정한다면, PagedAttention은 어텐션 상태를 저장하는 방식을 바꿉니다. Woosuk Kwon 외 연구진의 2023년 vLLM 논문은 KV 상태를 고정 크기 블록으로 나누고, 물리적으로 인접하지 않은 메모리에도 저장할 수 있게 하는 방식을 설명합니다. 블록 매핑은 시퀀스의 논리적 순서를 유지합니다.

이렇게 하면 단편화와 불필요한 복제로 낭비되는 메모리가 줄어듭니다. 메모리를 더 촘촘히 활용하면 더 많은 요청의 작업 데이터를 담을 수 있고, 스케줄러가 선택할 수 있는 유효 작업도 늘어납니다. 논문은 이 메모리 관리 방식이 Orca의 스케줄링 방식을 보완한다고 명시합니다.

물리적 용량의 한계는 여전히 남습니다. 더 효율적으로 배치한다고 해서 긴 대화를 무한히 담을 수는 없습니다. vLLM에서는 KV 공간이 부족하면 요청을 잠시 멈추고 나중에 그 상태를 다시 계산하는 **선점(preemption)**이 발생할 수 있습니다. 이로 인해 요청 완료까지의 지연 시간이 늘어날 수 있습니다. 자세한 동작은 최적화 문서에서 설명합니다.

지연 시간에는 어떤 영향을 줄까요?

연속 배칭은 큐에서 기다리는 시간을 줄일 수 있지만, 배치가 커지거나 요청이 몰리면 실행에 들어간 뒤의 체감 속도는 느려질 수 있습니다. 다음 지표를 나누어 살펴봐야 합니다.

• 첫 토큰까지의 시간(TTFT): 사용자가 출력이 시작될 때까지 기다리는 시간입니다.
• 토큰 간 지연 시간: 스트리밍이 시작된 뒤 토큰과 토큰 사이의 시간 간격입니다.
• 전체 지연 시간: 요청을 모두 처리하는 데 걸리는 시간입니다.

새 요청은 고정 배치 전체가 끝날 때까지 기다리지 않아도 됩니다. 하지만 새로 들어온 긴 프롬프트를 처리하는 작업은 이미 디코딩 중인 요청과 자원을 두고 경쟁할 수 있습니다. **청크 단위 프리필(chunked prefill)**은 프롬프트 처리를 작은 조각으로 나누어, 스케줄러가 진행 중인 생성 작업 사이에 끼워 넣을 수 있게 합니다.

예를 들어 vLLM 문서는 반복 실행당 토큰 예산에 따른 절충 관계를 설명합니다. 값을 작게 잡으면 토큰 간 지연 시간을 지키는 데 도움이 되고, 크게 잡으면 더 많은 프리필을 처리해 TTFT를 개선할 수 있습니다. 따라서 이 예산은 무조건 최대로 올릴 설정이 아니라, 워크로드에 맞춰 결정할 항목입니다. vLLM 튜닝 가이드.

LLM 연속 배칭은 부하가 낮거나 높을 때 어떻게 달라질까요?

부하가 낮으면 묶을 요청 자체가 적고, 과부하가 지속되면 여전히 큐가 쌓입니다. 요청을 한 번에 하나씩 보내는 개발자가 여러 요청이 겹치는 고객 대상 서비스와 같은 효과를 기대하기는 어렵습니다. 반대로 GPU가 감당할 수 있는 수준을 넘어 작업을 받아들이면 결국 대기 시간이 길어집니다.

사용자와 상호작용하는 애플리케이션에서는 중앙값과 함께 95번째 백분위수인 p95도 살펴봐야 합니다. 평균이 좋아도 일부 세션은 느릴 수 있습니다. 제품에서 허용할 수 있는 TTFT와 스트리밍 간격을 먼저 정한 다음, 그 범위 안에서 처리 용량을 측정해야 합니다.

연속 배칭을 지원하는 LLM 서버와 제약 사항

아래 네 서버는 모두 문서에서 연속 배칭 또는 인플라이트 배칭을 지원한다고 밝힙니다. 같은 기능을 지원하더라도 스케줄러, 메모리 예산, 지원 모델까지 서로 같다는 뜻은 아닙니다.

vLLM continuous batching

vLLM은 연속적인 요청 스케줄링과 페이지 단위 KV 캐시 관리를 결합합니다. 문서에서도 두 기능을 명시적으로 나열합니다. 운영자가 살펴볼 제어 항목은 단순히 원하는 동시 API 연결 수가 아니라, 최대 시퀀스 수와 반복 실행마다 스케줄링할 토큰 수입니다.

한계는 메모리 압박입니다. 동시 요청 수를 늘려도 실제로 활용할 수 있는 용량이 늘어나는 대신 선점과 재계산이 발생할 수 있습니다. 실제 트래픽 구성과 지연 시간 목표에 맞춰 튜닝하고, 설정을 비교할 때는 모델과 하드웨어를 고정해야 합니다.

SGLang

SGLang은 연속 배칭을 지원하며, 요청 수용을 명시적으로 제어하는 설정을 제공합니다. 서버 인자 문서에는 --max-running-requests, --chunked-prefill-size, 그리고 --mem-fraction-static으로 제어하는 모델 가중치·KV 풀 예산이 정의되어 있습니다.

이 설정들은 각각 다른 문제를 다룹니다. 동시에 실행할 수 있는 요청 수, 한 청크에 넣을 프롬프트 작업량, 메모리 할당 방식입니다. 요청 수 제한을 높인다고 해서 다른 제약까지 사라지지는 않습니다. 엔진 선택 전반은 vLLM과 SGLang 비교를 참고하고, 실제로 서비스할 모델과 요청 구성을 기준으로 평가해야 합니다.

NVIDIA TensorRT-LLM

NVIDIA TensorRT-LLM은 인플라이트 배칭을 연속 배칭 및 반복 단위 배칭과 같은 의미로 명시합니다. 기능 문서에서는 컨텍스트 단계와 생성 단계의 시퀀스를 함께 처리하는 방식을 설명하며, 문서에 나온 구현은 패킹된 입력 텐서를 사용합니다.

요청 수 제한과 토큰 예산은 별개의 제약입니다. PyTorch 스케줄러 문서에서도 KV 용량을 포함한 자원을 확보하는 일과, 용량 안에 들어오는 요청 중 무엇을 실행할지 선택하는 일을 구분합니다. 인플라이트 스케줄러도 용량 검사를 통과하지 못한 작업은 받아들일 수 없습니다.

Hugging Face Text Generation Inference

Hugging Face Text Generation Inference는 연속 배칭을 지원하지만, 새 배포를 검토한다면 현재의 유지보수 상태를 고려해야 합니다. 문서에 따르면 지금은 소규모 수정, 문서 개선, 가벼운 유지보수를 받는 단계이며, 앞으로는 vLLM과 SGLang을 비롯한 다운스트림 엔진을 사용할 것을 권장합니다.

이 상태가 되었다고 해서 기존 TGI 설치의 배칭 기능이 사라지는 것은 아닙니다. 새 서빙 스택을 고른다면 저는 활발히 개발 중인 대안부터 평가하겠습니다. 이미 목표를 충족하는 배포 환경이라면, 구체적으로 필요한 지원이나 기능에 맞춰 마이그레이션을 계획하는 편이 좋습니다.

연속 배칭에 대한 과장된 기대

연속 배칭에 어디서나 통하는 속도 향상 배수를 붙일 수는 없습니다. Orca와 PagedAttention 논문은 특정 시스템과 워크로드를 평가합니다. 그 결과에서 임의의 모델, GPU, 제공업체 엔드포인트에 그대로 적용할 수 있는 보편적인 개선치를 떼어 낼 수는 없습니다.

대기 시간도 사라지지 않습니다. 큐에 들어간 요청에는 여전히 프롬프트 처리와 메모리가 필요하며, 스케줄러 정책에 따라 차례를 기다려야 합니다. 긴 프롬프트, 높은 동시 수요, 캐시 압박은 계속 한계로 작용합니다.

마지막으로 전체 토큰 처리 속도가 높아졌다는 사실만으로 채팅 제품이 개선되었다고 볼 수는 없습니다. 사용자가 첫 토큰을 더 오래 기다리거나 스트리밍 도중 불편한 끊김을 겪는다면, 늘어난 서버 처리량은 제품에서 허용할 수 있는 운영 범위를 벗어난 것일 수 있습니다.

실제 운영에서는 무엇부터 바꿔야 할까요?

개발자는 요청이 겹칠 때 공유 서빙을 검토하고, 운영자는 지연 시간 한도 안에서 튜닝하며, 제공업체를 평가하는 담당자는 자원 경합 상황의 측정값을 요구해야 합니다. 가끔 요청을 보내는 개인용 도구라면 당장 바꿀 필요는 없습니다. 반면 고객이 대기하고 응답 길이도 제각각인 서비스라면 행동에 나설 구체적인 이유가 있습니다. 로컬 사용에서 공유 서빙으로 넘어가는 과정은 Ollama와 vLLM 비교에서 다룹니다.

1. 1

   동시 요청 수를 늘리기 전에 사용자 경험의 기준을 정합니다

   실제 워크플로에서 허용할 수 있는 첫 토큰까지의 시간, 스트리밍 간격, 완료 시간을 적어 둡니다. 백그라운드 요약기와 실시간 고객 지원 어시스턴트에는 서로 다른 허용 기준이 필요합니다.

2. 2

   실제 사용을 대표하는 요청 구성을 재현합니다

   모델, 하드웨어, 프롬프트 길이, 출력 제한, 캐시 조건을 서로 비교할 수 있게 맞춥니다. 짧은 답변, 긴 프롬프트, 긴 생성 작업을 모두 포함합니다. 실제와 비슷한 요청 도착 패턴을 유지해야, 한 명이 한가하게 사용하는 테스트로 바쁜 서비스의 성능을 대신 판단하는 일을 피할 수 있습니다.

3. 3

   처리량과 함께 큐 상태와 지연 시간을 기록합니다

   전체 출력의 초당 토큰 수, 완료된 요청, 대기 중인 요청, 실패, TTFT, 토큰 간격을 측정합니다. vLLM은 운영 환경 메트릭 문서에서 vllm:num_requests_waiting, vllm:time_to_first_token_seconds, vllm:inter_token_latency_seconds를 비롯한 관련 메트릭을 제공합니다.

4. 4

   목표를 충족하는 최대 부하를 운영 기준으로 삼습니다

   스케줄링 또는 메모리 설정은 한 번에 하나씩 바꿉니다. 지연 시간 한도를 넘거나 메모리 압박으로 재계산이 반복되면 동시 요청 수를 더 늘리지 않습니다. 제공업체에도 예상 동시 요청 수에서의 처리량과 지연 시간을 같은 방식으로 요청하고, 해당 용량이 공유인지 예약인지 함께 확인합니다.

최종적으로 확보해야 할 것은 측정으로 확인한 운영 한계입니다. 의도한 사용자 경험을 유지하면서 엔드포인트가 감당할 수 있는 워크로드가 얼마인지 알아야 합니다. 그래야 배칭이라는 기능을 실제 배포 판단의 근거로 삼을 수 있습니다.

AI 인프라를 실무 관점에서 이해하고 스택에서 무엇을 바꿔야 할지 알고 싶다면 뉴스레터를 구독하세요.