Benchmarks de negocio: cómo conectar coste AWS, tokens de IA y latencia

Un CTO necesita cuatro cifras para saber si una plataforma es rentable y escalable: coste por resultado útil, porcentaje de operaciones dentro del objetivo de latencia en el percentil relevante, volumen de resultados útiles sostenible y consumo del presupuesto de error. Con esas cuatro se puede discutir margen, capacidad y riesgo en la misma frase. Sin ellas, la conversación se desplaza a indicadores intermedios —CPU, factura mensual, precio por millón de tokens— que se pueden mejorar sin mejorar nada.

Un benchmark no sirve para demostrar que una tecnología es más rápida. Sirve para decidir cuánto margen, capacidad, riesgo y experiencia de cliente compra cada euro de infraestructura y cada token de IA. Esa es la tesis del artículo y el criterio con el que hay que leer cada tabla que sigue.

La tabla de traducción

Toda métrica técnica tiene una lectura de negocio y un error habitual asociado. La columna que importa es la última: una métrica que no cambia ninguna decisión es un dato, no un indicador.

Tres frases que sostienen el resto del artículo

El recorrido es el siguiente. Los capítulos 1 a 5 construyen la unidad de medida y desmontan las cuatro lecturas erróneas más caras: latencia media, coste por servidor, precio por token y CPU como objetivo. El capítulo 6 reúne coste, calidad, latencia y capacidad en una sola ecuación. Los capítulos 7 y 8 convierten esa ecuación en un ensayo reproducible y en telemetría concreta. El capítulo 9 aplica el modelo a un caso completo, el 10 compara tres decisiones de inversión y los capítulos 11 y 12 cierran con los errores recurrentes y la lista de adopción.

Hay un patrón que se repite en plataformas B2B con microservicios Java y Spring Boot sobre AWS, y que se ha agravado desde que hay funcionalidades de IA generativa en el flujo. Un trimestre de trabajo de optimización termina con dos paneles en verde —coste de infraestructura a la baja, CPU cómoda— y una cuenta de resultados que no mejora. A veces empeora. Nadie ha mentido en ninguna cifra. Todas las mediciones son correctas. Lo que falla es que ninguna de ellas tiene en el denominador el resultado que el negocio vende.

Esa es la definición operativa de optimización local: una mejora real y verificable sobre un indicador intermedio, cuyo efecto sobre el indicador final no se ha comprobado. No es negligencia. Es la consecuencia natural de que los indicadores intermedios sean fáciles de medir —vienen de serie con la plataforma— y el indicador final requiera unir tres fuentes que en la mayoría de las organizaciones no se hablan entre sí: la facturación de la nube, la telemetría de la aplicación y el registro de operaciones de negocio.

Qué distingue a un benchmark de negocio

Un benchmark técnico responde a «cuánto rinde este componente en estas condiciones». Es una pregunta legítima y necesaria para elegir entre dos implementaciones. Un benchmark de negocio responde a otra cosa: cuántos resultados aceptables produce el sistema completo, a qué coste unitario, dentro de qué umbral de latencia y con cuánto margen antes de romperse. Son cuatro dimensiones, no una, y la trampa está en que cualquiera de las cuatro se puede mejorar a costa de las otras tres.

Por qué la IA generativa ha hecho urgente esta distinción

Durante años el coste variable de una petición fue casi despreciable frente al coste fijo de la plataforma. Una petición más contra un servicio Java ya desplegado consumía milisegundos de CPU y algo de red; el coste marginal existía, pero era tan pequeño que razonar en términos de capacidad reservada resultaba suficiente. Una llamada a un modelo de lenguaje rompe esa aproximación en dos sentidos.

El primero es que el coste marginal deja de ser despreciable: se factura por token consumido y producido, de modo que una petición más tiene un precio directo, medible y sensible al contenido. Un contexto recuperado que crece porque alguien subió el número de fragmentos del recuperador de cinco a quince multiplica el coste variable sin tocar una línea de infraestructura.

El segundo es que el resultado deja de ser binario. Una consulta SQL devuelve o no devuelve. Una respuesta de un modelo puede ser correcta, parcialmente correcta, formalmente válida pero inútil, o directamente inventada. Eso introduce en la ecuación económica una variable que la ingeniería de plataforma no había tenido que modelar antes: la tasa de resultados aceptables. Y esa variable interactúa con todo lo demás, porque cada resultado no aceptable se paga dos veces —una en tokens y otra en el reintento, la revisión humana o el cliente perdido—.

El resto del artículo construye ese denominador pieza a pieza. Empieza por lo que parece más simple y casi nunca lo es: decidir qué se cuenta como resultado.

La unidad de medida correcta para una decisión de arquitectura es el coste por resultado útil: el coste total de producir algo que el negocio acepta, dividido por el número de resultados aceptados en el mismo intervalo. Todo lo demás —coste mensual, coste por servidor, coste por petición— es un paso intermedio válido para diagnosticar y peligroso para decidir.

Coste por resultado útil
=
  ( coste de cómputo
  + coste de red y transferencia
  + coste de almacenamiento
  + coste de bases de datos
  + coste de mensajería y colas
  + coste de servicios gestionados
  + coste de inferencia y embeddings
  + coste de observabilidad
  + coste del trabajo fallido o abandonado
  + coste de supervisión humana )
/
  resultados aceptados por el negocio

# Todas las partidas del numerador se miden en el MISMO intervalo
# y sobre el MISMO perímetro que el denominador.
# Un numerador mensual con un denominador de hora punta no significa nada.

La fórmula no tiene mérito. El trabajo está en dos sitios: decidir qué entra en el numerador —donde casi siempre falta algo— y decidir qué cuenta como resultado aceptado, que es una definición de negocio y no una decisión técnica.

Qué cuenta como resultado

Un resultado útil es el que la organización factura, entrega o reconoce internamente como trabajo hecho. La definición debe cumplir tres condiciones, y las tres se incumplen con frecuencia.

1. Debe ser observable en el sistema. Si el resultado se reconoce en una hoja de cálculo tres semanas después, no se puede usar como denominador de un panel operativo. Hay que instrumentar el momento en que el resultado se produce, aunque su aceptación formal llegue más tarde.
2. Debe incluir el criterio de calidad. «Documento procesado» no es un resultado útil si el procesado puede ser incorrecto. «Documento procesado y aceptado sin corrección manual» sí lo es, porque el segundo es el que ahorra trabajo y el primero solo lo desplaza.
3. Debe ser estable en el tiempo. Un denominador que cambia de definición entre trimestres invalida cualquier serie histórica. Si tiene que cambiar, se recalcula el histórico o se declara el corte, pero no se mezcla.

La jerarquía de denominadores

No hay un único denominador correcto para toda la organización. Hay una jerarquía, y cada nivel responde a una pregunta distinta. El error no es usar el coste por petición: es usarlo para responder a una pregunta que exige el coste por resultado.

Coste fijo, variable, escalonado y de fallo

Antes de intentar reducir un coste conviene saber a qué responde. Un plan de ahorro que ataca la naturaleza equivocada consume trimestres y produce diferencias que se pierden en el ruido de la factura.

La latencia media no debe usarse para fijar objetivos por una razón estructural: es insensible a la cola. Un sistema puede degradarse de forma severa para el dos por ciento de las peticiones sin que la media se mueva de forma perceptible, porque ese dos por ciento apenas pesa en el cálculo. El cliente, en cambio, no experimenta la media: experimenta su petición. Y si esa petición cae en la cola, la media que aparece en el panel es irrelevante para él.

