La tua fattura Tecton dice un numero, la tua bolletta AWS porta silenziosamente il resto, e nessuno dei due documenti si definisce il costo completo di servire le feature. Questa separazione è la trappola. Tecton applica un prezzo a consumo — crediti di calcolo per le pipeline che esegue più le risorse cloud che quelle pipeline consumano nel tuo account — quindi la fattura che ricevi da Tecton è sempre solo una parte della spesa. Se la tua contabilità registra la fattura e si ferma lì, il tuo costo del venduto è sottostimato, il tuo margine lordo è sovrastimato, e ogni decisione di prezzo che prendi su quel margine poggia su un numero che non è mai stato completo.
Questo articolo spiega come Tecton misura e fattura effettivamente, perché il serving delle feature di produzione appartiene al costo del venduto, come gestire crediti prepagati e impegni di consumo, e come riconciliare tutto a fine mese affinché ogni dollaro finisca nel conto giusto.
Come misura Tecton: feature view, non postazioni
Tecton è una piattaforma gestita di feature per il machine learning. Definisci le trasformazioni sui tuoi dati come feature view, Tecton le calcola su pipeline batch o streaming e serve i risultati ai tuoi modelli — un offline store per il recupero su larga scala durante l'addestramento e un online store per il recupero a bassa latenza durante l'inferenza in tempo reale. Non ci sono licenze per postazione da contare. Paghi per ciò che la piattaforma consuma mentre calcola, archivia e serve le tue feature.
Tale consumo si divide in due categorie che vengono fatturate in due luoghi diversi, ed è la prima cosa da interiorizzare.
La prima categoria sono i crediti Tecton. Coprono il calcolo che Tecton gestisce per tuo conto: crediti di calcolo Spark streaming per le feature view in streaming, crediti di calcolo Spark batch per le feature view batch. Il tuo utilizzo della piattaforma si traduce in crediti, e i crediti compaiono sulla fattura Tecton.
La seconda categoria è l'infrastruttura stessa, che viene fatturata attraverso il tuo account cloud. Tecton gestisce risorse di calcolo e archiviazione nel tuo ambiente AWS o GCP, quindi le letture e scritture dell'online store, il calcolo dei cluster Spark, l'archiviazione dell'online store e l'archiviazione S3 finiscono tutti sulla tua bolletta cloud — non su quella di Tecton. Un team che approvvigiona attraverso un canale e riconcilia attraverso l'altro troverà sempre un divario. Decidi una volta per tutte che il vero costo di una feature view è la somma di entrambe le categorie, e assicurati che la tua estrazione di fine mese copra sia la fattura Tecton sia le righe taggate della bolletta cloud.
Le feature view in streaming e batch consumano in modo diverso
Le componenti di costo differiscono per tipo di feature view, e sapere quali esegui ti dice quali righe monitorare.
Le feature view in streaming comportano letture e scritture dell'online store, calcolo del cluster Spark streaming, crediti di calcolo Tecton Spark streaming, archiviazione S3 e archiviazione dell'online store. Le feature view batch comportano un elenco simile — letture e scritture dell'online store, calcolo del cluster Spark job, crediti di calcolo Tecton Spark batch e archiviazione S3 — meno le parti specifiche dello streaming.
I parametri che muovono la fattura sono le scelte di progettazione che i tuoi ingegneri ML fanno ogni giorno. L'elaborazione continua in streaming esegue checkpoint e scritture molto più spesso dell'elaborazione a intervalli, quindi costa di più. Finestre di aggregazione più grandi richiedono più calcolo. Watermark più lunghi per i dati in ritardo aumentano i requisiti di memoria. La configurazione del cluster determina direttamente il prezzo di ogni job. La compattazione dei dati riduce il costo di archiviazione e migliora le prestazioni di lettura. Nessuna di queste è un'impostazione finanziaria; sono impostazioni ingegneristiche con conseguenze finanziarie, ed è per questo che la contabilizzazione di questa piattaforma inizia con una conversazione tra i due team su quali feature view esistono e su come sono configurate.
La gerarchia dei costi ti dice dove vanno i soldi
Le indicazioni di Tecton stessa classificano l'impatto sui costi dal più alto al più basso, e l'ordine vale la pena di essere memorizzato perché prevede da dove arriveranno le tue sorprese.
Le operazioni sull'online store sono in cima. Le scritture sull'online store sono tipicamente il costo infrastrutturale più alto, specialmente durante i backfill — il ricalcolo delle feature storiche per una feature view nuova o modificata — o con l'elaborazione continua in streaming. Un backfill è un picco pianificato: giorni o settimane di calcolo storico e un fiume di scritture compressi in un'unica finestra. Se nessuno avverte la finanza che sta arrivando, il mese in cui arriva sembra uno sforamento dei costi invece di un investimento.
Le risorse di calcolo vengono seconde: costi dei cluster Spark per l'elaborazione streaming e batch, variabili con configurazione e carico di lavoro. L'archiviazione viene terza: archiviazione e letture dell'online store più S3, in genere con impatto inferiore rispetto a calcolo e scritture.
La conseguenza pratica è che la tua fattura è guidata da scritture ed eventi di calcolo, non da quante persone accedono alla console. La pianificazione della capacità qui significa governare backfill, modalità di elaborazione e finestre di aggregazione — non l'organico.
Perché il serving delle feature di produzione è COGS
Secondo i principi contabili statunitensi (US GAAP), il costo del venduto di un'azienda SaaS — il costo dei ricavi — include i costi diretti per fornire il servizio che i clienti pagano: infrastruttura di hosting, calcolo e archiviazione cloud, software di terze parti incorporato nel prodotto e qualsiasi altra cosa che scala con l'utilizzo. Il serving delle feature per un prodotto ML di produzione supera facilmente questa soglia. Quando il tuo modello antifrode assegna un punteggio a una transazione, il tuo motore di raccomandazione classifica un feed, o il tuo modello di prezzo quota una tariffa, le letture dell'online store e le pipeline che mantengono aggiornate quelle feature sono un costo di fornitura tanto diretto quanto i server applicativi che stanno dietro.
Questa classificazione conta perché fluisce direttamente nel margine lordo, il numero che investitori, finanziatori e acquirenti usano per giudicare se l'economia del tuo prodotto funziona. Parcheggiare i costi di serving sotto la linea nelle spese operative generali gonfia il margine lordo e nasconde la storia della scalabilità. Un team di due diligence rimapperà comunque il tuo piano dei conti a una definizione standard di COGS SaaS; classificare correttamente fin dall'inizio significa che i tuoi dashboard raccontano la stessa storia che calcolerà un estraneo.
Non ogni dollaro di Tecton appartiene però ai COGS. La suddivisione segue l'uso, non il fornitore:
- Il serving di produzione è COGS. Letture e scritture dell'online store per l'inferenza in tempo reale, le pipeline streaming e batch che mantengono aggiornate le feature di produzione e l'archiviazione che sta dietro forniscono tutte il servizio rivolto al cliente.
- La sperimentazione e lo staging sono spese operative. Le feature view di sviluppo, la sperimentazione offline e gli ambienti di staging supportano la ricerca e lo sviluppo, non la fornitura. Registrale in R&D.
- Il lavoro solo di addestramento richiede giudizio. Il calcolo offline delle feature che esiste unicamente per addestrare la prossima versione del modello assomiglia più a R&D che a fornitura; la stessa pipeline che alimenta l'online store per il serving in tempo reale è COGS. Quando una singola feature view fa entrambe le cose, alloca secondo un driver difendibile — la spesa cloud taggata per ambiente è il più pulito che la maggior parte dei team ha a disposizione.
Tecton tagga le istanze di calcolo e le risorse dell'online store per feature view, quindi i dati di allocazione esistono nel tuo cost explorer cloud. Il compito contabile è decidere la mappatura una volta — quali feature view servono la produzione, quali servono la sperimentazione — e poi applicarla ogni mese invece di ridiscuterla a ogni chiusura.
Acquistare Tecton è una spesa; costruire l'equivalente può essere un cespite
Un'ulteriore classificazione che vale la pena di impostare correttamente: il team che acquista Tecton spesa il consumo come descritto sopra, ma il team che costruisce il proprio feature store su software open source affronta invece una questione di capitalizzazione. Il software a uso interno sviluppato per le proprie operazioni può qualificarsi per la capitalizzazione una volta che un progetto supera la fase preliminare, il che trasforma gli stipendi degli ingegneri e l'infrastruttura in un'attività ammortizzabile invece che in una spesa di periodo.
Nessuno dei due trattamenti è un dettaglio facoltativo. Se esegui Tecton, non capitalizzare le sue fatture come se avessi costruito la piattaforma. Se migri da uno store costruito internamente a Tecton, il vecchio cespite capitalizzato continua ad ammortizzare mentre il nuovo consumo impatta i COGS — due righe diverse, due storie diverse, entrambe corrette contemporaneamente.
Crediti prepagati e impegni sono prima attività, poi spese
Le piattaforme a consumo vendono comunemente crediti prepagati o impegni di spesa annuali, e la contabilizzazione di entrambi segue il principio di competenza economica: registra il pagamento come attività, poi spesa man mano che il beneficio viene consumato. Un dollaro inviato in anticipo a un fornitore non è ancora un costo di nulla. Diventa COGS quando i crediti si consumano contro il serving di produzione, R&D quando si consumano contro la sperimentazione, e una perdita se scadono inutilizzati.
In pratica ciò significa tre registrazioni, non una. Quando acquisti crediti, addebita un'attività prepagata e accredita la cassa. Ogni mese, riduci il saldo di quanto effettivamente consumato — consumo di produzione a COGS, consumo di staging a R&D. Se i crediti hanno una data di scadenza, mettila in calendario; un saldo scaduto è una perdita reale che merita uno storno pianificato, non una scoperta durante la pulizia dell'anno successivo.
I minimi take-or-pay aggiungono una maturazione in più. Se il tuo contratto ti impegna a una spesa minima trimestrale, devi il maggiore tra consumo effettivo e minimo. Quando il consumo scende sotto l'impegno verso la fine del periodo, matura il disavanzo che dovrai comunque pagare. La fattura arriverà dopo, ma la passività esiste alla data di bilancio, e la chiusura dovrebbe rifletterla.
Riconciliare a fine mese: due fatture, una verità
Tecton pubblica log di utilizzo fatturabile — record CSV dettagliati dell'uso della piattaforma e di come si traducono in crediti, che arrivano nel tuo object storage circa uno o due giorni dopo l'utilizzo. Combinati con la spesa cloud taggata, questi log sono le letture del contatore su cui poggia la tua riconciliazione. Tratta il processo mensile come l'incrocio di tre fonti tra loro: i log di utilizzo, la fattura Tecton e la bolletta cloud.
Una checklist di chiusura praticabile è questa:
- Estrai i log di utilizzo per l'intero mese. Conferma che i crediti di ogni feature view di produzione e di ogni esperimento siano presenti, inclusi gli ultimi due giorni — il ritardo dei log significa che una chiusura eseguita il primo del mese manca di dati. O attendi i log o matura i giorni finali dal run-rate e rettifica il mese successivo.
- Matura il lato Tecton non fatturato. Come la maggior parte della fatturazione a consumo, la fattura arriva dopo il periodo che copre. Registra una maturazione per i crediti stimati del mese a COGS e R&D in base alla ripartizione per ambiente, poi storna e rettifica quando arriva la fattura.
- Estrai la spesa cloud taggata. Filtra il tuo cost explorer cloud per i tag delle feature view per lo stesso periodo. Questa è la seconda categoria — cluster Spark, operazioni dell'online store, archiviazione — e va suddivisa tra prod e staging allo stesso modo.
- Riconcilia log, fattura e bolletta cloud. I log di utilizzo dovrebbero quadrare con la fattura Tecton; le righe cloud taggate dovrebbero muoversi nella stessa direzione. Un mese di backfill farà impennare entrambe. Una fattura che diverge dai log è una questione di fatturazione da sollevare subito, non al rinnovo.
- Riduci prepagamenti e impegni. Spesa i crediti consumati dall'attività prepagata, matura qualsiasi disavanzo dell'impegno e conferma che i saldi residui sembrino ancora utilizzabili prima della scadenza.
Il fallimento più comune è il punto tre — riconciliare meticolosamente la fattura Tecton mentre la spesa lato cloud si nasconde dentro una bolletta infrastrutturale più grande sotto una voce generica di hosting. Se il tuo estratto conto cloud mostra un'unica riga di calcolo aggregata, sistema il tagging prima di qualsiasi altra cosa. La spesa non taggata non può essere allocata, e la spesa non allocata finisce sempre da qualche parte sbagliata.
Un mese concreto nei libri
Supponi che la tua piattaforma ML consumi a gennaio crediti Tecton fatturati $40.000 contro il serving di produzione e $8.000 contro la sperimentazione, più $12.000 di spesa cloud taggata suddivisa in $9.500 produzione e $2.500 staging. Hai anche prepagato $100.000 di crediti all'inizio del trimestre. Gennaio si registra così:
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 USDLo schema si generalizza: il prepagamento è un'attività, il consumo la trasferisce a spesa per ambiente, e il lato cloud matura separatamente perché viene fatturato separatamente. Se il tuo team tiene i libri in formato testo, i pattern di tracciamento dei costi nella documentazione si estendono naturalmente a una suddivisione per feature view, e le viste dashboard rendono visibile mese per mese la tendenza prod-versus-staging.
Errori che falsano il margine
Quattro errori compaiono ripetutamente nei team che gestiscono infrastrutture ML fatturate a consumo. Ognuno è economico da prevenire e costoso da annullare attraverso periodi riesposti.
Registrare la fattura Tecton come costo totale. La fattura è una categoria. Ogni mese il calcolo lato cloud, le operazioni dell'online store e l'archiviazione aggiungono una seconda categoria di dimensioni comparabili, e ometterla sottostima i COGS di circa la metà. Riconcilia entrambe o non riportare nessuna delle due.
Spesare i prepagamenti al momento del pagamento. Un acquisto di crediti da $100.000 non è una spesa di $100.000 nel mese in cui parte il bonifico. È un'attività che si converte in spesa man mano che i crediti si consumano. Spesare al pagamento anticipa il trimestre, priva i mesi successivi del loro vero costo e rende illeggibili le tendenze di consumo.
Far passare lo staging attraverso i COGS. Le feature view di sperimentazione, i backfill offline per la ricerca sui modelli e gli ambienti di staging sono R&D. Mescolarli ai costi di serving sovrastima i COGS e penalizza il margine lordo per un lavoro che non ha mai toccato un cliente. I tag delle feature view esistono proprio per mantenere onesta questa suddivisione — usali.
Saltare la maturazione. La fatturazione a consumo avviene in via posticipata, i log di utilizzo ritardano di un giorno o due e la bolletta cloud arriva ancora più tardi. Una chiusura senza maturazione registra un mese parziale come se fosse completo, e i giorni mancanti emergono come una varianza misteriosa il mese successivo. Matura dal run-rate, poi rettifica quando arrivano i documenti.
Il tuo ultimo passo utile questo mese è piccolo: apri il tuo cost explorer cloud, filtra per i tag delle feature view e conferma che il numero che vedi sia il numero nei tuoi libri. Se i due non si sono mai incontrati, hai appena trovato il divario che questo articolo è stato scritto per colmare.
