연속 배칭

LLM 서버가 여러 요청을 묶어 처리하다가 하나가 끝나는 즉시 그 자리에 대기 중인 새 요청을 넣는 스케줄링 방식이다. 배치 전체가 끝날 때까지 기다리는 정적 배칭과 달리 GPU를 쉬지 않게 해, 길이가 제각각인 요청이 몰리는 챗봇·API 서비스에서 처리량을 크게 높일 때 쓴다.

vLLM, TGI 같은 요즘 LLM 서빙 프레임워크는 대부분 이 방식을 기본으로 쓴다.

긴 요청 하나가 배치 전체를 붙잡는다

LLM은 답을 토큰 하나씩 만들고, 요청마다 답 길이가 다르다. 정적 배칭에서는 한 줄짜리 답이 일찍 끝나도 긴 답이 끝날 때까지 새 요청을 못 받는다. 그동안 GPU 일부는 놀고, 뒤에 줄 선 요청은 계속 기다린다.

연속 배칭은 토큰 한 단계를 만들 때마다 배치 구성을 다시 짠다. 그래서 iteration-level 스케줄링이라고도 부른다. 이 아이디어는 Orca 논문에서 처음 체계적으로 제안됐다.

vLLM에서는 켜져 있고, 한도만 조절한다

vLLM은 따로 켜지 않아도 연속 배칭으로 돈다. 사용자는 한 번에 얼마나 많이 묶을지 상한만 정하면 된다.

많은 사용자를 받는 챗봇이라면 동시 요청 수를 넉넉히 두고, 응답 속도가 중요한 단일 사용자 도구라면 낮게 두는 식으로 맞춘다.

효과는 요청이 몰리고 길이가 섞일 때 크다

동시에 들어오는 요청이 많고 답 길이가 제각각일수록 효과가 크다. 반대로 요청이 거의 없는 개인용 서버에서는 묶을 게 없으니 차이가 작다. 길이가 비슷한 문서를 한꺼번에 처리하는 일괄 작업도 정적 배칭과 큰 차이가 나지 않는다.

메모리와 지연 시간은 따로 챙겨야 한다

요청을 많이 묶을수록 요청마다 KV 캐시 메모리가 필요하다. 메모리가 부족하면 일부 요청을 잠시 빼거나 다시 계산하게 된다. vLLM이 PagedAttention으로 KV 캐시를 잘게 나눠 관리하는 것도 연속 배칭을 메모리 낭비 없이 돌리기 위해서다.

처리량이 오르는 대신, 배치가 꽉 찰수록 요청 하나가 토큰을 받는 속도는 느려질 수 있다. 긴 프롬프트가 새로 들어오면 그 입력을 처리하는 동안 다른 요청의 생성이 잠깐 밀리기도 한다. 이를 줄이려고 긴 입력을 잘게 나눠 넣는 chunked prefill을 함께 쓰는 경우가 많다.

직접 모델을 띄우면 이미 쓰고 있다

연속 배칭은 따로 구현하는 기법이라기보다 서빙 프레임워크에 기본으로 들어 있는 기능이다. 사용자는 어떤 장면에서 요청이 몰리는지 보고 동시 처리 한도만 맞추면 된다.