Los percentiles resuelven ese problema porque responden directamente a la pregunta de negocio: qué fracción de las peticiones quedó por debajo del umbral que el cliente tolera. Esa frase es, literalmente, la definición de un objetivo de nivel de servicio de latencia.

Cómo elegir el percentil: por volumen, no por costumbre

La elección del percentil debe hacerse por el número absoluto de peticiones afectadas, no por convención. La aritmética es trivial y casi nunca se hace: multiplica el volumen diario por uno menos el percentil y comprueba si el número resultante te importa.

De ahí salen dos reglas prácticas. En alto volumen, el percentil útil es alto —p99 o p99.9— porque los percentiles bajos describen a poblaciones demasiado grandes para ser tolerables. En bajo volumen con alta criticidad —procesos de negocio donde cada operación tiene valor unitario elevado— el p98 suele ser más representativo que el p99, porque el p99 puede corresponder a un puñado de ejecuciones al mes y su valor oscila de forma errática entre periodos.

La tercera regla es la más importante y no aparece en la tabla: mide siempre al menos dos percentiles. El valor absoluto de uno solo dice poco; la distancia entre dos dice mucho. Un p95 estable con un p99 que se aleja indica que la cola está creciendo por eventos discretos, y eso es un diagnóstico, no una alarma genérica.

Latencia de servicio y latencia extremo a extremo

Por qué la utilización alta destruye la latencia

Hay una relación que explica la mayoría de los desastres de rendimiento derivados de una optimización de costes: el tiempo de espera crece de forma no lineal con la utilización. Para el modelo de colas más simple —llegadas de Poisson, un servidor, tiempos de servicio exponenciales— el tiempo total en el sistema es el tiempo de servicio dividido por uno menos la utilización.

Dos consecuencias que conviene tener presentes al negociar un objetivo de ahorro. La primera: la capacidad ociosa no es desperdicio, es el precio del percentil. Pasar de un 70 % a un 90 % de utilización parece un ahorro de un tercio de la infraestructura y triplica el tiempo de respuesta. La segunda: en este mismo modelo el tiempo de respuesta se distribuye de forma exponencial, de modo que el p99 está en torno a 4,6 veces la media. Un panel que muestre la media en verde y una alerta de p99 disparada no es una contradicción: es lo que predice la teoría.

El percentil de un flujo no se deduce del percentil de sus partes

Esta es la parte del capítulo que más decisiones equivocadas evita. Si una operación de negocio atraviesa varias dependencias y todas deben completarse para devolver la respuesta, la probabilidad de que la petición evite todas las colas es el producto de las probabilidades individuales. Bajo supuesto de independencia, con cada servicio cumpliendo su p99, la fracción de peticiones que superan algún umbral crece con el número de saltos.

Qué produce la cola

Cuando un percentil alto se degrada, el diagnóstico útil no es «el sistema está lento». Es identificar cuál de los mecanismos discretos ha empezado a dispararse. La tabla siguiente ordena las causas más frecuentes en plataformas Java sobre Kubernetes con dependencias gestionadas.

SLI, SLO, presupuesto de error y coste

Un indicador de nivel de servicio es la medición: la fracción de operaciones que cumplen un criterio. Un objetivo de nivel de servicio es el umbral que esa fracción debe alcanzar en una ventana. El presupuesto de error es lo que queda: si el objetivo es que el 99 % de las operaciones se completen en menos de un segundo, el presupuesto es el 1 % restante, y es una cantidad consumible.

La utilidad económica del presupuesto de error es que convierte la fiabilidad en una negociación explícita. Sin él, la discusión sobre si merece la pena pagar más capacidad se resuelve por intuición o por jerarquía. Con él, se puede formular en términos comparables: cuánta capacidad adicional cuesta el siguiente tramo de fiabilidad y cuánto valor protege ese tramo.

Y la relación con el coste es la que ya muestra la tabla de colas: subir el objetivo no cuesta lo mismo en cada tramo. Pasar del 99 % al 99,9 % exige más capacidad ociosa, más redundancia y menos margen de reintento que pasar del 95 % al 99 %. Un objetivo de nivel de servicio es, en su forma más honesta, una decisión de gasto disfrazada de decisión técnica. Conviene tomarla con esa conciencia y con la persona que aprueba el presupuesto en la sala.

El coste AWS por resultado de negocio se calcula sumando todo lo que el flujo consume —incluido lo que consume sin producir nada— y dividiendo por los resultados aceptados en el mismo intervalo. Este capítulo no contiene ningún precio: los precios de AWS varían por región, por familia de recurso y por modalidad de compra, y deben tomarse de AWS Pricing y de la factura propia en el momento del cálculo. Lo que sí contiene es la hoja completa, con cada variable nombrada y su origen declarado.

# ─────────────────────────────────────────────────────────────
# HOJA DE CÁLCULO · COSTE AWS POR RESULTADO DE NEGOCIO
# Todas las variables se instancian con la factura y la
# telemetría propias. Ninguna lleva valor por defecto: un valor
# por defecto es una invitación a no medir.
# ─────────────────────────────────────────────────────────────

# --- 1. Coste directamente atribuible al servicio ------------
C_computo      = horas_computo        * precio_hora_computo
C_almacen      = GB_mes_almacenados   * precio_GB_mes
C_datos        = GB_transferidos      * precio_GB_transferido
C_bbdd         = unidades_consumidas  * precio_unidad
C_mensajeria   = mensajes_procesados  * precio_mensaje
C_gestionados  = invocaciones         * precio_invocacion
C_inferencia   = (ver capítulo 4: tokens, caché, embeddings)

C_directo = C_computo + C_almacen + C_datos
          + C_bbdd + C_mensajeria + C_gestionados + C_inferencia

# --- 2. Coste compartido, con clave de reparto explícita -----
# clave ∈ { peticiones, tokens, segundos_cpu, GB_almacenados }
reparto        = clave_del_servicio / clave_total_del_perimetro
C_compartido   = (C_plano_control + C_balanceo + C_red_interna
               +  C_bbdd_multicliente + C_seguridad) * reparto

# --- 3. Observabilidad: parte del servicio, no gasto externo -
C_observabilidad = C_ingesta_metricas + C_ingesta_trazas
                 + C_ingesta_logs     + C_retencion
                 + C_consultas_y_paneles

# --- 4. Capacidad que se paga y no se usa --------------------
C_ocioso       = capacidad_reservada_no_usada * precio_unidad
C_redundancia  = replicas_de_seguridad        * precio_unidad
C_precalentado = capacidad_para_absorber_picos * precio_unidad

# --- 5. Trabajo que consumió recursos y no produjo nada ------
C_fallido      = (peticiones_rechazadas
               +  peticiones_abandonadas
               +  intentos_descartados) * coste_medio_por_intento

# --- 6. Numerador y denominador ------------------------------
NUMERADOR   = C_directo + C_compartido + C_observabilidad
            + C_ocioso + C_redundancia + C_precalentado
            + C_fallido

DENOMINADOR = resultados_aceptados_en_el_mismo_intervalo

coste_por_resultado = NUMERADOR / DENOMINADOR

Las variables y de dónde sale cada una

Qué mecanismos de AWS resuelven la atribución y cuáles no

La atribución tiene dos mitades. La primera —recursos dedicados a un servicio— la resuelven las etiquetas de asignación de costes y el informe detallado de uso. La segunda —recursos compartidos— no la resuelve ninguna herramienta, porque no es un problema de datos sino de criterio: hay que decidir cómo se reparte y asumir la decisión.

Los cuatro costes que casi nunca están en el cálculo

Cuando una organización calcula por primera vez su coste por operación, el número suele salir bajo. La razón es casi siempre la misma: faltan cuatro partidas que no aparecen como línea propia en ninguna factura.

