Многие СУБД сегодня поддерживают поиск ближайших соседей, нужный для рекомендательных систем и антифрода. Но на практике системы даже с одинаковым алгоритмом «под капотом» могут решать эту задачу с разной эффективностью: пропускная способность (QPS) и задержки могут сильно различаться из-за накладных расходов движка хранения и модели блокировок. И для бизнеса эта разница может обернуться лишними затратами на инфраструктуру или деградацией UX в пиковые часы. Поэтому к этим параметрам нередко предъявляются особые требования. 

Привет, Хабр. Меня зовут Георгий Белянин. В статье я разберу архитектуру векторного поиска в Tarantool и приведу результаты сравнения скорости вставки и запросов с Qdrant и pgvector.

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

Меня зовут Александр Прохоров. Я эксперт команды разработки Developer Productivity в VK Cloud. В статье расскажу, почему классическая инфраструктура тормозила развитие ИИ-проектов и какой подход к управлению вычислительными ресурсами стал ответом на эти вызовы.

Когда работаешь с такими масштабными продуктами, как мы делаем в VK, быстро начинаешь ценить код, который можно не писать. Особенно если речь о небольших сценариях: открыть поповер, анимировать появление блока или подстроить поле под контент. Ещё недавно для таких задач мы почти автоматически тянулись к JavaScript. Но за последние два года CSS сильно расширил свои возможности для задач, связанных с интерфейсом.

Я Максим Кузнецов, занимаюсь оптимизацией производительности и улучшением стабильности веб-версий ВКонтакте. В этой статье расскажу, что уже можно использовать как альтернативу JS, что стоит попробовать аккуратно, а за чем пока лучше просто следить.

Меня зовут Стас Погоржельский, я технологический евангелист VK Cloud и последние месяцы гоняю Prometheus и VictoriaMetrics на одном стенде, чтобы понять, сколько на самом деле стоит одна точка метрики на диске.

Обе системы делают одно и то же: принимают миллионы точек в минуту, хранят их месяцами и быстро отдают в алерты и дашборды. Обе сжимают точку до байтов и долей байта. Именно эти байты, умноженные на миллиарды точек в сутки, превращаются в счёт за диск. Ошибка в расчёте цены сэмпла заканчивается переполненным диском под мониторингом, урезанным retention или незапланированным расходом.

Когда место под метрики кончается, первым на планёрке звучит «сменим движок». Публичные бенчмарки подталкивают к тому же: Флант показывает, что Prom++, форк Prometheus, тратит памяти в 7,8 раза меньше Prometheus v2 (разбор на Habr), VictoriaMetrics показывает трёхкратную экономию диска против Grafana Mimir (бенчмарк VictoriaMetrics, замер вендора, 2022 год).

На моём стенде картина оказалась сложнее. В Prometheus 3.13 и VictoriaMetrics 1.149 ушёл один и тот же набор: 2,88 млн сэмплов, шесть профилей данных, один генератор с фиксированным seed. Внутри одного движка цена сэмпла различалась в 139 раз у VictoriaMetrics и в 12,8 раза у Prometheus. Между движками на одних данных разрыв доходил до 30,7 раза на шести профилях и до 34,3 раза в опыте с точностью. На равномерно случайных float64 движки менялись местами. Один лишний знак после запятой поднимал цену сэмпла у Prometheus в восемь раз, у VictoriaMetrics на 12%.

У нас в публичном облаке VK Cloud у каждого бакета Object Storage есть Bucket Access Policy. Это набор правил в формате JSON, который лежит на самом бакете и говорит, кому какие операции с какими объектами разрешены. Хранилище проверяет эти правила само на каждый запрос. Включается политика в личном кабинете и через S3 API, и я регулярно вижу проекты, где её не настраивали ни разу.

В статье разбираю состав бакет-политики, её отличия от AWS-руководства и что задавать областью действия ключа, а что политикой. Дальше три механизма проверки на endpoint и порядок между ними, перенос политики из AWS-руководства как есть с разбором, почему он не работает, и четыре итерации доводки (Resource, Principal, aws:SourceIp, явный Deny). Затем матрица из 16 запросов с ожидаемыми кодами и скрипт прогона, метрика доли отказов по Cloud Audit, регуляторика, чек-лист переноса между AWS S3, Ceph, MinIO и VK Object Storage.

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

