정적 배치를 고수하며 GPU 자원을 낭비하는 팀과 비동기 연속 배치를 활용해 인프라 효율을 극대화하는 팀의 서버 운영 비용은 시간이 갈수록 기하급수적으로 벌어진다. 단순히 고성능 하드웨어를 도입하는 것보다 추론 엔진 내부의 스케줄링 메커니즘을 이해하고 최적화하는 개발자가 내놓는 결과물은 응답 속도와 처리량 측면에서 차원이 다른 사용자 경험을 제공한다.
정적 배치의 한계와 연속 배치의 탄생 배경
전통적인 딥러닝 모델의 추론은 고정된 크기의 입력을 처리하는 방식이었다. 하지만 거대 언어 모델(LLM)은 입력과 출력의 길이가 매번 다르다는 특수성을 가진다. 과거의 정적 배치(Static Batching) 방식에서는 배치 내의 여러 요청 중 가장 긴 응답이 완료될 때까지 나머지 요청들이 GPU 메모리를 점유한 채 대기해야 했다. 이는 곧 자원의 유휴 시간 발생으로 이어졌으며, 특히 생성형 AI처럼 토큰을 하나씩 생성하는 구조에서는 치명적인 비효율을 초래했다.
이러한 문제를 해결하기 위해 등장한 것이 연속 배치(Continuous Batching)다. 이 기술은 전체 배치가 끝날 때까지 기다리는 대신, 특정 요청의 생성이 완료되는 즉시 새로운 요청을 그 자리에 끼워 넣는 '반복 수준 스케줄링(Iteration-level scheduling)'을 핵심으로 한다. 이를 통해 GPU는 단 한 순간도 쉬지 않고 토큰을 생성할 수 있게 되었으며, 이는 초기 LLM 서비스의 처리량을 비약적으로 상승시키는 계기가 되었다.
비동기 엔진의 내부 아키텍처와 작동 원리
연속 배치가 도입된 이후에도 한 가지 병목이 남아 있었다. 바로 스케줄링과 모델 실행이 동기적으로 맞물려 돌아간다는 점이었다. 기존 구조에서는 모델이 다음 토큰을 계산하는 동안 스케줄러가 새로운 요청을 준비하거나 큐를 관리하는 작업을 수행하기 어려웠다. 최근의 비동기 연속 배치(Asynchronous Continuous Batching) 아키텍처는 이 과정을 완전히 분리하여 스케줄링 루프와 모델 실행 루프를 병렬화한다.
내부적으로는 '프리필(Prefill)' 단계와 '디코딩(Decoding)' 단계를 세밀하게 제어한다. 프리필은 입력 텍스트를 처리하여 KV 캐시를 생성하는 과정으로 연산 집약적이며, 디코딩은 토큰을 하나씩 생성하는 과정으로 메모리 대역폭에 의존적이다. 비동기 엔진은 모델이 현재 배치의 디코딩을 수행하는 동안 백그라운드에서 다음 배치의 프리필을 준비하거나, 대기 중인 요청의 우선순위를 재조정한다. 이러한 비동기적 흐름은 스케줄링 오버헤드가 전체 추론 시간에 미치는 영향을 최소화하며, 특히 요청이 폭주하는 상황에서 시스템의 안정성을 유지하는 중추적인 역할을 한다.
데이터로 증명된 성능 향상과 현실적인 트레이드오프
비동기 연속 배치의 위력은 수치로 명확히 드러난다. 정적 배치와 비교했을 때, 연속 배치는 동일한 하드웨어 자원에서 처리량(Throughput)을 최대 10배에서 20배까지 끌어올릴 수 있다 (출처: vLLM 연구 논문 및 Hugging Face 기술 블로그). 특히 다수의 사용자가 동시에 접속하는 환경에서 그 차이는 더욱 극명해진다.
| 지표 | 정적 배치 (Static) | 비동기 연속 배치 (Async Continuous) |
|---|---|---|
| GPU 활용률 | 낮음 (대기 시간 발생) | 매우 높음 (지속적인 연산) |
| 처리량 (Throughput) | 기준점 (1x) | 최대 10x~23x (출처: Hugging Face Blog) |
| 첫 토큰 지연 시간 (TTFT) | 배치 크기에 비례하여 증가 | 스케줄링 우선순위에 따라 가변적 |
| 메모리 관리 | 단순 (고정 할당) | 복잡 (동적 KV 캐시 관리 필요) |
하지만 모든 기술이 그렇듯 비용 없는 개선은 없다. 비동기 연속 배치는 복잡한 KV 캐시 관리 로직을 필요로 하며, 이는 메모리 단편화(Fragmentation) 문제를 야기할 수 있다. 또한, 스케줄링 오버헤드가 약 1~2ms 정도 발생할 수 있는데, 이는 단일 요청 처리 시에는 무시할 수 없는 비율일 수 있으나 대규모 트래픽 상황에서는 전체 처리량 이득에 비해 미미한 수준이다 (출처: Hugging Face Blog).
도입 의사결정을 위한 전략적 프레임워크
단순히 '최신 기술이니까'라는 이유로 비동기 연속 배치를 도입하는 것은 위험하다. 서비스의 특성에 따라 최적의 선택지는 달라질 수 있다. 만약 내부 직원용으로 소수의 인원만 사용하는 툴이거나, 실시간 응답성보다 단일 긴 문서의 요약 성능이 중요하다면 복잡한 비동기 스케줄러보다는 단순한 추론 파이프라인이 더 관리하기 편하고 안정적일 수 있다.
반면, 수천 명 이상의 동시 접속자를 처리해야 하는 B2C 서비스나 API 제공업체라면 비동기 연속 배치는 선택이 아닌 필수다. 이때 개발자는 단순히 엔진을 실행하는 것에 그치지 않고, 최대 배치 크기(Max Batch Size)와 KV 캐시 점유율을 모니터링하며 시스템의 임계치를 파악해야 한다. 시스템의 처리량이 한계에 도달하면 비동기 스케줄러조차도 지연 시간을 제어하기 어려워지기 때문이다.
결국 기술의 정점은 도구의 화려함이 아니라 상황에 맞는 적절한 도구를 골라내는 안목에 있다. 지금 운영 중인 LLM 서비스의 GPU 사용률이 50% 미만에서 맴돌고 있다면, 하드웨어를 증설하기 전에 추론 엔진의 비동기성 설정을 먼저 점검해 보길 권한다.
참고: Hugging Face Blog