Sobrecosto de 1,8 millones de dólares en Claude de Amazon: cómo evitar que el gasto en IA se descontrole

Introducción

Según se ha informado, un proyecto interno de Amazon que utilizaba Anthropic Claude Sonnet acumuló una factura de 1,8 millones de dólares, superando el presupuesto planificado en un 860%, sin ser detectado durante cinco meses, y finalmente nunca llegó a implementarse.

La tarea en sí parecía bastante rutinaria: cotejar información de autores con listados de productos en la plataforma de comercio electrónico de Amazon.

El caso salió a la luz después de que el Financial Times informara de que un ingeniero senior de Amazon había debatido múltiples incidentes de sobrecostos relacionados con IA en una reunión interna de empleados. Sirve como advertencia útil para cualquier organización que pase de usar chatbots ocasionalmente a flujos de trabajo automatizados que pueden generar miles o millones de llamadas de pago al modelo cada día.

Los defectos del software tradicional suelen desperdiciar horas de ingeniería o producir salidas erróneas. Los defectos en flujos de trabajo de IA medidos por uso pueden hacer ambas cosas a la vez, y seguir generando gastos en tokens, herramientas, almacenamiento y cómputo cada minuto que permanecen activos.

La lección no es que las empresas deban dejar de usar IA, sino que los procesos de IA autónomos o de alto volumen necesitan controles financieros tan claros como sus controles de seguridad y calidad.

Qué ocurrió internamente en Amazon

Según personas familiarizadas con el asunto, Amazon utilizó Claude Sonnet en un proyecto destinado a cotejar información de autores con listados de productos en su plataforma minorista.

Según los informes, el despliegue:

• Costó 1,8 millones de dólares
• Superó el presupuesto asignado en un 860%
• Tardó cinco meses en detectarse
• No llegó a entrar en producción

Ingenieros senior describieron algunos errores de codificación relacionados con IA como "catastróficamente caros".

Amazon respondió que están experimentando, aprendiendo y mejorando su forma de utilizar la tecnología, incluida la gestión de la eficiencia de costes. La compañía también afirmó que presentar unos pocos casos aislados como práctica habitual no refleja con precisión el uso de la IA en la organización más amplia de Amazon.

Ambas afirmaciones pueden ser ciertas.

Estos incidentes pueden afectar solo a una pequeña parte de los equipos de Amazon, pero también revelan un problema de control que otras organizaciones deberían tomarse en serio.

El defecto de codificación específico aún no se ha revelado

El informe original en chino atribuía el sobrecosto a un programa sin límite de frecuencia de llamadas que enviaba solicitudes de forma continua en un bucle.

Esta explicación es plausible, pero aún no ha sido confirmada por los informes públicos actuales.

El Financial Times describió errores de codificación, controles de gasto deficientes y detección tardía. No publicó un análisis post-mortem técnico que mostrara:

• El código fuente
• El defecto preciso
• Si el proceso era un bucle infinito
• El número de llamadas al modelo
• La cantidad de tokens de entrada o salida
• Si el modelo se accedía directamente o a través de Amazon Bedrock
• La versión del modelo
• La configuración de uso de herramientas
• Los componentes de infraestructura que generaron los cargos

La conclusión más segura es más prudente: un despliegue fallido de Claude Sonnet generó una factura enorme, y los sistemas de control de Amazon no detectaron el problema durante cinco meses.

A menos que Amazon publique un informe técnico del incidente, cualquier explicación más detallada debe considerarse especulativa.

Este no fue el único problema de costes

Sobrecostes

Según se informa, el mismo informe interno también abordó al menos otros dos casos.

Según se informa, el sobrecoste logístico tardó más de dos semanas en detectarse.

Estos casos son de menor escala que el proyecto de cotejo de autores de 1,8 millones de dólares, pero apuntan al mismo patrón: cuando ningún fallo técnico obliga a detener el proceso, los sistemas de IA basados en uso pueden seguir acumulando costes.

Los trabajos por lotes tradicionales pueden fallar, agotar la memoria o no superar las pruebas.

