Cuatro opciones de solicitud de Amazon Bedrock que afectan al costo de inferencia

Incluso después de ajustar los prompts y la lógica de la aplicación, la factura de inferencia de Amazon Bedrock puede seguir creciendo. Las decisiones tomadas en cada solicitud siguen influyendo en cuántos tokens procesa el servicio y en la tarifa que se les aplica. Cuatro parámetros en concreto —la duración de la caché, el nivel de servicio, el esfuerzo de razonamiento y maxTokens— pueden modificar el costo sin cambiar el modelo ni el prompt.

El comportamiento de cada opción depende del modelo y de la carga de trabajo. La publicación original explica cómo se probó cada alternativa y cómo comprobar su efecto a partir de los metadatos de respuesta, los registros y los datos de facturación.

Quienes quieran reproducir estos ajustes pueden empezar por los cuadernos de Amazon Bedrock Samples Mixed TTL Caching y Tenant Isolation with Prompt Caching. Para maxTokens y el esfuerzo de razonamiento, la carpeta 01-low-effort del repositorio de GitHub sample-code-for-genai-cost-management-workshop contiene los ejemplos correspondientes. Cada muestra define su propio ID de modelo, por lo que debe sustituirse, junto con los parámetros de inferencia, para que coincida con el modelo utilizado. La disponibilidad de modelos por región de AWS figura en Models at a glance, mientras que decisiones más amplias como la selección de modelos, la inferencia por lotes, el enrutamiento y la destilación se tratan en Effective cost optimization strategies for Amazon Bedrock.

De dónde procede el costo de inferencia

Cada respuesta de Amazon Bedrock incluye metadatos de uso. Los tokens de entrada y salida se facturan según la tarifa del modelo y el nivel que atendió la solicitud. Las lecturas y escrituras de caché tienen contadores de tokens propios, y los tokens de razonamiento se facturan como tokens de salida.

Duración de la caché de prompts

Cuando una entrada de caché expira antes de que llegue la siguiente solicitud, las instrucciones de sistema, las definiciones de herramientas o el contexto de referencia repetidos vuelven a procesarse. La guía Prompt caching for faster model inference documenta valores de TTL de 5 minutos y 1 hora para los modelos Anthropic compatibles y un TTL mínimo de 30 minutos para los modelos GPT-5.6 compatibles. La compatibilidad y los campos de la API varían según el modelo, por lo que conviene consultar la matriz de compatibilidad vigente antes de elegir una duración.

Además, Amazon Bedrock ofrece almacenamiento implícito en caché de prompts en los modelos compatibles: intenta reutilizar prefijos de prompt elegibles sin controles de caché en la solicitud. Dado que la caché implícita funciona en régimen de mejor esfuerzo y no garantiza un acierto, las opciones de duración de esta sección se refieren a la caché explícita.

En los modelos que lo admiten, esta firma de la API Converse solicita una entrada de 1 hora:

{ "cachePoint": { "type": "default", "ttl": "1h" } }

En los modelos Anthropic compatibles, InvokeModel coloca el mismo valor ttl dentro de cache_control.

Una duración mayor no es automáticamente más barata. La página Amazon Bedrock Pricing publica tarifas distintas para escrituras de 5 minutos, escrituras de 1 hora y lecturas de caché. En Amazon Bedrock, una escritura de 5 minutos para Anthropic Claude Sonnet 5 y Anthropic Claude Opus 5 cuesta 1,25 veces la tarifa de entrada; una escritura de 1 hora cuesta 2 veces, y una lectura de caché cuesta 0,1 veces.

Esas tarifas fijan el punto de equilibrio, suponiendo que cada solicitud reutilice el mismo prefijo y que cada lectura renueve el TTL. Una caché de 5 minutos se amortiza con la primera reutilización dentro de esos 5 minutos. Si las solicitudes con el mismo prefijo llegan separadas por más de 5 minutos, cada una reescribe la entrada a 1,25 veces la tarifa de entrada; en ese patrón, la caché de 1 hora resulta más barata a partir de la segunda solicitud dentro de la hora.

Las tarifas de caché y los mínimos de puntos de control difieren según el modelo, así que la comparación debe repetirse con la página de precios y la guía de caché de prompts correspondientes al modelo utilizado, y después confirmarse con los tokens de lectura y escritura de caché tras el despliegue.

Recomendaciones prácticas: colocar el contenido estable antes que el dinámico, cumplir el mínimo de puntos de control del modelo y usar inferencia bajo demanda, ya que la caché de prompts no funciona con la inferencia por lotes.

