✉️ Подписывайтесь на email-рассылку от Yandex for Developers

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

🔶 Подписаться на рассылку можно здесь.

В форме можно выбрать мультистек-дайджесты Yandex for Developers или подписаться на новости для конкретных специальностей — Frontend, ML и Analytics.

📟 Ещё у нас есть отдельные рассылки про мероприятия и карьеру в Яндексе. Выбирайте, что вам интересно, и подписывайтесь по ссылке.

Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend

💹 Разбор архитектурных задач с Яндекс 360

Инженеры Яндекс 360 накопили большой опыт в проектировании систем, которыми пользуются более 100 миллионов человек каждый месяц. И теперь готовы делиться знаниями и объединять вокруг себя единомышленников.

📟 На первой онлайн-встрече Архитектурного клуба посмотрим на задачу по System Design.

📆 26 марта в 17:00 вместе с Дарьей Андреевой, руководителем бэкенд-разработки Биллинга и B2B-платформы, разберём, как проектировать большие группы в организации.

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

🔶 Чтобы принять участие в онлайн-разборе, нужно зарегистрироваться.

Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend

📖 Как выжать максимум из Decoder Attention на GPU

Привет, меня зовут Андрей Шукшов, в Яндекс R&D я пишу YNMT — движок инференса, на котором работают почти все наши LLM. Большую часть времени я пытаюсь понять, почему некоторые вещи работают медленно, а потом делаю их быстрее. Хочу поделиться с вами кейсом из своей практики:

Я разобрал по частям, почему Attention медленно работает на GPU в режиме генерации (декодирования), и написал fused kernel, который объединяет все операции, — чтобы выжать из железа максимум.

В статье на Хабре я рассказал, как решал эту задачу по шагам:

🟢 Нашёл узкое место генерации — decoder attention. Классическая схема (QKᵀ → softmax → V) использует три GPU-kernel, поэтому промежуточные результаты приходится читать и записывать в DRAM несколько раз

🟢 Учёл особенности декодирования. Новый токен даёт один вектор Q, а K и V заставляют расти кеш. Из-за этого вычисление превращается из GEMM в GEMV и входит в узкое горлышко пропускной способности памяти

🟢 Использовал Online Softmax. Этот алгоритм позволяет считать нормализацию по мере обработки данных и не требует сначала вычислять всю матрицу Attention

🟢 Собрал fused CUDA-kernel. Объединил все шаги attention в одном ядре, чтобы обрабатывать K и V по тайлам в shared memory

🟢 Оценил эффективность. Результат — ускорение примерно в 1,5–1,7 раза и 85–91% утилизации пропускной способности памяти

🔶 В статье на Хабре я рассказываю, как железо работает с кодом LLM на глубинном уровне и какие математические трюки помогут сделать модели быстрее.

Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend

🧬 От небольшой стойки до распределённого хранилища

Всем привет, меня зовут Евгений Козев, я руковожу командой NBS в Yandex Cloud. Сегодня расскажу о том, как работают сетевые диски, которые реализуют блочное хранилище и без которых не обходится ни одна виртуальная машина.

❇️ Зачем нужно блочное хранилище

Представьте классическую аппаратную систему хранения данных (СХД): вы берёте стойку, набираете в неё диски и подключаете к компьютеру. Это работает, но у такого подхода есть большой недостаток — отсутствие миграции. Нельзя просто взять и передвинуть виртуальную машину на другой хост, потому что она привязана к вашей СХД.

Чтобы её можно было переключать между железными устройствами и подключать к хранилищу по сети, нужна прослойка. А дальше одной СХД уже не хватает. Поэтому приходится строить распределённую систему с оркестраторами, которые выдают доступ к дискам.

❇️ С чего начинается облако (обычно с опенсорса)

Допустим, что вы — небольшая IT-компания, которой хватит готового решения из OpenStack, например Ceph. Это популярная платформа, ей больше 15 лет. Но рано или поздно вы начнёте расти. А когда клиентов станет много, такую систему будет сложно масштабировать. И вам придётся разбираться, как это всё поддерживать.

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

❇️ Как работает виртуальная машина в Yandex Cloud

Вы как пользователь приходите в региональный сервис Compute, который берёт железный хост в выбранном вами дата-центре и создаёт там Instance с гипервизором — вашу виртуальную машину. А мы как NBS должны присоединиться к нему так, чтобы появились сетевые диски.

❇️ Как мы это делаем

У нас есть сервис Disk Manager. Он принимает запросы от Compute и определяет, что хочет сделать пользователь: снять снапшот с диска, создать или удалить его и так далее. Запросы могут идти в разные дата-центры.

