Это первая (после нулевой) статья из серии Нейро сети для самых маленьких, в которой мы разбираем инфраструктуру для запуска нейронных сетей.

Для обучения и инференса нейросетей и для любых видов High Performance Computing используются специализированные технологии: GPU/TPU, RDMA, Kernel bypass, NVLink, InfiniBand, RoCE и другие. Про некоторые из них большинство только что-то слышали, но сталкиваться с ними не приходилось.

Нельзя просто взять ванильный стек Linux, воткнуть в него 400Gb Ethernet+IP и получить рабочее решение. Почему?

Потому что общее решение на масштабе в большинстве случаев проигрывает специализированным как в скорости, так и в стоимости. Как бы странно последнее ни звучало.

У студенческих проектов часто есть проблема: после защиты они отправляются в архив. Студент получает оценку, преподаватель — отчёт, но результат редко кто-то использует.

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

Ранее мы уже рассказывали на Хабре, как начать контрибьютить в YDB и какие задачи могут подойти для первых опенсорс-вкладов. Эта статья — продолжение той же темы, но с фокусом на студентах: в ней мы делимся, как подбираем темы для дипломов и учебных проектов, как сопровождаем работу и почему стараемся делать так, чтобы результат был полезен не только на защите.

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

Ярким кейсом стал проект к премьере сериала «Кибердеревня». Мы сканировали гостей мероприятия, создавали их 3DGS‑аватары (3D Gaussian Splatting) и интегрировали в подготовленные Unity‑сцены. Этот пайплайн наглядно подсветил узкое место: при масштабировании производства скорость упирается не в креатив или алгоритмы реконструкции, а в возможности инфраструктуры рендеринга. Стало очевидно, что нам нужно решение, способное ускорить обработку в десятки раз.

Традиционно такие задачи решаются на локальных рабочих станциях или через специализированные внешние рендер‑фермы. Однако в Яндексе уже есть YTsaurus — распределённая система с GPU‑кластерами, поддержкой контейнеризации и отработанными механизмами планирования задач. Меня зовут Анатолий Томилов, я разработчик инфраструктуры VR и 3D‑реконструкции, в Фантехе. В статье я расскажу, почему идея использовать YTsaurus в качестве внутренней рендер‑фермы выглядела логичной, но её реализация оказалась нетривиальной.

В марте 2024 года Redis сменил лицензию и, тем самым, положил начало развитию Valkey. Два года Valkey активно развивался: набирал количество контрибьютеров, коммитов, был встроен в многие проекты — в общем, показал себя на практике. Пришло время подвести итоги и понять: есть ли в этом сравнении победитель.

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

Привет, Хабр! Меня зовут Андрей Серебрянский. Раньше я строил платформы потоковой обработки данных в банках, а теперь вместе с командой разрабатываю YDB Topics и YMQ. После своих докладов на конференциях мы с коллегами по индустрии часто обсуждаем брокеры сообщений. И меня, как разработчика таких решений, огорчает упрощённый подход: «RabbitMQ не нужен, всё можно собрать на Kafka».

Вспоминая известную шутку: да, с помощью буханки бородинского и двух спиц можно собрать модель троллейбуса. Но зачем? Да, я люблю Kafka и с удовольствием про неё рассказываю на Хабре и Хайлоаде. Но, кроме Kafka и RabbitMQ, есть и третий класс брокеров сообщений: SQS-совместимые очереди в облачных платформах (и не только), которые для многих продакшн-задач подходят лучше, чем Kafka.

Опытные разработчики, проводя system design interview, любят спрашивать друг друга о разнице между брокерами сообщений. А мне каждый раз хочется ответить: «Зависит от контекста». В статье под катом я начну с такого контекста: напомню, для чего изначально создавались SQS, RabbitMQ, Kafka. После этого расскажу про принцип «простой API, умный сервер» и про задачи, которые в эпоху микросервисов решаются с помощью брокеров. А в завершение — про реализацию SQS, над которой сейчас работаю: Yandex Message Queue.

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

Yandex Smart Web Security — это сервис для защиты сайтов и приложений от DDoS‑, веб‑атак и ботов, который разрабатывают несколько команд Яндекса: Yandex Cloud, Yandex Infrastructure и команда Антиробота. Недавно мы добавили новую функциональность по работе с роботами: пользователям облачной платформы она даёт возможность самостоятельно настраивать правила для выделения роботного трафика буквально с помощью пары бегунков. Мы делаем фокус на простых инструментах управления. Но за этими, казалось бы, небольшими улучшениями интерфейса, стояла большая инженерная работа.

