State of Routing in Model Serving at Netflix

В наши дни большинство рекомендательных сервисов используют ML-модели: от линейных и градиентного бустинга до развесистых нейросетей. Если в продукте появляется первая поверхность для подключения продвинутых рекомендательных технологий, то самое простое — внедрить нужную модель в бэкенд сервиса.

Однако после запуска всё только начинается. Нужно как-то обновлять модели, тестировать новые архитектуры, подключать новые рекомендательные сценарии и при этом не упереться в ограничения железа.

Сегодня разбираем пост, в котором описана инфраструктура для инференса ML-моделей в Netflix. Посмотрим, как они решают эти вопросы в рамках своей платформы Switchboard.

Ключевые принципы платформы:

🔴Сотни типов моделей и десятки поверхностей для их использования (персонализированные рекомендации фильмов, антифрод).

🔴Суммарно ~1M RPS.

🔴В API есть абстракция Objective — идентификатор поверхности, для которой нужно посчитать ML-модель.

🔴В продуктовом коде один раз пишется интеграция с платформой, а в запросе передаётся информация о текущем Objective и текущем «контексте» (например, UserId, CountryId, DeviceId).

В Netflix используют более широкое понятие serving: кроме самого инференса модели, оно включает получение данных из внешних сервисов по идентификаторам из «контекста», расчёт фичей поверх входных данных, которые идут на вход в инференс, запуск модели и пост-обработку результатов.

🔴Продуктовый код «не знает», что у ML-моделей бывает версионирование, изменение архитектуры и постоянные A/B-эксперименты. Не знает, какие данные реально будут использованы при вычислении.

🔴ML-инженеры проводят эксперименты через Switchboard и могут с помощью динамических конфигов выбирать, какие модели будут обслуживать разные Objective.

🔴Инженеры Switchboard имеют контракты по SLA для нужных Objective и скрывают шардирование ML-моделей по различным кластерам, переливание трафика между моделями, A/B-эксперименты и миграции.

Но есть три критичные проблемы:

1. Switchboard становится единой точкой отказа — любой сбой на уровне входной прокси может задеть много ML-сценариев.

2. Появляется просадка по latency (~10–20 мс): дополнительный сетевой хоп, обработка входного payload'а (парсинг всего запроса для определения Objective и параметров, необходимых для управления трафиком) и нарезка A/B-экспериментов (тоже через внешний сервис).

3. «Шумные соседи»: клиенты могут неожиданно повысить нагрузку и неявно помешать запросам других клиентов.

Тогда в Netflix решают аккуратно избавиться от единой прокси в Switchboard. Но при этом важно не потерять классные свойства и абстракции, которые уже устоялись. Нужно, чтобы в клиенте появилась вся информация, которой владеет Switchboard, для определения, куда именно проксировать запрос.

Логику Switchboard делят на два компонента, которые скрыли в более умном клиенте на стороне продуктового кода:

1. Появляется отдельный легковесный сервис Lightbulb, в который клиенту надо отправить нужные «контекстные» данные и получить информацию, какую модель (routingKey) надо считать (по сути, нарезка трафика для необходимых кейсов).

2. Локально поднимается Envoy-прокси, куда независимо доставляют маппинги, на каких хостах какие ML-модели живут (routingKey → hosts).

Со стороны клиента остаётся пробросить routingKey в хедерах запроса в локальный Envoy, который согласно своим маппингам сделает запрос в нужный хост.

В итоге удалось избавиться от единой прокси и дополнительного сетевого хопа, а также от лишнего парсинга запроса на стороне Switchboard в пользу легковесных запросов в Lightbulb. И сохранить все продуктовые свойства платформы тоже удалось.

Ребята из Netflix репортят это как заслуженный успех, но часть деталей в статье не раскрыта и, скорее всего, требует отдельной проработки. Например, не сказано, что происходит в случае сбоев Lightbulb, который по сути стал новой единой точкой отказа и как происходит расселение ML-моделей по хостам. Поэтому ждём от Netflix постов с новыми деталями.

