vLLM 종류와 사용법 | 처음 시작할 때 꼭 알아야 할 실행 방식 정리

 

LLM을 직접 배포해보려다 보면 꽤 빨리 만나게 되는 이름이 있습니다.

바로 vLLM입니다.

Hugging Face 모델을 띄우고 API 형태로 연결하거나, GPU 자원을 좀 더 효율적으로 써서 추론 성능을 높이고 싶을 때 많이 언급되는 도구입니다.

그런데 막상 처음 접하면 헷갈리는 부분이 있습니다. vLLM이 하나의 “모델”처럼 보이기도 하고, 어떤 사람은 서버처럼 쓰고, 어떤 사람은 파이썬 코드 안에서 바로 불러서 쓰고, 또 어떤 사람은 Docker나 Kubernetes로 배포합니다.

그래서 이번 글에서는 vLLM의 종류를 “사용 형태” 기준으로 나눠서, 실제로 어떤 방식이 있고 어떻게 시작하면 되는지 처음 보는 사람도 이해할 수 있게 정리해보겠습니다.

#vLLM #vLLM사용법 #vLLM종류 #LLM서빙 #AI배포 #OpenAI호환API #GPU추론

vLLM은 정확히 어떤 도구일까

vLLM은 언어 모델 자체가 아니라, 언어 모델을 빠르고 효율적으로 추론하고 서빙하기 위한 엔진에 가깝습니다.

쉽게 말하면 모델은 따로 있고, vLLM은 그 모델을 실제 서비스 환경에서 더 잘 돌리기 위한 실행 계층이라고 보면 됩니다.

같은 모델을 사용하더라도 어떤 추론 엔진 위에서 돌리느냐에 따라 응답 속도, 메모리 사용, 동시 요청 처리 성능이 꽤 달라질 수 있습니다. 그래서 vLLM은 “모델 선택” 다음 단계에서 자주 등장합니다.

vLLM 종류는 어떻게 나눠서 보면 쉬울까

사실 vLLM에 공식적으로 “종류”라는 제품 라인이 따로 있는 건 아닙니다. 대신 실무에서는 어떤 방식으로 쓰느냐에 따라 나눠서 이해하는 편이 훨씬 쉽습니다.

실무에서 자주 말하는 vLLM 사용 형태

1. 오프라인 추론용 vLLM — 파이썬 코드 안에서 직접 호출
2. OpenAI 호환 API 서버형 vLLM — API 서버로 띄워서 호출
3. Docker 기반 vLLM — 컨테이너로 빠르게 배포
4. Kubernetes/Helm 기반 vLLM — 운영 환경에서 확장성 있게 배포
5. 분산 추론용 vLLM — 여러 GPU나 병렬 구성을 활용

즉 “vLLM 종류”라고 할 때는 모델 종류가 아니라 사용 방식과 배포 방식의 차이로 이해하는 게 가장 자연스럽습니다.

1. 오프라인 추론용 vLLM

가장 단순한 형태는 파이썬 코드 안에서 vLLM을 직접 불러서 모델 추론을 수행하는 방식입니다.

이 방식은 “내 코드 안에서 바로 모델을 실행해보고 싶다”, “API 서버까지는 아직 필요 없다”, “배치 처리나 내부 실험을 먼저 해보고 싶다” 같은 상황에서 가장 잘 맞습니다.

이런 사람에게 잘 맞습니다

모델 응답을 코드 안에서 바로 받아보고 싶은 사람, 배치 추론이나 내부 자동화 스크립트에 붙이고 싶은 사람, 서버 구축 전 단계에서 먼저 테스트해보고 싶은 사람에게 적합합니다.

보통 이 단계에서는 모델 로딩, 샘플 프롬프트 테스트, 출력 형식 확인, 성능 감각 파악 정도를 먼저 해보게 됩니다.

2. OpenAI 호환 API 서버형 vLLM

vLLM이 특히 많이 쓰이는 이유 중 하나는 OpenAI 호환 API 서버 형태로 띄울 수 있다는 점입니다.

이 방식으로 실행하면 기존에 OpenAI API를 붙여두었던 코드 구조를 크게 바꾸지 않고도 자체 모델 서버처럼 사용할 수 있습니다.

예를 들어 사내 챗봇, 자동화 워크플로, 웹 서비스 백엔드처럼 HTTP 요청으로 모델을 호출해야 하는 경우에는 이 방식이 가장 실용적입니다.

서버형 vLLM이 잘 맞는 경우

• 프론트엔드나 백엔드에서 HTTP API로 호출할 때
• 여러 사용자가 동시에 접근하는 챗봇 서비스일 때
• OpenAI API와 비슷한 호출 구조를 유지하고 싶을 때
• LangChain, LlamaIndex 같은 도구와 붙일 때

