LLM 추론 서버의 평균 tokens/sec는 괜찮아 보이는데, 실제 트래픽에서는 지연 시간이 튀고 GPU 사용률 그래프에는 빈틈이 보인다. 큐는 쌓이는데 GPU가 항상 바쁜 것도 아니다. 이때 문제는 모델이 느린 것이 아니라, 서버가 "어디서 기다릴지"를 잘못 정했기 때문일 수 있다.
최근 Hugging Face는 continuous batching에서 CPU와 GPU 작업을 분리해 겹쳐 실행하는 비동기 batching 구현과 분석을 공개했다. 핵심은 더 똑똑한 배치 크기 조절이 아니다. 배치 N을 GPU가 계산하는 동안 CPU가 배치 N+1을 준비하게 만들어, 추론 루프의 대기 위치를 바꾸는 것이다.1
문제는 배치가 아니라 CPU-GPU 교대 근무다
Continuous batching은 이미 정적 batching의 큰 낭비를 줄인다. LLM 응답 길이는 제각각이므로, 짧은 요청이 긴 요청을 기다리게 두면 GPU 슬롯이 낭비된다. Continuous batching은 시퀀스가 끝나는 즉시 새 요청을 넣어 token 단위로 배치를 재구성한다. BentoML도 이를 "in-flight batching"으로 설명하며, 정적·동적 batching과 달리 짧은 요청이 가장 긴 요청 종료까지 붙잡히지 않는다고 정리한다.2
하지만 여기에는 숨은 병목이 남아 있다. 일반적인 synchronous continuous batching에서는 CPU와 GPU가 번갈아 일한다. CPU는 요청 선택, KV cache 테이블 갱신, 완료 요청 제거, 새 요청 투입, 샘플링 결과 반영을 처리한다. 그다음 GPU가 forward pass를 실행한다. GPU가 끝나면 다시 CPU가 상태를 갱신한다.
Hugging Face의 프로파일링 예시에서는 8B 모델, batch size 32로 8K 토큰을 생성할 때 전체 300.6초 중 24.0%가 GPU가 CPU를 기다리는 시간으로 나타났다.1 이 수치는 모든 환경에 일반화할 수 있는 절대값은 아니다. 모델 크기, 샘플링 방식, 서버 구현, CPU 성능, KV cache 관리 방식에 따라 달라진다. 그러나 해석은 분명하다. continuous batching을 도입했는데도 GPU timeline에 규칙적인 빈칸이 보인다면, 다음 병목은 "얼마나 큰 배치를 만들 것인가"가 아니라 "누가 누구를 기다리는가"일 가능성이 크다.
비동기화는 처리량을 사지만, 단순성을 판다
Asynchronous continuous batching의 아이디어는 단순하다. GPU가 현재 배치를 계산하는 동안 CPU가 다음 배치의 스케줄링과 상태 갱신을 준비한다. 이를 위해 CUDA stream 같은 메커니즘으로 GPU 작업을 큐잉하고, CPU가 즉시 다음 일을 할 수 있게 만든다. 같은 stream 안의 작업은 순차 실행되지만, 다른 stream의 작업은 독립적으로 실행될 수 있다.1
실무적으로 이 변화는 "더 빠른 커널"보다 "더 나은 조율"에 가깝다. 모델 가중치나 attention 알고리즘을 바꾸지 않아도, CPU launch overhead와 스케줄링 시간을 GPU 계산과 겹치게 만들 수 있다.
다만 공짜는 아니다. 동기 방식은 느릴 수 있지만 이해하기 쉽다. 한 스텝이 끝난 뒤 상태를 보고 다음 결정을 내리면 된다. 비동기 방식은 아직 끝나지 않은 GPU 작업, 곧 필요해질 CPU 상태, 취소된 요청, 스트리밍 응답, KV cache 점유 상태가 서로 엇갈린다. 디버깅도 어려워진다. 평균 처리량은 좋아졌는데 특정 tenant의 p99가 나빠지거나, 긴 출력 요청이 짧은 요청을 밀어내는 현상이 더 선명하게 드러날 수 있다.
즉, 비동기 continuous batching은 "항상 더 좋은 모드"가 아니다. 대기 시간을 CPU와 GPU 사이에서 숨기는 대신, 운영 복잡성을 스케줄러와 관측 시스템으로 이전하는 선택이다.
언제 도입할 가치가 있나
도입 판단은 벤치마크 숫자 하나보다 workload의 모양을 봐야 한다.
먼저 동시성이 충분해야 한다. 큐가 비어 있는 시간이 많다면 비동기화할 다음 배치 자체가 없다. 반대로 요청이 꾸준히 들어오고, prompt 길이와 output 길이가 섞여 있으며, GPU trace에 짧은 idle gap이 반복된다면 효과를 기대할 수 있다.
둘째, CPU 쪽 일이 가볍지 않아야 한다. 샘플링, 토큰 후처리, request state 관리, KV cache block 할당, admission control이 GPU step 사이에 끼어 있다면 overlap의 이득이 커진다. LLM 추론은 prefill과 decode 성격도 다르다. prefill은 상대적으로 compute-bound이고, decode는 토큰을 하나씩 생성하며 memory-bandwidth-bound인 경우가 많다.3 그래서 decode 루프가 촘촘할수록 작은 CPU 대기 시간이 누적되어 크게 보인다.
셋째, tail latency보다 sustained throughput이 더 중요한 서비스에서 먼저 검토할 만하다. 배치형 문서 처리, 내부 에이전트 실행, 고동시성 API처럼 GPU 비용 효율이 핵심인 환경이 후보가 된다. 반대로 낮은 p99와 예측 가능한 토큰 스트리밍이 제품 경험의 핵심이라면, 비동기화 자체보다 스케줄링 정책과 backpressure 설계를 먼저 검증해야 한다.
빨라진 뒤에 드러나는 문제들
처리량을 올리면 기존의 나쁜 정책도 더 빨리 실행된다. 그래서 async continuous batching 이후에는 다음 문제가 더 중요해진다.
요청 취소는 즉시 반영되는가. 사용자가 연결을 끊었는데 GPU 슬롯과 KV cache를 계속 점유하면, 높아진 처리량이 곧 메모리 압박으로 돌아온다. 스트리밍 토큰은 순서를 보장하는가. CPU와 GPU가 겹쳐 움직이면 "생성은 됐지만 아직 전달되지 않은 토큰"의 상태 관리가 복잡해진다.
공정성도 문제다. output length 편차는 batching 효율을 해치는 핵심 요인이다. 관련 연구는 비슷한 실행 시간의 요청을 bin으로 묶는 multi-bin batching이 표준 batching보다 처리량을 개선할 수 있음을 보였고, oracle length 정보가 있을 때 최대 70% 개선을 보고했다.4 이는 async 여부와 별개의 메시지를 준다. 빠른 파이프라인도 스케줄링 정책이 나쁘면 긴 요청, 짧은 요청, 특정 tenant 사이의 불균형을 키울 수 있다.
결국 봐야 할 지표는 평균 tokens/sec만이 아니다. GPU idle 비율, CPU scheduling time, queue wait, TTFT, TPOT, cancellation lag, KV cache fragmentation, tenant별 p95/p99를 함께 봐야 한다.
비동기 continuous batching은 LLM serving의 다음 "마법 버튼"이 아니다. 이미 continuous batching을 쓰고 있고, GPU가 계산보다 조율을 기다리는 흔적이 보이며, 운영 복잡성을 감당할 관측·스케줄링 체계가 있는 팀에게 강력한 카드다. 지금 판단해야 할 질문은 하나다. 당신의 서버는 정말 계산이 느린가, 아니면 기다리는 장소를 잘못 골랐는가.
참고
1Unlocking asynchronicity in continuous batching
2Static, dynamic and continuous batching
3LLM Inference Optimization Complete Guide: KV Cache, Speculative Decoding, Continuous Batching
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.