Доклады конференции HighLoad++ 2026

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

Что такое Software Factory и зачем она нужна. Переход от отдельных coding agents к системе, способной автономно проходить значительную часть SDLC — от постановки задачи до реализации, проверки и обратной связи.

Из каких уровней состоит Software Factory. Разберём архитектуру agentic-разработки: модель, inner harness, outer harness и orchestration/control plane — какую задачу решает каждый уровень и где проходят их границы ответственности.

Loop Engineering вместо одного большого агента. Покажем, как разработка раскладывается на циклы разного масштаба: inner loops для выполнения конкретной инженерной работы, outer loops для проверки результата и движения задачи по SDLC и meta loops для анализа и улучшения самой фабрики.

Как Software Factory устроена в Райфе. На практическом примере покажем архитектуру нашей фабрики: AI-агентов, их роли, orchestration, работу с репозиториями и инженерными системами, code review, QA/eval и end-to-end verification.

Как фабрика понимает, что результат хороший. Разберём verification и feedback loops: автоматические проверки, тесты, code review, evals, метрики и другие сигналы, которые позволяют не просто генерировать код, а контролировать качество результата.

Как работает Self-Improvement. Покажем, как результаты выполнения задач, ошибки, ревью и evals превращаются в изменения harness, правил, инструментов и поведения агентов — и как замкнуть цикл, в котором Software Factory постепенно улучшает сама себя.

Это деловая игра про жизненный цикл создания ИИ-агента: от идеи и первого прототипа до тестов, инцидентов и сопровождения в продакшене. Участники становятся командами-разработчиками, которые участвуют в тендере заказчика. Их задача — создать ИИ-агента для распознавания изображений и набрать максимум баллов. Победит не тот, кто быстро собрал прототип, а тот, кто построил более надёжный процесс: с понятной целью, проверками, правилами оценки рисков и улучшениями после ошибок. В ходе игры команды активно используют ИИ как партнёра по разработке: для анализа вариантов, поиска слабых мест, генерации тестов, разбора ошибок и улучшений. Факты: 1. В игре 4 раунда от первого прототипа ИИ-агента до мультиагентной системы. 2. За время игры происходит разбор полезных практик жизненного цикла создания ИИ-агента при совместной работе команды, заказчика и ИИ-ассистентов (agent brief, prompting, evals, guardrails, human-in-the-loop, postmortem, regression tests и др.). 3. Лучший результат даёт команда, работающая совместно с ИИ: человек отвечает за смыслы и управление рисками, а ИИ ускоряет аналитику, тесты и улучшение системы.

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

Мы перестроили не инструмент, а процесс. Знание продукта лежит в git как живое описание доменов; требования копятся инкрементами от инициативы к эпику и истории; изменение живёт в Change и вливается в актуальный слепок через merge request с ревью. Каждая роль работает со своим слоем описания домена, а передача между ролями — это артефакт, а не встреча-пересказ.

В докладе: как агент собирает контекст под конкретную задачу и почему хватает «средней» модели; какие гард-рейлы не дают ему выдумывать; что именно уходит в разработку — модель данных, контракты, поведение; и почему главное изменение не в оргсхеме, а в том, что фокус человека смещается с генерации артефактов на их ревью. Покажу живьём репозиторий и проведу одну задачу целиком.

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

Публичные ИИ-ассистенты (вроде Claude в роли цифрового коллеги) удобны и эффективны, но для бизнеса они часто неприемлемы: конфиденциальные данные уходят вовне, отсутствует единая ролевая модель доступа, а прогнозировать и контролировать затраты на API практически невозможно. В российских реалиях добавляется критический риск: зарубежный сервис могут в любой момент ограничить, заблокировать или отключить без предупреждения.

Мы спроектировали и внедрили собственную on-premise альтернативу: OpenCode в качестве среды выполнения (runtime) и GitLab как слой хранения, версионирования и синхронизации. Агент работает полностью внутри закрытого контура компании и никак не зависит от доступности внешнего SaaS.