Modificar un prefijo almacenado en caché —ya sea una instrucción de sistema o una definición de herramienta— provoca un fallo de caché y una nueva escritura. Los puntos de control se evalúan en el orden herramientas, sistema y mensajes, de modo que un cambio en una sección anterior también invalida las posteriores. Los prompts que cambian con frecuencia deben versionarse para que cada versión tenga su propia entrada de caché. En la prueba del autor, seis llamadas a Claude Sonnet 5 con un punto de control de 1 hora, cambiando una vez el prompt de sistema y una vez la definición de herramienta, produjeron en cada modificación cero lecturas de caché y una nueva escritura.

AWS describe las entradas de caché como limitadas a la cuenta y la región, no a los inquilinos. En una aplicación multiinquilino se puede anteponer al prefijo almacenable un hash SHA-256 específico del inquilino, patrón descrito en Optimizing cost and latency with Amazon Bedrock prompt caching for Anthropic models. La autorización del inquilino debe aplicarse antes de construir el prompt. El hash divide las entradas dentro de una misma cuenta; las cargas de trabajo reguladas que necesiten una frontera de datos estricta deben mantener cada inquilino en una cuenta de AWS separada.

El valor predeterminado de 5 minutos conviene cuando la reutilización es frecuente. Conviene pasar a una duración mayor admitida cuando el mismo prefijo se repite al menos dos veces por hora con intervalos superiores a 5 minutos. Para superar a la ausencia total de caché, la caché de 1 hora necesita tres solicitudes por hora.

Niveles de servicio para cargas tolerantes a la latencia

Los trabajos en segundo plano, los sistemas de evaluación, los resúmenes nocturnos y los rellenos de datos no siempre requieren el perfil de latencia del tráfico interactivo. En los modelos que admiten Flex, este se selecciona con esta firma de solicitud:

{ "serviceTier": { "type": "flex" } }

El nivel Standard se solicita con default, no con standard, y también se puede omitir serviceTier:

{ "serviceTier": { "type": "default" } }

La compatibilidad de niveles es específica de cada modelo y debe registrarse por versión exacta. Las fichas de Amazon Nova 2 Lite y OpenAI gpt-oss-120b indican Flex como compatible, mientras que las de Anthropic Claude Sonnet 5 y Anthropic Claude Opus 5 en Amazon Bedrock lo marcan como no compatible. Una solicitud Flex enviada a un modelo no compatible falla con una ValidationException en lugar de ejecutarse silenciosamente en Standard: la solicitud del autor a Claude Sonnet 5 devolvió precisamente ese error.

Si la política admite Standard como alternativa, el error de nivel no compatible puede capturarse y reintentarse una vez con default. No debe reintentarse cualquier ValidationException, porque las solicitudes mal formadas generan la misma excepción. Los reintentos a nivel de aplicación deben limitarse; la estrategia de reintentos acotados del SDK de AWS ya gestiona la limitación y los errores transitorios.

Las solicitudes Flex necesitan un plazo definido por quien las invoca. Una respuesta admitida informa del nivel resuelto, que también puede verificarse con la métrica ResolvedServiceTier de Amazon CloudWatch. Las tarifas exactas figuran en Service tiers for optimizing performance and cost y en la página Amazon Bedrock Pricing del modelo en cuestión.

La prueba de Flex del autor en Amazon Nova 2 Lite empleó 200 solicitudes default y 200 flex enviadas en pares intercalados. Ambos niveles procesaron la misma cantidad de tokens de entrada y salida, las 400 solicitudes se resolvieron en el nivel solicitado y la diferencia de latencia mediana fue demasiado pequeña para distinguirla del ruido. En el momento de la redacción, la tarifa Flex publicada para Nova 2 Lite en us-west-2 era la mitad de la tarifa Standard, y la factura lo reflejó. El tráfico sensible a la latencia debe permanecer en default.

Esfuerzo de pensamiento adaptativo

Los tokens de razonamiento se facturan como tokens de salida. Claude Sonnet 5 y Claude Opus 5 ejecutan el pensamiento adaptativo con esfuerzo high de forma predeterminada, incluso cuando la solicitud omite el campo thinking. Una aplicación migrada desde Claude Sonnet 4.6 sin cambios empieza entonces a facturar tokens de pensamiento, y maxTokens ahora limita el pensamiento más el texto de respuesta. Claude Haiku 5.5 usa medium por defecto. Los tres modelos admiten low, medium, high, xhigh y max. El esfuerzo de una tarea se reduce con esta firma de solicitud:

{
  "thinking": { "type": "adaptive" },
  "output_config": { "effort": "low" }
}

El valor de effort pertenece a output_config, no al interior de thinking. Conviene revisar la documentación Adaptive thinking cada vez que se cambie de modelo.

El autor probó un agente con llamadas a herramientas construido sobre Claude Opus 5. Sus tres tareas siguen el diseño de Build long-horizon agents with Grok 4.7 on Amazon Bedrock y cada una tiene una única respuesta correcta. Cada tarea se ejecutó ocho veces en cada nivel de esfuerzo. Mediana de tokens de salida:

