Привет, Хабр! На связи команда генеративных моделей в компьютерном зрении. Вместе с другими командами мы делаем мультимодального ассистента Алиса AI. Внутри него мы развиваем несколько вариантов визуальной генерации с помощью отдельной модели Alice AI ART. Два базовых сценария её работы — генерация по тексту (Text‑to‑Image, T2I) и редактирование по картинке с инструкцией (Image‑to‑Image, I2I). Именно о них пойдёт речь. 

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

В этом году мы поставили себе цель, которая звучала просто, а на практике оказалась полугодовым приключением: не только подтянуть качество, а сделать одну модель, которая одинаково хорошо умеет и в T2I, и в I2I. Внутри мы называем такой режим unified или просто uni. Вас ждёт рассказ об отдельных экспериментах и наблюдениях, которые помогли нам сделать первый шаг в этом направлении и привели нас к Alice AI ART 2.0, — включая те, которые красиво не сработали (спойлер: их хватало).

Flutter активно движется в сторону Swift Package Manager (SPM) и, как и весь Swift‑мир, постепенно отказывается от CocoaPods. Сам Flutter описывает миграцию в два шага: включить флаг flutter config --enable-swift-package-manager и запустить сборку. Если после этого приложение собирается и в консоли появляется предложение deintegrate CocoaPods — вы счастливчик. Если нет, добро пожаловать под кат. 

Привет! Меня зовут Даниил Гиренко, я Flutter‑разработчик в Яндекс Про. Проект по переводу нашего супераппа с CocoaPods на Swift Package Manager оказался одним из самых сложных и долгих в моей карьере программиста. Весь мой пережитый ужас опыт я решил выразить в этой статье, чтобы решившиеся на миграцию разработчики (или агенты) понимали, какие подводные камни их ждут. Буду рад, если ваш проект займёт недели, а не месяцы, как у меня.

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

Привет, Хабр! Меня зовут Никита, и я один из тех, кто каждый год делает Frontend CTF в рамках конференции «Я 💛 Фронтенд». Сегодня хочу с вами поделиться, как и зачем мы ежегодно делаем соревнование для тех, кто любит пробираться сквозь загадки, секреты и спрятанные подсказки в браузерной игре.

Вы запустили LLM-инференс в продакшене. Поток запросов не менялся, нагрузка та же, что вчера, — а Time to First Token внезапно вырос в три раза. Первая мысль: что-то с моделью. На деле причина почти никогда не в модели — она прячется в планировщике, аллокаторе GPU-памяти, очереди стримингового вывода или сети.

Чем длиннее контекст, тем больнее. Для классического attention вычислительная сложность растёт очень быстро. KV-кеш раздувается до десятков и сотен гигабайт, а в облаке всё это происходит на совершенно произвольном трафике: у одного клиента кодовый ассистент, у другого — аналитика на миллион запросов в день, у третьего — голосовой робот. На таких смешанных нагрузках всплывает то, чего не видно на референсных замерах вендора.

Хорошая рекомендательная система быстро учится угадывать, что вы положите в корзину. И чем точнее она угадывает, тем реже показывает что‑то незнакомое: ведь выгоднее предлагать проверенное. Со временем система замыкается на привычках человека и перестаёт показывать ему хоть что‑то за их пределами.

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

Меня зовут Рамиль Боярченков, я занимаюсь машинным обучением в команде Яндекс Лавки. Расскажу, как мы собрали механизм, который подмешивает незнакомые товары персонально — тем, кто к ним расположен, — и с какой вероятностью это делать для каждого пользователя. По пути разберу, как мы калибровали «агрессивность» exploration и что получилось в итоге.

Граф из миллионов вершин не загружает современную GPU на все 100%: видеокарта почти всё время не вычисляет, а ждёт загрузки данных из памяти. Графовые нейросети, или GNN, упираются в это давно: сами операции достаточно простые, но доступ к памяти нерегулярный и разреженный. И чем мощнее GPU, тем заметнее недостаточная её утилизация.

Идея выросла из проектного курса в ШАДе. Толчком стало то, что один из самых популярных фреймворков для работы с графами, Deep Graph Library, на момент начала работы не обновлялся уже около года — это знак того, что в области что‑то застряло.