В докладе разберем:

Персональные и общие данные: как разграничить права доступа и настроить бесшовную синхронизацию контекста через Git. Оптимизацию ресурсов: сколько изолированных сред выполнения (sandbox) реально поднять на одном сервере и в каких сценариях действительно оправдан запуск тяжелого Chromium в Docker. FinOps и онбординг: как контролировать расходы (по пользователям, группам и моделям) и обучать сотрудников эффективной работе с агентом без «слива» бюджета на старте. Аналитику баз знаний (RAG): как отслеживать утилизацию документов и выявлять «мертвый груз». Стратегический выбор: стоит ли инвестировать в разработку собственного агента ради технологической независимости и безопасности.

Идея харнеса родилась не из теории, а из практики. Я делал проект в одиночку с ИИ-ассистентом и после каждой итерации переписывал не код, а agent.md и скиллы: каждую пойманную ошибку агента превращал в структурное ограничение, которое не даст повторить её снова. К моменту, когда проект стал командным, на руках был не только рабочий прототип, но и переиспользуемый харнес — 10 скиллов и 10 MCP-серверов.

Дальше начался второй, куда менее очевидный этап: то, что работало для одного человека, начало ломаться на команде из 5 человек и наборе из сотни параллельных агентов под нагрузкой 100 RPS. agent.md перестал быть личным дневником и стал общим ресурсом, который нужно версионировать. Правило "агент может почти всё, я слежу" перестало работать - понадобились явные границы (Red Zone/Green Zone) и права на уровне MCP-инструментов. Один агент, ждущий своей тестовой БД, превратился в очередь из десятков конкурирующих агентов - понадобился Resource Reservation Manager. В докладе - что именно из соло-практики выжило без изменений, что пришлось radикально переделать, и как мы измеряли, что харнес вообще "сходится", а не просто накапливает противоречащие друг другу правила.

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

Несколько лет назад мы уже брались за data lineage: четыре инженера, два года работы, а в прод уехала только урезанная версия. Проект увяз в графовом поиске по Postgres и в горе бизнесового и технического долга — дальше не поехал.

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

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

В Циане 300 инженеров и больше тысячи сервисов. SAST стоит давно, ручное ревью сервисов идет силами AppSec. И всё равно в сервисе аутентификации пять лет жила уязвимость с CVSS оценкой 8.6, которую мы срочно исправили. Уязвимость влияла на конфиденциальность данных, а также была доступна широкому списку лиц. Нашёл её не пентест и не сканер, а агентский воркфлоу на Claude Code, собранный за одну пятницу.

Дальше мы прогнали сканер по 73 критичным системам, разобрали результаты и сравнили выдачу с классическими Security инструментами. Подтверждённых уязвимостей — 700, 40 из которых высокой критичности, практически все невозможно найти классическими инструментами: это сценарные дефекты из нескольких ручек разных сервисов, где каждый вызов по отдельности легитимен, а также различные уязвимости бизнес логики, антипаттерны (например fail open).

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

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

В докладе мы заглянем под капот кодовых агентов и постараемся разобраться чем код похож и чем отличается от текста, как классический поиск стал завить от LLM и почему агенты вернулись к инструментами типа grep из 1973 года. Обсудим как экономика KV-cache диктует архитектуру агентов, как RL учит модели находить код и почему те начинают взламывать среду, в которой их проверяют.

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

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

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

В мастер-классе будет рассказ о том, как выглядит ALD Pro в продуктивной среде, как он эволюционировал, где находится сейчас, где и чем он отличается от Active Directory, и почему большая часть администраторов плохо понимает даже Active Directory (и из-за этого совершенно неготова с него слезать). Мы разберем, где ALD Pro похоже на FreeIPA, а где совершенно непохоже, где стоит ожидать места для удара головой, а где его придется сделать самому.

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

