vLLM 성능 비밀: Prometheus & Grafana를 활용한 완벽 모니터링 가이드

vLLM 의 성능은 메트릭으로 검증하는데요. Prometheus와 Grafana로 토큰 처리량, 캐시 효율, 메모리 사용률을 정밀 추적합니다.

2025년 06월 18일

오늘 이 글에서는 LLM 서빙의 게임 체인저로 불리는 vLLM과, 그 심장부의 움직임을 속속들이 들여다볼 수 있게 해주는 강력한 조합, Prometheus와 Grafana에 대해 이야기하고자 합니다. 단순히 ‘vLLM이 빠르다’는 막연한 사실을 넘어, ‘왜, 그리고 얼마나 효율적인지’를 데이터로 증명하고, 최적의 운영 상태를 유지하기 위한 통찰력을 얻는 여정을 함께 떠나보겠습니다.

vLLM은 대규모 언어 모델(LLM)의 추론을 고성능으로 제공하기 위한 프레임워크로, 특히 메모리 효율성과 처리량 향상에 중점을 두고 설계되었습니다. 이러한 성능을 유지하고 최적화하기 위해서는 시스템의 상태를 실시간으로 모니터링하는 것이 필수적입니다. Prometheus와 Grafana는 이러한 모니터링을 효과적으로 수행할 수 있는 도구로, vLLM의 다양한 메트릭을 수집하고 시각화하여 시스템의 성능과 상태를 직관적으로 파악할 수 있도록 도와줍니다.

vLLM , 왜 우리는 주목해야 하는가?

본격적인 모니터링 이야기를 시작하기 전에, 우리가 왜 vLLM에 주목해야 하는지 그 핵심 철학을 먼저 이해할 필요가 있습니다. vLLM의 혁신은 PagedAttention이라는 독창적인 아이디어에서 출발합니다.

기존의 LLM 서빙 프레임워크들은 Transformer 모델의 핵심 요소인 Key-Value Cache(KV Cache)를 관리하는 데 큰 어려움을 겪었습니다. KV Cache는 사용자의 요청(프롬프트)이 들어올 때마다 생성되어, 다음 토큰을 예측하는 데 재사용되는 중요한 데이터입니다. 문제는 이 KV Cache의 크기가 고정되어 있지 않고, 시퀀스의 길이에 따라 동적으로 변한다는 점입니다.

기존 방식에서는 각 요청에 대해 연속된 메모리 공간을 미리 할당해야 했습니다. 이는 마치 한 명의 손님을 위해 호텔의 한 층 전체를 예약하는 것과 같습니다. 손님이 실제로 몇 개의 방을 쓸지 모르니, 최악의 경우(가장 긴 시퀀스)를 가정하고 통째로 비워두는 것이죠. 이로 인해 메모리 공간은 심각하게 파편화되고(internal/external fragmentation), 실제 GPU 메모리의 상당 부분이 사용되지 않은 채 낭비되었습니다. 결국, 동시에 처리할 수 있는 요청의 수(batch size)가 줄어들고, 이는 곧 처리량(throughput) 저하로 이어졌습니다.

vLLM은 이러한 문제를 운영체제(OS)의 가상 메모리(Virtual Memory)와 페이징(Paging) 개념을 차용하여 해결했습니다. 거대한 연속 공간을 할당하는 대신, GPU 메모리를 ‘페이지‘라고 불리는 작고 고정된 크기의 블록(block)으로 나눕니다. 그리고 각 시퀀스의 KV Cache를 이 블록들에 나누어 저장합니다. 연속적이지 않은 물리적 메모리 블록들을 논리적으로 연결하여 하나의 연속된 공간처럼 사용하는 것이죠.

메모리 낭비 최소화: 필요한 만큼만 블록을 할당하므로 메모리 사용 효율이 극대화됩니다.
높은 처리량(Throughput): 낭비되던 메모리 공간에 더 많은 요청을 동시에 올릴 수 있게 되어, 배치 사이즈가 커지고 이는 곧바로 처리량 향상으로 이어집니다.
유연한 메모리 관리: 복잡한 샘플링 알고리즘(e.g., parallel sampling, beam search)에서도 메모리를 효율적으로 공유하고 관리할 수 있습니다.

