📻 Versión en audio: si prefieres escuchar en vez de leer, el resumen del artículo está justo aquí arriba.
Detrás de cada ticket de soporte, alarma de capacidad y hallazgo de seguridad en una empresa del tamaño de Amazon había un LLM de punta leyendo el texto completo y escribiendo un JSON con la categoría. Claude Sonnet 4.6 corrió años en Bedrock etiquetando millones de tickets en 20 categorías fijas, a 2,2 centavos de dólar por etiqueta: unos US$22.200 por cada millón de tickets. Esta semana los ingenieros que mantienen ese sistema publicaron los números de la mudanza: lo reemplazaron por Strands Decider, un modelo de decisión que cuesta alrededor de US$500 por millón de tickets. Un 98% menos, millones de dólares ahorrados al año.
El LLM era toda generación para un trabajo de decisión
La diferencia es conceptual y no hay confusión posible: Sonnet leía el ticket, razonaba y producía un JSON con la etiqueta. El modelo nuevo no sabe escribir texto; recibe un estado y una pregunta con opciones cerradas, y devuelve una probabilidad por cada opción más un puntaje de confianza. Como la pega era literalmente eso —elegir una de 20 etiquetas—, toda la capacidad de redacción del LLM gigante era peso muerto: el sistema aprovechaba solo el último token de cada razonamiento caro.
Los números del antes y el después la dejan clarita: la latencia promedio cayó de 4.215 a 897 milisegundos (78% menos). Los tokens por ticket bajaron de 6.724 a 2.010, y la salida pasó de 170 tokens a literalmente 1. El modelo corre en una GPU A10G de 24 GB, procesa un ticket en unos 640 milisegundos y una sola instancia lo aguanta todo con margen para picos. El promedio de las ejecuciones Lambda bajó 74% el mismo día en que apagaron Sonnet.
El detalle que nadie esperaba y el método sí
Dos lecciones valen la entrada, más allá del ahorro. La primera: el orden de las llaves del JSON cambiaba la respuesta. El mismo contenido con las claves en otro orden movía las probabilidades de salida hasta 0,19. Ahora mandan cada request con llaves ordenadas, y avisan que cualquier persona que compare corridas de un modelo de decisión debería chequear eso antes de creerse sus métricas. Es la clase de fragilidad que ni se comenta cuando el pipeline «funciona».
La segunda es el switch de tres posiciones: BEDROCK etiqueta todo con Sonnet, DUAL llama los dos modelos en paralelo sobre tráfico real, y DECIDER deja solo el nuevo, con reversión en 45 segundos. Juzgar cada desacuerdo de la corrida en paralelo les enseñó más que cualquier evaluación offline. Eso no es una gracia de arquitectura, es disciplina, y es reaplicable gratis en cualquier migración de modelo, no solo esta.
Lo que no aplica y lo que sí
Si tu catálogo de etiquetas cambia cada semana, si necesitas texto explicativo o si el contexto útil no cabe en unos miles de tokens, esta vía no sirve, y los mismos autores lo dicen con nombre y apellido. Pero el patrón general debería doler en todo lo demás: cada vez que armé un agente o un cron que termina siendo «leer texto y elegir entre opciones fijas», el LLM grande es un martillo carísimo para un clavo chico. Ando revisando qué pasos de mis pipelines son realmente generación y cuáles son decisiones disfrazadas de generación, porque el 98% del costo no estaba en la inteligencia: estaba en el hábito.
Fuente de inspiración: Amazon saves millions by replacing Sonnet 4.6 with Strands Decider (strandsagents.com)
