Tu factura de Tecton dice un número, tu factura de AWS carga silenciosamente el resto, y ninguno de los dos documentos se presenta como el costo total de servir features. Esa división es la trampa. Tecton cobra por consumo — créditos de cómputo por los pipelines que ejecuta más los recursos de nube que esos pipelines consumen dentro de tu propia cuenta — así que la factura que recibes de Tecton siempre es solo una parte del gasto. Si tus libros registran la factura y se detienen ahí, tu costo de ventas está subestimado, tu margen bruto está sobreestimado, y cada decisión de precios que tomes sobre ese margen se apoya en un número que nunca estuvo completo.
Este artículo explica cómo mide y factura Tecton realmente, por qué el serving de features en producción pertenece al costo de ventas, cómo manejar créditos prepagados y compromisos de consumo, y cómo conciliar todo esto al cierre de mes para que cada dólar caiga en la cuenta correcta.
Cómo mide Tecton: feature views, no licencias por usuario
Tecton es una plataforma gestionada de features para machine learning. Defines transformaciones sobre tus datos como feature views, Tecton las calcula en pipelines batch o de streaming, y sirve los resultados a tus modelos — un almacén offline para recuperación a gran escala durante el entrenamiento y un almacén online para recuperación de baja latencia durante la inferencia en vivo. No hay licencias por usuario que contar. Pagas por lo que la plataforma consume mientras calcula, almacena y sirve tus features.
Ese consumo se divide en dos cubos que se facturan en dos lugares distintos, y eso es lo primero que hay que interiorizar.
El primer cubo son los créditos de Tecton. Cubren el cómputo que Tecton gestiona en tu nombre: créditos de cómputo Spark streaming para feature views de streaming, créditos de cómputo Spark batch para feature views batch. Tu uso de la plataforma se traduce en créditos, y los créditos aparecen en la factura de Tecton.
El segundo cubo es la infraestructura misma, y se factura a través de tu propia cuenta de nube. Tecton gestiona recursos de cómputo y almacenamiento dentro de tu entorno de AWS o GCP, así que las lecturas y escrituras del almacén online, el cómputo del clúster Spark, el almacenamiento del almacén online y el almacenamiento en S3 caen todos en tu factura de nube — no en la de Tecton. Un equipo que aprovisiona por un canal y concilia por el otro siempre encontrará una brecha. Decide de una vez que el costo real de una feature view es la suma de ambos cubos, y asegúrate de que tu extracción de cierre de mes cubra tanto la factura de Tecton como las líneas etiquetadas de la factura de nube.
Las feature views de streaming y batch consumen de forma distinta
Los componentes de costo difieren según el tipo de feature view, y saber cuáles ejecutas te dice qué líneas vigilar.
Las feature views de streaming conllevan lecturas y escrituras del almacén online, cómputo del clúster Spark streaming, créditos de cómputo Tecton Spark streaming, almacenamiento en S3 y almacenamiento del almacén online. Las feature views batch conllevan una lista similar — lecturas y escrituras del almacén online, cómputo del clúster de jobs Spark, créditos de cómputo Tecton Spark batch y almacenamiento en S3 — menos las piezas específicas de streaming.
Los parámetros que mueven la factura son las decisiones de diseño que tus ingenieros de ML toman cada día. El procesamiento de streaming continuo hace checkpoints y escrituras con mucha más frecuencia que el procesamiento por intervalos, así que cuesta más. Las ventanas de agregación más grandes necesitan más cómputo. Los watermarks más largos para datos que llegan tarde elevan los requisitos de memoria. La configuración del clúster pone precio a cada job directamente. La compactación de datos reduce el costo de almacenamiento y mejora el rendimiento de lectura. Nada de esto son ajustes de finanzas; son ajustes de ingeniería con consecuencias financieras, y por eso la contabilidad de esta plataforma empieza con una conversación entre ambos equipos sobre qué feature views existen y para qué están ajustadas.
La jerarquía de costos te dice a dónde va el dinero
La propia guía de Tecton ordena el impacto en costos de mayor a menor, y vale la pena memorizar el orden porque predice de dónde vendrán tus sorpresas.
Las operaciones del almacén online están en la cima. Las escrituras al almacén online suelen ser el costo de infraestructura más alto, especialmente durante los backfills — recalcular features históricas para una feature view nueva o modificada — o bajo procesamiento de streaming continuo. Un backfill es un pico planificado: días o semanas de cómputo histórico y una avalancha de escrituras comprimidos en una sola ventana. Si nadie avisa a finanzas que viene, el mes en que aterriza parece un exceso de costo en lugar de una inversión.
Los recursos de cómputo van en segundo lugar: costos del clúster Spark para procesamiento streaming y batch, que varían con la configuración y la carga de trabajo. El almacenamiento va en tercer lugar: almacenamiento y lecturas del almacén online más S3, generalmente con menor impacto que el cómputo y las escrituras.
La consecuencia práctica es que tu factura la impulsan las escrituras y los eventos de cómputo, no cuántas personas inician sesión en la consola. La planificación de capacidad aquí significa gobernar backfills, modos de procesamiento y ventanas de agregación — no la plantilla.
Por qué el serving de features en producción es COGS
Según los US GAAP, el costo de ventas de una empresa SaaS — costo de ingresos — incluye los costos directos de entregar el servicio que pagan los clientes: infraestructura de hosting, cómputo y almacenamiento en la nube, software de terceros embebido en el producto, y cualquier otra cosa que escale con el uso. El serving de features para un producto de ML en producción supera ese umbral con facilidad. Cuando tu modelo de fraude puntúa una transacción, tu motor de recomendaciones ordena un feed, o tu modelo de precios cotiza una tarifa, las lecturas del almacén online y los pipelines que mantienen esas features frescas son un costo de entrega tan directo como los servidores de aplicación detrás de ellos.
Esa clasificación importa porque fluye directamente al margen bruto, el número que inversores, prestamistas y adquirentes usan para juzgar si la economía de tu producto funciona. Meter los costos de serving por debajo de la línea en gastos operativos generales infla el margen bruto y oculta la historia de escalabilidad. Un equipo de diligencia reasignará tu GL a una definición estándar de COGS de SaaS de todos modos; clasificar correctamente desde el principio significa que tus propios dashboards cuentan la misma historia que calculará un externo.
No todo dólar de Tecton pertenece a COGS, sin embargo. La división sigue el uso, no al proveedor:
- El serving de producción es COGS. Las lecturas y escrituras del almacén online para inferencia en vivo, los pipelines de streaming y batch que mantienen frescas las features de producción, y el almacenamiento detrás de ellos entregan todos el servicio de cara al cliente.
- La experimentación y el staging son gasto operativo. Las feature views de desarrollo, la experimentación offline y los entornos de staging apoyan la investigación y el desarrollo, no la entrega. Regístralos en I+D.
- El trabajo solo de entrenamiento requiere criterio. El cómputo de features offline que existe únicamente para entrenar la próxima versión del modelo se parece más a I+D que a entrega; el mismo pipeline que alimenta el almacén online para serving en vivo es COGS. Cuando una feature view hace ambas cosas, asigna según un driver defendible — el gasto en la nube etiquetado por entorno es el más limpio que la mayoría de los equipos tiene.
Tecton etiqueta las instancias de cómputo y los recursos del almacén online por feature view, así que los datos de asignación existen en tu explorador de costos de nube. La tarea contable es decidir el mapeo una vez — qué feature views sirven a producción, cuáles a experimentación — y luego aplicarlo cada mes en lugar de reabrirlo en cada cierre.
Comprar Tecton es gasto; construir el equivalente puede ser capital
Otra clasificación que vale la pena acertar: el equipo que compra Tecton expensea el consumo como se describe arriba, pero el equipo que construye su propio feature store sobre software de código abierto enfrenta en cambio una cuestión de capitalización. El software de uso interno desarrollado para tus propias operaciones puede calificar para capitalización una vez que un proyecto pasa la etapa preliminar, lo que convierte los salarios de ingeniería y la infraestructura en un activo amortizable en lugar de un gasto del período.
Ninguno de los dos tratamientos es color opcional. Si ejecutas Tecton, no capitalices sus facturas como si hubieras construido la plataforma. Si migras de un almacén autoconstruido a Tecton, el antiguo activo capitalizado sigue amortizándose mientras el nuevo consumo golpea COGS — dos líneas distintas, dos historias distintas, ambas correctas a la vez.
Los créditos prepagados y los compromisos son activos primero, gasto después
Las plataformas de consumo suelen vender créditos prepagados o compromisos anuales de gasto, y la contabilidad de ambos sigue el principio de correlación: registra el pago como un activo, luego expénsalo a medida que se consume el beneficio. Un dólar transferido a un proveedor por adelantado todavía no es costo de nada. Se convierte en COGS cuando los créditos se consumen contra serving de producción, en I+D cuando se consumen contra experimentación, y en una pérdida si expiran sin usarse.
En la práctica eso significa tres registros, no uno. Cuando compras créditos, debita un activo prepagado y acredita caja. Cada mes, reduce el saldo por lo que realmente se consumió — el consumo de producción a COGS, el consumo de staging a I+D. Si los créditos tienen fecha de expiración, agéndala; un saldo expirado es una pérdida real que merece una baja planificada, no un descubrimiento durante la limpieza del próximo año.
Los mínimos take-or-pay añaden una acumulación encima. Si tu contrato te compromete a un gasto mínimo trimestral, debes el mayor entre el consumo real y el mínimo. Cuando el consumo queda por debajo del compromiso cerca del fin del período, acumula el faltante que deberás de todos modos. La factura llegará después, pero el pasivo existe en la fecha del balance, y el cierre debe reflejarlo.
Conciliar al cierre de mes: dos facturas, una sola verdad
Tecton publica registros de uso facturable — registros CSV detallados del uso de la plataforma y cómo se traduce en créditos, que aterrizan en tu propio almacenamiento de objetos aproximadamente uno o dos días después del uso. Combinados con el gasto en la nube etiquetado, estos registros son las lecturas de medidor de las que cuelga tu conciliación. Trata el proceso mensual como un cruce de tres fuentes entre sí: los registros de uso, la factura de Tecton y la factura de nube.
Una lista de verificación de cierre viable se ve así:
- Extrae los registros de uso del mes completo. Confirma que están presentes los créditos de cada feature view de producción y los créditos de cada experimento, incluidos los últimos dos días — el retraso del registro significa que un cierre ejecutado el primero del mes tiene datos faltantes. O espera los registros o acumula los días finales desde el run-rate y ajusta el próximo mes.
- Acumula el lado no facturado de Tecton. Como la mayoría de la facturación por consumo, la factura llega después del período que cubre. Registra una acumulación por los créditos estimados del mes a COGS e I+D según la división por entorno, luego revierte y ajusta cuando llegue la factura.
- Extrae el gasto en la nube etiquetado. Filtra tu explorador de costos de nube por las etiquetas de feature view para el mismo período. Este es el segundo cubo — clústeres Spark, operaciones del almacén online, almacenamiento — y debe dividirse entre prod y staging de la misma manera.
- Concilia registros con factura y con factura de nube. Los registros de uso deben cuadrar con la factura de Tecton; las líneas etiquetadas de la nube deben moverse en la misma dirección. Un mes de backfill disparará ambos. Una factura que diverge de los registros es una pregunta de facturación que hay que plantear ahora, no en la renovación.
- Reduce prepagos y compromisos. Expensa los créditos consumidos desde el activo prepagado, acumula cualquier faltante del compromiso, y confirma que los saldos restantes todavía parecen usables antes de la expiración.
El fallo más común es el paso tres — conciliar la factura de Tecton meticulosamente mientras el gasto del lado de la nube se esconde dentro de una factura de infraestructura más grande bajo hosting genérico. Si tu estado de nube muestra una sola línea de cómputo combinada, arregla el etiquetado antes de arreglar cualquier otra cosa. El gasto sin etiquetar no se puede asignar, y el gasto no asignado siempre termina en algún lugar equivocado.
Un mes concreto en los libros
Supongamos que tu plataforma de ML consume créditos de Tecton facturados por $40.000 contra serving de producción y $8.000 contra experimentación en enero, más $12.000 de gasto en la nube etiquetado dividido en $9.500 de producción y $2.500 de staging. También prepagaste $100.000 de créditos al inicio del trimestre. Enero se registra así:
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 USDEl patrón se generaliza: el prepago es un activo, el consumo lo traslada a gasto por entorno, y el lado de la nube se acumula por separado porque se factura por separado. Si tu equipo mantiene sus libros en texto plano, los patrones de seguimiento de costos en la documentación se extienden naturalmente a una división por feature view, y las vistas de dashboard hacen visible la tendencia prod-versus-staging mes a mes.
Errores que distorsionan el margen
Cuatro errores aparecen repetidamente en equipos que ejecutan infraestructura de ML facturada por consumo. Cada uno es barato de prevenir y caro de deshacer a través de períodos reexpresados.
Registrar la factura de Tecton como el costo total. La factura es un cubo. Cada mes el cómputo del lado de la nube, las operaciones del almacén online y el almacenamiento añaden un segundo cubo de tamaño comparable, y omitirlo subestima COGS en aproximadamente la mitad. Concilia ambos o no reportes ninguno.
Expensar los prepagos en el momento del pago. Una compra de $100.000 en créditos no es un gasto de $100.000 en el mes en que sale la transferencia. Es un activo que se convierte en gasto a medida que se consumen los créditos. Expensar en el pago adelanta el trimestre, deja a los meses posteriores sin su costo real, y hace ilegibles las tendencias de consumo.
Enrutar el staging por COGS. Las feature views de experimentación, los backfills offline para investigación de modelos y los entornos de staging son I+D. Mezclarlos con los costos de serving sobreestima COGS y castiga el margen bruto por trabajo que nunca tocó a un cliente. Las etiquetas de feature view existen precisamente para mantener honesta esta división — úsalas.
Omitir la acumulación. El consumo se factura por atrasado, los registros de uso llegan con uno o dos días de retraso, y la factura de nube llega aún más tarde. Un cierre sin acumulación registra un mes parcial como si fuera completo, y los días faltantes aparecen como una variación misteriosa el próximo mes. Acumula desde el run-rate, luego ajusta cuando lleguen los documentos.
Tu último paso útil este mes es pequeño: abre tu explorador de costos de nube, filtra por las etiquetas de feature view, y confirma que el número que ves es el número en tus libros. Si los dos nunca se han encontrado, acabas de encontrar la brecha que este artículo fue escrito para cerrar.
