Выкатили в прод диалогового ассистента на LLM. Метрики вовлечённости и удержания подросли, в поддержке меньше типичных претензий про отсутствие AI, а в финмодели строка расходов на вызовы модели раздулась так, что стоимость одного запроса оказалась в три раза выше заложенного в бюджет. CFO хочет устойчивую модель до ближайшего заседания совета директоров, пользователи ждут, что продукт не сломают.

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

Базовые вопросы перед началом оптимизации

Перед тем как обсуждать маршрутизацию моделей, я бы зафиксировал контекст. От него зависит, можно ли списать всё на ошибку выбора модели или проблема в объёме и токенах. Задача в том, чтобы выровнять юнит‑экономику AI‑фичи (стоимость запроса к модели, маржа) и не потерять продуктовый эффект и доверие пользователей.

Имеет смысл явно ответить на несколько базовых вопросов:

Что за фича по форме? Диалог, генерация контента, RAG по базе знаний, копилот в IDE, у каждого свой профиль запросов и требований к задержке.
Откуда взялась тройка к бюджету? Дорогая модель вместо заложенной, рост числа запросов, длинные промпты, комбинация факторов, процент вклада каждого слоя разный.
Как монетизируем? Включено в базовую цену, аддон, usage‑based. От этого зависит, чувствует ли пользователь рост затрат при росте активности (лимиты, кредиты, предупреждение о смене тарифа) или перерасход остаётся невидимым до внутренних отчётов.
Какой горизонт и сроки? Квартал на демонстрацию динамики, это один план работ. Закрыть дыру к пятнице, это другой темп.
Что значит нам нравится в цифрах? Если когорта пользователей AI даёт заметный прирост удержания или выручки с клиента (чек, LTV), вы не обсуждаете отключение ради экономии. Вы обсуждаете соотношение ценности и COGS.

Последний пункт, главный якорь. Как только в комнате появляется число вроде удержание у вовлечённых в AI выше на десятки процентов, разговор смещается с вырезания трат на то, как сохранить этот эффект и выровнять юнит‑экономику. Это ровно тот сдвиг, который отличает зрелого PM от человека, который оптимизирует одну строку P&L.

Цель не урезать стоимость, а вытянуть ценность на доллар

Формально цели звучат похоже, но ветки решений расходятся.

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

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

OpenAI. CNBC подтверждала оценки 2024 года о ~$3.7 млрд выручки при убытке порядка $5 млрд за год (цифры впервые шли из документов, The New York Times была первой), то есть масштаб затрат на вызовы модели и инфраструктуру на фоне роста ChatGPT и API.
Perplexity. The Information разбирала экономику маржи и классификации расходов, открытый пересказ с ориентирами по данным The Information приводит ~$34 млн выручки и ~$57 млн затрат на compute и web за 2024 год (часть расходов уходит в R&D, поэтому итоговый убыток зависит от учётной политики).
Character.AI. В официальном блоге компания пишет про ~20 000 запросов в секунду (масштаб порядка Google Search) и стоимость менее $0.01 за час разговора при оптимизации стека вызовов модели, то есть рост трафика напрямую бьёт по затратам.
Microsoft (Microsoft 365 Copilot, GitHub Copilot). Computerworld пересказывает disclosure Microsoft и оценку Forrester, ~15 млн платных мест Copilot на фоне ~450 млн пользователей Microsoft 365 (в статье, ~3.3% базы, оценка аналитика).
Cursor. TechCrunch со ссылкой на Bloomberg писал про ARR выше $500 млн и раунд с оценкой ~$9.9 млрд, то есть быстрый рост выручки при том, что продукт остаётся тяжёлым по вызовам модели на одного пользователя.

Структурно это та же задача, что и у половины B2B SaaS с LLM внутри.

Куда уходят деньги - четыре драйвера

Четыре драйвера перерасхода на LLM-фиче - модель, токены, объём, слой повторного использования

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