Los procesos de IA pueden permanecer técnicamente saludables mientras ya están económicamente en quiebra.

Incluso cuando un proyecto ya no produce resultados útiles, puede seguir recibiendo respuestas exitosas de la API, escribiendo registros, llamando a herramientas, reintentando tareas o procesando registros de bajo valor.

Por qué los fallos de costes en IA se comportan de manera diferente

Los costes de las aplicaciones tradicionales suelen estar vinculados a unidades relativamente conocidas:

• Tiempo de servidor
• Capacidad de base de datos
• Almacenamiento
• Transferencia de red
• Horas de trabajo humano

Los flujos de trabajo de IA pueden acumular simultáneamente múltiples niveles de facturación por uso:

• Tokens de entrada
• Tokens de salida
• Contexto en caché y sin caché
• Tokens de razonamiento
• Llamadas a herramientas
• Búsquedas web
• Sesiones de ejecución de código
• Búsqueda vectorial
• Reintentos del agente
• Procesos de trabajo en paralelo
• Historial de conversaciones largas
• Recursos de computación en la nube
• Registros y salida de almacenamiento

Esto produce un efecto multiplicador.

Supongamos que una tarea envía un prompt muy largo, genera una respuesta extensa, llama a dos herramientas, reintenta tras un error y pasa el historial completo a la siguiente ronda. Si la aplicación procesa millones de registros, un pequeño error de diseño puede volverse extremadamente costoso.

Desde una perspectiva operativa, la aplicación puede parecer normal. Las solicitudes siguen devolviendo 200 OK. Los procesos de trabajo siguen activos. Las colas se reducen continuamente. La factura suele ser el primer lugar donde aparece el problema.

Un modelo de costes sencillo para flujos de trabajo de IA

Antes de lanzar un proceso de IA automatizado, calcule primero el coste por cada tarea de negocio completada.

Un modelo simplificado sería el siguiente:

La métrica clave no es solo el coste por token.

Sino:

Coste total por resultado de negocio completado con éxito

Una solicitud más barata con una tasa de fallos más alta, que requiera llamadas repetidas o genere más revisión humana, puede seguir produciendo un flujo de trabajo más caro.

Del mismo modo, un modelo más potente que complete la tarea en menos pasos puede resultar más barato en términos globales.

Primer control: asignar un responsable financiero para cada tarea de IA

Cada flujo de trabajo de IA en producción debe tener un responsable designado que supervise tanto el comportamiento técnico como el gasto.

Ese responsable debe conocer:

• El volumen de negocio esperado
• Los modelos utilizados
• Cada coste esperado
• Los presupuestos diarios y mensuales
• El coste máximo por ejecución
• Las condiciones para detener el flujo de trabajo
• Las personas que reciben las alertas
• El proceso para aprobar límites más altos

Cuando un único trabajador puede emitir solicitudes de forma continua, los presupuestos vagos a nivel de proyecto no son suficientes.

Los presupuestos deben existir en múltiples niveles:

Los niveles más bajos proporcionan el mecanismo de frenado más rápido y eficaz.

Establecer límites estrictos dentro de la aplicación

Las alertas de facturación en la nube son importantes, pero no sustituyen a los controles a nivel de aplicación.

La aplicación debe detenerse o requerir aprobación al alcanzar los límites establecidos.

Los límites útiles incluyen:

• Número máximo de solicitudes por tarea
• Número máximo de pasos del agente
• Número máximo de reintentos
• Número máximo de tokens de entrada
• Número máximo de tokens de salida
• Longitud máxima de contexto
• Número máximo de llamadas a herramientas
• Número máximo de procesos de trabajo en paralelo
• Tiempo máximo de ejecución
• Coste máximo en dólares por trabajo
• Número máximo de registros procesados antes de revisión

Estos controles deben estar desactivados por defecto.

Si el servicio de seguimiento de costes no está disponible, o la aplicación no puede determinar el presupuesto restante, el comportamiento más seguro suele ser pausar en lugar de continuar indefinidamente.

Utilizar un interruptor de emergencia independiente del agente

Los agentes autónomos no deben controlar su propia autoridad final de gasto.

