AI 용어집 · 심화 · 효율·인프라
연속 배칭 Continuous Batching
연속 배칭은 여러 사용자 요청을 묶어 GPU에서 함께 처리하되, 끝난 요청은 바로 빼고 기다리던 요청은 바로 끼워 넣어 GPU가 쉬지 않게 하는 서빙 기법이다.
어떻게 작동하나
LLM은 답을 토큰 하나씩 만드는데, 요청마다 답 길이가 제각각이다. 예전 방식(정적 배칭)은 묶은 요청 가운데 가장 긴 답이 끝날 때까지, 일찍 끝난 요청의 자리가 비어 있어도 새 요청을 받지 않았다. 연속 배칭은 토큰을 한 번 만들 때마다 묶음을 다시 짠다. 끝난 요청은 곧바로 결과를 돌려주고, 대기 중인 요청이 그 빈자리를 채운다. 그래서 반복(iteration) 단위 스케줄링이라고도 부른다.
정적 배칭 vs 연속 배칭
정적 배칭묶음 단위로 교체
- 가장 긴 답이 끝날 때까지 대기
- 끝난 자리는 빈 채로 남음
- 새 요청은 다음 묶음까지 기다림
연속 배칭토큰 단위로 교체
- 끝난 요청은 바로 빠짐
- 대기 요청이 바로 합류
- GPU가 쉬는 시간이 적음
공통 둘 다 여러 요청을 함께 계산해 GPU를 효율적으로 쓰려는 방법이다
왜 중요한가
GPU가 노는 시간이 줄어 같은 GPU로 훨씬 많은 사용자를 받을 수 있다. 처리량이 늘어나니 토큰 하나를 만드는 원가도 내려간다. 새 요청이 앞 묶음이 끝나기를 기다리지 않아도 되므로 TTFT도 대개 나아진다. 이런 이유로 vLLM, SGLang, TensorRT-LLM 같은 주요 추론 엔진이 기본으로 쓴다.
알아 둘 점
직접 켜고 끌 일은 드물고, 추론 엔진 설정에서 한 번에 함께 처리할 최대 요청 수나 최대 배치 토큰 수 같은 값으로 만난다. 이 값을 크게 잡으면 서버 전체 처리량은 늘지만, 사용자 한 명이 느끼는 토큰 생성 속도는 느려질 수 있다. 함께 처리하는 요청이 많을수록 KV 캐시 메모리도 더 필요해서 페이지드 어텐션 같은 메모리 관리 기법과 짝을 이룬다. 아주 긴 프롬프트가 들어오면 다른 요청의 생성이 잠시 밀릴 수 있어, 긴 입력을 조각내 처리하는 chunked prefill 같은 보완책을 함께 쓴다.
예시
고객 상담 챗봇을 운영하는 팀이 점심시간마다 응답이 밀린다는 불만을 받았다고 하자. 팀은 vLLM 설정에서 동시에 처리할 최대 요청 수를 조금씩 올려 가며 서버 처리량과 사용자별 응답 속도, TTFT를 함께 잰다. 처리량은 늘지만 한 명이 느끼는 속도가 목표보다 떨어지는 지점이 보이면, 그 직전 값으로 정하고 남는 수요는 GPU를 한 대 더 두는 쪽으로 해결한다.
이 사이트에서 나온 사례
- 논문 TokenRouter: 토큰 단위 LLM 라우팅을 위한 효율적 서빙 시스템 2026-10-10