Módulo 6: Finops For Tokens
7. On-demand vs. Provisioned Throughput: cuándo cada uno, con números reales
Descripción
El Módulo 2, lección 2 de esta guía ya citó los cinco modelos de precio de Bedrock, incluido Provisioned Throughput —el único que "vuelve a parecerse a prendido = cuesta"—, con un criterio cualitativo: tiene sentido "cuando el volumen sostenido es tan alto que el costo por hora reservada termina siendo menor que la suma de miles de invocaciones On-Demand". Esta lección le pone un número exacto a esa frase, verificado en este mismo momento contra el catálogo de precios oficial de AWS —no memorizado de una versión anterior de esta guía—, y lo aplica al perfil de uso real de extract-shipment-manifest-fields.
Conexión con el módulo
Esta es la única lección puramente conceptual del módulo, pero con la misma disciplina de números reales que cada lección de esta guía exige. Retoma la tabla de precios On-Demand del Módulo 2, lección 2, el aws_bedrock_provisioned_model_throughput que la lección 2 de este módulo ya confirmó como recurso real de Terraform, y los dos supuestos de volumen (GENAI-COST-PROFILE.md, sección 4) más el escenario desproporcionado de la lección 6 — para calcular, con aritmética verificable, exactamente qué tan lejos está Andes Cargo hoy de que Provisioned Throughput sea la decisión correcta.
Analogía: el abono mensual de transporte, no el boleto por viaje
Ya conoces el taxímetro que ni siquiera sabe cuántos viajes harás (lección 2) — la metáfora de On-Demand. Provisioned Throughput es el abono mensual de una línea de transporte: pagas una tarifa fija, sin importar cuántos viajes hagas ese mes, y esa tarifa te conviene solo si vas a viajar lo suficiente como para que el costo por viaje individual, sumado, supere el precio del abono. Nadie compra un abono mensual para viajar dos veces al mes — el boleto suelto sale más barato en ese caso, aunque el abono "se sienta" más profesional o más predecible. La pregunta que esta lección contesta con números es exactamente esa: ¿cuántos "viajes" (invocaciones) al mes necesitaría Andes Cargo para que el abono (Provisioned Throughput) empiece a convenir sobre el boleto suelto (On-Demand)?
Los números verificados, en este mismo momento
Los dos precios que esta comparación necesita, ambos verificados en vivo contra el catálogo público de precios de AWS (la misma API que alimenta aws.amazon.com/bedrock/pricing/), consultados el mismo día en que se escribió esta lección — marcados VARIABLE, no permanentes, exactamente la misma disciplina del Módulo 2, lección 2:
On-Demand, Amazon Nova Lite (us-east-1):
| Eje | Precio |
|---|---|
| Entrada | $0,06 por 1M tokens |
| Salida | $0,24 por 1M tokens |
Provisioned Throughput, por Model Unit / hora (us-east-1, idéntico para Nova Micro, Nova Lite y Nova Pro):
| Compromiso | Precio por MU/hora |
|---|---|
| Sin compromiso | $60,50 |
| Compromiso de 1 mes | $55,00 |
| Compromiso de 6 meses | $30,25 |
Los dos precios On-Demand son idénticos a los que el Módulo 2, lección 2 ya citó. Los tres de Provisioned Throughput también coinciden, exactos, con lo que esa lección adelantó — confirmados de nuevo aquí, no reciclados sin verificar, porque una decisión de arquitectura de esta magnitud merece su propia comprobación, no una cita de memoria de un módulo anterior.
El punto de cruce: cuántas invocaciones/mes necesitaría Andes Cargo
La pregunta exacta: ¿a qué volumen mensual de invocaciones (con el tamaño de token de extract-shipment-manifest-fields: 800 tokens de entrada, 150 de salida, GENAI-COST-PROFILE.md sección 4) el costo total On-Demand iguala el costo de reservar una sola Model Unit, corriendo los treinta días completos del mes?
python3 -c "
cost_per_request = (800 * 0.06 + 150 * 0.24) / 1_000_000
no_commit_month = 60.50 * 24 * 30
six_month_month = 30.25 * 24 * 30
print(f'costo por invocación On-Demand: \${cost_per_request:.6f}')
print(f'1 MU, sin compromiso, 1 mes: \${no_commit_month:,.2f}')
print(f'1 MU, compromiso 6 meses, 1 mes: \${six_month_month:,.2f}')
print(f'punto de cruce, sin compromiso: {no_commit_month/cost_per_request:,.0f} invocaciones/mes')
print(f'punto de cruce, 6 meses: {six_month_month/cost_per_request:,.0f} invocaciones/mes')
"Qué esperar (literal — ejecutado para escribir esta lección):
costo por invocación On-Demand: $0.000084
1 MU, sin compromiso, 1 mes: $43,560.00
1 MU, compromiso 6 meses, 1 mes: $21,780.00
punto de cruce, sin compromiso: 518,571,429 invocaciones/mes
punto de cruce, 6 meses: 259,285,714 invocaciones/mes
Verificado también con la calculadora misma del Módulo 2 (scripts/bedrock_cost_estimate.py), corrida exactamente en el punto de cruce del compromiso de 6 meses:
python3 bedrock_cost_estimate.py \
--model amazon.nova-lite-v1:0 --input-tokens 800 --output-tokens 150 \
--monthly-requests 259285714Qué esperar (literal):
Model amazon.nova-lite-v1:0
Input tokens / request 800
Output tokens / request 150
Monthly requests (declared) 259,285,714
Monthly input tokens 207,428,571,200
Monthly output tokens 38,892,857,100
Input cost ($0.0600/1M tok) $12,445.71
Output cost ($0.2400/1M tok) $9,334.29
----------------------------------------------------
TOTAL MONTHLY COST $21,780.00
$21.780,00 — exacto, coincide, dos caminos de cálculo independientes (la aritmética directa y la calculadora del Módulo 2) confirmando el mismo número. 259 millones de invocaciones al mes es el punto en el que 1 Model Unit, con el compromiso más barato posible (6 meses), empieza a costar lo mismo que seguir pagando On-Demand.
Comparado contra los volúmenes reales de Andes Cargo
ESCALA DE VOLUMEN, ANDES CARGO vs. EL PUNTO DE CRUCE
Realista (GENAI-COST-PROFILE.md §4) 40 / mes
Estrés (GENAI-COST-PROFILE.md §4) 5.000 / mes
Desproporcionado (M6.6, deliberado) 100.000 / mes
│
│ 2.593x de distancia
▼
Punto de cruce (6 meses de compromiso) 259.285.714 / mes
Punto de cruce (sin compromiso) 518.571.429 / mesIncluso el escenario deliberadamente desproporcionado de la lección 6 —cien mil invocaciones al mes, veinticinco veces el escenario de estrés original— está 2.593 veces por debajo del punto en que la Provisioned Throughput más barata posible empezaría a convenir. Dicho de otra forma: Andes Cargo necesitaría que cada uno de sus manifiestos actuales (~400/mes, COST-PROFILE.md sección 4) se multiplicara por más de 648.000, o que decenas de empresas del tamaño de Andes Cargo enrutaran manifiestos por el mismo modelo, para que esta decisión siquiera entrara en discusión seria con los números de hoy.
La honestidad de este número: qué SÍ mide, y qué NO mide
Esta comparación es intencionalmente conservadora en un sentido específico, y vale la pena decirlo con precisión: es una comparación puramente de dólares — cuánto costaría, en teoría, servir ese volumen con 1 MU frente a servirlo On-Demand —, no una confirmación de que 1 Model Unit de Nova Lite pueda físicamente procesar 259 millones de invocaciones al mes. La documentación oficial de AWS (docs.aws.amazon.com/bedrock/latest/userguide/prov-throughput.html) es explícita en un punto: el throughput exacto que entrega una Model Unit —cuántos tokens de entrada y salida por minuto— no está publicado; el mismo documento remite a "contactar a tu gerente de cuenta de AWS" para ese dato. Esto significa que el punto de cruce real podría requerir más de una Model Unit para sostener ese volumen —lo cual solo empujaría el punto de cruce todavía más lejos, nunca más cerca—, así que la conclusión de esta lección (Provisioned Throughput no es una decisión real para Andes Cargo hoy) queda, si acaso, reforzada por esta limitación, no debilitada.
LO QUE ESTA COMPARACIÓN VERIFICA LO QUE NO PUEDE VERIFICAR
El costo en $ de reservar 1 MU Cuántas invocaciones/minuto
por mes, a cada nivel de compromiso entrega 1 MU en la práctica
(verificado, catálogo público) (no publicado -- "contacta a
│ tu account manager")
▼ │
El costo en $ de servir un volumen ▼
dado On-Demand, con el tamaño de Si el volumen real necesitara
token real de esta carga MÁS de 1 MU, el punto de
│ cruce sería AÚN MÁS ALTO --
▼ nunca más bajo
El punto de cruce en $, con el
supuesto más favorable a Provisioned
Throughput (1 sola MU)Criterio de decisión, en una frase
Provisioned Throughput deja de ser una curiosidad teórica y se vuelve una decisión seria cuando el volumen sostenido —no un pico ocasional— se acerca, aunque sea en un orden de magnitud, al punto de cruce calculado contra el compromiso más largo disponible (el más barato por hora). Para extract-shipment-manifest-fields, tal como ADR-001 lo definió —un camino de escalamiento, una minoría del tráfico total—, ese punto está a más de tres órdenes de magnitud de distancia del escenario más pesimista que esta guía consideró. La decisión correcta para Andes Cargo, hoy, sigue siendo On-Demand — la misma conclusión del Módulo 2, lección 2, ahora sostenida con el número exacto que mide qué tan lejos está esa alternativa de volverse relevante.
Errores comunes
Comparar el precio por hora de Provisioned Throughput directamente contra el costo mensual On-Demand, sin convertir ambos a la misma unidad de tiempo (de error de unidades). Qué pasa: alguien compara $60,50 (por hora) contra $0,42 (el costo On-Demand mensual del escenario de estrés) y concluye, incorrectamente, que Provisioned Throughput es "obviamente" más caro por un factor enorme, sin considerar que $60,50 es por hora, no por mes. Cómo detectarlo: si tu comparación mezcla una cifra por hora con una cifra mensual sin convertir. Cómo corregirlo: siempre multiplica el precio por hora por las horas reales del período de compromiso (24 × 30 para un mes, como esta lección hace explícitamente) antes de comparar contra cualquier cifra mensual.
Asumir que 1 Model Unit alcanza para cualquier volumen, sin considerar que el throughput real por MU no está publicado (de sobre-simplificación). Qué pasa: alguien concluye, de esta lección, que "259 millones de invocaciones/mes con 1 MU" es un hecho confirmado sobre capacidad, no solo sobre costo. Cómo detectarlo: si citas el punto de cruce de esta lección como una garantía de que 1 MU efectivamente puede servir ese volumen. Cómo corregirlo: la sección de honestidad de esta lección lo aclara explícitamente — el número es un piso de costo, con el supuesto más favorable posible (1 sola MU); AWS no publica el throughput real por MU, así que el volumen físicamente soportable por una sola unidad podría ser mucho menor, lo cual movería el punto de cruce hacia arriba, no hacia abajo.
Citar los precios de esta lección meses después sin volver a verificarlos (el mismo error, en un dominio nuevo, que el Módulo 2 ya nombró varias veces). Qué pasa: alguien usa $60,50/$55,00/$30,25 como si fueran permanentes. Cómo detectarlo: si estás tomando una decisión de presupuesto real basada en un precio de esta lección sin haberlo revisado de nuevo. Cómo corregirlo: verifica siempre contra aws.amazon.com/bedrock/pricing/ el día que necesites el número real — la misma disciplina exacta que cada precio citado en esta guía exige.
Ejercicios
Ejercicio 1 — Calcula el punto de cruce con el compromiso de 1 mes ($55,00/MU/hora), y ubícalo en la escala de esta lección. ¿Está más cerca o más lejos del volumen desproporcionado de la lección 6 que el punto de cruce de 6 meses?
Ver solución
$55,00 × 24 × 30 = $39.600,00 por mes; $39.600,00 / $0,000084 ≈ 471.428.571 invocaciones/mes — más lejos que el punto de cruce de 6 meses (259.285.714), porque un compromiso más corto cuesta más por hora, así que hace falta un volumen todavía mayor para justificarlo. La relación se mantiene consistente: cuanto más largo el compromiso, más barato por hora, y más bajo (más alcanzable, aunque siga siendo astronómico para Andes Cargo) el punto de cruce.
Ejercicio 2 — Si Andes Cargo eligiera Nova Micro en vez de Nova Lite (precio On-Demand más bajo, mismo precio de Provisioned Throughput según la lección 2 de este módulo), ¿el punto de cruce subiría o bajaría? Justifica sin recalcular todo, usando la lógica de la fórmula.
Ver solución
Subiría (haría falta un volumen todavía mayor). El punto de cruce es costo_mensual_MU / costo_por_invocación; si el costo por invocación baja (Nova Micro es más barato que Nova Lite On-Demand, Módulo 2, lección 2) mientras el costo de Provisioned Throughput por MU se mantiene igual (el Módulo 6, lección 2 de esta guía ya confirmó que los tres modelos Nova comparten el mismo precio por MU), el denominador de la fracción baja, así que el resultado —el punto de cruce— sube. Un modelo On-Demand más barato hace que Provisioned Throughput sea, todavía, una decisión más lejana.
Ejercicio 3 — Explica por qué esta lección usa "1 sola Model Unit" como supuesto, en vez de calcular cuántas MUs necesitaría Andes Cargo para el volumen real. ¿Por qué esa simplificación no invalida la conclusión de la lección?
Ver solución
Porque el número exacto de tokens/minuto que entrega una Model Unit no está publicado (la sección de honestidad de esta lección ya lo cita, directo de la documentación oficial de AWS). Usar 1 MU es el supuesto más favorable posible a Provisioned Throughput —el piso de costo—: si el volumen real necesitara 2, 5, o 50 MUs para sostener el throughput requerido, el costo mensual de Provisioned Throughput se multiplicaría por esa misma cantidad, empujando el punto de cruce todavía más lejos del volumen real de Andes Cargo. Como la conclusión de esta lección (On-Demand sigue siendo correcto, por un margen de más de tres órdenes de magnitud) ya se sostiene con el supuesto más favorable a la alternativa, cualquier supuesto más realista solo reforzaría esa misma conclusión — nunca la revertiría.
Resumen y siguiente paso
Esta lección calculó, con precios verificados en vivo y aritmética verificable en dos caminos independientes, el punto exacto en el que Provisioned Throughput empezaría a convenir sobre On-Demand para extract-shipment-manifest-fields: entre 259 y 519 millones de invocaciones al mes, según el compromiso elegido. Comparado contra los tres escenarios de volumen que esta guía ya consideró —40, 5.000, y el deliberadamente desproporcionado 100.000 de la lección 6—, la distancia mínima es de más de 2.500 veces. La conclusión —On-Demand sigue siendo la decisión correcta— queda sostenida incluso con el supuesto más favorable posible a la alternativa (una sola Model Unit), porque AWS no publica el throughput real por MU y cualquier ajuste realista solo alejaría más el punto de cruce.
Antes de avanzar deberías poder: calcular el punto de cruce entre On-Demand y Provisioned Throughput para cualquier combinación de precio y tamaño de token; explicar por qué el número de esta lección es un piso de costo, no una garantía de capacidad; y defender, con la escala completa dibujada en esta lección, por qué On-Demand sigue siendo correcto para Andes Cargo hoy.
La lección 8, el proyecto que cierra este módulo, reúne todas las piezas —bedrock-budget.rego, la calculadora con presupuesto, el tagging completo— en una corrida real de act pull_request, en paralelo al security gate del Módulo 5.
Recursos
- AWS — Amazon Bedrock Pricing — la fuente oficial de todos los precios de esta lección; verifica aquí el número vigente antes de cualquier decisión real.
- AWS Docs — Increase model invocation capacity with Provisioned Throughput in Amazon Bedrock — la fuente de la limitación citada en la sección de honestidad: el throughput por MU no está publicado.
- Terraform Registry —
aws_bedrock_provisioned_model_throughput— el recurso real confirmado en el Módulo 6, lección 2 de esta guía, conmodel_unitscomo su atributo central. - Este módulo, lección 2 — el origen del contraste entre capacidad reservada (Provisioned Throughput) e invocación (on-demand, sin recurso equivalente), que esta lección convierte en números.