Меня зовут Федя Великонивцев, я старший исследователь Yandex Research, руковожу группой, которая занимается эффективными вычислениями на GPU. На том курсе мы с коллегами — Дарьей Фоминой из команды ML‑инфраструктуры Яндекса, Вячеславом Ждановским из команды разработки инференса — и студентами Даниилом Красильниковым, Алексеем Бойковым и Андреем Долговязовым взялись выяснить, почему графовые нейросети тормозят на современных GPU.

Так появился проект, который мы оформили в отдельную статью — On Efficient Scaling of GNNs via IO‑Aware Layer Implementations. Её приняли на ICML-2026 со статусом Spotlight. Для контекста: из 23 918 поданных работ приняли 6 352 (26,6%), а Spotlight достался только 536 работам — это 2,2% заявок с самыми высокими оценками программного комитета.

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

Представьте, что вам нужна фотореалистичная 3D‑копия реального объекта или сцены: например, лица актёра для крупного плана или целой городской улицы. Сегодня для этого есть два инструмента: классическое 3D‑моделирование и фотограмметрия. Однако они съедают недели работы и ломаются там, где очень важны детали, — волосы, хром, стекло, отражения превращаются в артефакты. А на то, чтобы снять реалистичную сцену или объект так, чтобы это масштабировалось на тысячи единиц, обычно уходит слишком много времени и денег.

Выход из этого тупика для целого ряда задач мы нашли в Gaussian Splatting и прогнали технологию через несколько очень разных проектов: сканирование людей и локаций для кино (например, для «Кибердеревни»), создание цифровых двойников городских кварталов и симуляцию для автономного транспорта. Инструмент один — задачи разные. И именно на этом контрасте и родилось самое интересное.

Сегодня я расскажу, как риг из 15 камер заменяет установку за сотни тысяч долларов и зачем мы используем движущегося человека как калибровочную доску. Объясню, почему для беспилотного автомобиля фотореализм обязан рождаться из данных, а не из 3D‑редактора. Ну и, конечно же, расскажу про YaGS Plugin — наш опенсорс‑плагин, который делает Gaussian Splatting полноценной частью сцены в Unreal Engine.

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

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

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

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

Трансформеры уже умеют писать код, генерировать тексты и рисовать картины. Но могут ли они управлять автономным автомобилем в реальных городских условиях, среди людей и других машин?

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

Мы пройдём путь от первых ML‑экспериментов до регулярных испытаний на реальных машинах. Разберём, чем Open Loop отличается от Closed Loop, почему качество предсказаний не определяет качество вождения и почему безопасность для нас важнее любой архитектуры.

Что происходит под капотом корпоративного мессенджера, когда нагрузка пробивает отметку в 650 000 запросов в секунду? Обычно в этот момент архитектура распределённых хранилищ начинает проверять на прочность не только диски и сеть, но и нервы команды эксплуатации.

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

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

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

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

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

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

Наверняка вы слышали, что большинство биомедицинских исследований в мире проводится на лабораторных грызунах. Это неслучайно: ДНК мыши и человека совпадают на 97,5%, у нас около 30 000 общих генов. Именно мыши помогают находить лекарства от рака, исследовать болезнь Альцгеймера и, как в нашем случае, изучать механизмы стресса и агрессии.

Учёные из Института цитологии и генетики (ИЦиГ) СО РАН в новосибирском Академгородке ведут масштабное исследование. Его цель — понять связь между хроническим стрессом, иммунитетом и патологической агрессией. Но есть проблема: чтобы оценить результаты экспериментов, нужно отсмотреть сотни часов видеозаписей поведения животных.

Ручная обработка таких данных — долгий и кропотливый труд. На разметку 10 минут видео у научного сотрудника уходит около часа напряжённой работы: нужно сидеть с секундомером, ставить видео на паузу и фиксировать каждое действие мыши в таблицу.