@RecSysChannel
Разбор подготовил ❣ Александр Михеев

InterFormer: Effective Heterogeneous Interaction Learning for CTR Prediction

Сегодня разбираем статью InterFormer об архитектуре под задачу CTR-prediction на гетерогенных данных: статичных признаках пользователя/айтема и поведенческих последовательностях.

Авторы выделяют две проблемы существующих подходов:  

1. слабое взаимодействие между sequence- и non-sequence-фичами;  
2. агрессивное раннее сжатие последовательностей через pooling/summary, из-за чего теряется много информации.

Ключевой вклад — модуль InterFormer, который обрабатывает разные типы признаков отдельно, но на каждом слое обменивает между ними сжатые представления:

🔴Interaction Arch — работает с non-sequence-фичами: user profile, item features, context. Ко входу добавляется summary последовательности, а в качестве бекбона можно использовать разные interaction-модули, например DCNv2 или DHEN.

🔴Sequence Arch — моделирует историю пользователя. Здесь sequence-эмбеддинги обновляются с учётом summary от non-sequence-фичей: сначала через personalized FFN, затем через multi-head attention.

🔴Cross Arch — слой обмена между двумя ветками. Non-sequence-признаки сжимаются через gated selection, а sequence-информация суммаризуется через комбинацию CLS-, PMA- и recent-tokens. Эти summary передаются в соседнюю ветку на следующем слое.

Идея в том, чтобы не «схлопывать» все признаки в один вектор слишком рано, а делать «двунаправленный обмен»: sequence помогает non-sequence-части, а non-sequence-контекст помогает sequence-моделированию.

Для задачи CTR используется стандартная бинарная кросс-энтропия.

Из публичных: AmazonElectronics (3M), TaobaoAds (25M), KuaiVideo (137M). Также авторы используют крупный внутренний датасет Meta* на 70B семплов.

На публичных датасетах InterFormer даёт лучшие результаты среди бейзлайнов. На внутреннем датасете Meta авторы показывают +0,15% NE, +24% QPS, а в pilot launch +0,6% uplift по по основным продуктовым метрикам.

Ablation studies подтверждают, что:

🔴bidirectional interaction лучше однонаправленного обмена;
🔴selective aggregation лучше раннего pooling/MLP/MHA-сжатия;
🔴удаление PMA, recent tokens, gating, PFFN или MHA ухудшает качество.

Главное достоинство InterFormer — имплементация идеи с двунаправленным взаимодействием между статичными признаками и последовательностями без агрессивного раннего сжатия. Однако архитектура получилась довольно сложной и тяжелой для распараллеливания, приросты на публичных датасетах небольшие, а самые интересные production-результаты получены на закрытых данных Meta.

@RecSysChannel
Разбор подготовил ❣ Никита Степанов
___
Компания Meta признана экстремистской; её деятельность в России запрещена.

OneReason Technical Report [1/2]

Сегодня разбираем хайповый техрепорт от Kuaishou на 108 страниц, в котором авторы научились получать существенный профит от ризонинг-моделей в рекомендациях.

В предыдущих статьях — OneRec-Think и OpenOneRec — модели уже могли генерировать человекочитаемые рассуждения на естественном языке, но thinking-режим не давал стабильного прироста и иногда даже ухудшал рекомендации. В OneReason авторы предлагают полный рецепт, объединяющий улучшенное восприятие itemic-токенов, структурированный CoT и доменный RL. В результате reasoning trace наконец начинает помогать предсказанию, а общие способности модели в основном сохраняются.

В этом разборе сосредоточимся преимущественно на первой части рецепта: устройстве бенчмарков, токенизации и многоуровневом претрейне, который создаёт семантический фундамент для последующего ризонинга.

