В 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 на новых мощностях.

Управление десятками и сотнями Helm-релизов быстро перестает быть тривиальной задачей, особенно когда появляются зависимости между релизами, CRD, несколько окружений и своя логика деплоя. 

Меня зовут Владимир Фидунин, я работаю в команде мессенджера VK WorkSpace. В статье расскажу, как мы прошли путь от Puppet + Helm до Helmwave и почему в итоге он стал для нас универсальным инструментом управления Helm-релизами. 

Привет, Хабр! Меня зовут Михаил Рязанский, я руководитель группы технической аналитики в Дзене. Группа включает в себя команды DWH, антифрода, аналитики модерации и ML‑аналитики. Вместе с Марком Хабаровым, лидом команды ML‑аналитики, мы расскажем про наш инструмент для анализа результатов А/Б‑тестов и про интеграцию в него LLM. Получилось интересно, местами — больно. Но обо всём по порядку. 

Привет, Хабр! Я Оля Шишенина, отвечаю за обучение и развитие сотрудников VK. Хочу рассказать про внутреннее мероприятие для инженеров, которое мы провели этой весной: Фиксатон VK — трёхдневный марафон по багфиксам, на котором разработчики чинили баги не только в своих командах, но и в смежных продуктах VK. Решения прошли многоэтапный фильтр от общего пула задач, через проверку кода, QA-ревью при подготовке к релизу.

Победители фиксатона получили Nintendo, Playstation, а главному победителю по баллам в индивидуальном зачёте мы подарили Niva Legend — это отличная машина для того, кто любит фиксить и тюнинговать.

Привет, Хабр! На связи Александр Сабко, Виктория Белявская и Сергей Павлухин, из мастерской по прикладному ИИ Инженерно-математической школы НИУ ВШЭ и VK.

Сейчас текстовые данные все чаще рассматриваются как источник информации о психологическом и эмоциональном состоянии человека (автора текста) — это особенно важно для задач, связанных с психологическим консультированием, анализом пользовательских коммуникаций и мониторингом эмоционального состояния. В тексте нам часто важна  не просто тональность, а динамика эмоционального состояния автора.

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

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

В статье мы расскажем, как мы выстраивали схему разметки на интервью с практикующими психологами, какие источники текстов взяли, что внутри инструмента, и что получилось с дообучением Qwen-3.

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

Привет, Хабр. Меня зовут Александр Кривяков. Я пресейл-архитектор VK Data Platform, VK Tech. В этой статье я расскажу об основных принципах работы ClickHouse, а также покажу возможные архитектурные решения и типичные сценарии применения системы.

Привет, Хабр! В этой статье я расскажу об эволюции подсистемы сериализации one-nio — фреймворка для создания высоконагруженных сервисов, работающего в Одноклассниках с 2012 года. Прошлой осенью я работал над обновлением подсистемы и добавил в нее новый режим работы, совместимый с актуальными версиями JDK.

Ситуация, с которой мы столкнулись, довольно прозаична. Библиотеке больше десяти лет, и экстремально быстрая сериализация (превращение объекта в последовательность байтов и обратно) с самого начала строилась в ней на внутренних лазейках JVM, к которым обычный прикладной код доступа не имеет. Когда one-nio только писали, это был стандартный паттерн для высоконагруженных фреймворков.

Сейчас же платформа методично «закручивает гайки»: старые бэкдоры помечаются как устаревшие, а затем безжалостно удаляются. И перед нами встал серьезный вызов: как перевести библиотеку на легальные API вплоть до JDK 25, сохранив производительность и не сломав то, что годами крутится в проде?

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

Современный поиск по видеоконтенту — это высоконагруженная система, требующая молниеносной реакции и безупречной релевантности. Сервис VK Видео оперирует колоссальной базой в 500 миллионов видеороликов и ежедневно обрабатывает около 10 миллионов запросов пользователей. При времени ответа в 0,5 секунды и нагрузке в 1800 RPS алгоритмам необходимо моментально находить именно тот контент, который ожидает увидеть зритель. Однако развитие алгоритмов ранжирования невозможно без качественных данных, на которых они обучаются. 

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

Меня зовут Владислав Чернышев, я руководитель группы качества поиска по видео в AI VK. В этой статье подробно расскажу про путь перехода от классической ручной разметки к гибридной VLM-системе, разберу ошибки и инфраструктурные барьеры, которые пришлось преодолеть для кратного ускорения процессов подготовки обучающих датасетов и офлайн-оценки качества поиска.

Всем привет! Мы — команда Облака Mail: редактор Наташа, дизайнер Саша и исследователь Лена.

Мы вместе работаем над улучшением сервисов Mail: проводим исследования пользовательского опыта, много дискаверим, проверяем гипотезы, проектируем интерфейсы и пишем тексты, которые помогают пользователям лучше ориентироваться в продукте.

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

Привет, Хабр! Меня зовут Захар Кондауров. Сегодня я хочу поделиться опытом разработки легковесной real-time модели шумоподавления и дереверберации, над которой я работал в рамках проектов Инженерно-математической школы НИУ ВШЭ и VK под руководством Ивана Бескровного, руководителя команды звуковых технологий VK Видео.

