Масштабирование Discovery‑платформы VK: 15 новых вертикалей, GPU‑ранжирование и сквозная оптимизация

Привет! Это команда AI VK. В конце января мы рассказали про Discovery‑платформу ^[1] — единый инфраструктурный слой для рекомендаций, поиска и рекламы во всех продуктах VK. Тогда разобрали её устройство, а теперь расскажем, что улучшили за последние месяцы — от запуска Discovery Portal до оптимизации инфраструктуры — и как эти изменения повлияли на продукты. 

Коротко: что такое Discovery‑платформа и зачем она нужна

Сначала вспомним архитектуру. В VK десятки продуктов, и почти в каждом есть три задачи: показать интересный контент, найти нужное по запросу, подобрать релевантную рекламу. За ними похожий сценарий: взять большой каталог объектов, отобрать кандидатов, отранжировать их под конкретного человека, показать в ленте десяток лучших.

Discovery‑платформа заменила десятки разрозненных подходов одним. Это не библиотека с полезными функциями, а полноценная инфраструктура: готовые данные, рантайм, единый способ развёртывания моделей, A/B‑контур.

Что платформа даёт командам

1. Конфиг вместо кода. Около 90% задач ранжирования решаются без единой новой строчки кода. Источник кандидатов, фактор в модели, правило фильтрации, отправка всего этого в A/B‑тест — правка конфигурации.

2. Скорость проверки гипотез. Цикл «идея — эксперимент — вывод» сократился в пять раз, новую рекомендательную систему в продукте запускаем в среднем за месяц.

3. Низкий порог входа. Инженер получает готовые блоки: поток данных, профиль, инфраструктуру деплоя, шаблоны пайплайнов. Собирать стек с нуля не нужно, онбординг короче. Так новые сотрудники втрое быстрее проводят первые успешные эксперименты в проде.

4. Тиражирование наработок. Удачное решение переносится в другой продукт конфигурацией, в том числе между доменами: лучшие наработки рекламы едут в рекомендации и наоборот.

Что изменилось в самой Discovery‑платформе

В этом году мы двигались по трём направлениям: скорость запуска новых вертикалей, единый интерфейс управления рекомендательными системами и эффективность использования железа. Дальше по порядку. 

1. Быстрый запуск 

На платформе появилось 15 новых рекомендательных вертикалей. Это работающие рекомендеры: они уже в проде, учатся на реальных данных и улучшаются итерациями. Например, сменой источников кандидатов, новыми факторами или экспериментами.

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

Запуск рекомендера всегда состоял из двух частей. Содержательная: какие кандидаты, какая модель, какие метрики. Рутинная: поднять сервис из шаблона, прописать выкатку, завести дашборды и алерты, подключить логирование, настроить A/B‑контур. Именно рутина занимала недели ручной работы.

За полугодие мы автоматизировали процесс. Теперь вертикаль описывают в конфигурации: каталог объектов, источники кандидатов, профиль, цели оптимизации. Платформа сама разворачивает сервисы, заводит потоки данных, создаёт мониторинги, подключает эксперименты и выдаёт доступы в смежных сервисах. Инженер остался, но занимается содержательной частью, а не сборкой инфраструктуры.

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

2. Discovery Portal: управление и мониторинг

Второй сюжет полугодия — Discovery Portal, единая точка управления инфраструктурой рекомендательных и смежных сервисов: конфигурации, топология сервисов, трафик, инструменты надёжности.

Проблема знакома всем, кто строил внутренние платформы. Система растёт, и даже типовые операции требуют всё больше контекста: где лежат настройки, что можно менять, как параметры связаны, к чему приведёт правка. Для инженера, который заходит сюда не каждый день, простое действие превращается в разбор устройства системы. Порог входа растёт, простые операции затягиваются.

При этом любое действие с инфраструктурой потенциально опасно. Отсюда требование к порталу: низкий порог входа и безопасность каждой операции. Сегодня Discovery Portal пользуются все разработчики AI VK, через него проходят десятки изменений в день. Команды сами запускают сервисы, проводят учения, устраняют поломки.

Безопасное управление изменениями

Безопасность здесь не лозунг, а набор конкретных механик.

1. Валидация изменения до применения. Discovery Portal проверяет конфигурацию на согласованность и не даёт сохранить заведомо нерабочий вариант.

2. Поэтапная раскатка. Изменение сначала едет на часть трафика, платформа сравнивает метрики с контрольной группой. Деградации нет — доля трафика растёт до полной раскатки. Метрики просели — раскатка останавливается, изменение уезжает обратно.

3. Откат в один шаг. Любая версия конфигурации хранится, возврат к предыдущей — обычная операция, а не аварийная процедура.

4. Прозрачная история. Видно, кто, что и когда поменял и какой эксперимент к этому привязан.

Единая точка входа

Вторая большая функция портала — единое окно во всё, что происходит в продакшене. Раньше телеметрия и инструменты лежали в разных местах: отдельно графики мониторинга, отдельно отладка, профилирование и анализ характеристик системы.

Теперь почти вся информация о своём продакшене собрана в одном месте и выглядит одинаково для разных вертикалей и команд.

3. Эффективность использования железа

Третье направление — вычислительные ресурсы. Здесь два улучшения: GPU‑инференс ранжирования в реальном времени и 70 тысяч высвобожденных CPU‑ядер. Работу сделали один раз в платформе, а пользуются все продукты, переехавшие на Discovery. Ради одного сервиса отдельная команда такую разработку не потянула бы.

Объясним, почему GPU в ранжировании внедряли именно так.