Далее мы идём в NBS-control. Это сервис, который отвечает за создание дисков, работу с ними, их увеличение и уменьшение. Он находит железный хост, на котором запущен ваш Instance, и создаёт на нём Volume — логическую сущность с ID диска, его размером и лимитами. Он подключается к гипервизору через протокол virtio-blk, и в вашей виртуальной машине появляется блочное устройство по адресу /dev/vdb.

❇️ Диски в Yandex Cloud

Для SSD и HDD используем YDB — Yandex Database, СУБД с открытым исходным кодом. Физические диски (pdisk) собираются в виртуальные (vdisk). Из восьми vdisk’ов получается группа. Для репликации, чтобы был консенсус, нужно именно такое количество.

Когда пользователь пишет блок данных, система разделяет этот элемент на четыре части и добавляет к ним ещё две. Это даёт отказоустойчивость ценой накладных расходов. На 1 Мб данных пользователя мы сохраняем 1,5 Мб, но если что-то выйдет из строя, то мы сможем их восстановить.

📟 Кстати, любой диск в Yandex Cloud можно зашифровать с помощью KMS на собственном ключе 🙃 Для этого нужно создать сервисный аккаунт и прокинуть его через Compute к нам.

🔶 В новом выпуске «Как мы делаем Yandex Cloud» я рассказал, кто такой разработчик сетевого блочного устройства, какой стек технологий использует наша команда и как выглядит рабочий процесс.

📺 Смотрите подкаст на ютубе, Rutube и в VK Видео.

🎧 Или слушайте в Яндекс Музыке и на любой удобной подкаст-платформе.

P. S. В рамках ежегодного митапа about:cloud — infrastructure я также поговорил о трёх процессах, на которые уходят ресурсы нашей системы. Смотрите мою часть выступления здесь.

Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend

💹 Переворачиваем архитектуру с ног на голову

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

Но когда мы начали делать Яндекс Аптеки, то поняли, что здесь такой паттерн не сработает. Если у пользователя болит голова, ему всё равно, как называется аптека, главное — найти конкретное лекарство. Поэтому нам пришлось перевернуть архитектуру на 180 градусов.

1️⃣ Сначала мы стали делать всё «по учебнику» через нормализованное хранение. Но оказалось, что в нашем случае CPU базы уходил в полку. Мы пробовали вертикально масштабироваться и накидывали ядра, пытались разбивать батчи айдишников и сплитовать запросы, но результат особо не менялся: база захлёбывалась.

2️⃣ Нужно было действовать радикально — и мы перешли к полной денормализации. Идея была такая: мы не стали джойнить данные на лету или делать сложные выборки и просто сложили всё нужное в одну плоскую таблицу. И всё заработало! Осталось только допилить систему, чтобы выиграть дополнительные миллисекунды.

🔶 А о том, как мы всё это сделали, можно прочитать в блоге Городских сервисов.

Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend

🛎 Я.Субботник по JVM-языкам начнётся через час

Подключайтесь к трансляции:

💸 Сайт
📹 YouTube
💬 VK Видео

Напомним, что ждёт слушателей:

🟢 13:05–13:50 — Андрей Кулешов, руководитель отдела разработки в Yandex Infrastructure. На примере Quarkus покажет, как ускоряются Java-фреймворки

🟢 13:50–14:55 — Дмитрий Некрылов, старший разработчик бэкенда в Yandex Robotics. Расскажет, как работают трассирующие профайлеры в Java изнутри и чем они отличаются от семплирующих

🟢 15:30–16:15 — Всеволод Жолобов, разработчик в Финансовом департаменте Яндекса. Покажет баги и особенности работы java.time

🟢 16:15–17:00 — Николай Леонтьев, разработчик бэкенда в Яндекс Директе. Расскажет про параллельность на корутинах в бэкенде Spring и GraphQL-Java

Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend

💹 Сверхустойчивость: как мы учились работать в режиме «минус один дата-центр»

Всем привет, это Алексей Терентьев, я руковожу одной из служб отдела эффективности Яндекс Go. Недавно перед нами поставили амбициозную цель: так оптимизировать ресурсы, чтобы бесперебойно работать при стопроцентной нагрузке серверов, учитывая, что у нас осталось только два из трёх дата-центров.

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

❇️ Первая проблема — некритичные зависимости с фатальными последствиями

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

☠️ Эта беда осложняется разными багами. Например, в ответе основного сервиса было поле optional_data, которое обогащали данными из десятка других мест. Одно из них упало, а код не был готов к null. В итоге падал весь конвейер. В нашем случае код был на C++ (std::optional), и разыменование nullptr приводило к core dump. Процесс опять мгновенно останавливался.

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

