Discovery-платформа была представлена в конце января как общий фундамент для рекомендаций, поиска и рекламы во всех сервисах VK. Архитектурно она решает типовую задачу: взять большой каталог объектов, отобрать кандидатов, отранжировать их под конкретного пользователя и показать в ленте десяток лучших результатов. Раньше эти сценарии реализовывались десятками разрозненных способов, теперь они сведены к единой инфраструктуре с готовыми данными, рантаймом, унифицированным развёртыванием моделей и A/B-контуром. За последние месяцы команда сосредоточилась на трёх направлениях: скорости запуска новых вертикалей, едином интерфейсе управления и эффективности использования вычислительных ресурсов.

Ключевым результатом стало появление 15 новых рекомендательных вертикалей, которые уже работают в проде, обучаются на реальных данных и развиваются за счёт смены источников кандидатов, добавления факторов и экспериментов. Особое значение имеет переезд на платформу небольших сценариев внутри продуктов, где строить отдельный рекомендер неэффективно — например, задач ранжирования комментариев. Раньше запуск рекомендера делился на содержательную часть (кандидаты, модель, метрики) и рутинную (поднятие сервиса из шаблона, выкатка, дашборды, алерты, логирование, A/B-контур), причём именно рутина занимала недели ручной работы. За полугодие процесс автоматизировали: теперь вертикаль описывается в конфигурации, а платформа сама разворачивает сервисы, заводит потоки данных, создаёт мониторинги, подключает эксперименты и выдаёт доступы в смежных системах. По оценке команды, цикл «идея — эксперимент — вывод» сократился в пять раз, а новую рекомендательную систему в продукте удаётся запускать в среднем за месяц; новые сотрудники проводят первые успешные эксперименты в проде втрое быстрее.

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

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

Контекст этих изменений связан с общим трендом на консолидацию ML-инфраструктуры внутри крупных технологических компаний. Рекомендательные системы исторически развивались децентрализованно: каждая продуктовая команда собирала собственный стек, что приводило к дублированию разработки и росту затрат на поддержку. Discovery-платформа повторяет логику, которую используют крупные международные игроки, строящие внутренние платформы машинного обучения с едиными каталогами данных, feature store и контуром экспериментов. Для VK это особенно актуально на фоне масштаба экосистемы: десятки продуктов, каждый из которых нуждается в рекомендациях, поиске и рекламе, а также на фоне роста нагрузки на инфраструктуру из-за ИИ-сервисов. В этом смысле переход к конфигурационному описанию вертикалей и автоматическому развёртыванию снижает зависимость от отдельных инженеров и позволяет тиражировать удачные решения между доменами — например, переносить наработки из рекламы в рекомендации и наоборот.

Для российского рынка эта история важна прежде всего как пример зрелости внутренних платформенных команд. Публичное описание архитектуры, метрик и механик безопасности изменений встречается нечасто: компании обычно раскрывают лишь общие цифры. Здесь же видны конкретные показатели — 15 вертикалей, сокращение цикла гипотез в пять раз, ускорение онбординга втрое, 70 тысяч высвобожденных ядер, десятки изменений в день через портал. Для отрасли это сигнал, что конкуренция в рекомендательных системах смещается от отдельных моделей к инфраструктуре и скорости экспериментов: выигрывает не тот, у кого лучшая модель, а тот, кто быстрее и дешевле проверяет гипотезы в проде. Кроме того, кейс показывает, как GPU-инференс постепенно становится штатной частью ранжирования в реальном времени, а не экзотикой для исследовательских задач.

Если сравнивать с альтернативами, то команды могли бы и дальше строить рекомендеры по отдельности или опираться на внешние облачные ML-платформы. Первый путь дешевле на старте, но дорожает с ростом числа сценариев и плохо масштабируется по экспертизе; второй даёт готовые инструменты, однако ограничивает контроль над инфраструктурой и данными, что критично для системы уровня Tier A с жёсткими требованиями к надёжности. Собственная платформа в этом смысле занимает промежуточную позицию: она сохраняет контроль и позволяет оптимизировать железо под конкретные нагрузки, но требует постоянных вложений в разработку и поддержку. Автоматизация запуска вертикалей и портал управления как раз снижают стоимость владения такой платформой, делая её экономически оправданной для небольших сценариев, которые раньше просто не рассматривались. Дальнейшие шаги команда не раскрывает детально, но логика развития просматривается: расширение числа вертикалей, углубление автоматизации и дальнейшая оптимизация ресурсов. Открытыми остаются вопросы о том, насколько универсальным окажется конфигурационный подход для принципиально новых типов контента, как будет масштабироваться GPU-инференс при росте нагрузки и появится ли у портала функции для смежных доменов за пределами рекомендаций, поиска и рекламы. Пока же главный эффект — изменение экономики экспериментов: когда запуск рекомендера стоит один день, а не недели инженерной работы, продуктовые команды начинают пробовать рекомендации там, где раньше не считали это целесообразным, и именно это, вероятно, определит следующий этап развития платформы.