На связи Денис из команды платформы данных в Yandex Cloud. Мы занимаемся разработкой системы SPQR, которая помогает легко реализовать горизонтальное масштабирование PostgreSQL с помощью шардирования. И это не теоретическая задача на два шарда и десять таблиц. Необходимо сделать систему, которая в пределе хранит петабайты данных и выдерживает сотни тысяч запросов в секунду. 

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

Привет, я Павел Семенищев, сетевой инженер в Yandex Infrastructure. В команде Network Operations Center (NOC) мы отвечаем не только за магистральные и дата‑центровые сети, но и за офисные, а также сети складов и дарксторов Яндекс Лавки. А это ОЧЕНЬ много удалённых точек присутствия, и при проблемах с Wi‑Fi на каждую сетевика не отправишь.

Для быстрого сканирования параметров сети на местах я создал WiProber под Android и WiFi Prober под iOS — получился сетевой «комбайн» для инженера, который сначала был нашим внутренним инструментом, а теперь есть и в общем доступе. Под катом расскажу, что умеют эти приложения, и какие ограничения операционных систем удалось обойти при их создании.

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

НМИЦ кардиологии им. ак. Е. И. Чазова Минздрава России при поддержке Центра технологий для общества Yandex Cloud запустил цифровой регистр пациентов, перенёсших ОКС. Для решения этой задачи мы обеспечили безопасную обработку более 13 тыс. медицинских документов с помощью больших языковых моделей и дали кардиологам максимум информации для исследований, мониторинга и предотвращения риска. 

Меня зовут Евгений Попов, в Yandex Cloud я руковожу проектами по направлению «Медицина». Сегодня я расскажу об этапах разработки решения и остановлюсь подробнее на нетривиальной задаче обезличивания данных.

Меня зовут Евгений Ефимкин, я руковожу группой Platform Reliability в Yandex Cloud. В числе прочего мы занимаемся безопасностью наших managed‑сервисов.

В managed PostgreSQL мы не выдаём клиенту привилегии superuser — иначе он сможет выйти за пределы своей базы прямо в операционную систему. Чтобы клиент при этом мог выполнять привилегированные операции: создавать базы, заводить роли, менять настройки кластера, — мы пишем сервисы Control Plane и выдаём специальные ограниченные роли (без выхода в ОС и без обхода проверок прав).

Несколько лет назад, занимаясь поддержкой логической репликации, я понял, что и этого мало: у PostgreSQL остаются места, где он сам, изнутри, выполняет код от superuser в обход всей конструкции. Дальше — два случая повышения привилегий у двух разных публичных облачных провайдеров. Оба вектора к моменту публикации закрыты — и в апстриме PostgreSQL, и у самих сервисов; оба провайдера своевременно проинформированы.

Меня зовут Дима Кирпа, я разработчик из команды ML Laboratory в Yandex Infrastructure. Четыре года я делаю внутренний поиск по корпоративному интранету Яндекса. Сегодня предлагаю ненадолго отложить судорожный тюнинг промптов и температуры LLM и окинуть внутренние корпоративные знания более широким взглядом. На примере опыта Яндекса я разберу процесс LLM‑изации интранета компании с самых азов. На время мы вернёмся в ламповый мир старого доброго фича‑инжиниринга, неспешно пройдёмся от настроек ранжирования к настройкам поискового контекста для LLM и увидим, как фичи поиска плавно перетекают в фичи генеративки. Напоследок убедимся, что всё не зря и наши разработки реально приносят пользу компании.

Я расскажу, как устроен бэкенд и ранжирование внутреннего поиска Яндекса, как на базе внутреннего поиска мы построили генеративную Q&A‑систему AI Chat. Покажу обоснования разных внедрений в виде чисел из реальных A/B‑экспериментов. Никакого хайпа, только факты. Цель статьи — доказать, что поиск — это база для корпоративных процессов обмена знаниями, а модель роста от поиска к агенту — самая эффективная.

