Локално обслужване на LLM в Netflix: Архитектура, предизвикателства и решения

Публикувано от Svetni.me Editorial на 19 юли 2026 г.

Повечето съвременни организации консумират големи езикови модели (LLM) чрез външни хоствани приложни програмни интерфейси (APIs). Технологичният гигант Netflix обаче избира различен подход, внедрявайки изцяло собствена инфраструктура за LLM инференция и разгръщане [1]. Вместо да обособява отделни и изолирани технологични силози за машинно обучение, компанията интегрира обслужването на моделите директно в съществуващата си микросервизна архитектура и производствена среда. Този избор им позволява да контролират жизнения цикъл на инференцията, да оптимизират закъснението (latency) и да намалят разходите при голям мащаб.

В тази статия разглеждаме в детайли архитектурните решения, инженерните компромиси и техническите иновации, които определят дизайна на LLM платформата на Netflix.

Архитектура на системата: Двуслойна инференция

Инфраструктурата за машинно обучение на Netflix е изградена около единна, базирана на JVM (Java Virtual Machine) система за обслужване. Тя управлява пълния жизнен цикъл на заявките за крайните потребители: от маршрутизиране и логика за A/B тестване, през генериране на кандидати за препоръки и извличане на признаци (features), до самата инференция, последваща обработка (post-processing) и подробно логване на всеки етап [1].

Калърите достигат до системата за инференция чрез два основни пътя:

  1. gRPC път през JVM системата за обслужване, оптимизиран за вътрешни системи с ниско закъснение.
  2. Директен HTTP път, използван от по-новите приложения, базирани на агенти и генеративен изкуствен интелект.

Начинът на изпълнение на самата инференция зависи от мащаба на съответния модел:

  • Малки CPU модели: Изпълняват се локално, "in-process" в JVM контейнера. Това елиминира напълно мрежовото закъснение при отдалечени повиквания.
  • Големи модели (LLM): Изискват специализиран графичен хардуер (GPU). В този случай JVM системата обработва предварителната и последващата обработка на данни локално, но делегира тежката инференция към отдалечена специализирана подсистема, наречена Model Scoring Service (MSS) [1].

Архитектура на LLM инфраструктурата на Netflix
Изображение: Svetni.me / Авторско изображение

MSS функционира като споделен бекенд за инференция с единен интерфейс, поддържащ XGBoost, TensorFlow, PyTorch и големи езикови модели. Под капака му стои Triton Inference Server, разработен от NVIDIA, който отговаря за ефективното зареждане на моделите, пакетирането на заявките (batching) и планирането на ресурсите на графичните процесори. Над Triton е изграден Java контролен панел (control plane), управляващ автоматичното мащабиране, проверката на състоянието (health checks) и разгръщането в множество облачни региони без прекъсване на услугата (zero-downtime upgrades) [1].

Избор на енджин: Преходът от TensorRT-LLM към vLLM

Първоначално инфраструктурата на Netflix се базира на TensorRT-LLM – високооптимизиран компилатор и библиотека на NVIDIA, тясно интегриран с Triton. До лятото на 2025 г. обаче компанията сменя посоката и избира vLLM като основен енджин за обслужване на модели. Този преход е продиктуван от четири ключови оперативни фактора:

  1. Елиминиране на компилацията: TensorRT-LLM изисква сложна и времеемка многостъпкова компилационна фаза за всеки конкретен графичен процесор. Преходът към vLLM позволява зареждане на персонализирани архитектури директно от оригиналните им тегла и конфигурации, което драстично ускорява цикъла на разработка и итерация.
  2. Разширяемост (Extensibility): vLLM предоставя лесни за използване софтуерни куки (hooks), които позволяват инжектиране на персонализирана логика в процеса на декодиране (constrained decoding).
  3. Лесно дебъгване: Тъй като не е силно компилиран "черен куфар", инфраструктурата на vLLM позволява лесна инспекция на грешките, междинните състояния и вътрешния процес на генериране на токени.
  4. Познатост и съвместимост: Повечето ML инженери в екипите за изследвания и разработка вече използват vLLM за своите експерименти, което улеснява трансфера на моделите към производствена среда.

Интеграция с Triton и пакетно управление

Едно от важните архитектурни решения е как моделите се пакетират и комуникират с Triton Inference Server:

  • Python бекенд (класически подход): Изисква ML авторите да дефинират експлицитно входно-изходните тензорни спецификации. Това силно обвързва обновяването на моделите с логиката на уеб интерфейса – всяка промяна на формата изисква координирана актуализация и на двете подсистеми.
  • vLLM бекенд за Triton: При този модел пакетът съдържа единствено JSON конфигурационен файл с пътища към теглата на модела и неговия токенизатор. Бекендът на vLLM в рамките на Triton динамично генерира нужните тензорни спецификации при разгръщане. Това позволява на модела и потребителския интерфейс да се развиват независимо [1].

