최신글

vLLM 처리량 설정 옵션 - max_num_seqs(batch size)

반응형

들어가며

추론엔진 성능을 올리는 옵션 중 하나가 batch_size가 있습니다. 그리고 vLLM에서는 max_num_seqs옵션에 해당하는데요. 이 글에서는 이 옵션의 의미가 무엇인지 살펴보고 간단히 테스트를 진행했습니다.

 

이론

vLLM 같은 추론 엔진은 여러 요청의 sequence를 iteration마다 묶어서 처리합니다. max_num_seqs 값이 커지면 한 번의 iteration에서 처리할 수 있는 최대 sequence 수도 늘어나 처리량을 높일 수 있습니다.

 

max_num_seqs를 높이는 주된 목적은 한 번에 더 많은 요청을 처리해 전체 추론 처리량을 높이는 것입니다. 이번 테스트에서 대기열이 줄면서 TTFT도 낮아졌지만, 이는 처리량이 늘면서 나타난 부수적인 효과입니다. 하지만 GPU 하드웨어 사양 등을 고려하지 않은 채 max_num_seqs만 높이면 병목이 생겨 오히려 성능이 낮아지거나, GPU 메모리 부족으로 vLLM이 비정상 상태에 빠져 장애가 발생할 수 있습니다.

 

테스트 방법

저는 vLLM 추론 엔진에서 batch 크기의 상한을 설정하고 TTFT, TPOT 등을 비교해 봤습니다. vLLM에서는 max_num_seqs로 한 번의 iteration에서 처리할 최대 sequence 수를 설정합니다.

 

테스트에는 vllm bench serve를 사용했습니다. Linux for loop로 동시 요청 수(–max-concurrency)를 설정했고, 1, 4, 8만 테스트했습니다.

for concurrency in 1 4 8; do
  docker compose --profile tools run --rm benchmark \
    vllm bench serve \
    --backend vllm \
    --max-concurrency "${concurrency}" \
    --seed "${concurrency}" \
    --num-warmups 5 \
    --num-prompts 100 \
    --request-rate inf \
    --base-url http://model-server:8000 \
    ...

 

vllm bench serve를 실행하면 다음과 같은 결과 리포트가 나옵니다.

 

테스트 환경

하드웨어:

  • NVIDIA GPU RTX 5060 Ti 16GB

 

vLLM 환경:

  • Ubuntu 20.04 LTS
  • Docker vLLM

 

예제 코드:

테스트 결과

max_num_seqs는 한 번의 iteration에서 처리할 수 있는 최대 sequence 수입니다. 아래 표의 conc는 클라이언트의 최대 동시 요청 수입니다.

 

클라이언트 요청이 충분히 들어오는 조건에서는 max_num_seqs가 클수록 요청 처리량도 늘었습니다.

 

한 번의 iteration에서 더 많은 sequence를 처리하면서 전체 처리량이 올라갔고, 요청이 대기열에서 기다리는 시간도 함께 줄었습니다.

 

vLLM 메트릭을 보면 max_num_seqs=1일 때는 한 번의 iteration에서 sequence를 1개만 처리하므로 요청 대기 시간이 쌓입니다. 사용자가 첫 응답을 받는 시간인 TTFT p95는 약 8초입니다.

 

반면 max_num_seqs=8에서는 대기 중인 요청이 없어 TTFT가 약 400ms입니다.

 

요청 대기 시간은 줄었지만, 응답 토큰을 생성하는 decode의 TPOT는 비슷했습니다. LLM의 decode는 메모리 대역폭의 영향을 많이 받기 때문에 이번 테스트에서는 큰 차이가 보이지 않았던 것 같습니다.

반응형