LLM 추론 비용 4~40배 줄이는 vLLM 최적화 6가지

vLLM 23배 throughput이 의미하는 추론 비용 절감

LLM을 직접 서빙하기 시작한 회사는 두 가지 충격을 거의 동시에 겪습니다. 첫째는 GPU 청구서의 크기, 둘째는 같은 GPU로 다른 팀은 우리보다 훨씬 더 많은 토큰을 뽑아낸다는 사실이에요. 2026년 들어 이 격차의 대부분은 추론 서빙 프레임워크와 KV Cache 최적화에서 갈립니다.

대표적인 사례가 vLLM입니다. Anyscale이 발표한 분석에 따르면 vLLM은 전통적인 단순 구현 대비 최대 23배의 throughput과 p50 latency 감소를 동시에 달성합니다(Anyscale Continuous Batching). 같은 A100 GPU에서 8 동시 요청 기준 Llama 3 8B를 돌리면 vLLM은 187 tok/s, ollama는 82 tok/s라는 벤치마크도 보고됩니다.

여기에 Prefix Caching·FP8 KV Cache·LMCache 같은 기술을 조합하면 long-context 추론에서 4~40배 비용 절감이 가능하다는 분석까지 나옵니다. 이 글에서는 vLLM 기반 추론 서빙 인프라에서 가장 큰 효과를 내는 6가지 최적화 기술을 어느 순서로 적용해야 하는지 정리했습니다. 이미 GPU 청구서가 부담스러운 상황이라면 AI GPU 비용 40~70% 절감 7가지 실전 액션도 함께 참고하면 좋습니다.

왜 같은 GPU인데 추론 비용이 4~40배 차이가 나는가

모델 추론 비용은 GPU 가격이 아니라 GPU 활용률에서 결정됩니다. 단순 구현은 GPU 메모리(VRAM)와 컴퓨트의 30~50%만 활용하는 경우가 흔하고, 나머지는 모두 낭비예요. 그 낭비를 만드는 핵심 원인 세 가지가 있습니다.

이 세 가지를 합치는 것이 vLLM의 출발선입니다. Anyscale 분석에서 23배 throughput이 나온 것도 단일 기술이 아니라 세 가지를 동시에 적용했기 때문이에요.

vLLM 추론 비용 최적화 6가지 기술

1, Paged Attention: 메모리 단편화 막는 기본

가장 먼저 적용해야 하는, 그리고 어떤 경우에도 끄지 말아야 하는 기술입니다. 전통 구현은 KV Cache를 연속된 메모리 블록에 할당하기 때문에, 가변 길이 요청이 들어오면 VRAM에 빈 조각이 생기고 30~50%가 사용 못 하는 상태로 묶여요. Paged Attention은 메모리를 페이지 단위로 쪼개 OS 가상 메모리처럼 관리해서 단편화를 완전히 제거합니다. vLLM에서는 기본 기술이라 별도 설정 없이 켜져 있어요.

2, Continuous Batching: 토큰 단위 동시 처리

요청 단위 배치(static batching)는 가장 긴 응답이 끝날 때까지 짧은 응답도 대기시키는 비효율을 만듭니다. Continuous Batching은 토큰 단위로 요청을 합류·이탈시켜 매 step마다 GPU를 꽉 채워요. 동시 요청이 8개 이상부터 효과가 뚜렷하고, throughput 2~4배 개선이 표준입니다(vLLM 공식 docs).

3, Prefix Caching: 반복되는 prompt 재사용

cache hit 시 비용을 85~95% 줄이는 단일 기술 중 가장 효과가 큰 항목입니다. 시스템 프롬프트, 도구 정의, 문서 prefix가 반복되는 워크로드에서 hit-rate 60~85%가 일반적이고, 호출당 비용이 5~12배 떨어져요. 에이전트 루프, 멀티 테넌트 SaaS, 리포 Q&A, 긴 문서 분석에 특히 잘 맞습니다.

