Feast vs. Tecton: Kapitálové vykazovanie internej infraštruktúry feature store podľa ASC 350-40, keď budujete namiesto nákupu

Váš ML tím práve strávil päť inžinierskych mesiacov budovaním open-source feature store. Váš kontrolór sa pozrie na mzdový beh a položí otázku, ktorú nikto v tíme nečakal: je tých 180 000 dolárov inžinierskeho času náklad, ktorý zasiahne tento štvrťrok, alebo aktívum, ktoré sedí v súvahe? Odpoveď mení váš burn multiple, výpočet runway a — ak práve získavate kapitál — príbeh, ktorý vyrozprávajú vaše finančné výkazy. A úplne sa mení podľa toho, či ste stavali na Feast alebo kúpili Tecton.

Feature store je infraštruktúrna vrstva, ktorá spravuje, ukladá a poskytuje machine-learningové príznaky (features) pre tréning aj inferenciu v reálnom čase. Jeho hlavnou úlohou je predchádzať nesúladu medzi tréningom a poskytovaním (training-serving skew): zabezpečiť, aby model v produkcii videl presne tie isté príznaky, na ktorých sa trénoval. Architektúra má päť pohyblivých častí — offline úložisko pre tréningové dáta, online úložisko pre poskytovanie s nízkou latenciou, pipeline príznakov, ktoré počítajú hodnoty, centrálny register príznakov a API na poskytovanie. Keď si tímy vyberajú medzi Feast a Tecton, vyberajú si medzi dvoma veľmi odlišnými modelmi vlastníctva a každý model prináša veľmi odlišné účtovné zaobchádzanie.

Feast vs. Tecton: kompromis budovať vs. kúpiť​

Feast je popredný open-source feature store: bezplatný na používanie, self-hosted a flexibilný. Online úložisko prevádzkujete sami (zvyčajne Redis alebo DynamoDB), offline úložisko tiež sami (S3, BigQuery alebo Snowflake) a vlastníte každý upgrade, každé stránkovanie pri výpadku a každé rozhodnutie o škálovaní. Tecton je plne manažovaná komerčná alternatíva, ktorú vytvorili členovia tímu stojaceho za platformou Michelangelo spoločnosti Uber. Zvláda online aj offline poskytovanie, streamovací výpočet príznakov a vstavané monitorovanie príznakov v rámci podnikovej SaaS zmluvy.

Štandardné porovnanie vyzerá takto:

Účtovne relevantná verzia tejto tabuľky má ešte jeden riadok: kde sa peniaze prejavia. Pri Tecton takmer všetky náklady prichádzajú ako faktúra od dodávateľa — náklad na predplatné. Pri Feast je licenčný riadok nula a skutočné náklady sa skrývajú v mzdách inžinierov: týždne, ktoré vaši dátoví inžinieri strávia nasadením registra, písaním pipeline príznakov, ladením online úložiska a budovaním monitorovania, ktoré Feast neobsahuje. Open-source infraštruktúra s „nulovými licenčnými nákladmi" stále potrebuje riadok v P&L za inžinierske hodiny, a práve tento riadok riadi ASC 350-40.

Účtovná otázka: čo ASC 350-40 skutočne hovorí​

Podľa US GAAP spadajú náklady na softvér na interné použitie pod ASC 350-40, ktorý zaraďuje každý dolár softvérového projektu do jednej z troch fáz (všeobecný rámec nájdete v našom praktickom sprievodcovi rozhodnutím kapitalizovať vs. účtovať do nákladov):

