Amazon recorta 98% el costo de etiquetar tickets con IA

Amazon cambió un LLM por un modelo de decisión y bajó 98% el costo

Amazon reemplazó Claude Sonnet 4.6 por Strands Decider para etiquetar tickets en uno de los sistemas internos de ticketing más grandes del mundo. El resultado: la misma calidad de etiquetado a 98% menos costo, con un ahorro que el equipo estima en millones de dólares en tokens por año.

La noticia no es que Amazon haya cambiado de modelo. Es que existe una categoría de modelos, los de decisión, que no genera texto: solo elige entre opciones conocidas. Y sirve exactamente para los pasos repetitivos y de alto volumen de un agente: clasificar, rutear, elegir una herramienta, aplicar una política.

Qué es un modelo de decisión y en qué se diferencia de un LLM

Un modelo de decisión recibe un estado y una pregunta con un conjunto cerrado de opciones. Devuelve una probabilidad para cada opción y un puntaje de confianza. No escribe una sola palabra.

En el caso de Amazon, el estado era el ticket y las opciones eran las 20 categorías del sistema: escalamientos de clientes, pedidos de capacidad, alarmas automatizadas, hallazgos de seguridad y todo lo que necesitara encajar en el catálogo.

AWS publicó Strands Decider 2B como open source. Según TechCrunch, el modelo salió el 1 de octubre de 2026, la misma semana en que OpenAI anunció una oferta similar, y está construido sobre el torso de Qwen3.5-2B con una cabeza de puntero de alrededor de un millón de parámetros en lugar de la cabeza generativa habitual. SiliconANGLE precisó que se afinó con un adaptador LoRA de rango 16 y que la escala de 2.000 millones de parámetros se eligió para poder correr en una máquina local con menos de 150 milisegundos de latencia.

El proyecto lo inició Marc Brooker, ingeniero distinguido de Amazon, después de ver Jev, el modelo de la startup TypeSafe AI, según TechCrunch. La versión que Amazon puso en producción para tickets no fue la 2B original: los ingenieros probaron el build E4B basado en Gemma 4 y les dio mejores resultados.

Los números: 78% menos latencia y 70% menos tokens

Los dos ingenieros a cargo del sistema, Carr y Mehul, no migraron a ciegas. Midieron ambos modelos sobre los mismos tickets:

La caída de tokens tiene dos causas. Strands Decider produce una sola salida, la opción elegida, en lugar de un JSON completo. Y su prompt es mucho más corto: las descripciones de las etiquetas de producción no entraban en la ventana de 4.096 tokens del modelo, así que reescribieron cada una de las 20 categorías como un criterio de una o dos frases y las enviaron como opciones de una única pregunta de elección, más una opción ninguna.

El impacto en costo, con precios de lista on-demand de us-east-1:

El costo por ticket de Strands Decider depende de qué tan ocupada esté cada instancia. A unos 640 ms por request, una instancia procesa cerca de 5.600 tickets por hora, lo que daría US$250 por millón a plena capacidad. Con margen para picos, en la práctica queda en unos US$500 por millón: unas 44 veces más barato que Sonnet.

El modelo corre en instancias SageMaker ml.g5.xlarge (una GPU A10G, 24 GB), usa unos 19 GiB y el endpoint escala automáticamente con el tráfico.

Cómo probaron el cambio sin apostar a ciegas

La parte más copiable del caso no es el modelo, es el interruptor. La función Lambda que etiqueta lee una configuración de tres vías desde AWS AppConfig en cada mensaje:

• BEDROCK: Sonnet etiqueta todos los tickets y Strands Decider no se llama.
• DUAL: ambos modelos se llaman en paralelo. El resultado de Sonnet se aplica al ticket y se compara con el de Strands Decider.
• DECIDER: Strands Decider etiqueta todo y Bedrock no se llama.

Correr los dos sobre tráfico real y revisar cada desacuerdo dio más información que cualquier evaluación offline. Y volver atrás era un cambio de configuración de 45 segundos.

