Вашият ML екип току-що похарчи пет инженерни месеца, за да изгради open-source feature store. Вашият финансов контролер поглежда ведомостта за заплати и задава въпрос, който никой в екипа не е очаквал: тези $180 000 инженерно време разход ли са, който удря това тримесечие, или актив, който стои в баланса? Отговорът променя вашия burn multiple, изчисленията ви за runway и — ако набирате финансиране — историята, която финансовите ви отчети разказват. И се променя напълно в зависимост от това дали сте изградили върху Feast, или сте купили Tecton.
Feature store е инфраструктурният слой, който управлява, съхранява и предоставя характеристики за машинно обучение както за обучение, така и за инференция в реално време. Основната му задача е да предотвратява разминаването между обучение и обслужване (training-serving skew): да гарантира, че моделът вижда точно същите характеристики в продукция, на които е бил обучен. Архитектурата има пет движещи се части — offline store за обучителни данни, online store за обслужване с ниска латентност, pipelines за характеристики, които изчисляват стойности, централен регистър на характеристиките и API-та за обслужване. Когато екипите избират между Feast и Tecton, те избират между два много различни модела на собственост, а всеки модел води до много различно счетоводно третиране.
Feast срещу Tecton: компромисът между изграждане и закупуване
Feast е водещият open-source feature store: безплатен за използване, self-hosted и гъвкав. Вие управлявате online store сами (обикновено Redis или DynamoDB), offline store сами (S3, BigQuery или Snowflake) и поемате отговорност за всяка актуализация, всеки инцидент и всяко решение за мащабиране. Tecton е напълно управляваната комерсиална алтернатива, създадена от членове на екипа зад платформата Michelangelo на Uber. Той се справя с онлайн и офлайн обслужване, изчисляване на streaming характеристики и вградено наблюдение на характеристики зад корпоративен SaaS договор.
Стандартното сравнение изглежда така:
| Фактор | Feast | Tecton |
|---|---|---|
| Разход за лиценз | Безплатен (само инфраструктурни разходи) | Корпоративно SaaS ценообразуване |
| Онлайн обслужване | Redis, DynamoDB — вие ги управлявате | Напълно управлявано |
| Offline store | Parquet, BigQuery, Snowflake — вие ги свързвате | Управлявано |
| Streaming характеристики | Push-базирани, вие изграждате pipelines | Вградено изчисление в реално време |
| Наблюдение на характеристики | Външни инструменти, които сглобявате | Вградено |
| Оперативна тежест | Висока — вашият екип управлява всичко | Ниска — SLA от доставчика |
Счетоводно релевантната версия на тази таблица има още един ред: къде се появяват парите. С Tecton почти целият разход идва като фактура от доставчик — разход за абонамент. С Feast линията за лиценз е нула, а реалният разход се крие в заплатите на инженерите: седмиците, които вашите data инженери прекарват в разгръщане на регистъра, писане на pipelines за характеристики, настройка на online store и изграждане на наблюдението, което Feast не предоставя. Open-source инфраструктурата с „нулев разход за лиценз“ все още изисква ред в отчета за приходи и разходи за инженерни часове, и точно този ред се урежда от ASC 350-40.
Счетоводният въпрос: какво всъщност казва ASC 350-40
Според U.S. GAAP разходите за софтуер за вътрешно ползване попадат под ASC 350-40, който разпределя всеки долар от софтуерен проект в един от три етапа (вижте нашето практическо ръководство за решението капитализиране срещу разход за общата рамка):
- Предварителен етап на проекта — разход при възникване. Оценка на доставчици, провеждане на proof-of-concept, сравняване на Feast с Tecton, проучвания за осъществимост и самият анализ build-vs-buy. Всичко това незабавно удря отчета за приходи и разходи.
- Етап на разработка на приложението — капитализиране на допустимите разходи. След като ръководството е оторизирало и се е ангажирало с проекта, разходите за проектиране, кодиране, конфигуриране, тестване и интегриране на софтуера се капитализират като актив и се амортизират за полезния му живот. Това е единственият етап, който изгражда актив.
- Етап след внедряване и експлоатация — разход при възникване. Обучение, поддръжка, поправки на грешки и текуща експлоатация след пускане в продукция. Нова функционалност, добавена по-късно, може да рестартира капитализирането, но поддържането на системата в действие никога не го прави.
За да се влезе в етапа на разработка на приложението, трябва да са изпълнени две условия: ръководството с релевантните правомощия е оторизирало проекта (имплицитно или експлицитно) и е вероятно проектът да бъде завършен и софтуерът да се използва по предназначение. Докато и двете не са налице, всеки долар все още е разход от предварителния етап — включително „прототип“, който по-късно става продукционен.
Капитализирането също има тясна дефиниция за допустими разходи. Преките заплати на разработчиците, работещи по изграждането, свързаните със заплатите разходи като осигуровки и таксите, платени на външни разработчици, работещи по проекта, обикновено отговарят на условията. Преобразуването на данни от стара система, обучението, поддръжката, общите режийни разходи и административните разходи не се включват — дори когато са направени в прозореца на етапа на разработка на приложението.
Съпоставяне на работата по feature store с трите етапа
Ето как типично изграждане на Feast се съпоставя с ASC 350-40:
Разход: оценката. Вашият екип прекарва три седмици в сравняване на Feast с Tecton, прави примерен pipeline и чете документацията на доставчика. Предварителен етап — разход. Това е вярно дори ако примерният код по-късно бъде използван в продукция; етапът се определя от целта на дейността към онзи момент, а не от това какво се превръща кодът.
Капитализиране: изграждането. Ръководството одобрява решението за Feast и финансира проекта. Инженерите вече разгръщат регистъра, пишат продукционни дефиниции на характеристики, изграждат batch и streaming pipelines, интегрират online store с вашата услуга за инференция и провеждат интеграционно и товарно тестване. Преките заплати на инженерите през този прозорец, плюс всякакви такси на изпълнители за внедряването, се капитализират — при условие че можете да документирате кой върху какво е работил и кога.
Разход: всичко след пускане в продукция. Вашата дежурна ротация настройва латентността на Redis, попълва обратно характеристика след грешка в pipeline, включва нови модели към съществуващи pipelines, актуализира версиите на Feast и поддържа таблата за наблюдение. След внедряване — разход. Ако шест месеца по-късно добавите наистина нова възможност, например streaming pipeline за нова продуктова линия, това отделно подобрение може да отговаря на условията за собствен прозорец на капитализиране.
Най-често срещаният режим на провал е липсващата документална следа. Капитализиране без едновременно проследяване на времето по етапи на проекта рядко преживява одит. Ако времето на вашите инженери не се проследява срещу изграждането на feature store спрямо обичайната работа, вашият одитор ще отчете всичко като разход — което може и да е правилният отговор, но трябва да бъде решение, а не по подразбиране.
Какво се променя, когато вместо това купите Tecton
Закупуването на управляван feature store обръща счетоводната картина. Tecton е договор за услуга, а не софтуер, който притежавате, така че таксите за абонамент са оперативни разходи, признати през срока на договора — просто, предвидимо и защитено срещу одит.
Тънката част е внедряването. Конфигурирането на SaaS платформа за вашите нужди — интегриране на Tecton с вашето хранилище за данни, свързване на API-та за обслужване с инференция, мигриране на дефиниции на характеристики — следва същата логика на ASC 350-40 съгласно указанията за cloud computing: разходите за внедряване в етапа на разработка на приложението могат да отговарят на условията за капитализиране, дори когато базовият софтуер се хоства от доставчика. На практика внедряванията на Tecton са достатъчно кратки, че много малки компании ги отчитат като разход на база същественост. Но ако интеграцията ви достигне шестцифрени разходи за инженерно време, същият анализ на етапите се прилага и същият стандарт за документация е валиден.
Тук има стратегическа бележка под линия за основатели, които набират финансиране. Капитализирането на изграждане на Feast подобрява текущия EBITDA и показателите за брутен марж, но на цената на растяща амортизационна тежест и актив, който екипът за дю дилиджънс на купувач ще разгледа внимателно. Отчитането на абонамент за Tecton като разход поддържа отчета за приходи и разходи честен относно run-rate изгарянето, но прави числата за тази година по-тежки. Нито едното третиране не е „по-добро“ — но инвеститорите ще попитат кое сте избрали и защо, така че избирайте съзнателно и документирайте обосновката.
ASU 2025-06: етапният модел си отива
Тристъпковата рамка датира от 1998 г., когато софтуерът се изграждаше в последователни waterfall фази с ясни граници. Тя се вписва лошо в гъвкавата, итеративна работа по feature store — кой спринт е „предварителен“, когато всеки спринт доставя в продукция? FASB се съгласи. През септември 2025 г. издаде ASU 2025-06, което премахва правилата, базирани на етапи, и ги заменя с принципна рамка, съсредоточена върху това дали остава значителна несигурност в разработката.
Според новия модел капитализирането започва, когато ръководството е оторизирало проекта, завършването и предназначението са вероятни и концепцията е преминала отвъд значителна несигурност относно изискванията за производителност, подхода за разработка или осъществимостта. Той е в сила за фискални години, започващи след 15 декември 2027 г., с разрешено ранно прилагане. За изграждане на feature store, започващо днес, практичният съвет е непроменен: вземете меморандума за оторизация, проследявайте времето срещу изграждането и отделете оценката от конструкцията. Тези навици удовлетворяват както старите етапи, така и новите принципи.
Практическо ръководство за вашето изграждане на feature store
Независимо дали избирате Feast, Tecton или трети вариант, пет практики поддържат счетоводството чисто:
Вземете оторизация в писмен вид, преди изграждането да започне. Имейл от CTO, одобряващ изграждането на Feast, бюджета и предвидената продукционна употреба, удовлетворява прага за оторизация. Датирайте го. Одиторите първо искат този документ.
Проследявайте инженерното време по етапи от първия ден. Оценителните експерименти отиват в една кофа, работата по продукционното изграждане в друга, поддръжката след пускане в трета. Проследяването на време чрез тагове или маркирането на спринтове работят еднакво добре; реконструирането на разделението по памет шест месеца по-късно не работи.
Капитализирайте само преки разходи. Заплати и осигуровки на разработчиците за часовете по изграждането, плюс фактури на изпълнители, свързани с внедряването. Изключете обучението, миграцията на данни от наследени pipelines, разпределенията на режийни разходи и сметката за cloud инфраструктура за работа на online store — хостингът е оперативен разход на завършената система, а не разход за изграждането ѝ.
Изберете срок на амортизация, който можете да защитите. Софтуерът за вътрешно ползване обикновено се амортизира линейно за три до пет години. Feature store, изграден върху бързо развиващ се open source, където голяма версия на Feast може да принуди преизграждане, аргументира по-краткия край. Документирайте обосновката в меморандума за капитализиране.
Тествайте за обезценка, когато фактите се променят. Ако изоставите изграждането на Feast по средата и подпишете с Tecton, капитализираният актив е обезценен — отпишете го. Същото важи, ако пивот убие продуктовата линия, която feature store обслужваше. Капитализиран софтуер, който вече няма употреба, не е актив.
Чести грешки, които водят до одиторски корекции
Грешките, които одиторите намират при капитализирането на инфраструктура, са депресиращо последователни. Капитализирането на оценителната фаза — сравнението на доставчици, proof of concept, експериментът — е най-честата; работата от предварителния етап никога не подлежи на капитализиране, колкото и полезна да се окаже. Капитализирането на поддръжка, прикрита като разработка, е на второ място: настройването на латентността на обслужването и попълването обратно на характеристики е експлоатация, не конструкция. Трето е липсващият меморандум: капитализирано салдо без документ за оторизация, без анализ на етапите и без обосновка за амортизацията се отчита като разход на общи основания. Четвърто е амортизирането за фантастични срокове — десет години за инфраструктура, залепена за open-source проект, който пуска счупващи промени ежегодно. И пето е пълното забравяне на cloud сметката: екипи, които внимателно капитализират заплати, докато игнорират шестцифрен годишен run rate за DynamoDB и изчисления, изопачават сравнението build-vs-buy, което е оправдало проекта на първо място.
Проследявайте изграждането като актива, който може да стане
Решението Feast срещу Tecton обикновено се представя като инженерна гордост срещу удобството на доставчик. Преформулирайте го като финансов въпрос и компромисът се изостря: Feast превръща паричното възнаграждение в капиталов актив с амортизационна опашка, докато Tecton превръща същата способност в чист оперативен разход с дата на подновяване. Вашият модел за runway, брутният ви марж и историята ви за дю дилиджънс се променят с избора — точно затова счетоводството заслужава място на прегледа на архитектурата, а не бележка под линия след него.
Това започва с обикновена счетоводна дисциплина: време, маркирано по проекти, датирана оторизация, фактури на изпълнители, свързани с изграждането, и меморандум за капитализиране, който вашият одитор може да проследи. Ако разходите ви за feature store в момента живеят като недиференцирани заплати на инженери в една счетоводна сметка, вече сте загубили възможността да капитализирате — записите не могат да бъдат реконструирани след факта.
Опростете финансовото си управление
Докато мащабирате ML инфраструктурата си, поддържането на ясни финансови записи за решения build-vs-buy, капитализиран софтуер и амортизационни графици е от съществено значение. Beancount.io предоставя счетоводство в обикновен текст, което ви дава пълна прозрачност и контрол върху финансовите ви данни — без черни кутии, без обвързване с доставчик. Започнете безплатно и вижте защо разработчиците и финансовите професионалисти преминават към счетоводство в обикновен текст.