이제 vLLM의 핵심 무기가 무엇인지 이해하셨을 겁니다. 그렇다면 이 강력한 무기가 실제 전투(프로덕션 환경)에서 얼마나 잘 작동하는지, 우리는 어떻게 알 수 있을까요? 바로 이 지점에서 Prometheus와 Grafana가 등장합니다.

Prometheus와 Grafana로 vLLM 의 심장부를 들여다보기

vLLM은 자신의 상태를 외부 세계에 투명하게 공개하기 위해 Prometheus가 수집할 수 있는 형식의 메트릭(metrics)을 /metrics 엔드포인트를 통해 기본적으로 제공합니다. 우리는 Prometheus를 이용해 이 메트릭들을 주기적으로 수집(scrape)하고, Grafana를 통해 시각화하여 vLLM 서버의 건강 상태와 성능을 한눈에 파악할 수 있습니다.

vLLM을 모니터링한다는 것은 단순히 CPU나 GPU 사용률을 보는 것을 넘어섭니다. 우리는 vLLM의 핵심 동작 원리와 직결된 지표들을 통해 서비스의 잠재적 문제점을 미리 감지하고, 성능을 최적화하며, 비용 효율적인 스케일링 전략을 수립할 수 있습니다.

vLLM을 Prometheus와 Grafana를 통해 모니터링하는 것은 단순한 리소스 사용량 확인을 넘어, LLM 서빙의 핵심 동작을 실시간으로 파악하고 최적화하는 데 필수적인 과정입니다. 이를 통해 요청 처리 상태, 토큰 생성 성능, 메모리 캐시 활용도 등 다양한 지표를 시각화하여 시스템의 효율성과 안정성을 높일 수 있습니다.

요청 처리 및 처리량 관련 지표 시각화

vLLM은 다음과 같은 요청 처리 상태 지표를 제공합니다:

vllm:num_requests_running : 현재 GPU에서 실행 중인 요청 수

vllm:num_requests_waiting : 실행 대기 중인 요청 수

vllm:num_requests_swapped : GPU 메모리 부족으로 CPU 메모리로 스왑된 요청 수

vllm:request_throughput_total : 서비스 시작 이후 처리한 총 요청 수

이러한 지표들은 Grafana 대시보드에서 실시간으로 시각화할 수 있으며, 시스템 부하와 처리 능력을 직관적으로 파악하는 데 도움이 됩니다.

토큰 처리 성능 지표 시각화

LLM의 실제 성능을 평가하기 위해 다음과 같은 토큰 처리 지표를 모니터링합니다:

vllm:prompt_tokens_total : 처리한 총 프롬프트 토큰 수

vllm:generation_tokens_total : 생성한 총 토큰 수

vllm:time_to_first_token_seconds : 첫 번째 토큰 생성까지의 시간

vllm:generation_throughput_toks_per_s : 초당 생성 토큰 수

이러한 지표들은 사용자 경험과 직결되며, Grafana를 통해 시각화함으로써 성능 병목 지점을 신속하게 식별하고 대응할 수 있습니다.

PagedAttention 및 Hi Ratio 관련 지표 시각화

vLLM의 핵심 기능인 PagedAttention의 효율성을 평가하기 위해 다음과 같은 지표를 모니터링합니다:

vllm:gpu_cache_usage_perc : GPU 캐시 사용률

vllm:spec_decode_efficiency : 사양 디코딩 효율성(Hi Ratio)

이러한 지표들은 메모리 사용 패턴과 디코딩 효율성을 직관적으로 파악할 수 있게 해주며, 필요 시 설정을 조정하여 성능을 최적화할 수 있습니다.

이러한 지표들을 효과적으로 시각화하기 위해 vLLM 공식 문서에서는 Prometheus와 Grafana를 활용한 모니터링 설정 예제를 제공합니다. 해당 예제를 통해 vLLM의 다양한 메트릭을 수집하고 시각화하여 시스템의 성능과 상태를 직관적으로 파악할 수 있습니다.

또한, GitHub의 vLLM 프로젝트에서는 다양한 모니터링 대시보드 예제를 공유하고 있으며, 이를 활용하여 자신만의 대시보드를 구성할 수 있습니다.

KV Cache Hit Ratio: vLLM 성능의 바로미터