Привет, это Всеволод Иванов и Артём Икчурин из Yandex Infrastructure — в нашей инфраструктурной команде Cloud Storage Services мы занимаемся разработкой хранилищ, которые внутри компании используются самыми разными сервисами. В Яндексе есть несколько систем хранения для разных задач, в том числе объектное хранилище для неструктурированных данных.

Несколько лет назад мы искали способы ограничить нагрузку на внутренний сервис S3 — так появилось наше собственное решение Yet Another Rate Limiter, или YARL, о котором мы уже писали на Хабре. Сегодня расскажем, как развивается наш лимитер. Так что если вам интересны высокие нагрузки, рекомендуем ознакомиться с предыдущей статьёй и затем вместе с нами отправиться под кат за продолжением.

Всем привет, меня зовут Антон Рыбочкин, я старший разработчик бэкенда в команде Yandex Monium. Monium — это платформа для сбора, хранения и анализа телеметрии (метрик, логов и трейсов). Она позволяет дать оценку того, как себя чувствует сервис, находить причины сбоев, оперативно уведомлять об аномалиях.

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

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

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

Привет, меня зовут Рамиль Габдрахманов, я руковожу разработкой видеоплееров в Yandex Infrastructure. Нашу видеоплатформу используют многие сервисы Яндекса: Кинопоиск, Яндекс Маркет, Яндекс Музыка и другие — а компании вне Яндекса могут использовать её через Yandex Cloud Video. В день наш плеер воспроизводит 103 847 867 931 секунду видео.

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

Greenplum много лет был в опенсорсе на GitHub под лицензией Apache 2.0. Казалось бы, лицензия Apache 2.0, что может пойти не так? Осенью 2023 года репозиторий неожиданно перестал принимать наши пул‑реквесты. Все наши CLA отозвали, а новые не подтвердили без каких‑либо пояснений.

А в мае 2024-го репозиторий был закрыт. Да, к опенсорс‑проекту могут потерять интерес — и он окажется заброшен. Но здесь, по сути, присвоили наши пул‑реквесты, изменив лицензию у кода, который мы написали, просто потому, что «ничего личного, это бизнес». Обстоятельства менялись, и вот — новые правила использования БД. Твои опыт и достижения либо присваиваются корпорацией, либо обнуляются.

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

На контроллере домена система EDR фиксирует подозрительную активность. Кажется, ничего такого. Обычный алерт, один из нескольких тысяч, которые ежедневно обрабатывает SOC. Однако уже через 15 минут этот инцидент приведёт к полному хаосу в ИБ‑отделе и заморозит деятельность всей компании. 

Меня зовут Сергей Нестерук, я отвечаю за безопасность применения искусственного интеллекта в Yandex Cloud. В этой статье расскажу, как не допустить ситуации, которую я только что описал.

Привет, это Андрей Мелихов, ведущий разработчик интерфейсов в Yandex Cloud. Я работаю в команде DataLens — BI‑системы для визуализации больших наборов данных на дашбордах и графиках. 

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

На связи Денис Волков из команды платформы данных в Yandex Cloud. В предыдущей статье мы рассказали, как устроен SPQR (Stateless Postgres Query Router): архитектура, компоненты и принципы. Красивая теория. Эта статья — про то, что происходит, когда теорию начинаешь применять к живому продакшену с десятками таблиц, набором микросервисов и новогодней нагрузкой. Про грабли, решения и конечно же проблемы.

Меня зовут Григорий Орлов, я руководитель команды разработки сетевых сервисов гибридных облаков в Yandex Cloud. В статье расскажу про детали работы наших сервисов на уровне Config Plane — это уровень, на котором пользователь может задавать целевое состояние системы. А именно речь пойдёт про CIC‑API — сервисе управления железом, которое стоит на наших точках присутствия и участвует в работе Cloud Interconnect, необходимого для создания приватных выделенных сетевых соединений.

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

Меня зовут Сергей Кукуруз, я руковожу ML‑проектами в центре технологий для общества Yandex Cloud. В этой статье расскажу, как мы совместно со студентами Школы анализа данных (ШАД), а также с движением добровольцев «СтопБорщевик» автоматизировали этот процесс с помощью машинного обучения. Мы подробно разберём технический пайплайн: от нормализации GeoTIFF‑файлов и извлечения признаков (индекс CIVE) до обучения модели в CatBoost.

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