LLM 확장의 핵심 연속 배칭 — 초당 수백 요청을 처리하는 배치 전략

핵심 메시지

• LLM은 시퀀스 디코딩에 수 초가 걸려, 요청을 단순히 대기열에 넣는 일반 머신러닝 방식으로는 초당 수백 요청을 감당하기 어렵다.
• 나이브 배칭은 요청들을 한 번 묶어 패딩한 뒤 함께 디코딩하는데, 먼저 끝난 시퀀스도 나머지가 끝날 때까지 기다려야 해 비효율적이다.
• 새로 들어온 요청은 현재 배치가 모두 끝날 때까지 유휴 상태로 대기하게 되어 사용자 경험이 나빠진다.
• 연속 배칭은 디코딩을 처음에 한 번만 묶지 않고 매 반복마다 다시 묶어, 끝난 시퀀스는 즉시 반환하고 새 요청은 바로 합류시킨다.
• 텍스트 생성 응답을 다루는 다중 요청 애플리케이션이라면 배치 방식과 디코딩 방식을 영리하게 설계해야 하며, 연속 배칭이 유효한 전략이다.

쉽게 이해하기

이 영상은 대규모 언어 모델(LLM) 서비스를 운영할 때 여러 요청을 어떻게 처리할지가 왜 중요한지를 설명한다. 일반적인 머신러닝 모델에서는 추론 서버가 빌 때까지 요청을 대기열에 넣어 기다리게 해도 괜찮다. 하지만 LLM은 한 요청을 처리하는 데 수 초가 걸릴 수 있어, 같은 방식으로는 초당 수백 건의 요청으로 확장하기 어렵다.

LLM이 다른 모델과 크게 다른 점은 시퀀스를 디코딩하기까지의 큰 지연이다. 여러 사용자가 같은 서버에 동시에 요청을 보내고, 입력 프롬프트는 길이도 도착 시각도 제각각이다. 이런 요청들을 사용자 경험을 해치지 않으면서 처리하는 일반적인 방법이 여러 요청을 함께 묶는 배칭이다.

먼저 나이브 배칭을 보자. 사용자 A·B·C의 요청이 각각 토큰 수가 다르다고 하면, 함께 입력하기 위해 길이를 맞추는 패딩이 필요하다. 묶어서 디코딩하면 각 프롬프트가 매 단계마다 출력 토큰 하나씩을 내고, 이를 원래 입력에 이어 붙이며 자기회귀적으로 디코딩을 계속한다. 그런데 어느 시퀀스가 먼저 종료 토큰(EOS)을 만들어도, 나머지 A·B가 끝날 때까지 기다려야 한다.

더 큰 문제는 세 번째 반복에서 사용자 D의 새 요청이 들어와도, 현재 배치가 끝나지 않았기 때문에 그저 유휴 상태로 대기해야 한다는 점이다. 즉 모든 시퀀스가 디코딩을 마쳐야 응답을 줄 수 있고, 새로 들어오는 요청들은 현재 배치가 끝나기만 기다린다. 매우 비효율적이다.

연속 배칭은 이를 해결한다. 원리는 단순하다. 디코딩 시작 시점에 한 번만 묶는 것이 아니라 매 반복마다 다시 묶는 것이다. B의 디코딩이 진행되는 중에 A·C 요청이 새로 들어오면, B가 끝나길 기다리지 않고 다시 배치를 구성해 A·C의 디코딩을 함께 시작한다. 어떤 시퀀스가 종료 토큰을 내면 그 시퀀스는 즉시 클라이언트로 보내고 나머지만 다시 묶어 계속한다. 그래서 끝난 요청도, 새로 온 요청도 불필요하게 대기하지 않는다.

주요 인사이트

• LLM 확장의 병목은 연산량 자체보다, 시퀀스 디코딩에 걸리는 큰 지연과 그로 인한 유휴 대기 시간이다.
• 나이브 배칭의 근본 한계는 '한 번 묶으면 전부 끝날 때까지 고정'이라는 점이다. 길이가 다른 시퀀스가 섞이면 먼저 끝난 자리가 낭비된다.
• 연속 배칭의 핵심 아이디어는 배치를 고정된 단위가 아니라 매 반복마다 갱신되는 동적 집합으로 다루는 것이다.
• 끝난 시퀀스를 즉시 반환하고 빈자리에 새 요청을 채우는 방식은 처리량과 응답성을 동시에 끌어올린다.
• 텍스트 생성형 다중 요청 서비스를 만든다면 배치·디코딩 전략이 사용자 경험을 좌우하는 설계 결정이 된다.

자주 묻는 질문

관련 AI 소식