Amazon Nova 2 Lite: cómo calcular el coste real por flujo entre tokens, caché, niveles de servicio y fallos

Del precio unitario al coste de un resultado útil

El precio por millón de tokens es un componente necesario, pero no responde por sí solo a la pregunta operativa relevante: cuánto cuesta terminar una tarea con el resultado y la latencia que el sistema necesita. En un flujo de Amazon Nova 2 Lite en Amazon Bedrock intervienen el volumen de entrada y salida, el contexto que se repite, las llamadas que fracasan, la validación de la respuesta y, según el diseño, el nivel de servicio seleccionado. Por tanto, una previsión defendible debe expresarse tanto en unidades de consumo como en resultados aceptados.

Conviene definir desde el inicio una unidad de trabajo. Puede ser una solicitud clasificada, una página procesada, un documento extraído, una sesión o una automatización que produce un objeto estructurado válido. La unidad elegida ha de incluir la condición de aceptación: por ejemplo, que el JSON pase el validador, que la herramienta finalice o que una revisión humana no sea necesaria. Esto evita presentar como éxito una respuesta que consumió recursos pero fue descartada.

Esta guía no fija importes: las fuentes proporcionadas describen identificación del modelo, modalidades, caché, niveles de servicio, rutas de inferencia, cuotas y datos de uso facturable, pero no incluyen una tabla de precios vigente. Antes de presupuestar, el equipo debe congelar la tarifa oficial aplicable fuera de este artículo y registrar la fecha de consulta. Sustituir ese dato en las fórmulas es preferible a reutilizar cifras antiguas o inferir precios a partir de otro modelo.

El identificador base documentado para el modelo es amazon.nova-2-lite-v1:0. La ficha también documenta perfiles de inferencia para Estados Unidos, Europa, Japón y Global. No debe suponerse que dos perfiles, rutas o regiones tienen el mismo precio, la misma capacidad ni el mismo tratamiento de datos solo porque invocan el mismo modelo base.

La ficha de cobro que se debe congelar antes de hacer cuentas

Toda hoja de cálculo debería empezar con una ficha de alcance. Anote la fecha y hora de consulta de la tarifa, moneda, cuenta o entorno, identificador del modelo, región de origen, perfil de inferencia, ruta In-Region o Cross-Region, nivel de servicio solicitado y unidad funcional. Añada una versión del prompt, configuración de salida, esquema de validación y periodo de observación. Esos campos permiten explicar por qué dos mediciones aparentemente iguales terminan con costes distintos.

La documentación de informes de coste y uso de Bedrock distingue para Nova 2 Lite tipos de uso de entrada, salida, lectura de caché y escritura de caché. También documenta sufijos que permiten distinguir el nivel Flex o Priority y el enrutamiento Cross-Region. Esta separación importa: una estimación que suma solo tokens de entrada y salida puede omitir operaciones de caché, y una conciliación agregada puede esconder una mezcla de rutas o niveles de servicio.

La inferencia geográfica Cross-Region puede procesar solicitudes dentro de la geografía elegida, aunque los prompts y resultados pueden moverse desde la región de origen a una región de destino de esa geografía. Esto debe evaluarse como requisito de arquitectura y residencia, no solo como variable de precio. La documentación aportada no basta para afirmar aquí una equivalencia de precio, cuota o facturación entre In-Region, Geo Cross-Region y Global Cross-Region.

Variables facturables y cuatro fórmulas que se pueden auditar

Para cada intento, separe al menos tokens de entrada ordinaria, tokens de salida, lecturas de caché y escrituras de caché. Si el flujo incluye entradas multimodales, herramientas integradas, razonamiento o alguna modalidad adicional, añada columnas específicas solo si la tarifa y el registro de uso aplicables las identifican. No asigne de forma automática un recargo a una función por el hecho de usarla: con las fuentes disponibles no se puede confirmar el tratamiento tarifario de razonamiento, imágenes, documentos, herramientas ni errores de API para este modelo.

Use precios unitarios convertidos a coste por token o mantenga el denominador por millón de tokens de manera consistente. Llame P_i al precio de entrada, P_o al de salida, P_cr al de lectura de caché y P_cw al de escritura. Para un intento j, los consumos correspondientes son I_j, O_j, CR_j y CW_j. Si hay otros conceptos publicados, incorpórelos como suma de cantidad por precio, sin esconderlos dentro de entrada u salida.

La primera fórmula estima el coste de una llamada individual. La segunda distribuye un lote entre los ítems procesados. La tercera sirve para sesiones que reutilizan instrucciones o contexto. La cuarta transforma consumo en coste por tarea completada correctamente. En todas ellas, el resultado depende de que la telemetría contabilice cada intento, incluidos los que acabaron en validación fallida o se abandonaron tras una espera excesiva.

Caché de prompt: medir el ahorro neto, no asumirlo