4, FP8 KV Cache: 메모리 50% 추가 절감

KV Cache를 FP8로 저장하면 메모리가 절반으로 줄고, 정확도 손실은 0.3~0.7점 수준으로 노이즈 범위입니다. INT8은 long-context 검색에서 1.5~3점이 빠져 정밀도가 중요한 워크로드에는 피해야 해요. 즉 FP8은 거의 무료로 얻는 절감이고, INT8은 정확도 검증 후에 켜는 게 안전합니다.

5, LMCache: 긴 컨텍스트의 TTFT 단축

KV Cache를 GPU 메모리 밖(시스템 RAM·NVMe·외부 스토리지)에 저장하고 필요할 때 직접 로드하는 기술입니다. 128K 컨텍스트 기준 TTFT가 11초에서 1.5초로 줄어드는 사례가 보고됩니다(llm-d 블로그). RAG처럼 긴 컨텍스트가 반복되거나 시스템 프롬프트가 매우 긴 워크로드에 도입을 검토할 단계예요.

6, Quantization: 모델 자체 압축

모델 가중치를 GPTQ·AWQ·FP8 등으로 양자화해 메모리와 컴퓨트를 동시에 줄이는 기술입니다. 위 5가지가 인프라 레벨이라면 Quantization은 모델 레벨이라 정밀도 영향이 가장 큰 영역이에요. 도메인별 평가셋을 만들고, 양자화 전후 정확도 차이를 측정한 뒤 운영에 들이는 절차가 필수입니다.

한꺼번에 못 한다면, 이 순서로 적용하세요

6가지를 한 번에 도입하려 하면 효과 측정도 어렵고, 문제 발생 시 원인 격리도 어렵습니다. 가장 빠르게 비용이 떨어지는 순서로 정리하면 다음과 같아요.

1~3순위만 잘 적용해도 일반 워크로드에서 추론 비용이 크게 떨어지는 경우가 흔합니다. Prefix Caching 단독으로도 cache hit 시 5~12배 절감(llm-d)이 보고되니, 여기에 Paged Attention·Continuous Batching까지 함께 적용하면 효과가 더 누적됩니다. 4·5순위는 효과는 크지만 운영 부담도 함께 늘어나니, 워크로드 특성을 먼저 보고 도입하는 것이 안전해요.

운영에서 자주 빠뜨리는 함정 5가지

1. 벤치마크와 운영 환경의 토큰 분포가 다르다. 벤치마크는 짧은 prompt + 짧은 응답이 많은데, 실서비스는 긴 시스템 prompt + 가변 응답이 섞입니다. 자체 워크로드 트레이스로 다시 측정해야 합니다.

2. Prefix Caching이 작동 안 하는 캐시 키 설계. 사용자 ID나 timestamp가 시스템 prompt 앞쪽에 섞이면 hit-rate가 0에 수렴합니다. 변하지 않는 부분이 앞쪽, 변하는 부분이 뒤쪽으로 가도록 prompt를 재배치해야 해요.

3. FP8과 양자화를 한 번에 적용. 두 가지를 동시에 켜면 정확도 손실 원인을 격리할 수 없습니다. 한 번에 하나씩 켜고 평가셋으로 측정한 뒤 다음 단계로 가는 것이 원칙입니다.

4. GPU 모니터링만 보고 토큰 처리량은 안 본다. GPU 사용률 95%인데 실제 토큰 처리량은 절반인 경우가 의외로 많습니다. tok/s, request/s, p50·p95·p99 latency를 함께 봐야 진짜 효율이 보여요.

5. 1회 평가만 하고 운영에 들인다. 모델 업데이트, vLLM 버전 업, 트래픽 패턴 변화 모두 효율을 흔듭니다. 자동화된 회귀 평가 파이프라인을 만들어두는 것이 장기적으로 가장 큰 비용 절감입니다.

이것만 기억하세요

자주 묻는 질문 (FAQ)