왜 내부 GPU에서 vLLM으로 LLM을 서빙하는가?

문서 확인일: 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 부담을 감수하는 대가다.

내부 앱 · Agent프롬프트 · 검색 결과 · PII인터넷 · 벤더 리전상용 LLM API

내부 앱 · Agent동일 데이터사내 VPC · 게이트웨이vLLM · GPU · 모델 저장소

2. 먼저 결정: 외부 API가 여전히 더 나은 경우

내부 GPU 서빙은 만능 답이 아니다. 다음에 해당하면 상용 API나 managed endpoint가 여전히 합리적일 수 있다.

상황	외부·managed가 유리한 이유
데이터가 공개 가능하거나 이미 익명화·집계됨	벤더가 운영·스케일·모델 업데이트를 부담
트래픽이 불규칙하고 피크가 극단적	GPU를 상시 구매·유지하기 어려움
최신 closed 모델·멀티모달·에이전트 기능이 핵심	자체 호스팅 모델만으로 기능 격차
팀에 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 호출이 안정적으로 반복되고, 그 workload가 2×A100급 GPU에서 SLO를 만족한다는 근거가 있다면 내부 전환을 재무 시나리오로 검토할 여지가 생긴다. 반대로 월 수백만 원 수준이면 GPU 상시 운영은 설명하기 어렵다. 실제 숫자는 조직마다 다르며, 여기서는 구조만 제시한다.

성능과 통제

내부 서빙은 “더 빠르다”를 보장하지 않는다. 대신 모델 pin, 배치 정책, 동시 요청 상한, prefix 설계를 서비스 SLO에 맞게 조정할 수 있다. Agent가 짧은 호출을 많이 보내는 workload는 API rate limit보다 자체 scheduler 정책이 더 맞을 수 있다—역시 가설이며 벤치마크로 확인해야 한다.

• 보안 · 규정데이터가 조직 경계를 넘어도 되는가?
• 트래픽 · SLO동시 요청과 지연 목표를 GPU로 감당할 수 있는가?
• 운영 역량GPU, Kubernetes, 모델 승인, 패치를 누가 맡는가?
• 비용 · 예측 가능성고정 GPU + 운영비가 API 대비 설명 가능한가?

4. vLLM이 하는 일과 하지 않는 일

하는 일(요약):

• OpenAI 호환 HTTP API 등으로 추론 요청을 받는다.
• Continuous batching과 PagedAttention 계열 메모리 관리로 여러 sequence의 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	데이터 외부 반출 가능, 빠른 시작, 최신 모델	데이터 경로·단가·rate limit 통제 제한
Cloud managed open model endpoint	VPC/peering으로 경로 일부 통제	여전히 클라우드 계약·리전·비용 구조에 묶임
Transformers + FastAPI (단순 서버)	PoC, 저동시성, 한두 모델	동시 요청·KV 메모리·배치 효율을 직접 구현해야 함
vLLM	온프레 GPU에서 다수 동시 추론, 스트리밍, 운영 메트릭	GPU/K8s/튜닝·관측 역량 필요

“FastAPI에 model.generate() 한 줄”은 데모에는 충분하다. Agent·RAG·채팅이 동시에 붙으면 KV cache 고갈, tail latency, GPU idle이 동시에 나타난다. vLLM은 그 문제를 스케줄러와 메모리 관리로 다루는 쪽에 가깝다. Optimization and Tuning

PagedAttention, continuous batching, prefix caching — 사용자 관점

구현 세부보다 체감으로 정리한다.

• PagedAttention / KV 메모리 관리: 긴 문맥·많은 동시 대화에서도 GPU 메모리를 “한 덩어리”처럼 쓰지 않게 나눠, 더 많은 요청을 동시에 살려 둘 여지를 만든다. 사용자는 “갑자기 전부 거절”보다 대기열·스트리밍이 유지되는 쪽을 기대한다.
• Continuous batching: 새 요청이 들어와도 decode 중인 batch에 끼워 넣거나 다음 iteration에 합친다. 사용자는 여러 Agent가 동시에 호출해도 GPU가 한가한 시간을 줄인 throughput을 본다.
• Automatic prefix caching: 동일한 토큰 접두부의 KV를 재사용한다. 시스템 프롬프트·공통 RAG 지시·고정 few-shot이 앞에 있으면 첫 토큰까지 시간, 즉 TTFT, 가 줄어들 수 있다. 의미 유사 문장 cache나 완성 답 cache가 아니다. 요청마다 타임스탬프를 접두부에 붙이면 재사용이 끊긴다. Automatic Prefix Caching

1. 요청 A · B · C 도착
2. Scheduler: prefill · decode 배치
3. GPU: 가중치 + KV cache
4. 각 클라이언트로 token streaming

6. 아키텍처: 앱 → 게이트웨이 → vLLM → GPU

운영에서 흔한 경로는 다음과 같다.

내부 Agent · RAG · 채팅
        ↓  (인증 · quota · 감사 로그)
   API Gateway / Ingress
        ↓
 Kubernetes Service
        ↓
 vLLM Pod (API + scheduler)
        ↓
 GPU + 모델 가중치 (PVC · object store)
        ↓
 Prometheus · DCGM · 로그 (관측)

게이트웨이는 vLLM 앞에서 신원·요청 제한·경로 노출 최소화를 담당한다. vLLM Pod는 추론 스케줄링을 담당한다. GPU 노드는 드라이버·device plugin 아래에서 할당한다. Kubernetes GPU scheduling GPU utilization만 보면 부족하고, KV cache 사용률, 대기 요청, TTFT·TPOT을 vLLM 메트릭과 DCGM counter를 함께 본다. DCGM Exporter counters

7. 도입 전 체크리스트

영역	확인 질문
데이터	어떤 classification이 내부 GPU로만 허용되는가? 로그·트레이스에 원문이 남는가?
모델	승인된 가중치·라이선스·버전 pin 정책이 있는가?
GPU	필요한 VRAM·노드 수·장애 시 degrade 시나리오는?
네트워크	게이트웨이 TLS, NetworkPolicy, /metrics 내부 전용 여부
SLO	TTFT·스트리밍 간격·E2E·오류율 목표가 정의됐는가?
운영	on-call, 롤백, 이미지 pin, CVE 패치 주기, 모델 교체 runbook
비용	GPU 상시 + 인건비 vs API 시나리오가 문서화됐는가?

하나라도 “아직 모름”이면, 전면 rollout보다 아래 검증 단계가 맞다.

8. 작은 검증부터 운영까지

1. 단일 GPU, 단일 모델, 낮은 동시성 — OpenAI 호환 클라이언트로 기능·스트리밍·도구 호출(필요 시)을 고정 버전으로 검증. Getting Started
2. 대표 workload replay — Agent/RAG에서 나온 프롬프트 길이 분포·동시성을 가상 trace로 재현(실제 로그 export가 없으면 합성). SLO baseline 기록.
3. 관측 연결 — /metrics scrape, GPU DCGM, 대시보드에 TTFT·queue·KV cache·preemption(노출 시) 패널.
4. 게이트웨이·quota — 내부 앱 하나만 연결, 인증·rate limit·감사 필드 확정.
5. 확장 결정 — 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 하나를 띄우기 전에 데이터 경로 diagram과 체크리스트를 이해관계자와 맞추는 것이 설치 명령보다 먼저일 때가 많다.