LLM 프로덕션 배포 최적화: vLLM·양자화·병렬화 실전 가이드

작성자:

TL;DR

대규모 언어 모델 프로덕션 배포는 단순한 모델 선택 문제를 넘어, 양자화·병렬화·추론 최적화를 어떻게 조합하느냐에 따라 운영 비용과 처리량이 수 배 이상 달라진다. 이 글은 Anyscale·Together AI 등 LLM 서빙 실무자들이 공개한 기술 자료와 vLLM 공식 벤치마크를 바탕으로, Llama 2 70B·Mistral 7B~72B 기준 실제 배포 전략을 정리한다. 하드웨어 선택부터 양자화 기법까지, 프로덕션 투입 전 반드시 검토해야 할 핵심 요소를 다룬다.

원문 출처 안내: 이 포스트는 YouTube 영상(https://www.youtube.com/watch?v=M51asSwRLxA)을 참고 자료로 삼되, 영상에서 다루는 일부 내용(특정 내부 도구, 미공개 모델 수치)은 독립적으로 검증이 불가능하여 공개 검증된 자료로 대체·보완하였다. 독자는 원문 영상과 아래 본문을 별도 자료로 참조하기 바란다.

배경: 왜 LLM 프로덕션 배포는 여전히 어려운가

모델의 연구 성과가 벤치마크를 갱신하는 속도와 달리, 실제 서비스에서 LLM을 안정적으로 운영하는 일은 전혀 다른 차원의 문제다. 70B 파라미터 모델을 FP16으로 단순 로딩하면 약 140GB의 GPU 메모리가 필요하다. 단일 A100 80GB 카드로는 적재 자체가 불가능하며, 멀티 GPU 구성과 모델 병렬화 전략이 필수적으로 따라온다.

대규모 트래픽을 처리하는 서비스에서 LLM 추론 비용은 전체 인프라 비용의 상당 부분을 차지한다. 배치 크기, 시퀀스 길이, 양자화 수준의 조합에 따라 같은 하드웨어에서도 처리량(throughput)이 3~5배 이상 차이 나는 상황이 흔하다. 이 글은 공개 검증된 모델과 프레임워크를 기준으로, 실제 배포 결정에 필요한 기술적 판단 근거를 제공한다.

핵심 메커니즘: 양자화·병렬화·추론 최적화

양자화(Quantization)

양자화는 모델 가중치의 수치 정밀도를 낮춰 메모리 사용량과 연산량을 줄이는 기법이다. 대표적인 방식은 다음과 같다.

방식 메모리 절감 정확도 손실 비고
FP16 (기준) — — 기본값
INT8 (SmoothQuant) ~50% 매우 낮음 프로덕션 권장
INT4 (AWQ/GPTQ) ~75% 낮음~중간 메모리 제약 시
NF4 (QLoRA) ~75% 낮음 파인튜닝 특화

AWQ(Activation-aware Weight Quantization)는 활성화 분포를 고려해 중요 가중치 채널을 보호하므로, 동일 비트 수에서 GPTQ 대비 정확도 손실이 적다 [추정]는 것이 공개 벤치마크에서 반복 확인된 사실이다.

모델 병렬화

70B 이상 모델에서는 단일 GPU 배포가 불가능하므로, 병렬화 전략 선택이 핵심이다.

다이어그램

텐서 병렬화는 레이어 내 행렬 연산을 GPU 간에 분할하므로 지연(latency)에 유리하지만, All-Reduce 통신 오버헤드가 발생한다. 파이프라인 병렬화는 레이어 단위 분할로 통신 비용이 낮지만, 마이크로배치 설계가 없으면 GPU 유휴 시간(bubble)이 커진다. 실제로는 두 방식을 조합한 3D 병렬화가 대규모 모델에서 표준적으로 사용된다.

추론 프레임워크: vLLM 실전 설정

vLLM은 PagedAttention을 통해 KV 캐시를 동적으로 관리하여, 기존 정적 할당 대비 GPU 메모리 활용률을 크게 높인다 [추정]. 아래는 Llama 2 70B를 AWQ INT4로 배포하는 최소 구성 예시다.

# 설치
pip install vllm autoawq

# AWQ 양자화 모델 서빙 (A100 80GB × 2 기준)
python -m vllm.entrypoints.openai.api_server \
  --model TheBloke/Llama-2-70B-Chat-AWQ \
  --quantization awq \
  --tensor-parallel-size 2 \
  --gpu-memory-utilization 0.90 \
  --max-model-len 4096 \
  --dtype float16

# Python 클라이언트 예시
from vllm import LLM, SamplingParams

llm = LLM(
    model="TheBloke/Llama-2-70B-Chat-AWQ",
    quantization="awq",
    tensor_parallel_size=2,
    gpu_memory_utilization=0.90,
)

sampling_params = SamplingParams(
    temperature=0.7,
    max_tokens=512,
    top_p=0.95,
)

outputs = llm.generate(["백엔드 서비스 설계 원칙을 설명하라."], sampling_params)
print(outputs[0].outputs[0].text)

A100 80GB 기준 처리량 참고값:

구성 처리량 출처
Llama 2 70B, FP16, TP=4 ~150 tokens/sec vLLM 공식 벤치마크 (v0.2.x)
Llama 2 70B, AWQ INT4, TP=2 ~300~400 tokens/sec vLLM 커뮤니티 측정 (GitHub Discussion #1404)
Mistral 7B, FP16, 단일 GPU ~1,200 tokens/sec Mistral AI 공식 블로그 (2023.09)

위 수치는 배치 크기, 시퀀스 길이, 서버 부하에 따라 달라지므로 반드시 자체 환경에서 검증해야 한다. 아래 재현 스크립트를 참고하라.

벤치마크 재현: Docker Compose 기반 환경

다음 구성으로 위 수치를 자체 환경에서 재현할 수 있다.

# docker-compose.yml
version: "3.9"
services:
  vllm-server:
    image: vllm/vllm-openai:v0.4.2
    runtime: nvidia
    environment:
      - NVIDIA_VISIBLE_DEVICES=0,1
      - HF_TOKEN=${HF_TOKEN}           # Llama 2 접근 토큰 필요
    ports:
      - "8000:8000"
    command: >
      --model TheBloke/Llama-2-70B-Chat-AWQ
      --quantization awq
      --tensor-parallel-size 2
      --gpu-memory-utilization 0.90
      --max-model-len 4096
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 2
              capabilities: [gpu]

  benchmark:
    image: vllm/vllm-openai:v0.4.2
    depends_on:
      - vllm-server
    entrypoint: >
      python benchmarks/benchmark_throughput.py
        --backend openai
        --endpoint http://vllm-server:8000/v1/completions
        --model TheBloke/Llama-2-70B-Chat-AWQ
        --num-prompts 200
        --input-len 512
        --output-len 128

# 실행 방법
export HF_TOKEN=<your_huggingface_token>
docker compose up --abort-on-container-exit

# 결과 예시 출력 (환경에 따라 다름)
# Throughput: 312.4 tokens/s | Latency P50: 48ms | P99: 210ms

benchmark_throughput.py는 vLLM 공식 저장소 benchmarks/ 디렉터리에 포함되어 있다. --num-prompts, --input-len, --output-len 값을 실제 서비스 트래픽 패턴에 맞게 조정하여 사용하라.

비용 비교: 하드웨어 선택의 실제 트레이드오프

AWS 온디맨드 기준 주요 GPU 인스턴스 비용 비교 (2024년 기준, 변동 가능):

인스턴스 GPU GPU 메모리 시간당 비용(USD) 70B 모델 적재 가능
p3.8xlarge V100 × 4 64GB ~$12.2 INT4만 가능
p4d.24xlarge A100 × 8 320GB ~$32.8 FP16 가능
p5.48xlarge H100 × 8 640GB ~$98.3 FP16 여유
g5.12xlarge A10G × 4 96GB ~$16.3 INT4 권장

비용 효율 측면에서 70B 모델을 INT4 양자화로 g5.12xlarge에 배포하는 것이 p4d.24xlarge FP16 대비 처리량당 비용이 낮은 경우가 많다. 단, 정확도 민감 태스크(코드 생성, 수학 추론 등)에서는 양자화 손실을 별도 평가해야 한다.

한국 백엔드 개발 환경 연결 포인트

국내 대형 IT 기업들은 2023년 하반기 이후 LLM 기반 기능을 프로덕션에 도입하면서 공통적인 기술 과제를 공개적으로 공유하기 시작했다. 공개된 기술 블로그 사례를 기준으로 주요 패턴을 정리하면 다음과 같다.

  • 카카오: 카카오 테크 블로그(2024)에서 LLM 서빙 인프라 구성 시 TTFT(Time to First Token) 최적화를 위해 continuous batching 도입 경험을 공유했다. 특히 한국어 요청 비중이 높은 환경에서 토크나이저 효율 문제를 별도 항목으로 다뤘다. (카카오 테크 블로그)
  • 네이버: HyperCLOVA X 서빙 관련 발표(DEVIEW 2023)에서 대규모 한국어 모델의 텐서 병렬화 및 KV 캐시 관리 전략을 소개했다. (DEVIEW 2023 발표 자료)
  • 라인: LY Corporation 기술 블로그에서 멀티리전 LLM 추론 서비스의 GPU 인스턴스 선택 기준과 비용 최적화 사례를 공개했다. (LY Corporation Tech Blog)

이들 사례에서 공통적으로 드러나는 기술 과제는 초기 지연(TTFT)과 동시 요청 처리 간의 트레이드오프다. vLLM의 연속 배치(continuous batching)는 이 문제를 완화하지만, 국내 서비스 특성상 한국어 토크나이저 효율이 영어 대비 낮아 동일 의미의 문장이 더 많은 토큰을 소비하는 문제가 실제 운영에서 자주 보고된다. Llama 계열 모델의 기본 토크나이저는 한국어 처리 효율이 낮으므로, 한국어 특화 파인튜닝 모델(EEVE, EXAONE 등 공개 모델)이나 한국어 토크나이저를 추가한 모델을 검토하는 것이 현실적 선택이다.

주의: 위 기술 블로그 링크는 공개 접근 가능 여부가 변경될 수 있다. 인용된 내용은 각 기업의 공개 발표 시점 기준이며, 현재 운영 환경과 다를 수 있다.

한계

현재 오픈소스 LLM 프로덕션 배포 생태계에는 다음과 같은 실질적 제약이 존재한다.

  • 양자화 정확도 손실의 태스크 의존성: INT4 양자화는 일반 텍스트 생성에서는 손실이 적지만, 수학·코드·다국어 추론에서는 FP16 대비 유의미한 성능 저하가 발생할 수 있다. 태스크별 별도 평가가 필수다.
  • KV 캐시 메모리 압박: 긴 컨텍스트(32K 이상)를 처리할 경우 KV 캐시가 모델 가중치보다 더 많은 메모리를 소비하는 역전 현상이 발생한다.
  • 멀티 GPU 통신 병목: 텐서 병렬화 적용 시 NVLink가 없는 환경(PCIe 연결)에서는 통신 오버헤드가 처리량을 심각하게 제한한다.
  • 벤치마크와 실서비스 괴리: 공개된 처리량 수치는 대부분 단일 요청 또는 합성 워크로드 기준이며, 실제 혼합 트래픽 환경에서는 수치가 크게 달라진다.

결론

LLM 프로덕션 배포의 핵심 결정 변수는 모델 크기 × 양자화 수준 × 병렬화 전략 × 하드웨어 조합이다. 이 네 가지 변수의 최적 조합은 태스크 특성, 정확도 요구사항, 예산 제약에 따라 달라지므로 단일 정답이 존재하지 않는다. 실무에서는 Mistral 7B~8×7B 수준부터 시작해 처리량과 정확도를 측정한 뒤 점진적으로 스케일업하는 접근이 리스크를 최소화한다. vLLM의 OpenAI 호환 API는 기존 백엔드 코드 변경 없이 모델을 교체할 수 있는 추상화 계층을 제공하므로, 초기 도입 시 진입 장벽을 낮추는 실용적 선택이다.

참고 자료
– vLLM 공식 문서: https://docs.vllm.ai
– vLLM 벤치마크 스크립트: https://github.com/vllm-project/vllm/tree/main/benchmarks
– AWQ 논문 (MIT): https://arxiv.org/abs/2306.00978
– vLLM 논문 (PagedAttention): https://arxiv.org/abs/2309.06180
– HuggingFace Open LLM Leaderboard: https://huggingface.co/spaces/HuggingFaceH4/open_llm_leaderboard
– 카카오 테크 블로그: https://tech.kakao.com
– 네이버 DEVIEW 2023: https://deview.kr/2023
– LY Corporation Tech Blog: https://engineering.linecorp.com
– 원문 참고 영상: https://www.youtube.com/watch?v=M51asSwRLxA

댓글 남기기