1. Fáza prípravného projektu — účtuje sa do nákladov v momente vzniku. Hodnotenie dodávateľov, overovacie proof-of-concept pokusy, porovnávanie Feast a Tecton, štúdie uskutočniteľnosti a samotná analýza budovať vs. kúpiť. Všetko ide okamžite do P&L.
2. Fáza vývoja aplikácie — kapitalizujú sa spôsobilé náklady. Keď vedenie projekt schválilo a zaviazalo sa k nemu, náklady na návrh, kódovanie, konfiguráciu, testovanie a integráciu softvéru sa kapitalizujú ako aktívum a odpisujú sa počas jeho doby použiteľnosti. Toto je jediná fáza, ktorá buduje aktívum.
3. Fáza po implementácii a prevádzková fáza — účtuje sa do nákladov v momente vzniku. Školenia, údržba, opravy chýb a priebežná prevádzka po spustení. Nová funkcionalita pridaná neskôr môže kapitalizáciu znovu spustiť, ale udržiavanie chodu nikdy nie.

Na vstup do fázy vývoja aplikácie musia platiť dve podmienky: vedenie s príslušnou právomocou projekt schválilo (implicitne alebo explicitne) a je pravdepodobné, že projekt bude dokončený a softvér bude používaný na zamýšľanú funkciu. Kým nie sú splnené obe, každý dolár je stále nákladom prípravnej fázy — vrátane „prototypu", ktorý sa neskôr stane produkciou.

Kapitalizácia má tiež úzku definíciu spôsobilých nákladov. Priame mzdy vývojárov pracujúcich na build-e, s mzdami súvisiace náklady ako benefity a poplatky tretím stranám zaplatené externým vývojárom pracujúcim na projekte sa vo všeobecnosti kvalifikujú. Konverzia dát zo starého systému, školenia, údržba, všeobecná réžia a administratívne náklady sa nekvalifikujú — a to aj vtedy, keď vzniknú počas okna fázy vývoja aplikácie.

Mapovanie práce na feature store do troch fáz​

Takto sa typický build na Feast mapuje na ASC 350-40:

Náklad: hodnotenie. Váš tím strávi tri týždne benchmarkovaním Feast proti Tecton, spraví spike vzorovej pipeline a číta dokumentáciu dodávateľa. Prípravná fáza — náklad. To platí aj vtedy, ak sa spike kód neskôr znovu použije v produkcii; fáza sa posudzuje podľa účelu aktivity v danom čase, nie podľa toho, čím sa kód stane.

Kapitalizovať: build. Vedenie schváli rozhodnutie pre Feast a financuje projekt. Inžinieri teraz nasadzujú register, píšu produkčné definície príznakov, budujú dávkové a streamovacie pipeline, integrujú online úložisko s vašou inferenčnou službou a spúšťajú integračné a záťažové testovanie. Priame mzdy inžinierov počas tohto okna plus akékoľvek poplatky kontraktorom za implementáciu sa kapitalizujú — za predpokladu, že dokážete zdokumentovať, kto na čom pracoval a kedy.

Náklad: všetko po spustení. Vaša pohotovostná služba ladí latenciu Redisu, dopĺňa príznak po chybe v pipeline, zapája nové modely do existujúcich pipeline, upgraduje verzie Feast a udržiava monitorovacie dashboardy. Po implementácii — náklad. Ak o šesť mesiacov pridáte skutočne novú schopnosť, napríklad streamovaciu pipeline pre novú produktovú líniu, toto samostatné vylepšenie sa môže kvalifikovať na vlastné okno kapitalizácie.

Jediným najčastejším zlyhaním je chýbajúca papierová stopa. Kapitalizácia bez súbežného sledovania času podľa fázy projektu zriedka prežije audit. Ak čas vašich inžinierov nie je sledovaný voči buildu feature store oproti bežnej práci, váš audítor zaúčtuje celú sumu do nákladov — čo môže byť napokon správna odpoveď, ale malo by to byť rozhodnutie, nie implicitné zlyhanie.

Čo sa zmení, keď namiesto toho kúpite Tecton​

Kúpa manažovaného feature store obracia účtovný obraz. Tecton je zmluva o službách, nie softvér, ktorý vlastníte, takže poplatky za predplatné sú prevádzkové náklady vykázané počas trvania zmluvy — jednoduché, predvídateľné a odolné voči auditu.

