В течение последнего года мы запустили несколько продуктов с LLM-решениями на борту. При этом, несмотря на различия в моделях и масштабе, у них, у всех была общая черта — расчет стоимости использования ИИ-фичи на старте расходился с реальностью: иногда — в несколько раз, но, всегда — в сторону увеличения бюджета.
Сценарий был примерно таким: стоимость одного активного пользователя в ИИ-ассистенте на момент сметы выглядела отлично, мы закладывали ее в финансовую модель, защищали бюджет, запускали проект. А через полгода в проде реальная цена была уже в разы выше, несмотря на то, что все делалось «правильно»: кэширование, маршрутизация, мониторинг.
Этот материал о том, где и почему бюджет расходится с рекламной моделью. Статья получилась большой и подробной: в ней будут рабочие формулы, таблицы с расчетами, примеры ловушек и советы по оптимизации.
Если читать лень, и нужен вывод, то вот он: декларативный прайс модели сам по себе никогда не даст точного ответа на вопрос, сколько будет стоить LLM-инструмент в разработке. Реальная экономика складывается из контекста, ретраев, RAG-пайплайна, кэширования, поведения пользователей, динамики нагрузки и постоянных изменений в самих моделях. Поэтому считать нужно не стоимость запроса в вакууме, а стоимость сценария — и регулярно пересчитывать ее заново.
Если же хотите разобраться, как заявленные 0,06 доллара за запрос превращаются в реальные 0,15 доллара, читайте дальше!
Один пользовательский запрос — не равно один вызов модели
Рассмотрим типичный сценарий — ассистент с поиском по базе знаний (Advanced RAG, по классификации Atlan — стандартная архитектура для большинства продакшн-систем 2026 года). Что происходит после нажатия клавиши Enter:
Легкая модель определяет, нужен ли вообще поиск или это просто светская беседа.
Легкая модель преобразует вопрос в форму, удобную для поиска.
Система ищет релевантные документы (это платная операция, но не вызов модели).
Легкая модель оценивает найденные документы и отбирает лучшие.
Основная модель формулирует ответ на основе отобранных документов.
Легкая модель проверяет, не противоречит ли ответ источникам.
Если проверка не пройдена, шаги 4–6 повторяются.
Что за легкая модель? Так обозначают «младшую» версию LLM в линейке провайдера. Те же компании, которые выпускают флагманские модели (Claude Opus, GPT-5), параллельно производят упрощенные версии: Claude Haiku, GPT-5 Nano, Gemini Flash. Они быстрее и дешевле, но справляются с простыми задачами не хуже старших сестер, а стоят в десятки раз меньше.
По данным Morph, разница в цене между Claude Haiku и Claude Opus — 60 раз. То есть отправить простой запрос («это вопрос или приветствие?») в дорогую модель — это как позвать Брэда Питта в фильм Александра Невского, прикольно, но с позиции художественной ценности — абсолютно нерационально.
Поэтому в продакшене редко используют только одну модель. Простые операции — классификация запроса, проверка ответа, отбор документов — отдаются на откуп легкой модели. Сложные рассуждения — дорогой. Такой подход позволяет сэкономить бюджет без потери качества.
Вернемся к детализации стоимости. Даже если идеально оптимизировать распределение между моделями, остается вторая часть уравнения: внутри каждого отдельного вызова (у нас их, напомним, 7) тоже не все так просто. Стоимость одного обращения к модели — это не плата за заданный вопрос.
Это плата за весь объем (пакет) текста, который вы отправляете модели вместе с вопросом: инструкции, загруженные документы, историю предыдущей переписки и на каждом этапе — будь то классификация намерений, отбор документов или финальная генерация — модель получает на вход свой пакет данных. И за каждый такой пакет выставляется отдельный счет.
Вот так выглядит наш алгоритм, если заглянуть в механику каждого шага. Теперь копнем еще глубже: посмотрим, что конкретно поступает на вход модели на самом затратном из этих семи шагов — пятом — при основной генерации ответа.
Здесь действует простой принцип: провайдер берет деньги за каждую единицу текста, которую вы отправляете модели. Чем больше блок во входящем пакете, тем больше за него придется заплатить. Если 60% входящего объема — это документы из базы знаний, то 60% счета за этот вызов придется на них, а не на вопрос пользователя.
В пересчете на деньги: если один вызов Claude Sonnet 4.6 (прайс Anthropic) стоит условных 1 доллар, то ~60 центов из этой суммы уходит на документы из базы знаний, ~20 центов — на историю диалога, ~15 центов — на инструкции к системе и только ~4 цента — на сам вопрос пользователя.
Главный вывод: вы платите не за то, о чем спрашивал пользователь. Вы платите за все, что подсказываете моделям сами, — инструкции, документы из базы, историю переписки. Это значит, что оптимизация коротких пользовательских запросов почти ничего не дает. Реальная экономия — в том, как организовано все остальное.
Скрытые расходы
Прайс провайдера — это только вершина айсберга. Когда неопытные команды считают стоимость LLM-решения, они, как правило, берут цену токена, умножают на предполагаемое количество запросов и получают некое число, которое на первый взгляд выглядит терпимо. Проблема в том, что это значение не имеет ничего общего с реальным счетом, и уж тем более через полгода.
Свежие исследования показывают, большинство команд ошибаются в бюджете в два-три раза, но не потому, что невнимательны, а потому что оперируют не теми статьями расходов. Они скрупулезно считают стоимость эмбеддинг-вызовов, выбирают векторную базу по бесплатному тарифу, а потом удивляются затратам, которые инициированы постоянно переполненным хранилищем, повторяющимися циклами переиндексации и поддержкой, вынужденной половину рабочей недели заниматься качеством поиска.
Эмбеддинги и переиндексация
Первый эмбеддинг-прогон выглядит дешево. Загрузить и проиндексировать корпус документов — разовая операция, и ее стоимость удобно укладывается в ожидаемый бюджет. Но чем дальше в лес, тем, как известно, злее белки.
Каждый раз, когда вы меняете способ разбивки документов — например, решаете дробить их на более короткие фрагменты для точности поиска — система заново обрабатывает весь архив целиком. Это как если после каждой переустановки полок и шкафов библиотека будет выставлять счет за повторный ввод всех книг в каталог. К тому же: чем больше фрагментов модель извлекает на свет при каждом запросе, тем больше токенов тратится — и этот счетчик легко и незаметно утраивается, без каких-либо видимых изменений в интерфейсе.
Отдельная ловушка — долгосрочные обязательства по хранению. Эмбеддинги нужно не только один раз посчитать, но и хранить, индексировать, обновлять и пересчитывать при смене модели. Размер такого слоя зависит от embedding-модели и размерности вектора: один и тот же корпус документов может занимать в векторной базе существенно разный объем. Простая аналогия: человека можно описать тремя словами — «высокий молодой блондин», а можно заполнить анкету из 50 пунктов. Второй вариант точнее, но дороже в хранении и обработке.
Для 100 миллионов документов разница составляет от ~400 ГБ до ~1,2 ТБ. Умножьте это на месяцы и годы хранения — и небольшое техническое решение на старте превращается в весомую статью регулярных расходов.
Векторная база данных
Еще один аспект, который постоянно упускают на старте, — рост векторной базы. Предварительную оценку делают обычно на небольшом объеме: сотни тысяч, пускай, миллион векторов. На этом уровне стоимость выглядит предсказуемой. Однако в проде база никогда не остается в исходных границах: появляются новые отделы, продукты, архивы, служебные данные. RAG-сценарий постепенно превращается в гигантский слой корпоративной памяти, и хранить приходится уже не изящный пилотный корпус, а постоянно растущий, рыхлый массив.
Проблема в том, что стоимость этого слоя не растет линейно. Провайдеры берут деньги не только за объем хранения, но и за количество копий базы, скорость поиска и число обращений. Пока база небольшая, все это входит в начальный тариф. Но в какой-то момент наше беспокойное хозяйство перестает соответствовать его возможностям — и система вынуждает перейти на следующий уровень, где меняется все: и цена за хранение, и условия. Рост базы в 10 раз может обернуться увеличением счета в 20–30 раз, потому что вы перешли в другую тарифную категорию.
Формально все как и было: система работает, SLA соблюдается, договор не нарушен. Но финансовая модель, собранная на старте, уже не вписывается в реальность. Команда платит уже не за тот продукт, который видела полгода назад, а за выросшую инфраструктуру вокруг него.
Логирование и мониторинг
Статья расходов, которую почти никогда не включают в первоначальный бюджет, — мониторинг. LLM-систему нельзя нормально эксплуатировать, если вы видите только суммарный счет за токены. Нужно понимать стоимость отдельных сценариев, причины задержек и поведение RAG-пайплайна.
Важно! Это отдельный слой данных. Документы и базы знаний может хранить провайдер, но телеметрия продукта — логи, трассировки, промпты, метаданные запросов — собирается, хранится и оплачивается отдельно. Вами!
В классическом приложении объем такой телеметрии чаще всего растет вместе с трафиком. В LLM-продукте связь сложнее: один пользовательский запрос может породить несколько внутренних обращений к базе, проверок и этапов постобработки. А вместе с ростом пользовательской нагрузки, растет объем диагностических данных.
Здесь стоит сделать оговорку. Такие данные редко хранят постоянно — для них выделяют буфер фиксированного объема (например, до 4 ГБ в месяц), и при превышении лимита старые записи автоматически стираются. Этот механизм называется ротацией логов, и он позволяет ограничивать расходы на хранение.
Но лишь частично, так как счет за мониторинг состоит из двух частей — приема данных и хранения с индексацией. Ротация касается только второй части. Прием тарифицируется за каждый отправленный гигабайт еще до того, как данные успеют стереться. А агрессивная ротация удаляет ровно ту историю, которая нужна для анализа расходов по пользователям и функциям. Поэтому телеметрия в LLM-системах — это всегда выбор между роскошью оплаты достаточного по объему хранилища логов и спартанским минимумом данных, которых хватит для оперативных реакций, но не полноценного анализа.
В общем, на старте мониторинг кажется второстепенной задачей: давайте сначала выведем продукт в прод, а организованные наблюдения оставим до лучших времен. Но когда система начинает работать с реальными пользователями, выясняется, что без этого слоя невозможно управлять ни качеством, ни стоимостью. И он тоже становится частью юнит-экономики.
Оценка качества и тестирование
Система, которая отвечает пользователям, должна проверяться на ошибки и деградацию качества после обновлений. В классическом программном обеспечении для этого есть автоматические тесты: они давно стали стандартом, хорошо описаны и относительно недороги в поддержке. С LLM-системами сложнее. Качество ответа невозможно проверить одной математической формулой: нужно понимать, сохранила ли система смысл, не потеряла ли важные детали, не заболела ли галлюцинациями и не стала ли врать в пограничных сценариях.
Поэтому в бюджет обязательно закладывают отдельный контур оценки качества. По наблюдениям Kalvium Labs, минимальный evaluation-пайплайн для RAG-системы включает три элемента:
набор контрольных запросов с ожидаемыми ответами;
функцию оценки;
проверку в цикле разработки, которая блокирует релиз при падении метрик ниже заданного порога.
Даже на небольших системах эти мероприятия требуют 4–8 часов в месяц. Если оценкой занимается внешний подрядчик, в счете появляется отдельная строка. Если это обязанность внутренней команды, отдельной строки может не быть, но время-то, все равно тратится — а оно, как известно, стоит денег.
Проблема в том, что такие расходы также никогда не закладываются в первоначальный бюджет — их просто не видно до тех пор, пока система не заработает в полную силу. Чтобы вы не грустили в одиночестве и понимали масштаб проблемы: только 51% организаций — половина, думают, что могут оценить возврат от инвестиций в свои ИИ-вложения, и только 22% компаний по данным CloudZero, действительно умеют отслеживать расходы на ИИ в разрезе отдельных факторов и транзакций. Остальные просто платят.
Модерация и фильтрация персональных данных
Если модель работает с данными клиентов или в регулируемой отрасли, к каждому запросу добавляется еще один уровень проверки: входящий текст сканируется на наличие персональных данных и нежелательного контента, а исходящий ответ фильтруется перед отправкой пользователю.
Технически это решается двумя способами.
Первый — простые автоматические правила: система проверяет, есть ли в тексте номера карт, паспортов, телефонов и другие очевидные паттерны. Это быстро и дешево, но не работает с контекстными нарушениями, проще говоря: если персональные данные записаны словами, а не цифрами, или если нарушение связано с содержанием ответа, а не с его форматом, система его пропустит.
Второй — отдельная облегченная модель, которая проверяет каждый ответ перед отправкой. Более точный подход, но требует дополнительных токенов на каждый запрос. На практике используют оба метода в связке.
Кто отвечает за фильтрацию, зависит от требований к данным. Внешние сервисы, такие как Azure Content Safety или AWS Comprehend, подключаются быстро и не требуют собственной инфраструктуры, но данные пользователей передаются на серверы третьей стороны. Для большинства коммерческих продуктов это приемлемо, но для банков, медицинских учреждений и государственных организаций — как правило, нет.
В таких случаях фильтры строят внутри собственного периметра, что требует отдельной инфраструктуры и поддержки. Если этот уровень не автоматизирован, стоимость смещается с понятной оплаты API на ручной труд, а эта статья расходов — ну, вы поняли, привычно не учитывается в бюджете.
Reasoning-модели: плата за невидимое
В 2024–2025 годах появился новый класс моделей — так называемые reasoning-модели, или модели «с расширенным мышлением» (Claude Opus с расширенным мышлением, GPT-5 с рассуждением, DeepSeek R1, Gemini 3 Thinking). От обычных они отличаются тем, что перед ответом генерируют внутреннюю цепочку рассуждений — проверяют себя, переформулируют, отбрасывают неверные ходы. При решении сложных задач — программировании, аналитике, математике — это дает ощутимый прирост качества.
Нюанс в том, что эти внутренние рассуждения — обычные токены, которые оплачиваются по цене выходных данных. На вопрос пользователя система дает ответ из 200 слов, за которым стоит оплаченный счет за 20 тысяч слов скрытых размышлений. Хотите пруф, пожалуйста: по данным TokenMix, один сложный запрос к Claude Opus с расширенным мышлением может сжечь от 20 до 40 тыс. невидимых токенов перед выдачей 500 видимых — это 0,50–1,00 доллара за один вызов, и почти вся сумма уходит на то, чего человек не видит.
Самое неприятное: низкая цена за токен в reasoning-моделях не означает низкую цену за ответ. Дешевая модель берет меньше за каждый токен, но, чтобы получить ответ, она часто думает дольше и тратит больше ресурсов на размышления. В результате один и тот же вопрос на дешевой модели обходится дороже, чем на продвинутой. Исследование, проведенное в Стэнфорде, Беркли и Карнеги — Меллон по 11 872 запросам, показало, что в 21,8% случаев дешевая модель в реальной работе оказывалась дороже премиальной, в некоторых случаях — аж в 28 раз. Вывод: нельзя выбирать reasoning-модель по цене, нужны тесты на реальных задачах.
Когда это становится критично? Буквально с первого дня, как только в системе включается режим reasoning хотя бы для части запросов. Без отдельного учета thinking-токенов в мониторинге счет растет незаметно — до тех пор, пока не придет сообщение от провайдера.
Парадокс активного пользователя
Бюджет на большие языковые модели почти никогда не распределяется равномерно — расходы концентрируются на небольшой группе самых активных пользователей. Масштаб перекоса хорошо виден на публичных кейсах.
TechCrunch называют это явление «tokenmaxxing»: пользователи на тарифах с фиксированной ценой потребляют столько вычислительных ресурсов, что отдельные «инференс-киты» тратили более 35 тыс. долларов, при этом платя всего 200 долларов в месяц — провайдер субсидировал их в 175 раз. И чем дольше пользователь работает с продуктом, тем дороже он обходится: у него накапливается больше диалогов, усложняется контекст, появляется больше повторных уточнений и обращений.
OpenAI запустила тариф ChatGPT Pro за 200 долларов в месяц, рассчитывая на активных пользователей. Через несколько месяцев Сэм Альтман публично признал, что компания теряет деньги на этом тарифе: отдельные пользователи делали по 20 тыс. с лишним запросов в месяц и обходились компании в сотни долларов каждый.
У GitHub Copilot похожая картина: средний разработчик потребляет вычислительные ресурсы на 30 долларов в месяц при цене подписки в 10 долларов, а активные пользователи — на 80 долларов. По данным AI Cost Check, «тяжелый» пользователь на флагманской модели может обходиться компании в 40–80 долларов в месяц только за счет расходов на API — это разорительно для любого SaaS-сервиса, подписка на который стоит менее 100 долларов.
Какой вывод? Юнит-экономика из расчета «в среднем на пользователя» обманчива. В системе с большим количеством активных юзеров среднее значение всегда меньше реального счета за крупных клиентов. Если на дашборде отображается только среднее значение, компания не видит, что ее прибыль зависит от мелких пользователей, которые субсидируют крупных.
Когда об этом стоит задуматься: при безлимитных тарифах, при усложнении использования системы (агенты, длинные диалоги, логические цепочки) и через 4–6 месяцев работы продукта, после того как у активных пользователей накопится достаточный объем истории взаимодействия.
Сводная таблица веса скрытых расходов в общем бюджете LLM-приложения:
Данные: открытые источники и собственные наблюдения WB-Tech за проектами в продакшене. Нижняя граница вилки — оптимистичный сценарий зрелой команды с хорошо настроенными процессами. Верхняя — типичная картина через несколько месяцев в продакшене.
Инструменты и метрики контроля расходов
Все статьи скрытых расходов в приведенной выше таблице объединяет одно: их невозможно контролировать, если о них не знать. В биллинге провайдера указана только итоговая сумма за месяц — кто, на что и почему ее потратил, придется выяснять отдельно. По меткому замечанию OpenObserve, счет провайдера показывает, сколько вы потратили, но не почему вы это потратили.
Чтобы понять, что стоит за общей суммой затрат на ИИ, нужны отдельные инструменты, системы мониторинга. Именно они показывают, что половину бюджета «съели» полсотни активных пользователей, часть ушла на повторные вызовы при сбоях, а остальное — на тестовое окружение. Эти инструменты подключаются к системе, фиксируют каждый вызов модели с привязкой к адресу и функции и собирают все данные в дашборды, которые демонстрируют источники расходов, а не среднюю температуру по больнице.
Что должно быть на таком дашборде. Согласно рекомендациям Traceloop и Braintrust, минимальный набор показателей для управления юнит-экономикой выглядит так:
Какие инструменты есть на рынке? Решений достаточно. Навскидку: Langfuse — открытый исходный код, минимальные затраты на инфраструктуру; Helicone и Traceloop — облачные сервисы с быстрым подключением; Datadog LLM Observability и Maxim Bifrost — корпоративные платформы для тех, у кого уже развернут крупный стек мониторинга.
Почему этим пренебрегают? Причина все та же: на этапе запуска, на фоне других процессов, кажется, что ежемесячного отчета от провайдера будет достаточно. Однако к моменту, когда счет удваивается, оказывается, что разобраться в ситуации задним числом невозможно — данных просто нет, а сократить скрытые расходы, о которых не знаешь, невозможно в принципе.
Цена по прайсу — иллюзия точности. Любой расчет по принципу «возьмем прайс и умножим на трафик» дает погрешность в разы. Реальная цифра — это всегда диапазон, и то, в каком месте этого диапазона вы окажетесь после запуска продукта, зависит не от выбора модели, а от того, как организован процесс вокруг нее.
Четыре формулы для расчета LLM-приложения
Финансовая дисциплина для систем с большими языковыми моделями — самая новая область корпоративных финансов. По данным State of FinOps 2026, всего два года назад только 31% компаний системно управляли расходами на искусственный интеллект. К 2025 году этот показатель был уже 63%, а в 2026-м — 98%.
Согласно исследованию FinOps Foundation, самый частый запрос ИИ-практиков сейчас — это «расчет стоимости архитектуры перед развертыванием», то есть способ подсчитать расходы до запуска системы в продакшн.
То есть индустрия осознает, что классическая модель расчета путем умножения количества запросов не работает, но происходит это буквально на глазах. Это также означает, что общепризнанных канонических формул юнит-экономики больших языковых моделей пока не существует.
Но есть отдельные методологии: фреймворк FinOps Foundation Crawl-Walk-Run, подходы CloudZero к атрибуции расходов, методология Bessemer по юнит-экономике SaaS-продуктов с искусственным интеллектом, научные работы о совокупной стоимости владения языковыми моделями. При этом у каждого источника свой взгляд на проблему, и ни один из них не дает ответов сразу на все вопросы, ответы на которые делают LLM-бюджет компании прозрачным.
Сколько будет стоить один активный пользователь в месяц? Базовая юнит-экономика — без нее нет смысла говорить о каких-либо других расчетах.
Какой стек выбрать — внешний API, дешевый публичный инференс или собственный сервер? Точка окупаемости с учетом совокупной стоимости владения, а не «цена GPU, деленная на количество запросов».
Что будет с моими расходами при увеличении трафика в 10 раз? Линейный прогноз вводит в заблуждение — нужно понимать, где находятся нелинейные пороги.
Сколько на самом деле стоит один решенный бизнес-кейс? Стоимость результата, а не запроса — критически важный показатель для моделей логического вывода и агентов, где для получения одного полезного ответа может потребоваться десяток запросов.
Поэтому все, что ниже, — это синтез из нашей практики. Для каждой формулы указано, откуда взят ее каркас и какие компоненты добавлены. Мы не ставим целью заменить будущие отраслевые стандарты, но предлагаем работающий инструмент уже сейчас, пока этих стандартов нет.
Формула 1: стоимость одного активного пользователя (CPMAU)
Базовая схема расчета стоимости запроса описана в руководстве AI Cost Guard: стоимость запроса = (входные данные × цена входных данных + выходные данные × цена выходных данных) / 1 000 000. Эта формула верна в качестве нижней границы, но в ней не учитывается все, что мы рассмотрели в разделе о скрытых расходах.
Расширенная версия, которая предлагается ниже, включает три компонента: множители операционных накладных расходов, множители оптимизации и долю скрытых расходов. Каркас множителей соответствует методологии Bessemer Venture Partners, ее девиз в плейбуке для ИИ-продуктов гласит: «Компании, которые игнорируют реальные затраты на старте и рассчитывают на быструю окупаемость, масштабируются до отрицательной маржинальности, даже не заметив этого».
Формула: CPMAU = R × C × T × M_оп × M_опт × (1 + H)
Значения диапазонов — это сводные данные из открытых исследований CloudZero, getmaxim.ai, Atlan и FinOps Foundation, подтвержденные реальными внедрениями в продакшн. В своем конкретном случае используйте их как отправную точку, корректируя в соответствии с фактическими показателями системы.
Пример расчета. Возьмем типичный корпоративный RAG-ассистент на Claude Sonnet 4.6 с легкими вызовами через Haiku 4.5:
R = 50. Активный сотрудник делает в среднем около 50 обращений к ассистенту в месяц.
C = 5. Один вопрос проходит через классификацию, переформулировку, отбор документов, генерацию и проверку.
T = $0,012. Средневзвешенная стоимость одного вызова: шесть легких операций на Haiku (~$0,003 каждая) + один основной вызов на Sonnet (~$0,032), усредненно $0,012 на вызов в цепочке.
M_оп = 2,0. Команда в продакшене, есть тестовый трафик, повторы при ошибках валидации.
M_опт = 0,4. Команда применяет кэширование системного промпта и маршрутизацию между моделями. Пакетный режим не используется (диалоговый интерфейс).
H = 0,6. Зрелая система через 4 месяца в продакшене: добавлены эмбеддинги для базы знаний, мониторинг через Langfuse, регулярные оценки качества.
CPMAU = 50 × 5 × $0,012 × 2,0 × 0,4 × 1,6 = $3,84 на одного активного пользователя в месяц.
Полученная цифра — это не точка, а позиция в диапазоне. Если у команды нет данных для точной оценки одного из множителей, нужно рассчитать формулу дважды: для пессимистичного сценария (M_оп = 2,5, M_опт = 1,0, H = 1,0 → 15 долларов на пользователя) и для оптимистичного (M_оп = 1,8, M_опт = 0,2, H = 0,43 → 1,55 доллара на пользователя).
Разница между крайними значениями — почти десятикратная. Это и есть пространство, к которому применяется юнит-экономика продукта, и то, в какой точке этого диапазона окажется компания, зависит не от выбора модели, а от управленческой дисциплины, мысль о которой проходит красной строкой сквозь эту статью.
Важно! Эта формула — основа всех последующих. В формуле 2 мы используем ее для расчета точки окупаемости собственной инфраструктуры. В формуле 3 — для прогнозирования при росте трафика. В формуле 4 — для перевода в показатель «стоимость за результат».
Формула 2: точка окупаемости с учетом совокупной стоимости владения
На салфетке self-hosted почти всегда выглядит дешевле API. Достаточно взять стоимость аренды GPU, разделить на ожидаемое число запросов — и сравнение с прайсом провайдера уже кажется убедительным. Проблема в том, что такой расчет учитывает только аренду железа. В реальной эксплуатации к ней добавляются загрузка и простои GPU, резервирование, обновления моделей, мониторинг, поддержка инфраструктуры и время инженеров.
По данным AI Pricing Master, чистая стоимость видеокарт составляет лишь 30–40% от реальных вложений в инфраструктуру — остальное уходит на резервирование, персонал и обновления. Вообще, главный фактор, влияющий на стоимость собственной инфраструктуры, — это не железо, а люди: загруженный работой старший инженер по логическому выводу в США стоит 250–360 тыс. долларов в год, в Европе — 180–260 тыс. долларов.
В России цифры скромнее, но тенденция та же: по данным Habr Career 2026, старший инженер по LLM обходится компании в 450–620 тыс. рублей в месяц с учетом налогов и социальных отчислений — это 5,4–7,4 млн рублей в год. Команда, которая ежемесячно тратит условные 800 тыс. рублей на внешний API, не сможет оправдать 500–600 тыс. рублей в месяц только на инженера по миграции — стоимость поддержки инфраструктуры съест всю потенциальную экономию.
Поэтому, прежде чем считать, мы рекомендуем сделать подумать над выбором стека. В 2026 году их три вот, на каких условиях они в среднем доступны.
Ключевое различие между этими вариантами — сложность перехода. Замена внешнего API на публичный инференс — это операционная замена: меняется только один адрес в настройках, а сам код и логика работы остаются прежними. Такой переход опытная команда может реализовать за день-два.
А вот решение перебраться на собственную инфраструктуру — это уже архитектура: нужно развернуть и настроить серверы, перенести модель, выстроить мониторинг и отказоустойчивость, а затем постоянно поддерживать все это силами отдельной команды. Это проект на месяцы. Эта формула (2), дающая возможность рассчитать окупаемость собственного оборудования, нужна только тем, кто всерьез рассматривает именно третий сценарий — для первых двух вариантов она просто не нужна.
Но если вам подходит третий сценарий, считать придется тщательно. И одной формулой здесь не обойтись: их две, и они работают только в паре.
Первая полная стоимость владения в месяц отвечает на вопрос «сколько стоит содержание собственной инфраструктуры в месяц» — это совокупная стоимость владения, которая не зависит от количества обработанных запросов.
TCO_месяц = (P_железо / N_аморт) + P_электричество + P_колокейшн + P_сеть + (k_FTE × S_год / 12) + P_софт
Вторая точка окупаемости в запросах в месяц отвечает на вопрос «при каком количестве запросов это вообще имеет смысл» — это точка окупаемости, которая делит фиксированные расходы на экономию с каждого запроса. Без первой формулы вторая не имеет смысла. Без второй первая не дает никакой полезной информации.
B = TCO_месяц / (T_API − T_свое_переменные)
Пример расчета. Команда рассматривает возможность миграции RAG-ассистента (50 тыс. активных пользователей, 50 запросов на пользователя в месяц = 2,5 млн запросов в месяц) с Claude Sonnet 4.6 на собственную инфраструктуру с Llama 4 70B.
Стоимость TCO:
Железо: 2× H100 за $60 тыс., амортизация 36 месяцев → $1 667/мес
Электричество: 2× 700 Вт × 730 ч × $0,12/кВт·ч × коэффициент охлаждения 1,4 → $172/мес
Колокейшн: $1000/мес
Доля инженера: 0,5 FTE × $300 тыс. / 12 = $12 500/мес
Софт и мониторинг: $300/мес
TCO_месяц = $15 639
Стоимость на API:
T_API (один запрос на Sonnet 4.6 с учетом множителей из формулы 1) = $0,038
T_свое_переменные ≈ 0
Точка окупаемости: B = $15 639 / $0,038 = 411 тыс. запросов в месяц
Команда обрабатывает 2,5 млн запросов в месяц — это в 6 раз больше точки окупаемости. На бумаге миграция оправдана: экономия составляет около 80 тыс. долларов в месяц.
Ловушка убыточности: главная проблема этого расчета
По данным Bench LM, за период с 2024 по 2026 год цены на API снижаются примерно на 80% в год. Это значит, что показатель T_API в нашей формуле — уменьшающийся. Точка окупаемости, которая сегодня составляет 411 тыс. запросов, через 6 месяцев при тех же условиях составит уже 800 тыс. запросов. Через 12 месяцев — 1,5 млн.
При этом совокупная стоимость владения собственной инфраструктурой не снижается. Услуги инженеров не дешевеют, электричество не дешевеет, амортизация оборудования фиксированная, а то и наоборот, требует дополнительных вложений в связи с износом. Расчет окупаемости — это статичная картина, которая начинает устаревать с момента подписания контракта на инфраструктуру.
Это значит, что формулу нужно прогонять регулярно — желательно, не реже одного раза в квартал. Если на момент принятия решения о миграции вы были в 6 раз выше точки окупаемости, то через год может оказаться, что эта разница сократилась вдвое-втрое, и любое замедление роста трафика сведет на нет всю экономическую выгоду от миграции.
Что с этим делать?
Решение о создании собственной инфраструктуры нельзя принимать на основании одного набора цифр — расчет нужно проводить по нескольким сценариям и регулярно повторять.
Рассчитайте формулу для текущих цен на API и текущего трафика
Пересчитайте ее для прогноза цен на API через 12 месяцев (возьмите снижение на 50% как реалистичный сценарий)
Учитывайте в расчетах реальную, а не оптимистичную долю инженера — практика показывает, что k_FTE редко опускается ниже 0,5 при любом серьезном продакшене
Учтите, что переход на дешевый публичный инференс (DeepSeek и подобные сервисы) дает экономию в 70–80% по сравнению с собственной инфраструктурой — но без миграции, без привлечения инженера и без многомесячного проекта.
По данным исследования Braincuber, внешние API остаются оптимальным вариантом для 87% сценариев. Собственная инфраструктура оправдана только в двух случаях: если есть жесткие требования к данным (банковский и государственный сектор, медицина) или при стабильном объеме более 1 миллиарда токенов в месяц. Во всех остальных случаях можно использовать либо публичную модель, либо внешний API.
Формула 3: прогноз стоимости при росте трафика в 10 раз
Линейное прогнозирование редко дает точную картину расходов на LLM-продукт. Пилотная версия работает в контролируемых условиях: мало пользователей, ограниченные сценарии, короткий контекст и ручная проверка качества. С переходом в продакшн меняется не только количество запросов, но и сама структура нагрузки: диалоги становятся длиннее, контекст — сложнее, появляется больше повторов и служебных вызовов. Одни факторы увеличивают счет быстрее, чем растет число пользователей. Другие — тянут его вниз.
Вот, что происходит с продуктом за пределами наивной модели.
По наблюдениям Codezilla, разрыв между прогнозом и реальными расходами чаще всего возникает именно при масштабировании. Простое умножение текущего счета на коэффициент роста не работает: одни факторы приводят к тому, что стоимость растет быстрее трафика, другие — к обратному эффекту.
Приведенная ниже формула учитывает оба направления. Она основана на анализе Divyam.AI и концепции LLMflation от a16z, которая предполагает снижение цен провайдеров примерно на 50% в год с сохранением прежнего уровня качества.
Формула: C_рост = C_текущий × K_трафика × M_нелинейный × (1 − D_LLMflation)
Пример расчета. Возьмем наш сквозной кейс. Сейчас у команды 50 тыс. активных пользователей RAG-ассистента, текущий счет C_текущ = $192 тыс./мес (50 тыс. × $3,84 из формулы 1). Команда планирует за 12 месяцев увеличить количество пользователей в 10 раз — до 500 тыс. пользователей.
Наивный расчет: 192 тыс. долларов × 10 = $1,92 млн/мес.
Реальный расчет с учетом нелинейных зависимостей:
Деградация кэша при росте в 10 раз: доля попаданий снизится с 60% до 30–40%, что увеличит стоимость одного запроса на 15–25%. Множитель: 1,2.
Концентрация активных пользователей: при базе в 500 тыс. в распределении появятся новые активные пользователи, которых не было в выборке из 50 тыс. Множитель: 1,15.
Пороги векторной базы: текущие 5 млн векторов превратятся в 50 млн — переход через два тарифных порога. Множитель: 1,10 (по средним показателям всей системы).
Инфраструктурные надстройки: появится резервирование, отдельный мониторинг, региональная репликация. Множитель: 1,15.
Совокупный M_нелин = 1,2 × 1,15 × 1,10 × 1,15 = 1,75.
LLMflation за 12 месяцев: примем D_LLMflation = 0,40 (консервативная оценка, реальное падение может быть выше).
C_рост = 192 тыс. долларов × 10 × 1,75 × (1 − 0,40) = 192 тыс. долларов × 10 × 1,75 × 0,60 = $2,02 млн/мес.
Реальный счет оказался на 5% выше наивного прогноза. При этом LLMflation существенно компенсировала рост — без нее счет составил бы 3,36 млн долларов в месяц, то есть был бы в 1,75 раза выше наивного прогноза.
Какие выводы можно сделать из этого расчета?
Во-первых, падение стоимости LLMflation работает только для тех, кто за ним следит. Сам факт, что на рынке появились более дешевые или эффективные модели, не снижает счет автоматически. Если модель однажды поставили в прод и больше к ней не возвращались, продукт продолжает жить в старой экономике.
Из этого следует, что выбор модели нельзя считать разовым решением. Его нужно регулярно пересматривать: сравнивать цену и качество, переносить простые сценарии на более дешевые модели, обновлять маршрутизацию и проверять, не держит ли система дорогую модель там, где она уже не нужна. По данным Divyam.AI, редкий ручной пересмотр модели позволяет забрать только часть потенциальной экономии (около 25% от возможной); остальное теряется из-за инерции эксплуатации.
Поэтому в прогнозе на год нужно либо указывать D_LLMflation на уровне 0,2–0,3 (если команда не планирует менять модель), либо на уровне 0,5–0,6 (если проводится ежеквартальная ревизия стека).
Во-вторых, факторы нелинейности не суммируются, а перемножаются. Каждый последующий применяется не к исходной сумме, а к уже увеличенной — как процент к проценту. Четыре фактора по +15% дают не +60%, а +75%. При небольшом масштабе разница незаметна. При росте трафика в 100 раз она превращается в многократный отрыв реального счета от планового.
В-третьих, хорошая новость: при активной работе со стеком рост трафика в 10 раз не обязательно означает рост счета в 10 раз. Снижение цен у провайдеров и умелая оптимизация могут частично или даже полностью компенсировать рост нагрузки.
Формула 4: стоимость одного результата
Стоимость одного запроса имеет смысл только для простого чат-бота. Как только архитектура усложняется — появляются reasoning-модели, агентские цепочки и многоэтапные рабочие процессы, — пользовательский запрос перестает быть актуальной единицей расчета.
Один и тот же внешний запрос может пройти по разным маршрутам: где-то достаточно одного вызова модели, а где-то система запускает поиск по базе знаний, делает несколько проверок, дополнительно рассуждает и повторно генерирует ответ. В такой ситуации средняя цена запроса становится слишком грубой метрикой: она скрывает главное — разные сценарии имеют разную себестоимость.
В 2025–2026 годах ИИ-индустрия все чаще использует метрику cost-per-outcome — стоимость одного успешного результата вместо стоимости одного обращения к модели. Самые известные примеры — Intercom Fin AI, который взимает с клиентов 0,99 доллара за одно успешное решение обращения, или Zendesk, берущий около 1,50 доллара за полностью решенный кейс. Это ценообразование на основе результата: компании продают не обращения к модели, а успешно решенные бизнес-задачи.
В основе этой модели лежит конкретный финансовый расчет. Согласно методологии Codebridge, формула стоимости результата состоит из четырех элементов:
затраты на использование ИИ для одной попытки;
стоимость ручной обработки эскалаций;
доля успешных попыток;
и (опционально) повторные обращения в рамках одной попытки.
Наблюдения за этим показателем приводят к парадоксальным выводам: агент с точностью 88% и стоимостью 1,10 доллара за результат, экономически выгоднее агента с точностью 92% и стоимостью 4,80 доллара, потому что первый эффективно работает с большими объемами данных, а второй тратит бюджет на решение сложных задач.
Формула: C_результат = (C_AI + C_эскалации × R_эскалации) / S_успеха
Пример расчета на нашем сквозном кейсе. Возьмем ту же RAG-систему и сравним два варианта ее архитектуры.
Вариант А: классический RAG на Claude Sonnet 4.6 (то, что мы рассчитывали по формуле 1).
C_AI на одну попытку = 0,076 доллара (один запрос пользователя из формулы 1)
S_успеха = 78% (типичная доля для классического RAG без агентного слоя — 22% запросов либо требуют уточнения, либо дают неточный ответ и перенаправляются оператору)
C_эскалации = 4 доллара (8 минут работы оператора при ставке 30 долларов в час)
R_эскалации = 22%
C_результат_A = ($0,076 + $4 × 0,22) / 0,78 = ($0,076 + $0,88) / 0,78 = $1,23 за решенную задачу.
Главное наблюдение: расходы на ИИ составляют всего 6% от стоимости результата. Остальные 94% — это ручная работа на этапах эскалации.
Вариант Б: RAG с агентным уровнем и логическим выводом на основе Claude Opus 4.7 для сложных случаев. Архитектура та же, но добавлен агентный уровень, который пытается самостоятельно решать сложные задачи с помощью логической модели и нескольких циклов уточнений.
C_AI на одну попытку = 0,42 доллара (в 5,5 раз дороже, потому что: больше вызовов в цепочке, использование токенов для рассуждений, переход на дорогую модель для сложных кейсов)
S_успеха = 92% (агент закрывает большую часть кейсов, которые в варианте А требовали эскалации)
C_эскалации = 4 доллара (то же самое)
R_эскалации = 8%
C_результат_Б = ($0,42 + $4 × 0,08) / 0,92 = ($0,42 + $0,32) / 0,92 = $0,80 за решенную задачу.
Вариант Б дороже на уровне одного запроса — 0,42 доллара против 0,076 доллара, разница в 5,5 раза. Но дешевле на уровне результата — 0,80 доллара против 1,23 доллара. Агентная архитектура с логическими выводами экономит деньги компании, просто это видно только в формуле 4.
Отсюда практический вывод: когда финансовый директор просит перейти на более дешевую модель, он смотрит на стоимость запроса. Но если более дешевая модель чаще ошибается и чаще отправляет задачи на ручную обработку, итоговая сумма растет, а не уменьшается.
Способы сократить расходы
Мы все просчитали: из чего складывается базовая стоимость, какие расходы скрыты, как считать юнит-экономику и точку окупаемости. Теперь о том, что с этим делать. Способов сократить расходы в индустрии накопилось немало, и мы предлагаем их сортировать не по технологиям, а по тому, сколько усилий требуется для внедрения.
Самое простое — это то, о чем говорится в разделах выше кэширование, пакетный режим и маршрутизация между моделями. Повторяться нет смысла, уточним лишь один момент.
Кэш в индустрии 2026 года эволюционировал: помимо обычного кэширования запросов, появилось семантическое кэширование, которое срабатывает не при точном совпадении запроса, а при смысловом сходстве. По данным Redis, это позволяет сэкономить еще 15–30% по сравнению с классическим кэшированием, особенно в сценариях B2C, где пользователи задают одни и те же вопросы в разных формулировках.
Далее следует целый пласт, которому уделяется обидно мало внимания, — работа с самим текстом, отправляемым модели. Мы видели, что вопрос пользователя занимает менее 5% входящих токенов, остальные 95% — это инструкции, документы и история. И значительная часть этих 95% часто оказывается ненужной.
По данным Morph, в среднем запросе к большой языковой модели содержится 40–60% избыточных токенов: устаревшая часть истории диалога, шаблонный системный промпт, целые файлы там, где нужны всего три функции.
Сжатие промптов и контекста (prompt compression, context compaction) — это инженерная практика, которая позволяет отсекать лишнее перед отправкой запроса. Ее внедрение требует двух-трех недель занятости инженера, но позволяет стабильно снизить счет на 20–40% без изменения архитектуры. По нашим наблюдениям, этот метод недооценен больше остальных: команды почему-то охотнее обсуждают переход на более дешевую модель, чем чистоту собственных промптов.
Сюда же относится ограничение длины ответа. На модели уровня Claude Sonnet 4.6 выходные токены стоят в 5 раз дороже входных и если в системном промпте нет явного указания «отвечай кратко» или ограничения через параметр max tokens, модель будет давать развернутый ответ везде, даже там, где достаточно одного предложения. Экономия при использовании этого метода — 10–20%, он очень быстро окупается и не имеет недостатков.
Следующий уровень — управление расходами на стороне пользователя. Это уже не техническая, а продуктовая мера: лимиты на количество запросов в день, на длину контекста, на доступ к дорогостоящим функциям. Выше мы говорили о парадоксе активного пользователя: 5% самых активных пользователей потребляют 40–60% бюджета.
Если в продукте нет тарифных порогов, эти пользователи либо разорят компанию, либо потребуют постоянного субсидирования за счет остальных. Введение лимитов — самый болезненный для продукта способ оптимизации, поскольку он напрямую влияет на пользовательский опыт. Но зачастую это единственный способ сохранить юнит-экономику на безлимитных тарифах. В 2025 году этот путь прошли OpenAI, Anthropic и Google — все они ввели лимиты после периода убыточной работы.
Совсем другой подход — сжатие модели. Это уже не операционная оптимизация, а архитектурное решение: вместо коммерческой модели вы берете открытую, уменьшаете ее размер, повышаете эффективность и разворачиваете у себя.
Главное преимущество сжатия в том, что оно радикально снижает требования к оборудованию — сжатая модель помещается на более дешевый сервер. Это делает собственную инфраструктуру выгодной даже там, где раньше она не окупалась, — но только при соблюдении условий из формулы 2: большой стабильный объем данных или жесткие требования к ним.
По мнению методологов NVIDIA, подтверждаемых исследованием arxiv 2505.02309, стандартная связка из трех методов — pruning (удаление лишних параметров), дистилляция (обучение «маленькой модели-ученика» на основе результатов «большой модели-наставника») и квантование (снижение точности вычислений) — позволяет уменьшить размер модели на 80–95% при потере качества всего на 1–2%.
Реальный пример: команда Bielik.AI уменьшила свою модель до версии Minitron 7B — она на 33% меньше и на 50% быстрее исходной, при этом сохранив 90% качества.
Но это путь для избранных. Качественное сжатие модели требует команды ML-инженеров и несколько месяцев работы, поэтому оправдан этот экспириенс будет только в двух случаях: либо у вас миллионы запросов в день и экономия на инфраструктуре перекрывает затраты на разработку, либо у вас жесткие требования к данным и собственная модель — единственный допустимый вариант. По данным Braincuber, в 87% случаев это избыточно — проще оставить API или перейти на дешевый публичный инференс.
Наконец, географическое расположение и нормативно-правовое регулирование. Если ваши пользователи находятся в Европе, а вы вызываете модели через американских провайдеров, к стоимости вызовов добавляется сетевая задержка и, в зависимости от типа данных, требования к локализации. Есть информация, что регуляторные издержки могут составлять 15–35% от стоимости базовой инфраструктуры. Этот момент стоит учитывать на этапе выбора провайдера, так как из-за мультирегиональной репликации и аудита с ведением журналов «дешевый» вариант может на самом деле оказаться дорогим.
Что остается открытым, а что можно использовать уже сейчас
В предыдущих разделах мы много чего проговорили, тем не менее в отрасли остаются вопросы, на которые пока нет однозначных ответов. Не потому, что никто не задумывался, а потому, что данных пока мало, кейсов недостаточно, а сами объекты исследования исчезают или меняются быстрее, чем команды успевают собирать статистику.
Самый острый из открытых вопросов — юнит-экономика агентов. Обычный RAG делает 3–7 вызовов модели на запрос, и это уже выглядит сложно. Но полноценный автономный агент, способный решать сложные задачи самостоятельно, может сделать 50–200 вызовов на одну задачу, а иногда и больше.
По данным компании Company of Agents, служебные расходы в таких системах составляют 30–50% от общей стоимости, и универсальной формулы для расчета пока не существует. Наша формула 4 работает, пока задача средней сложности. Но что делать, если агент делает 500 звонков и тратит 200 тысяч токенов на размышления ради одного ответа, индустрия пока не очень хорошо понимает.
Причин две. Во-первых, мало данных: агенты массово внедряются в продакшн только в последний год-два, и полезной статистики почти нет. Во-вторых, сама природа агентов мешает их считать: в отличие от RAG, где цепочка вызовов предсказуема, агент сам решает, сколько шагов сделать. Один и тот же запрос может потребовать 5, 50 или 500 вызовов — в зависимости от того, насколько «застрянет» с решением. Стоимость перестает быть фиксированной величиной и превращается в распределение с длинным «хвостом», которое сложно заложить в бюджет заранее.
Второй фактор с долей неизвестности — как устанавливать цену на продукт при инфляции 80% в год. Если зафиксировать цену для клиента на год вперед, то через полгода она перестанет отражать вашу прибыль, потому что ваши затраты сократились в два раза, а вы продолжаете брать прежнюю цену. Если предложить плавающую цену, клиент не сможет планировать бюджет, и вы проиграете тендер конкуренту с фиксированной ценой.
Как найти компромисс, индустрия пока не знает. Ценообразование на основе результата, полученного в формуле 4, отчасти решает проблему, но только для тех функций, результат которых можно объективно измерить. Для «помощника аналитика» или «ассистента маркетолога» такой возможности нет.
Третий вопрос — как удержать в продукте активных пользователей без ущерба для экономики. Мы уже поняли, что безлимитные тарифы не работают: топ-5% пользователей забирают 40–60% бюджета. Жесткие рамки портят пользовательский опыт и снижают индекс потребительской лояльности — пользователь, столкнувшийся с ограничением, теряет симпатию к продукту.
Промежуточные модели — мягкие ограничения, ступенчатые тарифы, кредитная система — индустрия только нащупывает. Пока никто не придумал универсальное решение, справедливое по отношению к разным сегментам и понятное для покупателя.
И тем не менее все эти неясности не отменяют главного: юнит-экономика больших языковых моделей — управляемая величина. Это не лотерея — «повезет/не повезет», а вполне осязаемый диапазон, в котором место компании определяется не удачным выбором модели, а дисциплиной процессов вокруг нее. Разница между результатами неуправляемой и оптимизированной экономики может быть десятикратной, и определяться лишь аккуратной работой.
Если переходить от чтения к делу, вот минимальный набор шагов, с которых стоит начать уже в этот понедельник.
А мы будем рады обсудить в комментариях, какие из описанных проблем вы наблюдали у себя и какие из открытых вопросов считаете наиболее важными. Если ваш опыт сильно отличается от того, что описано в статье, это особенно ценно: индустрия слишком молода, чтобы кто-то один знал ответы на все вопросы. Давайте спорить и искать истину!