1. El coste de los picos. Una plataforma que atiende un pico diario de tres veces la media no puede dimensionarse a la media. La capacidad que existe para absorber ese pico se paga las veinticuatro horas y solo se usa unas pocas. Esa diferencia no es ineficiencia: es el precio de no fallar en la hora que más factura. Pero debe estar en el numerador y hay que poder cuantificarla, porque es la primera partida que alguien propondrá recortar.
2. La capacidad ociosa y la redundancia. Réplicas mínimas en varias zonas, nodos de reserva, réplicas de lectura que solo sirven para conmutar. Es capacidad que existe para un escenario que —con suerte— no ocurre. Sacarla del cálculo hace que el coste unitario parezca mejor de lo que es y facilita que se elimine sin evaluar el riesgo que cubría.
3. El coste del trabajo fallido. Peticiones rechazadas, abandonadas por timeout, reintentos descartados y mensajes que acaban en la cola de fallidos. Todas consumieron cómputo, conexiones, consultas y, en flujos con IA, tokens. Ninguna suma al denominador. Una tasa de fallo aparentemente pequeña puede tener un efecto desproporcionado sobre el coste unitario cuando el fallo llega tarde en el flujo, después de haber consumido lo caro.
4. La observabilidad. Ingesta de métricas, trazas y registros, retención y consultas. Es la partida que más a menudo se gestiona por separado, y la que peor sobrevive a un recorte lineal, porque cuando se reduce se pierde precisamente la capacidad de justificar el resto de decisiones.

La telemetría que hace posible el cálculo

Todo lo anterior depende de que la telemetría lleve las etiquetas necesarias para agrupar por la dimensión en la que se toma la decisión. La lista siguiente separa de forma deliberada los atributos que provienen de una convención estándar de los que cada organización tiene que definir.

El coste de una funcionalidad de IA generativa se mide como coste por tarea completada con la calidad mínima aceptada. No como coste por llamada, ni como coste por token, ni como precio de catálogo del modelo. La diferencia entre esas magnitudes no es un matiz contable: es lo que permite que un cambio de modelo baje el gasto en tokens y suba el coste total.

Coste por tarea útil
=
  ( tokens_entrada        * precio_entrada
  + tokens_salida         * precio_salida
  + tokens_razonamiento   * precio_razonamiento
  + tokens_cache_escritos * precio_escritura_cache
  + tokens_cache_leidos   * precio_lectura_cache
  + tokens_embedding      * precio_embedding
  + consultas_vectoriales * coste_consulta_vectorial
  + llamadas_herramienta  * coste_herramienta
  + C_orquestacion        # cómputo, cola, almacenamiento del flujo
  + C_reintentos          # todo lo anterior, por cada intento descartado
  + C_supervision_humana )
/
  tareas_completadas_con_la_calidad_minima_aceptada

# Los precios unitarios se toman de la documentación vigente del
# proveedor. Cambian, varían por modalidad de servicio y por región,
# y no se publican aquí a propósito.

Por qué el precio por millón de tokens no basta

Para que el precio unitario fuera comparable entre dos modelos tendrían que cumplirse tres condiciones simultáneas: que consumieran los mismos tokens de entrada, que produjeran los mismos tokens de salida y que acertaran con la misma frecuencia. Ninguna se cumple, y las tres se pueden medir.

La aritmética de los reintentos

Si un modelo resuelve una tarea con probabilidad p en cada intento y se permiten hasta tres intentos, el número esperado de intentos es la suma de la serie geométrica truncada, y la fracción de tareas que quedan sin resolver es (1 − p)³. De ahí sale un resultado que conviene tener presente: el coste por tarea resuelta es exactamente 1/p veces el coste de un intento, con independencia de cuántos reintentos se permitan. Los reintentos cambian cuántas tareas se resuelven, no lo que cuesta resolver cada una.

Caché: cuándo compensa de verdad

Los mecanismos de caché de contexto suelen facturar la escritura del prefijo cacheado a una tarifa superior a la de entrada normal, y la lectura a una tarifa muy inferior. Llamando w al multiplicador de escritura, r al de lectura y h a la tasa de acierto, la caché compensa cuando h·r + (1 − h)·w < 1, lo que da un umbral de acierto mínimo de h* = (1 − w) / (r − w).

La consecuencia de diseño es concreta: para que la caché acierte, el prefijo tiene que ser estable y estar al principio. Un prompt que empieza con la fecha y hora actuales, con el identificador de sesión o con el nombre del usuario invalida la caché en cada petición y paga el sobrecoste de escritura siempre. Poner lo variable al final y lo estable al principio es un cambio de una línea con efecto directo sobre la factura.

Tres estrategias, ninguna ganadora universal

La comparación útil no es entre marcas de modelo —eso caduca en semanas— sino entre estrategias de uso. Cada una gana bajo condiciones que se pueden enunciar y medir.

Una CPU baja no significa que el sistema sea eficiente, y una CPU alta no significa necesariamente que haya un problema. Ambas afirmaciones incomodan porque la CPU es la métrica más visible de cualquier panel y la más fácil de convertir en objetivo. Pero describe un solo recurso, y una petición puede estar esperando por cualquiera de una docena.

Cómo leer la CPU

La saturación vive en otros sitios

Memoria: el uso importa menos que la presión

La métrica de memoria que se lleva a los paneles es casi siempre el uso, y es la menos informativa. Una JVM con el heap al 80 % puede estar perfectamente sana, y una con el 50 % puede estar dedicando una fracción significativa del tiempo a recolectar. Lo que importa es la presión: cuántas recolecciones ocurren, cuánto duran y qué proporción del tiempo total consumen.

La conexión con el resto del artículo es directa. Las pausas de recolección son eventos discretos que no afectan a la media y sí a la cola, de modo que aparecen en el p99 y no en el p50. Y como el capítulo 2 ha mostrado que el percentil de un flujo se degrada con cada dependencia, una pausa que en un servicio aislado sería tolerable se multiplica en un flujo con varios saltos.

Hay además un efecto económico que rara vez se atribuye a la memoria. Sobredimensionar el heap reduce la frecuencia de recolección y aumenta la memoria reservada por réplica, lo que reduce cuántas réplicas caben por nodo y sube el coste por operación. Infradimensionarlo hace lo contrario y degrada el percentil. La elección correcta no se deduce del uso medio: se deduce del percentil objetivo y del coste por réplica, que son las dos variables del capítulo 6.

La ley de Little: por qué la latencia encarece la infraestructura

La ley de Little establece que, en un sistema estable, el número medio de elementos en el sistema es igual a la tasa media de llegada multiplicada por el tiempo medio de permanencia. Es una identidad, no un modelo: no supone nada sobre la distribución de llegadas ni sobre la política de servicio. Y su consecuencia práctica es la relación más importante entre rendimiento y coste que existe.

# ─────────────────────────────────────────────────────────────
# LEY DE LITTLE APLICADA A CAPACIDAD
#   L = λ × W
#     L = peticiones simultáneamente en el sistema
#     λ = tasa media de llegada (peticiones por segundo)
#     W = tiempo medio de permanencia (segundos)
#
# Válida para cualquier sistema estable, sin supuestos sobre la
# distribución de llegadas ni de servicio. Es una identidad, no
# un modelo: si el sistema es estable, se cumple.
# ─────────────────────────────────────────────────────────────

# Ejemplo (ilustrativo): λ = 200 req/s, W = 0,25 s
L = 200 × 0,25 = 50 peticiones en curso

