Финансовая дисциплина для LLM: сколько на самом деле стоит один ответ и почему GPU съедает маржу быстрее маркетинга

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

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

1. повторные генерации из-за плохих промптов
2. перерасход токенов в системных инструкциях
3. стоимость embedding и RAG-поиска
4. логирование и хранение контекста
5. тестовые среды и A/B-эксперименты
6. idle GPU на self-hosted инференсе

Формально цена за 1000 токенов была известна. Фактически экономика не сходилась.

Финансовая дисциплина для LLM — это не про сокращение расходов. Это про управляемость.

Из чего на самом деле состоит стоимость ответа

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

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

Cost(answer) = C_tokens + C_compute + C_infra + C_storage + C_ops + C_failure

Разберём каждый компонент.

1. Стоимость токенов: не только input и output

Если используется API-модель, базовая формула проста:

C_tokens = (Input_tokens × Price_input) + (Output_tokens × Price_output)

Но есть нюансы:

1. Системный промпт иногда больше пользовательского
2. История диалога может разрастаться экспоненциально
3. RAG добавляет chunks документов
4. Few-shot примеры могут занимать половину контекста

В одном B2B-чат-ассистенте средний пользователь писал 40–60 токенов. Системный промпт — 900 токенов. История — ещё 1200. RAG-контекст — до 3000.

Фактический input доходил до 5000 токенов.

А это уже другой порядок расходов.

Практический совет

Команда ввела правило:

1. системный промпт ≤ 400 токенов
2. RAG-контекст ≤ 1500
3. обрезка истории по sliding window

Расходы снизились на 37 процентов без потери качества.

2. Лимиты токенов как финансовый риск

Большой контекст — это не только цена. Это:

1. рост latency
2. рост вероятности галлюцинаций
3. рост затрат на повторные генерации

Чем длиннее вход, тем выше вероятность, что ответ окажется нерелевантным и потребуется re-run.

А повторный запуск — это удвоенная стоимость.

В продукте для юридической аналитики повторные генерации достигали 18 процентов. После оптимизации контекста — 6 процентов.

Экономия в годовом пересчёте составила около 280 тысяч долларов.

3. Self-hosted инференс: когда GPU кажется дешевле API

На старте многие считают так:

Аренда GPU A100 — условно 2 доллара в час Модель 13B — работает быстро Значит, будет дешевле API

Но реальность сложнее.

Полная стоимость GPU

C_compute = (Аренда или амортизация GPU) + Электричество + Охлаждение + DevOps + Мониторинг + Простои

Если GPU простаивает 40 процентов времени, фактическая стоимость ответа растёт кратно.

Пример расчёта

Допустим:

1. A100 арендуется за 2.5 доллара в час
2. 720 часов в месяц
3. загрузка 55 процентов

Фактическая полезная стоимость часа = 2.5 / 0.55 ≈ 4.54

Если в час обрабатывается 900 запросов, стоимость инференса одного ответа ≈ 0.005 доллара только на GPU.

Но это без учёта DevOps, масштабирования и резерва.

Добавим ещё 40 процентов накладных — получаем 0.007–0.009.

И это уже сопоставимо с API при средних нагрузках.

4. RAG — невидимая статья расходов

Многие считают только генерацию. Но retrieval — это:

1. embedding документов
2. хранение в векторной базе
3. обновление индекса
4. re-index при изменении структуры

Если в компании 5 миллионов документов, embedding может стоить десятки тысяч долларов только на старте.

Плюс ежемесячные расходы на:

1. векторную БД
2. RAM
3. SSD
4. резервирование

В одном кейсе embedding базы знаний занял 1.8 млн долларов вычислительных ресурсов при первичной индексации исторического архива.

После этого команда стала чистить документы перед индексацией и экономить до 60 процентов бюджета.

5. Стоимость ошибок

LLM иногда ошибается.

Ошибка может стоить:

1. повторной генерации
2. обращения к оператору
3. компенсации клиенту
4. юридических рисков

Если 5 процентов ответов требуют ручной проверки, а оператор стоит 20 долларов в час, при средней проверке 3 минуты:

C_manual ≈ 1 доллар на 4 ответа

Это уже не мелочь.

В финансовом сервисе после внедрения автоматической confidence-модели доля ручной проверки снизилась с 12 до 4 процентов. Экономия составила почти 500 тысяч в год.

6. GPU-бюджет как продуктовая метрика

Зрелые команды начинают смотреть на GPU не как на инфраструктуру, а как на unit-экономику.

Появляются метрики:

1. GPU per active user
2. Cost per meaningful interaction
3. Tokens per revenue dollar

В SaaS с ARPU 49 долларов в месяц допустимая стоимость ИИ на пользователя не должна превышать 5–8 долларов, иначе маржа размывается.

Один стартап выяснил, что power users генерируют в 20 раз больше токенов, чем средний клиент. Ввели soft-limits и тариф с доплатой за heavy usage. Маржа стабилизировалась.

7. Как команда вводит финансовую дисциплину

Обычно это выглядит так:

Сначала хаос. Потом финансовый директор начинает задавать вопросы. Потом появляется таблица. Потом дашборд. Потом автоматический алерт при перерасходе токенов.

Рабочая схема включает:

1. Реальный трекинг токенов на уровне пользователя
2. Разделение dev и prod бюджетов
3. Лимиты на экспериментальные промпты
4. Прогнозирование нагрузки
5. A/B-тестирование длины ответа

Команда одного EdTech-продукта обнаружила, что сокращение средней длины ответа с 900 до 600 токенов не снижает удовлетворённость студентов, но экономит 32 процента бюджета.

8. Амортизация модели и fine-tuning

Если используется fine-tuned модель, нужно учитывать:

1. стоимость обучения
2. повторное обучение
3. хранение весов
4. тестовые инференсы

Если обучение стоило 200 тысяч долларов, а срок актуальности модели — 18 месяцев, то ежемесячная амортизация ≈ 11 тысяч.

Эту цифру нужно добавлять к C_compute.

9. Почему финансовая дисциплина — это не про экономию

Команда, которая считает деньги, начинает принимать более умные архитектурные решения:

1. сжатие контекста
2. кэширование ответов
3. distillation
4. гибридные пайплайны
5. fallback на меньшую модель

В одном проекте 70 процентов запросов перевели на 7B-модель, оставив 30 процентов на 70B. Качество не просело, бюджет сократился почти вдвое.

10. Что происходит без контроля

Без контроля:

1. GPU загружены неравномерно
2. эксперименты не отключаются
3. промпты разрастаются
4. повторные генерации растут
5. маржа испаряется

И самое неприятное — никто не понимает, почему.

Заключение

LLM — это не магия. Это вычисления. А вычисления стоят денег.

Считать нужно всё: токены, GPU, ошибки, RAG, эксперименты, человеческое время.

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

И тогда ИИ перестаёт быть игрушкой разработчиков и становится управляемым бизнес-инструментом.

А это, если честно, намного интереснее, чем очередной демо-ролик с красивым чат-ботом.