Привет! Это Степан Малькевич, руководитель группы рекомендаций ленты ВКонтакте (AI VK).

За прошедшие месяцы 2026 года время в ленте выросло на 11%. За этими цифрами — серия изменений, каждое из которых сделало свой вклад в рост метрик. Сейчас расскажу, что мы обновили и что из этого вышло.

Привет, Хабр! Мы — Александр Забурдаев, Ксения Золина, Даниил Марценюк, Илья Трофименко, Илья Кулешов — студенты мастерской по сервисам и платформам ИИ в Инженерно-математической школе НИУ ВШЭ и VK. Хотим поделиться опытом, который мы накопили, пытаясь перестать кормить весь речевой сигнал одной и той же нейросети целиком, и дать разным экспертам разбираться с разными типами шума. 

Речь пойдёт о задаче улучшения качества речи (Speech Enhancement, SE) и о том, как получилось интегрировать в неё разреженную смесь экспертов (sparse Mixture of Experts, MoE). Это архитектура, которая в языковых моделях уже стала стандартом, а в обработке аудио до сих пор не прижилась.

Модель мы назвали SESAME — Speech Enhancement with Sparse Adaptive Mixture of Experts. Она построена на базе MP-SENet. В ней стандартные полносвязные блоки внутри трансформера заменены на разреженный MoE-модуль. Код проекта доступен на GitHub.

Зачем вообще понадобилась очередная модель шумоподавления, когда их и так десятки — расскажем ниже. А заодно разберём, какие трюки из мира LLM в аудио работают, а какие нет (например, Expert Choice) — и почему.

Привет! Меня зовут Михаил Трапезников, я руководитель группы рекомендательных технологий в AI VK.

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

Привет, Хабр. Меня зовут Сергей Врулин, я Team Lead в команде агентов VK AI Space — корпоративной платформы для создания и запуска AI-агентов.

В июле 2026 года VK AI Space представила многоуровневую память для корпоративных AI‑агентов. Она позволяет агентам сохранять и переиспользовать информацию на всех этапах работы — в текущем диалоге и в рамках долгих проектов. Потенциально это позволит ускорить подготовку ответов и уменьшить число повторных задач.

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

Apache Kafka — популярная система потоковой обработки событий, предназначенная для сбора, хранения и передачи больших объемов данных в режиме реального времени. Она используется тысячами компаний и разработчиков для построения высокопроизводительных, отказоустойчивых и масштабируемых решений в области аналитики данных, IoT, микросервисов и многих других сфер.

Однако у Kafka есть один важный нюанс: «из коробки» у нее нет графического интерфейса (GUI), что затрудняет понимание текущего состояния кластера, диагностику неполадок и эффективное управление инфраструктурой и самим сервисом, особенно для начинающих пользователей или тех, кому сложно взаимодействовать с консольными инструментами.

Поэтому для комфортной работы с Apache Kafka активно используются специализированные UI-инструменты. Например, ранее для облачного сервиса Managed Kafka от VK Cloud мы использовали Provectus Kafka UI, но в рамках развития сервиса решили заменить UI на более современный и функциональный.

Меня зовут Никита Суровегин. Я продукт-менеджер в команде VK Data Platform, VK Tech. В этой статье я расскажу, с чего мы стартовали, какие инструменты проанализировали и что выбрали в итоге.

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

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

Статья написана на основе моего вебинара, можно посмотреть его в записи. 

Объектные хранилища, работающие по протоколу S3, уже давно стали де-факто стандартом для работы с неструктурированными данными — от бэкапов корпоративных систем до наполнения озёр данных (Data Lake) для аналитики. Однако переход от простого использования API к построению на базе S3 отказоустойчивой и безопасной инфраструктуры часто оказывается сложнее, чем кажется на первый взгляд, а многие встроенные механизмы остаются невостребованными. И связано не столько с отсутствием бизнес-потребности, сколько с недостаточным пониманием того, как именно эти функции работают. 

Чтобы устранить подобные «слепые зоны», в статье разберём, как с помощью объектных хранилищ решаются ключевые задачи обеспечения безопасности, катастрофоустойчивости и эффективности хранения.