Un servicio independiente debe poder:

• Deshabilitar claves de API
• Rechazar llamadas al modelo
• Pausar colas
• Reducir los procesos de trabajo a cero
• Bloquear herramientas externas
• Revocar roles
• Detener tareas programadas
• Requerir aprobación humana antes de reanudar

Incluso si el agente entra en un bucle de reintentos o produce mensajes de estado engañosos, el interruptor de emergencia debe seguir disponible.

Pruébelo antes de producción.

Los controles que nunca se han utilizado son solo teoría.

Supervisar cada llamada al modelo

Las organizaciones que utilizan Amazon Bedrock pueden habilitar el registro de llamadas al modelo para las invocaciones compatibles de bedrock-runtime.

AWS indica que estos registros pueden incluir datos de solicitud y respuesta, metadatos, identificadores de modelo, identificadores de solicitud, información de identidad y uso de tokens. Los destinos de registro pueden incluir Amazon CloudWatch Logs y Amazon S3.

El registro de invocaciones está desactivado por defecto.

El equipo debe habilitar únicamente los datos necesarios para la observabilidad y aplicar controles adecuados de privacidad, seguridad, retención y enmascaramiento. Los prompts y las salidas pueden contener información sensible de la empresa o de los clientes.

Como mínimo, los registros de seguimiento de costos deben incluir:

• Marca de tiempo
• Aplicación
• Entorno
• Equipo o centro de costos
• Modelo
• Usuario o inquilino
• Número de tokens de entrada
• Número de tokens de salida
• Uso de caché
• Llamadas a herramientas
• Número de reintentos
• Identificador de trabajo
• Costo estimado de la solicitud
• Resultado comercial
• Errores o motivos de escalamiento

De esta manera, la facturación puede asociarse con tareas específicas, en lugar de descubrir un total general enorme durante la revisión financiera mensual.

Uso de AWS Budgets para rastrear los costos de Claude en Bedrock

AWS Budgets puede rastrear costos o uso en relación con umbrales establecidos y enviar notificaciones. Las acciones de presupuesto también pueden aplicar controles, como políticas de IAM o políticas de control de servicios, cuando se superan los umbrales. Según la configuración, las acciones pueden ejecutarse automáticamente o esperar la aprobación humana.

Un detalle importante específico de AWS es fácil de pasar por alto.

La documentación de AWS Cost Anomaly Detection indica que este servicio no monitorea productos de terceros vendidos a través de AWS Marketplace, incluidos los modelos de lenguaje de terceros ofrecidos a través de Amazon Bedrock, como Anthropic Claude.

Estos costos siguen apareciendo en Cost Explorer y en la facturación, pero AWS recomienda usar AWS Budgets para alertar sobre este tipo de gastos.

Los presupuestos pueden usar filtros de entidad de facturación para rastrear con mayor precisión los cargos de Marketplace.

Este es exactamente el tipo de detalle de configuración que puede generar una falsa sensación de seguridad. Una empresa podría habilitar la detección de anomalías y asumir que todos los costos de modelos están cubiertos, cuando una categoría de facturación específica no está incluida.

No tratar AWS Budgets como un interruptor en tiempo real

La documentación de AWS indica que el estado de los presupuestos se actualiza varias veces al día.

La documentación también advierte que los costos pueden seguir aumentando antes o después de que se entregue la notificación.

Esto significa que AWS Budgets es útil para la gobernanza financiera, pero por sí solo puede no detener lo suficientemente rápido a un agente de alto rendimiento.

La pila de control debe incluir:

1. Contadores a nivel de solicitud dentro de la aplicación
2. Métricas de uso casi en tiempo real
3. Límites máximos por trabajo y por sesión
4. Alertas de presupuesto en la nube
5. Acciones presupuestarias automatizadas cuando corresponda
6. Revisión financiera diaria para lanzamientos de alto riesgo

Cuanto más rápido gaste dinero un flujo de trabajo, más cerca del punto de invocación deben estar los controles.

Uso de la detección de anomalías para costos dentro de la cobertura del servicio

