DEVOCEAN

웹 서비스를 준비하는 과정에서 부하테스트는 서비스 운영 중 발생할 수 있는 문제를 미리 파악하는 데 필수적인 단계입니다.

특히 LLM(Large Language Model)을 활용하는 서비스는 기존 웹 서비스와는 다른 특성을 가지고 있기 때문에,

이에 맞는 지표(Metric)를 정확히 이해하고 적절한 테스트를 진행하는 것이 매우 중요합니다.

이 글에서는 LLM 기반 서비스의 부하테스트에서 반드시 확인해야 하는 주요 Metric과 간단한 예제를 함께 정리하여 설명합니다.

여기서는 대표적으로 많이 사용되는 프레임워크인 vLLM을 기준으로 설명하나, 다른 프레임워크를 사용하더라도 핵심 원리와 지표 측정 방식은 크게 다르지 않으므로 참고하시면 좋을 것 같습니다.

LLM 기반 서비스의 특징

LLM을 이용한 서비스는 일반적으로 대화형(Chat) 기반으로 설계됩니다.

기존 API 서비스가 요청 처리 후 최종 데이터를 JSON 형태나 바이너리 등 완결적 결과를 주로 전달하는 반면, LLM 서비스는 생성되는 답변을 실시간으로 스트리밍 형태로 제공합니다.

이에 따라 사용자의 첫 번째 응답까지 걸리는 시간(TTFT), 각 토큰 생성 시간, 평균 응답 길이 등과 같이 전통적인 웹 서비스와는 차별화된 Metric을 사용하여 테스트해야 합니다.

또한 이 새로운 Metric들을 기존 서비스와 비교하기 위해 다른 형태로 환산하거나 분석하는 경우도 흔히 발생합니다.

부하테스트에서 중요하게 측정하는 Metric

LLM 서비스를 제공할 때 가장 중요한 두 가지 요소는 지연 시간(Latency)과 처리량(Throughput)입니다. 세부적인 Metric을 살펴보면 다음과 같습니다.

Latency 관련 Metric

• TTFT(Time To First Token): 사용자가 요청 후 첫 번째 토큰을 받을 때까지 걸리는 시간으로, 체감 응답 속도를 가장 잘 나타냅니다. vLLM에서는 vllm:time_to_first_token_seconds로 측정합니다.

• 총 대기 시간: 요청이 시작되어 최종 응답까지 걸리는 전체 시간으로, 긴 출력이 예상되는 서비스에서는 특히 중요합니다. vLLM에서는 vllm:e2e_request_latency_seconds로 확인합니다.

• 토큰당 생성 시간: 각 토큰 생성에 걸리는 평균 시간을 나타내며, vLLM에서 vllm:time_per_output_token_seconds로 측정됩니다.

Throughput 관련 Metric

• 토큰 처리량: 초당 생성되는 토큰 수(tokens per second, TPS)로 서비스의 성능을 평가할 때 가장 흔히 사용하는 지표입니다.

• 요청 처리량: 초당 처리 가능한 요청 수를 의미하며, 시스템 전체 성능을 평가하는 데 매우 중요합니다.

실제 부하테스트 사례

만약 vLLM 을 사용해서 서비스를 구성한다면, vLLM 기반 부하테스트는 vLLM에서 제공하는 benchmark_serving.py를 사용해 쉽게 진행할 수 있습니다. 샘플 스크립트는 다음과 같습니다.

python benchmarks/benchmark_serving.py \  
        --backend openai-chat \  
        --model 'google/gemma-3-4b-it' \  
        --host '127.0.0.1' \  
        --port '8080' \  
        --endpoint '/v1/chat/completions' \  
        --dataset-name hf \  
        --dataset-path lmarena-ai/VisionArena-Chat \  
        --hf-split train \  
        --max-concurrency 10 \  
        --num-prompts 1000

각 인자의 의미는 다음과 같습니다.

• backend: 요청 유형(OpenAI Chat API 사용 시 openai-chat 지정)

• model: 테스트 대상 모델

• host/port: 테스트 대상 서버 주소 및 포트

• endpoint: API 엔드포인트

• dataset-name: 사용 데이터셋 유형(hf는 Hugging Face 데이터셋 사용 시 지정)

• dataset-path: 실제 사용 데이터셋 경로

• hf-split: 데이터셋 분할(train, test 등)

• max-concurrency: 최대 동시 요청 수

• num-prompts: 총 요청 개수

부하테스트의 예시 결과는 아래와 같습니다.

============ Serving Benchmark Result ============
Successful requests:                 1000     
Benchmark duration (s):              343.43   
Total input tokens:                  94327    
Total generated tokens:              113826   
Request throughput (req/s):          2.91     
Output token throughput (tok/s):     331.44   
Total Token throughput (tok/s):      606.11   
---------------Time to First Token----------------
Mean TTFT (ms):                      598.11   
Median TTFT (ms):                    543.51   
P99 TTFT (ms):                       1601.70  
-----Time per Output Token (excl. 1st token)------
Mean TPOT (ms):                      25.29    
Median TPOT (ms):                    25.02    
P99 TPOT (ms):                       43.40    
---------------Inter-token Latency----------------
Mean ITL (ms):                       41.94    
Median ITL (ms):                     14.42    
P99 ITL (ms):                        326.10  
==================================================

이 중 주요하게 봐야 할 Metric은 Mean TTFT, Mean ITL, Request throughput, Output token throughput입니다.

예를 들어 평균 100 토큰을 생성하는 서비스라면, 사용자가 최종적으로 답변을 받기까지 약 4.5초 정도 소요될 것으로 예상할 수 있습니다(598.11ms + 100 토큰 × 41.94ms).

여기서 **TPOT(Time per Output Token)**는 토큰 자체의 순수 생성 시간이고, **ITL(Inter-token Latency)**은 생성된 토큰이 사용자에게 실제 전달될 때까지 걸리는 지연 시간입니다.

따라서 ITL이 실질적인 사용자 체감 속도를 더 정확히 나타냅니다.

특히, 평균값과 중간값 간 큰 차이가 있을 경우 스파이크 등 외부 요인으로 인한 성능 저하 가능성을 염두에 두고, 추가 분석을 진행해야 합니다.

또한, 높은 P99 값(예: TPOT 43.4ms 대비 ITL 326.1ms)이 나타날 경우 네트워크나 시스템 구성에 잠재적 문제가 있는지 점검하는 것이 필요합니다.

결론

LLM 서비스를 준비할 때는 기존 웹 서비스와는 차별화된 지표들을 명확히 이해하고, 이를 바탕으로 철저한 부하테스트를 진행해야 합니다.

특히 TTFT와 ITL, 토큰 처리량 등의 데이터를 면밀히 분석하여 사용자 체감 성능을 최적화하는 것이 중요합니다.

또한 Metric을 통해 도출된 데이터를 토대로 시스템 전반의 문제점을 파악하고, 네트워크 환경을 포함한 다양한 요소를 점검한다면, 보다 견고한 서비스로 발전시킬 수 있을 것으로 생각됩니다.

Reference

1. https://github.com/vllm-project/vllm/blob/main/benchmarks/benchmark_serving.py

2. https://docs.vllm.ai/en/latest/design/v1/metrics.html

3. https://www.redhat.com/ko/blog/evaluating-llm-inference-performance-red-hat-openshift-ai