Засновник, що керує AI-асистентом для написання текстів, розповів мені, що його "витрати на програмне забезпечення" становили $40,000 на місяць. Коли ми розклали цю суму, $34,000 з неї виявилися рахунками за API OpenAI та Anthropic — і жодна з них не входила до його собівартості реалізованої продукції. Вона лежала в загальному рядку "Програмне забезпечення та підписки" прямо поруч із інструментом для управління проєктами за $19 на місяць. Заявлена валова маржа становила 91%. Реальна валова маржа, після того як інференс перемістили туди, де йому й місце, становила 58%.
Це не бухгалтерська дрібниця. Це різниця між бізнесом, який виглядає як програмне забезпечення, і бізнесом, який поводиться як завод — де кожна продана одиниця споживає реальний, змінний ресурс. Якщо ви будуєте продукт на основі GPT-5, Claude, Gemini чи будь-якої іншої хостованої моделі, ваш рахунок за LLM — це не накладні витрати. Це собівартість реалізованої продукції, і якщо трактувати її інакше, ви насправді не знаєте, скільки грошей заробляєте.
Чому цю помилку так легко припуститися
Традиційний SaaS привчив ціле покоління засновників думати про витрати на програмне забезпечення як про фіксовані. Ви платите за хостинг, платите за свою CRM, платите за Slack — і жоден із цих рахунків не змінюється синхронно з тим, наскільки активно якийсь один клієнт користується вашим продуктом. Тож коли приходить перший рахунок за API від OpenAI, природно віднести його до тієї самої ментальної категорії: "інструменти, за які ми платимо, щоб вести бізнес."
Проблема в тому, що рахунок за LLM API поводиться не як підписка на SaaS. Він поводиться як сировина. Щоразу, коли клієнт надсилає запит, ви витрачаєте токени, а кожен токен має свою ціну. Клієнт, який робить 50 запитів на день, обходиться вам відчутно дорожче в обслуговуванні, ніж той, хто робить 2. Це підручникове визначення собівартості реалізованої продукції: витрата, що масштабується прямо пропорційно наданню вашого продукту конкретному клієнту, на відміну від витрати, яку ви платили б просто для підтримки роботи бізнесу незалежно від використання.
Галузеві дані підтверджують, наскільки суттєвим це стало. Звіт ICONIQ "State of AI" за січень 2026 року показав, що інференс тепер у середньому становить 23% від загального доходу в AI B2B-компаній на стадії масштабування, а 84% цих компаній повідомили про ерозію валової маржі на шість відсоткових пунктів або більше, безпосередньо пов'язану з витратами на AI-інфраструктуру. Це не похибка округлення, яку можна списати на "різні операційні витрати." Це часто єдиний найбільший фактор витрат у бізнесі, і саме так до нього й варто ставитися.
Де правильно провести межу між собівартістю та операційними витратами
Правило, яке розмежовує собівартість і операційні витрати, не змінилося лише через те, що вхідним ресурсом тепер є API моделі, а не склад, повний деталей: витрати на надання вашого продукту клієнту, що платить, належать до собівартості; витрати на створення вашого продукту належать до R&D у складі операційних витрат. Застосовано до AI-обгортки, цей поділ виглядає так:
Належить до собівартості:
- Виробничі витрати на інференс — кожен виклик API, який ваш робочий продукт робить від імені клієнта, що платить, будь то завершення чату, виклик ембедингу, прохід класифікації чи цикл викликів інструментів агента
- Хостинг моделі / обчислення на GPU — якщо ви запускаєте модель з відкритими вагами на власній або орендованій інфраструктурі замість виклику хостованого API, час обчислень, що припадає на обслуговування клієнтських запитів
- Допоміжна інференс-інфраструктура — запити до векторної бази даних, запуски конвеєра ембедингів та накладні витрати на оркестрацію, які існують спеціально для обслуговування виробничих запитів
- AI-специфічні витрати на підтримку — інженер підтримки, чия робота полягає в сортуванні проблем із результатами моделі для клієнтів, — це витрата на надання продукту, а не загальна витрата SG&A
Належить до операційних витрат (зазвичай R&D):
- Інференс для розробки та тестування — кожен запит, який інженер надсилає під час ітерації над фічею, налагодження регресії чи оцінки нової версії моделі
- Донавчання та оціночні прогони — створення чи покращення моделі — це R&D, а не надання продукту
- Внутрішні AI-інструменти — місця ChatGPT Enterprise чи ліцензії GitHub Copilot вашої команди — це витрата на продуктивність, а не витрата на обслуговування клієнтів
Практичний крок, який робить цей поділ можливим, нудний, але важливий: використовуйте окремі API-ключі або білінгові проєкти для виробничого та розробницького трафіку з першого дня. Якщо ваші інженери тестують запити з тим самим ключем, який ваш продукт використовує в продакшені, у вас немає способу коректно розподілити рахунок постфактум, і щомісяця ви завищуватимете або занижуватимете свою реальну маржу.
Як виглядає "реальна" валова маржа для AI-продуктів
Коли ви зробите цей поділ, очікуйте, що результат виглядатиме інакше, ніж ви звикли. Традиційні SaaS-бізнеси майже за замовчуванням орієнтуються на валову маржу 70–80%. AI-продукти, створені з нуля під AI, не досягають цього так само. Посібник із ціноутворення Bessemer Venture Partners за лютий 2026 року оцінює типову валову маржу AI-продуктів у 50–60%, що значно нижче діапазону 80–90% для традиційного SaaS, а дані ICONIQ показують, що середня по галузі валова маржа AI-продуктів зростає — але лише до 52%, порівняно з 41% у 2024 році та 45% у 2025 році.
Корисне емпіричне правило, що виникло серед операторів, які уважно це відстежують: тримайте витрати на LLM на рівні приблизно менше 20% від загальної собівартості, якщо хочете стійку, масштабовану бізнес-модель. Переступивши цей поріг, стиснення маржі, як правило, прискорюється в міру росту, а не послаблюється, бо більші клієнти використовують продукт більше, а не менше. Деякі категорії з інтенсивним використанням AI — кодові асистенти, агенти для обробки документів — мають співвідношення витрат на LLM у 30–40% від собівартості і все ще залишаються життєздатними, але лише тому, що вони свідомо встановили ціни з урахуванням цієї реальності, а не підлаштовувалися під неї заднім числом.
Число, яке насправді має значення, — це не ваша змішана валова маржа по всій компанії, а вартість на клієнта. Активні користувачі AI-функції можуть коштувати вам у 50–100 разів більше в чистому інференсі для обслуговування, ніж легкі користувачі на тому самому тарифному плані. Якщо ви цього не відстежуєте, ви не знаєте, які клієнти прибуткові, а яких ви тихо субсидуєте щомісяця. Тарифний план із фіксованою ціною, який виглядав нормально на перших десяти клієнтах, може почати приносити збитки в той момент, коли один із них переведе робочий процес у продакшн і збільшить обсяг своїх запитів у 20 разів.
Побудова моделі вартості на запит
Щоб почати, вам не потрібні складні інструменти — вам потрібна дисципліна в логуванні правильних чисел для кожного запиту. Базова формула проста:
request_cost = (input_tokens / 1,000,000) × input_price_per_million
+ (output_tokens / 1,000,000) × output_price_per_millionВихідні токени зазвичай коштують у 2–5 разів дорожче за одиницю, ніж вхідні, тому що генерація вимагає більше обчислень, ніж читання запиту, — тож модель вартості запиту, яка відстежує лише загальну кількість токенів без розділення на вхідні й вихідні, систематично неправильно оцінюватиме будь-що з довгими завершеннями. Як робочий приклад за цінами середини 2026 року: запит із 2,000 вхідних токенів і відповіддю на 500 токенів проти популярної моделі середнього рівня (приблизно $3 за вхідні / $15 за вихідні токени за мільйон) коштує близько $0.0135. Запустіть той самий тип запиту 50,000 разів на місяць, і ви отримаєте близько $675 витрат на інференс лише для цієї однієї функції — число, яке непомітне, якщо воно поховане в п'ятизначному рядку "витрати на хмару," але дуже помітне, щойно його прив'язано до функції та сегмента клієнтів, який його породив.
Щоб зробити це практичним:
- Логуйте кількість токенів для кожного запиту, а не лише вартість — більшість провайдерів моделей повертають кількість вхідних/вихідних токенів прямо у відповіді API, тож це зміна в логуванні, а не нове джерело даних.
- Позначайте кожен запит ID клієнта та ідентифікатором функції, щоб можна було агрегувати витрати за обліковим записом і за продуктовою поверхнею, а не лише за місяцем.
- Обчислюйте вартість на клієнта за розрахунковий період і порівнюйте її з тим, що цей клієнт вам платить. Це число говорить вам, чи справді ваші тарифні плани відповідають вашій вартості надання послуги, а не вашій змішаній середній маржі.
- Спрямовуйте запити до дешевших моделей там, де це дозволяє якість. Не кожен запит потребує вашої найпотужнішої (і найдорожчої) моделі — класифікація, вилучення даних і прості завдання форматування часто прийнятно виконуються меншою, дешевшою моделлю, а маршрутизація моделей — один із небагатьох важелів маржі, який ви повністю контролюєте, на відміну від цін провайдера.
Ціноутворення для захисту маржі, яку ви щойно знайшли
Щойно інференс правильно класифіковано як собівартість, ваша розмова про ціноутворення змінюється. Поширений орієнтир, який використовують оператори, — стягувати приблизно у 3–5 разів більше за вашу вартість токена на одиницю, так щоб завдання вартістю $0.30 було оцінене в $1.00 або більше — не тому, що цей множник є магічним, а тому, що він залишає запас для покриття варіативності використання, волатильності цін на моделі та витрат на підтримку й інфраструктуру, що супроводжують чистий інференс.
Оплата на основі використання стала стандартним способом, яким AI-компанії тримають ціноутворення та собівартість синхронізованими: стягуйте плату за токен, за запит або за виконане завдання, і ваш дохід масштабуватиметься разом із тією самою змінною, що визначає вашу вартість, замість того, щоб розходитися з нею так, як це відбувається з фіксованою підпискою під час сплесків використання. Якщо ви ще не готові повністю перейти на оплату на основі використання, побудуйте принаймні тарифи з гарантованим мінімумом плюс доплата за перевищення, щоб клієнт, який значно перевищує типове використання, тихо не перетворився на збитковий продукт до кінця місяця.
Тримайте свою структуру витрат такою ж перевірюваною, як і свій код
Ніщо з цього не є необов'язковою бухгалтерською гігієною — це різниця між знанням того, що ваша бізнес-модель працює, і виявленням того, що вона не працює, під час дью-ділідженс дзвінка щодо залучення інвестицій, коли асоціат інвестора будує модель вартості на клієнта, яку вам варто було побудувати ще шість місяців тому. Засновники, які уникають цієї розмови, — це ті, хто позначає витрати на інференс клієнтами й функціями з першого ж виклику API, а не ті, хто чекає, поки рахунок за OpenAI стане надто великим, щоб його ігнорувати.