1. Почему стандартом единицы, формирующей инфраструктуру, должны становиться апплаенсы или так называемые ПАКи?
2. Можно ли построить ПАК на китайских GPU?
3. Сопоставимы ли метрики производительности GPU при использовании китайских GPU?
4. Можно ли достроить инфраструктуру с помощью китайских GPU, если она ранее была создана на Nvidia?
5. Нужно ли централизованное управление GPU, если мы говорим про ПАК?
6. Комплектующие ПАК могут быть не в реестре и это ни на что не повлияет.
7. Китайские GPU – хуже, так как приходится иметь дело с непроверенными и не надежными поставщиками.
8. Что экономически более оправдано – ПАК (как отдельный особенный вид on-prem), или облако?

Я системный аналитик, и моя основная задача — перевести 152-ФЗ, Приказ ФСТЭК №117 и 187-ФЗ в метрики, критерии приёмки и зоны ответственности команд. Без этого разработка встанет, а регулятор не примет систему. Расскажу на трёх живых примерах, как я это делала. Первый — локализация данных. Мы разложили «хранить ПДн в РФ» на NFR. На реализации выяснилось, что синхронная отправка во внешний сервис добавляет 300 мс латентности. Я переписала критерий: ответ пользователю не ждёт внешний сервис, достаточно подтверждения из РФ-БД. Формулировка изменилась — и система заработала. Второй — мониторинг ИИ по ФСТЭК. Мы спроектировали требования к логам для LLM. Объём логов вырос в 10 раз — исходные требования по retention пришлось пересобрать с компрессией и выгрузкой в холодное хранилище. Ещё одна правка: гардрейлы должны проверять не только вход, но и выход модели. Третий — согласия на обучение моделей. Мы сформулировали сценарии: базовое согласие, отдельное согласие на обучение, отзыв согласия. На практике удаление данных из модели невозможно. Я переформулировала требование: дообучение идёт только на данных с активным согласием, исторические данные остаются в модели. Регулятор принял этот компромисс. Главный вывод: качественные требования спасают проект. Нельзя передать закон разработчикам — нужно превратить его в проверяемые условия. И честно фиксировать технические ограничения как согласованные риски.

Расскажу опыт приземления форка LangFlow в ИТ-ландшафт банка: от чистки кодовой базы и разделения бэкенда с фронтендом до масштабирования на большие объемы запросов. Покажу, как мы проводили оптимизацию на уровне кода, внедрили MongoDB и Redis и превратили Low-Code платформу в ключевой компонент архитектуры AI-ассистента на миллионы пользователей.

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

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

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

В своём докладе я расскажу о первопричинах гонок и при чём тут линеаризуемость, как не допустить гонки на разных уровнях системы — от переменных до микросервисов — и как добавить в это уравнение саги. В общем поговорим про правильное обновление данных в master- и masterless-системах.

Чтение с реплики выглядит как простой способ масштабировать Postgres на стение: добавили ещё один хост в строку подключения и разгрузили мастер. На практике тут два неочевидных сюжета. Первый: какие аномалии изоляции приложение может увидеть на реплике и почему Postgres их допускает. Второй: как приложению надёжно находить актуальный мастер, и почему привычные способы работают хуже, чем кажется. Обе темы получили развитие в сообществе в 2026 году. Разберём на пальцах, почти без погружения в исходники, да тут ещё и не всё написано так-то.

Фоновая компактификация для удаления устаревших данных в LSM-деревьях традиционно запускается по таймеру - вслепую: на кластерах YTsaurus до 90% данных переписывались без изменений, а период приходилось подбирать вручную. Мы научили компактификацию запускаться по данным: у каждого чанка есть дайджест — сводка в несколько килобайт, по которой заранее видно, сколько места освободит перезапись. Расскажем про структуры данных внутри дайджестов, три алгоритма на их основе и грабли, собранные при раскатке. В продакшне подход срезал поток компактификации в разы, поднял её КПД на порядок и полностью убрал ручную настройку.