Большинство исследований в speech enhancement часто ограничиваются только шумоподавлением, хотя современные архитектуры потенциально позволяют решать более продвинутые задачи, например, совместное шумоподавление и дереверберацию. Это обусловлено тем, что бенчмарков, ориентированных на шумоподавление, значительно больше, чем на другие искажения аудиосигнала, как и моделей для сравнения. Кроме того, далеко не все решения обучены на full-band аудио с частотой дискретизации 48 кГц, в основном только на 16 кГц — это сильно уменьшает диапазон частот в аудиосигнале.

Модель, которая одновременно подавляет шум и выполняет дереверберацию для full-band аудио, позволит устройствам с ограниченным количеством ресурсов обрабатывать речевой сигнал локально, уменьшая нагрузку на серверы и задержку ответа системы. Зачастую задачи шумоподавления и дереверберации решают последовательно разными нейронными сетями. Универсальная модель уменьшит количество используемой памяти и время обработки сигнала.

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

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

Меня зовут Сергей Петриченко. Я продуктовый менеджер VK Data Platform. В этой статье разберем, почему каталог — это не первый шаг к порядку, а скорее мультипликатор уже существующей зрелости и что необходимо сделать, чтобы его внедрение принесло реальную пользу.

Привет! Меня зовут Евгений Астафуров, я ведущий разработчик в Отделе экспериментальных технологий AI VK. Мы разрабатываем Discovery AI — набор ИИ‑технологий для интеллектуального поиска, рекомендаций и взаимодействия с контентом. В него вошли нейропоиск, анализ контекста, персонализация, генеративные модели и рекомендательные алгоритмы, чтобы помогать пользователям находить нужную информацию, получать релевантные ответы и новый контент.

В этой статье подробно разберу архитектуру технологии нейропоиска в Discovery AI, которая объединяет большую языковую модель (LLM), поиск, инференс и данные многомиллиардной контентной базы VK. Технология становится важным компонентом развития рекомендательных и поисковых систем в наших продуктах и будет поэтапно внедряться в сервисы для пользователей, авторов и бизнеса (Дзен, VK, Медиапроекты Mail, VK Видео и другие). 

Привет, Хабр. Меня зовут Дмитрий Сергеев. Я менеджер продукта «виртуальные серверы» (GPU) в компании VK Tech.

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

В этой статье я на примере сервисов VK Cloud разберу, в каких сценариях востребованы физические GPU, а также где и как их можно эффективно заменить с помощью vGPU, чтобы оптимизировать бюджет и сэкономить на аренде полного объема ресурсов.

Привет, Хабр! На связи Нина Андреянова из ВКонтакте, я занимаюсь реализацией больших кросс-командных проектов последние пять лет. Недавно я рассказывала про назначение тимлидом контрибьютора (спасибо за ваш интерес к статье!). Сегодня я пришла поделиться с вами ещё одной темой: высокая продуктивность команды и как руководители иногда её ломают. За годы работы в разных корпорациях я поняла одну неприятную управленческую правду: фраза «давайте ещё немного поднажмём» звучит вдохновляюще… ровно до того момента, пока ты не слышишь её третий квартал подряд. Если эта фраза звучит в команде регулярно, то, вероятнее всего, вы уже не ускоряетесь. Вы просто медленно тратите ресурс, который не восстанавливается.

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

Привет, Хабр! Меня зовут Андрей Орлов, я QA‑инженер в команде Tarantool Database, VK Tech. Я занимаюсь функциональным тестированием: проверяю новые фичи и изменения, поддерживаю и развиваю автотесты, разбираю инциденты, анализирую логи и метрики. Нагрузочное тестирование и стресс‑тестирование тоже входит в мои задачи — в том числе для проверки поведения Tarantool Database на больших конфигурациях. В этой статье я расскажу, как мы организовали и провели тестирование Tarantool Database на 640 инстансах, какие подходы и инструменты использовали и какие выводы сделали.

Как мы пришли к локальному скану, фильтру Блума и переезду очереди на Kafka — и почему это всё случилось 

Привет, Хабр. Я Данил Кислов, разработчик команды хранилищ. У нас в One-cloud (внутренняя корпоративная облачная платформа) лежит собственная S3-совместимая реализация — one-object-storage. Хочу рассказать, как эволюционировал метастор S3— та часть, что отвечает за метаданные объектов: списки версий, индексы, настройки бакетов и прочую служебную мелочь.

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

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

VK Cloud активно использует РЕД ОС от РЕД СОФТ — в том числе в VK Secure Cloud, аттестованном контуре для значимых объектов критической информационной инфраструктуры (ЗОКИИ). На ее примере покажу, как поднять производительность гипервизора, просто обновив легаси и не трогая железо. Вместе с дистрибутивом на ноду приезжает свежий стек целиком: ядро, эмулятор, клиент хранилища, системные библиотеки. Каждый слой подтягивает свой кусок. А для тех, кто застрял на CentOS, ушедшем в EOL, у истории есть вторая часть: обновление закрывает технический разрыв и регуляторику одним движением. Ниже разберу механику по слоям с командами, которые можно выполнить на своей системе.

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

Сначала DBA оптимизируют запросы. Потом появляются новые индексы. Потом увеличивается размер серверов. Затем появляются реплики. Потом еще реплики. И через некоторое время выясняется, что значительная часть бюджета на инфраструктуру уходит на обслуживание системы, которая изначально должна была просто хранить данные.

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

Привет, Хабр. Меня зовут Сергей Фомин. Я старший менеджер продукта Tarantool DataBase. 

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