전통적인 캐시 시스템에서 ‘Hit Ratio’는 요청한 데이터가 캐시에 존재할 확률을 의미하며, 이는 시스템 효율성의 직접적인 척도입니다. vLLM의 PagedAttention 컨텍스트에서 ‘Hit Ratio’라는 직접적인 메트릭은 없지만, 우리는 이와 유사한 개념을 KV Cache의 메모리 블록 사용률을 통해 유추하고 평가할 수 있습니다. PagedAttention의 목표는 할당된 GPU 메모리 블록을 최대한 효율적으로 사용하여 낭비를 줄이는 것이기 때문입니다.

이를 위해 우리는 vllm:gpu_cache_usage_perc 메트릭을 주목해야 합니다.

vllm:gpu_cache_usage_perc: vLLM에 할당된 전체 GPU KV Cache 중 현재 사용 중인 비율(0.0 ~ 1.0).

이 지표가 의미하는 바는 매우 중요합니다. 만약 이 사용률이 지속적으로 90% 이상을 유지한다면, 이는 vLLM이 GPU 메모리를 매우 효율적으로 사용하며 높은 배치 사이즈로 요청들을 처리하고 있다는 긍정적인 신호입니다. 즉, PagedAttention의 설계 목적이 성공적으로 달성되고 있음을 의미합니다. 반대로, 트래픽이 많음에도 불구하고 이 수치가 낮게 유지된다면, vLLM 시작 시 설정한 gpu_memory_utilization 파라미터가 현재 워크로드에 비해 너무 높게 설정되어 자원이 낭비되고 있을 가능성을 시사합니다.

더 나아가, 우리는 vllm:cpu_cache_usage_perc 메트릭을 함께 관찰해야 합니다.

vllm:cpu_cache_usage_perc: 스왑 공간으로 할당된 CPU 메모리 중 현재 사용 중인 비율

GPU 캐시 사용률이 100%에 도달했는데도 새로운 요청이 들어오면, vLLM은 기존 요청의 KV Cache 블록 중 일부를 CPU 메모리로 내보냅니다(Swap Out). cpu_cache_usage_perc가 상승하기 시작했다면, 이는 스와핑이 발생하고 있다는 명백한 증거입니다. 스와핑은 GPU와 CPU 간의 데이터 전송으로 인해 상당한 지연을 유발하므로, 이 지표의 증가는 잠재적인 성능 병목 현상을 경고하는 강력한 알람입니다.

Grafana 대시보드에서 GPU와 CPU의 캐시 사용률을 시계열 그래프로 함께 그려보면, 시스템 부하에 따른 메모리 압박의 변화와 스와핑 발생 시점을 명확하게 파악하고 대응할 수 있습니다.

PagedAttention의 작동 원리, 통계로 확인하기

PagedAttention의 정교한 메모리 관리는 어떻게 통계로 확인할 수 있을까요? 바로 물리적 메모리 블록의 상태를 추적하는 메트릭들을 통해 가능합니다. vLLM은 GPU와 CPU에 할당된 메모리 블록의 개수와 상태를 실시간으로 노출합니다.

우리가 주목해야 할 핵심 메트릭은 다음과 같습니다.

vllm:num_gpu_blocks_free: 현재 GPU에서 사용 가능한(비어있는) KV Cache 블록의 총 개수.

vllm:num_gpu_blocks_used: 현재 GPU에서 사용 중인 KV Cache 블록의 총 개수.

vllm:num_cpu_blocks_free: CPU 스왑 공간에서 사용 가능한 블록의 총 개수.

vllm:num_cpu_blocks_used: CPU 스왑 공간에서 사용 중인 블록의 총 개수.

이 네 가지 지표는 vLLM 메모리 관리 시스템의 ‘대차대조표‘와 같습니다. 이들을 통해 우리는 시스템의 가용 용량을 정확히 파악할 수 있습니다.