La arquitectura completa es estándar: los eventos de ticket llegan a una cola SQS que dispara una Lambda, que lee el ticket y llama al endpoint de SageMaker. CloudWatch lleva los logs, métricas y alarmas, y el stack se define en CDK con etapas de despliegue Beta, Gamma y Prod. Salvo las APIs de ticketing, todo es servicio estándar de AWS, así que cualquier cliente puede replicarlo.

El detalle que rompe comparaciones: el orden de las claves JSON

Un hallazgo contraintuitivo: enviar el mismo contenido con las claves JSON en distinto orden movió las probabilidades de salida hasta 0,19. Desde entonces envían cada request con las claves ordenadas. Si vas a servir un modelo de decisión detrás de una API, conviene verificar esto antes de comparar corridas.

¿Qué significa esto para tu startup?

Si tu producto usa un LLM para clasificar, rutear o etiquetar, probablemente estás pagando por generación de texto que nadie lee. Tres movimientos concretos:

• Separa tus llamadas al LLM en dos bolsas. Por un lado, las que son elección cerrada sobre un catálogo conocido (categoría de un ticket, intención de un mensaje, herramienta a invocar). Por otro, las que requieren razonamiento abierto o generar texto. La primera bolsa es candidata a un modelo de decisión; la segunda no.
• Antes de migrar, corre un modo DUAL. Mide ambos modelos sobre tráfico real y revisa los desacuerdos uno por uno. Es más caro durante la prueba y muchísimo más barato que descubrir en producción que el modelo nuevo falla en una clase específica.
• Reescribe tus etiquetas como criterios cortos. El equipo de Amazon pasó de descripciones largas a criterios de una o dos frases. Eso no solo hizo entrar el catálogo en la ventana del modelo: también obligó a definir qué significa cada categoría, algo que suele estar implícito en el equipo.

El argumento de fondo lo resumió Gary Kotovets, Chief Data, Analytics and AI Officer de Dun & Bradstreet, en Forbes: en su experiencia, filtrar y rankear el material con modelos pequeños antes de llamar al LLM grande reduce los tokens enviados al modelo mayor en aproximadamente 95%. La pregunta que propone no es qué modelo es más potente, sino cuál es el modelo más pequeño que puede hacer este trabajo de forma confiable.

Cuándo NO conviene reemplazar tu LLM

El propio equipo de Amazon marca los límites del enfoque. Un modelo de decisión funciona cuando la tarea es una elección cerrada sobre un catálogo conocido, el volumen es alto y la latencia del camino anterior importaba.

No funciona si:

• Tus etiquetas necesitan texto explicativo, no solo una categoría.
• El catálogo cambia cada semana.
• No puedes meter el contexto útil en unos pocos miles de tokens.

En esos casos, el LLM sigue siendo la herramienta correcta. La tendencia, de hecho, apunta a arquitecturas mixtas. Analytics India Magazine documentó el caso de Shunya Labs, que con un modelo interno de 143 MB y dos capas resuelve cerca del 90% de las consultas con 97,7% de precisión en predicciones de alta confianza, y redujo el tráfico hacia el LLM a 3,9% con un throughput 1,9 veces mayor.

Conclusión

Amazon no reemplazó un modelo caro por uno barato: reemplazó una tarea de generación por una tarea de decisión. Esa distinción es la que vale para tu startup. Antes de negociar precios con tu proveedor de LLM o de saltar al modelo más grande del mercado, revisa cuántas de tus llamadas están generando texto que nadie lee. Ahí suele estar el 98%.

Fuentes

• Strands Agents: Amazon saves millions by replacing Sonnet with Strands Decider (fuente original)
• TechCrunch: Amazon releases its own Jev clone as decision models flood the web
• SiliconANGLE: AWS debuts Strands Decider 2B
• Forbes: Small Language Models And The New Economics Of Enterprise AI
• Analytics India Magazine: Smaller Language Models Could Reshape How Enterprises Deploy AI

Artículos relacionados:

Strands Decider 2B: AWS libera modelo de decisión open source AWS libera Strands Decider 2B, el rival open source de Jev Amazon lanza Strands Decider 2B, rival open source de Jev Strands Harness: AWS abre un agente IA 28% más barato BillAI Bass: Asistente de voz con Raspberry Pi 5 y Strands