우리 팀만의 vLLM 플러그인 만들기 1편 - 검색 AI 모델 서빙 성능 극대화하기

네이버 플레이스 AI MLOps 가 검색·추천 스코어링 모델의 서빙을 vLLM 기반으로 옮긴 1편이다. 모델 코드는 한 줄도 빠르게 만들지 않았는데 재순위화 처리량이 6.2배 올랐고, 그 이유를 GPU 커널 단위 계측까지 파고들어 규명한다.

핵심 포인트

0.6B 재순위화 모델을 Hugging Face `Transformer.encode` 로 서빙할 때 63.85 QPS 였던 것이 vLLM `score` 태스크에서 397.21 QPS 로 약 6.2배가 됐다.
속성 기반 감성 모델(ABSA)의 단건 p50 은 101.22ms → 16.43ms 로 83.8% 감소했고, CLIP 기반 이미지 랭킹은 다섯 단계 최적화로 3.76 img/s → 62.2 img/s 로 누적 16.5배가 됐다.
병목은 순전파가 아니라 그 주변이었다. 네트워크 구간, JSON·텐서 직렬화, 토크나이저와 모델 서버 분리로 인한 추가 왕복, 그리고 요청이 흩어져 배치를 못 채우는 문제다.
검색·추천 모델은 생성형과 특성이 다르다. 입력은 짧지만 한 요청에서 후보 수십~수백 개를 평가해야 하고 p95 예산이 수십 ms 수준이다.
Nsight Compute 계측 결과 vLLM 경로의 전역 메모리 명령 수가 7.07M → 262K 로 **약 27분의 1** 이었다. 같은 일을 빨리 한 게 아니라 더 적은 커널 실행으로 처리한 것이다.

상세 정리

구조 변경의 뼈대는 둘이다. 모델을 vLLM 사용자 정의 모델로 구현해 풀링 런타임에 올리고, 전후처리를 IO Processor 안으로 옮긴 뒤 플러그인 패키지로 배포해 `pip install` 한 번으로 설치되게 했다.
기존에는 모델마다 별도 추론 경로(검색 백엔드 → 앱 서버 → 전처리 → 모델 서버 → 후처리 → 랭킹)를 운영해, 모델이 늘 때마다 경로가 복제되고 전후처리 로직이 여러 서비스에 흩어졌다.
vLLM 을 고른 근거: 생성은 풀링 런타임에 샘플링 계층을 결합한 한 가지 사용 방식일 뿐이고, 같은 런타임을 은닉 상태 → 임베딩·분류 확률·토큰 점수로 바꾸는 시스템으로 볼 수 있다.
다만 한 프로세스가 여러 모델을 서빙한다는 뜻은 아니다. 모델별 인스턴스를 띄우되 런타임·기본 이미지·플러그인 패키지·배포 방식을 공유한다.
얻는 것은 연속 배치, CUDA Graph, 최적화된 어텐션 백엔드, 페이지 단위 GPU 메모리 관리를 공짜로 쓰는 것이다. 모델별 서버를 따로 만들면 매번 처음부터 쌓아야 한다.
풀링 구조는 태스크(`embed`·`classify`·`token_embed`·`token_classify`)와 풀링 방식(CLS·LAST·MEAN·ALL·STEP)으로 결정된다. 재순위화는 `num_labels=1` 인 classify 태스크의 교차 인코더로 표현된다.
커널 계측 조건: 0.5B 재순위화 모델, H100(CUDA 12.8), `ncu --set full` 로 준비 구간 3만 회를 제외하고 안정 상태 커널 200개 집계.
다른 지표도 함께 바뀌었다. 공유 메모리 명령 18.19M → 5.57M, `cp.async` 0 → 3.24M, L2 적중률 95.63% → 99.17%.
`cp.async` 는 L1 을 거치지 않고 전역 메모리에서 공유 메모리로 직접 옮기는 Ampere 이후 명령이다. L1/TEX 적중률이 0.11% → 0.00% 로 나빠 보이는 것은 L1 을 의도적으로 우회했기 때문이다.
IO Processor 의 5단계는 `parse_data` → `merge_pooling_params` → `pre_process` → 엔진 풀링 추론 → `post_process` 다. 비즈니스 토큰화를 `pre_process` 안에서 끝내는 것이 핵심이다.
편의 동작 하나: `post_process_async` 의 기본 구현이 ID 기준으로 출력을 정렬한 뒤 동기 `post_process` 를 부르므로 구현자는 동기 버전만 신경 쓰면 된다.
**가장 흔했던 사고**: `pre_process` 에서 요청 단위 캐시에 넣은 값을 `post_process` 에서 `pop` 으로 지우지 않으면 장시간 실행 파드에서 메모리가 계속 늘다 몇 시간 뒤 OOM 이 난다.
통합이 늘 유리한 것도 아니다. 전후처리를 런타임 안으로 넣으면 그 CPU 부하가 GPU 파드로 들어오고, 이미지 디코딩처럼 무거운 작업은 GPU 를 기다리게 만든다. 그래서 토큰화 같은 가벼운 것만 바로 통합하고 무거운 것은 병렬 수준을 측정한 뒤 옮겼다.
재순위화 재측정(Qwen3 계열 0.6B, vLLM 0.19.0, BF16, 실제 질의·리뷰 1만 쌍): 고정 패딩 194 pairs/s, 동적 패딩(배치 32) 400, vLLM score 1,769 로 각각 9.1배·4.4배였다. 동적 패딩이 격차의 절반을 설명하고 나머지는 배치·커널 배치에서 나왔다.
실제 API 형태로도 확인했다. `/rerank` 는 질의 1개와 후보 20개를 한 요청으로 받으며, H100 한 장에서 동시 1요청 p50 24.9ms·787 pairs/s, 동시 16요청 p50 99.7ms·3,043 pairs/s 였다.
ABSA 동등성 검증: 테스트 414건 중 감성 분류는 100% 일치, 범위(span)는 413건으로 99.76% 일치했다. 차이 난 1건은 원본의 패딩 처리에서 온 경계 사례로 **vLLM 쪽이 더 정확**했다.
**"숫자가 너무 좋으면 의심부터"**: 초기 측정에서 배치 64 기준 13.1배가 나왔는데, `dtype="auto"` 로 실행한 vLLM 이 FP32 모델을 FP16 으로 자동 변환하고 있었다. 양쪽을 FP32 로 고정하자 순수 런타임 개선분인 4.05배가 남았고, 팀에 "자료형은 항상 명시한다" 는 규칙이 생겼다.
부수 발견: FP32 로 맞추자 최대 GPU 메모리는 vLLM 이 오히려 약 10% 많았다(2,642MiB → 2,901MiB). PagedAttention 블록 테이블과 CUDA 작업 공간 사전 할당 비용이 드러난 것으로, 평소엔 FP16 자동 변환이 이를 가리고 있었다.
이미지 랭킹의 결정적 한 수는 비전 특징 577개를 캐시로 옮기고 입력 시퀀스에 표시 토큰 하나만 남긴 것이다. 시퀀스가 654 → 78 로 줄며 배치 입력이 12 → 105 개로 늘었다.
서빙 단계에서는 이미지 다운로드를 `ThreadPoolExecutor(16)` 병렬로 바꾸고 `nn.MultiheadAttention` 을 vLLM 의 `QKVParallelLinear` + FLASH_ATTN + `RowParallelLinear` 조합으로 교체해 CUDA Graph PIECEWISE 모드에서 그래프 51개를 캡처했다. worker 를 32개까지 늘리면 GIL·CPU 경합으로 오히려 느려졌다.