구분	현황
건강한 상태	vllm:num_gpu_blocks_free가 항상 일정 수준 이상의 값을 유지하고, vllm:num_cpu_blocks_used가 0에 가깝다면, 시스템은 안정적으로 요청을 처리할 여유가 충분하다는 의미입니다.
부하 증가 상태	트래픽이 증가함에 따라 vllm:num_gpu_blocks_used는 증가하고 vllm:num_gpu_blocks_free는 감소합니다. 이는 자연스러운 현상입니다.
임계점 및 위험신호	vllm:num_gpu_blocks_free가 0에 가까워지는 순간이 바로 시스템의 한계점에 다다랐다는 신호입니다. 이 시점부터 vllm:num_requests_swapped와 vllm:num_cpu_blocks_used 메트릭이 상승하기 시작할 것입니다. 만약 이 두 지표가 급증한다면, 이는 GPU 용량을 초과하여 스와핑이 빈번하게 발생하고 있으며, 이로 인해 전체적인 응답 시간과 처리량이 저하될 것임을 예측할 수 있습니다.

구분

현황

건강한 상태

vllm:num_gpu_blocks_free가 항상 일정 수준 이상의 값을 유지하고, vllm:num_cpu_blocks_used가 0에 가깝다면, 시스템은 안정적으로 요청을 처리할 여유가 충분하다는 의미입니다.

부하 증가 상태

트래픽이 증가함에 따라 vllm:num_gpu_blocks_used는 증가하고 vllm:num_gpu_blocks_free는 감소합니다. 이는 자연스러운 현상입니다.

임계점 및 위험신호

vllm:num_gpu_blocks_free가 0에 가까워지는 순간이 바로 시스템의 한계점에 다다랐다는 신호입니다. 이 시점부터 vllm:num_requests_swapped와 vllm:num_cpu_blocks_used 메트릭이 상승하기 시작할 것입니다.

만약 이 두 지표가 급증한다면, 이는 GPU 용량을 초과하여 스와핑이 빈번하게 발생하고 있으며, 이로 인해 전체적인 응답 시간과 처리량이 저하될 것임을 예측할 수 있습니다.

Grafana에서는 num_gpu_blocks_free와 num_gpu_blocks_used를 하나의 스택 그래프(stacked graph)로 시각화하여 전체 GPU 블록 용량 대비 현재 사용량을 직관적으로 보여줄 수 있습니다.

이 그래프의 추이를 모니터링하면, 향후 필요한 GPU 자원량을 예측하고 스케일 아웃(scale-out) 시점을 결정하는 데 매우 중요한 데이터 기반의 근거를 마련할 수 있습니다.

결론: 데이터로 말하는 vLLM의 가치

지금까지 우리는 vLLM의 핵심 철학인 PagedAttention을 이해하고, Prometheus와 Grafana를 통해 그 성능과 내부 동작을 어떻게 투명하게 들여다볼 수 있는지 살펴보았습니다.

vLLM은 단순히 ‘빠른‘ 서빙 엔진이 아닙니다. 그것은 자신의 상태를 정밀한 데이터로 증명하고, 운영자에게 최적화의 실마리를 제공하는 ‘관측 가능한(Observable)’ 시스템입니다. KV Cache 사용률과 메모리 블록 상태와 같은 깊이 있는 메트릭들을 통해, 우리는 다음과 같은 가치를 얻을 수 있습니다.

성능 병목 지점의 정확한 식별: ‘느려졌다’는 막연한 감이 아니라, 스와핑 발생, 대기열 증가 등 구체적인 원인을 데이터로 찾을 수 있습니다.
비용 효율적인 자원 운영: 실제 워크로드에 맞춰 gpu_memory_utilization과 같은 핵심 파라미터를 튜닝하고, 불필요한 자원 낭비를 막을 수 있습니다.
데이터 기반 의사결정: 서비스 확장(scale-up/out)이나 투자 결정을 내릴 때, 실제 사용량 데이터를 기반으로 한 정량적인 예측이 가능해집니다.

LLM이 만들어가는 새로운 기술의 지평 위에서, vLLM과 같은 효율적인 서빙 기술과 Prometheus, Grafana와 같은 강력한 모니터링 도구의 조합은 안정적이고 성공적인 AI 서비스를 구축하는 데 없어서는 안 될 필수 요소가 될 것입니다. 이제 여러분의 vLLM 서버에 관측의 눈을 달아주고, 데이터가 들려주는 이야기에 귀를 기울여 보시기 바랍니다. 그 속에서 서비스의 안정성과 효율성을 한 단계 더 끌어올릴 수 있는 귀중한 통찰력을 발견하게 될 것입니다.