Feast vs. Tecton: капіталізація власної інфраструктури feature store за ASC 350-40, коли ви створюєте, а не купуєте

Ваша команда ML щойно витратила п'ять людино-місяців інженерної роботи на розгортання feature store з відкритим кодом. Ваш фінансовий контролер дивиться на розрахунок заробітної плати й ставить питання, якого ніхто в команді не очікував: ці $180 000 інженерного часу — це витрати, що зменшать прибуток цього кварталу, чи актив, який сяде на баланс? Відповідь змінює ваш burn multiple, розрахунок runway і — якщо ви залучаєте кошти — історію, яку розповідає ваша фінансова звітність. І вона повністю змінюється залежно від того, чи ви створювали на базі Feast, чи купували Tecton.

Feature store — це інфраструктура, яка керує, зберігає та обслуговує ознаки машинного навчання як для тренування, так і для інференсу в реальному часі. Його головне завдання — запобігати розбіжності між тренуванням та обслуговуванням: гарантувати, що модель бачить у продакшені точно ті самі ознаки, на яких тренувалася. Архітектура має п'ять рухомих частин — офлайн-сховище для тренувальних даних, онлайн-сховище для обслуговування з низькою затримкою, конвеєри ознак, які обчислюють значення, центральний реєстр ознак та API обслуговування. Коли команди обирають між Feast і Tecton, вони обирають між двома дуже різними моделями володіння, і кожна модель дає дуже різний бухгалтерський підхід.

Feast vs. Tecton: компроміс між створенням і купівлею​

Feast — провідний feature store з відкритим кодом: безкоштовний у використанні, розгортається самостійно та гнучкий. Ви самі керуєте онлайн-сховищем (зазвичай Redis або DynamoDB), офлайн-сховищем (S3, BigQuery або Snowflake) і самі відповідаєте за кожне оновлення, кожне чергування on-call та кожне рішення щодо масштабування. Tecton — повністю керована комерційна альтернатива, створена членами команди, що стояла за платформою Michelangelo від Uber. Він бере на себе онлайн- та офлайн-обслуговування, потокове обчислення ознак і вбудований моніторинг ознак за корпоративним SaaS-контрактом.

Стандартне порівняння виглядає так:

У бухгалтерської версії цієї таблиці є ще один рядок: де з'являються гроші. З Tecton майже вся вартість надходить як рахунок від постачальника — витрати на підписку. З Feast ліцензійний рядок дорівнює нулю, а реальна вартість ховається в зарплаті інженерів: тижні, які ваші дата-інженери витрачають на розгортання реєстру, написання конвеєрів ознак, налаштування онлайн-сховища та створення моніторингу, який Feast не постачає. Інфраструктура з відкритим кодом «без ліцензійних витрат» все одно потребує рядка P&L на інженерні години, і саме цей рядок регулює ASC 350-40.

Бухгалтерське питання: що насправді каже ASC 350-40​

За US GAAP витрати на внутрішнє програмне забезпечення регулюються ASC 350-40, який розподіляє кожен долар проєкту з програмного забезпечення за однією з трьох стадій (загальні принципи дивіться в нашому практичному посібнику з рішення «капіталізувати чи визнавати витратами»):

1. Попередня стадія проєкту — визнається витратами в міру виникнення. Оцінка постачальників, дослідницькі прототипи, порівняння Feast і Tecton, дослідження здійсненності та сам аналіз «створити чи купити». Усе це одразу потрапляє в P&L.
2. Стадія розробки застосунку — капіталізуються прийнятні витрати. Коли керівництво затвердило та взяло зобов'язання щодо проєкту, витрати на проєктування, написання коду, конфігурацію, тестування та інтеграцію програмного забезпечення капіталізуються як актив та амортизуються протягом строку його корисної служби. Це єдина стадія, яка створює актив.
3. Постімплементаційна та операційна стадія — визнається витратами в міру виникнення. Навчання, підтримка, виправлення помилок та поточна діяльність після запуску. Нова функціональність, додана пізніше, може відновити капіталізацію, але підтримка роботи системи — ніколи.

