Смолл/мидтех

Кажется, что если платформа живет внутри BigTech, то там уже все давно правильно спроектировано, обдумано и выстрадано. Спойлер: нет. Боли есть всегда. В любой доменной платформе. Если это не BigTech, а стартап — боли там тоже есть, просто о них еще не знают. А потом мы все дружно и героически их чиним. И периодически сами же снова создаем — потому что никто из нас не идеален, особенно когда домен еще не прожит и времени на «сначала подумать» традиционно нет.

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

Мы возьмем четыре платформенных домена, которые довольно часто одновременно существуют внутри одного BigTech: — FinTech — Compliance — заказы и корзина в e-commerce — каталог и витрины и посмотрим на них как на одноранговые системы.

Потому что самое интересное — не в различиях. Самое интересное — в том, насколько одинаково они ломаются.

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

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

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

Это разговор для тех, кто хотя бы раз приходил в новую компанию, смотрел на платформу и думал: «О, опять ОНО!».

В старых нагруженных корпоративных проектах часто можно встретить активное использование временных таблиц в СУБД. Нередко подобные решения оказываются очень чувствительными к росту объема поступающих в систему данных.

Чтобы оживить один из таких проектов без его модернизации мы воспользовались одним из ключевых преимуществ колоночных хранилищ и применили его к этому "проблемному" паттерну.

В рамках развития практик FinOps в Купере мы столкнулись с необходимостью управления "финансовыми аномалиями" – отклонениями в расходах на облачные ресурсы. Решение оказалось интересным и элегантным: вместо того, чтобы изобретать процесс с нуля, мы переиспользовали "кубики" из зрелых и уже показавших свою эффективность процессов управления инцидентами и проблемами. Расскажу о том, как это работает, почему это проще, чем кажется на берегу и как это поможет вам перестать переплачивать за облака и сервера.

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

Пройдем путь от незащищенного агента к укрепленному, с примерами атак и фиксов: обход логики системных промптов с примерами из контестов и багбаунти, обходы ML guardrails с помощью сдвигов текста, шифрования ответов, смены языка и др. LLM guardrails через подбор состязательных суффиксов/префиксов, кейсы из Web3 (например, атака на автономных агентов с переводом активов), Telegram/Discord/Twitter агентов и мультиагентов

Практическая ценность: - Алгоритм аудита для своих LLM-агентов: как выявить уязвимости вроде prompt-injection или supply chain атак. - Шаблоны защит: опенсорсные инструменты (Ml Guardrails, Llama Guard, выбран за эффективность в блокировке 99.997% jailbreaks по тестам на 300k промптах). - Ссылки на таксономию уязвимостей промптов и сравнение моделей от нас (из исследования апрель 2025), и от Pangea (август 2025) - Ссылки на OWASP Top-10 LLM, AI agents, MITRE и предлагаемые ими схемы защиты

Мы строим платформу инференса и обычно пропагандируем идею "локальные LLM в продакшн". Но для средних и малых компаний рекомендация часто будет противоположная: не надо начинать с покупки GPU. В докладе покажу, где именно ломается экономика локального инференса и почему "поставим vLLM на свою карту" не равно "получим дешёвый продакшн-сервис".

Разбор будет через TCO. RTX 5090 можно арендовать за 50-90 тыс. рублей в месяц или купить за 300-500 тыс., но железо — только первая строка затрат. Дальше появляются ДЦ, электричество, охлаждение, сеть, мониторинг, деплой, кусочек или полный DevOps на поддержку и несколько человеко-месяцев на запуск. Даже если модель даёт хорошие tok/s в бенчмарке, карта ночью простаивает, днём упирается в потолок, а среднемесячная загрузка редко похожа на провайдерские 50-70%.

В конце разберём исключения: ИБ или регуляторика; GPU-парк в наследство от прошлого проекта; CAPEX, который проще защитить, чем OPEX; подозрительно постоянная нагрузка/training, под которую железо можно занять почти круглосуточно. В остальных случаях сначала стоит смотреть на API/OpenRouter, отечественные сервисы с оплатой по токенам или аренду GPU на короткий тест.

В докладе поделимся практическим опытом переезда высоконагруженных AI-сценариев с вендорских моделей как услуги (MaaS) на локальные (on-premise) LLM, STT и эмбеддинги. Расскажем про реальные инженерные проблемы такого перехода: от ограничений контекстного окна и ресурсоемкости его обработки до деградации скорости инференса на фреймворках вроде vLLM и сложностей балансировки разноплановой нагрузки. Развенчаем популярные мифы о хостинге моделей и дадим конкретные инсайты, основанные на эксплуатации ансамбля моделей, обрабатывающего миллионы запросов в месяц.