AWS Cost Anomaly Detection utiliza modelos de aprendizaje automático para identificar patrones de gasto anómalos y ayudar a localizar posibles causas raíz.

AWS indica que este servicio evalúa aproximadamente tres veces al día los datos de facturación procesados.

Puede detectar de manera efectiva crecimientos inesperados en servicios de AWS, cuentas, regiones, tipos de uso y etiquetas de asignación de costos.

Para sistemas de IA, puede identificar anomalías en costos de soporte relacionados con cómputo, almacenamiento, bases de datos o red.

Sin embargo, los equipos deben recordar la limitación de Marketplace mencionada anteriormente y crear AWS Budgets por separado para los costos de modelos de terceros cuando sea necesario.

Usar Service Quotas como límite de seguridad, no como presupuesto

Amazon Bedrock aplica cuotas de servicio para la inferencia de modelos, incluidos límites basados en tokens para modelos y endpoints compatibles.

Las cuotas pueden prevenir un rendimiento ilimitado, pero no están diseñadas para ser presupuestos financieros precisos.

Las cuotas aún pueden permitir gastos muy superiores a los límites proyectados del proyecto. Por el contrario, aumentar las cuotas para resolver problemas de capacidad de producción puede eliminar involuntariamente un límite de seguridad útil.

Por lo tanto, los cambios de cuota deben requerir:

• Justificación comercial
• Proyección de costos actualizada
• Aprobación nominal
• Umbrales de alerta actualizados
• Plan de reversión
• Revisión después del aumento de tráfico

Los límites de velocidad y tokens deben considerarse parte del diseño de riesgo del sistema, no solo obstáculos para la escalabilidad.

Rastrear directamente el uso y los costos de Anthropic cuando corresponda

Para aplicaciones que llaman directamente a Anthropic, la consola de Anthropic proporciona informes de costos y uso.

Los límites de API de Anthropic pueden incluir solicitudes por minuto, tokens de entrada por minuto, tokens de salida por minuto y límites de gasto relacionados con el nivel de uso.

Estos límites pueden reducir el rendimiento no controlado, pero deben complementarse con controles a nivel de aplicación.

Las organizaciones con múltiples equipos también pueden implementar una puerta de enlace de LLM entre las aplicaciones y el proveedor de modelos. La puerta de enlace puede centralizar autenticación, seguimiento de uso, presupuestos, límites de velocidad, enrutamiento de modelos y registros de auditoría.

La puerta de enlace se convierte en un componente de seguridad crítico, por lo que debe operarse y revisarse con el mismo cuidado que cualquier otra capa de acceso de producción.

Comenzar con una muestra representativa pequeña

Según informes, un proyecto de Amazon intentó ejecutar una tarea de coincidencia de datos a gran escala.

Un patrón de despliegue más seguro es:

1. Ejecutar 100 registros representativos.
2. Medir precisión y costo.
3. Ejecutar 1,000 registros.
4. Revisar errores y distribución de tokens.
5. Probar los peores escenarios de entrada.
6. Confirmar los controles de detención.
7. Estimar el gasto para el procesamiento completo.
8. Requerir aprobación antes de procesar el conjunto de datos completo.

No inferir basándose únicamente en el registro promedio.

Los documentos más largos, los registros que fallan al coincidir, los casos ambiguos, los reintentos y los bucles de agentes suelen dominar el costo total.

Usar estimaciones por percentiles, como los costos P50, P95 y P99 por tarea.

Establecer un límite máximo de costo por resultado válido

El flujo de trabajo debe detenerse cuando las llamadas adicionales al modelo ya no sean económicamente razonables.

Para un sistema de coincidencia de autores, métricas útiles pueden incluir:

• Costo por coincidencia de autor exitosa
• Costo por registro revisado manualmente
• Porcentaje de registros resueltos automáticamente
• Tasa de coincidencias incorrectas
• Costo de las coincidencias incorrectas
• Ahorro en comparación con el procesamiento manual
• Número de llamadas al modelo requeridas por resultado aceptado

Un proceso que cuesta $0.02 por solicitud parece barato.