Jemnou časťou je implementácia. Konfigurácia SaaS platformy na vaše použitie — integrácia Tecton s vaším dátovým skladom, zapojenie API na poskytovanie do inferencie, migrácia definícií príznakov — sa riadi tou istou logikou ASC 350-40 podľa usmernení pre cloud computing: náklady na implementáciu vo fáze vývoja aplikácie sa môžu kvalifikovať na kapitalizáciu, aj keď je základný softvér hostovaný u dodávateľa. V praxi sú implementácie Tecton dostatočne krátke na to, aby ich mnohé malé spoločnosti účtovali do nákladov z dôvodu materiality. Ak však vaša integrácia dosiahne šesťciferné sumy inžinierskeho času, platí tá istá analýza fáz a ten istý štandard dokumentácie.

Je tu strategická poznámka pod čiarou pre zakladateľov získavajúcich kapitál. Kapitalizácia buildu na Feast zlepšuje optiku EBITDA bežného obdobia a hrubej marže na úkor rastúceho bremena odpisov a aktíva, ktoré bude tím due diligence nadobúdateľa dôkladne skúmať. Účtovanie predplatného Tecton do nákladov udržiava P&L čestný ohľadne run-rate burn, ale robí tohtoročné čísla ťažšími. Ani jedno zaobchádzanie nie je „lepšie" — ale investori sa budú pýtať, ktoré ste si vybrali a prečo, takže vyberajte zámerne a dôvod zdokumentujte.

ASU 2025-06: model fáz sa ruší​

Rámec troch fáz pochádza z roku 1998, keď sa softvér budoval v sekvenčných vodopádových fázach s čistými hranicami. Na agilnú, iteratívnu prácu na feature store sedí zle — ktorý sprint je „prípravný", keď každý sprint dodáva do produkcie? FASB súhlasil. V septembri 2025 vydal ASU 2025-06, ktorý ruší pravidlá založené na fázach a nahrádza ich rámcom založeným na princípoch, ktorý sa sústreďuje na to, či pretrváva významná neistota vývoja.

Podľa nového modelu kapitalizácia začína, keď vedenie projekt schválilo, dokončenie a zamýšľané použitie sú pravdepodobné a koncept sa posunul za významnú neistotu ohľadne výkonnostných požiadaviek, prístupu k vývoju alebo uskutočniteľnosti. Je účinný pre fiškálne roky začínajúce po 15. decembri 2027, s možnosťou skorého prijatia. Pre build feature store začínajúci dnes je praktická rada nezmenená: získajte autorizačné memorandum, sledujte čas voči buildu a oddeľte hodnotenie od konštrukcie. Tieto návyky vyhovujú starým fázam aj novým princípom.

Praktický playbook pre váš build feature store​

Či si vyberiete Feast, Tecton alebo tretiu možnosť, päť praktík udrží účtovníctvo v poriadku:

Získajte písomné schválenie pred začiatkom buildu. E-mail od CTO schvaľujúci build na Feast, rozpočet a zamýšľané produkčné použitie spĺňa prahovú podmienku autorizácie. Dátujte ho. Audítori o tento dokument žiadajú ako prvý.

Sledujte inžiniersky čas podľa fázy od prvého dňa. Overovacie spiky idú do jedného vedra, práca na produkčnom builde do druhého, údržba po spustení do tretieho. Sledovanie času pomocou značiek alebo označovanie sprintov funguje; rekonštrukcia rozdelenia z pamäti o šesť mesiacov neskôr nie.

Kapitalizujte len priame náklady. Mzdy vývojárov a benefity za hodiny na builde plus faktúry kontraktorov viazané na implementáciu. Vylúčte školenia, migráciu dát zo starších pipeline, alokácie réžie a účet za cloudovú infraštruktúru na prevádzku online úložiska — hosting je prevádzkový náklad hotového systému, nie náklad na jeho vybudovanie.

