Как выжать максимум из decoder attention на GPU
Генерация токенов в LLM часто упирается не в слабое железо, а в то, что вычисления организованы неоптимально. Андрей Шукшов (Яндекс R&D) рассказал на Хабре, почему так происходит, и показал способ насытить память GPU в режиме декодирования.
GPU и CPU: throughput vs latency
CPU оптимизированы для задач с низкой задержкой и сложной логикой. GPU делают ставку на параллелизм: тысячи более простых ядер выполняют одинаковые операции одновременно. Задержка DRAM скрывается за счёт большого числа потоков и высокой пропускной способности памяти. Это выглядит идеальным для LLM, в которых нужно одновременно выполнять триллионы однотипных операций. Главное тут — постоянно держать видеокарту полностью загруженной.
Как работает параллелизм на GPU
Казалось бы, CUDA даёт удобную модель с множеством независимых потоков, но на практике GPU работает варпами по 32 потока с одной инструкцией на всех. При расхождении веток варп последовательно исполняет обе, из-за чего часть потоков простаивает и теряется производительность.
SM внутри GPU
Streaming Multiprocessor (SM) — основная рабочая единица GPU. На видеокарте их больше сотни, и между ними распределяется вся работа. Внутри SM находятся CUDA Cores, Tensor Cores и быстрая Shared Memory. Чтобы всё работало, нужно давать достаточно параллельных задач и активно использовать быструю память, иначе SM будут простаивать или упираться в доступ к DRAM.
Декодер — худший сценарий для GPU
В режиме генерации модель выдаёт текст слово за словом. Каждый новый токен — это один вектор, который нужно умножить на весь накопленный KV-кэш предыдущих токенов. То, что в обучении выглядит как плотное умножение матрицы на матрицу (GEMM), в декодере превращается в умножение вектора на матрицу (GEMV). А это уже memory-bound-сценарий: вычислений мало, чтения из памяти много.
Аттеншн при этом состоит из трёх последовательных шагов:
1) Q @ Kᵀ;
2) Softmax;
3) умножение на V.
Если выполнять их как три отдельных кернела, результаты каждый раз записываются в глобальную память и снова читаются обратно. Для memory-bound-задачи это критично: мы трижды гоняем данные через DRAM и теряем пропускную способность.
Всё из-за софтмакса
Кажется логичным объединить всё в один кернел и не писать промежуточные результаты в память. Но софтмакс требует редукции по всей строке, потому что для подсчёта знаменателя, нужно увидеть все элементы. Это плохо сочетается с тайлингом, который используется для GEMM на уровне SM. Получается, софтмакс мешает в лоб зафьюзить все три операции.
Online Softmax и fused kernel
Решение — Online Softmax, с которым софтмакс можно считать итеративно. Данные обрабатываются частями, и софтмакс встраивается внутрь одного fused kernel`а.
Теперь тайлы K и V загружаются из DRAM в Shared Memory, внутри SM считается часть Q @ Kᵀ, на лету обновляется Online Softmax и сразу же домножается на V. Всё происходит в одном кернеле, без лишних обращений к глобальной памяти. Вместо трёх поездок «на склад» достаточно одной.
Результаты
Fused kernel даёт ускорение минимум в 1,5 раза по сравнению с тремя стандартными вызовами.
Главная метрика для memory-bound задач — утилизация пропускной способности памяти. В эксперименте она доходит до 85–91% от теоретического пика. Это значит, что алгоритм практически полностью насыщает шину памяти и упирается в физический предел железа.
Полное описание эксперимента, разбор архитектуры SM с деталями и замерами, а также выводы от автора — в хабростатье.
ML Underhood
Генерация токенов в LLM часто упирается не в слабое железо, а в то, что вычисления организованы неоптимально. Андрей Шукшов (Яндекс R&D) рассказал на Хабре, почему так происходит, и показал способ насытить память GPU в режиме декодирования.
GPU и CPU: throughput vs latency
CPU оптимизированы для задач с низкой задержкой и сложной логикой. GPU делают ставку на параллелизм: тысячи более простых ядер выполняют одинаковые операции одновременно. Задержка DRAM скрывается за счёт большого числа потоков и высокой пропускной способности памяти. Это выглядит идеальным для LLM, в которых нужно одновременно выполнять триллионы однотипных операций. Главное тут — постоянно держать видеокарту полностью загруженной.
Как работает параллелизм на GPU
Казалось бы, CUDA даёт удобную модель с множеством независимых потоков, но на практике GPU работает варпами по 32 потока с одной инструкцией на всех. При расхождении веток варп последовательно исполняет обе, из-за чего часть потоков простаивает и теряется производительность.
SM внутри GPU
Streaming Multiprocessor (SM) — основная рабочая единица GPU. На видеокарте их больше сотни, и между ними распределяется вся работа. Внутри SM находятся CUDA Cores, Tensor Cores и быстрая Shared Memory. Чтобы всё работало, нужно давать достаточно параллельных задач и активно использовать быструю память, иначе SM будут простаивать или упираться в доступ к DRAM.
Декодер — худший сценарий для GPU
В режиме генерации модель выдаёт текст слово за словом. Каждый новый токен — это один вектор, который нужно умножить на весь накопленный KV-кэш предыдущих токенов. То, что в обучении выглядит как плотное умножение матрицы на матрицу (GEMM), в декодере превращается в умножение вектора на матрицу (GEMV). А это уже memory-bound-сценарий: вычислений мало, чтения из памяти много.
Аттеншн при этом состоит из трёх последовательных шагов:
1) Q @ Kᵀ;
2) Softmax;
3) умножение на V.
Если выполнять их как три отдельных кернела, результаты каждый раз записываются в глобальную память и снова читаются обратно. Для memory-bound-задачи это критично: мы трижды гоняем данные через DRAM и теряем пропускную способность.
Всё из-за софтмакса
Кажется логичным объединить всё в один кернел и не писать промежуточные результаты в память. Но софтмакс требует редукции по всей строке, потому что для подсчёта знаменателя, нужно увидеть все элементы. Это плохо сочетается с тайлингом, который используется для GEMM на уровне SM. Получается, софтмакс мешает в лоб зафьюзить все три операции.
Online Softmax и fused kernel
Решение — Online Softmax, с которым софтмакс можно считать итеративно. Данные обрабатываются частями, и софтмакс встраивается внутрь одного fused kernel`а.
Теперь тайлы K и V загружаются из DRAM в Shared Memory, внутри SM считается часть Q @ Kᵀ, на лету обновляется Online Softmax и сразу же домножается на V. Всё происходит в одном кернеле, без лишних обращений к глобальной памяти. Вместо трёх поездок «на склад» достаточно одной.
Результаты
Fused kernel даёт ускорение минимум в 1,5 раза по сравнению с тремя стандартными вызовами.
Главная метрика для memory-bound задач — утилизация пропускной способности памяти. В эксперименте она доходит до 85–91% от теоретического пика. Это значит, что алгоритм практически полностью насыщает шину памяти и упирается в физический предел железа.
Полное описание эксперимента, разбор архитектуры SM с деталями и замерами, а также выводы от автора — в хабростатье.
ML Underhood
🔥16❤10👍9🥰1👾1
На днях команда Openpilot 0.11 анонсировала запуск первого робо-агента для автономного транспорта, обученного только на симуляциях.
О потенциальных плюсах, минусах и вопросах к подходу в канале об ML в автономном транспорте рассказывает наш коллега Кирилл Федянин.
О потенциальных плюсах, минусах и вопросах к подходу в канале об ML в автономном транспорте рассказывает наш коллега Кирилл Федянин.
🔥3❤2👍1
Forwarded from 404 Driver Not Found
This media is not supported in your browser
VIEW IN TELEGRAM
Openpilot 0.11 — первый робо-агент, обученный только на симуляциях
Команда Comma.ai опубликовала интересный пост, где утверждает, что впервые в истории индустрии выпустила на дороги робо-агент, полностью обученный в вымышленной нейросетями симуляции.
Немного контекста: в Comma.ai разрабатывают систему помощи водителю, совместимую со многими моделями автомобилей. Система работает на втором уровне автономности — умный лейн-кипинг в широком спектре сценариев. Эта задача гораздо проще, чем полностью автономное вождение, что позволяет Comma.ai экспериментировать.
В то время как Waymo и британская команда Wayve интегрируют модели мира в свои пайплайны, Comma.ai идёт ещё дальше и отказывается от всего, кроме модели мира. Похожую идею предлагали учёные из Беркли в классической для робототехники статье DayDreamer — интересно, что этот подход удалось адаптировать для автономного вождения.
Вот что предлагают создатели Openpilot 0.11:
Шаг 1. Собрать 40 тысяч часов интересных видео, записанных флотом автономного транспорта и разбить их на сцены по 10 секунд с частотой 5 Гц.
Шаг 2. Обучить на этом датасете двухголовую модель мира:
🔴 первая голова предсказывает по видеоконтексту следующее действие эго-агента,
🔴 вторая — генерирует следующий кадр по видеоконтексту и только что полученному следующему действию.
Потом к контексту добавляется сгенерированный кадр, и процесс повторяется.
Секретный ингредиент — подавать на вход модели не только две секунды истории, но и последнюю секунду в эпизоде. Так ей понадобится предсказывать только промежуточную траекторию — это значительно улучшает сходимость. В итоге получается достаточно реалистичный симулятор вождения, который генерирует следующий кадр по двум секундам видео и действию эго.
Шаг 3. Обучить в полученном симуляторе небольшую модель-водителя, которая должна сходиться в финальное состояние по одному лишь видео, не видя последний кадр. Щедро насыпать шум на всех стадиях для устойчивости.
Openpilot 0.11 обучали on-policy — модель много едет по сгенерированной ей самой траектории, что выгодно отличает подход от обычного imitation learning.
При этом награды или штрафы не задавались явно — по опыту reinforcement learning, конструирование наград иногда всё только портит. Авторы усвоили горький урок: для того чтобы всё сошлось, достаточно увеличить количество данных и размер модели.
Единственная проблема, которая остаётся, — модель-водитель может научиться ломать симуляцию непредсказуемыми способами. Авторы утверждают, что это решается за счёт гипотезы большого мира: одновременно увеличивать и модель мира, и размеры водителя так, чтобы мир всегда был на порядок больше.
В парадигме Level 2 получается хороший результат — агент держит линию и расстояние до других, объезжает запаркованные авто. Но вопрос, будет ли это скейлиться на более сложные задачи, остаётся открытым.
Разбор подготовил❣️ Кирилл Федянин
404 driver not found
Команда Comma.ai опубликовала интересный пост, где утверждает, что впервые в истории индустрии выпустила на дороги робо-агент, полностью обученный в вымышленной нейросетями симуляции.
Немного контекста: в Comma.ai разрабатывают систему помощи водителю, совместимую со многими моделями автомобилей. Система работает на втором уровне автономности — умный лейн-кипинг в широком спектре сценариев. Эта задача гораздо проще, чем полностью автономное вождение, что позволяет Comma.ai экспериментировать.
В то время как Waymo и британская команда Wayve интегрируют модели мира в свои пайплайны, Comma.ai идёт ещё дальше и отказывается от всего, кроме модели мира. Похожую идею предлагали учёные из Беркли в классической для робототехники статье DayDreamer — интересно, что этот подход удалось адаптировать для автономного вождения.
Вот что предлагают создатели Openpilot 0.11:
Шаг 1. Собрать 40 тысяч часов интересных видео, записанных флотом автономного транспорта и разбить их на сцены по 10 секунд с частотой 5 Гц.
Шаг 2. Обучить на этом датасете двухголовую модель мира:
Потом к контексту добавляется сгенерированный кадр, и процесс повторяется.
Секретный ингредиент — подавать на вход модели не только две секунды истории, но и последнюю секунду в эпизоде. Так ей понадобится предсказывать только промежуточную траекторию — это значительно улучшает сходимость. В итоге получается достаточно реалистичный симулятор вождения, который генерирует следующий кадр по двум секундам видео и действию эго.
Шаг 3. Обучить в полученном симуляторе небольшую модель-водителя, которая должна сходиться в финальное состояние по одному лишь видео, не видя последний кадр. Щедро насыпать шум на всех стадиях для устойчивости.
Openpilot 0.11 обучали on-policy — модель много едет по сгенерированной ей самой траектории, что выгодно отличает подход от обычного imitation learning.
При этом награды или штрафы не задавались явно — по опыту reinforcement learning, конструирование наград иногда всё только портит. Авторы усвоили горький урок: для того чтобы всё сошлось, достаточно увеличить количество данных и размер модели.
Единственная проблема, которая остаётся, — модель-водитель может научиться ломать симуляцию непредсказуемыми способами. Авторы утверждают, что это решается за счёт гипотезы большого мира: одновременно увеличивать и модель мира, и размеры водителя так, чтобы мир всегда был на порядок больше.
В парадигме Level 2 получается хороший результат — агент держит линию и расстояние до других, объезжает запаркованные авто. Но вопрос, будет ли это скейлиться на более сложные задачи, остаётся открытым.
Разбор подготовил
404 driver not found
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9❤6❤🔥3👍1🫡1
Is Evaluation Awareness Just Format Sensitivity? Limitations of Probe-Based Evidence Under Controlled Prompt Structure
Мы уже писали тут и тут о работах Yandex Research, принятых на ICLR 2026. Но это ещё не всё. На воркшоп ICBINB в рамках ICLR 2026 также приняли статью Вилианы Девбуновой, разработчика из службы технологий голосового ввода. Вилиана рассказала, как нашим исследователям удалось поставить под сомнение и критически переосмыслить устоявшееся представление о evaluation awareness в больших языковых моделях.
До ICLR осталось совсем немного времени. Ну а мы, как всегда, будем в по горячим следам рассказывать о самых интересных работах и событиях конференции.
#YaICLR26
ML Underhood
Мы уже писали тут и тут о работах Yandex Research, принятых на ICLR 2026. Но это ещё не всё. На воркшоп ICBINB в рамках ICLR 2026 также приняли статью Вилианы Девбуновой, разработчика из службы технологий голосового ввода. Вилиана рассказала, как нашим исследователям удалось поставить под сомнение и критически переосмыслить устоявшееся представление о evaluation awareness в больших языковых моделях.
В некоторых работах, вышедших в последнее время, авторы заявляли о наличии evaluation awareness в LLM — будто бы большие языковые модели понимают, что их оценивают.
Есть момент, что эти выводы в основном строятся на экспериментах с пробниками (linear probes), когда берут внутренние представления модели и учат простой классификатор различать evaluation- и deployment-запросы. И он действительно хорошо справляется. Из этого делают вывод, что внутри модели есть сигнал «меня сейчас тестируют».
Но проблема в том, что сами данные устроены не очень честно. Тестовые запросы почти всегда выглядят одинаково: чёткая структура, multiple-choice, формализованные задачи. А обычные пользовательские запросы, наоборот, пишутся разговорным языком и в свободной форме.
Исходя из этого, мы в своей работе выдвигаем гипотезу, что на самом деле модель не понимает, что её оценивают — она просто узнаёт знакомый шаблон. Чтобы проверить это, мы аккуратно разделяем три вещи:
- контекст (это тест или обычное использование),
- формат (формат бенчмарка или свободный текст),
- стиль или жанр (строгий или разговорный).
Чтобы проверить, на что именно реагирует пробник, мы собрали контролируемые датасеты 2х2 сеткой, в которых формат и контекст варьируются независимо друг от друга. Берём настоящие бенчмарки и обычные пользовательские запросы — это ось контекста. А по оси формата переписываем их: пользовательские запросы оформляем как тест с вариантами ответов, а бенчмарки, наоборот, находим в свободной разговорной форме. Получаются четыре комбинации: бенчмарк в родном формате, бенчмарк в свободной форме, пользовательский запрос в формате теста и пользовательский запрос как есть. Это позволяет понять, что ловит пробник — реальный контекст оценки или просто внешнюю структуру промпта.
Если обучить стандартный «пробник», как было в предыдущих работах, он начинает массово ошибаться. Например, обычные пользовательские запросы, оформленные как тест, почти всегда считаются как evaluation. То есть он реагирует не на смысл, а на форму.
При этом, если поменять только стиль, сделав его более академическим, ничего не меняется. Отсюда напрашивается вывод, что дело именно в жёсткой структуре вроде multiple-choice или полей Question: Answer:.
Мы также обнаружили интересный момент. Если специально обучить пробник на данных, где формат и контекст больше не скоррелированы, он начинает нормально различать именно контекст. Это может значить, что внутри модели действительно есть информация про evaluation и deployment, но стандартные методы не умеют её правильно извлекать и выбирают формат как более простой сигнал.
Итого главный вывод работы в том, что evaluation awareness, может быть в значительной степени просто чувствительностью к формату. При этом мы не опровергаем само существование evaluation awareness, но говорим, что существующие доказательства пока неубедительны.
До ICLR осталось совсем немного времени. Ну а мы, как всегда, будем в по горячим следам рассказывать о самых интересных работах и событиях конференции.
#YaICLR26
ML Underhood
❤16❤🔥6🔥6👍2😁2😍2
Как ML помогает бороться с борщевиком
ML-разработчики Школы анализа данных вместе с экспертами Центра технологий для общества Яндекса и движением «СтопБорщевик» запустили ИИ‑инструмент для борьбы с борщевиком. Подробно о технологии читайте на Хабре, а здесь мы кратко расскажем о главном.
Борщевик Сосновского — растение крайне живучее и плодовитое, способное быстро занимать большие территории. Очаги распространения борщевика фиксируют с воздуха — их хорошо видно во время цветения, — а затем картографируют. Это помогает находить новые области заражения и следить за ликвидацией.
Однако обводить борщевик на снимках вручную — процесс дорогой и долгий. А вот модель справится с этим в 50 раз быстрее.
Для обучения использовали 55 спутниковых снимков, что дало датасет в 10 тысяч изображений. Разметка проходила в два этапа: на первом выделяли по контуру области с борщевиком, а на втором — считали вегетативный индекс и подбирали для него порог: если значение было выше, область закрашивалась, если ниже — нет.
Данных было немного, поэтому вместо тяжёлых сегментационных сетей вроде U-Net использовали табличный ML: извлекли признаки из изображений и обучили градиентный бустинг. В итоге модель решает простую задачу — есть на участке борщевик или нет.
Итоговый подход получает на вход GeoTIFF-файл — растровое изображение с геоданными — и нормализует его, чтобы избавиться от бликов, глубоких теней и артефактов. Потом изображение разбивается на тайлы 256 × 256 пикселей и из каждого тайла извлекаются признаки, по которым модель определяет, есть ли перед ней борщевик. А далее идёт векторизация, итогом которой становится вычисление площади полигона, захваченного растением. Всё это передаётся на вход работы CatBoost-а.
С помощью модели уже удалось выявить очаги заражения площадью 421 гектар в 17 регионах европейской части России. Москву и область проанализировали полностью, а к лету планируют задействовать сервис для мониторинга 100 тысяч квадратных километров в Тверской и Ярославской областях.
Напоминаем, что узнать все тонкости работы технологии вы можете на Хабре. А если тоже хотите работать над подобными полезными проектами, то можно подать заявку в Школу анализа данных Яндекса. Набор на обучение открыт до 3 мая.
ML Underhood
ML-разработчики Школы анализа данных вместе с экспертами Центра технологий для общества Яндекса и движением «СтопБорщевик» запустили ИИ‑инструмент для борьбы с борщевиком. Подробно о технологии читайте на Хабре, а здесь мы кратко расскажем о главном.
Борщевик Сосновского — растение крайне живучее и плодовитое, способное быстро занимать большие территории. Очаги распространения борщевика фиксируют с воздуха — их хорошо видно во время цветения, — а затем картографируют. Это помогает находить новые области заражения и следить за ликвидацией.
Однако обводить борщевик на снимках вручную — процесс дорогой и долгий. А вот модель справится с этим в 50 раз быстрее.
Для обучения использовали 55 спутниковых снимков, что дало датасет в 10 тысяч изображений. Разметка проходила в два этапа: на первом выделяли по контуру области с борщевиком, а на втором — считали вегетативный индекс и подбирали для него порог: если значение было выше, область закрашивалась, если ниже — нет.
Данных было немного, поэтому вместо тяжёлых сегментационных сетей вроде U-Net использовали табличный ML: извлекли признаки из изображений и обучили градиентный бустинг. В итоге модель решает простую задачу — есть на участке борщевик или нет.
Итоговый подход получает на вход GeoTIFF-файл — растровое изображение с геоданными — и нормализует его, чтобы избавиться от бликов, глубоких теней и артефактов. Потом изображение разбивается на тайлы 256 × 256 пикселей и из каждого тайла извлекаются признаки, по которым модель определяет, есть ли перед ней борщевик. А далее идёт векторизация, итогом которой становится вычисление площади полигона, захваченного растением. Всё это передаётся на вход работы CatBoost-а.
С помощью модели уже удалось выявить очаги заражения площадью 421 гектар в 17 регионах европейской части России. Москву и область проанализировали полностью, а к лету планируют задействовать сервис для мониторинга 100 тысяч квадратных километров в Тверской и Ярославской областях.
Напоминаем, что узнать все тонкости работы технологии вы можете на Хабре. А если тоже хотите работать над подобными полезными проектами, то можно подать заявку в Школу анализа данных Яндекса. Набор на обучение открыт до 3 мая.
ML Underhood
🔥33❤17👍7😁6🕊1🖕1
На прошлой неделе мы запустили агент «Исследовать» в Алисе AI, а сегодня делимся техническими деталями
Это DeepResearch-агент, который может проанализировать большой объём данных и выдать полноценный разбор темы. За три месяца тестирования «Исследовать» использовали более 280 тысяч раз. Техлид агента Прохор Гладких рассказал о нём подробнее.
А работа началась год назад — в апреле 2025-го. Первая версия представляла собой классический пайплайн: поиск и генерация. Однако запросы в поиск генерировали с помощью тяжёлой модели и сразу несколько, а ответы получали с помощью ризонера. Так в Алисе появился режим «рассуждать + поиск».
Первый прототип непосредственно агента «Исследовать» был аналогом CodeAgent, собранным из smolagents. Такой подход позволил добиться неплохих результатов на SimpleQA и Frames.
Вторая итерация агента уже была полностью реализована на классическом function calling.
Удалось побить метрики CodeAgent и полностью отказаться от написания кода для вызова тулов. Всего в «Исследовать» 13 подагентов и 9 тулов, среди которых, например, CodeSandbox для запуска сгенерированного агентом кода.
Попробовать агент «Исследовать» можно на сайте alice.yandex.ru, в приложениях Алиса AI, Яндекс с Алисой AI и в Яндекс Браузере.
ML Underhood
Это DeepResearch-агент, который может проанализировать большой объём данных и выдать полноценный разбор темы. За три месяца тестирования «Исследовать» использовали более 280 тысяч раз. Техлид агента Прохор Гладких рассказал о нём подробнее.
А работа началась год назад — в апреле 2025-го. Первая версия представляла собой классический пайплайн: поиск и генерация. Однако запросы в поиск генерировали с помощью тяжёлой модели и сразу несколько, а ответы получали с помощью ризонера. Так в Алисе появился режим «рассуждать + поиск».
Первый прототип непосредственно агента «Исследовать» был аналогом CodeAgent, собранным из smolagents. Такой подход позволил добиться неплохих результатов на SimpleQA и Frames.
Вторая итерация агента уже была полностью реализована на классическом function calling.
DeepResearch — и у нас, и у конкурентов — сильно нагружающий GPU продукт. Здесь очень важна оптимизация потребления ресурсов видеокарт, так как на один запрос пользователя агент делает сотни вызовов моделей. Крайне важно попадать в KV-cache, и чтобы его объёма хватало на все параллельные исследования в поде.
Чтобы этого достичь, мы сделали систему, которая отправляет все запросы в рамках одного исследования на один под, а также провели около 30 экспериментов по подбору параметров LLM-движка. В итоге достигли оптимизации в десятки раз, что позволило раскатить агента на всех пользователей.
Удалось побить метрики CodeAgent и полностью отказаться от написания кода для вызова тулов. Всего в «Исследовать» 13 подагентов и 9 тулов, среди которых, например, CodeSandbox для запуска сгенерированного агентом кода.
Я был сильно удивлён, что агент отлично справляется не только с научными запросами, но и с подбором товаров в маркетплейсах по моим сложным критериям. Особенно порадовало, что он вычитывает отзывы пользователей и анализирует их за меня. Почти все покупки я сейчас делаю с помощью агента «Исследовать» для выбора и агента «Найти дешевле» для поиска лучшего предложения. Это снимает с меня когнитивную нагрузку по выбору бренда, отсмотру отзывов и так далее.
Попробовать агент «Исследовать» можно на сайте alice.yandex.ru, в приложениях Алиса AI, Яндекс с Алисой AI и в Яндекс Браузере.
ML Underhood
👍17❤9🔥5
Долгое бодрствование агентов — как мы построили платформу Agent Transport System для Алисы AI
Агент «Исследовать», о котором мы писали ранее, должен быть устойчивым к непредвиденным ситуациям. Собственно, исследование — процесс комплексный, требующий проанализировать несколько источников, вызвать разные инструменты и запустить модели. Если где-то что-то упадёт, то всё придется начинать сначала. Чтобы этого не происходило, в Яндексе использовали платформу Agent Transport System (ATS). О ней на Хабре рассказал Алексей Логинов, ведущий разработчик в команде, которая отвечает за инфраструктуру Алисы AI. Кратко выделим главное.
Сперва агентский режим ассистента реализовали на OpenAI Agents SDK. Это работало, но стейты выполнения хранились локально, а при любых сбоях приходилось начинать всё заново. Нужно было найти такое решение, которое позволяло бы продолжать работу именно из состояния до падения. Кроме того, хорошо бы иметь под капотом распределённое выполнение, чтобы агенты и тулы взаимодействовали друг с другом, находясь на разных хостах.
Для построения отказоустойчивых систем хорошо подходит фреймворк Temporal. Он оперирует двумя типами сущностей: workflow (объект с состоянием, который описывает последовательность шагов) и activity (функции, которые вызываются из workflow). Фреймворк фиксирурет решения, принятые workflow, и результаты завершённых activity. В случае падения Temporal восстанавливает выполнение, не вызывая уже сделанные activity.
Однако Temporal не умеет в стриминг, а агенту было бы хорошо выдавать ответы пользователю по мере их получения. К тому же агенты, написанные на Temporal, привязываются к Temporal SDK, что может быть не слишком удобно в случае «переезда» в будущем.
Поэтому Temporal взяли как основу для надёжности, а уже на фреймворке построили центральный сервер платформы — ATS, чьи протоколы и реализуют агенты. ATS также берёт на себя, например, оркестрацию и транспортировку данных и событий между агентами, тулами и моделями на разных хостах. В итоге схема работы выглядит так:
1. Клиент отправляет запрос в ATS.
2. ATS делает запрос в Temporal на запуск workflow. Temporal запускает workflow.
3. Workflow делает запрос в Temporal на запуск activity корневого агента. Temporal запускает activity корневого агента.
4. Activity корневого агента поднимает двунаправленный gRPC-стрим к сервису агента.
5. Если агенту нужно вызвать модель / инструмент / дочернего агента — он просит ATS, ATS сообщает workflow о необходимости запустить activity (signal/update).
6. Workflow запускает соответствующую activity.
7. Activity поднимает двунаправленный gRPC-стрим к сервису.
8. Все activity одного workflow общаются между собой через in-memory-очереди от дочернего activity к родительскому — так чанки данных передаются в реальном времени.
9. Корневой агент пишет свои чанки во внешний стриминговый сервис — пользователь видит ответ по мере выполнения.
10. Завершённые activity возвращают результаты workflow — Temporal сохраняет их.
В случае сбоя ATS начинает взаимодействовать с агентом заново. Когда агент просит вызвать инструмент, модель или дочернего агента, ATS проверяет, есть ли в хранилище какой-то результат работы по этому запросу с прошлого раза. Если да, то агент получает результат и шаг за шагом «перематывается вперёд» до состояния, в котором он был до сбоя, без повторных вызовов тяжёлых LLM и инструментов.
А подробнее о том, как всё устроено, читайте на Хабре.
ML Underhood
Агент «Исследовать», о котором мы писали ранее, должен быть устойчивым к непредвиденным ситуациям. Собственно, исследование — процесс комплексный, требующий проанализировать несколько источников, вызвать разные инструменты и запустить модели. Если где-то что-то упадёт, то всё придется начинать сначала. Чтобы этого не происходило, в Яндексе использовали платформу Agent Transport System (ATS). О ней на Хабре рассказал Алексей Логинов, ведущий разработчик в команде, которая отвечает за инфраструктуру Алисы AI. Кратко выделим главное.
Сперва агентский режим ассистента реализовали на OpenAI Agents SDK. Это работало, но стейты выполнения хранились локально, а при любых сбоях приходилось начинать всё заново. Нужно было найти такое решение, которое позволяло бы продолжать работу именно из состояния до падения. Кроме того, хорошо бы иметь под капотом распределённое выполнение, чтобы агенты и тулы взаимодействовали друг с другом, находясь на разных хостах.
Для построения отказоустойчивых систем хорошо подходит фреймворк Temporal. Он оперирует двумя типами сущностей: workflow (объект с состоянием, который описывает последовательность шагов) и activity (функции, которые вызываются из workflow). Фреймворк фиксирурет решения, принятые workflow, и результаты завершённых activity. В случае падения Temporal восстанавливает выполнение, не вызывая уже сделанные activity.
Однако Temporal не умеет в стриминг, а агенту было бы хорошо выдавать ответы пользователю по мере их получения. К тому же агенты, написанные на Temporal, привязываются к Temporal SDK, что может быть не слишком удобно в случае «переезда» в будущем.
Поэтому Temporal взяли как основу для надёжности, а уже на фреймворке построили центральный сервер платформы — ATS, чьи протоколы и реализуют агенты. ATS также берёт на себя, например, оркестрацию и транспортировку данных и событий между агентами, тулами и моделями на разных хостах. В итоге схема работы выглядит так:
1. Клиент отправляет запрос в ATS.
2. ATS делает запрос в Temporal на запуск workflow. Temporal запускает workflow.
3. Workflow делает запрос в Temporal на запуск activity корневого агента. Temporal запускает activity корневого агента.
4. Activity корневого агента поднимает двунаправленный gRPC-стрим к сервису агента.
5. Если агенту нужно вызвать модель / инструмент / дочернего агента — он просит ATS, ATS сообщает workflow о необходимости запустить activity (signal/update).
6. Workflow запускает соответствующую activity.
7. Activity поднимает двунаправленный gRPC-стрим к сервису.
8. Все activity одного workflow общаются между собой через in-memory-очереди от дочернего activity к родительскому — так чанки данных передаются в реальном времени.
9. Корневой агент пишет свои чанки во внешний стриминговый сервис — пользователь видит ответ по мере выполнения.
10. Завершённые activity возвращают результаты workflow — Temporal сохраняет их.
В случае сбоя ATS начинает взаимодействовать с агентом заново. Когда агент просит вызвать инструмент, модель или дочернего агента, ATS проверяет, есть ли в хранилище какой-то результат работы по этому запросу с прошлого раза. Если да, то агент получает результат и шаг за шагом «перематывается вперёд» до состояния, в котором он был до сбоя, без повторных вызовов тяжёлых LLM и инструментов.
А подробнее о том, как всё устроено, читайте на Хабре.
ML Underhood
❤11🔥10👏5👍3❤🔥2🤝2🤮1
Хотите лучше разбираться, как развивается машинное обучение сегодня? Собрали каналы от инженеров Яндекса — с фокусом на практику, исследования и реальные задачи.
👩💻 ML Underhood — чем живёт ML в Яндексе.
🧠 Душный NLP — детальные NLP-разборы.
🔍 CV Time — всё вокруг компьютерного зрения.
🔮 Рекомендательная — обзоры новых рекомендательных технологий.
🎙 Speech Info — голосовые технологии: ASR, TTS и аудио.
🚗 404 Driver Not Found — ML в автономном транспорте.
Подписывайтесь на каналы, которые вам ближе, чтобы понимать не только «что происходит», но и «как это работает».
Подписывайтесь на каналы, которые вам ближе, чтобы понимать не только «что происходит», но и «как это работает».
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥13❤8⚡6
Muon — мощный оптимизатор для обучения табличных DL-моделей
К такому выводу пришла tabular DL-команда Yandex Research, сравнив 15 оптимизаторов на 17 табличных датасетах для обучения современных моделей на основе архитектуры MLP. Сперва все оптимизаторы сравнивались для стандартных MLP, а затем лучшие варианты протестировали и на более продвинутых моделях вроде TabM.
В качестве референсного бейзлайна выступал широко распространённый оптимизатор AdamW. Сравнивали и вариации последнего: NAdamW, Cautious AdamW, AdEMAMix и другие. Кроме того, тестированию подверглись SOAP и Muon.
Самые высокие результаты показали Muon и AdamW с экспоненциальным скользящим средним (EMA) — эти методы обошли базовый AdamW более чем в половине датасетов. Добавление EMA к Muon может бустить качество на некоторых задачах, но в целом ванильный Muon более надежный.
Что в итоге? Muon показывает отличные результаты и рекомендуется к использованию как для базовых, так и для продвинутых моделей, а AdamW с EMA может быть неплохой альтернативой для более простых архитектур. Использование обоих оптимизаторов несколько замедляет обучение по сравнению с обычным AdamW, но всё зависит от модели. Вероятно, замедление будет допустимым во многих реальных приложениях.
ML Underhood
К такому выводу пришла tabular DL-команда Yandex Research, сравнив 15 оптимизаторов на 17 табличных датасетах для обучения современных моделей на основе архитектуры MLP. Сперва все оптимизаторы сравнивались для стандартных MLP, а затем лучшие варианты протестировали и на более продвинутых моделях вроде TabM.
В качестве референсного бейзлайна выступал широко распространённый оптимизатор AdamW. Сравнивали и вариации последнего: NAdamW, Cautious AdamW, AdEMAMix и другие. Кроме того, тестированию подверглись SOAP и Muon.
Самые высокие результаты показали Muon и AdamW с экспоненциальным скользящим средним (EMA) — эти методы обошли базовый AdamW более чем в половине датасетов. Добавление EMA к Muon может бустить качество на некоторых задачах, но в целом ванильный Muon более надежный.
Что в итоге? Muon показывает отличные результаты и рекомендуется к использованию как для базовых, так и для продвинутых моделей, а AdamW с EMA может быть неплохой альтернативой для более простых архитектур. Использование обоих оптимизаторов несколько замедляет обучение по сравнению с обычным AdamW, но всё зависит от модели. Вероятно, замедление будет допустимым во многих реальных приложениях.
ML Underhood
❤🔥20🔥11❤9👍2
ICLR 2026 стартует уже завтра 🇧🇷
Olá, amigos! Кто-то из наших инженеров уже любуется красотами Бразилии и считает диких обезьян, а кто-то ещё в многочасовом перелёте с кучей пересадок. Но всё это того стоит — впереди ICLR 2026.
Совсем скоро начнём вещать из Рио во всех наших каналах, а пока несём первые фото и впечатления.
Иван Ершов, руководитель команды LLM-агентов Алисы:
Данил Кашин, руководитель команды претрейна VLM:
Вилиана Девбунова, разработчик службы технологий голосового ввода:
#YaICLR26
ML Underhood
Olá, amigos! Кто-то из наших инженеров уже любуется красотами Бразилии и считает диких обезьян, а кто-то ещё в многочасовом перелёте с кучей пересадок. Но всё это того стоит — впереди ICLR 2026.
Совсем скоро начнём вещать из Рио во всех наших каналах, а пока несём первые фото и впечатления.
Иван Ершов, руководитель команды LLM-агентов Алисы:
Рио — яркий, красочный, зелёный, громкий. Я впервые перелетел Атлантику, соответственно впервые в Латинской Америке. Природа, постройки, люди сильно отличаются от того, что я привык видеть в Европе.
Поражает количество зелени, разнообразие деревьев, птиц, животных. На первой же прогулке с коллегами было ощущение, что улица — «бесплатный зоопарк»: обезьяны, маракуйя, папайя. При всём обилии зелени город выглядит аккуратным и убранным.
Люди в основном говорят на португальском — даже в аэропорту пришлось объясняться жестами. Мне пока больше помогает знание итальянского, чем английского.
Данил Кашин, руководитель команды претрейна VLM:
Пережив 14-часовой перелёт, добрались до Рио. Погода замечательная, красивые виды. Сейчас боремся с джетлагом и изучаем расписание оралов и постеров, чтобы собрать всё самое интересное и поделиться этим в каналах!
Вилиана Девбунова, разработчик службы технологий голосового ввода:
Очень заметен контраст: едешь по городу и в какой-то момент оказываешься рядом с горами, плотно усыпанными простыми домами — так называемыми фавелами. По застройке Копакабана похожа на Анталью.
Фан-факт: я уже проехала по Рио больше 60 км и не увидела ни одного спортивного мотоцикла — в основном все ездят на нейкедах с узкими кастомными рулями.
#YaICLR26
ML Underhood
❤22❤🔥13🔥12👍2
Инженеры и исследователи Яндекса — уже на открытии ICLR 2026 в Рио
В Бразилии стартовала она — 14-я конференция International Conference on Learning Representations. В этом году на ICLR приняли больше 5 тысяч статей (из почти 19 тысяч заявленных), что в полтора-два раза больше, чем в предыдущие годы.
В первый день конференции удача была на нашей стороне: ребятам удалось попасть в окно между очередями на получение бейджей — и на всё ушло не больше пяти минут. Так что они уже успели посетить первые постеры и послушать доклады.
Напоминаем, что представим и свои исследования: привезли шесть статей от Yandex Research на основную программу и ещё одну — на воркшоп ICBINB. Ждём фоторепортажей с постеров!
#YaICLR26
ML Underhood
В Бразилии стартовала она — 14-я конференция International Conference on Learning Representations. В этом году на ICLR приняли больше 5 тысяч статей (из почти 19 тысяч заявленных), что в полтора-два раза больше, чем в предыдущие годы.
В первый день конференции удача была на нашей стороне: ребятам удалось попасть в окно между очередями на получение бейджей — и на всё ушло не больше пяти минут. Так что они уже успели посетить первые постеры и послушать доклады.
Напоминаем, что представим и свои исследования: привезли шесть статей от Yandex Research на основную программу и ещё одну — на воркшоп ICBINB. Ждём фоторепортажей с постеров!
#YaICLR26
ML Underhood
❤22❤🔥7🔥5👏2👍1🤩1