Как учитывать расходы на разные ИИ-модели: практическое руководство

Из чего складываются расходы на ИИ-модели

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

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

Первый уровень расходов — это стоимость доступа к модели. Если вы используете внешний сервис вроде OpenAI API, Anthropic или YandexGPT, вы платите за токены. Токен — это фрагмент текста, который модель обрабатывает. В русском языке один токен примерно равен 3-4 символам, в английском — одному слову. Каждый запрос к модели включает входные токены (ваш промпт) и выходные токены (ответ модели). Стоимость входных токенов обычно ниже, чем выходных, потому что генерация текста требует больше вычислительных ресурсов.

Второй уровень — инфраструктурные расходы. Если вы разворачиваете модель на собственных серверах или арендуете облачные мощности, появляются затраты на вычислительные ресурсы. GPU стоят дорого, их аренда в облаке тоже. Например, для запуска модели уровня GPT-4 или Llama 70B нужны серверы с несколькими мощными видеокартами, что обходится в десятки тысяч рублей в месяц только за железо.

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

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

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

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

Рассмотрим конкретный пример. Компания внедряет чат-бота на базе GPT-4 для поддержки клиентов. Средняя длина запроса клиента — 100 токенов, средняя длина ответа — 300 токенов. Стоимость входных токенов — 0,03 доллара за 1000 токенов, выходных — 0,06 доллара. За один диалог компания платит примерно 0,021 доллара или около 2 рублей. Если в день обрабатывается 1000 запросов, это 2000 рублей в день, 60 тысяч рублей в месяц. Добавьте сюда хранение истории переписки, логирование для аналитики, инфраструктуру для интеграции с CRM — и бюджет вырастает до 100-120 тысяч рублей.

Разница между облачными сервисами и собственной инфраструктурой

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

Облачный API — это модель pay-as-you-go. Вы платите только за то, что используете. Не нужно покупать серверы, нанимать DevOps-команду, настраивать мониторинг. Достаточно зарегистрироваться, получить ключ доступа и начать отправлять запросы. Стоимость прозрачна и предсказуема на начальном этапе. Но есть нюансы.

• Цена за токен фиксирована и не зависит от объема. Если вы обрабатываете миллион запросов в месяц, вы платите столько же за токен, сколько и при тысяче запросов.
• Нет контроля над производительностью. Если сервис перегружен, ваши запросы могут обрабатываться медленнее.
• Данные покидают периметр компании. Для некоторых отраслей это неприемлемо по соображениям безопасности или регуляторных требований.
• Зависимость от внешнего провайдера. Если API недоступен, ваш продукт перестает работать.

Собственная инфраструктура — это модель с высокими начальными затратами, но потенциально более низкими операционными расходами при больших объемах. Вы покупаете или арендуете серверы, разворачиваете модель, настраиваете окружение. Это дает полный контроль над данными, производительностью и доступностью. Но требует экспертизы.

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

Промежуточный вариант — аренда облачных GPU для развертывания собственной модели. Вы арендуете виртуальные серверы с видеокартами, устанавливаете модель и платите за время работы инстанса. Это дешевле, чем API-токены при больших объемах, и гибче, чем покупка железа. Но требует технических навыков и расходов на администрирование.

Компания с нагрузкой 10 миллионов токенов в день может платить 300 тысяч рублей в месяц за API или 150 тысяч за аренду GPU-инстанса плюс 50 тысяч на DevOps. Экономия становится заметной после преодоления порога в 5-7 миллионов токенов ежедневно.

Внешние сервисы vs собственная инфраструктура: разница в учёте

Учет затрат на внешние API и собственную инфраструктуру строится по-разному. В первом случае вы работаете с переменными затратами, привязанными к потреблению. Во втором — с постоянными затратами, которые распределяются на объем использования.

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

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

Для собственной инфраструктуры учет строится через распределение постоянных затрат. Вы платите за серверы и электричество независимо от нагрузки. Задача — разнести эти расходы на конкретные проекты пропорционально их использованию.

Основная метрика здесь — время использования ресурсов. Если у вас один GPU-сервер и три проекта, нужно отследить, сколько времени каждый проект занимает ресурс. Проект, который генерирует 70% запросов, должен нести 70% затрат. Проблема в том, что GPU работает параллельно, и точное разделение времени не всегда очевидно.

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

Как построить учет для гибридной модели

Многие компании используют гибридный подход: часть задач решают через внешние API, часть — на собственной инфраструктуре. Например, сложные запросы отправляют в GPT-4, простые обрабатывают локальной моделью. Или используют внешнюю модель для прототипирования, а потом мигрируют на собственную.

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

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

