넷플릭스, 자체 LLM 서빙 플랫폼으로 프로덕션 환경 통합

넷플릭스는 외부 LLM API 의존 대신 자체 LLM 서빙 플랫폼을 구축하여 프로덕션 환경 통합을 추구함

vLLM 엔진과 NVIDIA Triton을 핵심 기술로 채택하여 모델 아키텍처 유연성과 운영 효율성을 확보함

레드-블랙(Red-Black) 및 버전드(Versioned) 배포 전략을 통해 안정적인 모델 업데이트와 제로 다운타임(Zero Downtime)을 달성함

데이터 미저장 정책(Zero-Retention Policy)을 적용하여 민감한 사용자 데이터의 유출 위험을 최소화함

vLLM 엔진 선택과 TensorRT-LLM 대비 장점

넷플릭스는 초기 TensorRT-LLM에서 vLLM으로 추론 엔진을 전환하며 운영 적합성(Operational Fit)을 우선시했다. vLLM은 커스텀 모델 아키텍처(Custom Model Architecture)를 별도 컴파일 없이 로드할 수 있어 비표준 모델의 반복 개발 속도를 높인다. 또한, 커스텀 디코딩 로직(Custom Decoding Logic)을 위한 확장성 후킹(Extensibility Hooking)을 지원하여 복잡한 제약 조건 처리에 유리하며, 디버깅 용이성(Debuggability) 측면에서도 컴파일된 엔진 대비 이점을 가진다. 기존 연구 커뮤니티에서의 높은 사용 빈도는 연구-프로덕션 전환 비용(Research-to-Production Handoff Cost) 절감에도 기여했다.

Triton vLLM 백엔드와 Python 백엔드 비교

모델 패키징 시 Triton의 vLLM 백엔드는 모델 가중치와 토크나이저만 명시하는 JSON 설정으로 동적 I/O 텐서 명세(Dynamic I/O Tensor Specification) 생성을 지원한다. 이는 모델과 프론트엔드가 독립적으로 발전할 수 있게 하여 유지보수성(Maintainability)을 극대화한다. 반면, Python 백엔드는 패키징 시점에 명시적 I/O 텐서 명세를 요구하며, 이는 프론트엔드 업그레이드 시 패키징 코드와의 강한 결합(Tight Coupling)을 유발한다. 다만, 커스텀 전처리/후처리나 앙상블 파이프라인 등 비표준 모델 로직은 여전히 Python 백엔드 사용이 불가피하다.

배포 전략: 레드-블랙 vs 버전드

넷플릭스는 GPU 인스턴스 업그레이드 시 레드-블랙(Red-Black) 배포와 버전드(Versioned) 배포 전략을 활용한다. 레드-블랙은 안정적인 모델 인터페이스(Stable Model Interface)에 적합하며, 트래픽을 점진적으로 전환하여 제로 다운타임(Zero Downtime)을 보장한다. 그러나 I/O 스키마 변경 시에는 업스트림 소비자(Upstream Consumer)와의 조정 문제로 실패할 수 있다. 버전드 배포는 각 모델 ID/버전별 독립 배포를 통해 소비자 업데이트와 모델 배포를 분리하여 이러한 문제를 해결하지만, 전환 기간 동안 GPU 비용이 일시적으로 증가하는 트레이드오프가 있다. 버전 불변(Version-Agnostic) 모델 설계를 통해 레드-블랙 전략 사용을 권장한다.

LLM 서빙의 제약 디코딩(Constrained Decoding) 구현

넷플릭스는 데이터 미저장 정책(Zero-Retention Policy)을 준수하며 LLM의 토큰 생성 과정을 제어하기 위해 vLLM의 커스텀 로짓 프로세서(Custom Logits Processor) 인터페이스를 활용한다. 초기 Python 기반 구현은 GIL(Global Interpreter Lock)로 인한 CPU 병목 현상으로 배치 크기 증가 시 선형적으로 지연 시간이 증가하는 문제를 보였다. vLLM V1에서는 배치 레벨(Batch-Level) 로짓 처리와 C++ 구현을 통해 이 문제를 해결했으며, 상태 머신(State Machine) 기반의 제약 조건 관리로 동적 배치 변화에 대응한다. 이 방식은 유효하지 않은 생성 결과에 대한 후처리 비용을 절감하고 결과물의 규정 준수(Compliance by Construction)를 보장한다.

운영상의 부트 시퀀스 및 메트릭 통합 과제

대규모 LLM의 콜드 스타트(Cold Start) 지연 시간을 줄이기 위해 모델을 Amazon FSx에 미리 마운트(Materialize)하여 고성능 파일 시스템 접근을 활용한다. 또한, vLLM과 Triton의 독립적인 메트릭 수집 방식으로 인한 관측 가능성(Observability) 격차를 해소하기 위해, 두 지표를 통합하는 경량 HTTP 프록시(Lightweight HTTP Proxy)를 도입하여 기존 대시보드 및 알림 시스템과의 호환성을 유지했다. 이는 프로메테우스(Prometheus)의 MultiProcessCollector를 활용하여 vLLM의 상세 메트릭을 포함한 통합된 `/metrics` 엔드포인트를 제공한다.