Что произошло
Ещё год назад вопрос «облако или контур» для ИИ решался просто: пилот — в облаке, потому что быстро и дёшево; о контуре подумаем, если пилот удастся. Сейчас компании из регулируемых отраслей начали переводить удавшиеся пилоты в промышленную эксплуатацию — и обнаружили, что экономика контура не имеет ничего общего с экономикой облачного пилота. Стоимость запроса, которая в облаке была строкой в счёте, в контуре превратилась в сумму из десятка статей, большая часть которых не зависит от количества запросов.
Второй сдвиг — в технологиях. Открытые модели, пригодные для промышленных задач, стали доступны в размерах, которые можно разместить на одном-двух серверах. Инструменты инференса — vLLM и аналоги — довели эффективность использования GPU до уровня, при котором собственный контур стал рационален не только для тех, кому он обязателен, но и для тех, у кого просто большой объём запросов. Это расширило круг компаний, которым нужно считать стоимость владения контуром.
Ошибка почти всегда одна и та же: считают железо и не считают эксплуатацию. Сервер с GPU — самая заметная и самая простая для оценки статья. Всё остальное — люди, обновление моделей, мониторинг, простои, резервирование — распределено во времени и по подразделениям и в первоначальной смете не появляется. Через год эксплуатации выясняется, что железо составило меньшую часть суммарных затрат.
Из чего складывается стоимость владения
Железо: GPU — не единственная строка
Стоимость вычислительной инфраструктуры складывается из нескольких слоёв, и GPU — только первый. Далее: серверы с достаточным объёмом памяти и пропускной способностью для загрузки моделей, системы хранения для моделей, векторных индексов и журналов, резервирование — второй комплект для отказоустойчивости или хотя бы горячий резерв.
Отдельная статья — инженерная инфраструктура: стойки, электропитание, охлаждение. Серверы с GPU потребляют и выделяют существенно больше, чем стандартные, и существующая серверная может не иметь запаса. Модернизация серверной или размещение в коммерческом ЦОДе — статья, о которой часто вспоминают после закупки оборудования.
И последнее по порядку, но не по значению — срок амортизации. Оборудование для ИИ обновляется быстрее классического серверного: через несколько лет текущая модель GPU будет уступать новым в разы по соотношению производительности и энергопотребления. Амортизация должна считаться по реалистичному сроку.
Инференс: стоимость запроса зависит от загрузки
В облаке стоимость запроса фиксирована: тариф за объём токенов. В контуре стоимость запроса — производная от загрузки: инфраструктура стоит одинаково независимо от того, обрабатывает она мало запросов или много. Это означает, что при низкой загрузке стоимость каждого запроса в контуре может быть в разы выше облачной, а при высокой — в разы ниже.
Отсюда следствие, которое часто упускают: контур выгоден при стабильно высокой загрузке. Одна задача с небольшим потоком запросов не загружает GPU и делает контур неоправданно дорогим в пересчёте на запрос. Несколько задач, разделяющих одну инфраструктуру, — другая экономика. Планирование контура должно исходить из портфеля задач, а не из одного пилота.
Второй фактор — эффективность инференса. Правильно настроенный vLLM с батчингом и квантованием даёт кратно большую пропускную способность на том же железе, чем наивное развёртывание. Разница между «работает» и «работает эффективно» — это разница в количестве серверов, а значит, в основной капитальной статье.
Выбор модели: сильная не всегда нужная
Самая распространённая ошибка проектирования — взять максимально сильную модель, которая помещается в бюджет. Сильная модель требует больше памяти, больше вычислений на запрос, больше серверов при той же нагрузке. При этом для значительной части корпоративных задач — классификации, извлечения данных из документов, маршрутизации обращений — модель среднего размера или специально дообученная малая модель даёт сопоставимое качество при кратно меньших затратах.
| Класс задачи | Подходящий размер модели | Почему |
|---|---|---|
| Классификация, маршрутизация, извлечение полей | Малая или дообученная малая | Задача узкая, качество определяется дообучением, а не размером |
| Суммаризация, ответы по базе знаний | Средняя с RAG | Знание подаётся из индекса, модели нужно понимать контекст, а не хранить его |
| Генерация документов, сложные рассуждения | Крупная | Требуется общая языковая компетенция, малые модели ошибаются |
| Агенты с многошаговыми сценариями | Крупная с контролем стоимости | Многократные обращения к модели за один сценарий, стоимость растёт нелинейно |
Портфель моделей под портфель задач — нормальная архитектура: малые модели закрывают массовые задачи, крупная — редкие сложные. Это снижает требования к железу и упрощает обновление.
Обслуживание: люди дороже серверов
Контур требует людей: инженеров инфраструктуры, специалистов по инференсу, ответственных за модели и данные, дежурных для реакции на инциденты. В облаке эти функции включены в тариф; в контуре они — штатные единицы или контракт с подрядчиком. По нашему опыту, в горизонте нескольких лет затраты на людей сопоставимы с затратами на оборудование или превышают их.
Эти люди дефицитны: специалист, умеющий настроить инференс под нагрузку и диагностировать деградацию модели, — не системный администратор общего профиля. Компании либо растят таких специалистов внутри, либо привлекают подрядчика; выбранный вариант должен быть учтён в стоимости владения явно.
Обновление моделей: каждые несколько месяцев
Открытые модели обновляются часто, и новые версии заметно лучше. Компания, зафиксировавшая модель на момент запуска, через год работает на устаревшей версии с худшим качеством и, вероятно, худшей эффективностью инференса. Обновление — не разовое событие, а процесс: тестирование новой версии на эталонных наборах, сравнение с текущей, миграция без простоя, откат при регрессии.
Каждое обновление — это работа: дни инженеров, вычислительные ресурсы на тестирование, риск регрессии на задачах, которые не покрыты эталонным набором. Если модель дообучалась, дообучение нужно повторять на новой версии. Это регулярная статья затрат, которую нужно закладывать с частотой, соответствующей темпу обновлений.
Мониторинг и контроль стоимости
Промышленная система требует наблюдаемости: доступность сервиса, задержки, загрузка GPU, качество ответов на контрольных выборках, аномалии в запросах, стоимость на задачу и на подразделение. Без этого невозможно ни диагностировать деградацию, ни доказать эффект, ни распределить затраты между внутренними заказчиками.
Совокупность практик — версионирование моделей, обновление без простоя, мониторинг качества и стоимости, управление доступом — называется LLMOps. Это не дополнительная опция, а условие эксплуатации. Компании, которые запускают контур без LLMOps, получают систему, которая работает до первого инцидента и не может объяснить, сколько стоит.
| Статья | Что входит | Как ведёт себя при росте нагрузки | Что обычно забывают |
|---|---|---|---|
| Оборудование | GPU, серверы, сеть, хранение, резерв | Ступенчато: новый сервер при исчерпании | Резервирование, срок амортизации |
| Инженерная инфраструктура | Электропитание, охлаждение, стойки или ЦОД | Ступенчато | Запас серверной по мощности |
| Лицензии и ПО | ОС, инструменты инференса, векторная база, мониторинг | Почти не зависит | Поддержка вендора отечественного ПО |
| Люди | Инженеры, дежурство, ответственные за модели | Слабо зависит | Дежурство и замещение |
| Обновление моделей | Тестирование, дообучение, миграция | Не зависит | Повторное дообучение |
| Мониторинг и LLMOps | Наблюдаемость, эталонные наборы, журналирование | Слабо зависит | Стоимость хранения журналов |
| Простои и инциденты | Потери от недоступности, разбор | Растёт с критичностью | Стоимость часа простоя для бизнеса |
Смета контура, в которой нет строк «люди», «обновление моделей» и «мониторинг», описывает стоимость покупки, а не стоимость владения.
Как это выглядит на практике
Банк из первой сотни, ассистент по внутренним регламентам. Первоначальная смета включала серверы с GPU и лицензии на ОС. Через два квартала эксплуатации выяснилось: потребовались инженеры на поддержку, доработка серверной по электропитанию, обновление модели с повторным дообучением и построение мониторинга, без которого служба безопасности не давала разрешения на расширение. Итоговые затраты за год превысили первоначальную смету кратно, при этом сама система работала и приносила эффект. Проблема была не в системе, а в смете.
Производственная компания из ТЭК, анализ технической документации. Компания изначально спроектировала контур под портфель из нескольких задач: разбор документации, классификация заявок, ассистент для инженеров. Общая инфраструктура с малой моделью для классификации и средней для остального. Загрузка GPU стабильно высокая, стоимость запроса оказалась ниже облачной. Ключевое решение — не «одна задача — один контур», а общая платформа с планированием загрузки.
Сеть клиник, обработка обращений с персональными данными. Прямое размещение в облаке невозможно из-за 152-ФЗ и врачебной тайны. Вместо полного контура — гибрид: шлюз маскирования внутри периметра заменяет персональные данные на токены, обезличенный запрос уходит во внешнюю модель, ответ демаскируется на обратном пути. В контуре остались только шлюз и малая модель для задач, где даже обезличенные данные не должны покидать периметр. Затраты сократились в разы относительно полного размещения.
Что это значит для российской компании
Кому контур обязателен. Финансовые организации, медицина, ТЭК, госсектор, операторы КИИ — для них размещение данных за пределами периметра ограничено регуляторно: 152-ФЗ, отраслевые требования, режим КИИ. Для этих компаний вопрос не «облако или контур», а «как построить контур, который окупается». Для остальных контур — выбор, который должен быть обоснован загрузкой и стоимостью, а не только соображениями контроля.
Гибрид со шлюзом маскирования — рабочий компромисс. Если персональные данные можно обезличить до отправки в модель, значительная часть нагрузки может обрабатываться внешним сервисом, а в контуре остаются шлюз и модели для задач, где обезличивание невозможно или недостаточно. Шлюз — отдельный компонент с собственными требованиями к надёжности и аудиту, но его стоимость несопоставима со стоимостью полного контура. Применимость гибрида должна быть согласована с безопасностью и юристами под конкретные категории данных.
Отечественный стек закрывает базовые слои. Astra Linux и РЕД ОС как операционные системы, PostgreSQL как хранилище, Qdrant или аналоги как векторные базы, vLLM как инференс — стек, из которого собирается контур, состоит из отечественных и открытых компонентов. Ограничения — в оборудовании: доступность GPU и сроки поставки нужно учитывать в плане, а не только в смете.
Что делать: пошагово
-
Определите регуляторный статус задач. Для каждой задачи — какие данные обрабатываются, можно ли их обезличить, что допускает регулятор. Результат — разделение на «только контур», «гибрид с маскированием», «допустимо облако».
-
Соберите портфель задач, а не одну. Составьте перечень задач на год-два, оцените нагрузку каждой, спланируйте инфраструктуру под суммарную загрузку.
-
Подберите модели под задачи. Для каждой — минимальный размер, дающий требуемое качество. Проверьте на эталонной выборке. Портфель из малых и средних моделей с одной крупной — типовая конфигурация.
-
Посчитайте стоимость владения за год по всем статьям. Оборудование с амортизацией, инженерная инфраструктура, лицензии, люди, обновление моделей, мониторинг, резервирование, простои. Сравните с облачным или гибридным вариантом при той же нагрузке.
-
Спроектируйте LLMOps до запуска. Версионирование моделей, процедура обновления без простоя, мониторинг качества и стоимости, эталонные наборы для регрессионного тестирования, управление доступом и журналирование.
-
Запустите с минимальной конфигурации и измеряйте загрузку. Не покупайте под пиковую нагрузку через два года. Запуск на минимальном комплекте с мониторингом загрузки даёт данные для обоснованного расширения.
-
Закрепите владельца платформы и владельцев задач. Платформа — в ИТ, с бюджетом на эксплуатацию. Задачи — у операционных подразделений, с распределением стоимости платформы по фактическому потреблению.
Типичные ошибки
Смета только на железо. Почему это проблема: эксплуатация за год сопоставима с железом или больше. Что вместо: стоимость владения по всем статьям до решения о покупке.
Одна задача — один контур. Почему это проблема: инфраструктура недогружена, стоимость запроса высокая. Что вместо: платформа под портфель задач.
Самая сильная модель для всего. Почему это проблема: кратно больше железа при том же качестве на массовых задачах. Что вместо: модель под задачу, портфель моделей.
Фиксация модели навсегда. Почему это проблема: через год — устаревшее качество и эффективность. Что вместо: процесс обновления с эталонными наборами и откатом.
Полный контур там, где достаточно гибрида. Почему это проблема: затраты в разы выше необходимого. Что вместо: анализ применимости маскирования по категориям данных, согласованный с безопасностью.
Как понять, что вы на верном пути
- Для каждой задачи определён регуляторный режим: контур, гибрид, облако.
- Инфраструктура спланирована под портфель задач с оценкой суммарной загрузки.
- Модели подобраны под задачи по эталонным выборкам, а не по принципу «самая сильная».
- Стоимость владения посчитана за год по всем статьям, включая людей, обновление и мониторинг.
- Есть процедура обновления модели с тестированием и откатом.
- Загрузка GPU, качество ответов и стоимость на задачу видны в мониторинге.
- Владелец платформы и владельцы задач названы, у каждого есть бюджет.
Вопросы, которые нам задают
При какой нагрузке контур становится выгоднее облака?
Универсального порога нет: зависит от размера модели, эффективности инференса и стоимости людей в конкретной компании. Практический метод: посчитать стоимость владения контуром за год и разделить на ожидаемое число запросов, сравнить с облачной ценой за тот же объём. При портфеле из нескольких задач с постоянной нагрузкой контур обычно оказывается дешевле; при одной задаче с нерегулярной нагрузкой — дороже. Для регулируемых отраслей сравнение теряет смысл: контур обязателен, вопрос в его эффективности.
Можно ли начать с гибрида и перейти на полный контур?
Да, и это разумная последовательность. Шлюз маскирования и малая модель в контуре — первый шаг, который даёт опыт эксплуатации и данные о реальной нагрузке. Полный контур строится на этих данных, а не на прогнозах. Важно, чтобы архитектура гибрида изначально допускала перенос задач внутрь без переписывания приложений.
Как обосновать бюджет на людей и LLMOps перед финансовым директором?
Как страховку от простоя и как условие измеримости. Без людей система остановится при первом серьёзном инциденте, и стоимость простоя будет выше годовой стоимости команды. Без мониторинга невозможно доказать эффект, а значит, невозможно обосновать продолжение. Финансовому директору нужны две величины: стоимость эксплуатации за год и стоимость простоя за неделю. Сопоставление обычно снимает вопрос.
Сколько GPU нужно для старта?
Меньше, чем кажется. Малая или средняя модель под массовые задачи с эффективным инференсом работает на одном сервере с несколькими GPU; резервирование — второй такой же. Закупка «с запасом на два года» — самая дорогая ошибка на старте, потому что через два года оборудование будет другим, а запас всё это время простаивал. Купите минимум, измерьте загрузку за квартал, расширяйте по факту.