# Una dependencia añade 250 ms al tiempo de permanencia.
# El tráfico NO cambia.
L = 200 × 0,50 = 100 peticiones en curso        # ×2

# Cada réplica sostiene 50 peticiones en curso sin degradar:
replicas = ceil(L / 50)                          # 1 → 2

# Conclusión: el coste de infraestructura se ha duplicado sin
# atender ni una petición más. La causa está fuera del servicio
# y la factura está dentro.

Cuándo falla el autoescalado por CPU

El autoescalado horizontal basado en CPU es un buen valor por defecto y una mala política universal. Falla de forma predecible en tres escenarios, todos ellos comunes en plataformas con IA generativa.

1. Cargas dominadas por espera. La CPU no sube aunque la cola crezca, así que el escalador no reacciona hasta que la latencia ya se ha degradado y el percentil ya ha incumplido. Cuando por fin reacciona, las réplicas nuevas tardan en estar listas y llegan tarde al pico.
2. Límites de tasa externos. Si el cuello de botella es la cuota de una dependencia, añadir réplicas no aumenta la capacidad real: multiplica el número de clientes que compiten por la misma cuota y sube la tasa de rechazo. Se paga más infraestructura para obtener más errores.
3. Arranques costosos. Una aplicación Java con arranque lento y calentamiento del compilador tarda en ser útil. Un escalador agresivo puede añadir réplicas que degradan el percentil mientras arrancan, en el peor momento posible.

La alternativa no es dejar de escalar: es escalar por una señal que represente la ocupación del recurso escaso. En cargas dominadas por espera, esa señal suele ser la concurrencia en curso o la profundidad de cola, ambas directamente relacionadas con L en la ley de Little. En flujos con límites de tasa, la política correcta puede no ser escalar sino descargar carga de forma controlada, rechazando pronto lo que no se va a poder atender, que es el fallo más barato posible según la máquina de estados del capítulo 1.

Coste, calidad, latencia y capacidad se relacionan en una sola ecuación: el coste por resultado útil es un cociente en el que la infraestructura, la inferencia, la observabilidad y la supervisión humana forman el numerador, y los resultados que el negocio acepta forman el denominador. La latencia y la calidad no aparecen como sumandos: entran por el denominador, porque determinan cuántas operaciones llegan a completarse y cuántas se aceptan.

Los cinco capítulos anteriores han medido esas cuatro dimensiones por separado. Este las junta. La ecuación no es sofisticada —es un cociente— pero permite derivar un resultado que explica por qué la mayoría de los planes de ahorro producen poco efecto: la capacidad de una palanca para mover el coste unitario está acotada por su peso en el numerador, mientras que cualquier palanca del denominador tiene efecto pleno.

# ─────────────────────────────────────────────────────────────
# ECUACIÓN ÚNICA
# ─────────────────────────────────────────────────────────────

margen_unitario = precio_por_resultado − coste_por_resultado_util

coste_por_resultado_util = N / D

  N = C_infra + C_ia + C_observabilidad
    + C_ocioso_y_redundancia + C_fallido + C_supervision

  D = peticiones_entrantes
      × (1 − tasa_de_abandono)          # capítulo 2: latencia
      × tasa_de_aceptacion              # capítulo 4: calidad

# ─────────────────────────────────────────────────────────────
# ELASTICIDADES
# ─────────────────────────────────────────────────────────────
# Si una partida i pesa s_i en N, reducirla un δ reduce el coste
# unitario en s_i · δ.   → elasticidad acotada por su peso.
#
# Si D crece un δ, el coste unitario baja en δ/(1+δ).
#                      → elasticidad ≈ 1, siempre.
#
# Corolario: ninguna palanca del numerador puede superar a la
# mejor palanca del denominador salvo que esa partida domine N.

Qué mueve realmente el coste unitario

La tabla siguiente instancia la ecuación con un reparto de pesos ilustrativo. Los pesos concretos varían mucho entre plataformas —una con IA intensiva puede tener el cincuenta por ciento del numerador en inferencia— y hay que calcularlos con la factura propia. Lo que no varía es la estructura: las dos últimas filas superan a todas las anteriores.

Las cuatro dimensiones tiran unas de otras

Un benchmark es aprobable cuando cumple tres condiciones: la hipótesis se escribió antes de ver los datos, cualquier persona puede reproducir el ensayo con la ficha publicada, y el informe enumera las razones por las que su conclusión podría ser errónea. Ninguna de las tres tiene que ver con la potencia del generador de carga.

Empieza por una hipótesis que pueda ser falsa

La mayoría de los ensayos corporativos empiezan con un objetivo, no con una hipótesis. La diferencia es que un objetivo se persigue y una hipótesis se pone a prueba. Un ensayo que no puede terminar con «no funciona» no es un ensayo: es una justificación con instrumentación.

La ficha del ensayo

Todo lo que no esté en la ficha no se podrá reproducir, y todo lo que no se pueda reproducir no debería sostener una decisión con consecuencias. La plantilla siguiente cubre los catorce bloques que en la práctica hacen falta.

# ─────────────────────────────────────────────────────────────
# FICHA DEL ENSAYO · plantilla
# Todo lo que no esté aquí escrito no se podrá reproducir.
# ─────────────────────────────────────────────────────────────

hipotesis:
  enunciado: "Cambiar X reduce el coste por resultado útil al menos un N %
              sin degradar el p98 de la operación Y por encima de T ms."
  se_rechaza_si: "El coste por resultado útil no baja, o el p98 supera T."
  # Una hipótesis que no puede ser rechazada no es una hipótesis.

trafico:
  origen: "Muestra de N días de producción, incluida al menos una hora punta."
  mezcla_de_operaciones: { crear: 35%, consultar: 45%, exportar: 12%, resto: 8% }
  patron_de_llegada: "Reproducción del perfil real por franja horaria."
  generador: "Tasa de llegada fija, independiente del tiempo de respuesta."
  # Un generador de bucle cerrado introduce omisión coordinada (cap. 2).

payloads:
  distribucion: "p50, p90, p99 del tamaño real. No un tamaño único."
  documentos: "Muestra estratificada por tipo, idioma y longitud."
  datos: "Anonimizados, con la misma cardinalidad y distribución."

concurrencia:
  rampa: "0 → objetivo en M minutos, en escalones."
  meseta: "Duración suficiente para observar GC mayor y renovación de conexiones."
  pico: "Escalón adicional para medir el comportamiento en saturación."

infraestructura:
  region: "La misma que producción. La latencia y el precio varían por región."
  computo: "Familia, tamaño, número de réplicas, límites y peticiones de recursos."
  red: "Zonas de disponibilidad implicadas y transferencia entre ellas."
  limites: "Cuotas de servicio y límites de tasa aplicables, documentados."

plataforma:
  java: "Versión exacta de JDK y distribución."
  spring_boot: "Versión exacta."
  jvm: "Recolector, tamaño de heap, banderas relevantes."
  concurrencia: "Modelo de hilos: plataforma o virtuales."
  pools: "Tamaño de pool JDBC, cliente HTTP y ejecutores."

modelo_de_ia:
  identificador: "Modelo y versión exactos, no la familia."
  parametros: "Temperatura, límite de tokens de salida, formato de respuesta."
  prompts: "Versionados en el repositorio, con hash en el informe."
  cache: "Política, prefijo cacheado y ventana de validez."
  fallback: "Modelo alternativo y condición de activación."
  presupuesto: "Número máximo de intentos por tarea."

dependencias:
  reales: "Cuáles se llaman de verdad."
  simuladas: "Cuáles se sustituyen y con qué distribución de latencia y error."
  # Un simulador con latencia constante elimina la cola que se quería medir.