• Проект или продукт
• Команда или подразделение
• Тип задачи (генерация текста, анализ данных, классификация)
• Модель (GPT-4, Claude, Llama, YandexGPT)
• Источник (внешний API или собственная инфраструктура)

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

Третий шаг — автоматизировать сбор данных. Ручной экспорт отчетов из разных систем приводит к ошибкам и отнимает время. Лучше настроить автоматическую интеграцию: API провайдеров обычно предоставляют эндпоинты для получения данных о потреблении, собственная инфраструктура может отправлять метрики в систему мониторинга вроде Prometheus или Grafana.

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

Как связать потребление с конкретными проектами и командами

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

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

Первый способ разделения — технический. Создайте отдельные ключи доступа или экземпляры модели для каждого проекта. Если используете OpenAI API, выпустите отдельные ключи для каждой команды и настройте лимиты потребления. Если разворачиваете модель самостоятельно, запустите несколько инстансов с раздельным логированием. Это требует дополнительных усилий на этапе настройки, но упрощает учет.

Второй способ — логический. Используйте метаданные в запросах. Каждый запрос к модели может содержать дополнительные поля: идентификатор проекта, название команды, тип задачи. Эти данные попадают в логи и позволяют агрегировать расходы по нужным срезам. Например, в Python при работе с OpenAI API вы можете передавать кастомный параметр user, который будет отображаться в дашборде провайдера.

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

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

Проблема распределения общих ресурсов

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

Стандартный подход — распределять пропорционально использованию. Если проект А генерирует 60% запросов, он несет 60% общих расходов. Если проект Б занимает 40% времени GPU, ему приписывают 40% стоимости сервера. Это справедливо и прозрачно, но требует точных данных о потреблении.

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

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

Учёт токенов: методы подсчёта и распределения

Токен — базовая единица расчета для большинства облачных ИИ-сервисов. Понимание того, как токены учитываются и как их количество связано с реальными расходами, дает контроль над бюджетом.

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

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

Пример: вы отправляете запрос из 200 токенов и получаете ответ на 300 токенов. Если стоимость входных токенов 0,03 доллара за 1000, а выходных — 0,06 доллара, то один запрос стоит (200 × 0,03 / 1000) + (300 × 0,06 / 1000) = 0,006 + 0,018 = 0,024 доллара или примерно 2,4 рубля.

Проблема в том, что размер запроса не всегда очевиден. Если вы используете систему с контекстом (например, чат-бота, который помнит предыдущие сообщения), каждый новый запрос включает всю историю диалога. Диалог из 10 сообщений может содержать несколько тысяч токенов контекста, которые передаются каждый раз заново.

Как оптимизировать потребление токенов

Снижение расхода токенов напрямую снижает стоимость использования модели. Существует несколько проверенных методов оптимизации.

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

Второй метод — кэширование. Если одинаковые запросы повторяются часто, сохраняйте ответы и переиспользуйте их. Некоторые провайдеры, такие как Anthropic, предлагают встроенное кэширование промптов: если часть запроса не меняется, она не тарифицируется повторно.

Третий метод — использование более простых моделей для простых задач. Не все запросы требуют GPT-4 или Claude Opus. Для классификации текста, извлечения ключевых слов, простых ответов подойдут менее мощные и более дешевые модели вроде GPT-3.5 или локальные модели типа Llama.

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

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

Шестой метод — ограничение длины ответа. Параметр max_tokens позволяет задать максимальное количество токенов в ответе. Если вам нужен короткий ответ, установите лимит на 100-200 токенов вместо дефолтных 1000-2000. Модель не будет генерировать лишнее.

Учет токенов на уровне проекта

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

Введите метрику стоимости операции. Например, если ваш чат-бот обрабатывает запросы клиентов, посчитайте среднюю стоимость одного обращения. Если система генерирует контент, посчитайте стоимость одной статьи или поста. Это дает понимание реальной экономики продукта.

Пример: чат-бот службы поддержки обрабатывает 5000 запросов в месяц. Общий расход токенов — 10 миллионов. Стоимость — 50 тысяч рублей. Средняя стоимость одного обращения — 10 рублей. Если при этом бот решает проблему клиента без участия оператора в 60% случаев, экономия на операторах составляет 150-200 тысяч рублей в месяц (стоимость работы операторов). ROI очевиден.