Выбор модели. Одна тяжёлая модель на все классы запросов, классический перекос. Простые задачи, классификация и короткое резюме, платят по тарифу размышляющей модели. В типичных прайс‑листах разница между маленькой и фронтирной задачами на порядки, и это первое место, где стоит искать рычаг, если профиль запросов смешанный.
Раздувание токенов. Длинный системный промпт на каждый вызов, десять чанков RAG там, где хватило бы пяти, мультитёрн, где в контекст уезжает вся история, всё это линейно умножает счёт.
Объём. Если фича реально зашла, фактическое число запросов на пользователя бьёт план. При плоской подписке пользователь не видит предельной цены запроса, и это нормально с точки зрения UX, но тогда рост объёма бьёт вас напрямую.
Нет слоя повторного использования. Exact‑match и семантический кэш, prompt caching у провайдера, батчи для офлайновых задач, всё, что уводит часть трафика с полного прогона через модель на каждый запрос или снижает стоимость повторяющегося контекста.

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

SCALE - пять рычагов

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

S — Smart routing

Разделить поток, простые запросы на компактные модели, тяжёлые рассуждения и генерация туда, где нужна полная мощность. На практике это классификатор плюс политика плюс A/B на качество, без сравнения как было и как стало вы не защитите ни пользователя, ни себя перед стейкхолдером.

C — Context и токены

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

A — Architecture, кэш, батчи, повтор

Семантический кэш для повторяющихся по смыслу вопросов, exact‑кэш для топа частых запросов из логов, prompt caching для статичного контекста, batch API для офлайна, стандартный набор, который редко внедряют за один день, но который хорошо стыкуется с метрикой cache hit rate.

L — Limits и ограничения

Если упираетесь в объём, tiered rate limits, справедливые квоты, UX, где действие AI требует явного намерения, а не фонового шума. Это не про наказание, а про снижение доли вызовов без ощутимой ценности для пользователя и продукта.

E — Economics

Если после S+C+A зазор к целевой марже остаётся, меняется граница монетизации, аддон, кредиты, открытие тяжёлых моделей только на верхних тарифах, usage‑based для сверхактивных. Здесь без совместной работы с финансами и продуктовым маркетингом не обойтись, и это нормально.

Как я бы уложил квартал

Недели 1–2. Измеримые быстрые победы без смены смысла продукта. Аудит промпта и лимитов длины ответа по типам запросов, топ частых вопросов из логов, exact‑кэш. Вы получаете baseline экономии и дисциплину учёта.
Недели 3–6. Маршрутизация как главный рычаг. Классификатор, политика маршрутизации, эксперименты на качестве. Это уже инвестиция в инфраструктуру, но с контролируемым риском, если вы не выкатываете всё сразу на сто процентов трафика.
Недели 7–12. Архитектурный слой и экономика. Семантический кэш, prompt caching, батчи для фоновых задач, параллельно кривая стоимости после оптимизаций и решение, нужны ли квоты и цена. Если инженерный пакет закрыл большую часть зазора, монетизацию можно не трогать, но на заседание совета директоров вы приходите уже с графиками, а не с надеждой.
Такой порядок осознанный, сначала то, что не ломает обещание продукта, затем то, что даёт максимум на единицу сложности, и только потом видимые для пользователя ограничения и деньги.

Метрики, за которыми стоит следить

Одна — north star.

North star. Отношение ценности AI для когорты (согласованная с финансами оценка вклада в выручку или удержание) к COGS вызовов модели для той же когорты. Без этого вы оптимизируете стоимость запроса в вакууме.

В сжатом виде одна и та же мысль в виде формулы (знаменатель и числитель нужно определить в одних и тех же единицах и для одной когорты):

North Star = ценность AI для когорты / COGS вызовов модели для той же когорты

Контрольные метрики. Смешанная стоимость запроса после оптимизаций, доля попаданий в кэш, доля трафика на дешёвом маршруте при неизменном или контролируемом качестве, CSAT и NPS по AI, retention когорты пользователей AI, средний weekly volume на пользователя, падение может быть и про качество, и про чрезмерные лимиты.

Контрольные метрики

Если коротко

Перерасход на LLM‑фиче при сильном продуктовом эффекте почти всегда задача на диагноз и последовательность, а не на выключение ради экономии. Рамка SCALE помогает не перепутать порядок работ и не убить retention ради строки в отчёте. Стейкхолдеры получают устойчивость, пользователи получают предсказуемое качество, команда получает план, который можно защитить цифрами, а не лозунгами.

Написано по мотивам статьи на MyPMinterview

Веду в ТГ канал про продукты и вайбкодинг — подписывайтесь https://t.me/supervisionpw

х3 бюджета на запрос — фреймворк SCALE для AI-фичи, которую нельзя убить