Стоимость инфраструктуры ИИ важнее, чем цена одной только модели

Почему счет за модель — это еще не весь счет

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

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

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

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

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

Откуда берутся дополнительные расходы

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

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

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

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

Мониторинг — еще одна тихая статья расходов. Если продукт зарабатывает, команде нужны оповещения до того, как пользователи начнут писать, что что-то сломалось. Метрики, дашборды, отслеживание ошибок, проверки доступности и audit trail тоже стоят денег. Можно уменьшить этот счет за счет более компактного стека или self-hosted-инструментов, но полностью отказаться от него нельзя, если нужен надежный продукт.

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

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

Поэтому спор «цена модели против инфраструктуры» для большинства команд — неправильный. Они связаны. Дешевая модель внутри дорогого процесса все равно может приносить убыток на каждой задаче.

Проследите один запрос от начала до конца

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

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

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

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

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

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

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

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

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

Простой пример с маржой

Ассистент для поддержки обрабатывает 20 000 чатов в месяц. На бумаге счет за модель выглядит безобидно. Если каждый чат стоит примерно $0,01 в токенах, месячные расходы на модель составляют всего $200.

Такой показатель делает продукт похожим на прибыльный. Если 100 клиентов платят по $15 в месяц, выручка составляет $1 500. На первый взгляд кажется, что запас очень большой.

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

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

Теперь подставим простые цифры. Логи и хранилище добавляют $180 в месяц. Повторы, воркеры очереди и фоновые задачи — еще $120. Итого общая сумма уже $500 вместе с $200 за модель.

Затем команда добавляет легкий слой проверки. Небольшая команда проверяет только 5% чатов, но люди все равно стоят денег. Один part-time reviewer и инструмент проверки вместе добавляют $700 в месяц.

Теперь реальная месячная стоимость составляет не $200, а $1 200. Если разделить это на 20 000 чатов, получится $0,06 за чат.

Сначала это все еще кажется нормальным по сравнению с выручкой в $1 500. Но маржа теперь всего $300, и она может быстро исчезнуть. Если средний клиент отправит немного больше сообщений, чем ожидалось, или если во время неудачного релиза повторы резко вырастут, стоимость одного чата подскочит раньше, чем кто-то это заметит.

Небольшое изменение может перевернуть экономику. Если средняя длина чата растет и стоимость модели поднимается с $0,01 до $0,015, месячный счет за модель увеличивается с $200 до $300. Общие расходы становятся $1 300. Маржа падает до $200.

Если поддержка попросит проверять 10% чатов вместо 5%, продукт может уйти в минус без какого-либо драматического сбоя или заметной ошибки. Команда может думать, что usage растет и клиенты активны, хотя unit economics незаметно ухудшаются.

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

Как посчитать свою реальную стоимость одной задачи

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

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

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

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

Средний трафик может скрыть проблему. Считайте обычный объем, а потом пиковый трафик и всплески сбоев. Процесс, который выглядит дешевым на 1 000 задач в день, может быстро стать дорогим, если очередь забивается, воркеры масштабируются, а каждый таймаут создает еще один круг логов. Команды, которые используют инструменты вроде Sentry, Grafana, фоновых воркеров и объектного хранилища, часто замечают, что support tooling растет быстрее ожидаемого, когда трафик становится хаотичным.

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

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

Вот простой пример. Допустим, одна задача приносит $0,80 выручки. Модель стоит $0,18, вычисления и очереди добавляют $0,07, логи и хранилище — $0,09, а ручная проверка — $0,21. Реальная стоимость составляет $0,55 за задачу. Это может работать. Но если повторы поднимут среднее значение до $0,68, маржа очень быстро станет тонкой.

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

Ошибки, которые съедают маржу

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

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

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

Сохранять один и тот же payload в нескольких местах — еще одна классическая ошибка. Команда хранит запрос в базе приложения, в очереди, в объектном хранилище, в аналитике и в support tool. Теперь одно действие пользователя создает пять событий хранения вместо одного. А еще потом приходится чистить пять мест. Выберите один источник истины и по возможности храните ссылки, а не копии.

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

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

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

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

Быстрая проверка перед запуском

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

Начните с одной цифры: стоимость одной успешной задачи. Не одного API-вызова, не одной сессии и не одного начатого запроса. Если 100 задач начались, 82 завершились правильно, а вы потратили $82 на модели, очереди, хранилище, проверку и мониторинг, ваша стоимость составляет $1 за одну успешную задачу.

Перед запуском ответьте на пять простых вопросов:

• Можете ли вы посчитать полную стоимость одной завершенной задачи, включая неудачные попытки и время на ручную проверку?
• Знаете ли вы, как долго логи, скриншоты, промпты, ответы и audit records хранятся перед удалением или архивированием?
• Останавливаются ли повторы после фиксированного лимита, и есть ли у очередей жесткий потолок, чтобы backlog не рос часами, пока никто этого не замечает?
• Проверяют ли люди только действительно рискованные случаи, например ответы с низкой уверенностью, платежные шаги, юридический текст или изменения, которые увидят клиенты?
• Можете ли вы назвать инструменты, дашборды или агентов, которыми никто на практике не пользуется, но которые все равно создают события, хранят данные или запускают задачи?

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

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

Лимиты на повторы важны не меньше. Если upstream-сервис начинает тормозить, бесконечные повторы могут завалить очередь, повторно запустить вызовы модели и создать дублирующую работу для проверки. Задайте небольшой бюджет на повторы, добавьте задержку между попытками и решите, когда система должна быстро падать.

К ручной проверке нужен тот же подход. Проверяйте рискованные крайние случаи, а не каждый ответ. Именно на такой rule-based review команды часто находят простую экономию без потери качества.

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

Что делать дальше, если цифры не сходятся

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

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

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

Начните с наименее болезненных сокращений

Несколько изменений обычно быстро двигают цифры:

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

Будьте строгими к дублирующемуся хранению. Команды часто сохраняют один и тот же контент в базе приложения, объектном хранилище, аналитических инструментах, support tools и системе проверки. Сначала это кажется безопасным. Но очень быстро становится дорого. Если одна копия закрывает реальную бизнес-потребность, остальные должны оправдать свою стоимость.

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

Введите еженедельную проверку затрат

Отслеживайте стоимость каждого процесса каждую неделю, а не только общий расход. Общий облачный счет скрывает проблему. А вид на уровне процесса показывает, что один support flow стоит 8 центов, другой — 42 цента, а один внутренний цикл проверки тратит деньги, не улучшая качество.

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

Если вашей команде нужен внешний взгляд, Oleg Sotnikov из oleg.is работает со стартапами и небольшими компаниями в роли Fractional CTO и советника по разработке с приоритетом на ИИ, инфраструктуре и автоматизации. Такой практический разбор очень помогает, когда счет выглядит запутанным, а команда не может понять, какая часть действительно бьет по марже.

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