vLLM의 비상 회복 설계: 성능과 안정성의 융합

대규모 언어 모델을 사용하는 서비스에서 요청 중단은 흔한 문제다. 특히 긴 대화 세션 중 연결이 끊기거나, GPU 메모리 과잉 사용으로 인해 서버가 다운되면, 사용자는 이전 대화 내용을 잃고 다시 처음부터 시작해야 한다. 이는 경험적 불만을 넘어 생산 환경에서의 시스템 취약점을 노출한다.

하지만 vLLM 같은 최신 추론 엔진은 전통적인 장애 복구 방식(예: 체크포인트 저장, 상태 백업)에 의존하지 않는다. 대신, 내부 아키텍처의 혁신을 통해 장애 발생 후 복귀 시간을 몇 밀리초 수준으로 압축한다. 이는 단순한 기술적 우위를 넘어서, 시스템 전체의 신뢰성 정의를 재편하고 있다.

장치 메모리 관리의 근본적 변화: PagedAttention 기술

기존의 트랜스포머 추론에서는 각 타임스텝의 키-값 캐시 (KV Cache)가 연속된 메모리 공간에 저장되어야 하며, 이로 인해 메모리 조각화가 심각하게 발생한다. 긴 입력 시퀀스일수록 메모리 부족(결함: OOM) 위험이 증가하며, 복구 시 전체 캐시 재생성이 필요하다.

vLLM의 핵심 기술인 PagedAttention는 운영체제의 가상 메모리 개념을 차용하여 이 문제를 해결한다. 이 기술은 캐시를 고정 크기의 페이지(예: 8개 토큰) 단위로 나누고, 논리적 위치와 물리적 주소 사이의 매핑 테이블을 유지한다.

from vllm import LLM

model = LLM(
    model="meta-llama/Llama-2-7b-chat-hf",
    max_model_len=32768,
    gpu_memory_utilization=0.9,
    enable_prefix_caching=True
  )
  

• 비연속 메모리 할당: 각 페이지는 GPU 내 어디서든 배치 가능 → 메모리 조각화 완전 제거
• 세밀한 재사용: 여러 요청 간 공유 가능한 페이지 활용 → 메모리 사용률 90% 이상 달성
• 복사 없이 확장: 새로운 토큰 추가 시 전체 캐시 복사 없이 페이지 추가 → 성능 저하 방지

이 구조 덕분에, 요청이 중단되더라도 그 상태를 "재생성"하는 비용이 극히 낮아진다. 즉, 복구는 복잡한 작업이 아니라, 단순한 스케줄링 결정으로 전환된다.

동적 배치 처리: 자율적인 실행 플로우

vLLM은 고정 배치 방식이 아닌 연속적 동적 배치 (Continuous Batching)를 적용한다. 이는 요청을 실시간으로 수집하고, 현재 가용 리소스에 따라 적절한 배치 크기로 묶어 처리한다.

이 방식은 다음과 같은 장점을 제공한다:

• 하나의 요청 실패 시 다른 요청에 영향 없음
• 부하 증가 시 자동으로 배치 크기 감소 → 시스템 붕괴 방지
• 클라이언트 재접속 시 request_id 기반으로 이전 상태 복원 가능

from vllm import AsyncLLMEngine, AsyncEngineArgs
from vllm import SamplingParams

engine = AsyncLLMEngine.from_engine_args(
    AsyncEngineArgs(
        model="Qwen/Qwen-7B-Chat",
        max_num_seqs=128,
        max_num_batched_tokens=2048,
        scheduling_policy="fcfs"
    )
)

async def stream_generator(prompt):
    results = engine.generate(
        prompt,
        SamplingParams(max_tokens=256),
        request_id=f"session-{hash(prompt)}"
    )
    async for result in results:
        yield result.outputs[0].text
  

request_id는 재시도 시 이미 처리된 부분을 건너뛰도록 하는 핵심 요소다. 이를 통해 부분 복구 (partial recovery)가 가능해진다.

표준화 인터페이스 및 양자화 지원: 무감각한 복구 경험

vLLM는 OpenAI API 호환 인터페이스를 제공하여, 클라이언트 코드 변경 없이 다양한 환경에 통합할 수 있다.

python -m vllm.entrypoints.openai.api_server \
    --model Qwen/Qwen-1_8B-Chat-Int4 \
    --host 0.0.0.0 \
    --port 8080
  

import openai

openai.api_key = "EMPTY"
openai.base_url = "http://localhost:8080/v1/"

response = openai.completions.create(
    model="Qwen-1_8B-Chat-Int4",
    prompt="어텐션 메커니즘을 설명하세요.",
    max_tokens=200
)
print(response.choices[0].text)
  

이처럼 인터페이스 일관성은 장애 발생 후에도 사용자가 느끼지 못하도록 만든다. Nginx 또는 Kubernetes의 리밸런싱 및 재시도 정책과 결합하면, 자동 재연결과 상태 복원이 가능하다.

또한, GPTQ/AWQ 기반의 4비트 양자화 모델을 직접 지원함으로써, 소형 그래픽 카드에서도 실행이 가능하다.

이는 장애 발생 시 보조 서버가 작은 양자화 모델로 신속히 대응할 수 있는 내려가기 전략 (graceful degradation)을 가능하게 한다.

실제 운영 환경에서의 강성 구현

Kubernetes 환경에서 실행될 경우, vLLM은 아래와 같은 아키텍처로 구성된다.

이 구조는 다음과 같은 사례에 효과적으로 대응한다:

• 고병렬 환경에서의 OOM: PagedAttention 덕분에 동일 메모리로 3~5배 더 많은 동시 요청 처리 가능
• 긴 생성 중 단절: enable_prefix_caching + cache_refresh_seconds 설정으로 재시도 시 이전 컨텍스트 자동 복원
• 모델 업데이트 중 중단: K8s 롤링 업데이트를 통해 새 버전 프리온보딩 → 점진적 트래픽 전환 → 기존 팟 정상 종료

주의사항 및 권장 설정

• TTL 제한: KV 캐시의 지속 시간을 30~60초로 설정하여 메모리 누수 방지
• 중복 요청 방지: request_id에 대해 IP 또는 서명 검증 추가
• 모니터링 통합: /metrics 엔드포인트 노출 → GPU 사용률, 지연 시간, 오류율 추적
• 안전 종료: SIGTERM 수신 시 현재 처리 중인 작업 완료 후 종료

결론: 성능이 안정성이다

vLLM은 전통적인 장애 복구 메커니즘을 따르지 않는다. 체크포인트, 공유 상태 저장소, 분산 일관성 알고리즘 등은 전혀 사용하지 않는다.

그러나 이는 오히려 더 진보적인 접근이다. 장애 발생 시 비용을 0에 가깝게 만들면, 복구 자체가 의미 없는 일이 된다.

메모리 효율성, 스케줄링 유연성, 인터페이스 표준화 — 이 세 가지가 결합되면, "시스템이 멈췄다"는 사실이 사용자에게 거의 느껴지지 않는다. 진정한 신뢰성은 복구 기능이 아니라, 복구가 필요 없도록 하는 설계에 있다.

앞으로는 자동 백업, 다중 지역 복제 등의 도구와 결합해, vLLM은 단순한 추론 엔진을 넘어 엔터프라이즈급 AI 서비스 중심으로 진화할 전망이다. 지금 이 순간, 이미 올바른 길을 걷고 있다.