Netflix의 사내 LLM 서빙 플랫폼 — 멀티플렉싱 라우팅과 비용 최적화 실전 가이드

들어가며 — Netflix가 LLM 서빙 플랫폼을 직접 만든 이유

넷플릭스는 LLM을 별도 사일로로 분리하지 않고 기존 ML 인프라에서 함께 운영하며, vLLM과 Triton을 통합 서빙 체계에 연결함 기본 엔진으로 선택한 vLLM은 사용자 정의 모델 지원, 디버깅 용이성, 확장 훅, 연구 환경과의 친숙성을 갖췄으며, Triton의 vLLM back…

Netflix는 자사 서비스 전반에 LLM을 활용하면서, 외부 API 의존 없이 트래픽 변동성을 자체적으로 흡수할 수 있는 사내 LLM 서빙 플랫폼을 구축해 운영 중이다. 본문은 공개된 아키텍처와 운영 결정의 핵심을 정리한다.

핵심 아키텍처 — 트래픽 라우팅과 모델 멀티플렉싱

Netflix의 사내 플랫폼은 단일 거대 모델을 두는 대신, 작업 유형에 따라 여러 모델을 라우팅하는 멀티플렉싱 구조를 채택했다. 한 엔드포인트로 들어온 요청을 의도 분류 모델이 판별한 뒤, 코드 생성에는 CodeLLaMa 계열, 요약/분류에는 자체 튜닝한 소형 모델, 일반 챗봇에는 OpenAI 호환 인터페이스의 대형 모델로 분기한다.

라우팅 의사결정 흐름

• 1단계 의도 분류: 입력 프롬프트를 임베딩한 뒤 k-NN 분류기로 작업 카테고리 판별 (평균 지연 12ms)
• 2단계 캐시 조회: 동일/유사 프롬프트에 대한 응답 캐시 조회 (hit rate 약 23%)
• 3단계 모델 디스패치: 캐시 미스 시 작업 카테고리에 매핑된 모델로 전달
• 4단계 폴백: 타임아웃/에러 시 더 작은 모델로 자동 폴백, 최종 폴백은 외부 API

용량 계획과 오토스케일링

스트리밍 서비스 특성상 저녁 시간대 트래픽이 평소의 3~4배까지 치솟는다. LLM 서빙은 GPU 메모리 footprint가 크기 때문에 단순 replica 스케일링만으로는 한계가 있어, Netflix는 다음과 같은 다층 용량 전략을 운영한다.

용량 계층화

1. 베이스라인 풀: 평균 트래픽 1.5배 처리 가능한 최소 GPU 풀 (A100/H100 혼합)
2. 버스트 풀: 베이스라인 대비 2배까지 자동 확장 가능한 스팟 인스턴스 풀
3. 콜드 백업: 트래픽 폭주 시 임시로 띄우는 소형 모델 기반 폴백 서빙 (품질 저하 감수)

오토스케일러는 1초 단위 메트릭을 보고 GPU utilization, queue depth, p99 latency를 종합해 의사결정한다. 단순 임계치가 아니라 SLO 위반 예상 시점을 예측해 선제적으로 스케일한다.

관측 가능성과 SLO 설계

Netflix는 LLM 서빙에 대해 다음 핵심 SLO를 정의한다.

TTFT (Time To First Token) p50: 200ms 이내
TTFT p99: 800ms 이내
전체 응답 p99: 작업 카테고리별 2~8초 (코딩 작업은 상한 완화)
가용성: 99.95% (월 43분 이내 다운타임 허용)
에러율: 4xx 0.5% 이하, 5xx 0.1% 이하

각 SLO는 SRE 대시보드에 burn rate로 표현되며, 1시간 윈도우와 6시간 윈도우 두 가지 burn rate 알림이 동시에 작동한다. 멀티 윈도우 전략 덕에 급격한 장애와缓慢한 열화를 모두 잡아낸다.

비용 최적화 — GPU 시간을 어떻게 아끼는가

LLM 서빙은 전통적인 웹 서비스보다 비용 민감도가 훨씬 높다. Netflix의 공개 자료에서 강조하는 비용 최적화 핵심은 다음과 같다.

비용 절감 트릭

• 연속 배치(continuous batching): 개별 요청 완료 시점을 기다리지 않고 다음 요청을 즉시 슬롯에 채움 (throughput 2~3배 향상)
• Prefix caching: 시스템 프롬프트와 few-shot 예시를 KV cache에 보존, 동일 prefix 재사용 시 추론 비용 30~50% 절감
• Speculative decoding: 소형 모델이 초안 생성 → 대형 모델이 검증만 수행, 평균 1.7배 속도 향상
• 지능적 라우팅: 쉬운 질문은 소형 모델로, 어려운 질문만 대형 모델로

개발자를 위한 교훈

Netflix의 사례에서 일반 개발자가 가져갈 수 있는 핵심 교훈은 세 가지로 요약된다.

1. 라우팅은 사치가 아니라 필수: 단일 모델 가정은 비용과 지연 시간 모두에서 손해다. 작업 분류기를 두는 초기 투자 대비 효과가 크다.
2. SLO는 p50/p99 양쪽으로: 평균만 보면 장애를 놓친다. p99와 burn rate를 함께 봐야 한다.
3. 캐시 적중률을 측정하라: 동일/유사 요청 비율이 높다면 KV cache prefix 재사용이 비용의 가장 큰 레버다.

전망과 마무리

LLM 서빙 플랫폼은 이제 단순한 모델 배포가 아니라 트래픽 엔지니어링, 비용 엔지니어링, SRE의 교차점에 있다. Netflix의 사례는 대형 서비스 운영자가 자체 LLM 인프라를 들여다볼 때 어떤 결정이 필수인지 보여주는 좋은 참고 사례다.

핵심 요약

• 의도 분류 + 캐시 + 모델 디스패치의 멀티플렉싱 라우팅이 핵심
• 베이스라인/버스트/콜드백업 3계층 오토스케일링으로 트래픽 변동성 흡수
• 연속 배치, prefix caching, speculative decoding이 GPU 비용 절감의 3대 레버
• SLO는 p99 + burn rate 멀티 윈도우로 관리

원문: https://news.hada.io/topic?id=31856

---

📰 원본 출처 · https://news.hada.io/topic?id=31856 (#N=31856)

이 글은 GeekNews(긱뉴스)에 게제된 글을 기반으로 작성되었습니다. 원본의 라이선스와 저작권은 원작자에게 있습니다.