Netflix의 사내 LLM 서빙 플랫폼

넷플릭스는 LLM을 별도 사일로로 분리하지 않고 기존 ML 인프라에서 함께 운영하며, vLLM과 Triton을 통합 서빙 체계에 연결함 기본 엔진으로 선택한 vLLM은 사용자 정의 모델 지원, 디버깅 용이성, 확장 훅, 연구 환경과의 친숙성을 갖췄으며, Triton의 vLLM backend로 모델과 프런트엔드의 결합도 줄임 기존 gRPC와 OpenAI 호환 API를 함께 제공하지만 response_format 누락, Triton·vLLM 버전 불일치, 비표준 모델 처리처럼 프로덕션에서 드러난 간극을 직접 보완해야 했음 안정적인 배포에는 비용이 낮은 Red-Black 전략을 우선 적용하고, 호환되지 않는 I/O 변경이 불가피할 때만 여러 버전을 동시에 유지하는 Versioned 전략을 사용함 요청별 제약을 디코딩 루프에서 강제하는 로짓 프로세서를 vLLM V1의 배치 처리와 멀티스레드 C++로 재구현했으며, 앞으로 GPU 융합 커널·비동기 스케줄링·저정밀 모델로 확장할 계획임 기존 ML 인프라에 통합한 서빙 구조 Netflix의 JVM 기반 통합 서빙 시스템은 라우팅과 A/B 테스트, 후보 생성, 특징 조회, 추론, 후처리, 단계별 로깅을 처리하며 실시간 및 캐시된 배치 경로를 모두 지원함 호출자는 기존 서빙 시스템의 gRPC 경로 또는 새로운 LLM 애플리케이션용 직접 HTTP 경로로 추론에 접근함 실행 위치는 모델 규모에 따라 달라짐 작은 CPU 모델은 원격 호출 비용을 피하도록 프로세스 안에서 실행함 큰 GPU 모델은 전·후처리를 로컬에서 수행하고 추론을 원격 Model Scoring Service(MSS) 에 위임함 MSS는 XGBoost, TensorFlow, PyTorch, LLM을 하나의 인터페이스로 제공하며, 하부의 NVIDIA Triton Inference Server가 모델 로딩, 배치 처리, GPU 스케줄링을 담당함 Triton 위의 Java 제어 영역은 배포, 버전 관리, 상태 확인, 자동 확장, 다중 리전 롤아웃을 처리함 모델 개발자가 아티팩트와 배포 설정을 패키징하면 GPU 인스턴스를 프로비저닝하고 Triton을 구성함 업그레이드는 무중단 방식으로 조정함 기본 추론 엔진으로 vLLM 선택 초기 플랫폼은 당시 성능이 높고 MSS의 Triton과 이미 통합돼 있던 TensorRT-LLM을 사용함 2025년 여름에는 오픈소스 엔진이 특화 스택과의 성능 차이를 대부분 좁혔고, 워크로드도 다음 범...