Zvoľte dobu odpisovania, ktorú dokážete obhájiť. Softvér na interné použitie sa zvyčajne odpisuje rovnomerne počas troch až piatich rokov. Feature store postavený na rýchlo sa vyvíjajúcom open source, kde by hlavná verzia Feast mohla vynútiť prepracovanie, argumentuje v prospech kratšieho konca. Zdôvodnenie zdokumentujte v memorande o kapitalizácii.

Testujte na zníženie hodnoty, keď sa zmenia fakty. Ak build na Feast na polceste opustíte a podpíšete s Tecton, kapitalizované aktívum je znehodnotené — odpíšte ho. To isté platí, ak pivot zlikviduje produktovú líniu, ktorej feature store slúžil. Kapitalizovaný softvér, ktorý už nemá použitie, nie je aktívum.

Časté chyby, ktoré vedú k úpravám pri audite​

Chyby, ktoré audítori nachádzajú pri kapitalizácii infraštruktúry, sú deprimujúco konzistentné. Kapitalizácia fázy hodnotenia — porovnanie dodávateľov, proof of concept, spike — je najčastejšia; práca v prípravnej fáze sa nikdy nedá kapitalizovať, nech sa ukáže akokoľvek užitočná. Na druhom mieste je kapitalizácia údržby vydávanej za vývoj: ladenie latencie poskytovania a dopĺňanie príznakov je prevádzka, nie konštrukcia. Na treťom mieste chýbajúce memorandum: kapitalizovaný zostatok bez autorizačného dokumentu, analýzy fáz a zdôvodnenia odpisovania sa zaúčtuje do nákladov na základe všeobecných princípov. Na štvrtom mieste odpisovanie počas fantazijných dôb — desať rokov pre infraštruktúru prilepenú k open-source projektu, ktorý každoročne vydáva zásadné zmeny. A na piatom mieste úplné zabudnutie na cloudový účet: tímy, ktoré starostlivo kapitalizujú mzdy a ignorujú šesťciferný ročný run rate za DynamoDB a výpočtový výkon, skresľujú porovnanie budovať vs. kúpiť, ktoré projekt pôvodne odôvodňovalo.

Sledujte build ako aktívum, ktorým sa môže stať​

Rozhodnutie Feast vs. Tecton sa zvyčajne rámuje ako inžinierska hrdosť proti pohodliu dodávateľa. Prerámujte ho ako finančnú otázku a kompromis sa vyostrí: Feast premieňa peňažnú odmenu na kapitálové aktívum s odpisovým chvostom, zatiaľ čo Tecton premieňa tú istú schopnosť na čistý prevádzkový náklad s dátumom obnovy. Váš model runway, vaša hrubá marža a váš príbeh pre due diligence sa všetky menia s touto voľbou — a práve preto si účtovníctvo zaslúži miesto na revízii architektúry, nie poznámku pod čiarou po nej.

To začína obyčajnou účtovnou disciplínou: čas označený podľa projektu, datovaná autorizácia, faktúry kontraktorov viazané na build a memorandum o kapitalizácii, ktoré váš audítor dokáže sledovať. Ak vaše náklady na feature store v súčasnosti žijú ako nerozlíšené mzdy inžinierov na jednom účte hlavnej knihy, už ste stratili možnosť kapitalizovať — záznamy sa nedajú rekonštruovať dodatočne.

Zjednodušte si finančný manažment​

Keď škálujete svoju ML infraštruktúru, udržiavanie jasných finančných záznamov pre rozhodnutia budovať vs. kúpiť, kapitalizovaný softvér a odpisové plány je nevyhnutné. Beancount.io poskytuje plain-text účtovníctvo, ktoré vám dáva úplnú transparentnosť a kontrolu nad vašimi finančnými dátami — žiadne čierne skrinky, žiadne uzamknutie u dodávateľa. Začnite zadarmo a zistite, prečo vývojári a finanční profesionáli prechádzajú na plain-text účtovníctvo.