지속적인 배치에서 비동기성 풀기

연속 배칭(Continuous Batching)은 LLM 서빙에서 GPU 활용률을 극대화하기 위한 핵심 기법으로, 정적 배칭과 달리 요청이 도착하는 즉시 실행 중인 배치에 동적으로 합류시키고, 완료된 요청은 즉시 빠져나가게 하는 방식이다. vLLM, TGI, TensorRT-LLM 같은 추론 엔진에서 표준으로 채택되어 있으며, 토큰 생성 단계(decode)마다 배치 구성을 재조정한다. 그러나 기존 구현은 본질적으로 "동기적(synchronous)"인 부분이 남아 있다. 예를 들어 새 요청의 프리필(prefill) 단계가 진행 중인 디코드 배치를 블로킹하거나, 토크나이저·디토크나이저·샘플링 후처리·KV 캐시 관리 같은 CPU 작업이 GPU 스텝과 직렬로 묶여 GPU가 대기하는 "버블"이 생긴다. 이 글의 주제인 비동기성(asynchronicity) 해제는 바로 이러한 CPU-GPU, 프리필-디코드, 스케줄링-실행 간의 직렬 의존성을 깨뜨려 파이프라인을 중첩(overlap)시키는 최적화를 의미한다.

기술적으로는 스케줄러 스레드와 모델 실행 스레드를 분리해 다음 스텝의 배치 구성을 현재 스텝의 GPU 연산과 병렬로 준비하고, 샘플링 결과의 디토크나이즈·전송·로그프롭 계산을 별도 워커로 떼어내며, 청크드 프리필(chunked prefill)을 통해 긴 프롬프트를 작은 단위로 쪼개 디코드와 인터리빙하는 방식이 결합된다. 더 나아가 CUDA 그래프, 비동기 KV 캐시 복사, 스트리밍 출력 큐 등이 함께 동작하면 GPU는 SM(Streaming Multiprocessor)이 거의 항상 일하는 상태로 유지된다. 실제 측정 결과로는 동일 하드웨어에서 처리량(throughput)이 20~50% 증가하고, TTFT(Time To First Token)와 TPOT(Time Per Output Token) 같은 지연 지표가 함께 개선되는 보고가 많다. 이는 곧 동일한 GPU 비용으로 더 많은 사용자에게 LLM 서비스를 제공할 수 있고, 특히 한국처럼 GPU 수급이 빠듯한 환경에서 인프라 비용을 직접적으로 절감하는 효과로 이어진다.

엔지니어 입장에서 가장 중요한 실무적 의미는 "추론 엔진 버전 업데이트가 곧 비용 절감"이라는 점이다. vLLM 0.6 이후 도입된 비동기 스케줄러나 멀티스텝 스케줄링, SGLang의 zero-overhead 배처, TensorRT-LLM의 in-flight batching 개선 등은 모두 같은 방향의 최적화이므로, 자체 호스팅 LLM을 운영 중이라면 정기적인 엔진 업그레이드와 벤치마크가 필수다. 또한 청크드 프리필 활성화 여부, max-num-batched-tokens 같은 스케줄러 파라미터, 토크나이저를 별도 프로세스로 분리하는 옵션 등 비동기 동작을 결정짓는 설정값들을 워크로드(짧은 챗 vs. 긴 문서 RAG)에 맞게 튜닝해야 효과를 제대로 누릴 수 있다.

애플리케이션 개발자도 알아둘 점이 있다. 비동기 파이프라인에서는 스트리밍 응답의 토큰 도착 패턴이 더 균일해지지만, 첫 토큰 지연과 중간 지연의 트레이드오프가 설정에 따라 달라질 수 있어 SSE/WebSocket 클라이언트의 타임아웃과 백프레셔 설계를 재검토할 필요가 있다. 관측성 측면에서는 GPU 활용률뿐 아니라 스케줄러 큐 길이, 프리필/디코드 비율, 배치 사이즈 분포를 함께 수집해야 병목을 정확히 진단할 수 있다. 마지막으로 자체 모델 서빙 대신 OpenAI·Anthropic 같은 상용 API를 쓰는 팀이라도 이 흐름은 무관하지 않다. 상용 API의 단가 인하와 지연 개선의 상당 부분이 이러한 서빙 레이어 최적화에서 나오므로, 가격·속도 변화 시점을 모니터링해 캐싱 전략과 모델 라우팅 정책을 주기적으로 재평가하는 것이 좋다.