연속 배치 처리는 대형 모델의 서버 측에서 사용되는 동적 스케줄링 방법으로, 시스템은 같은 배치 내 모든 요청이 생성될 때까지 다음 배치를 교체하기 전에 기다릴 필요가 없습니다; 대신 각 생성 단계가 끝난 후 완료된 요청을 제거하고 새로운 요청을 추가합니다. 주로 GPU 활용도와 전체 처리량을 개선하며, 여러 사람이 동시에 모델을 호출할 때 서비스 효율성을 목표로 합니다.
왜 정적 배치 처리가 빈 대기 현상에 빠지는지
전통적인 배치 프로세서는 먼저 요청 집합을 조립한 후 함께 실행합니다. 하지만 생성 작업의 입력과 출력 길이는 매우 다양합니다: 어떤 것은 수십 개의 토큰만으로 응답하고, 어떤 것은 수백 단계를 거쳐야 합니다. 짧은 요청이 완료된 후에는 위치가 비어 있을 수 있으며, 이후 요청은 전체 배치가 끝날 때까지 대기할 수 있습니다.
연속 배치 처리는 스케줄링 세분성을 "완전한 요청"에서 "현재 생성 반복"으로 좁힙니다. 토큰 생성 라운드마다 스케줄러는 종료된 시퀀스와 입력 가능한 시퀀스를 검토한 후 함께 다음 배치를 만듭니다. 배치 멤버는 지속적으로 변경되기 때문에 이를 반복적 스케줄링 또는 동적 배치 처리라고 부릅니다.
한 번의 디스패치는 세 가지 작업을 동시에 처리해야 합니다
- 처리량: 더 많은 요청이 함께 진행될 수 있도록 사용 가능한 컴퓨팅 자원을 채우려고 노력하세요.
- 지연: 단순히 대규모 배치를 기다리는 것이 아니라, 이미 도착한 사용자들을 긴 줄에 서게 만드는 문제입니다.
- 비디오 메모리: 각 활성 시퀀스는 컨텍스트 상태를 유지해야 합니다. 배치가 클수록 KV 캐시에 대한 메모리 부담이 높아집니다.
따라서 배치 제한이 항상 더 나은 것은 아닙니다. 서비스 프레임워크는 또한 다양한 길이의 폐기물 채우기, 선점 전략, 우선순위 설정, 공정성, 그리고 다양한 컴퓨팅 파워 요구가 필요한 입력 프리패딩 및 토큰별 토큰 디코딩을 다룹니다.
사용자들은 어떤 감정을 느낄까요?
동시 및 안정적인 온라인 서비스에서는 연속 배치 처리가 대기 빈틈을 줄여 더 많은 사용자가 동일한 GPU 세트를 지원할 수 있게 합니다. 하지만 처리량이 증가한다고 해서 모든 요청이 더 빠르다는 의미는 아닙니다: 스케줄러가 과부하 조건을 추구하면 낮은 우선순위 요청이 더 오래 기다릴 수 있고, 단일 요청 지연 시간이 증가할 수도 있습니다.
평가 시 첫 번째 토큰의 지연, 이후 토큰 간격, 초당 총 토큰 수, 그리고 높은 랭크 지연 시간을 별도로 관찰해야 합니다. 저동시성 개인 로컬 배포는 동적 배치를 거의 생성하지 못해 이점이 제한될 수 있습니다; API, 채팅 플랫폼, 다중 테넌트 추론 클러스터 등 핵심 인프라가 비용과 경험을 결정합니다.
