문서 확인일: 2026-10-05. vLLM 공식
stable문서의 개념을 기준으로 작성했다. CLI 플래그, 메트릭 이름, 기본 동작은 설치한 이미지 버전의 공식 문서,serve도움말, Pod 시작 로그,/metrics의 HELP·TYPE으로 확정해야 한다. 아래 트래픽·비용·지연 시간 수치는 모두 설명용 가상 예시이며 특정 조직의 측정값이 아니다.
이 글은 vLLM 설치 스크립트나 튜닝 매개변수 목록이 아니다. 내부 LLM 서빙이 필요한지, 그리고 그때 vLLM이 합리적인 선택인지를 판단하려는, vLLM 도입을 검토하는 엔터프라이즈 AI 엔지니어를 위한 글이다. 구체적인 스케줄러 설정과 병목 진단은 시리즈 후속 글에서 이어진다.
1. 답부터: 내부 LLM 서빙이 필요한 이유
많은 팀이 먼저 “어떤 모델을 올릴까?”를 묻지만, 그 전에 데이터가 어디를 지나가야 하는가를 분명히 해야 한다.
- Agent가 사내 문서, 티켓, 고객 프로필을 LLM에 넣는다.
- RAG 파이프라인이 검색 chunk와 메타데이터를 프롬프트에 실어 보낸다.
- 규정·계약·국가별 요구로 원문이 특정 리전·특정 벤더 밖으로 나가면 안 된다.
이 조건이면 “API 키만 발급하면 된다”는 접근은 성립하지 않는다. 내부 서빙은 데이터 경로 통제, 모델·버전 승인, 용량과 비용의 예측 가능성, 지연 시간·동시성에 대한 직접 통제를 동시에 노리는 선택이다. 대신 GPU와 MLOps를 직접 운영해야 한다.
2. 먼저 결정: 외부 API가 여전히 더 나은 경우
내부 GPU 서빙은 만능 답이 아니다. 다음에 해당하면 상용 API나 관리형 endpoint가 여전히 합리적일 수 있다.
| 상황 | 외부·managed가 유리한 이유 |
|---|---|
| 데이터가 공개 가능하거나 이미 익명화·집계됨 | 벤더가 운영·스케일·모델 업데이트를 부담 |
| 트래픽이 불규칙하고 피크가 극단적 | GPU를 상시 구매·유지하기 어려움 |
| 최신 비공개 모델(closed model)·멀티모달·Agent 기능이 핵심 | 자체 호스팅 모델만으로 기능 격차 |
| 팀에 GPU/K8s/추론 엔진 운영 경험이 거의 없음 | 학습 곡선과 장애 대응 비용이 큼 |
| “한 달 PoC” 수준 | 내부 서빙의 승인·보안·관측 정착 시간이 더 김 |
공정하게 보면, 외부 API는 운영 표준화와 빠른 시작을, 내부 vLLM은 데이터 주권과 통제를 산다. “보안 때문에 무조건 내부”도, “비용 때문에 무조건 API”도 단순화다. 실제로는 데이터 분류, SLO, 트래픽 형태, 운영 역량 네 축을 함께 본다.
3. 내부 GPU 서빙을 밀어 올리는 네 가지 압력
보안과 규정
감사·법무·고객 계약은 “모델이 좋다”보다 어디에 로그가 남고, 원문이 어디를 지나는지를 묻는다. 내부 서빙은 VPC 안의 게이트웨이·vLLM·GPU로 경로를 닫을 수 있다. 다만 내부라고 자동으로 안전한 것은 아니다. API key만으로 끝나지 않으며, 네트워크 정책, TLS, 사용자별 quota, /metrics 노출 범위도 설계해야 한다.
데이터 경로
동일한 Agent라도 외부 API는 프롬프트·컨텍스트가 벤더 네트워크로 나간다. 내부 vLLM은 모델 가중치와 KV cache가 조직이 통제하는 GPU·스토리지에 머문다. “학습에 쓰이지 않는다”는 벤더 약속과 “물리적으로 나가지 않는다”는 내부 통제는 다르다.
비용과 예측 가능성
API는 사용량에 비례하는 변동비 모델이다. 내부 GPU는 고정비—장비·전력·인건비·유지—가 크다. 가상 예시만 들어 보자. 월 2억 원 상당의 API 호출이 안정적으로 반복되고, 그 작업 부하가 2×A100급 GPU에서 SLO를 만족한다는 근거가 있다면 내부 전환을 재무 시나리오로 검토할 여지가 생긴다. 반대로 월 수백만 원 수준이면 GPU 상시 운영은 설명하기 어렵다. 실제 숫자는 조직마다 다르며, 여기서는 구조만 제시한다.
성능과 통제
내부 서빙은 “더 빠르다”를 보장하지 않는다. 대신 모델 버전 고정, 배치 정책, 동시 요청 상한, 공통 접두부 설계를 서비스 SLO에 맞게 조정할 수 있다. Agent가 짧은 호출을 많이 보내는 작업 부하는 API 요청 한도보다 자체 scheduler 정책이 더 맞을 수 있다—역시 가설이며 벤치마크로 확인해야 한다.
- 보안 · 규정데이터가 조직 경계를 넘어도 되는가?
- 트래픽 · SLO동시 요청과 지연 목표를 GPU로 감당할 수 있는가?
- 운영 역량GPU, Kubernetes, 모델 승인, 패치를 누가 맡는가?
- 비용 · 예측 가능성고정 GPU + 운영비가 API 대비 설명 가능한가?
4. vLLM이 하는 일과 하지 않는 일
하는 일(요약):
- OpenAI 호환 HTTP API 등으로 추론 요청을 받는다.
- Continuous batching과 PagedAttention 계열 메모리 관리로 여러 요청의 prefill·decode를 GPU에서 묶는다.
- KV cache, (버전·설정에 따라) prefix caching, 스트리밍 응답을 제공한다.
- Prometheus
/metrics등으로 서버 측 지표를 노출한다. Production Metrics
하지 않는 일:
- 데이터 분류, IAM, 감사 정책 자체를 대신하지 않는다.
- 모델 법무·보안 승인, 라이선스 준수, 가중치 공급망 검증을 대신하지 않는다.
- Kubernetes, GPU 드라이버, 노드 패치, DCGM·Prometheus·알림을 자동으로 완성하지 않는다.
- “Agent 오케스트레이션”, “RAG 품질”, “평가 체계(harness)”를 제공하지 않는다—앱 계층 문제다.
vLLM을 도입하면 추론 엔진(inference engine) 하나를 얻는 것이지, 엔터프라이즈 AI 플랫폼 전체를 얻는 것은 아니다.
5. 대안과 vLLM의 경계
| 접근 | 적합한 경우 | 한계 |
|---|---|---|
| 상용 LLM API | 데이터 외부 반출 가능, 빠른 시작, 최신 모델 | 데이터 경로·단가·요청 한도 통제 제한 |
| 클라우드 관리형 오픈 모델 endpoint | VPC/peering으로 경로 일부 통제 | 여전히 클라우드 계약·리전·비용 구조에 묶임 |
| Transformers + FastAPI (단순 서버) | PoC, 저동시성, 한두 모델 | 동시 요청·KV 메모리·배치 효율을 직접 구현해야 함 |
| vLLM | 온프레 GPU에서 다수 동시 추론, 스트리밍, 운영 메트릭 | GPU/K8s/튜닝·관측 역량 필요 |
“FastAPI에 model.generate() 한 줄”은 데모에는 충분하다. Agent·RAG·채팅이 동시에 붙으면 KV cache 고갈, 꼬리 지연시간(tail latency), GPU 유휴 시간이 동시에 나타난다. vLLM은 그 문제를 스케줄러와 메모리 관리로 다루는 쪽에 가깝다. Optimization and Tuning
PagedAttention, continuous batching, prefix caching — 사용자가 느끼는 변화
구현 원리보다 사용자에게 보이는 변화로 설명한다.
- PagedAttention / KV 메모리 관리: 긴 문맥·많은 동시 대화에서도 GPU 메모리를 “한 덩어리”처럼 쓰지 않게 나눠, 더 많은 요청을 동시에 살려 둘 여지를 만든다. 사용자는 “갑자기 전부 거절”보다 대기열·스트리밍이 유지되는 쪽을 기대한다.
- Continuous batching: 새 요청이 들어와도 decode 중인 batch에 추가하거나 다음 iteration에 합친다. 사용자는 여러 Agent가 동시에 호출해도 GPU 유휴 시간을 줄여 높아지는 처리량을 본다.
- Automatic prefix caching: 동일한 토큰 접두부의 KV를 재사용한다. 시스템 프롬프트·공통 RAG 지시·고정 few-shot이 앞에 있으면 첫 token이 나올 때까지의 시간, 즉 TTFT, 가 줄어들 수 있다. 의미 유사 문장 cache나 완성 답 cache가 아니다. 요청마다 타임스탬프를 접두부에 붙이면 재사용이 끊긴다. Automatic Prefix Caching
- 요청 A · B · C 도착
- Scheduler: prefill · decode 배치
- GPU: 가중치 + KV cache
- 각 클라이언트로 token streaming
6. 아키텍처: 앱 → 게이트웨이 → vLLM → GPU
운영에서 흔한 책임 경계는 다음과 같다.
- 1내부 앱Agent · RAG · 채팅이 요청을 보낸다
- 2게이트웨이인증 · 요청 한도 · 감사 로그
- 3Kubernetes ServicevLLM Pod로 요청을 전달
- 4vLLM PodAPI · scheduler · streaming을 처리
- 5GPU · 모델 저장소가중치와 KV cache를 사용
- 6관측Prometheus · DCGM · 로그로 상태를 확인
게이트웨이는 vLLM 앞에서 신원·요청 제한·경로 노출 최소화를 담당한다. vLLM Pod는 추론 스케줄링을 담당한다. GPU 노드는 드라이버와 device plugin을 통해 할당된다. Kubernetes GPU scheduling GPU utilization만으로는 충분하지 않다. KV cache 사용률, 대기 요청, TTFT·TPOT을 vLLM 메트릭과 DCGM counter로 함께 확인해야 한다. DCGM Exporter counters
7. 도입 전 체크리스트
| 영역 | 확인 질문 |
|---|---|
| 데이터 | 어떤 데이터 등급이 내부 GPU에서만 처리되어야 하는가? 로그·트레이스에 원문이 남는가? |
| 모델 | 승인된 가중치·라이선스·버전 고정 정책이 있는가? |
| GPU | 필요한 VRAM·노드 수·장애 시 성능 저하 시나리오는? |
| 네트워크 | 게이트웨이 TLS, NetworkPolicy, /metrics 내부 전용 여부 |
| SLO | TTFT·스트리밍 간격·E2E·오류율 목표가 정의됐는가? |
| 운영 | 당번 체계(on-call), 롤백, 이미지 버전 고정, CVE 패치 주기, 모델 교체 runbook |
| 비용 | GPU 상시 + 인건비 vs API 시나리오가 문서화됐는가? |
하나라도 “아직 모름”이면, 전면 배포보다 아래 검증 단계가 맞다.
8. 작은 검증부터 운영까지
- 단일 GPU, 단일 모델, 낮은 동시성 — OpenAI 호환 클라이언트로 기능·스트리밍·도구 호출(필요 시)을 고정 버전으로 검증. Getting Started
- 대표 요청 재현 — Agent/RAG에서 나온 프롬프트 길이 분포·동시성을 합성 trace로 재현(실제 로그 export가 없으면 합성). SLO 기준값 기록.
- 관측 연결 —
/metricsscrape, GPU DCGM, 대시보드에 TTFT·queue·KV cache·preemption(노출 시) 패널. - 게이트웨이·quota — 내부 앱 하나만 연결, 인증·요청 한도·감사 필드 확정.
- 확장 결정 — replica, 모델 복제, queue 앞 대기열, 또는 GPU 추가. 튜닝은 vLLM 튜닝이란 무엇인가?에서 이어진다.
9. 후속 글: 튜닝과 메트릭
이 시리즈 Internal LLM Serving의 다음 단계는 “왜 내부에서, 왜 vLLM으로”을 넘어 어떻게 안정적으로 돌릴지다.
- vLLM 튜닝이란 무엇인가? — 제한된 GPU에서 scheduler, prefill·decode, KV cache, 주요 설정과 SLO 기반 tuning loop.
- vLLM은 왜 느려졌을까? — TTFT·TPOT·대기열·prefill·KV cache·선점을 함께 읽는 운영 진단.
도입 판단이 “예”에 가깝다면, PoC Pod 하나를 띄우기 전에 데이터 경로 도식과 체크리스트를 이해관계자와 맞추는 것이 설치 명령보다 먼저일 때가 많다.
Discussion
토론
질문, 정정, 반례, 다른 해석이 있다면 남겨 주세요.