AI-инжиниринг
Cost Management: считаем токены, оптимизируем промпты, выбираем модели по бюджету
Цели урока
- Рассчитывать стоимость LLM-запросов с учётом input/output токенов и разных моделей
- Применять техники prompt compression для сокращения input токенов на 40-70%
- Реализовать model tiering - маршрутизацию задач к модели подходящей мощности
- Построить систему budget alerts с per-request, daily и monthly лимитами
- Создать cost dashboard с unit economics для принятия бизнес-решений
Стартап запустил AI-фичу. Один endpoint, один баг в промпте - 10,000 токенов на запрос вместо 500. Через месяц счёт: USD 50K вместо ожидаемых USD 5K. Один пользователь с нестандартным поведением генерировал 80% всех расходов. Без per-user квот, без spending alerts, без cost per request трекинга. Cost management - это не экономия на спичках. Это разница между живым продуктом и закрытым стартапом.
- GitHub Copilot маршрутизирует autocomplete на gpt-4o-mini, chat на gpt-4o - разница в цене 16x при сопоставимом качестве для каждой задачи
- Jasper AI (копирайтинг) публично рассказывал: LLM costs = 60%+ от revenue до оптимизации. Выжили - внедрили model tiering и per-user квоты
- OpenAI ввёл prompt caching со скидкой 50% - признание, что стоимость стала главным барьером для enterprise
- Replit сократил LLM-расходы на 30% через intelligent routing - без потери качества для 95% пользователей
- Helicone и Langfuse - observability-платформы специально для LLM cost tracking, выросли в 5x за 2024 год на волне этой проблемы
Почему cost management стал отдельной дисциплиной
Управление затратами на LLM выросло вместе с экономикой API. Когда **OpenAI открыла свой API (2020)**, тарификация была потокенной: каждый входной и выходной токен имеет цену, а расходы растут прямо пропорционально трафику. Эта модель оплаты сделала траты непредсказуемыми для команд, привыкших к фиксированной стоимости серверов. Когда продукты переходили от прототипов к реальному трафику, один неограниченный промпт или один тяжёлый пользователь мог раздуть месячный счёт. Подсчёт токенов, пользовательские квоты, выбор модели по бюджету и алерты по расходам сложились в практическую дисциплину, а не запоздалую мысль.
Предварительные знания
Анатомия стоимости: input, output, embedding токены
Компания Latitude делала AI-игры. Март 2024 - счёт от OpenAI: USD 150,000. Февраль был USD 2,000. За 60 дней - рост в 75 раз. Не хакеры, не DDoS. **Разработчики не знали, что output токены стоят в 4 раза дороже input.** Длинные нарративы генерировали по 2000-4000 output токенов на запрос. Ни один алерт не сработал. Просто счёт пришёл.
| Модель | Input ($/1M tokens) | Output ($/1M tokens) | Ratio | Контекст |
|---|---|---|---|---|
| GPT-4o | 2.50 | 10.00 | 1:4 | 128K |
| GPT-4o-mini | 0.15 | 0.60 | 1:4 | 128K |
| Claude Sonnet 4 | 3.00 | 15.00 | 1:5 | 200K |
| Claude Haiku 3.5 | 0.80 | 4.00 | 1:5 | 200K |
| Gemini 1.5 Flash | 0.075 | 0.30 | 1:4 | 1M |
| text-embedding-3-small | 0.02 | - | - | 8K |
Output токены убивают бюджет тихо. RAG-чатбот с 3500 input и 800 output токенов на GPT-4o - это USD 0.017 за запрос. Звучит как копейки. 100,000 запросов в день - уже USD 1,675 в день, USD 50,250 в месяц. Тот же трафик на gpt-4o-mini: USD 3,015 в месяц. Разница - 94%. Выбор модели - это не вопрос вкуса.
Считать стоимость до отправки запроса - не паранойя. Это норма. `tiktoken` считает токены за микросекунды - дешевле, чем идти в API и обнаруживать сюрприз в конце месяца. Langfuse и Helicone умеют трекать cost per request автоматически и строить графики распределения расходов по endpoints, моделям, пользователям.
При использовании GPT-4o, какой компонент стоимости обычно доминирует в приложениях с генерацией длинных ответов?
Prompt Compression: сокращаем input без потери качества
Microsoft исследовала типичные промпты production-систем. Вывод: **50-70% токенов можно выбросить - модель ответит так же.** Это не магия. Это то, как работают трансформеры: они смотрят на весь контекст, но большая часть слов в стандартных промптах просто дублирует смысл других слов. LLMLingua автоматически сжимает промпты именно на этом принципе.
RAG-системы страдают от другой болезни: в контекст летят все чанки подряд, включая нерелевантные. Низкорелевантный чанк не помогает - он мешает. Добавляет шум, растягивает контекст, убивает бюджет. Фильтрация по `relevanceScore >= 0.7` и жёсткий token budget решают проблему без потери качества.
| Техника | Экономия токенов | Риск потери качества | Сложность внедрения |
|---|---|---|---|
| Сжатие system prompt | 40-70% | Низкий | Низкая |
| Фильтрация RAG-чанков | 30-60% | Средний | Средняя |
| Компактные few-shot | 50-70% | Низкий | Низкая |
| LLMLingua (auto-compression) | 50-70% | Средний | Высокая |
| Ограничение max_tokens output | Зависит | Зависит от задачи | Низкая |
Какая техника prompt compression даёт наибольшую экономию при минимальном риске потери качества?
Model Tiering: выбор модели под задачу
GitHub Copilot обслуживает миллионы запросов в день. Autocomplete - gpt-4o-mini. Chat с объяснением кода - gpt-4o. Сложный рефакторинг - claude-sonnet. Три модели, три ценовых уровня, один продукт. Это не мультимодельная экзотика - это стандартная практика. **Использовать GPT-4o для классификации тикета в три категории - как ехать за хлебом на грузовике.**
Реальная статистика типичного B2B SaaS с AI: **60% запросов - simple** (классификация, extraction), **30% - medium** (summarization, QA), **10% - complex** (reasoning, analysis). Перевод simple-задач на gpt-4o-mini снижает суммарный счёт на 40-55%. При 100K запросов в день - это разница между USD 1,600 и USD 900 только на inference.
Какой тип задачи НЕ подходит для дешёвой модели (GPT-4o-mini)?
Budget Alerts и Quotas: защита от перерасхода
Август 2023. Разработчик запустил бесконечный цикл с вызовом GPT-4 API. Обнаружил через 6 часов - USD 12,000 ушло. Incident review: не было ни budget alerts, ни per-request quotas. Spending limits на стороне OpenAI - грубый стоп-кран, не инструмент. **Один баг в промпте, одна итерация без break - и месячный бюджет исчезает за ночь.** Application-level budget service - это не optional feature.
**OpenAI Usage Limits не являются заменой application-level бюджетирования.** Они работают как грубый стоп-кран, но не дают granular контроля: per-user квоты, per-endpoint лимиты, alerting при аномалиях. Application-level budget service - обязательный компонент production-системы.
Какой уровень проверки бюджета должен выполняться ДО отправки запроса к LLM API?
Cost Dashboard: визуализация и unit economics
Jasper AI - сервис копирайтинга на LLM. Публично рассказывали: до оптимизации LLM costs составляли 60%+ от revenue. Выжили. Но чтобы это обнаружить - нужна была одна метрика: **cost per user vs ARPU**. Если подписка USD 10 в месяц, а LLM на одного пользователя стоит USD 6 - это не бизнес. Это субсидируемый сервис.
Langfuse и Helicone - observability-платформы специально для LLM. Трекают cost per request, распределяют по моделям, endpoints, пользователям. Helicone даёт spending alerts из коробки. Langfuse позволяет attach userId к каждому trace и считать unit economics автоматически. Для старта - достаточно своего Redis-based решения.
P95 cost per query - особая метрика. Средняя стоимость USD 0.005, а P95 - USD 0.04. Это значит: 5% запросов в 8 раз дороже остальных. Кто они? Один endpoint? Один тип пользователей? Один паттерн промпта? Dashboard с разбивкой по endpoint + model + userId отвечает на этот вопрос за секунды.
| Метрика | Формула | Здоровый диапазон |
|---|---|---|
| Cost per query | Total LLM cost / Total queries | USD 0.001 - USD 0.05 |
| Cost per user / month | Total LLM cost / MAU | < 30% от ARPU |
| LLM cost ratio | LLM cost / Revenue | < 15-20% |
| Cache hit savings | Cached queries × avg cost | Должен расти |
| P95 query cost | 95th percentile cost | < 10x средней |
Какая метрика критична для оценки жизнеспособности бизнес-модели AI-продукта?
Стоимость AI в бюджете - фиксированная статья, как хостинг
LLM cost - переменная, которая зависит от поведения пользователей, длины промптов и выбора моделей
Хостинг стоит одинаково независимо от того, что делают пользователи. LLM - нет. Один пользователь с длинными запросами может стоить в 100 раз дороже среднего. Один endpoint с плохим промптом способен удвоить месячный счёт. Стоимость LLM - это функция от кода, данных и поведения - и она меняется с каждым деплоем. Поэтому нужны per-user квоты, per-request бюджеты и real-time observability через Langfuse или Helicone.
Управление стоимостью LLM
- Output токены стоят в 4-5x дороже input - первая оптимизация: max_tokens и краткие инструкции в промпте
- Prompt compression даёт 40-70% экономии без потери качества: сжать system prompt, фильтровать RAG-чанки по relevanceScore, использовать компактные few-shot
- Model tiering: 60% задач - simple (gpt-4o-mini, 0.15/1M), 30% - medium (gpt-4o), 10% - complex (claude-sonnet). Экономия 40-55% суммарно
- Три уровня защиты ДО запроса: per-request лимит + daily limit + monthly limit. Пост-фактум мониторинг не останавливает расход
- Ключевая бизнес-метрика: LLM cost / ARPU per user. Больше 20-30% - сигнал к срочной оптимизации
Что дальше
Cost management задаёт бюджетные рамки. Следующий шаг - rate limiting, который защищает и от перерасхода, и от превышения квот API-провайдера.
- Rate Limiting для AI API — Budget alerts ограничивают деньги, rate limiting ограничивает количество запросов и токенов в единицу времени
- Кеширование LLM — Кеширование - самый эффективный способ снизить стоимость: нулевая стоимость при cache hit
- Observability — Cost dashboard - часть observability pipeline. Мониторинг расходов в реальном времени
Связанные уроки
- aie-05-api-integration — Учёт стоимости оборачивает каждый вызов API
- aie-28-caching-optimization — Кэширование - главный рычаг снижения стоимости
- aie-30-rate-limiting-ai — Лимиты ограничивают неконтролируемые траты
- aie-35-observability — Метрики по запросам вскрывают драйверы стоимости
- ml-08-regularization — Штрафуем дорогие пути, чтобы держаться в бюджете
- alg-20-greedy