Si requiere 50 llamadas, la mitad de los registros falla y el resto se envía a revisión manual, la economía real puede ser muy deficiente.

Enrutar tareas simples a métodos más económicos

No todos los registros necesitan un modelo de vanguardia.

Una canalización consciente de los costos puede usar:

1. Coincidencia exacta
2. Uniones a bases de datos
3. Reglas
4. Similitud de embeddings
5. Modelos más pequeños
6. Modelos más potentes solo en casos ambiguos
7. Revisión humana para decisiones de alto riesgo

Para proyectos de coincidencia de datos, el software tradicional puede resolver la mayoría de los casos a menor costo y de manera más determinista.

Los LLM deben usarse solo cuando la ambigüedad lingüística realmente lo requiera, no aplicarse automáticamente a cada línea.

La propia guía de precios de Anthropic recomienda elegir el modelo adecuado, usar caché de prompts para contextos repetidos, emplear procesamiento por lotes para trabajos no urgentes y monitorear los patrones de uso.

Evitar reintentos ilimitados

Los reintentos son una fuente común de gasto oculto.

Una solicitud fallida puede ser reintentada por la aplicación, el sistema de colas, el SDK, la puerta de enlace, el administrador de trabajadores, el agente o el orquestador del flujo de trabajo.

Cuando múltiples capas reintentan de forma independiente, una tarea lógica puede generar múltiples solicitudes pagadas.

Definir una política de reintentos unificada que incluya:

• Número máximo pequeño de intentos
• Retroceso exponencial
• Jitter
• Manejo explícito de errores no reintentables
• Idempotencia
• Colas de mensajes muertos
• Alertas para fallos repetidos
• Presupuesto por tarea que incluya todos los costos relacionados, incluidos los reintentos

Los errores no deben crear bucles económicos infinitos.

Separar las credenciales de desarrollo y producción

Los scripts de prueba no deben heredar límites de nivel de producción.

Usar cuentas o espacios de trabajo independientes, claves de API, roles de IAM, presupuestos, cuotas, registros, fuentes de datos y permisos de red.

Los entornos de desarrollo deben tener límites de gasto deliberadamente bajos.

Un prototipo que entra accidentalmente en un bucle debería fallar con una factura pequeña, no obtener cuotas de producción de nivel empresarial.

Revisar el código generado por IA como se revisa la infraestructura financiera de producción

El incidente involucró un proyecto asistido por IA, pero el problema clave no es si el código fue generado por un modelo.

Lo importante es si el código puede gastar dinero.

Cualquier componente que pueda iniciar solicitudes pagadas a modelos debe someterse a revisión de:

• Terminación de bucles
• Comportamiento de reintentos
• Concurrencia
• Expansión de colas
• Contexto máximo
• Límites de llamadas a herramientas
• Manejo de tiempos de espera
• Mecanismos de cancelación
• Atribución de costos
• Rutas de error
• Registro de eventos
• Ejecución de presupuestos
• Comportamiento de apagado de emergencia

Las pruebas unitarias deben incluir escenarios de fallo económico.

Ejemplos: el modelo nunca devuelve una respuesta válida, entrega repetida de tareas, el proceso de trabajo se bloquea después de una llamada pagada, errores recurrentes de límite de velocidad, el contexto crece con las salidas de herramientas en cada turno y el servicio de estimación de costos no está disponible.

El camino normal funcionalmente correcto no es suficiente.

Lista de verificación para el control de costos de IA en producción

Propiedad y planificación

• Un responsable técnico designado es responsable del gasto.

• Se documentan el uso esperado y el costo por resultado exitoso.

[ ] Los entornos de desarrollo, preproducción y producción tienen presupuestos independientes.

• El procesamiento a escala completa requiere aprobación explícita.

Control de aplicaciones

• Cada tarea tiene un máximo de solicitudes, tokens, pasos, reintentos y tiempo de ejecución.

• Cada sesión de agente tiene un presupuesto en dólares estadounidenses.

• Los servicios que no son agentes pueden detener el flujo de trabajo.

• Las tareas se pausan cuando no se puede leer el presupuesto restante.

• Se evita el trabajo duplicado mediante la idempotencia.