ejecucion:
  calentamiento: "Descartado del análisis. Debe cubrir compilación JIT y llenado de caches."
  repeticiones: "Mínimo tres ejecuciones completas en momentos distintos."
  aislamiento: "Sin despliegues, migraciones ni tareas programadas durante la ventana."

metricas:
  latencia: "p50, p95, p98, p99 y p99.9, de servicio y extremo a extremo."
  errores: "Por tipo, no solo tasa global."
  resultados: "Aceptados, completados sin aceptar, reintentados, abandonados."
  recursos: "CPU, restricción, memoria, pausas de GC, pools, colas."
  ia: "Tokens de entrada y salida, intentos por tarea, aciertos de caché."
  coste: "Método de atribución declarado (capítulo 3)."

criterio_de_exito:
  primario: "Coste por resultado útil dentro del objetivo de latencia."
  secundario: "Ninguna degradación del p98 por encima de T."
  # El criterio se escribe ANTES de ejecutar.

amenazas_a_la_validez:
  - "Enumeradas de forma explícita en el informe."

Cronología de una ejecución

Amenazas a la validez

Enumerarlas no debilita el informe: es lo que lo hace defendible. Un informe sin limitaciones declaradas se lee como una promesa, y la primera vez que la realidad se aparte del ensayo, todo el trabajo pierde credibilidad de golpe.

Qué debe contener el informe final

El informe es el entregable, no las gráficas. Si un miembro del comité no puede entender qué se midió, con qué condiciones y bajo qué supuestos, la decisión se tomará por confianza en quien presenta, que es precisamente lo que un benchmark debería evitar.

1. Hipótesis, criterio de éxito y criterio de rechazo, escritos antes de ejecutar.
2. Ficha completa del entorno: región, infraestructura, versiones, parámetros y límites.
3. Descripción del tráfico: mezcla de operaciones, distribución de cargas útiles y patrón de llegada.
4. Duración del calentamiento, número de repeticiones y dispersión entre ellas.
5. Percentiles p50, p95, p98, p99 y p99.9, de servicio y extremo a extremo.
6. Desglose de errores por tipo y de resultados por estado, no solo tasas globales.
7. Método de atribución de costes, con la clave de reparto declarada.
8. Fecha de las tarifas utilizadas y versión exacta de cada modelo de IA.
9. Amenazas a la validez identificadas, con su mitigación o su reconocimiento explícito.
10. Coste por resultado útil de cada variante, con su intervalo entre repeticiones.
11. Recomendación, con las condiciones bajo las cuales dejaría de ser válida.

La instrumentación que hace posible el coste por resultado útil se apoya en una decisión de diseño: emitir un registro por tarea de negocio, no por llamada técnica, y repartirlo después en tres señales con propiedades distintas. Las métricas soportan los paneles y las alertas; las trazas soportan el diagnóstico; un evento por operación soporta el cálculo económico.

El registro de la operación

/**
 * Registro de una operación de negocio.
 *
 * Es un objeto de datos deliberadamente plano: se construye durante la
 * ejecución y se entrega completo al final. Registrar cada campo por
 * separado en el momento en que se conoce es lo que hace que, con el
 * tiempo, unos campos se emitan y otros no.
 *
 * ORIENTATIVO. No es una integración lista para producción: falta el
 * tratamiento de errores, la propagación de contexto asíncrono y la
 * gestión del ciclo de vida.
 */
public record OperationReport(

    // ── Identidad ────────────────────────────────────────────
    String  businessOperation,   // taxonomía cerrada: "clasificar-documento"
    String  tenantId,            // alta cardinalidad: ver advertencia
    String  environment,

    // ── Resultado ────────────────────────────────────────────
    Outcome outcome,             // ACCEPTED, COMPLETED_NOT_ACCEPTED,
                                 // ABANDONED, REJECTED, NEEDS_REVIEW
    Duration duration,           // extremo a extremo dentro del servicio
    int     attempts,            // intentos hasta resolver, mínimo 1
    String  failureReason,       // null si outcome == ACCEPTED

    // ── Consumo de IA ────────────────────────────────────────
    String  model,               // identificador exacto del modelo usado
    String  fallbackModel,       // null si no hubo degradación
    long    inputTokens,
    long    outputTokens,
    long    cachedInputTokens,
    long    embeddingTokens,
    int     toolCalls,

    // ── Coste estimado ───────────────────────────────────────
    // Se calcula en el borde con las tarifas vigentes inyectadas
    // como configuración. Es MODELADO, nunca medido, y por eso
    // viaja en un campo con nombre propio.
    BigDecimal estimatedAiCostUnits
) {

    public boolean isUseful() {
        return outcome == Outcome.ACCEPTED;
    }
}

Emisión de las tres señales

/**
 * Emisión de las tres señales a partir de un único registro.
 *
 * La separación importa:
 *   · MÉTRICAS  → cardinalidad baja, agregables, baratas de retener.
 *   · TRAZAS    → cardinalidad alta, muestreadas, con el detalle.
 *   · EVENTO    → una línea por operación, para el cálculo de coste.
 *
 * ORIENTATIVO.
 */
@Component
public class BusinessTelemetry {

    private final MeterRegistry registry;
    private final Tracer tracer;

    public BusinessTelemetry(MeterRegistry registry, Tracer tracer) {
        this.registry = registry;
        this.tracer   = tracer;
    }

    public void emit(OperationReport report) {

        // ── 1. MÉTRICAS ──────────────────────────────────────
        // Sin tenantId: es la etiqueta que multiplica las series.
        Tags tags = Tags.of(
            "business.operation", report.businessOperation(),
            "request.outcome",    report.outcome().name(),
            "gen_ai.request.model", nullSafe(report.model())
        );

        registry.timer("business.operation.duration", tags)
                .record(report.duration());

        registry.counter("business.operation.attempts", tags)
                .increment(report.attempts());

        if (report.isUseful()) {
            registry.counter("business.operation.useful", tags).increment();
        }

        // Los tokens como resumen de distribución, no como contador:
        // interesa el percentil de tokens por tarea, no solo el total.
        registry.summary("gen_ai.usage.input_tokens", tags)
                .record(report.inputTokens());

        registry.summary("gen_ai.usage.output_tokens", tags)
                .record(report.outputTokens());

        // ── 2. TRAZA ─────────────────────────────────────────
        // Aquí sí va tenantId: las trazas se muestrean y no
        // generan una serie temporal por valor distinto.
        Span span = tracer.currentSpan();
        if (span != null) {
            span.tag("business.operation", report.businessOperation());
            span.tag("tenant.id",          report.tenantId());
            span.tag("request.outcome",    report.outcome().name());
            span.tag("business.attempts",  String.valueOf(report.attempts()));
            span.tag("gen_ai.request.model", nullSafe(report.model()));
            span.tag("gen_ai.usage.input_tokens",
                     String.valueOf(report.inputTokens()));
            span.tag("gen_ai.usage.output_tokens",
                     String.valueOf(report.outputTokens()));

            if (report.fallbackModel() != null) {
                span.tag("business.fallback_model", report.fallbackModel());
            }
            if (report.failureReason() != null) {
                span.tag("business.failure_reason", report.failureReason());
            }
        }

        // ── 3. EVENTO DE COSTE ───────────────────────────────
        // Una línea por operación hacia el almacén analítico.
        // Es lo que se cruza con el informe de uso y costes para
        // calcular el coste por resultado útil por cliente.
        costEventPublisher.publish(report);
    }
}

Uso desde el caso de uso