Nova 2 Lite admite caché explícita con un mínimo de 1.000 tokens por checkpoint, hasta cuatro checkpoints, un tiempo de vida de cinco minutos y un máximo de 20.000 tokens de caché. Estos límites delimitan qué diseños pueden beneficiarse: una instrucción extensa y estable compartida por solicitudes cercanas en el tiempo es un candidato más claro que un contexto pequeño, muy variable o espaciado.

La comparación correcta no es «con caché frente a sin caché» en abstracto. Mida tokens escritos, tokens leídos, número de solicitudes elegibles, porcentaje de aciertos, intervalo entre llamadas, complejidad adicional y cambios en la tasa de éxito. La escritura inicial puede tener un coste distinto de una lectura, y el informe de coste y uso permite distinguir ambas categorías. El ahorro neto aparece solo si las lecturas reutilizadas compensan las escrituras y el mantenimiento del diseño.

Una caché también puede empeorar la economía si aumenta la complejidad de segmentación, reduce la personalización necesaria, provoca expiraciones frecuentes o incentiva a incluir contexto irrelevante. El hecho de que un bloque sea almacenable no prueba que reduzca la factura. La decisión debe basarse en una cohorte comparable y en costes por tarea aceptada, no solo en tokens de entrada observados.

Standard, Flex y Priority: una decisión de coste esperado

La documentación de niveles de servicio describe Flex para cargas tolerantes a retrasos y Priority como una opción solicitada por petición. También indica que las cuotas bajo demanda se comparten entre Priority, el comportamiento predeterminado y Flex. Por ello, elegir un nivel no elimina la necesidad de medir la demanda agregada ni garantiza por sí mismo que el flujo opere dentro de sus límites de cuota.

El nivel efectivamente atendido puede observarse en la respuesta de la API, CloudTrail y CloudWatch según la documentación. Guarde ese dato junto con el nivel solicitado. Es esencial para detectar diferencias entre intención y servicio servido y para conciliar análisis de latencia, consumo y tipos de uso del informe de costes.

La alternativa más barata por unidad puede ser más cara por resultado útil si incrementa el abandono, los timeouts o la repetición de trabajo. A la inversa, un nivel orientado a prioridad solo justifica su coste adicional si reduce pérdidas operativas que el flujo realmente sufre. Esta es una conclusión de análisis económico, no una afirmación sobre precios o rendimiento garantizado de un nivel concreto.

Fallos, reintentos y respuestas descartadas: el multiplicador que hay que contabilizar una vez

Un flujo robusto debe registrar todos los intentos: primera llamada, reintento automático, reparación de JSON, nueva llamada después de timeout y escalado a revisión humana. Para evitar doble contabilización, asigne un identificador de tarea raíz y un identificador de intento. Cada coste de modelo pertenece a un intento; el coste por tarea aceptada se obtiene agregando los intentos de la tarea una sola vez y dividiendo entre tareas aceptadas.

Distinga errores antes de invocar el modelo, que pueden no producir consumo de inferencia, de respuestas o fallos posteriores a una invocación. No es seguro tratar todo error HTTP como gratuito ni todo reintento como idéntico al primer intento. La conciliación debe usar los datos de respuesta, registros operativos y los tipos de uso de Bedrock disponibles en el informe de costes. Si falta correlación por solicitud, documente esa limitación en vez de atribuir todo el gasto al último paso visible.

Las cuotas publicadas incluyen límites de solicitudes por minuto y tokens por minuto para la inferencia Cross-Region de Nova 2 Lite, y algunas cuotas pueden ajustarse mediante Service Quotas. Mida rechazos, esperas y reintentos ligados a límites. Un cambio de cuota o de patrón de llegada puede modificar la tasa de éxito y el coste efectivo sin que varíe el precio unitario.

Presupuesto mensual sustituible y conciliación con el gasto

Para presupuestar, parta de una previsión de tareas iniciadas al mes, una distribución esperada de intentos por tarea y consumos medios por tipo de intento. Calcule cada segmento por separado: solicitudes simples, documentos, sesiones con contexto repetido y automatizaciones estructuradas. Multiplique el coste medio por intento de cada segmento por sus intentos previstos; después sume el coste de operaciones auxiliares y revisión humana si forman parte del coste operativo que se quiere decidir.

Como ejemplo de estructura, una hoja puede tener una fila por segmento y columnas para tareas iniciadas, tasa de aceptación, intentos por tarea, entrada, salida, escritura y lectura de caché por intento, precios vigentes, coste estimado y coste por aceptado. Las celdas de precio deben permanecer vacías hasta copiar la tarifa verificada para la configuración concreta. No conviene rellenarlas con cifras ilustrativas porque podrían interpretarse como tarifa actual.

Al cerrar el periodo, compare previsión y realidad por modelo, ruta, nivel de servicio y tipo de uso. Explique la variación con cambios de mezcla de entradas, longitud de salida, aciertos de caché, reintentos y aceptación, antes de atribuirla a una modificación de precios. Recalcule cuando cambien el modelo, región o perfil, prompt, política de caché, nivel de servicio, mezcla multimodal, volumen, cuotas o reglas de validación.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.