넷플릭스, vLLM·트라이톤 기반 사내 LLM 서빙 구조 공개

Netflix TechBlog 공식 기술 글에 따르면 회사는 대규모언어모델(LLM)의 배포와 추론 전 과정을 기존 운영 환경 안에서 직접 처리하는 사내 서빙 플랫폼을 구축했다. 핵심 추론 엔진으로 vLLM을 채택하고, 엔비디아 트라이톤 추론 서버와 자체 제어 계층을 결합했다.

넷플릭스의 기존 머신러닝 서빙 시스템은 라우팅과 A/B 테스트, 후보 생성, 특성 조회, 추론, 후처리와 로그 수집을 하나의 JVM 기반 경로에서 다룬다. 작은 CPU 모델은 이 시스템 안에서 바로 실행하고, GPU가 필요한 대형 모델은 공유 추론 백엔드인 Model Scoring Service(MSS)로 전달한다. MSS 아래에서는 트라이톤이 모델 로딩과 배치 처리, GPU 스케줄링을 맡는다.

회사는 처음에는 TensorRT-LLM을 사용했지만 2025년 여름 작업 부하를 다시 비교한 뒤 vLLM을 기본 경로로 선택했다. 사용자 정의 모델 구조를 별도 다단계 컴파일 없이 불러올 수 있고, 제약 디코딩 같은 확장 로직을 붙이기 쉬우며, 연구 환경에서 운영 환경으로 넘기는 비용을 줄일 수 있다는 판단이었다.

모델 패키징에는 트라이톤의 vLLM 백엔드를 기본값으로 삼았다. 모델 가중치와 토크나이저를 가리키는 JSON 설정만 두면 배포 시점에 입출력 명세를 만들 수 있어, 모델 아티팩트와 프런트엔드 업그레이드의 결합을 낮출 수 있다는 설명이다. 다만 트라이톤과 vLLM의 버전이 어긋나면 백엔드 전체가 로드되지 않을 수 있어 호환 버전을 서비스 이미지에 고정했다. 사용자 정의 전처리나 비표준 실행이 필요한 모델에는 파이썬 백엔드를 예외 경로로 남겼다.

호출 인터페이스는 기존 gRPC와 함께 OpenAI 호환 API를 제공한다. 호스팅 모델에서 자체 미세조정 모델로 전환할 때 애플리케이션 변경을 줄이기 위한 선택이다. 넷플릭스는 트라이톤의 OpenAI 호환 프런트엔드를 재사용했지만, response_format 요청이 vLLM까지 전달되지 않아 JSON 형식 제약이 사라지는 문제를 발견했다. 이후 프런트엔드를 수정해 해당 요청을 vLLM의 가이드 디코딩 매개변수로 변환하도록 했다.

배포는 인터페이스가 유지될 때 새 버전으로 트래픽을 단계적으로 옮기는 레드-블랙 방식과, 모델 버전별 배포를 동시에 유지하는 버전드 방식으로 나뉜다. 입출력 명세가 달라지는 변경에는 이전 버전과 새 버전을 함께 띄워 호출자 전환 시점을 분리한다. 그 대신 전환 기간에는 GPU 비용이 일시적으로 늘어나는 절충이 생긴다.

운영 과정에서는 콜드 스타트와 관측성도 별도 과제로 나타났다. 대형 모델을 시작할 때마다 객체 저장소에서 내려받는 대신 모델 발표 시점에 Amazon FSx에 미리 적재했고, 트라이톤과 vLLM이 따로 내놓는 지표는 경량 HTTP 프록시에서 하나의 메트릭 엔드포인트로 합쳤다.

제약 디코딩은 토큰 생성 이후 결과를 고치는 대신 생성 단계에서 허용 가능한 토큰을 제한하는 방식으로 구현했다. 초기 vLLM V0 구현은 요청별 파이썬 로직과 GIL 때문에 동시 요청이 늘수록 CPU 병목이 커졌다. 넷플릭스는 2025년 4분기 vLLM V1로 옮긴 뒤 배치 단위 처리 구조와 C++ 멀티스레딩을 적용했다. 메모리 압박으로 요청이 선점됐다가 다시 실행될 때 토큰 이력이 줄어드는 상황도 감지해 상태 머신을 초기화하도록 보완했다.

넷플릭스는 앞으로 시스템 프롬프트 압축, vLLM V1 비동기 스케줄링, GPU 융합 커널 기반 벡터화 로짓 프로세서, 저정밀 모델 도입을 검토할 계획이다. 이번 공개는 기업 내부 LLM 운영이 모델 선택만의 문제가 아니라 패키징, 인터페이스 호환성, 버전 전환과 관측성까지 함께 설계해야 하는 플랫폼 엔지니어링 과제임을 보여준다.

출처: Netflix TechBlog 공식 기술 글 https://netflixtechblog.com/in-house-llm-serving-at-netflix-a5a8e799ea2c