Привет! На связи Артём Матвеев из команды AI VK Research. Мы занимаемся фундаментальными и прикладными исследованиями в области рекомендательных систем, поиска и генеративного искусственного интеллекта. 

Сегодня я расскажу про нашу работу, которая была принята на воркшоп End-to-End Customer Journey Optimization конференции KDD 2026. KDD — A*-конференция и одна из ведущих мировых площадок в области машинного обучения и искусственного интеллекта, где обсуждают развитие рекомендательных систем, поиска, рекламы и других AI-технологий.

Наша статья называется Session-Level Optimization for Large-Scale Retrieval using REINFORCE with Multi-Step Off-Policy Correction. Рассказываем, как мы научили модель рекомендаций сразу оптимизировать долгосрочную удовлетворённость пользователя (long-term user satisfaction).

Представьте себе баг-репорт: все шесть подов в статусе 1/1 Running, Readiness зелёный, kafka-agent на брокерах отдаёт 204. А кластер мёртв: оператор бесконечно крутит реконсайл и валится в TimeoutException: Timed out waiting for a node assignment. Call: describeMetadataQuorum. Если зайти на том контроллера, можно увидеть, что __cluster_metadata-0/quorum-state: leaderId выставлен, а appliedOffset в 0. Ни одна запись метаданных не применена. JVM живые, raft-лог на диске растёт, и при этом ни один под не написал в stdout ни строки следующие восемь часов. Это не выдумка, а реальный баг-репорт Strimzi от 25 мая 2026, и к нему мы ещё вернёмся.

В Kafka 4.x больше нет привычного «запасного выходa» в виде ZooKeeper: метаданные переехали внутрь самой Kafka (KRaft), и если кворум контроллеров теряет большинство, чинить уже приходится сам кластер Kafka, а не внешний сервис. 

Раньше чтобы с этим справиться в Kafka существовал ZooKeeper, отдельная система со своими инструментами, ансамблем и культурой восстановления. В версии  4.x его нет, и в документации от процедуры остался только линк на 3.9. Метаданные переехали внутрь самой Kafka (KRaft), и если кворум контроллеров теряет большинство, чинить уже приходится сам кластер Kafka, а не внешний сервис.

В этой статье расскажем, что делать в такой ситуации и как восстанавливать этот кворум, чтобы не случилось ситуации, описанной выше.

Привет! Меня зовут Михаил Трапезников, я руководитель группы рекомендательных технологий в AI VK.

Одна из главных задач рекомендательных систем внутри крупных экосистем — найти взаимосвязь в разных паттернах потребления контента и применить в алгоритмах. Пользователь может смотреть длинные видео в VK Видео, короткие клипы в VK Клипах и листать ленту ВКонтакте, но каждый из этих сигналов описывает его интересы лишь частично. Для решения этой задачи мы разработали нейропрофиль пользователя, который формирует единое представление его интересов на основе всех типов взаимодействий с контентом внутри разных продуктов.

В этой статье я расскажу:

Как мы создали нейропрофиль — единую трансформерную модель, которая объединяет сигналы пользователя из разных сервисов VK и формирует целостное представление о его интересах.

Как устроена его архитектура, какие данные она использует и как обучается на миллиардах взаимодействий с контентом.

Как кросс-доменный подход помогает улучшать рекомендации в VK Видео, VK Клипах и других продуктах экосистемы.

База данных — бизнес-критический компонент любой ИТ-инфраструктуры, поэтому вопрос обеспечения ее доступности и отказоустойчивости обычно находится в центре внимания. Однако, фокусируясь на отказоустойчивости, компании нередко недооценивают риск переполнения диска. При этом подобные ситуации могут оставаться незамеченными до полной остановки записи БД, например при заполнении отдельного раздела, где хранятся данные или WAL.

Привет, Хабр. Меня зовут Александр Шмелёв. Я Team Lead команды разработки Databases, VK Tech. В этой статье я расскажу о рисках и причинах переполнения дисков, а также рассмотрю несколько способов предотвращения подобных проблем.

