У вашому рахунку від Tecton стоїть одна цифра, ваш рахунок від AWS тихо несе решту, і жоден із цих документів не називає себе повною вартістю обслуговування фіч. Саме в цьому розриві й криється пастка. Tecton формує ціну за споживання — обчислювальні кредити за пайплайни, які він запускає, плюс хмарні ресурси, що ці пайплайни споживають у вашому власному акаунті — тож рахунок, який ви отримуєте від Tecton, завжди є лише частиною витрат. Якщо ваші книги фіксують рахунок і на цьому зупиняються, ваша собівартість продажів занижена, ваш валовий прибуток завищений, і кожне цінове рішення, яке ви ухвалюєте на основі цього прибутку, спирається на цифру, яка ніколи не була повною.
Ця стаття пояснює, як Tecton насправді вимірює й виставляє рахунки, чому продакшн-обслуговування фіч належить до собівартості продажів, як обліковувати передплачені кредити й зобов'язання щодо споживання та як звірити все це на кінець місяця, щоб кожен долар потрапив на правильний рахунок.
Як Tecton вимірює: Feature Views, а не місця
Tecton — це керована платформа фіч для машинного навчання. Ви визначаєте перетворення над вашими даними як feature views, Tecton обчислює їх у пакетних або потокових пайплайнах і подає результати вашим моделям — офлайн-сховище для масштабного вилучення під час навчання та онлайн-сховище для вилучення з низькою затримкою під час живого інференсу. Тут немає ліцензій на кожне робоче місце, які треба рахувати. Ви платите за те, що платформа споживає під час обчислення, зберігання й обслуговування ваших фіч.
Це споживання поділяється на два кошики, які виставляються в рахунках у двох різних місцях, і це перше, що варто засвоїти.
Перший кошик — кредити Tecton. Вони покривають обчислення, якими Tecton керує від вашого імені: кредити потокових обчислень Spark для потокових feature views, кредити пакетних обчислень Spark для пакетних feature views. Ваше використання платформи перетворюється на кредити, і ці кредити з'являються в рахунку Tecton.
Другий кошик — сама інфраструктура, і рахунки за неї виставляються через ваш власний хмарний акаунт. Tecton керує обчислювальними ресурсами та ресурсами зберігання у вашому середовищі AWS чи GCP, тож читання й записи в онлайн-сховищі, обчислення кластера Spark, зберігання в онлайн-сховищі та зберігання в S3 — усе це потрапляє до вашого хмарного рахунку, а не до Tecton. Команда, яка закуповує через один канал, а звіряє через інший, завжди знайде розрив. Вирішіть раз і назавжди, що справжня вартість feature view — це сума обох кошиків, і переконайтеся, що ваш щомісячний збір даних охоплює і рахунок Tecton, і позначені теґами рядки хмарного рахунку.
Потокові та пакетні feature views споживають по-різному
Компоненти витрат відрізняються за типом feature view, і знання того, які саме ви запускаєте, підказує, за якими рядками стежити.
Потокові feature views охоплюють читання й записи в онлайн-сховищі, обчислення кластера потокового Spark, кредити потокових обчислень Tecton Spark, зберігання в S3 та зберігання в онлайн-сховищі. Пакетні feature views мають схожий перелік — читання й записи в онлайн-сховищі, обчислення кластера пакетних завдань Spark, кредити пакетних обчислень Tecton Spark та зберігання в S3 — за винятком елементів, специфічних для потокової обробки.
Параметри, що рухають рахунок, — це проєктні рішення, які ваші ML-інженери ухвалюють щодня. Безперервна потокова обробка робить контрольні точки й записи набагато частіше, ніж обробка за інтервалами, тож коштує дорожче. Більші вікна агрегації потребують більше обчислень. Довші водяні знаки для даних, що надходять із запізненням, підвищують вимоги до пам'яті. Конфігурація кластера безпосередньо визначає ціну кожного завдання. Ущільнення даних знижує вартість зберігання й покращує продуктивність читання. Жодне з цих налаштувань не є фінансовим; це інженерні налаштування з фінансовими наслідками, і саме тому облік цієї платформи починається з розмови між двома командами про те, які feature views існують і на що вони налаштовані.
Ієрархія витрат підказує, куди йдуть гроші
Власні рекомендації Tecton ранжують вплив на витрати від найвищого до найнижчого, і цей порядок варто запам'ятати, бо він підказує, звідки з'являться ваші несподіванки.
Операції з онлайн-сховищем стоять на першому місці. Записи в онлайн-сховище зазвичай є найбільшою інфраструктурною витратою, особливо під час бекфілів — переобчислення історичних фіч для нового або зміненого feature view — або за безперервної потокової обробки. Бекфіл — це запланований сплеск: дні або тижні історичних обчислень і потік записів, стиснуті в одне вікно. Якщо ніхто не попередить фінансовий відділ про його наближення, місяць, коли він припадає, виглядатиме як перевитрата, а не як інвестиція.
Обчислювальні ресурси стоять другими: витрати кластера Spark на потокову та пакетну обробку, що змінюються залежно від конфігурації та навантаження. Зберігання стоїть третім: зберігання й читання в онлайн-сховищі плюс S3, зазвичай із меншим впливом, ніж обчислення й записи.
Практичний наслідок полягає в тому, що ваш рахунок визначається записами й подіями обчислень, а не тим, скільки людей входить у консоль. Планування потужностей тут означає керування бекфілами, режимами обробки та вікнами агрегації — а не кількістю персоналу.
Чому продакшн-обслуговування фіч — це COGS
Згідно з US GAAP, собівартість продажів SaaS-компанії — собівартість виторгу — включає прямі витрати на надання послуги, за яку платять клієнти: інфраструктуру хостингу, хмарні обчислення й зберігання, стороннє програмне забезпечення, вбудоване в продукт, і все інше, що масштабується з використанням. Обслуговування фіч для продакшн-продукту ML легко проходить цю планку. Коли ваша модель шахрайства оцінює транзакцію, ваш рекомендаційний рушій ранжує стрічку, а ваша модель ціноутворення виставляє ставку, читання в онлайн-сховищі й пайплайни, що підтримують актуальність цих фіч, є настільки ж прямими витратами на надання послуги, як і сервери застосунку за ними.
Ця класифікація важлива, бо вона безпосередньо впливає на валовий прибуток — показник, який інвестори, кредитори й покупці використовують, щоб оцінити, чи працює економіка вашого продукту. Якщо розмістити витрати на обслуговування нижче лінії в загальних операційних витратах, це завищує валовий прибуток і приховує історію масштабування. Команда дью-ділідженсу все одно перезіставить ваш головний реєстр під стандартне визначення COGS для SaaS; правильна класифікація від початку означає, що ваші власні дашборди розповідають ту саму історію, яку обчислить сторонній спостерігач.
Однак не кожен долар Tecton належить до COGS. Розподіл іде за використанням, а не за постачальником:
- Продакшн-обслуговування — це COGS. Читання й записи в онлайн-сховищі для живого інференсу, потокові та пакетні пайплайни, що підтримують актуальність продакшн-фіч, і зберігання за ними — усе це забезпечує орієнтовану на клієнта послугу.
- Експериментування й стендінґ — це операційні витрати. Розробницькі feature views, офлайн-експериментування й стендінґ-середовища підтримують дослідження та розробку, а не надання послуги. Відносьте їх до R&D.
- Робота лише для навчання потребує судження. Офлайн-обчислення фіч, що існує виключно для навчання наступної версії моделі, виглядає радше як R&D, ніж як надання послуги; той самий пайплайн, що живить онлайн-сховище для живого обслуговування, — це COGS. Коли один feature view робить і те, і те, розподіляйте за обґрунтованим драйвером — позначені теґами хмарні витрати за середовищами є найчистішим із тих, що має більшість команд.
Tecton позначає теґами обчислювальні інстанси й ресурси онлайн-сховища за feature view, тож дані для розподілу існують у вашому оглядачі хмарних витрат. Завдання обліку — визначити зіставлення один раз: які feature views обслуговують продакшн, а які — експериментування, — а потім застосовувати його щомісяця, а не переглядати його заново на кожному закритті.
Купівля Tecton — це витрати; побудова еквівалента може бути капіталізацією
Ще одна класифікація, яку варто зробити правильно: команда, що купує Tecton, відносить споживання до витрат, як описано вище, але команда, що будує власне сховище фіч на програмному забезпеченні з відкритим кодом, натомість стикається з питанням капіталізації. Програмне забезпечення для внутрішнього використання, розроблене для ваших власних операцій, може кваліфікуватися на капіталізацію, щойно проєкт проходить попередню стадію, що перетворює інженерні зарплати й інфраструктуру на актив, що амортизується, а не на витрати періоду.
Жоден із цих підходів не є необов'язковим штрихом. Якщо ви використовуєте Tecton, не капіталізуйте його рахунки так, ніби ви побудували платформу. Якщо ви переходите зі саморобного сховища на Tecton, старий капіталізований актив продовжує амортизуватися, тоді як нове споживання потрапляє до COGS — два різні рядки, дві різні історії, обидві правильні одночасно.
Передплачені кредити й зобов'язання — спершу активи, витрати згодом
Платформи з оплатою за споживання зазвичай продають передплачені кредити або річні зобов'язання щодо витрат, і облік обох слідує принципу відповідності: зафіксуйте платіж як актив, а потім відносьте його до витрат у міру використання вигоди. Долар, переказаний постачальнику авансом, ще не є витратами ні на що. Він стає COGS, коли кредити згорають на продакшн-обслуговуванні, R&D, коли вони згорають на експериментуванні, і збитком, якщо вони минають невикористаними.
На практиці це означає три проведення, а не одне. Коли ви купуєте кредити, дебетуйте актив із передплати й кредитуйте грошові кошти. Щомісяця зменшуйте залишок на те, що фактично спожито — продакшн-споживання до COGS, стендінґ-споживання до R&D. Якщо кредити мають дату закінчення терміну дії, внесіть її до календаря; залишок, що втратив чинність, — це реальний збиток, який заслуговує на заплановане списання, а не на виявлення під час прибирання наступного року.
Мінімуми «бери або плати» додають нарахування зверху. Якщо ваш контракт зобов'язує вас до мінімальних квартальних витрат, ви винні більше з фактичного споживання та мінімуму. Коли споживання падає нижче зобов'язання ближче до кінця періоду, нарахуйте нестачу, яку ви все одно будете винні. Рахунок надійде пізніше, але зобов'язання існує на дату балансу, і закриття має його відобразити.
Звірка на кінець місяця: два рахунки, одна істина
Tecton публікує журнали оплачуваного використання — детальні записи CSV про використання платформи та те, як воно перетворюється на кредити, що потрапляють до вашого власного об'єктного сховища приблизно через день-два після використання. У поєднанні з позначеними теґами хмарними витратами ці журнали — це показники лічильників, на яких тримається ваша звірка. Розглядайте щомісячний процес як зіставлення трьох джерел одне з одним: журналів використання, рахунку Tecton і хмарного рахунку.
Робочий контрольний список закриття виглядає так:
- Витягніть журнали використання за повний місяць. Переконайтеся, що присутні кредити кожного продакшн-фіча й кожного експерименту, включно з останніми двома днями — затримка журналу означає, що закриття, проведене першого числа місяця, бракує даних. Або зачекайте на журнали, або нарахуйте останні дні за поточною ставкою й уточніть наступного місяця.
- Нарахуйте невиставлену частину Tecton. Як і більшість рахунків за споживання, рахунок надходить після періоду, який він покриває. Проведіть нарахування за оціненими кредитами місяця до COGS і R&D за розподілом середовищ, а потім сторнуйте й уточніть, коли надійде рахунок.
- Витягніть позначені теґами хмарні витрати. Відфільтруйте оглядач хмарних витрат за теґами feature view за той самий період. Це другий кошик — кластери Spark, операції з онлайн-сховищем, зберігання — і його потрібно так само розділити на продакшн і стендінґ.
- Звірте журнали з рахунком і хмарним рахунком. Журнали використання мають узгоджуватися з рахунком Tecton; позначені теґами хмарні рядки мають рухатися в тому самому напрямку. Місяць бекфілу дасть сплеск в обох. Рахунок, що розходиться з журналами, — це питання до білінгу, яке варто порушити зараз, а не під час поновлення.
- Зменште передплати й зобов'язання. Віднесіть спожиті кредити з активу передплати до витрат, нарахуйте будь-яку нестачу за зобов'язанням і переконайтеся, що залишки все ще виглядають придатними до використання перед закінченням терміну дії.
Найпоширеніша помилка — крок третій: старанно звіряти рахунок Tecton, поки витрати на хмарну частину ховаються в більшому рахунку за інфраструктуру під загальним хостингом. Якщо у вашому хмарному звіті один змішаний рядок обчислень, виправте теґування перед тим, як виправляти будь-що інше. Витрати без теґів неможливо розподілити, а нерозподілені витрати завжди опиняються десь не там.
Конкретний місяць у книгах
Припустімо, ваша ML-платформа за січень згоряє кредитами Tecton на 40 000 доларів на продакшн-обслуговування та 8 000 доларів на експериментування, плюс 12 000 доларів позначених теґами хмарних витрат, розподілених як 9 500 доларів продакшн і 2 500 доларів стендінґ. Ви також передплатили 100 000 доларів кредитів на початку кварталу. Січень у книгах виглядає так:
2026-01-01 open Assets:Cash:Operating USD
2026-01-01 open Assets:Prepaid:Tecton-Credits USD
2026-01-01 open Expenses:CostOfSales:Feature-Serving USD
2026-01-01 open Expenses:Research:ML-Experimentation USD
2026-01-01 open Liabilities:Accrued:Tecton USD
2026-01-01 open Liabilities:Accrued:Cloud USD
2026-01-05 * "Tecton" "Prepay Q1 consumption credits"
Assets:Prepaid:Tecton-Credits 100000.00 USD
Assets:Cash:Operating -100000.00 USD
2026-01-31 * "Tecton" "January credit consumption, prod serving plus experimentation"
Expenses:CostOfSales:Feature-Serving 40000.00 USD
Expenses:Research:ML-Experimentation 8000.00 USD
Assets:Prepaid:Tecton-Credits -48000.00 USD
2026-01-31 * "Cloud" "January tagged feature-platform infra, prod plus staging"
Expenses:CostOfSales:Feature-Serving 9500.00 USD
Expenses:Research:ML-Experimentation 2500.00 USD
Liabilities:Accrued:Cloud -12000.00 USDСхема узагальнюється: передплата — це актив, споживання переводить його у витрати за середовищами, а хмарна частина нараховується окремо, бо виставляється окремо. Якщо ваша команда веде книги в простому тексті, схеми відстеження витрат у документації природно поширюються на розподіл за кожним feature view, а подання дашбордів роблять тенденцію продакшн проти стендінґу видимою місяць за місяцем.
Помилки, що викривляють маржу
Чотири помилки повторюються знову й знову в командах, що керують ML-інфраструктурою з оплатою за споживання. Кожну дешево запобігти й дорого виправити через перераховані періоди.
Проведення рахунку Tecton як усієї вартості. Рахунок — це один кошик. Щомісяця хмарні обчислення, операції з онлайн-сховищем і зберігання додають другий кошик порівнянного розміру, і його пропуск занижує COGS приблизно вдвічі. Звіряйте обидва або не звітуйте про жоден.
Віднесення передплат до витрат у момент платежу. Покупка кредитів на 100 000 доларів — це не витрати в 100 000 доларів у місяці, коли йде переказ. Це актив, що перетворюється на витрати в міру згоряння кредитів. Віднесення до витрат у момент платежу завантажує квартал наперед, позбавляє пізніші місяці їхньої справжньої вартості й робить тенденції споживання нечитабельними.
Спрямування стендінґу через COGS. Експериментальні feature views, офлайн-бекфіли для досліджень моделей і стендінґ-середовища — це R&D. Змішування їх із витратами на обслуговування завищує COGS і карає валовий прибуток за роботу, яка ніколи не торкалася клієнта. Теґи feature view існують саме для того, щоб цей розподіл був чесним — використовуйте їх.
Пропуск нарахування. Рахунки за споживання виставляються із запізненням, журнали використання відстають на день-два, а хмарний рахунок надходить ще пізніше. Закриття без нарахування проводить частковий місяць як повний, і відсутні дні виринають як загадкове відхилення наступного місяця. Нарахуйте за поточною ставкою, а потім уточніть, коли надійдуть документи.
Ваш останній корисний крок цього місяця невеликий: відкрийте оглядач хмарних витрат, відфільтруйте за теґами feature view і переконайтеся, що число, яке ви бачите, — це число у ваших книгах. Якщо ці двоє ніколи не зустрічалися, ви щойно знайшли розрив, для усунення якого написано цю статтю.
