로컬 LLM 프로덕션 서빙 아키텍처: Ollama와 vLLM 기반 고성능 사내 인프라 구축

서론: 클라우드 API 종속 탈피와 사내 프라이빗 AI의 필연성

OpenAI나 Anthropic의 상용 API는 초기 프로토타이핑에는 이상적이지만, 월간 수억 토큰을 소모하는 대규모 프로덕션 환경에 진입하는 순간 감당하기 어려운 비용 청구서로 돌아옵니다. 더욱이 금융, 의료, 제조 등 핵심 기밀 데이터를 다루는 엔터프라이즈 환경에서는 외부 클라우드로의 데이터 전송 자체가 보안 규정(Compliance) 위반이 됩니다.

이에 따라 Llama 3.3, Mistral, Qwen과 같은 오픈소스 가중치 모델을 자체 온프레미스 GPU 서버에 배포하는 **‘프라이빗 추론 인프라’**가 급부상하고 있습니다.

본 칼럼에서는 개발자 친화적인 Ollama와 엔터프라이즈급 처리량을 보장하는 vLLM 엔진의 구조적 차이와 프로덕션 서빙 최적화 기법을 분석합니다.

1. Ollama vs vLLM: 서빙 엔진 구조 비교

비교 항목	Ollama (개인 및 내부 테스트용)	vLLM (프로덕션 엔터프라이즈용)
핵심 타겟	1인 개발자, 로컬 Mac/PC, 간단한 API 서버	동시 접속자 수백 명 이상의 실서비스 배포
추론 백엔드	llama.cpp 기반 (CPU/GPU 하이브리드)	PagedAttention 기반 독자적 CUDA 커널
배치 처리(Batching)	순차 처리 (단일 요청 병목 발생 가능)	Continuous Batching (동적 요청 병합 처리)
처리량(Throughput)	보통 (초당 20~50 토큰 수준)	극대화 (Ollama 대비 5~15배 높은 처리량 달성)
지원 양자화 포맷	GGUF (4-bit, 5-bit, 8-bit)	AWQ, GPTQ, FP8, SqueezeLLM

2. vLLM의 마법: PagedAttention 메모리 혁신

LLM 추론 과정에서 가장 큰 병목은 과거의 토큰 어텐션 상태를 저장하는 **KV 캐시(Key-Value Cache)**입니다. 전통적인 서빙 엔진은 최대 컨텍스트 길이에 맞춰 메모리를 연속적으로 미리 할당하므로, 60~80%의 GPU VRAM이 내부 단편화(Internal Fragmentation)로 낭비되었습니다.

vLLM은 운영체제의 가상 메모리 페이징 기법에서 착안한 PagedAttention을 통해 KV 캐시를 고정 크기의 비연속 메모리 블록으로 쪼개어 관리합니다.

메모리 낭비율을 4% 미만으로 압축
동일한 24GB VRAM GPU(RTX 4090/A10G)에서 동시에 서빙할 수 있는 동시 요청 수(Concurrent Requests)를 4~8배 증가시킴

3. 프로덕션 양자화(Quantization) 전략: AWQ vs FP8

8B~70B 파라미터 모델을 1대의 GPU 서버에서 구동하기 위해서는 정밀도 손실을 최소화하는 양자화 선택이 필수적입니다.

AWQ (Activation-aware Weight Quantization, 4-bit):
- 모든 가중치를 일괄 압축하지 않고, 활성화 출력에 큰 영향을 미치는 1%의 핵심 가중치(Salient Weights)를 선별 보존합니다.
- Perplexity(언어 모델 복잡도) 손실 거의 없이 VRAM 요구량을 1/3로 절감.
FP8 (8-bit Floating Point):
- 최신 NVIDIA Ada Lovelace / Hopper(H100, L40S) 아키텍처의 하드웨어 가속을 100% 활용하는 차세대 표준입니다.
- 수학적 추론 및 복잡한 코딩 태스크에서 16비트 모델과 동일한 성능을 유지합니다.

결론: 데이터 주권과 원가 혁신을 동시에 달성하라

자체 온프레미스 LLM 인프라는 초기 GPU 셋업 비용이 발생하지만, 장기적으로 토큰당 추론 단가를 상용 클라우드 대비 85% 이상 절감할 수 있는 강력한 경제적 해자입니다.

보안이 핵심인 사내 지식 검색이나 대규모 배치 데이터 정제 파이프라인부터 단계적으로 프라이빗 추론 인프라를 도입해 보시기 바랍니다.