El detalle que decide si toda la instrumentación sirve está en dónde se abre el registro. Si envuelve la llamada al modelo, cada reintento produce un registro independiente y se pierde la noción de cuántos intentos costó la tarea. Si envuelve la tarea, el número de intentos es un atributo y todo lo demás se sigue.

/**
 * Uso desde el caso de uso de aplicación.
 *
 * El registro envuelve la TAREA DE NEGOCIO completa, no la llamada al
 * modelo. Es la diferencia que permite contar intentos por tarea
 * resuelta en lugar de llamadas totales.
 *
 * ORIENTATIVO.
 */
public ClassificationResult classify(Document document, TenantId tenant) {

    Instant start   = clock.instant();
    var     builder = OperationReport.builder()
                        .businessOperation("clasificar-documento")
                        .tenantId(tenant.value())
                        .environment(environment);

    int attempts = 0;

    try {
        while (attempts < maxAttempts) {
            attempts++;

            ModelResponse response = modelPort.complete(promptFor(document));

            builder.accumulateTokens(
                response.inputTokens(),
                response.outputTokens(),
                response.cachedInputTokens()
            );
            builder.model(response.modelId());

            ValidationResult validation = validator.validate(response);

            if (validation.isValid()) {
                telemetry.emit(builder
                    .attempts(attempts)
                    .outcome(validation.needsHumanReview()
                             ? Outcome.NEEDS_REVIEW
                             : Outcome.ACCEPTED)
                    .duration(Duration.between(start, clock.instant()))
                    .build());

                return validation.result();
            }

            builder.failureReason(validation.reason());
        }

        // Presupuesto de intentos agotado: la tarea NO suma al
        // denominador, pero todo lo consumido sí suma al numerador.
        telemetry.emit(builder
            .attempts(attempts)
            .outcome(Outcome.ABANDONED)
            .duration(Duration.between(start, clock.instant()))
            .build());

        throw new ClassificationFailedException(document.id());

    } catch (RateLimitedException e) {
        telemetry.emit(builder
            .attempts(attempts)
            .outcome(Outcome.REJECTED)
            .failureReason("rate_limited")
            .duration(Duration.between(start, clock.instant()))
            .build());
        throw e;
    }
}

Configuración de Spring Boot Actuator

# Histogramas agregables en el servidor, no percentiles calculados
# en cada instancia. Los percentiles precalculados por instancia NO
# se pueden promediar ni sumar entre réplicas: agregarlos produce un
# número que no corresponde a ninguna distribución real.
management.metrics.distribution.percentiles-histogram.http.server.requests=true
management.metrics.distribution.percentiles-histogram.business.operation.duration=true

# Cubos alineados con los umbrales del objetivo de nivel de servicio.
# Un cubo en el umbral exacto permite calcular el cumplimiento sin
# interpolar, que es la fuente habitual de discrepancias entre el
# panel y el informe contractual.
management.metrics.distribution.slo.business.operation.duration=200ms,500ms,1s,2s,5s

# Atributos de recurso comunes a métricas, trazas y registros.
management.opentelemetry.resource-attributes.deployment.environment=production
management.opentelemetry.resource-attributes.service.namespace=plataforma-b2b

# Muestreo: conservar el 100 % de lo que falla y muestrear el resto.
# El detalle de la cola está en las trazas de las peticiones lentas,
# no en las rápidas.
management.tracing.sampling.probability=0.05

Consultas que responden a la pregunta económica

# ── Cumplimiento del objetivo de latencia por operación ──────
# Fracción de operaciones por debajo de 1 s, calculada a partir de
# los cubos del histograma. No usa histogram_quantile: para un
# umbral fijo, contar el cubo es exacto y interpolar no lo es.

sum by (business_operation) (
  rate(business_operation_duration_seconds_bucket{le="1.0"}[5m])
)
/
sum by (business_operation) (
  rate(business_operation_duration_seconds_count[5m])
)

# ── p98 de la operación de negocio ───────────────────────────
# Agregando primero los cubos de TODAS las réplicas y calculando
# el percentil después. El orden importa: calcular el percentil por
# réplica y promediarlo es un error frecuente y silencioso.

histogram_quantile(
  0.98,
  sum by (le, business_operation) (
    rate(business_operation_duration_seconds_bucket[5m])
  )
)

# ── Intentos por tarea resuelta ──────────────────────────────
# El indicador que revela si un cambio de modelo ha desplazado
# coste hacia los reintentos.

sum by (business_operation) (rate(business_operation_attempts_total[15m]))
/
sum by (business_operation) (rate(business_operation_useful_total[15m]))

# ── Tokens de entrada por resultado útil ─────────────────────
# Sube cuando el contexto recuperado crece o cuando la caché deja
# de acertar, y ninguna de las dos cosas se ve en el gasto total
# hasta el cierre del mes.

sum by (business_operation) (rate(gen_ai_usage_input_tokens_sum[15m]))
/
sum by (business_operation) (rate(business_operation_useful_total[15m]))

Cómo repartir la información entre señales

Errores de instrumentación que se pagan caros

Un mismo trimestre de trabajo puede reducir la factura de infraestructura y empeorar el margen, o aumentarla y mejorarlo. Este capítulo lo muestra sobre un flujo completo —una API Java y Spring Boot sobre AWS que usa un modelo de IA para clasificar y resumir documentos— comparando tres escenarios con exactamente el mismo tráfico de entrada.

El sistema

Los tres escenarios

Base. El sistema tal como está: modelo de calidad alta, contexto generoso, capacidad con margen y una fracción moderada de solicitudes que pasan por revisión humana.

B · optimización local. Un trimestre de trabajo con dos objetivos aprobados en comité: reducir el coste de infraestructura y reducir el coste de IA. Se suben los objetivos de utilización y se recortan réplicas; se cambia a un modelo con un precio unitario del cuarenta por ciento del anterior. Ambos objetivos se cumplen.

C · optimización de negocio. El mismo trimestre dedicado a otra cosa: recortar el contexto recuperado y estabilizar el prefijo cacheable, escalar por concurrencia en curso en lugar de por CPU, fijar un presupuesto explícito de intentos con timeout ajustado, y añadir capacidad para absorber el pico. El coste de infraestructura sube.

Parámetros declarados

Resultados derivados

Por qué B parecía un éxito

Esta es la parte del caso que conviene leer dos veces. El escenario B no solo mejoró la métrica que se había fijado como objetivo. Mejoró casi todas las métricas que un comité habría pedido.

• El coste de infraestructura bajó un 14 %. Objetivo cumplido, con evidencia en la factura.
• El coste de IA bajó de 60 a 31, un 48 %. Objetivo cumplido con holgura, aunque menos de lo prometido: el precio unitario cayó un 60 % y los ejemplos añadidos al prompt más los reintentos se comieron la diferencia.
• El coste AWS por resultado útil mejoró un 5 % y el coste de IA por resultado útil mejoró un 43 %. Es el dato más incómodo del caso: incluso las métricas unitarias de cada partida —que son las correctas para juzgar esa partida— apuntaban en la dirección buena.
• El p50 apenas se movió: de 420 a 520 ms. Cualquier panel de latencia media habría mostrado una degradación menor y explicable.

Las tres señales que delataban el problema estaban fuera del perímetro habitual: el p98, que se multiplicó por 2,4; la tasa de revisión humana, que no aparece en ninguna factura de nube porque es coste de personal; y el número de resultados útiles, que cayó casi un 10 % sin que el tráfico entrante cambiara. Solo el denominador contaba la historia completa.

