ЛекцияВШЭ · 23 мая 2026
AIOps / LLMOps для ИИ-продуктов
Управленческие решения, экономика и FinOps для продакшен-контура ИИ
/ AIOps / LLMOps для ИИ-продуктов · ВШЭ 2026
Содержание слайдов
1. AIOps / LLMOps для ИИ-продуктов
Управленческие решения, экономика и FinOps для продакшен-контура ИИ
2. Александр Поломодов
Technical Director & Fellow, Т-Технологии
Архитектура и инженерные практики
AI внедрение на масштабе разработки
Фокус: управляемый продакшен AI
3. Платформа есть. Теперь ей надо управлять
Руководитель выбирает поведение, запуск и контроль
Словарь уже есть — Gateway, context, evals, защитные ограничения известны.
Фокус на решениях — SLA, автономия и цена качества.
Денежный якорь — Support-бот проверяет TCO/FinOps.
4. Базовые компоненты считаем пройденными
AIOps / LLMOps начинается после появления платформы
Не пересказываем карту платформы
Выбираем сервис под сценарий
Считаем цену решенной задачи
Фокус: управляемость AI-продукта
5. 01. От базы к управлению
Не повторяем устройство AI-платформы, а переводим его в решения руководителя
6. После запуска AI становится сервисом
Появляются владельцы, бюджет и контур контроля
Качество: сценарии и пороги
Риск: права, аудит, резервный сценарий
Стоимость: не только токены
Ответственность: продукт, платформа, риск
7. Менеджер выбирает рамку
Одна модель может быть помощником, сервисом или агентом
Что должно произойти
Какой сценарий улучшаем
Какую базовую линию побеждаем
Что нельзя сломать
Цена ошибки и риск данных
Потолок стоимости операции
8. AIOps — это контур решений
До запуска: сценарий и потолок
Во время: автономия и резервный сценарий
После: экономика и маршруты
Модель управления важнее единичной модели
9. 02. Решения менеджера
Сценарий, автономия, цена ошибки, SLA, бюджет качества и ответственность
10. До масштаба нужны решения
Иначе AI растет быстрее контроля
Value — Ценность и сценарий — Где ценность, какую базовую линию и какой SLA.
Risk — Риск и контроль — Допустимая автономия и human-in-the-loop.
Cost — Экономика и ответственность — Цена качества; владельцы продукта, данных, риска и счета.
11. Цена ошибки задает автономию
Дороже последствие — строже контроль
Низкая цена ошибки
Черновики, подсказки, поиск
Быстрые модели и кэш
Метрика: скорость и deflection
Высокая цена ошибки
Деньги, договоры, prod
Policy gate, approval, аудит
Метрика: инциденты и эскалации
12. AI SLA шире uptime API
Важен безопасный результат, а не вызов модели
Service health
Latency, timeouts, fallback
Peaks, queues, rate limits
SLO включает резервный путь
Quality health
Источники, полнота, policy
Нет контекста — эскалация
Качество мерим по сценариям
13. Оценка идет от продукта
Одинаковый стек может быть правильным или нет
Ценность: процесс и базовая линия
Риск: ошибка и approval
Экономика: unit cost
Операционность: выпуск и откат
Решение объясняется не стеком
14. 03. Варианты и компромиссы
API-first, управляемая платформа, арендованные GPU, свой self-host и hybrid
15. AI-runtime — портфель вариантов
Выбор зависит от данных, контроля и горизонта
Покупаем больше готового
API-first: быстрый старт
Managed: контроль и lock-in
SaaS: проверка спроса
Берем больше контроля
Rented GPU: OPEX вместо CAPEX
Own self-host: контроль и эксплуатация
Hybrid: маршруты по сценариям
16. Помощник и агент — разные продукты
Одна модель, но разные риск и управление
Read-only помощник
Ценность: поиск и объяснение
Риск: ошибка и утечка
Контроль: ACL, citations, резервный сценарий
Агент с действиями
Ценность: выполняет шаги
Риск: деньги и prod
17. Нужны правила маршрутизации
Путь выбирается по сценарию, риску и цене
Низкий риск — дешевый route
Дорогая ошибка — premium/review
Сбой — partial/read-only/handoff
Стоимость меняет routing
18. Выбор — портфельное решение
API-first — старт и проверка
Rented GPU — переходный контроль
Own self-host — только при нагрузке
Hybrid — разные сценарии
Нельзя выбрать runtime без сценариев и финансового горизонта
19. 04. Денежный кейс
Support-бот: нагрузка, токены, GPU, команда и управленческий выбор
20. Считаем support-бота
200 000 диалогов в месяц, 10 сообщений в диалоге, SLA до 5 секунд
Что считаем — Нагрузка, токены, peak, GPU, CAPEX/OPEX, команда.
Что сравниваем — API-first, rented GPU, own self-host, hybrid.
Что решаем — Путь на год и метрики пересмотра.
21. Параметры кейса фиксируют масштаб решения
Это уже не игрушечное демо, но еще не нагрузка, которая автоматически оправдывает свое железо
22. Сначала переводим продуктовые параметры в RPS и параллельность
1 000 000 LLM-ответов в месяц дают пик около 9-10 одновременных генераций для SLA 5 сек
23. GPT-5.2 API дает понятный стартовый OPEX
При профиле 1 400 input и 180 output токенов на ответ LLM-часть стоит около $4 970 в месяц
24. API-first покупает скорость
Риск — тихий рост unit economics
Почему стартовать удобно
Почти нулевой CAPEX
Быстрее production
Тоньше платформа вокруг
Что нужно контролировать
Output, cache, retries
Provider limits и деградация
25. Self-host начинается с SLA и пиков, а не с желания купить GPU
Для пика около 10 параллельных ответов оценка дает 6-8 A100 для 14B и около 12 GPU для 32B
26. Арендованные GPU убирают CAPEX, но оставляют OPEX и эксплуатацию
В примере 6-8 A100 дают 1.17-1.56 млн руб/мес до учета сети, хранения и команды
27. Self-host меняет задачу
Вместо токенов появляется инфраструктурный продукт
Rented GPU
Проверка self-host гипотезы
OPEX зависит от загрузки
Нужны MLOps/SRE
Own hardware
Максимум контроля
CAPEX и сроки поставки
Смысл при стабильной нагрузке
28. Сравнение стратегий показывает решение на первый год
Для заданной нагрузки API-first чаще всего рационален, если нет жесткого требования on-prem
29. Решение должно включать точку пересмотра
Запуск через API не отменяет план пересчета при росте трафика, комплаенса или цены качества
30. Решение по кейсу
Стартовать API-first
Сразу вести unit economics
Задать триггеры пересмотра
Self-host доказывать расчетом
Первое решение - скорость с контролем, не вечная архитектура
31. 05. Управляемость и FinOps
Дашборд, распределение затрат, пересчет unit economics и 120-дневный план
32. FinOps начинается с владельца счета
Без связи с продуктом расходы растут быстрее пользы
Сценарий имеет лимит
Стоимость видна по route
Общий счет прячет решения
Цена объясняет компромисс
33. Если выбирать свое железо, счет быстро становится платформенным
Habr/TCO пример показывает порядок: одна конфигурация около 202 млн руб, а prod/dev/test/reserve - около 606 млн руб
34. После CAPEX начинается эксплуатация
Электричество, охлаждение, лицензии, поддержка и команда превращают железо в сервис
35. Общую AI-платформу нужно распределять по понятным драйверам
GPU-часы, хранение, кВт·ч, трафик, контейнеры, модели и пользователи связывают затраты с поведением продуктов
36. Дашборд соединяет качество, риск и деньги
Отдельные графики токенов не дают решения
Качество и риск
Качество по сценариям
Резервный сценарий и policy violations
Инциденты с evidence pack
Экономика и контроль
Cost per outcome
Cache, retries, route mix
37. 120 дней: от сценария к масштабу
План начинается с управленческого контура
0-30: сценарии, базовая линия, owners
30-60: observability, fallback, dashboard
60-90: limited release, unit economics
90-120: FinOps и масштабирование
Масштабируйте управляемые сценарии
38. Нельзя измерить — нельзя управлять
Без evals качество кажется выше
Без резервный сценарий растет риск
Без unit economics ломается экономика
Без ответственности начинается спор
Управляемый ИИ начинается с решений менеджера
39. Материалы
AIOps, риск и экономика
OpenAI pricing and docs.
OWASP, NIST, Langfuse.
Habr TCO, FinOps Foundation.
40. Форма обратной связи по второму дню
Форма обратной связи по второму дню