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

Стоимость GenAI-системы — это не только сколько стоит вызвать модель. Это инфраструктура, эксплуатация, безопасность, наблюдаемость, разработка, интеграции, поддержка пользователей и постоянные изменения вокруг моделей. Именно поэтому «мы поднимем open-source модель сами, будет дешевле» часто оказывается правдой только на первом слайде презентации.

Из чего складывается стоимость GenAI в продакшене

Типовая GenAI-система состоит не из одной модели. Даже если бизнес-задача звучит просто, например, сделать Q&A чат-бота по документам, внутри быстро появляются:

• backend-сервис (API)

• модель или несколько моделей

• RAG: индексация документов, эмбеддинги, векторный поиск

• хранилище документов

• авторизация и права доступа

• модерация и guardrails

• трассировка запросов

• мониторинг качества

• логирование ошибок

• рейт-лимиты, очереди и ретраи

• CI/CD

• регламент обновления моделей

• поддержка пользователей и команд, которые интегрируются с этим сервисом

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

Цена за токен — заметный, но не единственный расход

Если использовать Yandex Cloud AI Studio, стоимость зависит от режима работы модели и количества токенов: входных, исходящих, кешированных и токенов инструментов. Это уже важная деталь: один и тот же пользовательский сценарий может стоить по-разному в зависимости от длины промпта, длины ответа, истории диалога и использования tools.

Например, в синхронном режиме YandexGPT Pro 5.1 стоит 0,8 ₽ за 1000 входящих токенов и 0,8 ₽ за 1000 исходящих токенов с НДС. YandexGPT Lite стоит 0,2 ₽ за 1000 входящих и 0,2 ₽ за 1000 исходящих токенов. DeepSeek V3.2 в AI Studio стоит 0,5 ₽ за 1000 входящих токенов и 0,8 ₽ за 1000 исходящих токенов.

Допустим, у нас есть внутренний ассистент, который обрабатывает 1 млн запросов в месяц. Средний запрос:

• 1000 входящих токенов

• 500 исходящих токенов

Тогда примерная стоимость генерации:

На этом этапе возникает соблазм сказать, что Lite дешевле Pro в 4 раза и нужно брать эту модель. Но если Lite отвечает хуже, чаще требует повторных запросов, хуже следует инструкциям, хуже работает с длинным контекстом или создаёт больше ошибок для пользователей, реальная стоимость может быть выше. Дешёвый токен может привести к дорогому бизнес-процессу.

Покупка GPU vs оплата за токены

Другой популярный подход — поднять open-source модель самостоятельно на своей инфраструктуре. Например, через vLLM, TGI или другой serving-стек.

В Yandex DataSphere конфигурация g2.8 с 8 GPU A100 стоит 4 401,83808 ₽ в час. При расчёте 720 часов в месяц это примерно:

4 401,84 ₽ × 720 ≈ 3 169 323 ₽ / месяц

Конфигурация g2.1 с 1 GPU A100 стоит 550,22976 ₽ в час, а g1.1 с 1 GPU V100 — 341,52192 ₽ в час. Цены DataSphere для региона Россия указаны с НДС.

На первый взгляд, 8×A100 за ~3,17 млн ₽/месяц может выглядеть конкурентно, если у вас большой объём трафика. Но это только compute. Дальше нужно добавить:

• Kubernetes или другой runtime

• хранилище для моделей и образов (container registry)

• observability стек (наблюдаемость)

• сетевую инфраструктуру

• инженерную команду

а также процессы вокруг:

• обновления моделей

• тестирования качества

• безопасности

• работу с деградациями и инцидентами

DataSphere отдельно тарифицирует хранение моделей, Docker-образов, дисков, датасетов и других артефактов; например, хранение модели внутри DataSphere сверх бесплатных лимитов стоит 13,08 ₽ за 1 ГБ в месяц.

То есть self-hosting может быть дешевле на большом масштабе. Но он редко бывает дешевле сам по себе. Он становится выгодным, когда у компании уже есть сильная инфраструктурная команда, понятный объём нагрузки и реальная потребность контролировать serving, latency, безопасность и модельный стек.

Главный скрытый расход — ФОТ

В России стоимость инженерной команды ниже, чем в США, но она всё равно быстро становится одной из основных категорий расходов. По данным Dream Job, средняя зарплата ML Engineer в России в 2026 году — 185 000 ₽ на руки, типичный диапазон — 140 000—230 000 ₽, а в Москве среднее значение указано как 260 000 ₽. Другой обзор по рынку ML-инженеров указывает ориентиры по грейдам: Middle — около 160 000—200 000 ₽, Senior — 280 000—350 000 ₽, Lead — 360 000—450 000 ₽ в зависимости от региона и формата работы.

Но для продакшен GenAI вам обычно нужен не один ML Engineer. Минимальный состав может выглядеть так:

Даже маленькая команда из 2—3 сильных инженеров может стоить компании заметно больше, чем API-вызовы модели. Особенно если считать не только зарплату на руки, а полную стоимость сотрудника: налоги, оборудование, менеджмент, найм, отпуска, простои, коммуникации и стоимость ошибок.

Именно здесь часто ломается наивная математика: API стоит 1 млн ₽ в месяц, а self-hosting на GPU — 3 млн ₽. Значит API дешевле.

Или наоборот: GPU стоит 3 млн ₽ в месяц, а API при нашем объёме стоит 5 млн ₽. Значит self-hosting дешевле.

Обе оценки неполные. Нужно считать людей, эксплуатацию, риски и качество.

Доступ к LLM через API vs self-hosting

Упрощённо выбор выглядит так.

Доступ к LLM через API