Другой пример: система генерации контента для соцсетей расходует 20 миллионов токенов в месяц, создавая 1000 постов. Стоимость — 100 тысяч рублей. Стоимость одного поста — 100 рублей. Если копирайтер за эту же работу берет 300-500 рублей за пост, экономия — 200-400 тысяч рублей в месяц.

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

Разработка внутренних тарифов на ИИ-сервисы

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

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

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

Как рассчитать справедливый тариф

Справедливый тариф должен отражать реальную стоимость операции, но быть округленным для удобства расчетов. Берите данные за последние 2-3 месяца и рассчитайте среднюю стоимость.

Пример расчета для API-модели:

• Средний размер входного запроса: 150 токенов
• Средний размер выходного ответа: 250 токенов
• Стоимость входных токенов: 0,03 доллара за 1000
• Стоимость выходных токенов: 0,06 доллара за 1000
• Расчет: (150 × 0,03 / 1000) + (250 × 0,06 / 1000) = 0,0195 доллара ≈ 1,95 рубля
• Округленный тариф: 2 рубля за запрос

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

Пример для самостоятельного развертывания модели:

• Месячная стоимость GPU-сервера (аренда): 50 тысяч рублей
• Электричество, охлаждение, администрирование: 15 тысяч рублей
• Прогноз месячного объема запросов: 100 тысяч
• Постоянные затраты на один запрос: (50 + 15) / 100 000 = 0,00065 рубля
• Переменные затраты (электричество, лицензии): 0,1 рубля за запрос
• Итоговый тариф: 0,00065 + 0,1 ≈ 0,11 рубля за запрос или 1,1 рубля за 10 запросов

Тариф нужно периодически пересматривать. Если реальное потребление выросло, постоянные затраты снизятся на один запрос. Если потребление упало, тариф нужно поднять, иначе вы будете нести убытки.

Дифференцированные тарифы для разных моделей и задач

Одного универсального тарифа недостаточно, если компания использует разные модели. GPT-4 дороже GPT-3.5, локальная модель дешевле облачной. Тарифы должны это отражать.

Создайте прайс-лист по моделям:

• GPT-4: 2,5 рубля за запрос
• GPT-3.5: 0,5 рубля за запрос
• Claude Opus: 3 рубля за запрос
• Локальная модель Llama: 0,1 рубля за запрос

Дифференцированные тарифы мотивируют команды выбирать экономичные варианты. Если для простой классификации текста GPT-3.5 дает такой же результат, как GPT-4, команда выберет дешевый вариант. Если нужна максимальная качество, команда согласится переплатить.

Кроме того, можно установить разные тарифы по типам задач. Генерация текста требует больше ресурсов и генерирует более длинные ответы, поэтому может быть дороже. Классификация текста — проще и дешевле.

Еще один параметр — времяотклика. Приоритетные запросы, которые обрабатываются в реальном времени, могут стоить дороже, чем фоновые. Это справедливо при использовании собственной инфраструктуры, когда пиковые нагрузки требуют резервной мощности.

Интеграция с учётными системами компании

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

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

Первый уровень интеграции — синхронизация данных. Счета от провайдеров ИИ-услуг нужно автоматически импортировать в бухгалтерскую систему. Вручную выписывать каждый счет неэффективно и чревато ошибками. Современные системы учета (1C, Финолог, облачные решения типа Yandex.Metrica) поддерживают интеграцию через API или импорт CSV.

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

Система учета получает информацию: "10 октября, проект X, 5000 токенов, 100 рублей". Она автоматически создает запись в центре затрат проекта X, кодирует расход как "услуги в области информационных технологий" и привязывает к нужному периоду. Никакой ручной работы.

Третий уровень — интеграция с системой бюджетирования. Если компания планирует расходы на проекты, ИИ-расходы должны быть частью этого плана. Система должна показывать, насколько текущие расходы отклоняются от бюджета. Если проект потребляет токены быстрее, чем планировалось, система должна это зафиксировать и предупредить ответственного.

На практике интеграция выглядит так:

1. Приложение отправляет запрос к модели с метатегом: project_id=12345, team=Data Science.
2. API-провайдер логирует запрос и его стоимость.
3. Ночью интеграционный сервис выгружает данные из провайдера и преобразует их в формат компании.
4. Данные попадают в учетную систему и автоматически распределяются по центрам затрат.
5. Финдиректор видит в своем дашборде: "Data Science потребил 50 тысяч рублей в этом месяце, на 10% выше бюджета".
6. На основе этого принимается решение: ограничить потребление, перенести часть задач на дешевую модель или пересмотреть бюджет.