Совместными усилиями команд Центра технологий для общества Yandex Cloud и Yandex Crowd Solutions мы решили помочь автоматизировать этот процесс. В результате нам удалось сэкономить учёным более 500 часов рутинной работы, освободив это время для настоящей науки. В статье расскажем, как объединили облачные технологии, краудсорсинг и энтузиазм, чтобы решить неочевидную, но критически важную проблему фундаментальной науки: собрали команду из студентов и экспертов, организовали разметку специфических данных, внедрили open‑source‑модель компьютерного зрения DeepLabCut и докрутили её собственными ML‑эвристиками.

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

Так выглядела наша точка отсчёта. Речь о Директории — компоненте B2B‑платформы Яндекс 360, который отвечает за жизненный цикл организаций и служит единым источником истины об их оргструктуре для других сервисов: Календаря, Почты, Мессенджера, Диска. Когда вы ставите встречу на целый отдел или отправляете общую рассылку для бухгалтерии, под капотом к Директории прилетает запрос «Дай мне всех пользователей этой группы с учётом всей вложенности». Это наш самый горячий запрос, и старая архитектура с ним перестала справляться.

Привет! Меня зовут Малик, я занимаюсь развитием B2B‑платформы в Яндекс 360. В этой статье я расскажу, зачем нам вообще понадобился граф при хранении оргструктур, почему мы решили засунуть этот граф именно в PostgreSQL и как мы это реализовали. А ещё — как нам удалось выкатить такое масштабное архитектурное изменение в продакшен без даунтаймов и что мы получили в итоге.

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

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

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

Проблема в том, что медиалента — это не один виджет и не просто плеер внутри ячейки. Это система, которая живёт на пересечении сразу нескольких тяжёлых доменов: динамически собираемый интерфейс, сетевые ограничения, декодирование медиа, менеджмент памяти, жизненный цикл вложенных контейнеров, UX‑требования к мгновенному старту, интеграция в чужие экраны и такие сложные системы, как BDUI, рекомендации, пагинации, и при этом — высокий трафик на массовом сценарии. 

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

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

Отладка корутин в Android — задача, с которой сталкивается каждый разработчик, использующий Kotlin. На один экран могут приходиться десятки вызовов launch и async, но стандартные инструменты показывают потоки, а не корутины. В итоге, когда одна из корутин зависает, разработчик оказывается в тупике: отладчик показывает живой поток, но не показывает, какая корутина на нём выполнялась, в каком suspend‑вызове она остановилась и кто её запустил. Приходится искать причину вслепую — расставлять логи и пытаться воспроизвести проблему вручную. 

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

Чтение сериализованных данных — это инфраструктурный налог, который платит каждый сервис при получении информации из внешних источников, например по сети или с диска. В индустрии для схематизированных данных стандартом де‑факто стал Protobuf, и чаще всего этот налог выражается в существенных затратах CPU на его парсинг. В продвинутых случаях парсинг пытаются заменить на значительно более дешёвую, но при этом куда менее удобную работу с zero‑copy представлением FlatBuffers.

Мы открыли исходники YaFF (Yet Another Flat Format) — формата, который убирает этот налог, не заставляя отказываться от Protobuf. На масштабе Яндекса это особенно важно, потому что менять такие базовые вещи, как формат, дорого и больно. Поэтому YaFF изначально спроектирован как альтернативный wire format для существующих экосистем Protobuf (и в перспективе FlatBuffers). Это позволяет дёшево и бесшовно встраиваться в существующие проекты, не переписывая десятки тысяч строк кода.

Как это работает на практике, мы покажем на примере Яндекс Рекламы: в рекомендательной системе, где каждый из сотен тысяч запросов обрабатывает десятки тысяч объектов, нужно особое внимание к представлению данных. Благодаря YaFF мы смогли постепенно, шаг за шагом, оптимизировать систему и без дорогих рефакторингов сэкономить 10–20% CPU в масштабах крупных рантаймов.

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

Для этого мы сравнили два способа «подружить» ИИ‑агента с внутренними API — MCP и CLI + Skill. Взяли гипотезу из внешних исследований, собрали бенчмарк на 14 сценариях и двух моделях, прогнали больше 400 запросов на реальных внутренних инструментах. И в какой‑то момент всё, что работало, сломалось — и это оказалось самым интересным. Пришлось разбираться почему.

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

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

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