처음 vLLM을 접하는 사람도 실제 서비스 관점에서는 이 서버형 방식을 가장 많이 사용하게 됩니다.

3. Docker 기반 vLLM

로컬 환경에 직접 모든 걸 깔기보다 컨테이너로 빠르게 띄우고 싶은 경우에는 Docker 방식이 편합니다.

이 방식의 장점은 환경 재현이 쉽고, 서버 이관이나 팀 공유도 비교적 편하다는 점입니다. 특히 GPU 서버에서 여러 AI 서비스를 나눠 운영하는 경우에는 컨테이너 기반이 훨씬 관리하기 좋은 편입니다.

개발 초반에는 로컬 파이썬 방식으로 테스트하고, 어느 정도 안정되면 Docker로 옮겨서 운영하는 흐름도 자주 보입니다.

4. Kubernetes/Helm 기반 vLLM

실제 운영 환경에서 확장성과 관리 편의성이 중요해지면 Kubernetes나 Helm 기반 배포를 고려하게 됩니다.

이 단계는 개인 실험보다 팀 단위 서비스 운영에 더 가깝습니다. 여러 노드, 여러 GPU, 오토스케일링, 운영 자동화까지 생각해야 할 때 훨씬 유리합니다.

운영 환경에서 Kubernetes가 잘 맞는 이유

• 배포 자동화가 쉬움
• 자원 관리와 확장성이 좋음
• 장애 대응과 롤링 업데이트에 유리함
• 여러 모델 서버를 체계적으로 운영하기 좋음

처음부터 이 방식으로 시작할 필요는 없지만, 실제 서비스 규모가 커질수록 결국 많이 보게 되는 형태입니다.

5. 분산 추론용 vLLM

모델이 커지거나 요청량이 많아지면 단일 GPU만으로는 한계가 오는 경우가 있습니다. 이때는 분산 추론 구성이 필요해집니다.

vLLM 문서에서는 context parallel, data parallel, expert parallel 같은 병렬화와 확장 관련 항목을 별도로 다루고 있습니다. 즉 단순히 “모델 하나 띄우기”를 넘어서 더 큰 운영 구조까지 고려할 수 있는 방향으로 확장되고 있다고 보면 됩니다.

이 부분은 초보자가 처음부터 건드릴 영역은 아니지만, 나중에 GPU 수를 늘리거나 대형 모델을 다룰 계획이 있다면 미리 개념 정도는 알고 있으면 좋습니다.

vLLM 사용법은 어떤 순서로 익히면 좋을까

처음 시작하는 사람이라면 아래 순서로 접근하는 게 가장 덜 헷갈립니다.

추천 학습 순서

1. 먼저 오프라인 추론으로 모델이 잘 도는지 확인한다
2. 그다음 OpenAI 호환 서버로 띄워 API 호출 구조를 익힌다
3. 필요하면 Docker로 감싼다
4. 운영 환경이 커지면 Kubernetes/Helm로 확장한다
5. 성능 이슈가 커지면 분산 추론과 병렬화를 본다

이 순서가 좋은 이유는 처음부터 복잡한 운영 구조를 보지 않고도 모델 실행 → API화 → 배포 → 확장 흐름을 자연스럽게 익힐 수 있기 때문입니다.

vLLM을 처음 쓸 때 자주 묻는 질문

가장 흔한 질문은 이런 것들입니다.

“로컬에서 바로 써도 되나?”
“OpenAI API처럼 붙일 수 있나?”
“Docker로 올릴 수 있나?”
“쿠버네티스 배포도 가능한가?”
“GPU 여러 장이면 확장할 수 있나?”

결론만 말하면 vLLM은 이런 흐름을 대부분 염두에 두고 발전해온 도구라서, 처음 실험부터 실제 운영 확장까지 비교적 넓은 범위를 커버하는 편입니다.

처음 시작할 때 가장 현실적인 선택

• 혼자 테스트: 오프라인 추론
• 앱 연결: OpenAI 호환 API 서버
• 재현 가능한 배포: Docker
• 운영 자동화: Kubernetes/Helm
• 대규모 성능 확장: 분산 추론

마무리

vLLM은 단순히 “LLM을 실행하는 도구” 정도로만 보면 생각보다 큰 그림을 놓치기 쉽습니다.

실제로는 코드 안에서 돌리는 오프라인 추론부터, OpenAI 호환 API 서버, Docker 배포, Kubernetes 운영, 분산 추론까지 꽤 넓은 사용 방식을 커버하는 도구에 가깝습니다.

그래서 vLLM 종류를 이해할 때는 모델 종류처럼 보기보다 어떤 방식으로 쓰느냐를 중심으로 보는 게 가장 이해가 쉽습니다.