1. Проблема: почему стандартные инструменты не работают
   • время бэкапа для 100–500 ТБ — от суток и более;
   • критическая нагрузка на CPU/IO, риск деградации продуктива;
   • проблемы консистентности при длительных операциях.
   • срыв RTO (время восстановления);
   • потеря данных при сбоях в процессе бэкапа;
   • вынужденный downtime.
2. Ключевые требования к альтернативным решениям
   • Минимальное воздействие на рабочую систему (near zero downtime).
   • Предсказуемое время выполнения (часы вместо дней).
   • Гарантия консистентности данных.
   • Масштабируемость под огромные объёмы (сотни террабайт).
   • Автоматизация и мониторинг.
3. DB-agnostic решение: LVM снэпшоты. Принцип: мгновенное «фото» файловой системы через механизм Copy on Write. Плюсы:
   • создание снэпшота — секунды независимо от объёма;
   • нулевая блокировка записи;
   • полная файловая консистентность.
4. Решение для Cassandra/Scylla: бэкап по token ranges с параллельной обработкой данных по диапазонам токенов. Плюсы:
   • линейное масштабирование скорости (больше узлов = быстрее);
   • равномерное распределение нагрузки;
   • поддержка инкрементальных бэкапов.
5. Альтернативные подходы (кратко)
   • Репликация в отдельный кластер + бэкап с реплики:
   • Облачные снапшоты (AWS EBS, GCP Persistent Disks): Выводы и заключение: Бэкап огромных БД – сложная техническая задача, так как стандартные подходы и инструменты не работают. Без применения нестандартных подходов риск потери данных становится неприемлемым.

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

Я расскажу не про API поиска, а про инженерные решения при встраивании поиска в YDB: обновления вместе с таблицей, фильтры и права доступа, шардинг, сбои, SQL-план и ранжирование. Разберу кластеризованный векторный индекс, полнотекстовый индекс с BM25, цену N-грамм и фильтров, а также 'HybridRank'.

SLO — одновременно аналитика за месяцы/годы и инструмент ранней детекции проблем ежеминутно. Но часто пользовательские метрики прореживаются и удаляются — «честный» ответ на вопрос «как сервис работал год назад» либо невозможен, либо неподъёмно дорог при хранении полных исходных данных и расчёте в лоб. Расскажу, как мы свели время от конфигурации SLO до ответа на вопрос «стали лучше или хуже за год» с нескольких часов до десятка секунд — за счёт гибрида точности (прореженные данные на больших окнах, точные — только у границы инцидента), расчёта в одной точке вместо размазывания по кластеру и автозаведения SLO на появляющихся ресурсах, покрывая тысячи ресурсов без ручных действия пользователя.

Последние несколько лет мы в Яндекс Рекламе активно мигрировали с MapReduce технологий на real-time. Последним, что отделяло нас от полностью real-time обновления индексов, оставалось full-state обновление индексов HNSW, которые позволяют Яндекс Рекламе находить самые релевантные для пользователей объявления среди миллиарда объектов. В докладе расскажу как мы с помощью нового алгоритма обновления индекса HNSW смогли перейти на полностью real-time процессинг данных.

В Яндексе активно используют монорепозитории и trunk‑based development — это ускоряет разработку: ежедневно в trunk вливают до 10 000 коммитов, а общая длина ветки превысила 10 миллионов коммитов.

Масштабы выявили ограничения классических алгоритмов (в том числе из git) — пришлось адаптировать и оптимизировать подходы. В докладе расскажу, как мы ускорили работу с историей в Arc VCS на трёх уровнях: 1) лог коммитов: отказ от классического BFS и его оптимизация; 2) история файла: три реализации индекса и сравнение с решениями git, SVN, jj, sapling; 3) blame: создание индекса для отображения авторства каждой строки.

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

Работая в крупной ритейл-компании, мы управляем более чем 12 000 потоков данных и хранилищем объёмом 12+ петабайт. Инженеры данных ежедневно работают с набором разрозненных инструментов: среды разработки, GitLab, Airflow, SQL-движки, различные сервисы хранения и трансформации.

Такой «зоопарк» увеличивает time-to-market, усложняет онбординг и создает зависимость от контекста конкретных людей и команд.

Мы решили объединить ключевые процессы разработки потоков данных в единую веб-платформу: одно входное окно для создания, редактирования и оркестрации пайплайнов, интегрированное с Airflow и GitLab через API.

В докладе расскажем: - как родилась идея и как мы её «продавали» внутри, - как проектировали архитектуру из 10+ микросервисов, - как решали задачи сложной интеграции, - почему выбрали low-code подход, - какие ошибки допустили, - и какие результаты получили на текущем этапе.

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

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

На обезличенных production-инцидентах я покажу, как одно правило заблокировало всё, другое вывело из строя целую инсталляцию, бинарно-несовместимый инстанс вызвал каскадное падение кластера, а холодный старт создал угрозу повторной перегрузки.

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

Расскажу о наших поломках в капче, какие выводы мы из этого сделали и как теперь тестируем и выкатываем её.

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

Каждый второй PostMortem заканчивается спором о причине, а половина «мер по недопущению» умирает в тексте документа. Мы построили инструмент — PostMortem Copilot, — который на базе LLM и поиска похожих инцидентов через MinHash LSH автоматически формирует гипотезу корневой причины, альтернативные версии, факторы инцидента и конкретные меры по четырём целям: «не повторится», «заметим раньше», «пострадаем меньше», «починим быстрее».

Расскажу, почему мы отказались от эмбеддингов в пользу коэффициента Жаккара, как эмпирически нашли оптимальный порог схожести, как построили AI-судью для объективного выбора LLM из десятка on-prem моделей и почему модель — это лишь 30% успеха. Покажу продовые результаты. И расскажу, куда мы двигаемся дальше.

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

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

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

Мы расскажем про "внутреннюю кухню" обработки запросов на примере классических и современных WAF

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

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

Участники получат практическую схему построения ИИ-системы для AppSec: от прототипа до безопасной интеграции в CI/CD.

Современный NGFW обязан обрабатывать большие объемы зашифрованного трафика на скоростях до 400 Гбит/с, и бизнес больше не готов отключать функции безопасности ради производительности. Разрабатывая межсетевой экран с чистого листа, мы обошли классические ограничения и все шло отлично, пока в этот идеальный конвейер не потребовалось встроить IPSec VPN. Обработка такого объема трафика всегда приводит к следующим проблемам: высокие требования к вычислительным ресурсам, плохой параллелизм, Elephant Flow и связанная с ним сложность балансировки нагрузки на несколько ядер CPU.

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

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

Оптимизация - тема неиссякающая. Одним из классических методов оптимизации как для edge, так и для серверов является векторизация. При этом автовекторизация хорошо работает только на относительно простых задачах, а значит актуальной остаётся задача ручной векторизации. Мы разработали небольшой кросс-платформенный векторный JIT-компилятор для x86, Arm и Risc-V - удобный инструмент для хардкор-оптимизаторов, пишущих на C++.

В докладе обсудим:

• Нишу нашего проекта, сравним его с разными JIT и AOT-решениями: xbyak, llvm, mir, rcc.

• Коротко остановимся на архитектуре и дизайне.

• Рассмотрим API и живые примеры использования, чтобы продемонстировать удобство.

• Узнаем, как библиотека применялась в реальных проектах и какие результаты это принесло.

• Дальнейшие планы развития проекта.

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

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

В докладе расскажем, как мы через неудачные попытки пришли к разработке yet another flat format для эффективной и удобной работы с данными в рантайме. Посмотрим, как единая объектная модель упрощает жизнь ML-инженерам, и проведем deep dive во внутреннее устройство и trade-offs flatbuffers, чтобы понять, почему у нас получился не универсальный «убийца flatbuffers» и как осознанный выбор компромиссов при создании формата позволяет экономить десятки тысяч ядер и гигабайты сети на наших кластерах.

Всё возрастающее энергопотребление на фоне развивающегося энергетического кризиса неизбежно ведёт к консолидации вычислительных ресурсов, в частности, в виде суперкомпьютерных систем с «человеческим лицом». Они должны представлять собой не кластер с SSH-доступом к виртуалкам, а user-friendly конечный продукт предоставляющий дистанционным пользователям имитирующий вид обычной OS интерфейс, где привычным образом создаются, устанавливаются и запускаются программы, которые выполняются системой на предоставляемом кластером мощном оборудовании различного типа. В докладе предлагается снова обратить наше внимание к теме суперкомпьютеров, порассуждать об их важности, о том какие они бывают и каким должно быть отвечающее современным вызовам суперкомпьютерное ПО, включая файловую и операционные системы. Будет сделан обзор существующего ПО для суперкомпьютеров как мировых, так и отечественных производителей. И, как это ни парадоксально, складывается ощущение, что за ситуацию в этой отрасли в РФ краснеть вероятно даже и не придётся..😉

Код проектов в DeFi имеет множество интересных особенностей, главная из которых - предельная лаконичность, интересные паттерны проектирования и максимальная оптимизация. Это прекрасно демострируют AMM (Automatic Market Makers) - децентрализованные пулы для обмена различных активов. Лучшие подобные проекты работают в полностью permissionless среде, никем не управляются, и представляют собой простые, красивые и законченные математические модели. Дневные объёмы этих проектов - десятки миллиардов долларов, топовые протоколы, строго следующие permissionless паттернам ни разу не были взломаны, и в этом заслуга минималистичного и элегантного дизайна. Доклад описывает основные идеи, алгоритмы и примеры кода и позволяет лично убедиться, что вся суть протокола и его безопасность могут базироваться буквально на одной строке кода. Базовая AMM - это пара сотен строк кода которая на протяжении почти 10 лет без малейших изменений управляет миллиардами долларов, остается полностью актуальной и без сомнений являюется одним из самых демонстративных примеров применения блокчейн технологий.

Компания Яндекс активно развивает направление автономного транспорта, в том числе развивается флот роботов-доставщиков. К 2027 году ожидаемый размер флота роботов-доставщиков оценивается в 20 тысяч устройств. Роботы доставщики находятся постоянно на связи: передается в том числе видеоинформация камер.

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

Для достижения цели разработана методология оптимизации параметров кодирования и сравнения кодеков. Она опирается на общепринятые подходы: критерия BD‑Rate, точечный анализ для заданных значений битрейта/качества и сопоставление Rate‑Quality‑кривых. В ходе экспериментов варьировались ключевые параметры (промежуточное разрешение, Intra‑period, количество опорных кадров, HW Preset, тип битрейт‑контроля, размер буфера). Результат — снижение общего битрейта от четырёх камер робота-доставщика на 15 % при сохранении или улучшении визуального качества (до 30% на одной из камер)

Дополнительно оценены перспективные способы повышения эффективности сжатия: применение AV1‑энкодера (сокращение битрейта на ~10 %) и технологии Region of Interest (ROI) - перераспределение битрейта с периферийных участков в зону интереса — экономия 5–10 %). В качестве направлений дальнейшего развития выделены внедрение алгоритмов предобработки видео, полномасштабное использование AV1 и масштабирование ROI‑подхода. Решения отличаются практической ориентированностью: они позволяют добиться значимого сокращения битрейта без кардинальной смены системы кодирования, что критично для быстрого развёртывания в реальной инфраструктуре.

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

Робот-доставщик встречает пешеходов, которые могут неожиданно пересечь его путь, и автомобили, маневрирующие в тесных придомовых зонах. Расскажем, как с помощью диффузионных моделей создавать таких интерактивных агентов и управляемые сложные сценарии для RL-обучения. Расскажем, как использовать диффузионные модели для создания интерактивных пешеходов в RL-симуляции. С помощью classifier-free guidance и LoRA-адаптеров можно усиливать редкие типы поведения и управлять сложностью обучающих ситуаций. Обсудим интеграцию модели в closed loop, генерацию целевых сценариев и практические проблемы реалистичности и устойчивости.