Security Gate — это наша внутренняя AppSec-платформа, объединяющая инструменты и практики для проверки безопасности кода, зависимостей и других компонентов разработки. Платформа помогает находить потенциальные проблемы безопасности, приоритизировать результаты сканирования и встраивать проверки в привычный процесс работы с кодом.

В статье разберём, из чего состоит Security Gate, как устроены приоритизация находок и интерфейс и какие возможности доступны разработчикам.

Демо нагрузки и реальная нагрузка различаются. Демо всегда быстрое — если поставить модель и прогнать пару запросов, то latency вас обрадует, а TTFT, вероятнее всего, будет приятным. Но когда сервис неделю живет под реальной нагрузкой, начинаются проблемы: p99 растет, память утекает, а однажды прилетает OOM на запросе, который вчера проходил без проблем.

Я Стас Погоржельский, технологический евангелист VK Cloud, неоднократно наблюдал этот сценарий в демонстрационных средах. Инференс редко выходит из строя сразу и явно; как правило, его работа постепенно ухудшается, оставаясь незаметной до достижения критического состояния. 

Ниже я разберу четыре механизма, приводящие к деградации производственной среды на длительном интервале: фрагментацию KV-кэша, нехватку памяти (OOM) при работе с длинным контекстом, блокировку очереди (head-of-line blocking) внутри батча и расхождение метрик p50 и p99. Для каждого случая опишу внутреннее поведение системы, способы воспроизведения проблемы и метрики, сигнализирующие о надвигающемся инциденте.

В 2024 году была опубликована интересная статья, в которой описано, как за 54 дня обучения Llama 3 405B кластер Meta из 16 384 карт H100 пережил 419 внезапных прерываний, примерно по одному каждые три часа. 58,7% из них пришлись на GPU и их память. Процессоры за то же время отказали дважды. Свежее по такому масштабу никто ничего не публиковал, но тренд на Kubernetes с тех пор только усилился: по опросу CNCF за 2025 год, 82% пользователей контейнеров гоняют кубер в проде и 66% компаний с genAI-моделями держат на нем инференс.

Сам Kubernetes до сих пор как будто бы уверен, что отказы лечатся рестартами. Для stateless-сервиса это правда, а вот для пода с GPU нет: если контейнер упадет, то kubelet поднимет его заново на том же мертвом устройстве, и все пойдет по кругу.

Я Стас Погоржельский, технологический евангелист VK Cloud. Про то, как раздавать GPU через DRA, на Хабре уже писали, про отказоустойчивость кластеров в целом тоже. Эта статья про то, о чем обе умалчивают: что происходит после того, как выданное устройство умерло. Мы посмотрим на это наглядно: соберем отказный стенд, отберем у пода GPU и посмотрим глазами kubectl, кто и когда об этом узнает. А потом разберем механизмы 1.36, с которыми из этой ситуации впервые можно выйти без вечного Pending и без убийства ноды целиком.

В нашей компании исторически сложилась децентрализованная модель управления данными. Каждая из бизнес-вертикалей развивала собственные аналитические системы и хранилища, выбирая технологии и инфраструктуру независимо. В результате сформировался ландшафт из разрозненных решений с дублирующей функциональностью и растущим числом физических кластеров. На момент принятия решения о переходе в облако инфраструктура насчитывала более 10 отдельных железных кластеров под Airflow, Hadoop и смежные технологии. Совокупный объём аналитических данных достиг 0,5+ эксабайта (EB). 

Такая архитектура создавала не только технические, но и бизнес-ограничения. Обмен данными между вертикалями был затруднён: мешали как различия в инфраструктуре, так и юридические тонкости, связанные с оформлением доступа. Поддерживать такой ландшафт становилось всё сложнее. Поэтому в компании решили построить единую платформу для работы с данными, чтобы увеличить скорость и качество принятия решений на основе данных как в runtime, так и в отчётности и А/Б-тестах. 

Я Василий Ципиди, операционный руководитель OneDWH VK. Вместе с техническим руководителем OneDWH VK – Олегом Виноградовым расскажем сегодня о том, как мы подошли к миграции 0,5+ EB данных на единый облачный стек, какие архитектурные решения выбрали, чтобы обеспечить целостность данных и как перестроили процессы, чтобы гарантировать предсказуемость SLA на новых мощностях.