Щоб увійти в стадію розробки застосунку, мають виконуватися дві умови: керівництво з відповідними повноваженнями затвердило проєкт (неявно чи явно), і є ймовірним, що проєкт буде завершено, а програмне забезпечення використано за призначенням. Доки обидві умови не виконані, кожен долар — усе ще витрати попередньої стадії, включно з «прототипом», який пізніше стане продакшеном.

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

Відображення роботи над feature store на три стадії​

Ось як типовий проєкт на Feast відображається на ASC 350-40:

Витрати: оцінка. Ваша команда витрачає три тижні на порівняння Feast і Tecton, пробує зразковий конвеєр і читає документацію постачальника. Попередня стадія — витрати. Це так, навіть якщо код прототипу пізніше буде використано в продакшені; стадія визначається метою діяльності на той момент, а не тим, чим стане код.

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

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

Найпоширеніша причина невдач — відсутній паперовий слід. Капіталізація без одночасного відстеження часу за проєктами та стадіями рідко витримує аудит. Якщо час ваших інженерів не відстежується окремо за створенням feature store і за звичайною діяльністю, ваш аудитор визнає витратами все — що може бути правильною відповіддю, але це має бути рішенням, а не типовим результатом.

Що змінюється, коли ви натомість купуєте Tecton​

Купівля керованого feature store перевертає бухгалтерську картину. Tecton — це сервісний контракт, а не програмне забезпечення, яким ви володієте, тож плата за підписку є операційними витратами, що визнаються протягом строку контракту — просто, передбачувано та захищено від аудиторських зауважень.

Тонкий момент — впровадження. Налаштування SaaS-платформи для ваших потреб — інтеграція Tecton з вашим сховищем даних, підключення API обслуговування до інференсу, міграція визначень ознак — підпорядковується тій самій логіці ASC 350-40 за настановами щодо хмарних обчислень: витрати на впровадження на стадії розробки застосунку можуть відповідати критеріям капіталізації, навіть попри те, що базове програмне забезпечення розміщене у постачальника. На практиці впровадження Tecton достатньо короткі, що багато малих компаній визнають їх витратами з міркувань суттєвості. Але якщо ваша інтеграція сягає шестизначних витрат інженерного часу, застосовується той самий аналіз стадій і той самий стандарт документування.

Тут є стратегічна примітка для засновників, які залучають кошти. Капіталізація проєкту на Feast покращує EBITDA поточного періоду та показники валової маржі ціною зростаючого амортизаційного тягаря та активу, який прискіпливо вивчатиме команда due diligence покупця. Визнання підписки Tecton витратами зберігає чесність P&L щодо run-rate burn, але робить показники цього року важчими. Жоден підхід не є «кращим» — але інвестори запитають, який ви обрали і чому, тож обирайте свідомо та документуйте обґрунтування.

ASU 2025-06: модель стадій зникає​

Тристороння модель походить з 1998 року, коли програмне забезпечення створювалося послідовними водоспадними фазами з чіткими межами. Вона погано підходить для гнучкої, ітеративної роботи над feature store — який спринт є «попереднім», коли кожен спринт випускається в продакшен? FASB погодився. У вересні 2025 року він випустив ASU 2025-06, який скасовує правила, засновані на стадіях, і замінює їх принципоорієнтованою моделлю, що зосереджується на тому, чи залишається значна невизначеність розробки.

За новою моделлю капіталізація починається, коли керівництво затвердило проєкт, завершення та використання за призначенням є ймовірними, а концепція подолала значну невизначеність щодо вимог до продуктивності, підходу до розробки чи здійсненності. Він набуває чинності для фінансових років, що починаються після 15 грудня 2027 року, з дозволом дострокового застосування. Для проєкту feature store, що стартує сьогодні, практична порада незмінна: отримайте меморандум про затвердження, відстежуйте час за створенням та відокремлюйте оцінку від будівництва. Ці звички задовольняють і старі стадії, і нові принципи.

Практичний посібник для вашого проєкту feature store​