Ninguna de las tres decisiones gana siempre: gana la que ataca la partida que domina el numerador o la tasa que domina el denominador, y ambas cosas se pueden calcular antes de elegir. Ahorrar infraestructura tiene efecto rápido y techo conocido; cambiar de modelo mueve la partida de inferencia y, de rebote, la tasa de aceptación; rediseñar el flujo es lo más lento y lo único que actúa sobre los dos lados del cociente a la vez.

Ante un coste unitario que hay que bajar, casi todas las organizaciones eligen entre esas mismas tres opciones. La elección suele hacerse por disponibilidad de equipo o por afinidad técnica, y rara vez por la única razón defendible: cuál de las tres tiene el mayor efecto esperado sobre el coste por resultado útil, dados los pesos del numerador y las tasas del denominador que ya se han medido.

Bajo qué condiciones gana cada una

Lo que sigue no es un catálogo de descuidos. Cada uno de estos errores se comete con datos correctos, herramientas adecuadas y equipos que saben lo que hacen. El fallo está siempre en el mismo sitio: una magnitud intermedia se presenta como si fuera la magnitud final, y nadie tiene a mano la comprobación que lo desmentiría.

El error que no está en la tabla: confundir correlación con causalidad

Los diecisiete errores anteriores se corrigen midiendo mejor. Este no. Es un error de inferencia, y aparece precisamente cuando la medición es buena: dos series se mueven juntas y se concluye que una causó la otra.

Es especialmente frecuente en la relación entre latencia y negocio, porque es una relación real y bien documentada en la literatura del sector. Que exista en general no implica que el efecto observado en un caso concreto tenga esa magnitud ni esa causa. Un despliegue coincide con un día de la semana, con una campaña, con un cambio de producto y con la estacionalidad. Atribuir la variación al despliegue es una decisión, no una observación.

El efecto de composición

La adopción tiene cuatro capas y un orden que no se puede alterar: primero se define qué cuenta como resultado útil, después se instrumenta, después se calcula y por último se gobierna. Las decisiones de la primera capa cuestan reuniones, no trimestres, y son las únicas que ninguna herramienta puede tomar por la organización.

Primero: diagnóstico

Diez preguntas. No hace falta ninguna herramienta para responderlas, solo honestidad sobre cuánto trabajo manual costaría obtener cada dato hoy. Si una respuesta requiere varios días de cruces en hojas de cálculo, la respuesta operativa es «no».

Bloque 1 · Fundamentos

Son decisiones de definición, no de ingeniería, y por eso se hacen primero: cuestan reuniones, no trimestres. Ninguna herramienta puede tomarlas por la organización.

• ✓ Definir qué cuenta como resultado útil, por operación de negocio, y dejarlo escrito con su criterio de calidad.
• ✓ Acordar la taxonomía de operaciones de negocio, con conjunto cerrado de valores y cardinalidad controlada.
• ✓ Acordar el conjunto cerrado de valores de resultado: aceptado, completado sin aceptar, en revisión, abandonado, rechazado.
• ✓ Etiquetar todos los recursos etiquetables con la etiqueta de asignación de costes y verificar que su valor coincide con service.name.
• ✓ Activar el informe detallado de uso y costes y llevarlo a un almacén consultable.
• ✓ Documentar la clave de reparto del coste compartido, con su justificación y su fecha.

Bloque 2 · Instrumentación

Es el trabajo técnico y el que suele estar en semanas si los fundamentos están acordados. Si no lo están, la instrumentación se hace dos veces.

• ✓ Emitir un registro por tarea de negocio con duración, resultado, intentos, modelo y tokens.
• ✓ Separar señales por cardinalidad: métricas agregadas, trazas muestreadas y un evento de coste por operación.
• ✓ Publicar histogramas con cubos, no percentiles calculados por instancia, con un cubo en el umbral del objetivo.
• ✓ Instrumentar la latencia extremo a extremo en el borde, además de la latencia de servicio.
• ✓ Registrar el coste de revisión humana como una serie propia, aunque provenga de otro sistema.
• ✓ Cruzar el evento de coste con el informe de uso y conciliar el resultado con la factura del periodo.

Bloque 3 · Decisión

Con las dos capas anteriores, estas seis son cálculos, no proyectos. Es donde el trabajo empieza a devolver.

• ✓ Calcular el coste por resultado útil y su desglose por partida, y publicar los pesos.
• ✓ Fijar el objetivo de latencia por operación, con el percentil elegido por volumen de peticiones afectadas.
• ✓ Declarar el presupuesto de error y tratarlo como cantidad consumible en las revisiones.
• ✓ Calcular el techo de cada palanca del numerador antes de comprometer un objetivo de ahorro.
• ✓ Establecer el punto de equilibrio entre coste de modelo y coste de supervisión para cada tarea con IA.
• ✓ Revisar el coste y el margen por cliente antes de cada renovación contractual.

Bloque 4 · Gobierno

Son reglas de proceso. Existen para que lo anterior no se degrade con la rotación de personas y con la presión de los cierres trimestrales, que es lo que ocurre por defecto.

• ✓ Ningún objetivo de ahorro se aprueba sin una restricción explícita sobre percentil y tasa de aceptación.
• ✓ Ningún ensayo soporta una decisión sin ficha reproducible y sin amenazas a la validez declaradas.
• ✓ Ninguna cifra se publica sin su clasificación: medida, modelada o ilustrativa.
• ✓ Ninguna recomendación se cierra sin declarar bajo qué condiciones dejaría de ser válida.
• ✓ El panel de dirección contiene cuatro cifras; el detalle vive en los paneles de ingeniería.
• ✓ Las condiciones que invalidarían una decisión pasada quedan vigiladas como alerta.

A lo largo de trece capítulos, la misma idea ha aparecido con distinto disfraz. La CPU baja que oculta una cola. El coste por pod que baja mientras sube el coste por transacción. El modelo barato que se paga en revisión humana. El throughput de laboratorio que ningún cliente experimenta. El p50 que mejora mientras el p98 destruye la conversión. La redundancia que se recorta justo antes de necesitarla. En todos los casos, la medición era correcta y el denominador estaba equivocado.

La corrección no es sofisticada. Es exigir que toda cifra que sostenga una decisión económica tenga en el denominador el resultado que la organización vende, y que toda propuesta de ahorro declare su techo antes de empezar. Lo primero es un trabajo de instrumentación que suele estar en semanas. Lo segundo es aritmética elemental que casi nadie hace, porque revela que la mayoría de los planes de ahorro tienen un límite máximo mucho menor de lo que se prometió.

Las cuatro cifras

Si de este artículo solo sobrevivieran cuatro números en el panel de dirección, deberían ser estos: coste por resultado útil, porcentaje de operaciones dentro del objetivo de latencia en el percentil elegido, volumen de resultados útiles y consumo del presupuesto de error. Con esas cuatro se puede discutir margen, capacidad y riesgo en la misma frase, y se puede rechazar una propuesta sin recurrir a la jerarquía. Todo lo demás es diagnóstico y pertenece a los paneles de ingeniería.

Cómo puedo ayudar

Si esa pregunta no tiene respuesta en tu organización, una auditoría técnica orientada a coste, capacidad y calidad la produce en pocas semanas. No es un informe de recomendaciones genéricas: es el modelo instanciado con tus datos y la instrumentación que lo mantiene vivo cuando la auditoría termina.

El entregable que más suele cambiar la conversación interna no es el plan de optimización, sino la primera tabla de coste y margen por cliente. Es el momento en que un trabajo que empezó como técnico pasa a formar parte de la revisión comercial, y en que arquitectura deja de defender presupuesto para pasar a explicar margen.