Впреки това съществуват производствени рискове. Несъответствия във версиите на Triton и vLLM могат да доведат до неочаквани сривове. Затова при специфични случаи, изискващи сложна пред- и след-обработка или обединяване на модели (ensembles), екипът все още разчита на класическия Python бекенд като авариен вариант.

Уеб интерфейс, съвместим с OpenAI

За да се интегрира лесно с по-широката екосистема от LLM инструменти, платформата излага HTTP интерфейс, съвместим с този на OpenAI [1]. За целта се използва библиотека, изградена с FastAPI и KServe. Това решение предлага изключително предимство: разработчиците на приложения могат да преминат от използване на комерсиални външни модели към локално хоствани и фино настроени модели без никакви промени по клиентския код.

По време на интеграцията екипът открива важен пропуск: оригиналният Triton OpenAI бекенд е изпускал параметъра response_format (използван за структуриран JSON изход). За да поправи това, Netflix копира кода чрез git subtree и пачва логиката локално, преобразувайки response_format в параметри за ориентирано декодиране (guided decoding), съвместими с vLLM [1].

Стратегия за разгръщане: Червено-Черно срещу Версии

При обновяване на моделите Netflix балансира между две основни стратегии за разгръщане:

  1. Червено-Черно (Red-Black / Blue-Green): Новият модел се разгръща паралелно със стария. Трафикът се пренасочва поетапно, като при неуспех се извършва моментално връщане назад (rollback). Този метод работи отлично при стабилни интерфейси, но крие рискове, когато входно-изходните схеми се променят – по време на преходния прозорец стари заявки могат да достигнат до новия модел и да причинят грешки.
  2. Версионирано разгръщане (Versioned): Всеки модел се хоства на собствен уникален адрес, съдържащ идентификатор и версия (например modelId и modelVersion). Това изолира напълно клиентите и гарантира липса на сривове, но временно дублира разходите за GPU ресурси.

Препоръка за оптимизация: За да запази предимствата на Червено-Черното разгръщане и да спести разходи, Netflix препоръчва вграждането на променливите конфигурации (като форми на тензорите) директно в метаданните на модела. Версионираното разгръщане се пази единствено като последна мярка за фундаментално счупващи интерфейсни промени [1].

Дълбок технически анализ: Ограничено декодиране в голям мащаб

Ограниченото декодиране (constrained decoding) – процесът на принуждаване на модела да генерира токени, съвпадащи с определена регулаторна граматика или схема – е критично за приложенията на Netflix. За да постигне висока скорост, инженерният екип вгражда тази логика директно в цикъла за декодиране на моделите, използвайки интерфейса за обработка на логити (logits processor) на vLLM.

Революцията в производителността се случва при прехода между две версии на енджина:

  • vLLM V0 (чист Python): Логиката за обработка на логити се изпълнява последователно на CPU. Поради глобалното заключване на интерпретатора в Python (GIL), времето за изчисление на процесора нараства линейно спрямо размера на партидата (batch size), превръщайки се в тежко теснолинейно място.
  • vLLM V1 (партидна C++ оптимизация): Цялата критична логика е пренаписана на C++ с многонишкова обработка на ниво цяла партида заявки. Този подход заобикаля GIL и поддържа времето за обработка на логити напълно плоско, независимо от нарастването на batch size. Освен това новата версия е подсилена да се справя коректно с частично предварително попълване (partial prefills) и принудително отнемане на ресурси (preemption), нулирайки състоянията на граматичния автомат при промяна в историята на токените [1].

Оперативно управление и мониторинг

Инфраструктурата се допълва от две важни оперативни оптимизации:

  • Кеширане на моделите: За да се избегне бавното първоначално стартиране (cold starts) от отдалечени хранилища като Amazon S3 или Hugging Face, Netflix използва Amazon FSx за споделено файлово кеширане. Зареждането се задейства автоматично още при обявяването на новия модел.
  • Обединено наблюдение: Triton и vLLM излагат отделни метрики. Netflix решава това чрез леко HTTP прокси, което чете Triton HTTP метриките и обединява vLLM метриките от локалните .db файлове на Prometheus (PROMETHEUS_MULTIPROC_DIR), излагайки единен и завършен /metrics краен адрес за системата Prometheus [1].

Собственият LLM стек позволява на Netflix да постигне оптимален баланс между гъвкавост, контрол над данните и висока производителност, поставяйки нови стандарти в областта на корпоративното обслужване на модели с изкуствен интелект.

Източници

  1. AI Platform’s Model Runtime and Inference teams, "In-House LLM Serving at Netflix", Netflix Technology Blog, Юли 2026. URL: https://netflixtechblog.com/in-house-llm-serving-at-netflix-a5a8e799ea2c