Выгоднее если вы только запускаете продукт, нагрузка непредсказуема, команда маленькая, а главная задача — быстро проверить гипотезу. В этом случае YandexGPT, DeepSeek или другие модели через API позволяют не строить всю инфраструктуру с нуля.

Плюсы:

• быстрый старт

• не нужно управлять GPU

• проще масштабироваться на раннем этапе

• меньше эксплуатационной нагрузки

• проще считать стоимость на уровне токенов

Минусы:

• зависимость от провайдера

• ограничения по моделям и настройкам

• меньше контроля над latency (временем отклика)

• сложнее оптимизировать serving под свой сценарии и тип нагрузки

• возможные ограничения по данным и комплаенсу

Self-hosting моделей

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

Плюсы:

• больше контроля

• можно оптимизировать serving

• можно выбирать open-source модели

• можно строить собственный роутинг и механизмы кэширования

• потенциально ниже стоимость за токен на большом объёме

Минусы:

• высокая сложность

• нужен опыт с GPU-инфраструктурой

• нужны SRE-практики

• нужно самим решать инциденты

• нужно самим обновлять модели

• нужно самим строить evals и release gates

Скрытые расходы, о которых забывают

Наблюдаемость

Для обычного backend-сервиса достаточно latency, error rate, throughput и логов. Для LLM-системы этого мало.

Нужно понимать:

• сколько токенов потребляется

• какие промпты дают плохие ответы

• где растёт latency

• где модель галлюцинирует

• какие пользователи повторяют запросы

• какие инструменты вызываются

• какие документы попадают в контекст

• как меняется качество после обновления модели

Без этого система становится чёрным ящиком: деньги тратятся, пользователи жалуются, а команда не понимает, где проблема.

Обновление моделей

Модель — это не статичная библиотека. Провайдеры обновляют версии, меняют поведение, добавляют новые режимы, снимают старые версии с поддержки.

Каждое обновление требует:

• регрессионного тестования

• сравнения качества

• проверки промптов

• проверки latency

• проверки стоимости

• коммуникации с пользователями

• rollback-плана

Если этого нет, можно обновить модель и сломать upstream-команды.

Безопасность

В корпоративном контексте вопрос не только в том, где дешевле токен.

Нужно отвечать на вопросы:

• какие данные уходят в модель

• логируются ли запросы

• где хранятся трейсы запросов

• можно ли отправлять персональные данные

• как работает маскирование PII и других данных

• кто имеет доступ к истории запросов

• можно ли использовать внешние tools

• как аудитить действия агента

Это не бесплатная часть системы. Её кто-то должен проектировать, внедрять и поддерживать.

Качество

Стоимость плохого ответа может быть выше стоимости токенов.

Например, если модель помогает бухгалтерии, юристам, поддержке или инженерам, ошибка может привести к:

• потере времени

• неправильному решению

• ручной перепроверке

• недоверию пользователей

• отказу от продукта

• инциденту безопасности

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

Как посчитать полную стоимость GenAI-системы

Хорошая формула выглядит не так:

TCO = цена токенов

где TCO — это Total Cost of Ownership, т. е. полная стоимость владения.

А примерно так:

TCO =
  стоимость inference
+ стоимость инфраструктуры
+ стоимость хранения
+ стоимость сети
+ стоимость разработки
+ стоимость эксплуатации
+ стоимость observability
+ стоимость безопасности
+ стоимость обновления моделей
+ стоимость ошибок

Для managed API основная переменная часть — токены. Для self-hosting — GPU, инфраструктура и команда.

Практический подход:

1. Посчитать ожидаемый объём запросов.

2. Разделить входные и исходящие токены.

3. Посчитать стоимость для 2—3 моделей.

4. Добавить RAG: embeddings, хранилища, поиск.

5. Добавить observability и логи.

6. Оценить стоимость команды.

7. Оценить стоимость поддержки и инцидентов.

8. Сравнить API и self-hosting не на демо, а на горизонте 6—12 месяцев.

Пример: внутренний AI-ассистент

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

Параметры:

• 1 000 активных пользователей

• 30 запросов на пользователя в месяц

• 30 000 запросов в месяц

• 1 500 входящих токенов

• 700 исходящих токенов

Для YandexGPT Pro 5.1:

Вход: 1500 / 1000 × 0,8 ₽ = 1,2 ₽
Выход: 700 / 1000 × 0,8 ₽ = 0,56 ₽
Итого: 1,76 ₽ за запрос

30 000 × 1,76 ₽ = 52 800 ₽ / месяц

Для YandexGPT Lite:

Вход: 1500 / 1000 × 0,2 ₽ = 0,3 ₽
Выход: 700 / 1000 × 0,2 ₽ = 0,14 ₽
Итого: 0,44 ₽ за запрос

30 000 × 0,44 ₽ = 13 200 ₽ / месяц

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

Но если это уже не 30 000, а 3—10 млн запросов в месяц, математика меняется. Тогда имеет смысл отдельно смотреть на кэширование, роутинг запросов, batch-режимы, более дешёвые модели для простых задач и self-hosting.

Вывод

Главная ошибка при оценке GenAI систем — сравнивать только цену токена или часа за аренду GPU.

Для прототипа это нормально. Для продакшена — нет.

Managed API может быть дороже на единицу inference, но дешевле по TCO (полной стоимости владения), если экономит месяцы разработки и эксплуатации. Self-hosted open-source модель может быть дешевле на большом объёме, но только если у вас есть команда, инфраструктура и зрелые процессы.

Правильный вопрос звучит не так:

Какая модель дешевле?

А так:

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

И почти всегда ответ зависит не от одной цены в прайсе, а от масштаба, команды и зрелости компании.

P.S. Про разработку в эпоху ИИ, агентов и LLM ?? тут