Si prefieres empezar por el material y no por una conversación, los tres artículos vinculados en las referencias cubren la base sobre la que se apoya esta guía: el montaje de la plataforma de señales, el modelo de concurrencia que determina cuánta infraestructura hace falta para un tiempo de permanencia dado, y la separación de capas que permite instrumentar el dominio sin contaminarlo.

Qué respalda cada fuente

AWS, coste y FinOps

• AWS Pricing Fuente de cualquier precio unitario del capítulo 3. Deliberadamente no se reproduce ninguna cifra aquí: varían por región, familia y modalidad de compra.
• AWS Pricing Calculator Herramienta para instanciar la hoja de cálculo del capítulo 3 antes de tener consumo real.
• AWS Cost and Usage Report La fuente de verdad para el cálculo de coste unitario. Detalle por hora, recurso y etiqueta.
• AWS — Split Cost Allocation Data Reparto del coste de un nodo entre los pods que se ejecutan en él. Respalda la fila correspondiente del capítulo 3.
• AWS — Etiquetas de asignación de costes Mecanismo de atribución de recursos etiquetables. Su límite —no reescribe el histórico— está citado en el capítulo 3.
• AWS — Cost Categories Agrupación de líneas de factura en dimensiones de negocio mediante reglas.
• AWS Well-Architected — Pilar de optimización de costes Marco de referencia para la disciplina de coste. Respalda el enfoque de coste unitario del capítulo 1.
• AWS Well-Architected — Pilar de eficiencia del rendimiento Relación entre dimensionamiento, latencia y coste, base conceptual de los capítulos 5 y 6.
• Amazon Builders' Library — Timeouts, retries and backoff with jitter Respalda el tratamiento de reintentos como presupuesto acotado y su efecto sobre la cola (capítulos 1 y 2).
• Amazon Builders' Library — Using load shedding to avoid overload Respalda la afirmación de que rechazar pronto es el fallo más barato posible (capítulos 1 y 5).
• FinOps Framework Marco de la disciplina. Respalda la separación entre informar, optimizar y operar que estructura el capítulo 12.
• FOCUS — FinOps Open Cost and Usage Specification Especificación abierta de datos de coste. Relevante para organizaciones multinube que necesitan un esquema común.

Telemetría, métricas y observabilidad

• OpenTelemetry — Semantic Conventions Referencia de todos los nombres de atributo del capítulo 3 y del capítulo 8.
• OpenTelemetry — Resource Semantic Conventions Origen de service.name, deployment.environment, cloud.provider y cloud.region. Son los atributos estables del esquema.
• OpenTelemetry — Semantic Conventions for Generative AI Origen de gen_ai.request.model y de los atributos de uso de tokens. Área en desarrollo: verificar contra la versión en uso.
• OpenTelemetry — Sampling Respalda la recomendación de muestreo dirigido del capítulo 3: conservar el 100 % de lo que falla.
• Micrometer — Documentación de referencia Medidores, etiquetas y distribución. Base del código del capítulo 8.
• Spring Boot Actuator — Metrics Propiedades de distribución, histogramas y objetivos de nivel de servicio usadas en el capítulo 8.
• Spring Boot Actuator — Tracing Configuración de muestreo y exportación de trazas.
• Prometheus — Histograms and summaries Respalda la afirmación central del capítulo 8: los percentiles por instancia no son agregables.
• Prometheus — histogram_quantile Semántica exacta de la función usada en las consultas del capítulo 8, incluida la interpolación entre cubos.
• Prometheus — Metric and label naming Convenciones de nombrado y advertencias sobre cardinalidad de etiquetas.
• The RED Method Tasa, errores y duración por servicio. El capítulo 8 añade a este esquema el resultado de negocio.
• Brendan Gregg — The USE Method Utilización, saturación y errores por recurso. Estructura del diagnóstico del capítulo 5.
• OpenCost Atribución de coste por espacio de nombres y despliegue en Kubernetes. Citado en el capítulo 3 con su límite: trabaja con los precios que se le configuren.

Plataforma, JVM y fiabilidad

• Kubernetes — Managing resources for containers Peticiones y límites de recursos. Respalda la explicación de la restricción de CPU por cuota del capítulo 5.
• Kubernetes — Horizontal Pod Autoscaling Métricas admitidas para el autoescalado, incluidas las que no son CPU. Base de la alternativa propuesta en el capítulo 5.
• HotSpot Virtual Machine Garbage Collection Tuning Guide Comportamiento de los recolectores y sus pausas. Respalda la relación entre memoria y cola de latencia.
• JEP 444 — Virtual Threads Modelo de concurrencia que cambia cuánta infraestructura hace falta para un tiempo de permanencia dado (capítulo 5).
• Google SRE Book — Service Level Objectives Definición de indicador, objetivo y presupuesto de error usada en el capítulo 2.
• Google SRE Workbook — Implementing SLOs Elección de percentil y de ventana. Respalda la regla de elegir el percentil por volumen de peticiones afectadas.

Teoría de colas y medición de latencia

• J. D. C. Little — A Proof for the Queuing Formula: L = λW (Operations Research, 1961) Fuente original de la ley de Little, base del capítulo 5 y de la relación entre latencia y capacidad.
• J. D. C. Little y S. C. Graves — Little's Law (Building Intuition, INFORMS, 2008) Exposición moderna y condiciones de aplicabilidad. Respalda que la identidad no supone distribución alguna.
• J. Dean y L. A. Barroso — The Tail at Scale (Communications of the ACM, 2013) Fuente de referencia sobre por qué la cola de latencia domina la experiencia en sistemas distribuidos. Capítulo 2.
• Gil Tene — How NOT to Measure Latency Descripción de la omisión coordinada y de sus consecuencias sobre los percentiles publicados. Capítulos 2 y 7.
• HdrHistogram Herramienta para registrar distribuciones de latencia con precisión en la cola y corregir la omisión coordinada.

IA generativa

• Spring AI — Documentación de referencia Integración de modelos y recuperación en aplicaciones Spring Boot, contexto del caso práctico del capítulo 9.
• Spring AI — Observabilidad Métricas y trazas que emite el propio marco, incluidas las de uso de tokens. Complementa el capítulo 8.
• Anthropic — Prompt caching Ejemplo de documentación oficial donde se especifican las tarifas diferenciadas de escritura y lectura de caché y su ventana de validez, que son los parámetros w, r y h del capítulo 4.

Continúa en este sitio

• Observabilidad en Microservicios El montaje de la plataforma de señales —Micrometer, OpenTelemetry, Prometheus y Grafana— que esta guía da por supuesto en el capítulo 8.
• Virtual Threads en Java 21 El modelo de concurrencia que determina cuántas peticiones en curso sostiene una réplica, que es el parámetro que convierte la ley de Little en número de réplicas.
• Arquitectura Hexagonal desde cero Cómo aislar el dominio tras puertos para poder instrumentar la operación de negocio sin contaminar el modelo.
• Arquitectura Java Decisiones estructurales en plataformas Java enterprise, donde se toman las que fijan el techo de coste unitario.
• Spring Boot Arquitectura, rendimiento y configuración, incluidas las propiedades de Actuator usadas en el capítulo 8.
• Inteligencia Artificial Empresarial Adopción de IA en plataformas enterprise: es el contexto donde el coste por tarea útil del capítulo 4 se convierte en decisión de producto.
• Auditoría técnica El servicio que instancia esta guía con los datos de una plataforma concreta: modelo de costes, telemetría de negocio y plan priorizado.
• Servicios de consultoría Arquitectura, modernización, cloud e IA para plataformas Java.
• Hablemos de tu plataforma Para evaluar si el coste por resultado útil se puede calcular hoy en tu organización y qué haría falta.