vLLM 1.1 LoRA 핫스왑 — 멀티 테넌트 LLM 서빙, 비용 50%↓

핵심 요약

고객사별 도메인 미세조정 어댑터를 따로 서빙하면 GPU가 폭증한다. vLLM 1.1의 LoRA 핫스왑은 베이스 모델 1개 + 어댑터 N개를 한 GPU에 동거시키고 요청별로 어댑터를 즉시 교체. 사내 12개 테넌트를 8×H100 4노드 → 2노드로 통합해 월 비용 51% 절감.

1. 무엇이 새로워졌나

1.0까지의 LoRA 서빙은 어댑터 로딩이 수 초 걸리고 메모리 풀이 분리돼 있었다. 1.1은 어댑터 캐시 풀과 페이지드 KV 캐시를 통합, 핫스왑 지연을 2ms 이하로 줄였다. 동시 어댑터 32개까지 안정 동작.

2. 셋업

vllm serve meta-llama/Llama-3.3-8B-Instruct \
  --enable-lora \
  --max-loras 32 \
  --max-lora-rank 64 \
  --lora-modules tenantA=/models/loraA \
                  tenantB=/models/loraB

요청에서 model: "tenantA"로 명시하면 해당 어댑터로 추론. 런타임 동적 추가는 /v1/load_lora_adapter 엔드포인트.

3. 처리량 비교

처리량은 11% 감소했지만 비용은 절반. p95도 0.2s 늘었을 뿐 SLA 안에 들어옴.

4. 어댑터 사이즈 가이드

rank 8~16이면 메모리·품질 균형 우수. rank 64까지 한 모델에 동시 32개 가능. rank 128 이상은 어댑터당 250MB가 넘어 동거 효율 급락. rank를 낮추고 학습 데이터를 1.5배 늘리는 게 비용·품질 모두 유리했다.

5. 콜드 어댑터 처리

접근 빈도 낮은 어댑터는 S3에 보관, 첫 요청 시 lazy load. --lora-storage s3://... 옵션으로 80개 어댑터를 디스크 부담 없이 운영. 첫 호출만 1.4s 지연.

6. 모니터링

# Prometheus 메트릭
vllm:lora_adapter_loads_total
vllm:lora_active_count
vllm:lora_swap_latency_seconds

swap_latency p99이 50ms을 넘으면 어댑터 수를 줄이거나 GPU 메모리 확장.

7. 함정

• 베이스 모델 토크나이저가 다르면 동거 불가 — 같은 base에서 출발한 어댑터만
• guided decoding과 LoRA를 동시 활성화 시 성능 22% 하락 — 한쪽만
• FP8 베이스 모델 + LoRA bf16은 정확도 손실 큼 — 어댑터도 FP8로 양자화 필수

자주 묻는 질문

Q. SGLang이나 TGI도 LoRA 핫스왑 지원하나? SGLang 0.5는 부분 지원, TGI 3.1은 제한적. 멀티 테넌트라면 2026년 5월 기준 vLLM 1.1이 가장 성숙.