Que un esfuerzo menor conserve la precisión depende del modelo y de la tarea, por lo que la medición debe hacerse sobre tareas parecidas a la carga real.

En la carga de trabajo Invoke Bedrock model for code generation de Amazon Bedrock Samples, la mediana de tokens de salida fue de 676 con esfuerzo low y de 743 con high, una diferencia dentro de la variación entre ejecuciones, y los programas evaluados pasaron en todos los niveles.

Los recuentos de tokens de salida por solicitud, la métrica AWS/Bedrock OutputTokenCount de CloudWatch, los registros de invocación y una tasa de acierto por tarea permiten evaluar el ajuste. Las tareas rutinarias y bien delimitadas pueden empezar por debajo de high; high debe mantenerse donde las pruebas de calidad demuestren que la tarea lo necesita. Una reducción de tokens que rompe la tarea no es un ahorro.

Límites de tokens de salida

maxTokens actúa como techo de salida a nivel de aplicación: acota lo que un prompt defectuoso, una regresión o un bucle pueden generar antes de que la solicitud se detenga. La regla de cuotas está documentada en How tokens are counted in Amazon Bedrock: el servicio descuenta los tokens de entrada más maxTokens cuando comienza la solicitud, por lo que un valor sobredimensionado reduce la concurrencia.

Un techo de salida no es un control de seguridad. Amazon Bedrock Guardrails sigue siendo el control estándar de IA responsable en cargas de trabajo de IA generativa en producción: puede filtrar contenido, detectar ataques de prompts y comprobar el anclaje en entradas y respuestas compatibles, como se describe en Detect and filter harmful content by using Amazon Bedrock Guardrails.

maxTokens debe fijarse por tipo de tarea tras observar una distribución representativa de tokens de salida:

{ "inferenceConfig": { "maxTokens": 155 } }

Los parámetros de solicitud están documentados en Inference using Converse API.

En la prueba del autor sobre Claude Sonnet 5, cinco salidas normales llegaron como máximo a 103 tokens, por lo que se eligió una cota ilustrativa de 155 tokens con margen. Después se envió dos veces el mismo prompt deliberadamente verboso con el pensamiento adaptativo desactivado: una bajo un techo de 2.048 tokens y otra bajo la cota de 155. La primera generó 2.048 tokens de salida y la segunda 155, de modo que la cota evitó 1.893 tokens de salida. Ambas solicitudes se detuvieron en max_tokens, por lo que las dos respuestas quedaron truncadas. Una cota limita el gasto pero no vuelve útil un prompt inadecuado, y dentro de una cadena de varios turnos o agéntica un turno truncado puede romper los pasos siguientes.

Para la calibración en producción deben compararse los percentiles 95 y 99 (P95 y P99) de cada tipo de tarea y añadirse margen al percentil elegido. Con el pensamiento adaptativo activado, maxTokens también limita los tokens de pensamiento, por lo que la calibración debe hacerse con el pensamiento habilitado. P95 restringe la exposición de forma más agresiva pero acepta un mayor riesgo de truncamiento; P99 conserva más respuestas válidas de cola larga con un techo mayor. Las detenciones por max_tokens deben monitorizarse y la solicitud investigarse antes de elevar el límite de la tarea.

En conjunto

El mismo ciclo de prueba sirve para cada parámetro: confirmar la compatibilidad del modelo, cambiar una única opción de solicitud, medir tokens o costo y seguir la calidad o la finalización. Los equipos que enrutan entre modelos deben mantener un registro de capacidades por versión de modelo, región y API —duración de caché admitida, niveles de servicio, niveles de razonamiento y techo de salida—, validar cada solicitud contra ese registro antes de enviarla y luego comprobar en la respuesta el nivel resuelto y los contadores de caché.

Señales a vigilar

Los percentiles P95 y P99 de cada tipo de tarea deben derivarse de la telemetría de aplicación etiquetada por tarea o de los registros de invocación.

Conclusión

Las cuatro opciones residen dentro de la solicitud de inferencia. La compatibilidad del modelo debe revisarse cada vez que cambie el modelo; después, un parámetro cada vez puede modificarse y su efecto medirse en la aplicación.

Recursos para evaluar estas opciones según la carga de trabajo: la consola de Amazon Bedrock en console.aws.amazon.com/bedrock; Prompt caching for faster model inference; Service tiers for optimizing performance and cost; Adaptive thinking; Detect and filter harmful content by using Amazon Bedrock Guardrails; Effective cost optimization strategies for Amazon Bedrock; y las muestras y publicaciones relacionadas Invoke Bedrock model for code generation y Build long-horizon agents with Grok 4.7 on Amazon Bedrock.