Monitoreo

• Cada llamada al modelo se atribuye a un equipo, proyecto, usuario y tarea.

• Se registra el uso de entradas, salidas, caché, herramientas y reintentos.

• Se configuran alertas tanto para la tasa de gasto como para el gasto total.

• Se habilita una revisión diaria durante el lanzamiento inicial en producción.

• El equipo comprende los elementos de costo no cubiertos por la detección de anomalías.

Calidad y economía

• El costo se mide por cada resultado comercial exitoso.

• Se utilizan código convencional y modelos más pequeños cuando corresponde.

• Se han probado los costos en el peor de los casos y en percentiles altos.

• Se incluyen los costos de revisión humana.

• El flujo de trabajo se detiene cuando las llamadas adicionales ya no aportan valor.

Gobernanza

• El código generado por IA se somete a revisión humana.

• Los aumentos de presupuesto y cuotas requieren aprobación.

• El interruptor de emergencia se prueba periódicamente.

• La respuesta a incidentes incluye a las partes interesadas financieras y técnicas.

• El equipo revisa el gasto después de cada cambio importante en el modelo o en el mensaje.

Lecciones de la respuesta de Amazon

Se informa que los ingenieros de Amazon están construyendo salvaguardas automatizadas para futuros proyectos de IA.

Esa es la dirección correcta, pero la automatización debe existir en múltiples niveles.

Un sistema de control maduro debería combinar límites duros en la aplicación, límites del modelo y de la puerta de enlace, presupuestos de nube, acciones automatizadas, registros de uso, paneles financieros, aprobaciones humanas y revisiones periódicas.

La compañía también eliminó anteriormente una tabla de clasificación interna que alentaba a los empleados a maximizar el uso de su herramienta de desarrollo Kiro. Según el Financial Times, esa tabla fomentaba el "tokenmaxxing", un fenómeno en el que los empleados aumentaban el consumo de tokens para mejorar su posición.

Este es un recordatorio útil: los incentivos pueden socavar el control de costos.

Si los empleados son recompensados por usar más IA en lugar de generar valor comercial medible, el uso aumentará incluso sin mejoras en los resultados.

Las organizaciones deberían recompensar los problemas resueltos, las mejoras de calidad, el tiempo ahorrado, los ingresos generados, el riesgo reducido y la disminución del costo por unidad de producción.

La cantidad de tokens es una métrica de entrada, no una métrica de productividad.

Preguntas frecuentes

¿Amazon realmente gastó $1,8 millones en Claude Sonnet?

El Financial Times informó que un proyecto interno de Amazon que usaba Claude Sonnet acumuló una factura de $1,8 millones. El proyecto, destinado a hacer coincidir información de autores con listados de comercio electrónico, superó el presupuesto en un 860% y no llegó a implementarse.

¿Por qué el sobrecosto no se detectó durante cinco meses?

Los informes públicos indican que Amazon carecía de controles de gasto suficientes y que los errores de codificación fueron uno de los factores que contribuyeron al problema. Amazon no ha publicado un análisis post-mortem técnico para identificar los defectos específicos o las fallas de monitoreo.

¿El problema fue causado por bucles infinitos de IA?

Esa explicación apareció en algunos informes secundarios, pero no ha sido confirmada en los informes principales. La cantidad exacta de solicitudes, la lógica de reintentos, el volumen de tokens y los defectos del código fuente siguen sin divulgarse.

¿Amazon tiene otros casos de sobrecosto de IA?

Sí. Se informa que la misma presentación interna también incluía costos inesperados de aproximadamente $541.000 en un proyecto de auditoría financiera y $134.000 en un proyecto de logística.

¿AWS Cost Anomaly Detection puede monitorear los costos de Claude en Amazon Bedrock?

La documentación de AWS indica que Cost Anomaly Detection no supervisa los productos de terceros de AWS Marketplace, incluidos los modelos Anthropic Claude en Bedrock. AWS recomienda usar AWS Budgets para gestionar estos costos y, cuando corresponda, los filtros de entidad de facturación.

