The AI VK team published a report on Habr about the development of the Discovery platform — a unified infrastructure layer for recommendations, search, and advertising across all VK products. Over the past six months, the platform has changed its operating model: new recommendation services are now configured rather than coded, and neural network ranking has been moved to GPU with millisecond latencies. Simultaneously, a significant increase in engagement on VK Video, the VKontakte feed, and music was recorded, which the team directly links to the updated ranking.
What happened
On October 29, 2026, the AI VK blog on Habr published an engineering report on the scaling of the Discovery platform. Over the past six months, 15 new recommendation verticals were launched on it, the launch of a new recommender was reduced to one day, and about 90% of ranking tasks are now solved by editing configuration without writing new code. The hypothesis testing cycle has been reduced by five times. Discovery Portal appeared — a single point of configuration management with validation, phased rollout, and automatic rollback upon metric degradation. GPU inference of transformer models was introduced into online ranking: dynamic batching, a backup CPU path, and shared GPU usage along with end-to-end runtime optimization freed up 70,000 CPU cores. Product results: +20% watch time on the VK Video main page, +11% time in the VKontakte feed, +35% track additions from recommendations in VK Mix, and in VK Clips, views increased by 5.5% with a 3% increase in likes and a 15% increase in shares, plus a 10% increase in the TVT metric on the VK Video main page.
Context
The Discovery platform is a common runtime on which recommendations, search, and advertising for all VK products operate, with a unified feature layer for model training and inference. The case belongs to the platformization genre: recommendation infrastructure ceases to be a product of a single team and becomes a common layer where launching a new vertical or model is reduced to configuration, and safe rollout is formalized as a separate tool rather than an internal process with a verbal description. From a scientific perspective, the material contains no new architecture or training method — such techniques have long been known from industrial reports. The rarity lies elsewhere: practices of configuration-based launches, latency percentile control, and metric-based rollback are shown as a confirmed production environment of a VK-scale ecosystem, not as a separate experiment.
Why this matters for the industry
The case marks a shift in the standard for everyone building recommendation systems: moving ranking to configurations, managed rollout through a unified portal, and GPU inference in the online environment are now hygiene for large platforms, not an experiment by a single team. The key economic mechanism is the common runtime: one optimization of the hot path, whether it is candidate caching, feature reuse, or migration to GPU, frees up resources for all products at once, not just one service, which explains the order of magnitude of the claimed economy in tens of thousands of cores. If the figures are sustainable, teams will have to explain to the business why launching a model takes weeks instead of days; there is also likely to be increased demand for tooling for model validation, phased rollout, and automatic rollback — a niche that external products rarely occupy. For a startup founder, the conclusion is stricter: if the product relies on standard recommendation engineering, the advantage is likely illusory, and value shifts to proprietary data, distribution, and vertical product.
Why this matters for users
For readers, the publication provides an industrial reference for auditing their own ML feature launch processes: how long it takes to launch a recommender, what share of tasks is solved by configuration, and how rollback is structured when metrics drop. The described patterns are particularly useful: dynamic batching of GPU requests, tail latency control by upper percentiles instead of the average, quality degradation instead of service failure upon model failure, and a unified feature layer for training and inference. For end users of VK, this translates into more accurate recommendations in video, feed, and music. It is not possible to build something on top of the platform: there is no open source, API, or pricing in the material, so the value for an external reader is educational and methodological.
What is currently unknown / limitations
All key figures are self-declared by the VK team: the publication lacks baseline levels for comparison, A/B test durations, and confidence intervals, so causality and the magnitude of effects remain outside independent verification. Operational metrics — launching a recommender in one day, about 90% of configuration tasks, a five-fold reduction in the hypothesis cycle — are given without definitions of baseline levels and measurement boundaries, including the criterion for what is considered a new recommender. Product metrics are provided in aggregate, without a breakdown by experiments and control groups.
Sources
Author
Look at AI, editorial team