Чому рахунок дивує всіх

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

Єдина формула, яка потрібна

Вартість на користувача на місяць = кількість запитів × токени на запит × ціна токена. Усе інше — деталі. Недооцінюють зазвичай середній множник: токени на запит тихо зростають у міру того, як ви додаєте системні інструкції, знайдені документи та історію діалогу.

• Вхідні токени: ваші інструкції, повідомлення користувача і все, що ви до нього доклали
• Вихідні токени: зазвичай дорожчі й напряму залежать від того, наскільки довгі відповіді ви дозволяєте
• Ретраї та невдалі виклики — вони теж коштують грошей
• Фонові задачі: сумаризація, індексація, модерація, прогони оцінок

Важелі, які реально знижують рахунок

• Віддавайте легкі 80% запитів меншій моделі, а сильну вмикайте лише там, де це важливо
• Кешуйте стабільну частину промпту замість того, щоб слати її щоразу
• Кешуйте цілі відповіді на повторювані питання — у підтримці вони повторюються частіше, ніж здається
• Обрізайте історію діалогу замість надсилання всього з самого початку
• Діставайте менше, але точніше дібраних фрагментів замість «набити контекст»
• Обмежуйте довжину відповіді — більшість корисних відповідей коротші, ніж модель видає за замовчуванням

На практиці основна економія живе в маршрутизації та кешуванні. Скоротити рахунок більш ніж удвічі без помітної для користувача втрати якості — звична річ.

Бізнес-питання за технічним

Вартість запиту має сенс лише відносно його цінності. ІІ-функція, що економить оператору підтримки десять хвилин, коштує дорого — і виправдано. ІІ-функція, що переписує заголовок користувачу безкоштовного тарифу, не варта майже нічого, а користуватимуться нею постійно. Перш ніж оптимізувати технологію, вирішіть, які запити взагалі заслуговують бути дорогими.

Запобіжники, потрібні будь-якому продукту

• Ліміти на користувача та на акаунт із першого дня
• Жорстка місячна стеля витрат і алерт задовго до неї
• Логування вартості кожного запиту, щоб бачити, яка фіча дорога
• Дешевий запасний сценарій при досягненні ліміту замість падіння сервісу
• Захист від зловживань — боти швидко знаходять безкоштовний ІІ-ендпоінт

Висновок

Ціни на моделі падають, і це реальний попутний вітер. Але споживання зростає швидше, ніж дешевшають моделі, і фіча зі зламаною юніт-економікою не стане прибутковою, якщо просто зачекати. Рахуйте ІІ змінною собівартістю: моделюйте до запуску та вимірюйте після. Це і є різниця між ІІ-функцією, яка масштабується, і тією, що тихо з'їдає маржу.