Discovery‑платформа — система Tier A. Для неё действуют строгие требования к надёжности: отказоуйстойчивость и контроль деградации. Обычно платформенные команды считают такие требования налогом. У нас сложилось обратное отношение: Tier A делает платформу лучше, потому что заставляет проектировать сначала поведение ^[2] при сбое и только потом — удачный сценарий. На практике это несколько правил:

1. Любая часть выдачи должна деградировать, а не падать. Если недоступен один из источников кандидатов, выдача собирается по остальным. Если не отвечает модель ранжирования, работает более простая модель.

2. Свежесть данных — это тоже отказ. Старый профиль и старые контентные признаки не ломают ответ, но ломают качество. Поэтому мониторинг следит и за успешностью ответов, и за возрастом данных. 

3. Любая новая технология в проде обязана уложиться в тот же контур надёжности. Это правило нам особенно пригодилось при внедрении GPU в ранжирование.

GPU‑инференс в ранжировании с сохранением Tier A

Трансформеры требуют больше вычислительных ресурсов, чем классические модели на CPU, и их сложнее уложить в жёсткие ограничения по времени ответа. В первом полугодии мы внедрили GPU‑инференс в контур ранжирования Discovery, где задержки измеряются миллисекундами. Решение встроили в общую инфраструктуру, чтобы любая команда могла подключать нейросетевые модели. При этом нужно было сохранить надёжность уровня Tier A. Основные сложности:

1. Батчинг против задержки. GPU эффективен на больших батчах, а онлайн‑запросы приходят по одному. Нужен динамический батчинг: собрать запросы за короткое окно и отдать одним куском, не выйдя за бюджет времени. Размер окна — прямой размен между утилизацией железа и хвостом задержек.

2. Хвосты, а не среднее. В синхронном контуре важна не средняя задержка, а верхние перцентили: одна медленная стадия в конце цепочки портит впечатление ^[3] от всей выдачи.

3. Отказ GPU‑парка не должен ронять выдачу. Отсюда обязательный запасной путь: при недоступности нейросетевой модели ранжирование продолжает работать на более простой модели. Качество ниже, продукт жив.

4. Совместное использование карт. Одна модель редко утилизирует GPU полностью. Платформа умеет размещать на одной карте несколько моделей и заполнять простой карты низкоприоритетными батч‑задачами.

5. Одинаковый результат в обучении ^[4] и в проде. Расхождение препроцессинга между обучением и инференсом — классический источник тихой потери качества. Общий слой признаков снимает большую часть проблемы.

Главный итог: GPU в ранжировании перестал быть экспериментом отдельной команды и стал обычной опцией платформы. Продуктовая команда включает нейросетевую модель конфигурацией, а не отдельным проектом на квартал.

Первый крупный результат такой раскатки — нейросетевое ранжирование ^[5] в VK Видео, что дало +10% в TVT на главной. В VK Клипах просмотра увеличилось на 5,5% одновременно с лайками (+3%) и шэрами (+15%). Обычно рост времени просмотра оплачивается падением других метрик, а здесь — ростом.

70 тысяч CPU‑ядер

Когда у каждой команды свой стек, оптимизация локальна: экономия остаётся внутри продукта, а соседние сервисы тратят ресурсы на те же вычисления. На общем стеке одна оптимизация в горячем пути рантайма Discovery умножается на все продукты сразу. Что дало эффект:

1. Перенос тяжёлых вычислений с CPU на GPU. Там, где это действительно оправдано.

2. Переиспользование расчётов между продуктами. Один и тот же признак не считается пять раз в пяти сервисах.

3. Кэширование кандидатов. Часть сильных кандидатов из предыдущего запроса сохраняется и переиспользуется в следующем, чтобы не повторять ^[6] тяжёлые вычисления.

4. Работа с горячим путём запроса. Сериализация, аллокации, лишнее копирование данных.

В отдельных продуктах эффект доходил примерно до 30%. Главное: экономию дал не каждый продукт по отдельности — мы нашли технические точки оптимизации и масштабировали их сразу на несколько продуктов. 

Эффект для рекомендаций

Продукты, которые переехали на платформу с января 2026 года, продолжают стабильно расти:

1. ВКонтакте: +11% времени в ленте. Добавления друзей из рекомендаций выросли на 167%, число новых подписчиков — на 22%, а просмотры постов оригинальных авторов увеличились почти в пять раз. Для ленты клипов время просмотра увеличилось на 22%. Реактивность рекомендаций прибавила 7%, релевантность — 4%.

2. Одноклассники: +5,8% времени в ленте и +1,8% DAU.

3. VK Видео: +20% времени просмотра на главной и +10% в блоке рекомендаций к ролику.

4. VK Музыка: +35% добавляемых треков из рекомендаций VK Микс и −19% дизлайков.

Эффект для рекламы

В начале этого года на Discovery переехали крупные продукты VK Рекламы: реклама сообществ, лид‑формы, реклама мобильных приложений.

Инженерно это интереснее, чем переезд рекомендера. У рекламы свой контур: аукцион, прогноз конверсий, бюджетные ограничения, требования рекламодателя. Но нижние слои те же — отбор кандидатов, прогноз вероятности целевого действия, ранжирование под пользователя. Это позволяет рекламодателям эффективнее запускать кампании, а пользователи видят только интересные им предложения.

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

Следующий шаг — переезд поиска на инфраструктуру Discovery. А о том, какие эксперименты проводила команды и что удалось перевезти на Discovery, расскажем в следующем материале.