❇️ Вторая проблема — поллинг

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

Получается шквал запросов, 99,9% которых приносят один и тот же ответ, ведь баланс баллов меняется от силы пару раз в день. С учётом того, что подобных параметров может быть много, это создаёт серьёзную холостую нагрузку на бэкенд.

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

Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend

🈯️ Зовём на интенсив ШАДа Agents Week

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

Этой теме Школа анализа данных посвятила интенсив, который пройдёт с 6 по 10 апреля. Эксперты подробно расскажут про AI-агентов:

🟢 Как их проектировать и настраивать
🟢 Что нужно, чтобы вывести в прод, масштабировать и оценивать качество
🟢 Какие подходы помогут построить single- и multi-agent-системы

❇️ Решать практические задания будет проще, если вы:

🟢 Знаете, как работают трансформеры и GPT-like-модели
🟢 Умеете писать код на Python и знакомы с инференсом LLM
🟢 Понимаете API и клиент-серверное взаимодействие

💡 Кому будет полезен этот интенсив: разработчикам (и не только на Python), которые хотят перейти от LLM-запросов к комплексным агентным системам.

📆 Формат: 5 дней онлайн-занятий по вечерам. Чтобы получить сертификат, нужно пройти отборочный тест и выполнить итоговую работу.

💹 Срок подачи заявок: до 9 апреля включительно.

🔶 Программа, спикеры и регистрация

Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend

🔠 Приглашаем на about:cloud — infrastructure 16 апреля

Это большой митап от разработчиков Yandex Cloud и Yandex Infrastructure. Предлагаем заглянуть под капот наших продуктов, разобрать технические кейсы, обсудить ошибки и честно поговорить про инфраструктуру.

В программе:

🟢 Вячеслав Спиридонов, руководитель группы SRE Yandex BareMetal в Yandex Infrastructure. Расскажет про IaC для управления алертами в системах мониторинга

🟢 Валентин Синицын, руководитель Stackland в Yandex Cloud. Покажет, что будет, если заменить оркестрацию процесса установки «хореографией», которая популярна в мире Kubernetes

🟢 Андрей Кириленко, руководитель AI Studio Tech в Yandex Cloud. Расскажет, как оптимизировать инференс LLM

🟢 Евгений Зайцев, ведущий технический менеджер проектов, и Андрей Агарков, технический менеджер проектов, из Yandex Infrastructure. Расскажут, как строили CDN Yandex Cloud и через что пришлось пройти в процессе

🟢 Сергей Хейфец, системный разработчик, и Максим Давыдов, системный разработчик, из Yandex Cloud. На примере Inception (SRSO, CVE-2023-20569) покажут, как команда системной разработки исследует уязвимости и выбирает методы защиты

Ещё наша команда подготовила разные активности: в онлайне пройдёт DevChallenge, а очных участников ждут закрытые сессии.

📆 Когда: 16 апреля
📍 Где: в Москве и онлайн

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

➖ Если у вас остались вопросы, пишите Константину Дроздовскому.

Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend

🧬 Как мы научили Нейроюриста отвечать точнее

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

❇️ Как это работает

Ключевая технология, которая обеспечивает быстрые и точные ответы модели, — векторный индекс. Он был с нуля разработан как часть YDB, распределённой СУБД Яндекса. Такое решение даёт возможность создавать для одной таблицы несколько разных векторных индексов с фильтрацией. Одни оптимизированы для глубокого поиска в миллионах документов за 10 мс, другие — для небольших массивов. В момент запроса Нейроюрист автоматически выбирает тот индекс, который лучше всего подходит под конкретный фильтр.

❇️ Как идёт поиск

Запрос пользователя превращается в вектор — набор чисел, который отражает смысл вопроса. Затем система ищет в индексе максимально подходящие документы. Они, в свою очередь, добавляются в промпт языковой модели, и уже на их основе Нейроюрист формулирует финальный ответ со ссылками на реальные нормы и судебные решения. Такой подход называется RAG (retrieval augmented generation). Он помогает модели не галлюцинировать и опираться только на найденную информацию.

❇️ Что в итоге

Нейроюрист гарантированно получает весь релевантный контекст и обеспечивает нужный уровень полноты и скорости поиска (десятые доли секунды!) в любых категориях. При этом он сохраняет высокое качество ответов даже при расширении базы данных, потому что выбор индекса всегда адаптируется под объём, а сама СУБД YDB отлично масштабируется на миллиарды векторов и записей.

🔶 Подробнее про техническую реализацию можно прочитать в статье на Хабре.

Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend