Доклады и форматы ++

Как строить pipeline на сотни миллиардов сырых HTML-страниц без бесконечного GPU-кластера. Погрузимся в архитектуру распределённой обработки веба: extraction основного контента, LID, document-level filtering, дедупликацию и каскадную маршрутизацию сложных страниц. Покажем, как сочетать CPU-first алгоритмы, лёгкие классификаторы и GPU-fallback, а также какие инженерные компромиссы возникают между throughput, стоимостью обработки и качеством итоговых данных.

AI в разработке обсуждается в терминах возможностей: ускорение, автоматизация, агенты, новый уровень продуктивности. Но как только разговор выходит за пределы демо и презентаций, возникает более жесткий вопрос: сколько на самом деле стоит это ускорение и где заканчивается эффект, а начинается новая статья затрат. В докладе разберем, из чего складывается полная стоимость владения в инженерной организации: токены, GPU-кластеры, on-prem и облако, платформенная команда, поддержка, интеграции, безопасность, тестовые контуры и цена инженерного времени.

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

Что заберете с собой • Каркас модели окупаемости AI для инженерной организации. • Список метрик, без которых нельзя честно обсуждать эффект от AI. • Подход к декомпозиции затрат: что учитывать кроме токенов и лицензий. • Низковисящие фрукты для быстрого pre-check: где смотреть экономику раньше всего. • Признаки, что пилот уже сейчас уходит в убыток, даже если формально выглядит перспективно. • Логику выбора между тремя сценариями: купить готовое, строить свое, не внедрять вовсе.

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

Расскажу, как мы с нуля обучили AliceAI-Foundation-80B-A3B-Base — MoE-модель на 80 млрд параметров, из которых около 3 млрд активируются для каждого токена. Покажу устройство её архитектуры: сочетание Kimi Delta Attention с полным attention и блочный вариант Attention Residuals, который позволяет слоям обращаться к представлениям предыдущих блоков.

Отдельно расскажу, как мы связали резкий скачок loss с ростом активаций MoE и стабилизировали обучение с помощью Z-Loss. В завершение разберу распределённую реализацию Muon, в которой пересылки данных выполняются параллельно с ортогонализацией, что примерно вдвое ускоряет шаг оптимизатора.

Что такое 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. Лучший результат даёт команда, работающая совместно с ИИ: человек отвечает за смыслы и управление рисками, а ИИ ускоряет аналитику, тесты и улучшение системы.

Когда поиском пользуется человек, профиль запросов относительно предсказуем. Агент способен за одну пользовательскую задачу сделать серию вариативных вызовов API, поэтому дорогой retrieval может превратиться в риск каскадной деградации. Я расскажу, как мы готовим поиск в 360 на примере поиска по почте и календаря к такой модели нагрузки; Я подробно разберу как на примере календарных данных которые создают неприятную развилку: повторяющиеся встречи нужно представить в поисковом индексе, а одно событие может быть связано со множеством пользователей. Мы сознательно переносим тяжёлую работу в поставку и индексацию и заранее готовим поисковое представление событий, чтобы путь запроса оставался коротким и предсказуемым. Разберём trade-off между стоимостью индексации и сложностью чтения, цену быстрого retrieval и границы применимости такого подхода, а также как это влияет на надежность всей системы в условиях современных агентов.

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

• Решение проходит цепочку «бизнес-аналитик → архитектор → системный аналитик → разработка» и на каждой передаче искажается.
• Изменение в одном домене задевает соседние команды и интеграции. Выяснить, кого именно, удаётся только серией встреч.
• Знание о продукте лежит в вики, каталоге архитектуры, коде и головах, и эти источники расходятся между собой.
• Процессы и регламенты описаны, но под срок шаги пропускаются, и заметить это некому.
• ИИ-агенту в таком ландшафте не хватает контекста: корпус знаний многократно больше того, что модель может прочитать, а выбрать нужную часть заранее некому.

Готовых решений для этого нет. Существующие инструменты и фреймворки для работы с агентами рассчитаны на одного разработчика и один репозиторий. Для цепочки ролей, нескольких команд и связанных систем мы собрали свой фреймворк — Genome — и применяем его на платформе B2B-продаж: 12 доменов, 3 команды, десятки интеграций.

Что будет в докладе

• Как Genome раскладывает знание о большом продукте: домены, владельцы, связи с соседними системами и каталогом архитектуры компании.
• Как агент получает контекст под конкретную задачу, когда всё знание в него не помещается.
• Как устроена передача между ролями: что проверяет скрипт, что агент, что принимает человек, и что происходит при расхождении с принятым решением.
• Как правила процесса становятся машинными проверками.
• Показ в терминале: один эпик от запроса бизнеса до контракта между командами.
• Что уже работает, что ещё обкатываем и чем собираемся измерять эффект.

Что вы сможете применить у себя после выступления

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

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

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

Помните вечный документ «первый день сотрудника», который правит каждый новопришедший? Теперь ваш новопришедший — это ИИ, и «контекст в голове» больше не работает: важны однозначность, повторяемость и понятные интерфейсы к вашей системе.

В докладе пройдёмся по всему SDLC — от анализа требований до поддержки — и на наших опенсорсных примерах покажем, как встроить ИИ в каждый этап: стенды и деплой по кнопке, e2e-тесты, которые легко создавать и запускать, reconciliation loop как основа выживания (ведь теперь систему ломает ещё и ИИ), и основная арифметика, сколько всё это стоит в плане инфраструктуры. По итогам получаем процесс - как включить ИИ в свою разработку, не проводя разницы между ним и человеком.

Публичные ИИ-ассистенты (вроде 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 автоматических проверок и инвариантов, которые ловят его раньше, чем код доедет до прода. На живых примерах покажу, где агент ошибался и что его останавливало — включая запрос к графу на миллионы связей, который он сначала написал неправильно.

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

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

Практическая часть — опыт банковского проекта со 100+ микросервисами. Покажу, почему стандартного OpenSpec оказалось недостаточно, как мы адаптировали процесс для межсервисных изменений, нескольких репозиториев и независимой проверки — и с какими ограничениями столкнулись при внедрении.

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

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

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

Тезисы воркшопа

• Участники разберутся, почему AI агенту недостаточно просто дать доступ к корпоративной документации и чем инженерный гайдлайн отличается от обычной инструкции.
• Каждая команда выберет конкретное инженерное правило или повторяющееся замечание из code review и сформулирует его так, чтобы оно было понятно и разработчику, и AI агенту.
• Участники выполнят одну и ту же инженерную задачу дважды. Сначала без дополнительного контекста, затем с подключенным гайдлайном.
• Команды научатся описывать область применения правила, ограничения, причины выбора подхода, хорошие и плохие примеры, исключения и критерии проверки результата.
• Участники проведут перекрестное ревью гайдлайнов и проверят, можно ли однозначно понять и применить написанное правило.
• Готовые гайдлайны будут загружены в Developer Book и подключены к AI инструментам через MCP.
• Команды сравнят результаты до и после подключения контекста и определят, какие части гайдлайна действительно повлияли на поведение AI.
• Участники познакомятся с системой оценки качества гайдлайнов и поймут, как находить неоднозначности, пропущенные ограничения и непроверяемые требования.
• По итогам воркшопа каждый участник получит готовый шаблон гайдлайна, методику его проверки и артефакт, который можно адаптировать для своей команды.
• Главный результат воркшопа состоит в том, что инженерное правило перестает быть пассивной документацией и становится рабочим контекстом для разработчика и AI агента.

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

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

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

Год назад я запускал один агентный поток и успевал читать каждую строку кода. Сегодня у меня до десяти параллельных окон агентной разработки — и держать в голове каждый поток физически невозможно. Если у вас так же, то вы не одиноки. Это новая инженерная дисциплина, и у неё есть своя механика. В докладе разберу, как удерживать качество при ведении параллельных агентных потоков: пять контрольных точек вместо чтения всего кода (декомпозиция, выполнение по плану, тесты, зелёные тесты, critique-ревью второй моделью); карту границ «что агенту не доверишь» — зоны, где модели ошибаются систематически; и способ посчитать личный предел параллельности, чтобы «ещё один агент» не выжег фокус. Сто лет науки об управлении, span of control и формула Грайкунаса дают готовый инструмент: применю его к агентным потокам. Слушатель унесёт набор контрольных точек, критерии границ делегирования и метод оценки своего лимита потоков.

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

Большинство бизнес-сценариев ИИ-автоматизации не требуют гигантских фронтирных моделей - они просто не окупаются. При проектировании RAG и агентных систем harness (обвязка, архитектура применения модели) важнее самой модели: грамотно построенная RAG-система с моделью на 7B стабильно обыгрывает свежие GPT и Claude, работающие "в лоб" без хорошего RAG, особенно на специальных или закрытых доменах, не попавших в трейнсет этих самых GPT.

Но что такое "хорошо" и что такое "плохо" применительно к обвязке для RAG? Простой поиск по текстовым чанкам для контекста LLM - это плохо! На "грязных" реальных корпусах он теряет полноту и ломает поиск именно там, где нужна многошаговая аналитика. "Я такого не хочу даже вставить в книжку", а в рабочую систему - тем более.

А вот про "хорошо" я расскажу на примере нашего вкусного RAGU - открытого модульного движка GraphRAG для реального бизнеса, а не для GPU-rich компаний с кластерами на тысячи терафлопс. RAGU опирается на многошаговый harness, превращающий сырые документы в граф знаний последовательно и с самопроверкой. Мы обсудим границы применимости RAGU и его результаты на публичных бенчмарках в сравнении с LightRAG, HippoRAG 2 и другими вариантами harness, а также прикладные вопросы: какие ручки крутить, как выбирать стратегию поиска под свой домен и почему отсутствие «коробочного» дефолтного пайплайна - это сознательное архитектурное решение, а не баг.

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

Рассказ посвящен тому, как в рамках необходимости увеличения эффективности разработки за счет ИИ не потерять в безопасности, не слить никуда и никому свои данные через AI-агентов, AI-ассистентов и другие AI-инструменты

Расскажем, как выглядит процесс разработки AI-агентов на платформе: от идеи и выбора сценария до подключения инструментов, настройки доступов и запуска в production. Отдельно разберём, что происходит со стороны безопасности: авторизация, работа с токенами, контроль tool calls, аудит действий, observability и SSDLC для агентов. На примерах агентов, влияющих на SDLC, покажем, как ускорять разработку, аналитику и дежурства без потери контроля над доступами, данными и действиями агента

Проблема: MAU агентных систем для PDLC в банке составляет 40+ тысяч человек. Ежедневно системами пользуются более 10 тысяч человек. При этом помимо пользователей за потребление токенов конкурируют автономные агенты, системы обучения моделей и замеров (бенчмарков). Токены затрачиваются не только на генерацию ответа, но и на сбор и анализ громадного объема корпоративного контекста, знаний, методик, правил регуляторов. В месяц мы потребляем более 10Т токенов, что требует значительного количества GPU-ресурсов и команд поддержки работоспособности.

Решение: • Балансировка задач по дневному и ночному инференсу. • Внедрение контекстного храналища для эффективного управления контекстом (сокращение потребления токенов "на входе"). • Создание конвейеров автономной работы, включающий как ИИ шаги, так и детерменироанную логику ("Не используем ИИ там, где можно автоматизировать без ИИ", например, в сборке проектов).

Когда AI перестаёт отвечать текстом и начинает выполнять действия, одного LLM API уже недостаточно.

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

За четыре месяца мы построили Маверик — собственную агентную платформу X5.

Сегодня на платформе:

— 8 000+ пользователей; — 100 000+ обращений за два месяца; — 50+ подключённых корпоративных систем; — 250+ доступных агенту инструментов; — 100+ автоматизаций по расписанию; — 90% задач доводятся до результата без участия человека.

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

Что получит слушатель

После доклада слушатель сможет:

— спроектировать pipeline от пользовательского запроса до выполненного действия; — отделить agent core от моделей и интеграций; — собрать расширяемый tool layer; — определить, какие операции требуют human approval; — организовать выполнение кода в sandbox; — добавить model fallback без потери состояния задачи; — разделить executor и controller; — переводить диалоговые запросы в повторяемые workflow; — выбрать метрики, которые показывают реальную пользу агента.

Все возможные сроки вышли и уже без вариантов на предприятиях КИИ должен быть полностью импортозамещенный стек, включая замену 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 пришлось пересобрать с компрессией и выгрузкой в холодное хранилище. Ещё одна правка: гардрейлы должны проверять не только вход, но и выход модели. Третий — согласия на обучение моделей. Мы сформулировали сценарии: базовое согласие, отдельное согласие на обучение, отзыв согласия. На практике удаление данных из модели невозможно. Я переформулировала требование: дообучение идёт только на данных с активным согласием, исторические данные остаются в модели. Регулятор принял этот компромисс. Главный вывод: качественные требования спасают проект. Нельзя передать закон разработчикам — нужно превратить его в проверяемые условия. И честно фиксировать технические ограничения как согласованные риски.

Пользователь открывает карточку сотрудника. API отвечает за 80 миллисекунд, Kafka lag в норме, consumer работает, Redis доступен. Но часть данных уже устарела: сотрудник уволен, а один из пользовательских сценариев всё ещё видит его активным.

Как понять, можно ли вообще доверять такому ответу?

Разберём систему, где данные о миллионах людей собираются из нескольких источников и проходят через:

PostgreSQL → Outbox/CDC → Kafka → Read Model → Redis → API

Покажу, почему timestamps, трейсы, Data Lineage и consumer lag хорошо объясняют, что произошло с данными, но ещё не отвечают на вопрос, насколько сильно мы можем доказать их актуальность в момент принятия бизнес-решения.

Сравним несколько способов проверки:

• полную реконсиляцию источника и проекции
• watermarks, чекпоинты, sampling и синтетичесие пробы
• индивидуальное доказательство прохождения значимых изменений
• токен консистентности и version-aware чтения
• authoritative/strong чтения для критических операций.

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

Поэтому для разных сценариев будем использовать разные гарантии. Информационный профиль может жить с ограниченной eventual consistency. Пользователь после собственной правки должен получить read-your-writes. А критическая операция должна либо получить достаточное доказательство актуальности нужных ей данных, либо честно признать состояние неизвестным и не выполнять действие.

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

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

Георезервирование это уже не "модно", это уже привычная реальность. Но есть ряд проблем: - мы знаем как обеспечить быстрое переключение при аварии - мы умеем адаптировать распределение нагрузки динамически в соответствии с потребностями - мы умеем обеспечивать resilience при аварии но как это обычно бывает, - "выберете два пункта из трех", а может есть вариант как получить все? Как говорится "нам и то и другое, и можно без хлеба" (с)

Мы научились считать метрики А/Б-экспериментов в реалтайме (об этом был прошлый доклад) — и этот подход вырос из решения одной задачи в платформу реалтайм-сигналов. CORTe (COllector RunTime) на едином коде и методологии закрывает сразу три задачи — A/B-тестирование, онлайн-мониторинг продуктов и приёмку релизов. Сегодня CORTe работают процессинги для Рекламы, Алисы, Маркета и других продуктов, а потоки доходят до >300K RPS на источник. Когда сигналы считаются в одном месте по единой методологии, метрики перестают расходиться между задачами — уходит проблема кросс-валидации и рассинхрона, когда одну и ту же метрику по-разному считают в экспериментах, мониторинге и приёмке. Использование CORTe даёт масштабируемое и интегрированное в инфраструктуру компании решение.

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

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

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

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

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

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

Классическая модель I/O в Linux (blocking read/write, poll/epoll, POSIX AIO) упирается в накладные расходы на syscalls и context-switch при высоком RPS. io_uring – это не “ещё один API”, а смена модели: приложение общается с ядром через shared-memory кольца (SQ/CQ) вместо синхронных вызовов, что открывает целый класс возможностей, которых в старом I/O не существует в принципе (не “хуже реализовано”, а отсутствует как концепция). Доклад показывает это на конкретных примерах и цифрах.

Чтение с реплики выглядит как простой способ масштабировать 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): Выводы и заключение: Бэкап огромных БД – сложная техническая задача, так как стандартные подходы и инструменты не работают. Без применения нестандартных подходов риск потери данных становится неприемлемым.

Для репликации хостов кластера, MongoDB использует механизм, который называется oplog; он обеспечивает синхронизацию данных, а также не позволяет репликам сильно отставать от мастера. Однако, иногда, одна или несколько нод кластера могут отстать слишком сильно, после чего администратору приходится вручную инициировать полную синхронизацию ноды, которая в документации красиво зовётся "Initial Sync".

За красивым названием кроется самая примитивная реализация: пользователь вручную удаляет все данные с хоста, после чего реплика качает эти данные с одного из свежих хостов

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

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

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

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

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

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

Запустить LLM сегодня можно быстро: взять GPU, поднять vLLM или SGLang, получить OpenAI-compatible API и показать демо. На этом этапе всё выглядит почти слишком хорошо: модель отвечает, curl работает, первые пользователи довольны.

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

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

Разбор пойдёт в формате «вызов -> решение». Начнём с одного vLLM-контейнера, затем добавим несколько моделей, команды, ключи, права на модели, учёт токенов и эксплуатационные метрики. Производительность, GPU-пулы и роутинг запросов будут фоном; основной фокус - управляемый AI API как сервис.

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

Для ML/AI задач стандартного планирования Kubernetes часто недостаточно: GPU задачи конкурируют за ограниченные ресурсы, требуют очередей, приоритизации и более гибкого распределения вычислительных мощностей кластера. В докладе я покажу, зачем ML инфраструктуре нужен отдельный планировщик GPU задач, и разберу это на примере того, как мы реализовали это в Nova AI.

Основной фокус доклада - Volcano как практический инструмент для оркестрации GPU нагрузок. Сравню его с Kueue и Kai Scheduler, объясню, как устроен Volcano, разберу динамическое дробление видеокарт.

Покажу прикладные кейсы: как настраивать очереди для задач разной важности, как Volcano можно использовать вместе с KubeRay для запуска распределенного инференса LLM.

В Яндексе активно используют монорепозитории и 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-инженеров: с реальными ограничениями по ресурсам, итерациями, отказами и эволюцией решения.

Запустить Valkey в проде не очень сложно. Запустить его как Managed-сервис для тысяч клиентов с жесткими SLA - вызов, где стандартные инструменты ломаются один за другим. В этом докладе я расскажу о внутренней кухне нашего Managed Service for Valkey и поделюсь опытом эксплуатации.

Мы обсудим, почему мы выкинули встроенный Sentinel/Cluster failover и написали свой, как чтение AOF для бекапов спасает нас от OOM-ов, и как наш патч для PSYNC из AOF позволяет выкатывать обновления с рестартом, не перегружая primary-ноды генерацией RDB для реплик. Отдельно затронем суровую реальность эксплуатации сервиса на C: как организовать централизованный сбор minidump'ов без использования гигантских core-файлов и риска утечки пользовательских данных.

Будет много архитектуры и низкоуровневых деталей.

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

Сначала мы посмотрим на «наивную» реализацию агента, а потом — прокачаем его до зубов! Посмотрим, как изменится его поведение, скорость работы и расход токенов. А в промежутках поговорим про open source инструменты и модели для AIOps, результаты опроса и курьёзные случаи.

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

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

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

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

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

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

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

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

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

X.509 сертификаты обычно воспринимаются как готовый способ сделать систему безопаснее: включили HTTPS, настроили mTLS, добавили доверенные CA и задача решена. На практике дьявол кроется в деталях: непонимание назначения полей сертификатов, неправильное использование списков отзыва, soft-fail проверки доверия и многое другое.

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

Злоумышленники иcпользуют украденные учетные записи, легитимные в инфраструктуре компании, и средства удаленного доступа, такие как RDP, SSH и другие. Это делает хакеров невидимыми для традиционных систем сетевой безопасности.

Если для перемещения или вредоносных действий используются IoT-устройства или хосты, на которых не установлены агенты, такая активность может остаться незамеченной даже самыми передовыми агентсткими средствами защиты.

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

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

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

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

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

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

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

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

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

Поговорим о методике поиска узких мест в при проведении нагрузочного тестирования Рассмотрим самый быстрый алгоритм и что будет, если ему не следовать На какие метрики производительности и в какой последовательности смотреть, чтобы не закопаться Какие могут быть развилки при анализе причин деградации Какие ключевые метрики у серверов приложений, баз данных, брокеров сообщений. Как могут помочь профилирование и tracing. В каких случаях и кого от команды необходимо звать на помощь Как LLM и machine learning используются в анализе причин деградации и поиске решений. И все это на примерах

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

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

На примере файлового хранилища TATLIN.BACKUP Роман расскажет, как устроено перфоманс-тестирование системы. В докладе будут рассмотрены основные виды тестов, подходы к непрерывному отслеживанию производительности в процессе разработки (continuous benchmarking), а также методы поиска и устранения первопричин деградаций на основе реальных расследований.

Оптимизация - тема неиссякающая. Одним из классических методов оптимизации как для 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» и как осознанный выбор компромиссов при создании формата позволяет экономить десятки тысяч ядер и гигабайты сети на наших кластерах.

Что делать, если один расчёт длится от десятков минут до нескольких часов, модели становятся всё тяжелее, а локальное исполнение перестаёт масштабироваться вместе с их сложностью?

В докладе поговорим о том:

• почему модель "микросервис + autoscaling" не всегда подходит для тяжёлых математических расчётов;
• где проходит граница между сервисной архитектурой и HPC;
• как меняется архитектура, когда главная метрика - не RPS, а time-to-result;
• зачем поверх вычислительного кластера нужна отдельная платформа;
• и какие новые задачи становятся возможны, когда вычислительные ресурсы перестают быть главным ограничением.

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

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

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

Используете Kubernetes? Автоматизируете управление инфраструктурой? Тогда, вы уже пользуетесь Cloud Native инструментами и практиками. Cloud Native подходы выросли из облачного окружения, но могут применяться даже на bare metal. На основе данных исследования State of Cloud Native Russia 2026 и международных исследований покажем, какие инженерные capabilities ускоряют поставку, увеличивают стабильность продукта и повышают качество разработки. В докладе мы рассмотрим различные подходы, оценим их влияние на эффективность разработок и сравним эффекты их применения вне облачной среды. Рассмотрим три ключевых направления и их взаимное влияние: - AI-capabilities: как на эффективность команд влияют доступные ИИ возможности: самостоятельная работа с контекстом, уровни автономности агентов и инструменты верификации результата. - Архитектурные и cloud-native практики: какие свойства архитектуры и инфраструктуры упрощают внесение изменений, уменьшают связанность и стоимость эксплуатации, а также как это связано со скоростью разработки и стабильностью продукта. - DevSecOps capabilities: насколько безопасность интегрирована в стандартный процесс разработки, что удаётся автоматизировать, и какие уровни контроля позволяют снижать риски без заметного уменьшения скорости поставки.

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

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

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

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

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

Далее представлена архитектурная модель разрабатываемого сервиса.

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

1. Проектирование архитектуры сервиса, направленной на минимизацию задержки передачи сигнала на всех этапах информационного обмена — от городского API до сервисного уровня и далее до клиентского приложения.
2. Обеспечение устойчивой работы сервиса при высокой нагрузке, предполагающей одновременное обслуживание сотен тысяч сессий, соответствующих активным поездкам.
3. Реализация механизмов отказоустойчивости, гарантирующих непрерывность функционирования сервиса в случае выхода из строя нескольких его инстансов.
4. Оптимизация конфигурации базы данных и каналов доставки данных, включая проработку специфических аспектов их настройки для достижения максимальной эффективности и надёжности системы.
5. Переход от HTTP-поллинг клиента к событийной схеме на websocket.

Интеграция с Единой биометрической системой — это не просто подключение к 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%.

Расскажу о том, как антифрод продолжает проверки при отказе хранилищ

▎ Отказала база — лёг сервис. Отказал кэш — лёг сервис. Неудачный релиз одного потребителя — встала очередь, разгребают всей командой. Мы решили, что так быть не должно, но начали не с «сделаем всё отказоустойчивым», а с одного вопроса: что минимально необходимо, чтобы платёж прошёл онлайн. Дальше выписали каждый инфраструктурный узел на этом пути, построили карту деградации и научили деградировать каждый узел по отдельности. Теперь отказ базы гасит часть функциональности, а не сервис; с кэшем то же; неудачный релиз не останавливает разбор очереди. Расскажу, как мы это делали, где едва не выключили то, что выключать нельзя, и почему часть наших защит оказалась декорацией. И чем всё закончилось, когда контур научился деградировать.

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