추천Netflix의 자체 LLM 서빙 인프라

Netflix는 기존처럼 외부 LLM API를 사용하지 않고, 자사의 ML 플랫폼 위에 완전한 LLM 서빙 시스템을 구축했다. JVM 기반의 통합 서빙 시스템이 라우팅, A/B 테스트, 후보 생성, 특성 추출, 추론을 한 곳에서 처리한다. 작은 모델은 인프로세스로 실행되고, 큰 모델은 GPU가 필요해 Model Scoring Service(MSS)로 위임된다.

엔진 선택: vLLM 채택

초기에는 TensorRT-LLM을 사용했으나, 2025년 중반 오픈소스 엔진들의 성능 격차가 줄어들었고 워크로드도 확대됐다. Netflix는 재벤치마킹 후 vLLM을 주력 엔진으로 선택했다. 이유는 컴파일 파이프라인 없이 커스텀 모델 아키텍처를 로드할 수 있고, 커스텀 디코딩 로직을 위한 확장성 후크를 제공하며, 디버깅이 용이하고, 연구 커뮤니티에서 이미 널리 사용 중이어서 research-to-production 비용이 낮기 때문이다.

Triton 통합 및 패키징 전략

Triton은 두 가지 패키징 방식을 지원한다. Python 백엔드는 명시적으로 I/O 텐서 스펙을 정의해야 하고, vLLM 백엔드는 JSON 설정만으로 배포 시점에 동적으로 생성한다. vLLM 백엔드가 이상적이지만 실제로는 Triton/vLLM 버전 불일치와 커스텀 모델 로직 문제가 발생했다. 표준 HuggingFace 호환 모델이 아닌 경우 Python 백엔드를 사용해야 한다.

API 설계: OpenAI 호환 인터페이스

XGBoost부터 대규모 LLM까지 모든 모델을 동일한 gRPC 호출로 서빙하되, OpenAI 호환 HTTP API를 추가 프론트엔드로 제공한다. 이는 hosted 모델에서 fine-tuned self-hosted 모델로 전환할 때 코드 변경을 최소화한다. NVIDIA Triton의 OpenAI 호환 프론트엔드를 채택했으나, response_format이 silent drop되는 버그가 있어 git-subtree로 패칭해 guided decoding과 연결했다.

배포 전략: Red-Black vs Versioned

GPU 배포는 CPU 서비스보다 시작이 느리고 I/O 스키마 변경으로 조정 문제가 생긴다. Red-Black 배포는 새 버전과 기존 버전을 병렬 운영하며 단계적으로 트래픽을 전환하지만, 스키마 변경 시 조정 갭이 발생한다. Versioned 배포는 각 모델 버전마다 독립 인스턴스를 유지해 모델 배포와 컨슈머 업데이트를 분리하지만, 전환 기간 GPU 비용이 증가한다. Netflix는 모델에 변수 설정을 embed해 스키마 변경을 피하고 Red-Black을 사용할 것을 권장한다.

운영상 고려사항

vLLM-on-Triton 시작 시 S3/Hugging Face에서 직접 다운로드하면 콜드 스타트 지연이 커져서, Amazon FSx에 모델을 미리 캐싱한다. Prometheus 메트릭 측면에서 vLLM은 .db 파일로, Triton은 자체 엔드포인트로 내보내는데, Triton의 브릿지는 40개 이상의 vLLM 메트릭 중 9개만 표면한다. Netflix는 HTTP 프록시로 두 메트릭을 하나의 /metrics 엔드포인트로 병합했다.

제약 조건 기반 디코딩

Netflix 일부 프로덕션 워크로드는 토큰 생성에 세밀한 제어가 필요하다. 추론 후 비즈니스 로직을 적용하고 재시도하는 대신, vLLM의 커스텀 로직 확장으로 제약을 디코드 루프 내부에 넣어 준수하는 출력을 생성한다.