Доклад о построении системы обработки видео в реальном времени: от запуска модели YOLO и отслеживания объектов до подсчёта событий в нужных зонах, сохранения результатов, API и интерфейса для пользователей.

Главный акцент — решение реальных проблем, которые возникают при работе ML-сервиса: задержки, нестабильные видеопотоки (RTSP), нехватка CPU/GPU, качество бизнес-метрик, проверка результатов «глазами» и отслеживание ухудшения работы модели со временем.

Мы хотели построить микросервисную SaaS-платформу, но вместо независимо развёртываемых сервисов получили распределённый монолит. Сервисы зависели от общей библиотеки контрактов, общались посредством RPC через RabbitMQ, обращались к базе данных и Redis через специальные микросервисы и образовывали циклические зависимости. В результате систему можно было тестировать и развёртывать только целиком, а один деплой занимал больше полутора часов. На реальных примерах я разберу архитектурные и инфраструктурные решения, которые постепенно сделали систему хрупкой: глобальную библиотеку с интерфейсами и DTO всех сервисов, преобладание интеграционных тестов и централизованные фикстуры, Supervisor внутри Docker-контейнеров, логирование через RabbitMQ, синхронный вызов внешнего GeoIP-сервиса, жёсткую зависимость от PHP 7.4 и конфигурацию через CSV. Доклад поможет распознать ранние признаки распределённого монолита и отличить локально удобное техническое решение от архитектурного антипаттерна. Я покажу не только последствия ошибок, но и причинно-следственные связи между ними, расскажу, какие компоненты системы пришлось переделывать и как расставлять приоритеты при распутывании подобных зависимостей.

Формат - доклад + демо стенд

Компании, которой нельзя отдавать данные наружу, публичные API не помогут — нужен свой ИИ-стек. В ГНИВЦ мы собрали первую версию ИИ-песочницы целиком из open-source: инференс текстовых, мультимодальных и голосовых моделей, веб и API, RAG, наблюдаемость, агенты в контуре. Год назад одна A100, сейчас ~20 GPU, ~1000 пользователей, 60B токенов за 30 дней — подняли всё "двумя" руками. Расскажу, из чего собрать такую платформу и что забрать команде из 1–2 DevOps.

Мы строим облачны гиперскейлер с нуля. Анализируя референсы мы нашли интересный факт: в 2022 году AWS рассказал, что аутентифицирует более полумиллиарда API-запросов в секунду. Мы спросили себя: а сколько это в железе? И вместо оценок на салфетке собрали стенд проверки HMAC-подписей — сначала наивно, потом всерьёз.

Пройдём путь запроса от подписи до вердикта: каскад деривации ключей, SigV4 байт в байт, компактный кадр верификации вместо тяжёлого callout. Разгоним стенд с замерами «до/после» на каждом шаге — от 90 тысяч до миллиона RPS. По дороге — главный инсайт: выключение криптографии ускоряет систему лишь на 11%. Лимит миллиарда — не процессор, а сеть.

Все цифры — с открытой методикой и воспроизводимым кодом. Финал — честная арифметика миллиарда: тактов на запрос, терабиты на провод, узлы на стойку.

• Как small-tech эволюционировала от фиксации инцидентов в Excel к централизованной системе наблюдаемости с метриками, логами и трейсингом.
• Внедрение SLO/SLI на основе собственной метрики «негативное влияние» для измерения качества сервисов.
• Автоматизация управления инцидентами: от ручной эскалации к чат-ботам и AI-ассистентам.
• Трансформация дежурных администраторов в команду оперативного реагирования с четкими SLA.
• Практические кейсы: снижение MTTR с 4 до 1,5 часа, рост доступности сервисов до 99,9%.