En la guerra diaria por la capacidad de GPU, la noticia no suele llegar con fanfarria. A veces llega en forma de número que cambia en una tabla, un sábado cualquiera, y que solo notas cuando el presupuesto ya estaba cerrado. Eso es lo que ha ocurrido con los EC2 Capacity Blocks for ML de AWS, donde se ha detectado un incremento aproximado del 15 % en algunos de los paquetes más codiciados para cargas de inteligencia artificial.
El caso más comentado afecta a instancias de la familia P5 con NVIDIA H200, usadas para entrenamiento e inferencia a gran escala. En concreto, la p5e.48xlarge (un “bloque” con 8 aceleradores NVIDIA H200) habría pasado de 34,61 a 39,80 dólares por hora en la mayoría de regiones. En paralelo, la p5en.48xlarge sube de 36,18 a 41,61 dólares por hora. La subida no es anecdótica: en entornos donde se reservan ventanas para entrenamientos largos o despliegues críticos, un 15 % es suficiente para romper la planificación de FinOps, cambiar decisiones de arquitectura y reabrir debates internos que parecían cerrados.
Qué se está pagando aquí: garantía de capacidad, no solo “GPU por horas”
Para un medio de administradores de sistemas, el matiz clave es que Capacity Blocks no se comporta como el on-demand estándar. No es simplemente “arranco una instancia cuando quiero”. Es un mecanismo para reservar capacidad de GPU con antelación y ejecutar trabajos en una ventana concreta, algo que los equipos de infraestructura usan como seguro frente a dos problemas habituales:
- Stock y cuotas: la GPU de última generación no siempre está disponible cuando el proyecto entra en fase de ejecución.
- Planificación operativa: hay entrenamientos que no se pueden interrumpir alegremente y despliegues que dependen de un “slot” de cómputo garantizado.
En la práctica, muchos sysadmins han acabado usando Capacity Blocks como se usaba antes un “bloque de mantenimiento” en CPD: se reserva, se ejecuta y se cierra el periodo. Eso da control… pero también convierte el precio en un dato crítico de calendario. Si el precio cambia, no cambia solo un coste: cambia la viabilidad de una ventana de ejecución.
Cuánto duele en números que entiende cualquiera con guardias y ticketing
Para aterrizarlo: el salto de 34,61 a 39,80 son 5,19 dólares más por hora en la p5e.48xlarge. Si un equipo reserva 100 horas de entrenamiento o inferencia intensiva, el diferencial ya es de 519 dólares por ejecución. Si el pipeline exige 400 horas en un mes (sumando experimentos, retraining, validaciones y backfills), la desviación se convierte en 2.076 dólares mensuales solo para ese bloque, sin contar almacenamiento, red, EBS, snapshots, transferencias o servicios gestionados alrededor.
Y esto es lo que le preocupa a un sysadmin: la GPU rara vez viene sola. Viene con:
- datos en S3 o EFS,
- red de alto rendimiento,
- artefactos y checkpoints,
- colas de trabajo,
- orquestación (Kubernetes/EKS, Slurm, Ray, SageMaker o pipelines propios),
- observabilidad y costes indirectos.
La subida de precio en la capa de cómputo se filtra al resto del sistema porque afecta a la duración de trabajos, a la estrategia de reintentos y a la manera de dimensionar colas.
Por qué ahora: la cadena de suministro vuelve a empujar y los hiperescalares recalibran
La lectura de fondo es sencilla: si suben memorias y componentes, y si la demanda de GPU para IA sigue compitiendo con presupuestos corporativos cada vez más agresivos, es razonable pensar que AWS y otros hiperescalares (Google Cloud, Azure, Oracle, IBM, etc.) empiecen a trasladar parte del incremento a servicios de computación, especialmente donde la demanda es más “inelástica”: entrenamientos críticos, capacidad reservada, y configuraciones de gama alta que tienen alternativa limitada.
No es una acusación ni una teoría conspirativa: es una dinámica de mercado. Pero para IT tiene una consecuencia práctica: la previsibilidad deja de ser un supuesto y pasa a ser una variable que hay que monitorizar.
Qué deberían hacer los equipos de sistemas desde ya
1) Tratar los cambios de pricing como un evento operativo
Igual que se monitoriza latencia o errores 5xx, conviene monitorizar variaciones de coste en servicios críticos. En AWS, eso pasa por:
- presupuestos y alertas,
- detección de anomalías de coste,
- etiquetas de imputación y cuadros de mando por proyecto.
El objetivo no es “pagar menos”, sino enterarse antes de que el coste cambie y poder reaccionar sin apagar incendios en comité.
2) Revalidar estrategia: Capacity Blocks vs. alternativas
Según el caso, puede tener sentido reequilibrar:
- parte en on-demand (si hay capacidad),
- parte en Spot (si el workload tolera interrupciones y checkpointing),
- parte en reserva/compromiso (si el coste total sale mejor y se mantiene la disponibilidad).
Para sysadmins, la regla es conocida: si el job es reanudable, Spot es un arma; si es crítico y no reanudable, pagas previsibilidad.
3) Optimización técnica con impacto real: menos horas de GPU
En IA, reducir horas de GPU suele ser más rentable que discutir céntimos:
- cuantización (cuando el caso lo permite),
- batching inteligente,
- cachés y reutilización de embeddings,
- ajuste de hiperparámetros para evitar “grid search infinito”,
- pipelines que fallen rápido (validación previa antes de encender 8 GPU).
4) Plan B realista: multi-región, multi-proveedor o bare metal
No siempre se ejecuta, pero un plan B reduce dependencia:
- poder mover trabajos entre regiones si la disponibilidad cambia,
- tener infraestructura alternativa (otro proveedor o bare metal) para ciertos lotes,
- diseñar para portabilidad mínima (contenedores, IaC, artefactos reproducibles).
No se trata de “irse de AWS”, sino de no estar atrapado cuando el precio o la capacidad cambian.
La advertencia final: el coste de GPU ya es una señal de riesgo, no un dato contable
Para un administrador de sistemas, esta historia no va solo de dólares por hora. Va de algo más incómodo: la infraestructura de IA está entrando en una fase donde disponibilidad y pricing se mueven como variables estratégicas. Si AWS sube un 15 % un bloque con 8 H200, no es descabellado que el resto del mercado ajuste precios donde haya margen para hacerlo.
Y la pregunta operativa para 2026 no es “¿cuánto cuesta la GPU?”, sino: “¿cómo garantizo que el sistema sigue siendo viable si el coste cambia un fin de semana?”.
Preguntas frecuentes
¿Qué es un EC2 Capacity Block for ML y por qué lo usan los equipos de sistemas?
Es una forma de reservar capacidad de cómputo para ML/IA con antelación, útil cuando se necesita ejecutar trabajos en una ventana concreta y no se quiere depender de disponibilidad on-demand.
¿Qué impacto tiene una subida del 15 % en una instancia con 8 NVIDIA H200?
En los precios citados, la p5e.48xlarge sube de 34,61 a 39,80 dólares/hora. Eso son 5,19 dólares/hora adicionales; a 100 horas, 519 dólares más por ejecución.
¿Spot puede sustituir a Capacity Blocks para entrenamiento con GPU?
Depende del workload. Si hay checkpointing frecuente y tolerancia a interrupciones, Spot puede ser muy eficiente. Si el job es crítico, con plazos cerrados o difícil de reanudar, Capacity Blocks aporta previsibilidad.
¿Qué deberían monitorizar los sysadmins para enterarse de estos cambios a tiempo?
Alertas de presupuesto, detección de anomalías de coste, imputación por etiquetas y paneles por proyecto/entorno (dev/staging/prod), además de revisar periódicamente los costes de las familias de instancia críticas para IA.
vía: AWS sube precios