¿AWS Budgets puede detener inmediatamente el gasto descontrolado en IA?

Por sí solo, no. AWS indica que la información de presupuesto se actualiza varias veces al día y que los costos pueden seguir aumentando antes o después del período de notificación. Las aplicaciones de alto tráfico necesitan límites duros a nivel de solicitud e interruptores de emergencia independientes.

¿Los límites de velocidad son equivalentes a los límites de gasto?

No. Los límites de velocidad controlan el rendimiento, mientras que los presupuestos controlan el costo aceptable. Un flujo de trabajo puede funcionar dentro de los límites de velocidad y, aun así, superar ampliamente el gasto planificado durante semanas o meses.

¿Cuál es el control más importante para los agentes de IA?

Establecer un presupuesto duro por cada sesión de agente que incluya solicitudes, tokens, herramientas, reintentos y tiempo. Aplicar ese presupuesto fuera del agente y contar con un método probado para detener el flujo de trabajo de inmediato.

Herramientas relacionadas

• AWS Budgets: Permite rastrear costos y uso en comparación con umbrales, y activar notificaciones o acciones de presupuesto configuradas.
• AWS Cost Anomaly Detection: Detecta patrones de gasto anómalos en AWS dentro de las categorías de facturación compatibles.
• AWS Cost Explorer: Ayuda a los equipos a analizar costos y uso históricos en servicios y dimensiones de facturación de AWS.
• Registro de invocaciones de modelos de Amazon Bedrock: Registra llamadas a modelos compatibles y metadatos relacionados en CloudWatch Logs o Amazon S3.
• Cuotas de servicio de Amazon Bedrock: Muestra límites de modelos y endpoints que pueden restringir el rendimiento de inferencia.
• Consola de Anthropic: Ofrece claves de API, informes de uso, informes de costos, espacios de trabajo y controles a nivel de cuenta para el uso directo de la API de Anthropic.

Enlaces relacionados

• Financial Times: Exceso de gasto en IA de Amazon: Informe principal sobre el proyecto de $1,8 millones y sobrecostos internos adicionales.
• Documentación de AWS Budgets: Guía oficial sobre cómo rastrear costos y uso de AWS con presupuestos.
• AWS Budget Actions: Explica las acciones automáticas o que requieren aprobación humana cuando se superan los umbrales.
• Limitaciones de AWS Cost Anomaly Detection: Documenta el monitoreo de anomalías y la exclusión de cargos de modelos de terceros del Marketplace.
• Registro de invocaciones de Amazon Bedrock: Detalla el registro de invocaciones de modelos para auditoría y depuración.

com/bedrock/latest/userguide/model-invocation-logging.html): Guía oficial de configuración y manejo de datos para el registro de invocaciones de modelos en Bedrock.

• Informes de costos y uso de Anthropic: Describe los informes de costos, uso, tokens, modelos, espacios de trabajo y límites de velocidad en la consola de Anthropic.
• Límites de velocidad de la API de Anthropic: Describe los límites de número de solicitudes, tokens de entrada, tokens de salida y niveles de uso.

Resumen

Según informes, un proyecto interno de Amazon que usaba Claude Sonnet gastó 1.8 millones de dólares, superando el presupuesto en un 860%, sin ser detectado durante cinco meses y sin llegar nunca a implementarse. Según informes, otros proyectos de IA generaron gastos inesperados de cientos de miles de dólares.

Los registros públicos no confirman que el evento principal fuera causado por un bucle infinito de solicitudes. Lo que los registros confirman es la brecha entre la velocidad de gasto de los flujos de trabajo de IA y la velocidad a la que las organizaciones detectan problemas.

Las empresas deberían combinar el seguimiento de solicitudes individuales, presupuestos a nivel de trabajo, límites de tokens y herramientas, reintentos controlados, enrutamiento de modelos, presupuestos en la nube, acciones automatizadas y un interruptor de emergencia que los agentes no puedan anular.

**

La regla más segura es simple: ningún proceso de IA debería ejecutarse durante cinco meses sin demostrar repetidamente que sigue siendo útil, está dentro del presupuesto y está autorizado para continuar.