Какие системы выбрать

Выбор систем зависит от размера компании и сложности структуры.

Для малого бизнеса (до 50 сотрудников) достаточно простого решения: отслеживание расходов через Google Sheets или простую базу данных. Экспортируете счета из провайдера в CSV, импортируете в таблицу, вручную распределяете по проектам. Это занимает час в неделю, но работает.

Для среднего бизнеса (50-500 сотрудников) нужна более серьезная инструмент. Вариант — встроенный функционал в существующей системе управления проектами (Jira, Asana) или системе бухучета (1C, SAP). Вариант — специализированная система для управления облачными расходами типа Finops платформ (например, CloudZero, Kubecost).

Для крупного бизнеса (от 500 сотрудников) нужна комплексная система с API-интеграциями, многоуровневым распределением затрат, прогнозированием и оптимизацией. Некоторые компании разрабатывают собственную систему, встраивая ее в ERP.

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

Распределение расходов по продуктам и подразделениям

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

Распределение по подразделениям работает, только если установлены правила. Что считается расходом конкретного подразделения? Как распределяются общие расходы на инфраструктуру?

Правило 1: прямые расходы относятся на подразделение, которое их инициировало. Если маркетолог генерирует текст через API, стоимость относится на маркетинг. Если разработчик тестирует модель, стоимость относится на разработку.

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

Правило 3: расходы на разработку и оптимизацию относятся на подразделение, которое запросило работу. Если инженер написал скрипт для ускорения работы модели, расходы на его работу относятся на подразделение, которое попросило оптимизацию.

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

Система внутреннего чартбэка

Чартбэк (chargeback) — это система, при которой подразделения платят друг другу (или центральной ИТ-функции) за используемые услуги. Это мотивирует экономить и использовать ресурсы ответственно.

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

Маркетинг потребил 60% вычислительных ресурсов, поэтому несет 60% от 100 тысяч рублей = 60 тысяч. Продажи потребили 40%, несут 40 тысяч. Деньги переводятся со счета подразделений на счет ИТ, что компенсирует расходы центра на инфраструктуру.

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

Но чартбэк не всегда справедлив. Некоторые подразделения могут быть вынуждены использовать ИИ (например, поддержка клиентов должна отвечать на запросы в реальном времени), в то время как другие могут выбирать. Это может привести к напряженности.

Решение — комбинированная система. Фиксированная часть расходов распределяется поровну (все платят базовый взнос), переменная часть распределяется по чартбэку (платите в зависимости от потребления). Это справедливо и мотивирует оптимизировать только переменные расходы, а не отказываться от необходимого использования.

Расчёт себестоимости при использовании общих ИИ-ресурсов

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

Проблема в том, что ИИ-ресурсы часто общие. Одна модель обслуживает несколько продуктов. Как справедливо распределить затраты?

Пример: компания продает три сервиса, которые используют одну модель GPT-3.5. Сервис A обрабатывает 40% запросов, сервис B — 35%, сервис C — 25%. Месячный счет за API — 50 тысяч рублей. Как распределить?

Вариант 1: пропорционально объему. Сервис A несет 20 тысяч, B — 17,5 тысяч, C — 12,5 тысяч. Это просто и справедливо, если предположить, что все запросы примерно одинакового размера.

Вариант 2: по выручке. Если сервис A приносит 50% выручки компании, он несет 50% расходов на ИИ. Это справедливо, если нужно оценить каждый продукт как самостоятельный бизнес.

Вариант 3: по маржинальности. Дополнительный запрос к модели обходится в определенную сумму (переменные затраты). Это значит, что первые несколько запросов несут всю стоимость инфраструктуры (постоянные затраты), а остальные — только переменные. Справедливо относить постоянные затраты на основной продукт, который требует наибольшей надежности, а остальные — на переменные расходы.

Вариант 4: по времени обработки. Если один запрос обрабатывается дольше, он потребляет больше вычислительных ресурсов. Можно взвешивать расходы по времени вместо просто количества запросов.

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

Учет себестоимости в ценообразовании

Когда вы знаете себестоимость продукта с учетом ИИ-расходов, вы можете правильно его оценить. Цена должна перекрывать себестоимость и приносить прибыль.

Пример расчета для SaaS-сервиса с ИИ:

• Себестоимость обслуживания одного клиента в месяц: 200 рублей (зарплата поддержки, инфраструктура, амортизация)
• Среднее потребление ИИ-сервисов одним клиентом в месяц: 100 тысяч токенов
• Стоимость этих токенов: 50 рублей
• Итого себестоимость: 250 рублей
• Желаемая маржа: 70% (стандарт для SaaS)
• Минимальная цена: 250 / 0.3 = 833 рубля в месяц

