Más allá del precio por token: cómo elegir el modelo OpenAI correcto en Amazon Bedrock

Por qué el precio por token ya no basta

Las organizaciones suelen comparar modelos generativos por su precio por millón de tokens. Es un número simple y aparece en todas las hojas de cálculo, pero las aplicaciones de producción compran resultados, no tokens: un ticket de soporte resuelto, un informe de investigación entregable, o un resumen financiero correcto.

Entre el precio publicado y ese resultado hay multiplicadores que la etiqueta ignora: cuántas veces el modelo acierta, cuántos tokens necesita para acertar y, en cargas de trabajo agenticas, cuántos turnos requiere para completar la tarea. Cada turno suele reenviar la conversación completa, lo que incrementa factura y latencia.

El benchmark que resume este artículo demuestra por qué conviene evaluar el costo por resultado y no solo por token cuando se decide qué modelo desplegar en Amazon Bedrock.

El arnés de benchmarking: cómo se midieron las diferencias

El experimento usa un arnés reproducible (openai-on-aws/benchmarks-openai) que ejecuta la misma ruta de código —la Responses API de OpenAI— contra distintos backends y modelos. Eso permite mantener constante la lógica de evaluación mientras se cambia solamente el proveedor y el ID del modelo.

Se compararon cinco modelos: tres disponibles en Amazon Bedrock (gpt-5.6-luna, gpt-5.6-terra y gpt-5.6-sol) y dos modelos costo-optimizado del API de OpenAI usados frecuentemente como referencia (gpt-5.4-mini y gpt-5.4-nano). Las dos últimas se eligieron porque muchas equipos comienzan con mini o nano y preguntan si migrar a Bedrock vale la pena.

Importante para interpretar resultados: las instancias en Amazon Bedrock se ejecutaron con “reasoning” deshabilitado, mientras que las ejecuciones en el API de OpenAI usaron sus configuraciones por defecto. Es, por tanto, una comparación de configuraciones prácticas de despliegue, no una estimación controlada de la capacidad intrínseca del modelo.

Qué se midió

El arnés midió tres vectores clave:

• Precisión y costo por respuesta correcta en benchmarks de alta exigencia (AIME —matemáticas de competencia—, GPQA Diamond —ciencia de posgrado— y MMLU-Pro).
• Trayectorias multi-turno en tareas de investigación web usando un agente con herramientas reales.
• Entregables profesionales evaluados con rúbricas; la calificación combina controles deterministas y un juez LLM (gpt-5.5) con prompts inmutables cuyo hash se registra en los resultados.

Cada ejecución genera un JSON con marca temporal; los números y gráficas se derivan de esos archivos, y el código es público para que equipos repliquen las pruebas con sus propios datos.

Costo de una respuesta correcta: resultados y lecciones

Para cada benchmark se calculó el gasto total del modelo (incluyendo intentos fallidos) dividido por la cantidad de respuestas correctas observadas. Eso estima el costo real por respuesta exitosa en la muestra.

Algunos hallazgos destacados:

• Niveles de capacidad (tiers) son visibles: por ejemplo, gpt-5.6-sol resolvió el 75% de los problemas de AIME frente al 37% de gpt-5.4-mini. En GPQA Diamond sol obtuvo 68% frente a 43% de mini, y en MMLU-Pro 82% frente a 59%.
• Eficiencia de tokens puede dominar la factura incluso antes de cambios de precio. En la configuración probada (con reasoning deshabilitado en Bedrock), gpt-5.6-luna consumió menos tokens facturados que mini, lo que ya lo hacía más barato por respuesta correcta pese a un precio nominal por token mayor.

Tras la reducción de precios anunciada el 30 de julio de 2026 (luna −80% y terra −20% en Amazon Bedrock), el costo observado por respuesta correcta en AIME fue de $0.0021 para luna frente a $0.0139 para mini en ese conjunto de pruebas. En estos archivos de resultados se usaron supuestos de precio de $0.22/$1.32 por 1M input/output tokens para luna y $2.20/$13.20 para terra; verifique la tier de Bedrock y la región aplicable en la página de precios antes de tomar decisiones.

Estos números muestran que el modelo más barato por token no siempre resulta más barato por resultado cuando se consideran precisión, necesidad de reintentos y eficiencia de tokens.

Costo de las trayectorias de agentes: el efecto de los turnos

Las aplicaciones agenticas (p. ej., asistentes que realizan búsqueda web, recuperación de documentos o llamadas a herramientas) tienen una dinámica distinta: cada turno suele re-enviar el sistema prompt, resultados de herramientas previas y el historial de conversación. El contexto por turno crece linealmente, lo que puede hacer que el total de tokens facturados crezca aproximadamente de forma cuadrática con el número de turnos.

Además del coste, cada turno añade una ronda de latencia. Un modelo que concluye una tarea en cinco turnos en lugar de ocho puede ahorrar más que la simple reducción proporcional de turnos.

Para medir esto se usó una muestra estratificada de 50 preguntas de DeepSearchQA (preguntas multi-paso de investigación web) ejecutadas en un loop de agente real con herramientas web_search y fetch_page. Las respuestas se evaluaron con una pasada determinista combinada con el juez LLM, tal como en las otras pruebas.

La conclusión práctica: optimizar para menos turnos y mayor precisión por intento puede reducir costos operativos más que elegir el modelo con menor precio por token.

¿Puede producir trabajo aceptable por profesionales?

El benchmark incluye entregables profesionales evaluados con rúbricas, no solo preguntas de quiz. La idea es medir si un modelo produce trabajo que un profesional aceptaría o requeriría revisión mínima. El proceso de calificación usa reglas deterministas y el juez LLM gpt-5.5 para mantener consistencia entre ejecuciones.

Los datos de la prueba sugieren que, en estas muestras, modelos de la serie 5.6 en Bedrock ofrecen saltos de capacidad que reducen la necesidad de reintentos y refinamientos humanos en tareas complejas. Eso influye directamente en el costo total por resultado y en la viabilidad de automatizar procesos en producción.

Recomendaciones para equipos y tomadores de decisión en América Latina

• Mida por resultado, no por token: ejecute el arnés (openai-on-aws/benchmarks-openai) con sus propios prompts y flujos de trabajo antes de elegir modelo.
• Considere la naturaleza agentica de sus cargas: soporte, búsquedas y workflows con herramientas pueden generar costos crecientes por turno. Optimizar la estrategia de interacción (menos turnos, prompts más precisos) puede ser más rentable que bajar el precio por token.
• Verifique precios y tiers por región: los archivos del benchmark usan supuestos específicos; confirmen la tier de Bedrock y la región antes de extrapolar cifras.
• Evalúe calidad profesional: si el objetivo es automatizar entregables que exigen rigor, prioricen modelos que reduzcan la cantidad de revisiones humanas, incluso si su precio nominal es mayor.
• Repliquen y ajusten: los resultados pueden cambiar según prompts, temperatura, herramientas usadas y políticas de reasoning. El arnés es reproducible y debe ser la base para decisiones en su contexto.

Conclusión

Elegir un modelo para producción en Amazon Bedrock requiere mirar más allá de la etiqueta de precio por token. La combinación de precisión, eficiencia de tokens y número de turnos en workloads agenticos determina el costo real por resultado. Usar un benchmark reproducible y probar con sus propios datos es la forma más segura de decidir qué modelo ofrece el mejor balance entre costo y calidad para su organización.