Convierte la expansión de GPUs de AWS 2027-28 en un plan de capacidad y coste por token

La expansión es una curva de oferta con fecha

Estás fijando el precio de la inferencia de 2027 antes de que se instalen las GPUs que la servirán. El dilema es la oferta con fecha frente al servicio garantizado. El 26 de agosto, AWS y NVIDIA anunciaron una expansión de dos millones de GPUs para la nube de Amazon, que abarca componentes Blackwell Ultra, Rubin y Rubin Ultra en 2027 y 2028. El acuerdo reserva 100.000 GPUs en la infraestructura segura de AWS para cargas de trabajo federales de EE. UU. y de seguridad nacional. Si se resta la asignación segura del pool anunciado, la base para la planificación comercial es de 1,9 millones de GPUs. Usa ese pool reducido antes de fijar el precio de la inferencia.

La expansión se apoya en un compromiso previo de poner en servicio más de un millón de GPUs a partir de 2026. El lote de 2026 establece la primera línea base de servicio; los lotes de 2027 y 2028 definen el horizonte de planificación. Un lote posterior no puede cubrir la brecha de servicio de un trimestre anterior. Mantén la fecha separada de la expansión de marketing. La ventana de planificación es una curva de oferta escalonada.

Resta las GPUs que no puedes servir

Las unidades seguras no están disponibles para el servicio comercial ordinario. Las unidades no productivas no generan tokens para el cliente. Si una unidad no se factura como token, no pertenece al denominador de servicio. La capacidad comercial es el resto tras esas exclusiones. El comportamiento de reserva reduce aún más el pool. El CEO de NVIDIA, Jensen Huang, calificó la alianza AWS-NVIDIA como un motor clave de crecimiento para la era de la IA y afirmó que la demanda supera todas las previsiones. Cuando la demanda va por delante de la oferta, los operadores pueden retener capacidad para el tráfico de pico en lugar de venderla a un precio medio más bajo. La capacidad reservada se convierte en el insumo escaso. El pool utilizable es menor antes de que se facturen tokens.

Los límites de CPU e interconexión reducen la capacidad utilizable

AWS también ofrecerá CPUs NVIDIA Vera como opción para tareas agénticas que requieren un intenso cómputo de CPU junto a los aceleradores. Ese requisito de CPU reduce el pool de aceleradores, porque el servicio agéntico consume tanto tiempo de CPU como de GPU. Las horas de CPU pertenecen al numerador del coste. La asignación de CPU afecta tanto al coste como al rendimiento. Planifica la asignación de CPU antes de asumir que cada hora de acelerador produce tokens.

NVIDIA está extendiendo NVLink Fusion, su interconexión de chips de alta velocidad, al silicio Trainium de Annapurna Labs de Amazon para que Trainium y las GPUs de NVIDIA puedan compartir un diseño a escala de rack. La unidad de servicio se convierte en un dominio compartido, no en una tarjeta independiente. Construye el modelo de servicio en torno al rack, no al chip. La topología del rack determina cuántos aceleradores pueden servir una tarea. Una GPU que no puede acceder a la memoria, la CPU o el acelerador par adecuado produce menos tokens. La restricción es la ruta entre componentes.

Recalcula el precio por token y el coste de las caídas

El coste por token es una ratio, no un precio de lista: el coste total de servicio dividido entre los tokens servidos. Expresa cada partida en dólares por token, incluyendo tiempo de acelerador, tiempo de CPU, interconexión, energía, mano de obra y mantenimiento. Si el numerador sube mientras los tokens por hora de GPU bajan, el precio unitario sube. El denominador es la parte que puede compensar un numerador mayor. Sigue la ratio por trimestre de servicio.

El coste de las caídas es el otro lado de la misma ratio. Los tokens perdidos reducen el denominador, mientras que el trabajo de recuperación eleva el numerador. Los créditos SLA y la fuga de clientes pueden añadir otra capa de coste. Una caída breve puede borrar el margen de muchos tokens facturados. La exposición a caídas pertenece a la misma ratio, bajo estrés.

Usa este orden para convertir la expansión anunciada en un plan de capacidad de servicio con fecha:

• Fecha cada lote de GPUs hasta 2028; no cuentes un lote posterior en un trimestre de servicio anterior.
• Resta la capacidad federal reservada y la no productiva antes de asignar la inferencia de producción.
• Aplica las restricciones de CPU y NVLink, porque un dominio de servicio es tan rápido como su ruta más lenta.
• Recalcula el coste por token y el coste de las caídas tras cada cambio de capacidad.