Обираєте ви Feast, Tecton чи третій варіант, п'ять практик зберігають облік чистим:

Отримайте письмове затвердження до початку створення. Лист від CTO, який схвалює створення на Feast, бюджет і передбачуване продакшн-використання, задовольняє поріг затвердження. Поставте дату. Аудитори запитують цей документ першим.

Відстежуйте інженерний час за стадіями з першого дня. Дослідницькі прототипи — в одному кошику, робота над продакшн-збіркою — в іншому, підтримка після запуску — в третьому. Відстеження часу за тегами або маркування спринтів — обидва працюють; відтворення розподілу з пам'яті через шість місяців — ні.

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

Оберіть строк амортизації, який зможете обґрунтувати. Внутрішнє програмне забезпечення зазвичай амортизується рівномірно протягом трьох-п'яти років. Feature store, побудований на швидкозмінному відкритому коді, де мажорна версія Feast може змусити до перебудови, схиляє до коротшого строку. Задокументуйте обґрунтування в меморандумі про капіталізацію.

Тестуйте на знецінення, коли змінюються факти. Якщо ви покидаєте створення на Feast на півдорозі та підписуєте контракт з Tecton, капіталізований актив знецінюється — спишіть його. Те саме стосується випадку, коли півот знищує продуктову лінію, якій служив feature store. Капіталізоване програмне забезпечення, яке більше не має застосування, не є активом.

Поширені помилки, що спричиняють аудиторські коригування​

Помилки, які аудитори знаходять у капіталізації інфраструктури, пригнічуюче однотипні. Капіталізація фази оцінки — порівняння постачальників, proof of concept, прототипу — найчастіша; робота попередньої стадії ніколи не підлягає капіталізації, хоч би якою корисною вона виявилася. Капіталізація підтримки під виглядом розробки йде другою: налаштування затримки обслуговування та довантаження ознак — це операційна діяльність, а не будівництво. Третя — відсутній меморандум: капіталізоване сальдо без документа про затвердження, без аналізу стадій і без обґрунтування амортизації визнається витратами за загальними принципами. Четверта — амортизація за вигаданими строками: десять років для інфраструктури, прив'язаної до проєкту з відкритим кодом, що щороку випускає зміни, які ламають сумісність. І п'ята — повне забуття хмарного рахунку: команди, які ретельно капіталізують зарплату, ігноруючи шестизначний річний run rate на DynamoDB та обчислення, викривляють порівняння «створити чи купити», яке й обґрунтувало проєкт.

Відстежуйте створення як актив, яким воно може стати​

Рішення Feast проти Tecton зазвичай подають як інженерну гордість проти зручності постачальника. Переформулюйте його як фінансове питання — і компроміс загострюється: Feast перетворює грошову винагороду на капітальний актив з амортизаційним хвостом, тоді як Tecton перетворює ту саму можливість на чисту операційну витрату з датою поновлення. Ваша модель runway, ваша валова маржа та ваша історія для due diligence — усе змінюється разом із вибором, і саме тому бухгалтерський облік заслуговує на місце на архітектурному рев'ю, а не на виносці після нього.

Це починається зі звичайної бухгалтерської дисципліни: час із тегами проєктів, датоване затвердження, рахунки підрядників, прив'язані до створення, та меморандум про капіталізацію, який ваш аудитор зможе простежити. Якщо витрати на ваш feature store зараз живуть як нерозподілена зарплата інженерів в одному рахунку, ви вже втратили можливість капіталізації — записи неможливо відтворити заднім числом.

Спростіть своє фінансове управління​

Масштабуючи свою інфраструктуру ML, підтримувати чіткі фінансові записи для рішень «створити чи купити», капіталізованого програмного забезпечення та графіків амортизації — це суттєво. Beancount.io пропонує бухгалтерію у простому тексті, яка дає вам повну прозорість і контроль над вашими фінансовими даними — жодних чорних скриньок, жодної залежності від постачальника. Почніть безкоштовно і дізнайтеся, чому розробники та фінансові фахівці переходять на бухгалтерію у простому тексті.