Если вы установите цену ниже 833 рублей, каждый клиент будет убыточен. Если выше — начнется накопление прибыли. Это основание для ценообразования.

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

Как меняются затраты при масштабировании и росте нагрузки

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

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

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

При использовании собственной инфраструктуры картина сложнее. Постоянные затраты остаются фиксированными до момента, когда текущие мощности перестают справляться. Затем наступает скачок — нужно докупать или арендовать дополнительные серверы.

Пример: компания арендует GPU-сервер за 80 тысяч рублей в месяц. Сервер обрабатывает до 500 тысяч запросов в месяц. При нагрузке в 300 тысяч запросов стоимость одного запроса составляет 0,27 рубля. При 500 тысячах — 0,16 рубля. Стоимость падает с ростом нагрузки, потому что постоянные расходы распределяются на больший объем.

Но когда нагрузка достигает 600 тысяч запросов, одного сервера недостаточно. Нужен второй сервер за те же 80 тысяч рублей. Теперь постоянные расходы — 160 тысяч. Стоимость одного запроса снова подскакивает до 0,27 рубля, пока новый объем не вырастет до миллиона запросов.

Пиковая нагрузка как скрытый фактор затрат

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

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

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

Еще один подход — кэширование популярных запросов. Если 20% запросов генерируют 80% нагрузки и эти запросы повторяющиеся, кэш снижает реальное потребление ресурсов без ущерба для пользователей.

Эффект масштаба при переходе на собственную инфраструктуру

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

Точка окупаемости зависит от объема. Если вы обрабатываете 5 миллионов токенов в день через OpenAI API, это стоит примерно 150 долларов в день или 4500 долларов в месяц. Собственный сервер с GPU обойдется в 1500-2000 долларов в месяц аренды плюс операционные расходы. Экономия начинается при нагрузке выше 3-4 миллионов токенов в день.

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

Кроме того, собственная инфраструктура менее гибка. Если нагрузка резко упадет, вы продолжите платить за арендованные серверы. API позволяет масштабироваться вниз мгновенно — если запросов стало меньше, счет уменьшается автоматически.

Типичные ошибки при учёте расходов на ИИ

Учет расходов на ИИ — новая область для большинства компаний. Ошибки здесь естественны, но их можно избежать, если знать распространенные паттерны.

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

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

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

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

Третья ошибка — планирование по средним значениям. Средняя нагрузка в 100 тысяч запросов в день может скрывать пики в 300 тысяч. Если инфраструктура рассчитана на среднее, она будет падать в пиковые часы.

Решение — планировать по 95-му перцентилю. Посмотрите на распределение нагрузки за последние несколько месяцев, найдите уровень, который не превышается в 95% случаев, и рассчитывайте мощности под него. Это дает запас прочности.

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

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

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

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

Ошибки в распределении затрат

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

Ошибка — распределение всех расходов пропорционально выручке. Это кажется справедливым, но не учитывает реальное потребление. Продукт, который приносит 50% выручки, но потребляет только 10% ИИ-ресурсов, будет нести завышенные расходы.

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

Ошибка — отсутствие правил для общих ресурсов. Если несколько проектов используют одну модель, но правила распределения затрат не установлены, каждая команда будет спорить, кто должен платить больше.

Решение — документировать методику распределения и согласовать ее со всеми заинтересованными сторонами. Прозрачность устраняет конфликты.

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

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

Чему научиться на чужих ошибках

Компании, которые уже внедрили ИИ и прошли через болезненные уроки, выработали несколько принципов.

• Начинайте с простого учета, но планируйте сложный. Даже если сейчас достаточно таблицы, закладывайте возможность масштабирования.
• Автоматизируйте рано. Ручной учет работает при десятках запросов в день, но разваливается при тысячах.
• Не экономьте на мониторинге. Система предупреждения о превышении лимитов окупается с первого предотвращенного инцидента.
• Вовлекайте команды в управление расходами. Когда разработчики видят стоимость своих экспериментов, они начинают думать об оптимизации.
• Документируйте решения. Через полгода вы забудете, почему установили именно такой тариф или выбрали именно такую методику распределения.

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

Прозрачный учет превращает расходы на ИИ из черного ящика в управляемый актив. Когда вы видите, куда идут деньги и какую ценность они создают, технология перестает быть экспериментом и становится частью операционной эффективности бизнеса.