Todos escuchamos la promesa: Graviton ofrece mejor precio-rendimiento. Y este año la apuesta subió: Graviton5 ya está disponible en general, con 192 núcleos por socket, la memoria DDR5 más rápida de la nube y un mensaje de marketing claro: está construido para la era de la IA agéntica. Lo que casi nadie hace es medir qué significa todo eso para su propio workload.

Esta charla lo mide en EKS. Tres clases de workload en el mismo clúster, con node groups x86 y Graviton: una aplicación Java de alta concurrencia (donde importa que un vCPU de Graviton sea un núcleo físico y no un hermano de hyperthreading), MongoDB (que vive del ancho de banda de memoria) y la nueva: un modelo open-weight cuantizado corriendo con Ollama sobre CPU, midiendo tokens por segundo y costo por millón de tokens. Para cada una muestro el número y el porqué, con profiling continuo de eBPF y flame graphs que enseñan adónde se va el tiempo en cada arquitectura. De yapa: la evolución generacional medida, de m5 a M9g.

La charla es deliberadamente angosta y profunda: tres workloads, tres porqués, y una regla de decisión por clase de workload. La audiencia se lleva: un criterio medido para decidir qué corre en ARM y qué no (incluyendo si tu modelo local de IA puede vivir en los nodos que ya pagas), el harness open source completo (k6, Prometheus, Pyroscope, buildx multi-arch, Karpenter) para repetirlo todo en su propia cuenta, y el camino de migración real en EKS: node groups mixtos, Spot más Graviton, y el bloqueador del que nadie habla: los DaemonSets. Todos los números son propios; donde cito a terceros, son mediciones independientes, no marketing.