Авторы предлагают не предсказывать следующий айтем напрямую по шумной истории пользователя. Сначала модель строит структурированный reasoning trace в три этапа. На этапе Persona Abstraction она сжимает историю в компактный профиль устойчивых предпочтений. Затем Interest Expansion выделяет несколько возможных направлений интереса, подтверждённых поведением пользователя. Наконец, Transition Inference сравнивает эти гипотезы с учётом силы и свежести сигналов, их временной связности и соответствия целевому домену. После этого модель генерирует itemic-токены следующего айтема.

Способности модели авторы оценивают на четырёх последовательных уровнях:

R0 — связывать itemic-токены с их текстовой семантикой и отвечать на вопросы о свойствах айтемов;
R1 — выводить отношения и возможные переходы между айтемами на основе их семантики;
R2 — рассматривать историю пользователя как временную последовательность и восстанавливать эволюцию его интересов;
R3 — объединять предыдущие способности для next-item prediction.

Для каждого уровня в едином OneReason-Bench предусмотрен свой набор диагностических задач. Финальное качество рекомендаций измеряют в двух сетапах: 

🔴single-domain, где модель видит историю только из целевого домена,
🔴cross-domain, где получает взаимодействия пользователя из всех четырёх доменов, но предсказывает айтем из конкретного. Кросс-доменная история обычно даёт небольшой прирост, но для холодных пользователей помогает больше.

Чтобы модель вообще смогла строить такие рассуждения, сначала её пришлось научить понимать сами itemic-токены и пользовательские истории. Об этом поговорим во второй части.

@RecSysChannel
Разбор подготовил ❣ Илья Мурзин

OneReason Technical Report [2/2]

В первой части разобрали, как устроен OneReason-Bench и почему авторы вообще вводят многоступенчатый ризонинг вместо next-item prediction. Теперь посмотрим, как модель учат работать с itemic-токенами и почему претрейн оказался здесь так важен.

На претрейне модель прежде всего учат воспринимать историю пользователя и связывать семантические ID с текстом. Каждый айтем представляют четырьмя токенами: токеном домена и тремя семантическими ID. От завершающего токена из OpenOneRec отказались, чтобы сократить представление айтема и оставить больше контекста.

Данные для претрейна делят на четыре уровня гранулярности:

🔴на уровне токенов модель учат связывать с текстом отдельные itemic-токены, их префиксы и полные токеновые последовательности;
🔴на уровне айтемов — генерировать описания, восстанавливать itemic-токены по тексту и отвечать на вопросы о свойствах контента;
🔴на уровне отношений — понимать связи и переходы между айтемами через естественно-языковые объяснения;
🔴на уровне пользователя — работать с доменно сгруппированными и хронологически перемешанными историями, моделируя кросс-доменные связи и эволюцию интересов.

То есть претрейн не сводят к одному next-item objective. Обучающая смесь одновременно охватывает задачи от семантики отдельных токенов до моделирования полной пользовательской истории.

Около 28,4% токенов претрейна приходится на данные общего назначения: 26,85% составляют текстовые корпуса, а ещё 1,59% — мультимодальные. Они нужны, чтобы во время специализации на рекомендациях модель сохраняла общие reasoning- и instruction-following-способности. С такой смесью итоговая модель остаётся близка к исходному Qwen3-8B на общих LLM-бенчмарках.

Сам претрейн проходит в три этапа.

1) Сначала при замороженном бэкбоне обучают только новые эмбеддинги и соответствующие веса LM-головы для itemic-токенов.

2) Затем размораживают все параметры и продолжают обучение с меньшим learning rate.

3) На последнем этапе максимальную длину отдельных примеров увеличивают с 4K до 32K токенов, чтобы модель научилась обрабатывать полные пользовательские истории.

OneReason обгоняет рекомендательные бейзлайны и почти не просаживается на LLM-бенчмарках — в отличие от Open OneRec, которая заметно теряла в языковых способностях. При этом модель, обученная получать качество за счёт рассуждений, становится лучше и в режиме без ризонинга.

Аблейшны показывают, что добавление каждого следующего уровня гранулярности улучшает качество, а лучший результат даёт весь претрейн-рецепт целиком.

@RecSysChannel
Разбор подготовил ❣ Илья Мурзин